Googleでさえ追いつけない ─ AI時代のセキュリティは「秒単位」の戦いになった

Googleでさえ「走りながら守る」時代に入った

AIは、企業の生産性を押し上げる道具であると同時に、セキュリティ担当者にとっては新しい攻撃面そのものになっている。生成AI、社内エージェント、学習データ、プロンプト、外部SaaS、マルチクラウド環境。かつてはネットワーク境界や端末、サーバー、ID管理を中心に考えていればよかった防御の対象が、いまや「AIが触れるすべて」に広がっている。

TechCrunchが報じたGoogle Cloud COO、Francis de Souza氏の発言は、その変化を象徴している。同氏は、企業がAIを導入するなら、セキュリティはあとから付け足すものではなく、最初からプラットフォーム設計に組み込むべきだと強調した。従業員が勝手に外部のAIツールを使う「シャドーAI」、複数クラウドにまたがるデータ管理、監査可能性、ガバナンス。これらはすでに情報システム部門だけの課題ではなく、経営層や取締役会が扱うべきリスクになっている。

特に重要なのは、AI導入が「便利な新機能の追加」では済まない点だ。AIエージェントが社内システムを横断して動くようになると、人間が忘れていた古いデータ置き場、更新されていないアクセス権、放置されたSharePointや古い業務ファイルまで掘り起こされる可能性がある。これまで「誰も見つけないから問題にならなかった」データが、AIによって一気に可視化される。つまりAIは、攻撃者だけでなく、企業内部の“過去の管理不備”まで高速に発見してしまう。

攻撃は「時間」ではなく「秒」で進む

de Souza氏は、侵害から次の攻撃段階へ進むまでの平均時間が、かつての数時間単位から秒単位へ縮まっていると説明している。これはセキュリティ担当者にとって極めて重い意味を持つ。人間がアラートを見て、状況を確認し、関係者を集め、判断し、手作業で遮断する。その間に、攻撃はもう次の段階へ進んでいる。

この流れの中で、Google Cloud側が示す答えは「AIネイティブな防御」だ。人間が直接すべてを操作するのではなく、AIエージェントが監視、防御、初動対応を行い、人間はそれを監督する。攻撃が機械の速度で進むなら、防御も機械の速度で動かすしかないという発想である。

この考え方自体は合理的だ。だが同時に、そこには大きな矛盾もある。AIを使って守るには、そのAI自体が安全でなければならない。AIが参照するデータ、AIを呼び出すAPI、AIが使う認証情報、AIの利用料金を管理する課金システム。それらの基盤に穴があれば、AI防御は守りではなく新しいリスクになる。

Gemini APIキー問題が示した「古い前提」の崩壊

今回のTechCrunch記事が興味深いのは、Google Cloudのセキュリティ提言を紹介するだけでなく、Google自身が直面している問題にも触れている点だ。特に注目されたのが、Gemini APIをめぐる一連の高額請求トラブルである。

問題の中心にあるのは、Google CloudのAPIキーの扱いだ。長年、Google MapsやFirebaseなどでは、APIキーはクライアント側コードに埋め込まれることが珍しくなかった。開発者にとって、これは必ずしも「パスワードを公開している」という感覚ではなかった。サービス識別や課金のための公開可能なキーとして扱われてきた面がある。

ところが、Gemini APIのような高額なAI推論サービスが同じプロジェクト内で有効化されると、既存のAPIキーがAIリクエストにも使える状態になり得る。もしそのキーが古いWebサイトのJavaScriptや公開リポジトリ、過去の設定に残っていれば、攻撃者はそれを見つけ、Geminiや画像・動画生成モデルに大量のリクエストを投げ、開発者の請求アカウントに巨額の費用を発生させられる。

これは単なる「開発者がキー管理を怠った」という話だけでは片づかない。なぜなら、一部の開発者は、当時のドキュメントや一般的な慣行に従ってキーを使っていたからだ。公開してもよいと考えられていた識別子が、後から高額AIサービスの認証に近い役割を持つようになった。ここに、AI時代のセキュリティの難しさがある。昨日まで安全だった設計が、今日の新機能追加で危険な設計に変わるのだ。

