Google Cloud APIキー約2,900件がGeminiへのアクセス権を意図せず保持 ― 「秘密ではない」前提が崩れた構造的問題

本稿では、Google Cloud APIキーが意図せずGemini API（正式名：Generative Language API）への認証手段として機能していた問題について、発見者であるTruffle Securityの調査結果（2026年2月25日公開）をもとに、技術的な発生メカニズムと実務上の影響、組織としての確認手順について解説する。

発見の概要：「公開識別子」が「認証情報」に変化していた
発生メカニズム：2つの構造的問題
1. 遡及的な権限拡大（Retroactive Privilege Expansion）
2. インセキュアなデフォルト設定
悪用された場合の影響範囲
Google自身のキーでも実証
開示タイムラインとGoogleの対応
実務視点での考察：AI機能の有効化が既存のセキュリティ前提を変える
参考情報

発見の概要：「公開識別子」が「認証情報」に変化していた

セキュリティ企業Truffle Securityの研究者Joe Leon氏は、Google Cloudプロジェクトで使用されるAPIキー（プレフィックス「AIza…」）が、Gemini APIのエンドポイントに対して認証情報として機能することを発見した（Truffle Security、2026年2月25日）。

Google Cloud APIキーは、Google Maps、Firebase、YouTubeなどのサービスでプロジェクト識別や課金管理に使用される。Googleは長年にわたり、用途に応じた文脈で「APIキーは秘密ではない」という趣旨の案内を行ってきた。Firebaseのセキュリティチェックリストでは「アクセス制御はSecurity Rulesで行うため、APIキー自体は秘密ではない」と説明しており、Maps JavaScriptのドキュメントではキーをHTMLに直接埋め込むよう案内しつつ、無制限キーの悪用リスクに対してAPI制限の設定を推奨している。いずれの場合も、キーはプロジェクトの識別子であって認証情報ではないという前提での運用が一般的だった。この指針に従い、多数のウェブサイトがクライアントサイドのJavaScriptコードにAPIキーを公開状態で埋め込んでいる。

Truffle Securityは、2025年11月のCommon Crawlデータセット（約700TiBのウェブアーカイブ）をスキャンし、Geminiエンドポイントに対して有効な状態のGoogle APIキー2,863件を公開インターネット上で確認した。影響を受けていたのは大手金融機関、セキュリティ企業、グローバル人材企業に加え、Google自身も含まれていた。

発生メカニズム：2つの構造的問題

遡及的な権限拡大（Retroactive Privilege Expansion）

問題の核心は、Google CloudプロジェクトでGemini APIを有効化すると、同一プロジェクト内でAPIの制限が設定されていない（Unrestricted）キーや、Gemini APIが許可対象に含まれるキーが、Geminiエンドポイントへのアクセス権を暗黙的に獲得する点にある。この際、開発者への警告、確認ダイアログ、メール通知は一切行われない。

例えば、3年前にMaps用のAPIキーを作成し、Googleの案内に従ってウェブサイトのソースコードに埋め込んだとする。この時点でキーは無害な公開識別子だった。その後、別のチームメンバーが社内プロトタイプ開発のために同一プロジェクトでGemini APIを有効化した場合、そのMaps用キーがGeminiの認証情報として機能するようになる。しかし、キーの権限が変更されたことは誰にも通知されない。

Truffle Securityはこの挙動について、設定ミス（misconfiguration）ではなく権限昇格（privilege escalation）であると位置づけている。キーを公開した時点では正当な行為であり、後から権限が変更されたためである。

インセキュアなデフォルト設定

2つ目の問題は、Google Cloudで新規APIキーを作成した際のデフォルト設定が「Unrestricted（無制限）」となっている点にある。これはプロジェクト内で有効化されているすべてのAPIに対してキーが即座に有効になることを意味し、Gemini APIが有効化されたプロジェクトでは、Maps用に作成した新規キーであっても自動的にGeminiへのアクセス権を持つ。UIには「unauthorized use」に関する警告が表示されるが、デフォルト設定自体は制限なしのままである。

Truffle Securityはこれらの問題をCWE-1188（Insecure Default Initialization of Resource）およびCWE-269（Incorrect Privilege Assignment）に該当すると分類している。

悪用された場合の影響範囲

攻撃者がウェブサイトのソースコードからAPIキーを取得し、Geminiのエンドポイントにリクエストを送信した場合、以下の操作が可能になるとTruffle Securityは報告している。

プライベートデータへのアクセス：Gemini APIの/files/および/cachedContents/エンドポイントを通じて、プロジェクトオーナーがアップロードしたデータセット、ドキュメント、キャッシュされたコンテキストにアクセスできる。

課金の乗っ取り：Gemini APIの利用は有料であり、モデルとコンテキストウィンドウのサイズによっては、1日で数千ドルの請求が発生しうる。関連して、Redditユーザーが「盗まれた」Google Cloud APIキーにより2026年2月11日〜12日の2日間で82,314.44ドルの請求を受けたと報告している（通常の月額利用料は180ドル）。このRedditの報告と今回の脆弱性の直接的な関連は確認されていない。

クォータの枯渇：APIコールの上限を使い切ることで、正規のGeminiサービスを停止させることが可能となる。

なお、この脆弱性が実際に悪用されたかどうかは現時点で確認されていない。

Google自身のキーでも実証

Truffle Securityは、Google自身のプロダクトの公開ウェブサイトに埋め込まれていたAPIキーでも同様の問題を実証した。Internet Archiveの記録から、当該キーは少なくとも2023年2月から公開されており、Gemini API登場以前に埋め込まれたものだった。このキーを使用してGemini APIの/modelsエンドポイントにリクエストを送信したところ、利用可能なモデルのリストが返却された（200 OK）。

