13時間で900万円:生成AI時代に続出するAPIキー流出事件と対策【LLMJacking】

生成AIのAPIキーが流出して短時間で高額請求される事件が世界中で続出しています。たとえば、13時間で900万円の請求、48時間で1200万円の請求など。

これは、生成AI時代の新しい攻撃手法【LLMjacking】の被害です。

今この瞬間にも、被害は起こっています。過去にAPIキーを作って放置した方、バイブコーディングを始めた方が主要ターゲットです。

本記事では攻撃の手法・対策をお伝えします。

LLMjackingの例
LLMjacking ━ 産業化された犯罪
1. キーの取得にもAIが使われている
事件には2つのパターンがある
1. パターン①:バイブコーディングで雑にキーを置いてしまう
2. パターン②:過去のキーが Gemini 登場で勝手に書き換わった
実演:ブラウザのキーで本物の Gemini が動く
1. 準備:AI Studio でキーを取得
2. WSL のターミナルで叩く
Google は対策してくれるか
今すぐできる対策
まとめ

LLMjackingの例

まずは実際に起きている事件を並べてみます。

13時間で約900万円(Firebase + Gemini構成、ブラウザにキー直置き)
48時間で約1,200万円($82,314、メキシコの3人スタートアップ。通常月$180が46,000%増)
数時間で約230万円($15,400、ソロ開発者。課金アラートを見て数分以内にキー取り消すも遅延で課金累積、スタートアップ破綻寸前)
約1,900万円($128,000、日本企業。ファイアウォールでIP制限していたのに突破された)
約830万円($55,444、CS学生がGitHubにコミット。ボットが数分で発見・悪用)
約33万円($2,200、2026年4月。Viteビルドのフロントから流出)
約65万円($4,368、2026年4月末。2022年に作ったキーが原因)

これらは個別の事件です。背景にある規模感はもっと大きいものです。

Truffle Security の調査では、2025年11月に2,863本の有効なAPIキーがネット上に放置されていることが分かりました。

Google API Keys Weren't Secrets. But then Gemini Changed the Rules. ◆ Truffle Security Co.

Google spent over a decade telling developers that Google API keys (like those used in Maps, Firebase, etc.) are not secrets. But that's no longer true.

被害者には大手金融機関、セキュリティ企業、グローバル人材会社、そして Google 自身も含まれていました。
CloudSEK の Android アプリ調査では、上位10,000のアプリのうち22本のアプリのキーがネット上に放置されている状態でした。アプリの合計ダウンロード数は5億。Google Pay for Business、など、有名なアプリも含まれています。

Hardcoded Google API Keys in Top Android Apps Now Expose Gemini AI | CloudSEK

CloudSEK's BeVigil has identified 32 hardcoded Google API keys across 22 popular Android applications that inadvertently grant unauthorized access to Google's G...

GitGuardian の State of Secrets Sprawl Report では、2025年に120万件のAIサービスの秘密情報が GitHub 上で漏洩したと報告されています。APIキーも含まれます。前年比で81%の増加です。

さらに同調査では、Claude Code で書かれたコードはシークレット漏洩率が通常の約2倍と報告されています。Claude Code が問題というより、生成AIが書いたコード(バイブコーディング)が問題だと考えられます。

29 million leaked secrets in 2025: Why AI agents credentials are out of control - Help Net Security

AI agents rely on credentials, but poor governance causes credential leaks, exposing systems as integrations and AI-driven development scale.

LLMjacking ━ 産業化された犯罪

これらの事件は、単なる個人の不注意ではありません。LLMjacking(エルエルエム・ジャッキング)という名前が付いた、産業化された犯罪カテゴリです。

LLMjacking は、クラウドセキュリティ企業 Sysdig が2024年5月に最初に文書化した攻撃カテゴリです。

盗まれたAPIキーは「裏市場で取引される商品」になっています。攻撃者はキーでAIを大量に使い倒します。さらに、他の犯罪者にアクセスを再販する。

被害者は何も知らずに請求書だけを受け取る、という構造です。

キーの取得にもAIが使われている

