なぜ危ないのか
LLMはプロンプトに含まれた文字列パターンをそのままコードに反映する傾向があります。「OpenAI APIを使ったチャットUIを作って」と依頼する際に過去の会話でキーを貼っていると、生成HTMLのscriptタグにそのキーが出現することがあります。開発者本人が見落としがちなのは、AIが「例として」キーを埋めてしまうケースです。
公開されたHTMLはGitHubやCloudflare PagesのCDNキャッシュに乗ることもあり、削除しても検索エンジンのキャッシュに残り続ける場合があります。「数時間で削除した」としても、その間にクローラーがキャッシュした可能性を排除できないため、そもそも公開しないことが最重要です。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
ソースで見る場所
ターミナルで`grep -rn 'key\|token\|secret\|Bearer\|sk-\|AIza' index.html`を実行すると、キーらしき文字列の行番号を一覧できます。プロジェクト全体をスキャンするなら`grep -rn`でディレクトリを指定し、.htmlと.jsを対象に絞ると誤検知が減ります。
ブラウザの開発者ツール（Network タブ）でページを読み込み直し、外部へのリクエストのヘッダーを確認します。Authorizationヘッダーや`x-api-key`カスタムヘッダーにキーが含まれていれば、JavaScriptがランタイムで送信しており、HTMLソースに直書きされていなくても同様のリスクがあります。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
安全に共有する設定
キーをHTMLから除去した後、機能の代わりにモックレスポンスを返すスタブ関数を差し込むと、レビュアーが動作UIを確認しつつ実キーへのアクセスをゼロにできます。例として`fetch('/api/chat')`を`Promise.resolve({text:'モック回答'})`に置き換えるだけで済みます。
共有先が社内であればVPNやアクセス制御つきのストレージを使い、社外の場合はギガサイト便のようなパスワード保護プレビューで公開範囲を絞ります。URLを知れば誰でも開ける状態での共有は、キーを除去した後でも意図しない情報開示のリスクを残します。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
再発防止ルール
AIへの依頼プロンプトに「APIキー・シークレット・トークンの実値は絶対に出力しないこと。代わりに`process.env.API_KEY`や`'YOUR_KEY_HERE'`形式のプレースホルダを使うこと」と明記します。この一文を含むシステムプロンプトをチームで標準化することで、生成段階での混入を防ぎます。
CI/CDパイプラインにsecret-scan stepを追加し、HTMLをビルドした直後に`gitleaks`や`trufflehog`でスキャンします。検出された場合はビルドを失敗させ、手動確認を促す仕組みにすることで、プロンプトルールをすり抜けた場合のセーフティネットとして機能します。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
よくある質問
プレースホルダ文字列を使っているのにAIが実キーに書き換えてしまう場合は？
AIが過去のコンテキストからキーを推測して補完している可能性があります。新しいチャットセッションを開始し、キーを一切含まない状態でプロンプトを作り直してください。
grepで何もヒットしなければ安全と判断してよいですか？
grepは既知のプレフィックスを探すため、プロバイダーが変わるとパターンが漏れます。Node.jsの環境変数やビルド時のenv置換が正しく動作しているか、ビルド後のファイルも確認してください。
すでに公開してしまったキーを無効化した後、追加でやるべきことは？
新しいキーを発行して環境変数に設定し直します。また、旧キーでのAPIアクセスログを取得して不正利用がなかったか確認し、社内インシデント手順に従って記録を残しておくと後の監査に役立ちます。