開示タイムラインとGoogleの対応

Truffle Securityは2025年11月21日にGoogleのVulnerability Disclosure Program（VDP）に報告した。主要な経緯は以下の通りである。

2025年11月25日、Googleは当初「Intended Behavior（意図された動作）」として報告を却下した。Truffle SecurityがGoogle自身のインフラにおける具体的な実証を提示した後、12月2日に「Customer Issue」から「Bug」に再分類され、深刻度が引き上げられた。Googleは2,863件の露出キーリストの提供を求め、Truffle Securityがこれを提供した。12月12日にGoogleは修正計画を共有し、漏洩キーの検出パイプラインの拡張、露出キーのGemini APIアクセスの制限、開示日までの根本原因修正を約束した。2026年1月13日、Googleはこの脆弱性を「Single-Service Privilege Escalation, READ（Tier 1）」に分類した。

Googleの広報担当者はThe Hacker Newsに対し「この報告を認識しており、研究者と連携して問題に対処した。漏洩したAPIキーがGemini APIにアクセスすることを検出・ブロックするプロアクティブな措置を実装済みである」と回答している（The Hacker News、2026年2月28日）。

Googleが公開したロードマップによれば、今後の対策として（1）AI Studio経由で作成される新規キーはGemini専用スコープをデフォルトにする、（2）漏洩が検出されたキーのGemini APIアクセスをデフォルトでブロックする、（3）漏洩検出時にプロジェクトオーナーにプロアクティブに通知する、の3点が挙げられている。ただし、既存の影響を受けたキーの遡及的な監査と個別通知については、Truffle Securityは実施を求めているものの、Googleからの明確な回答は報じられていない。

実務視点での考察：AI機能の有効化が既存のセキュリティ前提を変える

「秘密ではない鍵」という運用前提の変化

この問題の本質は、単一の脆弱性ではなく、AIサービスの追加がプラットフォーム全体のセキュリティモデルを変質させるという構造にある。

Google Cloud APIキーは10年以上にわたり「秘密ではない」という前提で運用されてきた。この前提に基づいてウェブサイトのHTMLに埋め込まれ、公開リポジトリにコミットされ、JavaScriptバンドルに含まれてきた。これらはすべてGoogleの公式ドキュメントに従った正当な行為だった。しかしGemini APIの登場により、その運用前提が遡及的に成立しなくなった。

問題は、開発者側がセキュリティの前提変更を認識する手段がなかった点にある。APIキーの権限変更時に通知が行われず、既存のキーが暗黙的に新しい権限を獲得するアーキテクチャになっていた。Truffle Securityの表現を借りれば「公開識別子が秘密の認証情報に変わった」のであり、これは設定ミスではなくプラットフォーム設計の問題である。

影響を受ける典型的な構成

以下に該当する組織は、今回の問題の影響を受けている可能性がある。

最も影響を受けやすい構成：Google Maps、Firebase、YouTube等のAPIを利用するウェブサイトがあり、同一GCPプロジェクト内でGemini APIが有効化されている場合。特にMaps APIキーをクライアントサイドJavaScriptに埋め込んでいるケースはリスクが最も高い。

見落とされやすい構成：開発者がAI機能の検証目的でGemini APIを有効化したが、同一プロジェクトに既存のウェブ向けAPIキーが存在することを認識していない場合。チーム内の別メンバーが有効化した場合は、キーの公開担当者が権限変更に気づかない。

新規プロジェクトでの見落とし：GCPで新規APIキーを作成し、デフォルトの「Unrestricted」設定のまま使用している場合。Gemini APIが有効であれば、そのキーは自動的にGeminiへのアクセス権を持つ。

組織としての確認手順

Truffle Securityが推奨する確認手順は以下の通りである。

ステップ1：Gemini APIの有効化状況の確認。GCPコンソールで「APIとサービス」→「有効なAPIとサービス」に移動し、「Generative Language API」が有効になっているかを確認する。組織内のすべてのGCPプロジェクトに対して実施する必要がある。有効化されていなければ、今回の問題の影響は受けない。

ステップ2：APIキーの設定監査。「APIとサービス」→「認証情報」で各APIキーの設定を確認する。警告アイコン（Unrestricted設定）が表示されているキー、またはGenerative Language APIが許可サービスに含まれているキーが対象となる。

ステップ3：対象キーの公開状態の確認。上記で該当したキーが、クライアントサイドJavaScript、公開リポジトリ、その他インターネット上に露出していないかを確認する。特に古いキーほど、Gemini API登場前に公開された可能性が高いため、優先的に確認すべきである。露出が確認された場合はキーをローテーション（再生成）する。

Vibe Coding時代のAPIキー管理への示唆

今回の問題は、先日報じたLovable/Supabaseの事案と構造的に共通する要素を持つ。Lovableの事案ではAI生成コードがSupabaseのRLSを未設定のまま本番にデプロイしていたが、今回のケースではプラットフォーム側のAPI設計がAI機能追加時にセキュリティ前提を暗黙的に変更した。いずれも「AIサービスの有効化が既存のセキュリティ境界を予期せず拡張する」という同一の構造的問題を示している。

Vibe Codingツールを含むAI開発ツールの普及に伴い、GCPプロジェクト内でGemini APIを有効化する機会は増加する。その際、同一プロジェクトに既存の公開APIキーが存在しないかを事前に確認する運用を組み込む必要がある。Truffle Securityが指摘する通り、「公開識別子が暗黙的に秘密の認証情報に変わる」というパターンはGoogle固有の問題ではなく、既存プラットフォームにAI機能を後付けするあらゆるサービスで起こりうる。