「13時間で6万ドル請求」漏えいしたFirebaseキーが、AI開発アプリを壊し続ける理由

日本の開発者が、Firebase + Gemini のアプリから流出した Google API キーが原因で、13時間で$60,000（約900万円）もの請求を受けました。今朝 Qiita でその投稿がトレンドになっているのを見て、胃が痛くなりました――新しい話だからではありません。CodeHeal（AIが生成したコード用のセキュリティスキャナ）を作っている中で、毎週まったく同じミスを見てきたからです。

キーが露出していました。そのキーには参照元（リファラ）制限がありませんでした。攻撃者がそれを見つけ、Gemini に向けて投げて、数時間で予算を燃やし尽くしたのです。以上です。これが「ハック」の全てです。

これは、2026年にAI加速プロジェクトが壊滅する #1 の方法で、誰もそれについて十分に話していません。

実際に何が起きたのか

短く言うと：

• 個人開発者が Firebase + Gemini のアプリを出荷した
• Google API キーがフロントエンドのバンドルに紛れ込んだ（よくあることです。Firebase の Web SDK は、文字通りそこに貼り付けるよう求めます）
• そのキーには Application restriction（アプリ制限） も API restriction（API制限） も設定されていなかった
• 誰かがそれをスクレイピングし、Gemini に向けて投げ、13時間で約9,000,000円（159円/$ の今日のレートで約$60K）を使い切った
• Google の不正検知が発動するのが遅すぎた

請求書は、開発者が朝のコーヒーを飲み終える前に届きました。

なぜAI生成コード時代ではこれがこれほど悪くなるのか

私は CodeHeal を、こうしたパターンが繰り返し起きるのを見続けていたからこそ作りました。Claude が生成したリポジトリや Copilot が生成したリポジトリをいくつもスキャナにかけてみた結果、次のことに気づきました：

1. LLM は「とりあえず動く」に最適化されがちです。
「Next.js アプリで Firebase + Gemini をつなげて」と AI に頼むと、最も抵抗の少ない方法――生のキーを入れたクライアントサイドの設定オブジェクトにしてしまう――が選ばれます。コンパイルでき、デモが動き、開発者は出荷できます。LLM がほとんどの場合止まって 「ちなみに、このキーはもう公開されています。制限をかけましたか？」 と言うことはありません。

2. Firebase の公式ドキュメントが水を濁します。
Firebase の Web 設定は技術的には公開される想定になっていますが、安全なのは、制限をかけて Firebase Security Rules に依存している場合のみです。同じキーが制限なしで、さらに Gemini の API アクセスまで紐づいているなら、あなたは「他人が開ける蛇口」を作ってしまっているのと同じです。

3. フィードバックループが壊れている。
キーが漏れたと学ぶのは、請求が届いてからです。CI のアラームも、型チェックも、テスト失敗もありません。ここはまさに、静的解析がその出番を持つカテゴリです。

CodeHeal の初期テストでは、GitHub からクローンした公開の「Firebase + AI」スターターを約40件スキャンしました。そのうち32件には、少なくとも 1つの露出キー、または制限が欠けた状態の Firebase 設定が、平文のまま入っていました。割合にすると80%です。私は特別に選び抜いていません――GitHub 検索の最初の2ページに出てくるスターターが対象です。

その瞬間、私はスキャナをサイドプロジェクトとして書くのをやめ、プロダクトとして書き始めました。

なぜこれを LLM で検出しなかったのか

CodeHeal を最初に試作したとき、最も明白なことをやってみました。リポジトリをモデルに渡し、シークレットを検出するよう頼むのです。同じ入力を5回実行しました。すると、5通りの答えが返ってきます。ハードコードされたキーをまるごと見逃すこともありました。「存在しない」リーク済み JWT をでっち上げることもあります。さらに、一度は process.env.NEXT_PUBLIC_API_KEY は 環境変数を使っているから安全だと言われました――しかし、まさにそのバグがあなたに$60K の請求をもたらします。なぜなら NEXT_PUBLIC_* はブラウザへ出荷されるからです。