「上限」のはずが上限ではないという不信

さらに開発者の不信を強めたのが、利用上限や課金上限に関する問題だ。The Registerの報道では、Google Cloudの開発者が不正なAPI利用によって数千ドルから数万ドル規模の請求を受けた事例が紹介された。中には、月額数十ドル程度だった利用が短時間で1万ドル超に跳ね上がったケースや、250ドル程度の上限を設定していたつもりが、アカウント履歴に応じてより高い利用枠に自動的に引き上げられていたケースもある。

Google側の理屈は、サービス停止を避け、成長する顧客がスムーズに利用拡大できるようにするというものだ。たしかに、急にトラフィックが伸びる正当なサービスにとって、硬直的な上限は障害につながる。AIアプリが急成長する時代には、利用枠の自動拡大は開発者体験をよくする面もある。

しかし、不正利用が起きた瞬間、その設計は逆方向に働く。攻撃者にとっては、盗んだキーでより多く使える余地が広がる。利用者にとっては、「上限を設定していたはずなのに止まらない」という感覚になる。SNS上で最も強く見られた反応も、この点に集中していた。開発者たちは「アラートではなく、本当に止まる上限が必要だ」と訴えている。

Redditで広がった怒りと恐怖

Redditのr/googlecloudでは、Gemini APIやGoogle Cloudの高額請求に関する投稿が相次いでいる。ある投稿者は、B2B SaaSを運営しており、通常は月50ドル程度だったGoogle Cloud請求が、Veo 3やGemini画像出力トークンにより1万ドル超へ跳ね上がったと説明した。本人はそれらのサービスを製品で使っておらず、Googleのサポートに不正利用を訴えたが、当初は「不正の証拠が確認できない」とされたという。

別の投稿では、古いGoogle Maps用APIキーが、Gemini APIを有効化した後に悪用され、約3万6800ユーロの請求が発生したとされている。コメント欄では、「この問題はすでに報じられていたはずなのに、まだ挙動が変わっていないのか」と驚く声や、「Google Cloud Consoleが怖くなった。数万ドルを発生させるキーを持つのは信用できない」という声が見られた。

日本の小規模企業を名乗る投稿者も、Gemini APIの不正利用で約12万8000ドル相当の請求リスクに直面し、倒産の可能性にまで言及していた。コメントでは、Googleが任意のハードストップ、つまり一定額を超えたら確実にプロジェクトやAPIを止める仕組みを提供すべきだという意見が目立った。AIコーディングツールの普及でGoogle Cloudを触る開発者が増えるほど、「全員が完璧にキーを守れる」という前提は現実的でなくなる、という指摘である。

Redditの反応には怒りだけでなく、実務的な回避策も含まれていた。APIキーを使わず、サービスアカウントやより限定された認証方式に移行する、Gemini APIを組織レベルで無効化する、公開サービスとAI利用を別プロジェクトに分ける、API制限を必ず設定する、といった提案だ。つまりコミュニティは、Googleの対応を批判しながらも、自衛策を共有する場にもなっていた。

Hacker Newsでは「設計思想」への批判が強い

Hacker Newsでは、より設計思想に踏み込んだ議論が目立った。Truffle Securityの調査をめぐるスレッドでは、Google APIキーが長年「公開してもよい識別子」に近い扱いをされてきたのに、Geminiによって実質的に高額なAI利用やデータアクセスの鍵になった点が問題視された。

あるコメントでは、APIキーごとに10ドル、100ドルのような明確な支出上限を置けるべきだという比較がなされていた。OpenAIやOpenRouterなどではキー単位・アカウント単位で支出管理をしやすいという見方もあり、Google Cloudの請求アラートは遅延があるため、実際の防波堤にならないという不満が示されていた。

また、「これはユーザー名をパスワードとして使うようなものだ」とする批判も広がった。もちろん、すべての責任をGoogleに押しつけるのは単純化しすぎだという反論もある。Gemini APIはデフォルトで全プロジェクトに有効化されるわけではなく、プロジェクト所有者が有効化する必要がある。そのため、プロジェクトを分離し、キーを制限し、最小権限を守るべきだという意見も根強い。

