會原 
「秘密じゃない」はずのAPIキーが裏口に……。
セキュリティ企業Truffle Securityが米国時間2026年2月25日付の記事で、Googleが長年「APIキーは秘密情報ではない」と案内してきたキーが、AI「Gemini」のAPIにも通ってしまう場合がある問題を公開しました。
同社の調査では、ウェブサイトのソースコードに埋め込まれ公開状態になっているAPIキーのうち、少なくとも2863件がGemini APIのエンドポイントに応答したといいます。
Google CloudのAPIキー（「AIza…」で始まる文字列）は、Google MapsやFirebase、YouTubeなどで開発者が広く利用してきたものです。たとえばFirebaseのセキュリティチェックリストではFirebase用途のAPIキーについて「秘密ではない」と説明しており、クライアント側コードへの埋め込みも許容しています。Google Maps JavaScript APIのドキュメントも、HTML内にAPIキーを含める例を掲載しているほどです。こうした背景から、開発者がキーをフロントエンドに配置する運用は珍しくなかったようです。
ところがTruffle Securityによると、同じGoogle CloudプロジェクトでGemini API（Generative Language API）を有効化すると、既存のAPIキーが追加の警告や通知なしにGemini側でも使える状態になり得るのだとか。もともとGoogle Mapsの表示などで公開前提だったキーが、プロジェクトの設定変更をきっかけにGemini側の「鍵」としても機能してしまうわけです。同社は有効化の際に警告表示や確認ダイアログ、メール通知が一切ない点を問題視しています。
公開状態のAPIキーを悪用すれば、Gemini APIの「/files」や「/cachedContents」といったエンドポイント経由でアップロード済みファイルやキャッシュ内容にアクセスできるおそれがあるほか、API利用料を第三者に消費されるリスクもあるとのこと。
影響は広範囲に及び、大手金融機関やセキュリティ企業、人材採用企業のキーが該当したほか、Google自身の公開サイトに埋め込まれていた古いAPIキーでもGemini APIの「/models」エンドポイントが応答する例を同社は確認したそうです。ただし、これをもって社内データが実際に閲覧されたとまでは断定できません。
Truffle Securityがこの問題をGoogleへ報告したのは2025年11月21日のことです。Googleは同月25日、当初この挙動を「意図したもの」と判断しましたが、同社がGoogle側の公開サイト上のキーを含む具体例を提示してやり取りを重ねた結果、12月2日には「バグ」として扱われ対応が動き出したといいます。2026年1月13日にGoogleはこの問題を「単一サービスの権限昇格（読み取り）」に分類し、2月2日時点でも根本原因の修正に取り組んでいると確認したとのことです。90日間の開示猶予（2月19日が期限）を経て、Truffle Securityは2月25日付で調査結果を公開しました。
ここで出てくる「権限昇格」とは、ざっくり言うと「本来なら限られた操作しかできないはずの認証情報で、想定外のデータや機能にアクセスできてしまう状態」のこと。映画のチケットで舞台裏にまで入れてしまうバグ、と考えると分かりやすいかもしれません。今回はAPIキーの「読み取り」権限が意図せず広がったケースとしてGoogleが分類しています。
Google側も対策を進めており、Truffle Securityは「流出したキーを見つけるパイプラインを拡張し、該当キーによるGemini APIアクセスの制限を始めた」と説明しています。GoogleのGemini APIドキュメントでも、公開露出した可能性のあるキーのブロックや、AI Studioで発行する新しいキーの既定スコープ縮小などの対策が確認できます。漏
開発者に対してTruffle Securityは、Google Cloudの各プロジェクトで「Generative Language API」が意図せず有効になっていないか確認し、Geminiに通り得る設定のAPIキーが公開コードやクライアントサイドに含まれていないか点検した上で、露出しているキーはローテーションするよう呼びかけています。
今回の件は、開発者が「昔の前提」で公開していたキーが、後から追加された機能の影響で性質を変えてしまうタイプの問題です。APIキーの制限（利用可能APIの絞り込みやアプリケーション制限）を定期的に見直す重要性を、改めて突きつける事例だといえそうです。
