シナリオ
あなたはマルチサイトのWebプラットフォームを担当しています。セキュリティチームは、インシデントの把握をユーザーのスクリーンショットに依存しないよう、CSP、Permissions-Policy、非推奨、介入のレポートの一元化を求めています。エンジニアリングチームはReporting APIを提案しています。これは、Reporting-Endpoints でエンドポイントを宣言し、application/reports+json を受信し、任意で ReportingObserver を使ってページ内でレポートを監視するというものです。採用の判断基準、段階的なローンチ、および成功指標を説明してください。
面接官が評価するポイント
- ブラウザで発生する問題の早期検知を、測定可能なユーザーおよびビジネスの成果に結び付けられるか。
- Reporting APIはベストエフォート型であり、信頼性の高いメッセージングチャネルではないことを理解しているか。
- ブラウザのサポート状況、エンドポイントのセキュリティ、プライバシー、データガバナンスへの対処能力。
- 段階的ロールアウト、重複排除、ロールバック基準（ゲート）の設計能力。
前提条件の確認（クラリファイングクエスチョン）
レポートの種類、対象ブラウザ、サイト数、現在のCSP/非推奨のベースライン、データ保持要件、およびアラート対応キャパシティを確認します。エンドポイントにすでに認証があるか、URLフラグメントが送信される可能性があるか、目的がインシデント削減、修復時間の短縮、コンプライアンスの証跡のいずれであるかを質問します。
30秒での回答
低コストでクリティカルではない診断シグナルとして採用します。まずはレポート専用モード（report-only）と少数のサイトサンプルから開始し、承認されたレポートタイプのみを受け入れ、既存のログを保持しながらレート制限、重複排除、マスキング（redaction）を追加します。アクション可能なレポートの割合、初回レポートから修正までの時間、誤検知率、エンドポイントのコスト、古いブラウザのカバレッジを測定します。データ品質とプライバシーのレビュー完了後にのみ対象を拡大します。配信保証を前提としたセキュリティ判断は行いません。
ステップごとの論理的思考
1. 課題と代替案の明確化
Reporting APIは、CSP、Permissions-Policy、COEP、Integrity、非推奨機能、クラッシュ、介入のレポートを転送できます。追加のカバレッジ、クライアント側の負荷・コスト、データの機密性、運用の観点から、既存のRUM SDK、サーバーログ、ブラウザコンソールと比較検討します。
2. 実用最小限のシグナル（MVS）の定義
タイプごとに論理キューを使用し、csp-violation と deprecation から開始します。サーバー側で Content-Type: application/reports+json を検証し、ペイロードサイズ、送信元、フィールドを制限し、サイト、バージョン、フィンガープリント単位で重複排除します。エンドポイントで障害が発生した場合でも、失われるのは診断データのみであり、ページリクエスト自体には一切影響を与えてはなりません。
3. 信頼性と互換性の管理
仕様上、配信は保証されていません。ネットワークやポリシーの状況により、ユーザーエージェントがレポートを破棄する場合があります。MDNでは、サポートは比較的新しいブラウザで最も手厚く、古いデバイスには存在しない可能性があると説明されています。ブラウザのバージョンごとにカバレッジをセグメント化し、サーバーログおよび ReportingObserver を補完として維持します。受信レポートがゼロであることは、違反がゼロであることを証明するものではありません。
4. プライバシー、セキュリティ、ローンチゲートの設定
レポートにはURL、ユーザーエージェント、ポリシーの詳細が含まれる場合があります。HTTPS、認証または推測不可能なパス、クエリパラメータのフィルタリング、保持期間の制限、アクセス監査を活用します。社内サイトおよびトラフィックの1%を対象にレポート専用モードで開始し、エンドポイントの負荷、機密フィールド、アクション可能な割合を監視します。PII（個人を特定できる情報）の漏洩、コストの急増、またはアラートストームが発生した場合は、エンドポイントの設定を無効化します。
質の高い模範解答
これを新しいロギングシステムではなく、ブラウザポリシーと非推奨機能に関する「早期診断レイヤー」として位置付けます。意思決定には3つのゲートを設けます。第1に価値：レポート専用モードで代表的な10サイトをサンプリングし、レポートから既存のチケットが特定できるかを確認し、平均検出時間（MTTD）のベースラインを測定します。第2にリスク：エンドポイントのフィールド、データ保持、クロスサイトの分離、アクセス制御についてセキュリティとプライバシーのレビューを実施します。第3に運用：レポートのバーストに対する負荷テストを実施し、送信元ごとのクォータ、重複排除キー、ドロップ率のモニタリングを設定します。配信はベストエフォートであるため、RUM、サーバーログ、および手動のフォールバックを維持します。ローンチ後は、ブラウザファミリーごとにカバレッジを表示し、アクション可能な割合、MTTR、誤検知、100万ページあたりのレポート数、レポートタイプ別のコストを追跡します。特定のブラウザでカバレッジが低い場合は、結論の適用範囲をカバーされたトラフィックのみに限定します。エンドポイントに異常が発生した場合は、Reporting-Endpoints レスポンスヘッダーを削除することで、コアなページリクエストを変更することなくロールバックします。
よくある間違い
- Reporting APIを信頼性の高いキューやコンプライアンス監査ログとして扱うこと。
- ブラウザのカバレッジを補正せずに、レポート数が減少したことだけで成功と判断すること。
- 未加工のURL、クエリパラメータ、ユーザーエージェントを無期限に保存すること。
- エンドポイントのレート制限、重複排除、コスト、オーナーシップに触れずにSDKの統合ばかりを議論すること。
- レポート専用モード、サンプリング、ロールバック基準を設けずに、全サイトで一斉に有効化すること。
フォローアップの質問と回答
「なぜReportingObserverを使わないのですか？」
ページ内での実験やカスタム処理には適していますが、クラッシュしたページでは監視を継続できません。リモートエンドポイントであれば、ページのライフサイクルから独立してレポートを受信できます。両者は補完し合えますが、どちらも配信を保証するものではありません。
「製品が機能していることをどのように証明しますか？」
ブラウザのカバレッジでセグメント化し、確認された問題に対する検出時間、修復時間、アクション可能な割合、誤検知の事前/事後比較を使用します。同時にエンドポイントのコストとプライバシーイベントも監視します。
「サポートされていないブラウザについてはどうしますか？」
サポートマトリクスをプロダクトの制約条件として扱い、サーバーログとRUMを維持し、結論の範囲をサポート対象トラフィックに限定します。カバレッジを一見均一に見せるためだけに、高コストなポリフィルを挿入することは避けます。