1. 目標と範囲を定義する
監査ツールを開く前にオーナーを一人決め、成果を文章化してください。対象のオーディエンス、ジャーニー、ページやルート、時間枠、そしてその作業が支援すべき意思決定を明記します。役立つゴールは「モバイルで商品をカートに入れて購入に至るフローを完了する」のようなタスクを記述し、単にサイトを速くしたいという曖昧な願いにとどめません。
譲れない条件を列挙します：購入・問い合わせフローの機能、アカウントアクセス、同意（consent）挙動、アクセシビリティ、検索のクロール可能性、承認済みコンテンツ。合成スコアの向上は、フォームが動作しなくなる、コンテンツが検索から隠れる、キーボード操作が難しくなる場合は勝利とは言えません。
開始ページ、ユーザーのアクション、成功した終了状態を一文で書く。
悪化させてはならない成果を選ぶ（例：送信の成功、重大なアクセシビリティブロッカーが増えない等）。
2. 比較可能なベースラインを取得する
コード、コンテンツ、設定、タグを変更する前に、URL一覧、日付、テスト条件、リリースバージョン、レポートやトレース、手動タスクの結果を保存します。web.devは変更前のサイト状態を記録し、複数のページタイプをテストすることを推奨しています。シングルページアプリケーション（SPA）の場合、初回ロードだけでなくルート、コンポーネント、フローを含めます。
複数の視点を使ってください。Lighthouseはパフォーマンス、アクセシビリティ、SEOなどの自動監査を提供します。ストレージをクリアしたかクリーンなプロファイルでの初回ロードをテストし、その後ターゲットタスクを完了させます。十分な実ユーザーデータがある場合は、重要なページ群とデバイスクラスを比較してください。Core Web Vitalsはフィールド測定です：LCPは読み込み、INPは対話性、CLSは視覚的安定性をカバーします。
フィールドデータは実際の訪問を反映し、ラボテストは問題を再現しやすくします。利用可能なら両方を使う。
シミュレートされたロードはユーザー入力がないためINPを測れません；ラボのTotal Blocking Timeはあくまで代替指標です。
3. ジャーニーをエンドツーエンドで監査する
所見をジャーニーとメカニズム別に整理します。ページ資産とサードパーティのリクエストサイズ、タイミング、依存関係を確認してください。モバイルのビューポート、キーボード経路、可視フォーカス、ラベル、エラーメッセージ、見出し、リンクの目的、ズーム、画像・スクリプト・同意依存サービスが遅いまたは利用不可の場合に何が起きるかをチェックします。
自動アクセシビリティ出力はトリアージとして扱ってください。W3Cは、単一のツールだけでアクセシビリティ基準を満たしているか判断できないと述べています；専門的な人的評価が必要です。検索では、重要なレンダリング済みリソースがユーザーだけでなくクローラーにも利用可能であることを確認します。変更が影響する場合は、リダイレクト、canonical、内部リンク、robotsディレクティブ、サイトマップ、構造化データも含めて検討します。
タグマネージャー、解析、チャット、決済、フォント、CDN、API、同意ツールなど、タスクが依存するものを列挙する。
決済、認証、ユーザーデータ、ヘッダー、セキュリティ制御に関する変更は、資格のあるセキュリティや決済のレビューを受ける。
4. ランク付けされたバックログを作る
各項目について小さな仮説を書きます：このページやフローのこのメカニズムを変更するのは、証拠がこの問題の原因を示しているからだ；期待される結果を測定し、名指しのガードレールを保護する。観察と診断は分けて記録してください。保存されたトレースは大きな画像がコンテンツを遅延させていることを示せますが、対処はデザインやコンテンツのレビューも必要です。
項目はImpact（影響）、Confidence（確信度）、Effort（労力）、Risk（リスク）で順位付けします。Impactは優先ジャーニーの優先度、Confidenceはラボ・フィールド・手動の証拠が一致するか、Effortは調整工数も含みます。Riskは依存先、セキュリティ、リリースの複雑さ、可逆性を含みます。重大な機能的またはセキュリティ上の露出はこのモデルよりも優先され、専門家のトリアージが必要です。
オーナー、証拠へのリンク、仮説、ページ、測定項目、ガードレール、依存関係、リリース方法、ロールバックトリガーを保持する。
安全性が求められる場合を除き、無関係なリファクタリングを測定可能な変更にまとめない。
5. 安全にリリースし、戻れる手段を残す
デプロイ前に何が変わるか、承認者、リリースウィンドウ、検証担当者、成功条件、ロールバックトリガー、復旧方法を記録してください。可能なら代表的なステージング環境でテストし、コンテンツ、権限、統合、リダイレクト、同意の選択、一般的な障害経路を含めます。プロダクションはデータ、キャッシュ、設定、サードパーティにより差が出る場合があります。
プラットフォームがサポートする場合は、段階的リリース、フィーチャーフラグ、バージョン管理された資産、または可逆的な設定を使ってください。結果を比較する前にキャッシュとCDNの挙動を確認します。OWASPは設定とデプロイ管理をセキュリティテストの領域と扱っており、ヘッダー、権限、ファイル露出、ドメインやクラウド設定は軽率な最適化変更の対象にすべきではありません。
失敗したチェックアウト、壊れたナビゲーション、予期しないクライアントエラー、アクセシビリティの回帰など、観測可能なトリガーを定義する。
ロールバック計画は復旧時間を短縮できるが、すべてのリスクを除去するわけではない；復旧手順を事前にテストする。
6. 検証、判断、反復する
リリース後、ベースラインの機能チェックと比較可能なラボテストを繰り返します。該当するデバイス、ブラウザ、状態、統合を再確認してください。同一条件で比較する：URL、キャッシュ状態、デバイスクラス、地域（可能なら）、測定ウィンドウ。目標指標だけでなくガードレールも確認します。
証拠が成熟するまで時間を置いてください。Google は検索の変化が現れるまで数時間から数か月かかることがあると述べており、評価するには数週間待つことを推奨しています。実ユーザーパフォーマンスデータは集計された証拠であり、リリース直後の判断材料ではありません。期待どおりなら、保持、調整、調査、またはロールバックを記録し、テンプレート、プラットフォーム、タグ、コンテンツ、依存関係に意味のある変更があれば再ベースラインを行います。
期待したジャーニーの成果が改善し、合意されたガードレールが維持されている。
フィールドやタスクの証拠がラボ結果と矛盾する、または重大なガードレールが後退した場合に行動する。