さらに怖いことに、キーを抜き取る際にも生成AIが使われています。たとえば次のような形でキーが取得されています。

①キーがそのまま入ったコードを GitHub 上に公開
↓
②数分〜数時間以内に AI ボットがキーを発見・収集
↓
③攻撃者がそのキーで AI を叩き始める

バイブコーディングにより、コードを見ずにGitHub上にプッシュしてしまうケースが増えています。攻撃者にしてみれば、GitHubは格好のキー採取場所といえるでしょう。

AI ボットが GitHub と Web サイトを24時間自動スキャンしている、と考えたほうが良いかもしれません。

8,000+ ChatGPT API keys exposed across GitHub & production sites

8,000+ ChatGPT API keys exposed across GitHub and live sites reveal a growing “vibe coding” risk. Learn how leaked AI credentials are exploited, the financial i...

事件には2つのパターンがある

APIキー流出事件を整理すると、原因は大きく2つに分けられます。

パターン①:バイブコーディングで雑にキーを置いてしまう

これは、多くの個人開発者・スタートアップが今直面しているパターンです。

Google AI Studio でキーが1分で取れる
生成AIにアプリをつくってもらう
生成AIは「動く最短コード」を出す
そのコードはキーをフロントエンド(ブラウザ側のJavaScript)に直書きしている
開発者が気づかずにそのままデプロイ
AIボットが数分〜数日で発見し、悪用が始まる

「便利すぎる」が「事故が起きやすい」を生んでいます。

パターン②:過去のキーが Gemini 登場で勝手に書き換わった

こちらは Google 側の設計問題です。Truffle Security はこれを Retroactive Privilege Expansion(遡及的な権限拡大) と命名しました。

2010年代から、Google Maps や Firebase の APIキーは「公開してOK」と公式が案内していました。当時はそれで問題ありませんでした。

ところが2023年12月に Gemini API が登場しました。同じ AIza... 形式のキーが、Gemini の認証情報としても使われる仕様になりました。

プロジェクトで Generative Language API を有効化した瞬間、既存の公開済みキー全部が、警告も確認ダイアログもメール通知もなく、Gemini エンドポイントへのアクセス権を獲得するようになりました。

つまり、開発者（キー発行者）は何もしていないのに、過去に作ったキーがある日突然「Gemini を直接呼び出せる凶器」に変わっていた、という状況です。このキーが盗まれ、被害がでています。

Google API Keys Weren't Secrets. But then Gemini Changed the Rules. ◆ Truffle Security Co.

Google spent over a decade telling developers that Google API keys (like those used in Maps, Firebase, etc.) are not secrets. But that's no longer true.

実演:ブラウザのキーで本物の Gemini が動く

事件の構造を理解するために、自分のキーで実際に試してみました。

※この検証は自分のキーを自分の環境で叩くものです。他人のキーをたたくのは違法です。

準備:AI Studio でキーを取得

Google AI Studio を開いて「Get API key」をクリックすると、すぐにAPIキーが発行されます。

Google Cloud Console の複雑な設定を経由せずに取れる、個人開発者向けの最速ルートです。

WSL のターミナルで叩く

取得したキーを WSL の Ubuntu ターミナルで環境変数に設定します。

export GEMINI_KEY="AIza..."

1	export GEMINI_KEY="AIza..."

そして curl で Gemini API を直接叩きます。

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent?key=$GEMINI_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"contents":[{"parts":[{"text":"こんにちは"}]}]}'

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent?key=$GEMINI_KEY" \

-H 'Content-Type: application/json' \

-d '{"contents":[{"parts":[{"text":"こんにちは"}]}]}'

レスポンスとして、Gemini からの日本語応答が JSON で返ってきます。

"candidates": [
  {
    "content": {
      "parts": [
        {
          "text": "こんにちは!\n何かお手伝いできることはありますか?"
        }
      ],
      "role": "model"
    },
    "finishReason": "STOP",
    "index": 0
  }
]

