なぜ危ないのか
社外レビューでは相手のネットワーク環境やブラウザ設定を制御できません。受け取った担当者がURLをSlackやメールで転送したり、スクリーンショットを社内に共有したりする行動を止める手段がありません。URLクエリにトークンが含まれていると、その転送行為のたびにトークンが拡散します。
特に問題になるのは、AIがデモ用として生成したコードに実際のAPIキーを入れてテストした後、そのまま共有してしまうケースです。「デモ用だから大丈夫」と思ったAPIキーが、実際には本番環境で有効な場合があります。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
ソースで見る場所
共有するHTMLファイルをテキストエディタで開き、`?`記号の後に続く文字列を探します。`token=`・`key=`・`apikey=`・`access_token=`のようなパターンがあれば要精査です。JavaScriptで動的にURLを組み立てている場合は、`+`や`${}`による文字列連結でトークンが埋め込まれていないか追跡します。
ブラウザでHTMLを開いた後、DevToolsのConsoleに`location.search`と入力して実行します。クエリ文字列がそのまま表示されるので、機密情報が含まれているか即座に確認できます。Networkタブで外部ドメインへのリクエストURLにもクエリが含まれていないか合わせてチェックしてください。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
安全に共有する設定
確認ステップでトークンが見つかった場合は、ダミー値（例：`preview-only-no-auth`）に書き換えたコピーを作成します。元のファイルは社内保管し、共有するのはダミー版のみです。ギガサイト便にダミー版をアップロードし、ファイル名に「preview」と入れて区別します。
ギガサイト便の共有URLには会社ドメイン認証を設定すると、相手企業の社員のみアクセスできる状態になります。URLを転送されても認証を通過できなければコンテンツは見えないため、トークン不在と組み合わせることで多層的な防御になります。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
再発防止ルール
社外共有前の標準手順書に「URLのクエリ文字列に機密情報が含まれていないことを確認」を必須チェック項目として追加します。チェック欄付きのPDFやNotionテンプレートを用意しておくと、担当者が変わっても手順が維持されます。
AI生成HTMLをプロジェクト管理ツール（GitHub・Notion・Jira）で管理している場合は、共有前にレビューステータスを「セキュリティ確認済み」に変更するフローを設けます。承認者が確認した記録を残すことで、後から経緯を追跡できます。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
よくある質問
ダミー値に差し替えた場合、レビュアーはHTMLの動作を正しく確認できますか？
API呼び出しが含まれる場合はモックサーバーまたはスタブデータを使って動作させます。見た目の確認が目的であればスタティックなHTMLとして動かせる状態にすると、トークンなしでレビューできます。
URLに`?preview=true`のような無害なパラメータがあるだけでも問題になりますか？
previewやlangのような制御フラグは問題になりません。問題になるのはtoken・key・auth・session_idのように認証・識別に使われる値を持つパラメータです。値の中身と用途を判断してください。
社外レビューが終わった後、ギガサイト便の共有URLはどのタイミングで失効させるべきですか？
レビュー完了の連絡を受けた翌日を目安に失効させてください。修正後の再レビューがある場合は新しいURLを発行し直す運用が安全です。自動失効の有効期限をあらかじめレビュー締切日に合わせておくのが最も漏れのない方法です。