セキュリティ企業Truffle Securityは2026年2月25日、Google CloudのAPIキー（AIza…形式）に関する権限昇格の脆弱性を公表した。
Google CloudではMapsやFirebase向けに発行されたAPIキーが公開情報として扱われてきたが、同一プロジェクトでGemini API（Generative Language API）を有効化すると、既存のキーが通知なしにGeminiの機密エンドポイントへのアクセス権を獲得する。同社が2025年11月のCommon Crawlデータセット（約700TiB）をスキャンした結果、この脆弱性の影響を受ける有効なAPIキー2,863件を公開ウェブ上で発見した。影響範囲には大手金融機関やセキュリティ企業、Google自身も含まれる。
同社は2025年11月21日にGoogleの脆弱性開示プログラムへ報告し、Googleは同年12月2日に「バグ」へ再分類、2026年1月13日に「単一サービスの権限昇格、READ」（Tier 1）と分類した。2026年2月19日に90日間の開示期限が終了した。
From: 
Google API Keys Weren’t Secrets. But then Gemini Changed the Rules.
【編集部解説】
今回の問題の本質は、「過去に安全とされたものが、環境の変化によって危険になる」という、テクノロジーの進化に伴う構造的リスクにあります。
Google CloudのAPIキー（AIza…形式）は、もともとMapsやFirebaseなどのサービスで使う「プロジェクト識別子」として設計されました。課金の追跡に使われるIDのようなもので、Google自身が公式ドキュメントで「クライアントサイドのコードに埋め込んで安全」と明記してきた経緯があります。実際、Firebaseのセキュリティチェックリストには、2026年2月時点でも「APIキーは秘密情報ではない」との記載が残っています。
ところが、同じプロジェクトでGemini API（Generative Language API）を有効化した瞬間、これらのキーの性質が根本から変わります。公開ウェブページのソースコードに記載されていた「無害な識別子」が、Geminiのエンドポイントにアクセスできる「認証クレデンシャル」へと暗黙のうちに昇格してしまうのです。開発者への通知は一切ありません。
セキュリティの分類としては、CWE-1188（安全でないデフォルト初期化）とCWE-269（不適切な権限管理）の2つに該当します。平たく言えば、「新しく作ったキーが最初から全権限を持つ設計」と、「既存のキーの権限が知らないうちに拡大される設計」が組み合わさった結果、生まれた脆弱性です。
この問題が深刻なのは、攻撃の敷居が極めて低い点にあります。ウェブページのソースコードを表示してキーをコピーし、curlコマンドを1行実行するだけで、被害者がGemini APIを通じて保存したファイルやキャッシュデータにアクセスできてしまいます。インフラへの侵入は不要です。さらにAPIの利用料金を被害者のアカウントに請求することも可能で、モデルやコンテキストウィンドウの設定次第では、1日あたり数千ドル規模の被害が発生し得ます。
注目すべきは、Truffle Securityの報告に対するGoogleの初動です。2025年11月25日の最初の回答は「意図された動作」という判定でした。しかし、研究者がGoogle自身のインフラに埋め込まれたキーで問題を実証して見せたことで、Googleは対応を本格化させています。BleepingComputerの取材に対し、Googleの広報担当者は「漏洩したAPIキーがGemini APIにアクセスしようとする試みを検出・ブロックするプロアクティブな措置をすでに実装した」と回答しています。
この事案から見える長期的な課題は、「AI機能の後付け」がもたらすセキュリティモデルの破綻です。CSO Onlineのジョン・E・ダン氏が指摘するように、開発者がMapsの埋め込み機能でサイトを構築し、後から同じプロジェクトにGeminiを追加した場合、元のキーがGemini経由で保存されたデータセットやドキュメントへの認証手段となります。従来のクラウドサービスでは、公開キーと秘密キーを明確に分離する設計（たとえばStripeのPublishable KeyとSecret Keyの分離モデル）が標準的なプラクティスとされてきました。Google Cloudがすべてのサービスに単一のAIza…形式を使い続けてきた設計判断が、AI時代に入って裏目に出た形です。
Googleはロードマップとして、AI Studioで作成する新規キーのGemini専用スコープ化、漏洩キーの自動ブロック、プロアクティブな通知の3点を掲げています。いずれも有意義な改善ですが、すでに公開状態にある既存キーの遡及的な監査とプロジェクトオーナーへの個別通知については、まだ具体的な対応が示されていません。
この問題はGoogleだけに限られるものではありません。既存のクラウドプラットフォームにAI機能を急速に統合する動きは業界全体で加速しています。2022年時点で安全だったクレデンシャルが、2026年には深刻なリスクとなり得る。「クレデンシャルは静的なリスクである」という従来の前提そのものが、AI統合の時代には通用しなくなりつつあります。Google Cloudを利用しているすべての開発者と組織にとって、自社のGCPプロジェクトでGenerative Language APIが有効になっていないか、APIキーの権限設定はどうなっているかを、今すぐ確認する価値のある事案と言えるでしょう。
【用語解説】
APIキー（API Key）
アプリケーションがサーバーやサービスにアクセスする際に使用する識別用の文字列である。認証やプロジェクトの特定、課金の追跡などに用いられる。
権限昇格（Privilege Escalation）
本来与えられていない上位の権限を、意図せずまたは不正に取得すること。今回の事案では、公開用識別子が機密APIへの認証クレデンシャルに変質した点が該当する。
CWE-1188 / CWE-269
MITRE社が管理するソフトウェア脆弱性の分類体系（Common Weakness Enumeration）における識別番号である。CWE-1188は「安全でないデフォルトによるリソースの初期化（Initialization of a Resource with an Insecure Default）」を指す。プログラムやサービスが初期状態で過剰な権限を付与する設計上の弱点である。CWE-269は「不適切な権限管理（Improper Privilege Management）」を指す。元記事では「不適切な権限割り当て（Incorrect Privilege Assignment）」とも表現されている。
Common Crawl
非営利団体が運営するウェブアーカイブプロジェクトである。インターネット上の公開ウェブページを定期的にクロールし、HTML、JavaScript、CSSなどを大規模データセットとして無償公開している。
Generative Language API
Google CloudにおけるGeminiのAPI名称である。このAPIをプロジェクトで有効化すると、同プロジェクト内の既存APIキーがGeminiのエンドポイントへのアクセス権を暗黙的に獲得する。
VDP（Vulnerability Disclosure Program）
脆弱性開示プログラム。外部のセキュリティ研究者がソフトウェアやサービスの脆弱性を報告するための公式な枠組みである。Googleを含む多くのテクノロジー企業が運用している。
【参考リンク】
Truffle Security公式サイト（外部）
漏洩クレデンシャル検出ツール「TruffleHog」を開発するセキュリティ企業。オープンソース版とエンタープライズ版を提供している。
TruffleHog GitHubリポジトリ（外部）
TruffleHogのオープンソースコードが公開されているリポジトリ。800種以上のクレデンシャルタイプのスキャン・検証に対応する。
Gemini APIトラブルシューティングガイド（Google公式）（外部）
漏洩キーのブロック方針やキー管理のセキュリティ措置ロードマップが記載されたGoogleの公式ページ。
Firebase セキュリティチェックリスト（Google公式）（外部）
Firebaseの公式セキュリティガイドライン。APIキーの取り扱いに関する記載が今回の問題の背景理解に役立つ。
Common Crawl（外部）
インターネット全体のウェブページを定期的に収集・公開する非営利プロジェクト。今回のスキャン対象データの提供元。
【参考記事】
Previously harmless Google API keys now expose Gemini AI data（外部）
BleepingComputerの報道。Googleの広報声明を独自取得し、2,800件以上の有効キー発見と対策を伝える。
‘Silent’ Google API key change exposed Gemini AI data（外部）
CSO Onlineの解説記事。2,863件のキー露出とAI時代のクラウド進化が生む構造的リスクを論じている。
Thousands of exposed Google API keys are now a ticking bomb（外部）
Cybernewsの報道。Googleの公式ロードマップの詳細やGemini専用キーのデフォルト設定方針を紹介している。
Google created a Gemini vulnerability via API keys: report（外部）
The Stackの報道。当初「意図された動作」とされた経緯からTier 1分類までの時系列を整理している。
Leaked Google API keys can expose Gemini API access（外部）
Bitdefenderの解説記事。Gemini普及に伴う公開キーのリスク変化とGoogleの漏洩キーブロック方針を分析。
【編集部後記】
「安全」とされてきたものが、ある日突然リスクに変わる。今回の事案は、AIの急速な普及がもたらす思わぬ副作用を浮き彫りにしました。みなさんが関わるプロジェクトでも、過去に配置したAPIキーが今どのような権限を持っているか、改めて確認してみる価値があるかもしれません。こうした「静かな変化」に気づくきっかけとして、この記事がお役に立てればうれしいです。