"candidates": [

{

"content": {

"parts": [

{

"text": "こんにちは!\n何かお手伝いできることはありますか?"

}

"role": "model"

"finishReason": "STOP",

"index": 0

}

]

たった2行のコマンドで、本物の Gemini が動きます。

攻撃者がやっていることも、構造的にはこれと同じです。違いは「自分のキーか、他人のキーか」だけ。

攻撃者はこれをループで何百万回も叩きます。精度をあげるために高単価モデルを選びます。さらに、複数のクラウドサーバーから並列で叩きます。

これが「13時間で900万円」のスピード感の正体です。

Google は対策してくれるか

Googleキーの問題については、Truffle Security の報告を受けて、Google は段階的に対策を入れています。

実際に2026年5月時点で、Cloud Console で新規キーを作成しようとすると「APIを選択する必要があります」のエラーが出ます。制限なしのキーは作成できなくなっています。

さらに、過去に作った制限なしのキーも、編集画面を開いて保存しようとすると同じエラーが出ます。制限なしのまま保存できない仕様になっていました。（こちらは、私の方で実行した結果です。残念ながらスクショを取り損ねました）

「事故が起きにくくする」改善はしてくれていますが、ただ、「事故後の被害者を救済する仕組み」は依然として弱い、というのが現状です。完全に賠償してくれるかどうか、保証はありません。そのため、自己防衛は必須です。

気になったら次の項目を参考に、今すぐチェックしてください。

今すぐできる対策

ではここから対策です。

① フロントエンドにキーを置かない

これが最も重要な原則です。AI APIキーは必ずサーバーサイドで扱います。

具体的には、ブラウザ → 自分のサーバー → Gemini API、という構造を作ります。

バイブコーディングで生成AIにコードを書いてもらった場合は、必ずキーがどこに置かれているか確認してください。

分からない時は生成AIに「フロント側に置いていないかチェックして」と言えばOKです。

フロントエンドのみのアプリは危険

React、Vue、純HTMLなど、純粋なフロントエンドアプリではキーを安全に置く場所はありません。ブラウザは何を置いても見られる場所です。

Next.js の API Routes、Supabase Edge Functions、Laravel など、何らかのバックエンドを用意してください。

NEXT_PUBLIC_*、VITE_*、REACT_APP_* プレフィックスの環境変数にキーが入っていたとしても、危険です。「環境変数を使っているように見えるが、実はビルド時にブラウザバンドルに展開される」ためです。

② 過去のキーを点検する

Google Cloud Console を開いて、すべてのプロジェクトを順番に確認します。

左メニュー「APIとサービス」→「有効なAPIとサービス」で「Generative Language API」が有効化されているか確認
有効化されているプロジェクトについて、「APIとサービス」→「認証情報」を開く
各APIキーの設定を見て、「制限なし」になっているキー、または「Generative Language API」を許可しているキーをチェック
そのキーがフロントエンドで使われている可能性があれば、即削除またはローテーション
使い道が思い出せないキーは削除する

Google AI Studio で過去にキーを作った場合も、同様に一覧を確認して、不要なものは削除します。

③ 残すキーには制限をかける

削除できないキー(現役で使っているもの)には、最低限の制限をかけます。

API 制限:そのキーで使う API だけを許可リストに追加。他のAPIは弾く
HTTPリファラ制限:特定ドメインからのリクエストだけ受け付ける(ただし curl で偽装可能なので完全な保護ではない)
IP制限:特定のサーバーIPだけ許可(サーバーサイドで使う場合)
予算アラート:設定はするが、これは通知のみで使用は止まらない、最後の砦

「制限をかけたから安全」ではなく、「キーを置く場所そのものを安全にする」が本質的な対策です。

まとめ

2026年は、フロントエンド側のAPIキーが「盗んで使える商品」になった年です。

盗まれたら数時間で数百万円が消える。LLMjacking という産業化された犯罪市場で取引される。攻撃者も AI を使って自動化している。

これは特定の人だけの問題ではなく、生成AIを使ってアプリを作るすべての人に関わる話です。バイブコーディングが普及するほど、雑にキーを置いてしまう事故は増えます。

守る方法はシンプルです。

フロントエンドにキーを置かない
過去のキーを点検する
残すキーには制限をかける

この3つだけです。文字だけでは分かりにくい点あると思います。動画版もみてくださいね。