事前準備
HTMLをアップロードしてURLを発行したら、まずシークレットウィンドウで開いて「認証画面が出るか」「コンテンツが想定どおり表示されるか」を自分の目で確認します。このステップを飛ばすと、パスワードを設定したつもりが実は未設定のままレビュー依頼を送るという事故が発生します。確認後はスクリーンショットを撮って「動作確認済み」の証跡として残しておくと、後のトラブル時に役立ちます。
スマホでの表示確認はPCとは別の通信環境（Wi-Fiではなくモバイル回線）で行うと、CDN設定やキャッシュ起因の問題を発見しやすくなります。スマホ実機が手元にない場合はブラウザのDevToolsでモバイルエミュレーションを使いますが、CSS Gridのサブグリッドなど一部挙動に差が出ることを念頭に置いてください。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
確認観点
HTMLソース内の `<script src>` を全件洗い出し、読み込み先ドメインが承認済みリストに含まれているか確認します。広告タグのテスト版IDや、開発中に追加したデバッグ用スクリプトが残っていることが多いため、本番リリース時のものと差分が出ていないか`grep -n '<script'`で一覧化して目視確認するのが確実です。
APIキーや認証トークンの漏えいはセキュリティレビューで最も指摘される項目のひとつです。`grep -rn 'Bearer\|apikey\|secret\|token'` でHTMLファイル全体を検索し、ヒットした箇所が本当に必要かどうかを開発者に確認します。特にバンドル後のJSファイルにはビルド時の環境変数が混入しやすいため、ビルドログと照合することをお勧めします。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
NG例
「noindexを設定したから大丈夫」と考えて認証を省くのは典型的なNGパターンです。noindexはGoogleのクロールをブロックするだけで、URLを知っている第三者は誰でもアクセスできます。セキュリティ的に機密度の高いレビューページには、必ずパスワードまたはメール認証を組み合わせてください。
もうひとつのNGは、修正のたびに同一URLに上書きアップロードして「最新版と旧版が混在する状態」を作り出すことです。セキュリティ担当者が旧版を見て指摘し、その後に修正版が差し替えられていても気づかずに二重指摘するという混乱が生じます。修正版は別URLで発行し、「旧URLは期限切れにしました・新URLはこちらです」と明示して送ることでこの問題を防げます。
修正後の再共有
指摘対応後に再共有する際は、「何を直したか」の変更サマリをURLと一緒に送ります。「v2を送ります」だけでは担当者が差分を把握できず、再レビューの範囲が広がって時間を消費します。変更箇所は「#3のAPIキー漏えいを修正・#7のnoindexとパスワード認証を両方設定」のように指摘番号と対応を1行ずつ列挙するのが効率的です。
再共有URLには新しい有効期限を設定し、前回のURLは失効させます。もし複数の担当者が並行してレビューしている場合は、旧URLが失効した旨を全員にCCで通知することで「旧URLで確認していた」という行き違いを防げます。ギガサイト便では同一ファイルをアップし直すと新しいURLが発行されるため、うっかり上書きになるリスクがありません。
よくある質問
外部scriptの読み込みが問題になるのはどのようなケースですか？
テスト用のアナリティクスIDや広告タグが残ったままだと、実際のユーザー行動データが汚染されます。また承認されていない第三者スクリプトはXSSの起点になりうるため、セキュリティレビューで必ず確認される項目です。
noindexを設定した場合、パスワード認証は省略できますか？
省略できません。noindexはGoogleのインデックスを防ぐだけで、URLを直接知っている人は誰でもアクセス可能です。機密情報を含むページには必ずパスワードまたはメール認証を設定してください。
画像パスが本番環境でも解決できるか確認する具体的な方法は？
HTMLをアップロードした後、ブラウザのDevTools「Network」タブで404が出ていないか確認するのが最短です。相対パスを使っている場合、ルートが変わると画像が表示されなくなるため、絶対パスまたはデータURI埋め込みへの変換を検討します。