プロンプトとコンテキスト
Reporting API は、CSP、Permissions-Policy、Integrity-Policy、COEP、非推奨、および介入（intervention）レポートのための共通メカニズムをブラウザに提供します。レポートは ReportingObserver を使用してページ内で読み取ることも、ブラウザからリモートエンドポイントへ POST 送信することも可能です。この面接では、ユーザーデータを長期ログにコピーすることなく、ブラウザシグナルを信頼性の高い可観測性に変換できるかどうかが評価されます。
面接官が評価するポイント
- ページ内オブザーバーとリモートエンドポイントの信頼性境界を区別できているか。
Reporting-Endpoints、レポートタイプ別のルーティング、サンプリング、および重複排除を設計しているか。- URL、User-Agent、およびビジネスパラメータにおけるプライバシーリスクに対処しているか。
- レポートオンリー（report-only）でのロールアウト、アラート、修正、およびリグレッション検証を連携させているか。
最初に明確にすべき質問
目標がセキュリティポリシーの移行なのか、ブラウザの非推奨機能のアップグレードなのか、クラッシュの手がかり収集なのかを確認します。ブラウザのサポート状況、クロスオリジンページ、保持期間、コンプライアンス、エンドポイントのバースト処理能力、および未加工の URL をサードパーティに送信してよいかどうかを明確にします。
30秒での回答
収集、転送、処理、ガバナンスの4つのレイヤーを使用します。ポリシーは report-only モードで開始し、Reporting-Endpoints を介してタイプをルーティングし、即時デバッグにはオブザーバーを使用し、ページライフサイクル外での集約にはリモートレポートを使用します。サーバー側でアラートやリグレッションテストの前にレート制限、重複排除、マスキング、サンプリングを適用します。到達は保証されないため、これは実際のエラー監視の代替にはなりません。
ステップごとの詳細解説
1. 収集パスの選択
ReportingObserver は、types および buffered オプションを備え、開発時やページ内での診断に適しています。リモートエンドポイントは User-Agent から application/reports+json の POST を受信し、ページクラッシュ後も手がかりを保持できるため、本番環境での集約に適しています。どちらのパスでも、ブラウザの互換性とレポート欠落への対処が必要です。
2. エンドポイントとルーティングの設計
Reporting-Endpoints で名前付きエンドポイントを宣言し、CSP、COEP、または Permissions-Policy のレポートディレクティブから送信先を選択します。type ごとにセキュリティ、非推奨、信頼性の各パイプラインへルーティングします。専用ヘッダーを持たない crash や deprecation などのレポート向けに default エンドポイントを提供します。取り込み時に Content-Type とボディサイズを検証します。
3. ノイズとプライバシーの制御
サイト、バージョン、レポートタイプ、エラーフィンガープリント単位で重複排除を行い、ソースごとのレート制限を実施し、集約前にクエリパラメータ、アカウント識別子、機密パスを削除します。診断用フィールドのみを保持し、短い保持期間を強制して、アクセスを監査します。単一の互換性問題がアラートストームに発展しないよう、重要度や新バージョンの差分に応じてサンプリングを調整します。
4. ガバナンスループの完結
ポリシーを厳格化する前に、report-only モードでベースラインを確立します。新しい非推奨レポートをブラウザのバージョンやリリースバッチと関連付け、自動リグレッションまたは WebDriver で生成したテストレポートで修正を検証します。エンドポイントの成功率、レイテンシ、欠落、修復時間を監視します。ページをブロックしない縮退パスを維持します。
優れた回答例
まず収集の目標とデータの境界を制限します。ポリシー移行の場合、report-only モードから開始し、Reporting-Endpoints を介して CSP、Permissions-Policy、非推奨レポートを制御されたエンドポイントに送信し、タイプ別にルーティングします。ReportingObserver は即時診断用であり、本番環境の事実はリモート集約から取得します。その際、ブラウザは到達を保証しないという点を明記します。
サーバーは application/reports+json を検証し、サイズとレートの制限を適用し、サイト、バージョン、タイプ、フィンガープリント単位で重複排除します。URL クエリパラメータとアカウント識別子を除去し、バージョンレベルの User-Agent ディメンションのみを保持し、アクセス監査を伴う短い保持期間を適用します。アラートは重要度、リリースの差分、影響を受けたページを使用してサンプリングを行います。修正後、リグレッションテストによってレポート発生率の低下を確認します。このパイプラインがページの実行をブロックしたり、フロントエンドのエラー監視や実ユーザー監視（RUM）を置き換えたりしてはなりません。
よくある間違い
ReportingObserverのみを使用し、ページクラッシュ時に手がかりを失うこと。- 未加工の URL、クエリパラメータ、または完全な User-Agent を長期ログに記録すること。
- ドロップ、スロットリング、ブラウザ間の差異を監視せずに、エンドポイントが到達を保証していると思い込むこと。
- ベースラインの策定や段階的なロールアウトを経ずに、report-only の結果をブロッキングポリシーとして扱うこと。
フォローアップの質問と回答
ページ内オブザーバーとリモートエンドポイントのどちらをどのように選びますか？
オブザーバーはデバッグが容易でページコードで処理できますが、ページが存続していることに依存します。リモートエンドポイントは独立して集約を行い、本番環境やクラッシュ時の手がかりを保持します。重複排除キーを用いて二重カウントを防ぐことで、両者を併用できます。
レポーティングシステムによるユーザー情報の漏洩をどのように防ぎますか？
取り込み時にフィールドの許可リスト、URL のマスキング、サイズ制限、レート制御を適用します。完全な識別子ではなくバージョンディメンションを保持し、暗号化と監査を伴う短い保持期間を使用し、チーム間のアクセスを制限します。
レポート量が突然急増する可能性があるのはなぜですか？
リリース、ブラウザ、サイト、タイプ、フィンガープリント別にスライスして、新しいリグレッション、ポリシー設定ミス、ボットトラフィック、再試行を切り分けます。エスカレーションやリリースのロールバックを行う前に、エンドポイントのスロットリングとサンプリングを確認します。