しかし議論全体としては、AIによって「古いクラウドの慣行」が危険化したという見方が強い。公開前提のキー、高額AI推論、遅延する課金データ、自動拡張される利用枠。個々には説明可能な仕様でも、組み合わさると小規模開発者にとって致命的なリスクになる。

キーを削除しても終わらない「23分」の問題

さらにAikido Securityの調査は、別の不安を投げかけた。同社の検証によると、Google APIキーを削除しても、最大で約23分間、一部のリクエストが認証され続ける可能性があるという。大規模分散システムでは、設定変更が全サーバーに伝播するまで時間がかかることは珍しくない。だが認証情報の失効に関しては、その遅延がそのまま攻撃時間になる。

もし攻撃者が漏えいキーを持っていて、利用者が慌ててキーを削除したとしても、その後しばらく大量リクエストを送り続けられる可能性がある。Gemini APIが有効であれば、料金を発生させるだけでなく、アップロード済みファイルやキャッシュされた会話内容へのアクセスリスクも問題になる。

この点は、AIセキュリティの核心に近い。従来のクラウドリソースであれば、数分の遅延は許容される場面もあったかもしれない。しかしAIモデルへのリクエストは高価で、データも機密性が高い。数分あれば、攻撃者は膨大な推論を走らせられる。AI時代には、認証の「最終的に整合する」という発想は、コスト面でもデータ保護面でも危うい。

Googleの提言は正しい。だからこそ問われる

ここで重要なのは、Google Cloud COOの提言自体は間違っていないということだ。AI戦略にはデータ戦略とセキュリティ戦略が不可欠であり、シャドーAIを放置してはいけない。マルチクラウド、SaaS、外部パートナー、社内エージェントを横断して一貫したセキュリティ姿勢を持つべきだ。攻撃が機械の速度になった以上、防御にもAIを活用する必要がある。

問題は、その正しい提言を実行するための基盤を、プラットフォーム事業者自身がどこまで安全に提供できているかである。企業に「セキュリティを後付けするな」と言うなら、クラウド側も「AI機能を後付けした結果、既存の認証・課金設計が危険化する」事態を避けなければならない。

今回の騒動は、Googleだけの問題ではない。あらゆるクラウド事業者、AIプラットフォーム、SaaS企業に共通する警告だ。AI機能を既存サービスに次々と組み込むとき、過去の設計前提は必ず見直す必要がある。公開してよいキー、内部だけで使うキー、課金上限、データアクセス範囲、失効処理、監査ログ、サポート体制。AI以前の常識をそのまま流用すれば、どこかで破綻する。

企業と開発者が今すぐ見直すべきこと

この問題から得られる実務的な教訓は明確だ。第一に、AIを有効化するプロジェクトと、公開フロントエンドやMaps、Firebaseなどで使うプロジェクトを分離すること。第二に、すべてのAPIキーにAPI制限とアプリケーション制限を設定し、不要なAPIを無効化すること。第三に、単なる請求アラートではなく、実際に停止する支出上限やクォータを確認すること。第四に、古いWebサイト、古いリポジトリ、古いモバイルアプリに残っているキーを棚卸しすること。第五に、AI利用ではAPIキーよりもサービスアカウントやOAuth、最小権限の認証設計を優先することだ。

そして経営層は、AI導入を「現場の便利ツール」ではなく、財務リスクと情報漏えいリスクを伴うインフラ変更として扱う必要がある。1本のキー漏えいが、数千万円規模の請求や機密データ流出につながるなら、それはCISOや開発チームだけでなく、CFO、法務、経営会議のテーマである。

AIセキュリティの本当の課題は「速度差」ではなく「責任の設計」

AI時代のセキュリティは、たしかにリアルタイム化している。攻撃は速く、防御も速くなければならない。しかし本当の課題は、速度だけではない。誰がリスクを負うのか、誰が止める権限を持つのか、何がデフォルトで安全なのか、障害を避ける設計と不正利用を止める設計のどちらを優先するのか。つまり「責任の設計」が問われている。

