ひとことで言うと
CSP Report-Only とは、Content Security Policy のポリシーをいきなり強制適用するのではなく「違反を検出してレポートするだけ」のモードで動かせる仕組みです。通常の `Content-Security-Policy` ヘッダーの代わりに `Content-Security-Policy-Report-Only` ヘッダーを使い、`report-uri` または `report-to` で指定したURLに違反レポートが POST で送られてきます。
実際のページ動作はブロックされません。ユーザーには通常通りコンテンツが表示されつつ、裏でどのスクリプトやリソースがポリシー違反になるかを集計できます。「このHTMLに今のポリシーを当てたら何が壊れるか」を事前に把握するためのドライラン機能と考えると理解しやすいです。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
HTML共有で関係する場面
AI生成HTMLを共有サービスにアップロードする前に、自分のローカルサーバーや簡易テスト環境で `Content-Security-Policy-Report-Only` を設定してページを開くと、ブラウザのコンソールに違反一覧が表示されます。これにより「本番公開後にCSPでブロックされそうなコード箇所」を事前に洗い出せます。
複数のAIツールで生成したHTMLを組み合わせて1つのページを作った場合、インラインスクリプトや外部フォント読み込みが混在しやすく、CSPとの相性が予測しづらいです。Report-Only モードで試すことで、どのリソースが問題になるかを安全に特定し、差し替えや修正の優先順位を決められます。
よくある誤解
「Report-Only はブロックしないから安全」と捉えてずっと Report-Only のまま運用する例があります。レポートを収集して問題を把握したら最終的には通常の CSP に移行しないと、セキュリティ上の保護は実際には機能していません。Report-Only はあくまで移行前の調査フェーズで使うものです。
「レポートが0件ならポリシーに問題がない」という誤解もあります。レポートが届くのはポリシー違反が発生したときだけなので、テストしていないパスやユーザー操作が存在する場合は見落としが起きます。代表的な操作シナリオを一通り実行してから違反件数を判断することが重要です。
安全に使うための注意点
Report-Only のレポート送信先（report-uri）を自分が管理しているサーバーに設定しないと、レポートがどこかへ送信されても確認できません。簡易な受け取り先として requestbin.com などのWebhookサービスを使う方法もありますが、レポートに含まれるURLや情報が第三者のサーバーに送られることを念頭に置き、機密情報が露出しないか確認してください。
AI生成HTMLを共有する際に Report-Only を自分で設定できるケースは限られます。共有サービスがヘッダー設定を管理している場合、ユーザーが独自に Report-Only を追加する手段はありません。その場合は、ローカルHTTPサーバー（例: `npx serve` や VS Code Live Server）でヘッダーを付けてテストし、問題がないことを確認してからアップロードするというワークフローが有効です。
よくある質問
CSP Report-Only と通常のCSPヘッダーを同時に設定することはできますか？
可能です。両方を同時に送信できます。通常のCSPで基本的なポリシーを強制しつつ、Report-Only で次バージョンの厳しいポリシーを試すという使い方ができます。ただし設定が複雑になるため、管理方法をチームで統一してください。
AI生成ページのCSP違反レポートを収集する際、レポートの中に何が含まれますか？
違反したリソースのURL、ブロックされたURIの種類、どのポリシーディレクティブに違反したか、対象ページのURLなどが含まれます。ページURLがクエリパラメータにトークンを持つ場合は、そのURLも含まれることに注意が必要です。
共有サービスのCSPが厳しくてページが壊れるとき、Report-Only は問題の解決に役立ちますか？
直接は解決しませんが、問題の特定に役立ちます。ローカルで同等のポリシーをReport-Onlyで適用してコンソールを確認すれば、どのスクリプトやリソースが原因かわかり、HTMLをどう修正すれば共有サービスで正しく動くかを判断できます。