Google APIキーはなぜ危険になった？「公開OK」がGeminiで崩壊した理由

Google APIキーがGeminiの登場で公開OKから危険に変わった問題を示すダークブルーの背景に鍵のシルエット

2026年2月27日｜読了時間：約10分

「公開していいよ」とGoogle自身が案内してきたAPIキーが、Geminiの登場によって機密データへのアクセス手段に変わっていた。

セキュリティ企業Truffle Securityの調べで、ウェブ上の約3,000個のキーが危険な状態にあると判明した。

なぜ「安全」だったはずの鍵が凶器に変わったのか、実際の被害事例から対処法まで整理する。

この記事でわかること

Googleが「公開してOK」としてきたAPIキーがGeminiの認証手段に——何が起きたのか
攻撃者にできること——データ流出から1日数十万円の不正課金まで
Googleの対応と「今すぐ確認すべきこと」——根本修正はまだ終わっていない
まとめ

Googleが「公開してOK」としてきたAPIキーがGeminiの認証手段に——何が起きたのか

セキュリティ企業Truffle Securityの調査により、Google MapsやFirebase用に「公開しても安全」とされてきたAPIキーが、Gemini APIの認証手段としても機能していることが判明した。

開発者はGoogleの指示に従っていただけだった

APIキーがウェブサイトのソースコードに丸見えだと聞くと、「管理がずさんだ」と感じるかもしれない。
パスワードを付箋に書いてモニターに貼っているようなものだ、と。

ところがこの場合、開発者たちはGoogleの公式ドキュメントに従っていた。

Firebase公式の記載

Firebaseのセキュリティチェックリストには「APIキーは秘密ではない」「クライアントコードに安全に埋め込める」と明記されている。
Google Mapsのドキュメントでも、APIキーをHTMLに直接貼り付ける方法が案内されてきた。

GoogleのAPIキーは「AIza...」で始まる文字列だ。
もともとは利用量を計測して課金するためのプロジェクト識別子として設計された。

誰かに見られても、料金の上限に引っかかるだけ。
データにはアクセスできない。
だから「公開してOK」だった。

この前提が、Geminiの登場で崩れた。

なぜGeminiで前提が崩れたのか

問題の核心は、権限の「後付け拡張」にある。

① 開発者がGoogle Mapsのためにキーを作り、HTMLに埋め込む（Googleの指示どおり）

② 同じプロジェクトで、別のチームメンバーがGemini APIを有効化する（内部プロトタイプ用など）

③ 元のMapsキーが自動的にGemini APIへのアクセス権も持つようになる

③のステップで、通知も確認画面も一切ない。
開発者は知りようがない。

Truffle Securityの調査によると、Google Cloudの公式ドキュメントでも新規APIキーのデフォルト設定は「無制限」と記載されている。
つまり、プロジェクト内で有効なすべてのAPIにアクセスできる状態で生成される。

CybersecurityNewsはこの問題を、セキュリティ上の弱点の国際分類であるCWE-1188（安全でないデフォルト設定）とCWE-269（不正な権限割り当て）に該当すると報じた。

Google自身も同じ罠にかかっていた

この問題の皮肉な点は、Google自身のウェブサイトに埋め込まれたキーにも同じ問題があったことだ。

Truffle Securityの調べでは、あるGoogleプロダクトの公開ページに埋め込まれたキーは2023年2月から存在していた。
Gemini APIが登場するよりも前だ。

そのキーでGemini APIの /models エンドポイントにリクエストを送ると、200 OK（成功）が返ってきたという。
「公開してOK」というルールを作った側が、そのルールのせいで脆弱ぜいじゃくになっていた。

The Stackの報道では、大手銀行やセキュリティ企業も影響を受けた組織に含まれている。

なぜGoogleだけこの問題を抱えるのか

決済サービスのStripeは「公開キー」と「秘密キー」を最初から分離している。
AWSのAPIキーはすべて秘密扱いで、フロントエンドに埋め込むことを想定していない。
Googleは「公開用の識別子」と「認証用の鍵」を同じ AIza... 形式で共有していたために、Geminiという「認証が必要なサービス」を追加した瞬間に破綻したのではないか。

では、この脆弱なキーを手に入れた攻撃者は、具体的に何ができるのだろうか。

攻撃者にできること——データ流出から1日数十万円の不正課金まで

攻撃は極めて簡単だ。ウェブサイトのソースコードからAPIキーをコピーし、コマンド1行を叩くだけでGeminiにアクセスできる。

curlコマンド1行で終わる攻撃

ファイアウォールの突破も、パスワードの解読もいらない。

ウェブサイトの「ソースを表示」を開き、AIza... で始まるキーをコピーする。
あとはターミナルでコマンドを1行叩くだけだ。

Truffle Securityの報告より

/files/ エンドポイントにリクエストを送り、403（拒否）ではなく200 OK（成功）が返れば、そのキーでGemini APIにアクセスできてしまう。

アクセスできる先には、Gemini APIにアップロードされたデータセットやドキュメント、キャッシュされた会話内容が含まれる。

法務チームが契約書PDFをGeminiに読み込ませていたら、その中身が見える。
人事部が社内規程を分析させていたら、それも対象になる。

攻撃者はデータを盗むだけではない。
Gemini APIを勝手に使い倒して、被害者のアカウントに利用料金を課すこともできる。

