13時間で€54,000の課金急増: API制限のないFirebaseブラウザキーでGemini API呼び出しが発生
(discuss.ai.google.dev)- FirebaseブラウザキーがAPI制限なしで露出しており、外部からGemini APIリクエストが自動的に発生し、短時間で多額の課金が発生
- 実際のユーザートラフィックとは無関係に13時間で€54,000超の費用が請求され、コストアラートの発報が遅延して対応が遅れた
- Google Cloudサポートは当該リクエストを**正常な利用(valid usage)**として分類し、料金調整の要請を拒否
- Googleは支出上限、認証キー、自動キー無効化、前払い課金などの保護機能を導入し、無制限キーの利用を段階的に終了する予定
- 開発者はクライアントコードにキーを含めず、APIキー制限と予算上限設定を必ず適用する必要がある
Firebaseブラウザキー露出によるGemini API課金急増の事例
-
事件の概要
- 既存のFirebase Authenticationのみを使っていたプロジェクトでFirebase AI Logicを有効化した直後、Gemini APIの使用量が急増
- 実際のユーザートラフィックとは無関係な自動化リクエストが短時間で発生し、約13時間で€54,000超の課金が発生
- APIを無効化し、認証情報(credential)をローテーションした後に異常トラフィックが停止
- 予算アラート(€80)およびコスト異常検知アラートが数時間遅れて発報し、対応時点ではすでに€28,000規模の費用が発生
- 最終請求額は遅延したコスト報告により€54,000超で確定
-
Google Cloudサポートの結果
- ログと分析資料を提出したが、**リクエストがプロジェクトで発生した有効な利用(valid usage)**に分類され、料金調整の要請は拒否された
- 当該利用は異常でありユーザー主導のトラフィックではないにもかかわらず、システム上は通常課金として処理された
-
ユーザーの問い合わせ事項
- Firebase AI LogicまたはGemini有効化後に類似事例が存在するかを質問
- App Check、クォータ、サーバーサイド呼び出しへの移行以外に追加の保護手段があるかを問い合わせ
- このようなケースに対する**追加のエスカレーション経路(escalation path)**が存在するかを質問
Google側の回答 (Logan Kilpatrick)
-
課金および利用制限機能
- **Gemini APIユーザー向けの課金上限(billing account caps)**が導入されており、Tier 1ユーザーは月額$250上限以降は自動的に停止
- **プロジェクト単位の支出上限(project spend caps)**を設定可能で、例として個人アカウントは$50に制限設定
- すべての課金レポートには約10分の遅延が存在
-
APIキーのセキュリティと変更点
-
制限のないAPIキー(unrestricted key)の利用はまもなくGemini APIで無効化予定
- 新規ユーザーにはデフォルトで認証キー(Auth key)が生成され、これは従来よりセキュリティが強化された形式
- クライアントコードにキーを含めないこと。露出すると費用が発生する可能性がある
- 公開Webでキーが露出すると自動検知して無効化する機能があり、実際に数分で遮断された事例がある
-
-
キー制限とサービス範囲
-
Google AI Studioで生成されたキーはデフォルトでGemini API専用に制限
- 一方、Google Cloud Consoleなど他の経路で生成されたキーは複数サービスにアクセス可能で、必要に応じてサービス別の制限設定が必要
-
-
追加対応と今後の計画
- 問題事例の確認のため、**直接メール(Lkilpatrick@google.com)**での連絡を要請
- **前払い課金(prepaid billing)**制度が導入され、利用前決済方式へ移行中
- 現在米国の新規アカウントに適用済みで、世界全体へ段階的に拡大中
- これらの措置は開発者のコスト統制と予期しない課金の防止強化を目的としている
1件のコメント
Hacker Newsの意見
予算アラート（€80） と 費用超過アラート を設定していたが、どちらも数時間遅れて発動した
対応した時点で費用はすでに €28,000 に達しており、最終的には遅延した費用レポートのせいで €54,000 以上が請求された
この状況で「ハードな支出上限は技術的に不可能だ」という3社の言い訳には説得力がない
ハードキャップが不可能だというのはおかしいし、少なくともユーザーに選択肢は与えるべきだ
昔ならこういうミスは単なるバグだったが、今では破産につながりかねない
浴室のタイル交換を頼んだのに庭のリフォーム代まで請求されたら、当然拒否する権利がある
ただ、通信事業者の課金システムを扱った経験からすると、TB単位のログを集計するのに時間がかかるのは理解できる
とはいえ通信会社は普通、2〜3%の 不良債権 を見込んだうえで顧客に配慮する
Google もこうした状況ではもっと 上品な対応 をすべきだ
特に AI キーが公開された直後にこうなったなら、Google がキースキャンを検知して遮断すべきだった
だが実際には、この機能はまともに動いていないようだ
私も似たような経験がある
GCP で $100 の予算を設定していたのに、超過してから 5時間後になってようやくメール通知 を受けた
こういう機能の優先順位が低いことに驚く
短期的には Google の収益は増えるかもしれないが、こんな経験をした開発者は二度と勧めなくなるだろう
うちの 2人チーム も runaway job のせいでほぼ潰れかけた
GCP 推奨どおりにアラートと kill switch を連携させたのに、通知が6時間遅れて届いた
結局、証拠を示してようやく返金してもらえた
Google は「明細項目が多すぎてパイプラインが詰まった」と言っていたが、まさにその状況に備えるための仕組みではないのか
結局 Google との費用精算はどうなったのか気になる
どのクラウドも 金の流れを止める機能 を先に作ろうとはしない
後期資本主義 の典型的な姿だ
GitHub 検索結果を見ると、公開リポジトリに Gemini API トークン がそのまま露出しているケースが多い
Google は長いあいだ API キーを秘密情報として扱っておらず、LLM キーになってから急に秘密扱いに変わった
おそらく投稿者はフロントエンドやコード共有の過程でキーを露出させてしまった可能性が高い
関連する HN スレッド と 公式ドキュメント にも明記されている
それなのに、なぜまたこうした事例が出てくるのか疑問だ
“Your API key was reported as leaked. Please use another API key.”
つまり大半は自動で遮断されているようだ
Google Cloud には ハードキャップ を設定する簡単な方法がない
私も1時間以上設定方法を探し回り、結局 Reddit で Pub/Sub → Cloud Function → 請求の無効化 という方法を知った
完全に 狂気じみた構成 だ
失敗率100% を誇っている
ユーザーが自作した保護策に失敗しても、「それは当社の責任ではない」と言いやすい
使用量がしきい値を超えたら自動で kill-switch が作動する機能があればいいのにと思う
5時間のダウンタイムは許容できても、巨額の請求書は到底耐えられない
この投稿を読んで、私はすぐに Firebase の料金プランをダウングレード した
1か月のあいだ、自分が一度も呼び出していない API に $6,909 が請求された事例を見て衝撃を受けた
私も以前、教育セッション中に API キーを作ったことがあり、もしかすると写真に撮られていたかもしれないと思った
2020〜21年に学生へクラウドサービスを教えていたとき、AWS Free Tier を使っていた
MediaWiki サーバー を立ち上げたが、スパムアカウントが次々に作られ、セキュリティにも不安があった
ネットワークポートが常に攻撃されているように感じた
結局、予算を $20〜30 に制限する方法がないと気づいて AWS を諦めた
クラウドは管理が楽に見えても、無制限の費用爆弾 という点で個人にも企業にも危険だ
個人開発者や小規模チームにとって、パブリッククラウドは 恐ろしく不安な環境 だ
安全装置がなく、費用が無限に跳ね上がる可能性がある
そのため、プロジェクトのかなりの時間を 費用監視と遮断ロジック に費やしている
以前は単純な VPS を使っていたが、最近は Google や AWS のサービスを使わざるを得ないことが多い
それでも GCP は、プログラムから 請求先アカウントの接続を切れる点 が少しだけましだと感じる
アメリカでは法的問題になるだろうが、他の国ではどうなのかわからない
こうした 課金システム は、顧客体験（CX）の観点から見て設計がひどい
課金はイベントベースなので、使用量がキューにたまり、集計が遅れる
通知も集計後にしか来ないため、遅延が起きるとすでに大幅超過になっている
こうした構造は企業だけを守り、顧客は守らない
本当に顧客中心なら、ハードリミットに達した瞬間に その金額を超えて請求されないように すべきだ
そうすれば企業側にも、自ら集計システムを改善する動機が生まれる
プリペイド料金制やデータ通信量上限サービス のように事前に差し引く方式なら十分実現可能だ
結局は Google の ビジネス慣行の問題 だ
Google Cloud の公式ドキュメントによれば、緊急時には 請求先アカウントを無効化 して課金を止められる
公式ガイド には「復旧不可能なリソース損失のリスク」があると警告されている
ただ、テスト用途や社内向けアプリには良い 非常ブレーキ だ
別の代替ドキュメント と 予算アラート設定ドキュメント も参考になる
私は5分で $400 を使ってしまったことがある
私たちも同じ問題を経験した
もともと秘密情報ではなかったキーが、Gemini API を有効化した後に秘密扱いへ切り替わった のに、警告はなかった
幸い通知で早めに気づき、被害は $26,000 に抑えられた
Google サポートに返金を依頼したが最初は拒否され、今は再審査中だ
こういう場合は できる限り上の部署まで問題をエスカレーション すべきだ