その日、私は LLM を引っこ抜いて、エンジンを書き直しました。純粋な静的解析――AST の走査、パターンマッチング、ルールベースのヒューリスティックとして。検出は今では決定的です。同じ入力は、常に同じ出力を生みます。セキュリティツールにおいて、それは最低限の土台です。正直なところ、市場にある「AIセキュリティ」スキャナの多くが、まだ LLM をループに入れて動かしていることに驚いています。

CodeHeal は現在 14カテゴリ と 93ルール を搭載しています。ハードコードされたシークレット／無制限クレデンシャルのカテゴリが、自己回収し続けているものです。

今日あなたが本当にやるべきこと

今すでに本番環境で Firebase + AI アプリを動かしているなら、以下は10分チェックリストです：

1. Google Cloud Console → APIs & Services → Credentials を開く。 すべての API キーに Application restriction（アプリ制限）（HTTP リファラ、IP、または Android/iOS アプリ）と API restriction（API制限）（呼び出せる API を制限）を、両方設定してください。片方だけではダメです。両方です。
2. フロントエンドのバンドルを確認する。 ビルド済み JS を開き、AIza を検索してください。Google API キーのプレフィックスです。リファラロックがないものが見つかったら、スタンドアップの後ではなく 今すぐローテーションします。
3. 予算アラートは必須です。 あなたを壊すような金額にならないハード上限を設定してください。Google のデフォルトは「何も設定されていない」ことが多いです。
4. Gemini/Vertex キーは、決して、決してクライアントに置かない。 バックエンドのルート経由でプロキシしてください。プロトタイピング的でも気にしません。
5. プッシュの前に毎回スキャナを実行する。 後ではありません。前です。

CodeHeal がこのカテゴリをどう扱うか

ルール定義は開示しません（検出ロジックはプロダクトなので）という前提で、全体像だけ言うと：

• クライアントへ送られるソースファイル内の「キーっぽいリテラル」を探します（Next.js NEXT_PUBLIC_*、Vite VITE_*、CRA REACT_APP_*、および生の文字列パターン）
• 既知のプロバイダープレフィックス（Google、OpenAI、Anthropic、Stripe など）と照合し、確信度の違いに応じた扱いをします
• フレームワーク固有の落とし穴もチェックします――Firebase 設定オブジェクト、リポジトリにコミットしてしまったハードコード済みの Vercel 環境値、誤って追跡されてしまった .env.local ファイルなど
• 発見結果は件数ではなく被害範囲（ブラスト半径）でランク付けします。露出した Gemini キーは、数百の見た目だけの警告よりも上です

Firebase + Gemini の Next.js アーキタイプのアプリでは、CodeHeal のスキャンは2秒未満で動作し、無制限キーのパターンを Critical としてフラグを立てます。$60K の物語の開発者は、最初の git push の時点でその警告を見ていたはずです。

気まずい真実

AI は、これまで1週間かかっていたものを午後に出荷できるようにします。その一方で、午後に本番クレデンシャルを漏えいさせることも可能にします。スピードアップは対称的です――つまり、速くなった分、請求システム側も容赦なく回ります。そして Google、OpenAI、Anthropic、その他あらゆる AI プロバイダの課金システムは、あなたを救うためには作られていません。収益は利用に基づくため、救わないように明確に作られているのです。

雰囲気でコードを書いてしまう AI アプリに対して、静的解析はあなたが買う中で最も安い保険です。

まとめ

あなた自身の AI 生成リポジトリをスキャンした結果がどうなるか見たいなら、CodeHeal はブラウザで動作し、無料プランの signup なしで利用できます：

CodeHeal でリポジトリを無料でスキャンする

無料プランで1日5回のスキャン。14カテゴリ、93ルール、LLM なし。同じ入力なら毎回同じ結果です。コード内に無制限の API キーが見つかった場合、スクレイパーより先に分かります。