Truffle Securityの報告では、モデルやコンテキストウィンドウの設定次第で1日あたり数千ドル（数十万円〜100万円超）の請求が発生しうるとされている。

$300の学生クレジットが830万円の請求に化けた

こうした被害は仮定の話ではない。

実際の被害事例

2025年9月、ある学生がGitHubにGemini APIキーを誤って公開した。
本人が気づいたとき、請求額は約830万円（$55,444.78）に達していた。
使っていたのは$300分の学生向け無料クレジットだけだった。

これだけではない。
別のReddit投稿では、盗まれたGemini APIキーによって48時間で約1,230万円（$82,000）の請求が発生した事例も報告されている。

事例	漏洩の経緯	請求額
学生（2025年9月）	GitHubに誤って公開	約830万円
別のユーザー	APIキーの窃取	約1,230万円

もしあなたのウェブサイトにGoogle Mapsを埋め込んでいるなら、そのHTMLソースコードにはAPIキーが記載されているはずだ。
そのキーが、知らないうちにGeminiへのアクセス手段になっている——それが今回の問題の本質だ。

Googleはこの問題にどう対応しているのか。
そして、自分のプロジェクトが影響を受けているかどうか、どう確認すればいいのか。

Googleの対応と「今すぐ確認すべきこと」——根本修正はまだ終わっていない

Googleは漏洩したAPIキーのブロックを開始し、対策ロードマップを示している。しかし2026年2月時点で根本的な修正は完了していない。

「意図された動作」から「バグ」へ——二転三転した対応

この問題が公になった経緯自体が、事態の深刻さを物語っている。

報道のきっかけは、Googleが脆弱性を修正したからではない。
根本的な修正は2026年2月時点で完了していない。

Truffle Securityが設定した90日間の猶予期限が過ぎたため、やむを得ず公開に踏み切った形だ。

① 2025年11月21日：Truffle SecurityがGoogleの脆弱性報告プログラムに報告

② 11月25日：Googleが「意図された動作」と判断し、修正を拒否

③ 12月1日：Truffle SecurityがGoogle自身のインフラにも問題がある例を提示

④ 12月2日：Googleが → 「バグ」に再分類し、対応を開始

⑤ 2026年1月13日：「単一サービスの権限昇格けんげんしょうかく（読み取り）・Tier 1」に分類

⑥ 2月2日：Googleが「根本修正は作業中」と回答

⑦ 2月19日：90日の情報開示猶予期限が到来。Truffle Securityが情報を公開

注目すべきは、最初の反応だ。
Googleは当初「これは仕様だ」と回答した。

Truffle Securityが「あなたたち自身のサイトも影響を受けていますよ」と示して初めて、態度が変わった。

Googleが打ち出した3つの対策

BleepingComputerの報道で、Googleのスポークスパーソンは「問題を認識しており、研究者と協力して対処した」と述べている。

Googleの公式ドキュメントに記載された対策ロードマップは以下の3点だ。

対策	内容	状況
スコープの制限	AI Studioで新規作成するキーはGemini専用に限定	実施中
漏洩キーのブロック	漏洩確認済みキーのGeminiアクセスを自動ブロック	実施中
開発者への通知	キーの漏洩を検知した際にプロアクティブに通知	計画中

ただし、これらは「今後作られるキー」や「すでに漏洩が確認されたキー」への対策だ。
過去10年間に作られ、まだ漏洩が検知されていない無数のキーについては、開発者自身が確認するしかない。

今すぐ確認すべき3ステップ

Google Maps、Firebase、YouTubeなどGoogleのAPIを使っているなら、以下の手順で確認してほしい。

ステップ1：Gemini APIが有効か確認する
Google Cloudコンソール → 「APIとサービス」 → 「有効なAPIとサービス」を開く。
「Generative Language API」が一覧にあれば、そのプロジェクトは影響を受けうる。

ステップ2：キーの設定を確認する
「APIとサービス」 → 「認証情報」を開く。
各APIキーの制限状態をチェック。
「制限なし」と表示されているキー、または「Generative Language API」が許可リストに入っているキーが危険。

ステップ3：公開されたキーがないか確認する
ウェブサイトのHTML、JavaScriptファイル、GitHubのリポジトリに AIza... で始まる文字列がないか検索する。
見つかったら即座にキーをローテーション（再発行）する。

影響を受けない条件

Gemini API（Generative Language API）が有効化されていないプロジェクトであれば、この問題の影響は受けない。
まずは有効化の有無を確認するところから始めよう。

Googleの「APIキーは秘密ではない」という10年来の方針は、AI時代のセキュリティ要件と正面から衝突した。
修正が完了するまで、自分のプロジェクトは自分で守るしかない。

まとめ

Googleが10年以上「公開してOK」と案内してきたAPIキーが、Gemini APIの認証手段としても機能するようになっていた
攻撃者はウェブサイトのソースコードからキーをコピーするだけで、Geminiのデータにアクセスしたり高額な利用料金を課したりできる
Googleは漏洩キーのブロックなどの対策を始めているが、根本修正は2026年2月時点で未完了
Google Maps・Firebase・YouTube等のAPIを使っている開発者は、GCPコンソールでGemini APIの有効状態とキーの制限設定を今すぐ確認すべき