Gemini APIキー漏洩で722件の不正利用。Googleへの対応までAIに委ねて分かったこと

2026年7月22日、私が管理するGoogle Gemini APIで、身に覚えのない利用が見つかりました。

発生時間は17時33分から18時03分までの約30分間。リクエストは合計722件で、成功616件、失敗106件。

内容は、私の業務とは関係のない画像編集、商品画像、ロールプレイ、成人向け画像、動画、音楽の生成。

いや、正直に言うと…ぞっとしました。

今回、私は原因調査だけでなく、証拠の整理、Googleへ送る文面の作成、そしてGoogle Cloud Billing Supportとのやり取りまでAIに委ねた。そこまでが今回の実験でした。

でも、何も考えずに丸投げしたわけではありません。

秘密情報をどこまで扱うか。外部へ何を送るか。設定や課金に関わる変更を実行するか。

その境界と最終承認は、ずっと私が握ったまま。ここは譲れない線でした。

Gemini APIキー漏洩で30分722件。「不正利用」と判断するまで

異常な数字を見ても、すぐ不正利用と決めつけることはできません。

うん、自分や自分のAIが動かした処理の可能性もある。まずはそこからです。

そこでAIに、同じ時間帯のCockpitやClaudeのタスク履歴、ローカルで実行した画像生成、Google側の分単位メトリクス、AI Studioのログ内容を照合してもらう。

確認できた事実は、次の5つです。

• 発生時間に対応する正規のタスクがない
• 同日に行った既知の画像生成はOpenAIの画像モデルで、Geminiではない
• 生成内容が私の事業や作業内容と一致しない
• 対象キーを隔離した後にリクエストが止まった
• Google側の利用メトリクスとAI Studioのログが、対象の認証情報に対応していた

一つだけなら偶然かもしれません。

でも、時刻、内容、正規タスク、停止タイミングが重なる——ここまでそろって、722件を「身に覚えのない不正利用」と判断しました。

Gemini APIキー漏洩で最初に必要だったのは、犯人探しではない。

自分の利用と第三者の利用を、一次証拠で分けることでした。

最も疑わしかったのは、ブラウザへ秘密を渡す構成だった

調査で最も確度が高いと判断した露出経路は、APIキーを示す環境変数がGitで追跡される.envに入り、クライアント側アプリがブラウザからGemini APIや画像生成APIを直接呼ぶ構成でした。

この構成では、ビルド後のJavaScriptやブラウザから送るリクエストに、認証情報が現れる可能性もある。

いやー、サーバーの内側に置くべき鍵を、玄関先まで持ち出してしまうようなものです。

一方で、リポジトリ自体は非公開。どの公開・共有経路から第三者へ渡ったのかまでは、立証できていません。

だから私は「原因はこれだ」と断定せず、「一次証拠から見て最も確度の高い露出経路」として扱ったんです。

ここ、地味だけど大事なんですよね……。

セキュリティ調査では、強い言葉よりも、確認できた事実と未確認の部分を分けるほうが、その後の交渉でも役に立ちます。

AIに任せたのは、調査だけではない

ぶっちゃけ、今回AIに任せた範囲はかなり広いです。

1. ローカルの設定、タスク履歴、ログ、Google側の記録を横断して時系列を作る
2. 不正利用と判断できる根拠と、まだ断定できない点を分ける
3. APIキー値や個人情報を伏せたGoogle向け報告文を英語で作る
4. 私向けの日本語訳を付け、送信前に内容を確認できるようにする
5. 私の承認後、Google Cloud Billing Supportへ報告する
6. 定型案内で終わらせず、人間の担当者へ事実を提示して課金調整の審査まで進める

つまり、「AIに調査レポートを書かせた」で終わりではありません。

外部窓口との実務対応まで——そこまで委ねた。

でね、APIキーの値、認証情報の内部識別子、再発行した認証情報、メールアドレス、支払情報は、提出文にもこの記事にも入れていません。

追加のキー失効・再発行、クラウド設定、予算、ログ保存設定の変更も、AIの判断だけでは行わせない。ここも人間の仕事です。

AIへ対応を任せても、主権まで渡す必要はない。

Googleには「原則有効な請求」と言われた。それでも審査まで進めた

Google Cloud Billing Supportでは、最初から望んだ答えが返ってきたわけではありません。

まあ、当然といえば当然です。

Google側の基本説明は、認証情報の管理は利用者との共有責任であり、発生した利用は原則として有効な請求になる、というもの。

そこでAIは、感情的に押し返すのではなく、発生時間、件数、正規タスクとの不一致、キー隔離後に停止した事実、Google側のメトリクスとの一致を順に提示しました。

人間の課金担当者へ引き継がれた後も、「何を確認できていて、何がまだ分からないか」を崩さず伝え続ける。最後まで、この軸は変えませんでした。

そして担当者は、課金調整リクエストを内部チームへ連携すると明言。

案内された回答目安は3〜5営業日。結果は登録メールへ通知される予定ですが、現時点では審査中です。

12,993円は、722件分の確定額ではない

Googleの請求レポートでは、2026年7月22日のGemini API費用が12,993円、同日の全サービス合計が13,033円でした。

ただし、これは日単位の数字。30分間に発生した722件だけの金額を切り出したものではありません。

担当者は、Gemini APIの請求が7月6日から22日に発生していたことも確認済みです。

したがって、12,993円は7月22日のGemini API費用の上限であり、不正利用722件分の確定額ではない。

課金調整が認められるか。認められるとしていくらになるか。そこも、まだ未確定です。

しかもね、数字を大きく見せるために混同しない。これも、AIへ課した大切なルールでした。

AIに委ねても、決定権は渡さない

セキュリティ事故が起きたとき、人間の負担は調査だけではありません。

いや、むしろ調査の後が長い。

大量のログを読み、時間をそろえ、証拠を並べ、秘密情報を除き、外国語の窓口で同じ説明を繰り返す。定型回答から人間の担当者へ進み、結果が確定するまで状態を管理する。ひとつひとつは地味ですが、全部を本人が抱えると重いです。

今回は、その運用負荷をAIに引き取ってもらうことができた。

その代わり、AIに任せる前に境界を決めました。

• 秘密値は画面、報告書、チャットに出さない
• 確認できた事実と推定を分ける
• 外部送信は本文を確認してから承認する
• 失効、再発行、削除、設定変更、課金操作は勝手に行わせない
• 送信後も、受付、金額、未確定事項を一次証拠で読み戻す

AIへの委譲は、判断を捨てることではありません。

自分が握るべき判断を明確にしたうえで、それ以外の実務を引き取ってもらう。その役割分担です。

私がAIへ任せたのは、文章作成だけではありませんでした。

事故の発見から証拠整理、Googleへの説明、課金調整の審査依頼まで。対応の流れそのもの。

そして私が最後まで手放さなかったのは、「何を事実とするか」「何を外へ出すか」「どの変更を許可するか」という決定権でした。

これが、AIと一緒に現実の問題へ対応するときの、私なりの委ね方。

悪いことこそ宝物。そう言えるのは、事故を美化するからではありません。

失敗を隠さず、次の判断基準へ変えるから。

この記事が、同じような場面で「全部、自分で抱えなくていい」と思える材料になればうれしいです。

※本記事は2026年8月28日時点の確認済み事実がベース。秘密情報や個人を特定できる情報は掲載していません。

よくある質問