なぜGemini APIを有効化したFirebaseキーが13時間で900万円を溶かすのか

2026年2月のある朝、一人の開発者が目を疑うメールを受け取った。Google Cloudからの請求通知——金額は€54,000、日本円にして約900万円。前日まで月額数千円で動いていたサービスが、深夜の13時間で破滅的な数字に膨らんでいた。ログを辿ってみると、攻撃に使われたのは他でもない、自分が1年以上前から「公開して安全」とされていたため、GitHubにそのまま掲載し続けていたFirebase APIキーだった。

なぜ「公開してよいとされていたキー」が、突然9桁の請求を生み出したのか。その答えは単純なミスではなく、AIブームに乗じたGoogleのインフラ上の「静かな変質」に求めなければならない。

Firebaseキーの安全神話

Firebase（Googleのモバイル・ウェブ開発プラットフォーム）を使ったことがある開発者なら、公式ドキュメントに記載されていた次の記述を覚えているだろう。「Firebaseコンフィグに含まれるAPIキーは公開してかまわない。アクセス制御はFirebase Security Rulesが担うからだ」。「AIza」で始まるAPIキーをJavaScriptコードに埋め込み、GitHubに公開する習慣はFirebase開発コミュニティで広く定着した。

その実態は統計からも浮かび上がる。セキュリティ企業Quokkaが25万件のAndroidアプリを分析した結果、3万5千件を超えるユニークなGoogle APIキーが埋め込まれていることが確認された。Truffle Securityが2025年11月に実施した調査では、2,863件の有効キーがパブリックインターネット上に露出していると判明した。この広がりは「知識不足による失敗」ではなく、Googleが長年公式に維持してきた指示に従った結果だった。

ところが、2025年秋から2026年初頭にかけて、その「公式ルール」が音もなく書き換えられた。

有効化1クリックで爆弾化

GCPプロジェクト上でGenerative Language API（Gemini API）を有効化した瞬間、従来は「Firebaseの設定取得用」に過ぎなかったAIzaキーに、新たな顔が与えられた。GCPのAPIキーは「制限なし」がデフォルト設定であるため、プロジェクト上で有効化された全てのAPIに対して認証情報として機能する仕様になっている。Geminiを有効化した瞬間、そのキーはGemini APIへのアクセス認証としても転用できるようになったのだ。

問題の核心は、この変化が既存ユーザーに一切通知されなかった点にある。2月11日から12日の間に別の被害者が受けた請求は$82,314.44。冒頭の事案では設定していた€80の予算アラートが届いた時点で€28,000に達していた——Googleの処理遅延が最大10分あるため、ボットによる高速な攻撃には間に合わない。

WallarmのセキュリティストラテジストTim Erlinはこの事態を端的に表現した。「無害な課金トークンとして配布された数千のAPIキーが、現在はGeminiクレデンシャルとして公開インターネット上に存在している」。Truffle SecurityはこのリスクをGoogleの脆弱性開示プログラム（VDP）に2025年11月に報告したが、当初Googleは「APIキーの公開は仕様の範囲内」として却下した。インフラへの具体的な影響を示した後にようやく「バグ」として再分類された経緯は、Googleがこのリスクを長期間見過ごしてきたことを示している。問題は、その間にも被害が積み上がり、さらにある「加速装置」が拍車をかけていた。

AIコードが漏洩条件を揃えた

この問題が2026年の現在に急浮上した背景には、AIコーディングツールの急速な普及がある。GitHubセキュリティラボの調査によると、2024年に公開リポジトリで検出されたハードコードされた秘密情報（APIキーを含む）は約2,380万件——前年比25%増という加速ぶりだ。さらに衝撃的なのは、2022年に漏洩した秘密情報の70%が2025年現在も有効なまま放置されているという事実で、古い漏洩キーが「まだ使える武器」として今も悪用されている。

Forbes「AI 50」に選出されたAI企業の65%がGitHub上に検証済みの秘密情報を漏洩させているというデータも、この問題が先端技術企業にも無縁でないことを示している。そして急増要因として見落とされがちなのが「バイブコーディング」だ。CursorやClaude Codeといった自律型AIコーディングツールが普及したことで、開発者が生成コードを十分にレビューしないままコミットするケースが増えている。GitHub Copilotを使用したコードに秘密情報が混入する確率は6.4%と報告されており、AIが書いたコードほど人間によるレビューが薄くなるという逆説が生じている。

「安全とされていた既存キー」「Gemini API有効化という一見無害な操作」「AIコーディングによる新規漏洩の加速」——この三つが2026年春に交差し、Google APIキー悪用の被害件数を急増させる構造が出来上がった。

設定変更で安全が崩れた証明

Googleはこの問題に対応するため、Auth Keys（制限機能付きの新形式キー）の導入、漏洩が確認されたキーの自動ブロック、制限なしキーの段階的無効化を進めている。2026年4月1日からはGemini APIにティア別の月額利用上限が設定され、同年3月23日導入のプリペイド方式では残高ゼロで即座にサービスが停止される仕組みも加わった。

しかし既存の制限なしキーは自動的には安全化されない。GCPコンソールの「APIとサービス → 認証情報」から各キーに「使用するAPIのみ」を制限設定し、Gemini API専用キーをサーバーサイドにのみ配置する——これが現時点での最低限の防護だ。

今回の事案が示す本質は「APIキーの安全性はコンテキストに依存し、後から変化する」という事実だ。1年前は完全に安全だったキーが、有効化ボタン一つで今日の脅威に変わる。AIサービスの機能追加が日常化した現代において、セキュリティレビューは「一度やったら終わり」ではなく、サービス構成が変わるたびに繰り返す継続的なプロセスとなった。13時間と900万円という数字は、その事実を証明する最も高価な教材として記録されるだろう。