スタンフォード大学などの研究は、約1,000万のWebページを分析し、有効なAPI認証情報1,748件の露出を確認した。AI生成HTMLにキーが直接書かれていた実例を入口に、公開用JavaScript、ビルド工程、漏えい後の無効化まで解説する。
30秒でわかる / THE SIGNAL
約1,000万のWebページを調査した研究で、14サービスの有効な認証情報1,748件が確認された。露出の84％はJavaScript内。AIが生成したHTMLでも、秘密のキーを埋め込んだまま公開すれば閲覧者に見えてしまう。削除だけでなく無効化・再発行が重要だ。
AIが書いたHTMLに、APIキーがそのまま載っていた
AIにWebサイトの制作を依頼し、生成されたHTMLを確認したところ、APIキーが文字列のまま記載されていた――そんな指摘を受けた経験があるという声がある。これは、AIが意図的に情報を盗むという話ではない。動く機能を優先して生成されたコードに、秘密にすべき認証情報が含まれたまま公開される危険があるということだ。
HTMLやブラウザで動くJavaScriptは、閲覧者の端末に配信される。見た目の画面に表示されていなくても、開発者ツールや通信内容から確認できる場合がある。『画面に見えない』と『外部から取得できない』は違う。
1,000万ページを調べ、有効な認証情報1,748件を確認
スタンフォード大学などの研究者が発表した『Keys on Doormats: Exposed API Credentials on the Web』は、約1,000万のWebページを分析した研究だ。AWS、Stripe、GitHub、OpenAIなど14のサービスに関連する、有効性が確認された認証情報1,748件を発見。これらは9,804ページ、5,693の異なるドメインに現れていた。銀行や重要インフラに関係する露出も報告されている。
重要なのは、1,748件が1,000万サイトの全APIキーの総数ではなく、研究対象のサービスと検証方法で有効と確認できた件数だという点だ。見つかった文字列のすべてが秘密情報というわけでもない。
84％はJavaScript。公開後のファイルに潜む落とし穴
研究によれば、確認された認証情報の露出の84％はJavaScriptファイルに存在した。さらに、JavaScript経由の露出の62％は、公開用にコンパイル・結合されたバンドルファイルでのみ確認された。第三者のリソースを通じて伝播した例もある。
開発中のソースコードだけを調べても、公開時のビルド工程で環境変数が埋め込まれる場合は見逃す恐れがある。例えばクライアント向けの環境変数として扱われる設定に秘密鍵を入れると、公開JavaScriptへ取り込まれ得る。環境変数に移すだけでは、必ずしも秘密を守れない。
AI生成コードは危険なのか。研究結果との境界線
今回の研究はWeb上の認証情報の露出を測定したものであり、AI生成コードが漏えいの主因だと証明したものではない。一方、AIにHTMLを生成してもらい、秘密のAPIキーがそのまま記載されていたという実例は、専門家以外にもWeb制作が広がる時代の注意点を示す。
AIが作ったコードでも、人が書いたコードでも、ブラウザへ送るファイルに秘密情報を置かない原則は同じだ。秘密を必要とするAPI呼び出しは、原則としてサーバー側で処理する。公開利用を前提とする識別用キーも存在するため、名称だけで漏えいと断定せず、提供元の仕様、権限、ドメイン制限などを確認したい。
消すだけでは終わらない。無効化は約26％
研究チームは問題を発見した組織へ通知し、その後の対応を追跡した。14日後、公開場所からの認証情報の削除は進んだ一方、有効な認証情報の減少率は約26％にとどまった。公開HTMLやJavaScriptから文字列を消しても、第三者がすでにコピーしていれば使われ続ける可能性がある。
秘密のキーが公開された場合は、対象キーを無効化・ローテーションし、新しいキーへ切り替える。あわせてアクセス履歴、請求額、権限、関連サービスへの影響を確認する。公開ファイルやキャッシュ、リポジトリ履歴にも残存していないか点検が必要だ。
AIでWebサイトを作った人が確認したい5項目
① 公開HTML・JavaScript・JSONなどに秘密のAPIキーやトークンが含まれていないか。② ビルド後の公開ファイルを実際に確認し、環境変数が意図せず混入していないか。③ GitHubなどの公開リポジトリと過去のコミットに秘密情報が残っていないか。④ APIキーの権限、利用元制限、予算上限、監視設定は適切か。⑤ 漏えいが判明した場合、ファイルの修正だけでなく無効化・再発行と利用履歴の調査を済ませたか。
秘密のキーが必要な機能は、クライアント側にキーを埋め込むのではなく、サーバー側の処理や適切な認証方式へ設計を改める。
WORK SIGNALの視点｜AIに任せる範囲と、公開の責任を分ける
ここからは編集部の考察だ。AIでWebサイトを作れることは、技術への入口を広げる。一方、動作確認だけで公開を判断すると、見えないリスクを見落としやすい。AIの利用をやめるのではなく、生成・検証・公開・運用という工程を分け、秘密情報の点検を標準作業にしたい。
重要なのは『AIが書いたから危険』という単純な結論ではない。誰が作ったコードでも、公開した時点でどの情報が外部に届くのかを確かめる仕組みが必要だ。小さなサイトでも、公開前チェックとキーの管理を省略しないことが、利用者と事業を守る第一歩になる。
一次情報・参考資料
研究論文（2026年3月公開）：https://arxiv.org/abs/2603.12498 研究者による論文紹介：https://gsmaragd.github.io/publications/CCS2026-WebKeys/ ITmedia NEWS（2026年10月23日）：https://www.itmedia.co.jp/news/article/2610/23/2000002515/