Googleでさえ、この移行期を手探りで進んでいる。だからこそ、他の企業が無防備なままAI導入を進めるのは危険だ。AIを使えば守れる、AIなら検知できる、AIなら自動化できる。そうした期待の前に、まずAIを取り巻く認証、課金、データ、権限、監査の仕組みを点検しなければならない。

AIセキュリティは、未来の話ではない。すでに、APIキー1本、古いプロジェクト1つ、遅れたアラート1通が、企業の存続を左右する段階に入っている。

出典URL

TechCrunch「Everyone is navigating AI security in real time — even Google」
Google Cloud COO Francis de Souza氏のAIセキュリティに関する発言、シャドーAI、マルチクラウド、エージェント型防御、Gemini API関連トラブルへの言及を参照。
https://techcrunch.com/2026/05/24/everyone-is-navigating-ai-security-in-real-time-even-google/

The Register「Google users fight for refunds as unauthorized API usage bills soar」
Google Cloud／Gemini APIキー悪用による高額請求、Rod Danan氏やIsuru Fonseka氏の事例、Googleの説明を参照。
https://www.theregister.com/ai-ml/2026/05/13/google-users-fight-for-refunds-as-unauthorized-api-usage-bills-soar/5239160

The Register「Google reimburses Register sources who were victims of API fraud」
Googleが一部開発者に返金したこと、ただし自動的な利用枠拡大方針を維持している点を参照。
https://www.theregister.com/devops/2026/05/15/google-reimburses-register-sources-who-were-victims-of-api-fraud/5241429

The Register「Threat hunters find Google API keys still usable 23 minutes after deletion」
APIキー削除後も最大約23分利用可能だったとするAikido調査と、その影響を参照。
https://www.theregister.com/devops/2026/05/21/threat-hunters-find-google-api-keys-still-usable-23-minutes-after-deletion/5244504

Aikido Security「Google API keys keep working after you delete them」
Google APIキー削除後の失効遅延、検証方法、Gemini有効時のデータ・課金リスクを参照。
https://www.aikido.dev/blog/google-api-keys-deletion

Truffle Security「Google API Keys Weren't Secrets. But then Gemini Changed the Rules.」
Google MapsやFirebaseなどで使われていたAPIキーがGemini API有効化によりリスク化する構造、公開キー調査を参照。
https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules

Google公式ブログ「Giving you more transparency and control over your Gemini API costs」
Gemini APIのProject Spend Caps、Usage Tiers、自動アップグレード、支出管理機能に関するGoogle側の説明を参照。
https://blog.google/innovation-and-ai/technology/developers-tools/more-control-over-gemini-api-costs/

Reddit r/googlecloud「Charged $10,138 in March 2026 due to Google's documented Gemini API key vulnerability」
1万ドル超のGemini／Veo関連請求を受けたとする開発者投稿とコミュニティ反応を参照。
https://www.reddit.com/r/googlecloud/comments/1t4xkmf/charged_10138_in_march_2026_due_to_googles/

Reddit r/googlecloud「Unexpected €36.8k Google Cloud Gemini API bill after enabling Gemini」
古いGoogle Maps APIキーがGemini API利用に悪用されたとする投稿とコメント反応を参照。
https://www.reddit.com/r/googlecloud/comments/1shgu71/unexpected_368k_google_cloud_gemini_api_bill/

Reddit r/googlecloud「We are facing possible bankruptcy after unauthorized Gemini API usage reached about $128k」
日本の小規模企業を名乗る投稿者の高額請求事例と、ハードストップを求める反応を参照。
https://www.reddit.com/r/googlecloud/comments/1rv3xr9/we_are_facing_possible_bankruptcy_after/

Reddit r/googlecloud「Google users fight for refunds as unauthorized API usage bills soar」
The Register記事に対する開発者コミュニティの反応、支出上限・API制限・警告表示に関する議論を参照。
https://www.reddit.com/r/googlecloud/comments/1tcqxli/google_users_fight_for_refunds_as_unauthorized/

Hacker News「Google API keys weren't secrets, but then Gemini changed the rules」
Truffle Security調査に対する開発者・セキュリティ関係者の議論、支出上限や設計思想への批判を参照。
https://news.ycombinator.com/item?id=47156925