Gemini APIで5.4万ユーロ請求、HNはbrowser keyとhard cap問題に集中

HN threadが強く反応したのは、Google AI Developers Forum postの内容が珍しいsecurity incidentというより、誰でも踏みそうな罠に見えたからだ。投稿者は、既存のFirebase projectでFirebase AI Logicを有効にした後、実ユーザーとは合わないautomated trafficが発生し、Gemini APIの利用額が数時間で€54,000+になったと書いている。€80のbudget alertとcost anomaly alertは設定していたが、通知は数時間遅れ、対応時点でcost viewはすでに約€28,000を示していたという。

コミュニティの関心は、誰が悪いかだけではなかった。Google ecosystemの一部では、browser-visible keyが長くclassic secretというよりrestrictionをかけるidentifierとして扱われてきた。だがLLM APIでは、その前提が危うくなる。generate endpointはautomated abuseを短時間で大きな請求に変えられるからだ。HNのコメントは、public GitHubに残るGemini風のkey、昔からのFirebase習慣、そしてbudget alertがspending capではないことをsmall teamが痛い形で学ぶ問題をつなげていた。

ForumではGoogle側の返信が、Gemini APIのbilling account cap、project spend cap、約10分のreporting delayを説明した。さらに、呼び出しをserver-sideに移し、restrictionとcapを明示的に置くことも示している。この情報は重要だが、HN側の不安を消すものではない。billing dataが遅れ、その間もserviceがrequestを受け続けるなら、budget alertは即時ブレーキではなく、大きな損害後の通知になり得る。

実務上の読みははっきりしている。Gemini、Firebase AI Logic、または似たclient-facing AI featureを出すなら、server-side mediation、API restriction、quota、spend capをlaunch前に組み込む必要がある。HNが見た本質は、cloud billing systemが大規模meteringには強くても、個人開発者や小さなチームが求めるemergency brakeはまだ分かりやすくないという点だ。