APIキー漏洩でAI利用料が累計100万ドル｜LLMjackingの手口と対策
この記事の要点
- 盗んだAPIキーやクラウドの認証情報で他社のAIを勝手に使い、料金を被害組織に払わせる「LLMjacking」が広がっています。Google（Mandiant）は、1日で10万ドル超、累計で100万ドルに達した不正請求を報告しました。
- 主な入口は、漏れたり盗まれたりしたクラウドの認証情報（GitHubのトークンを含む）です。侵害時点でAIサービスを使っていなかった組織でも、攻撃者がAIの機能を有効にして使い込んだ事例があります。
- Wizの集計では、10月以降に少なくとも12社のAI開発基盤が侵害を公表しました。Wizが追跡した鍵では、盗まれてから30分以内に試され、1本で30時間に約80万回呼び出されました。
- 使える地域を絞った鍵でも、13時間で100万回超の呼び出しが成功しました。鍵の制限だけでは請求は止まらず、請求上限・アラートと素早い失効を組み合わせる必要があります。
- 今週中に、社内のAIの鍵とクラウドの認証情報がどこに置かれているかを洗い出し、外部サービスに預けた鍵の作り直しと、各社の利用上限・アラートの設定を確認してください。
生成AIのAPIキー（プログラムからAIを呼び出すための鍵）を盗み、他人の契約でAIを使い倒す攻撃が広がっています。「LLMjacking（LLMジャッキング）」と呼ばれるこの攻撃について、Google の脅威インテリジェンス部門と Mandiant は2026年11月3日、1日で10万ドルを超える不正請求や、累計100万ドルに達した事例を報告しました[1]。
10月には、開発者が鍵を預けるクラウドの開発基盤が相次いで侵害され、保存されていた環境変数（鍵などの設定値）が盗まれました。Wiz によれば少なくとも12社が事案を公表しました。手口が公表された事案では、いずれも「AIを使うための鍵」が狙われています[2]。社内ツールや業務の自動化でAIのAPIを使う会社にとって、鍵の漏洩は情報漏洩であると同時に、高額請求に直結する問題になりました。
この記事では、何が起きたのか、鍵がどこから盗まれ、どう換金されるのか、請求の上限はどこまで守ってくれるのか、そして今週確認することを整理します。情報は2026年11月5日時点のものです。
何が起きたのか？
Mandiant は2026年、企業のAI利用権が乗っ取られる LLMjacking の事案に複数対応しました。被害は北米・南米・アジア太平洋の金融、小売、技術、運輸の各業種に及びます[1]。同時期に、AIアプリの開発・運用に使われるクラウド基盤の侵害が相次ぎ、利用者が預けていたAIの鍵が実際に悪用されました[2][3]。
10月6日〜17日
AI開発基盤で侵害の公表が続く
Fireworks AI、Andromeda、Zeabur、Lightning AI、OpenCode などが事案を公表[2]。
10月21日
Railway が環境変数の流出を公表
暗号化された環境変数に第三者がアクセスし、一部は復号された可能性。AI推論の事業者を狙う一連の攻撃の一部と見ている[4]。
10月30日
Northflank が全利用者に鍵の作り直しを要請
「すべての環境変数が復号されたと想定する」とし、同日中に利用者から AI の鍵の不正利用が報告された[3]。Wiz が一連の侵害をまとめた報告を公開[2]。
11月1日
Trigger.dev も環境変数への不正アクセスを公表
一部の組織の環境変数に攻撃者がアクセスした[5]。
11月3日
Google が LLMjacking の手口と対策を公開
国内企業が LLMjacking の被害を公表した例は、11月5日時点で編集部は確認できていません。ただし、Mandiant の対応事案にはアジア太平洋の組織も含まれます[1]。侵害された開発基盤も海外の事業者ですが、日本の開発会社やスタートアップが使っていてもおかしくないサービスです。
LLMjacking とはどんな攻撃か？
LLMjacking は、他人のAI利用権を乗っ取り、その料金を持ち主に払わせる攻撃です。Google は、侵入を担う攻撃者と、盗んだ利用権を転売する「LLMミキサー」と呼ばれる中継サービスの運営者とで、分業が進んでいると指摘しています[1]。
暗号資産の採掘にサーバーを無断で使う攻撃（クリプトジャッキング）は、計算資源を少しずつ消費します。これに対し LLMjacking は、数時間で請求を急増させることがあります[1]。AIの料金は使った量に応じて増えるため、盗まれた鍵が大勢に転売されると、持ち主の請求額は短時間で膨らみます。
別の攻撃者は、盗んだ他社のAPIキーを使って8時間足らずで50万回を超えるLLMのAPI呼び出しを行い、トークン中継サービス jet-night.com を動かしていた。Jet Night は、100万ドル近いトークン費用を被害組織に負わせた。
Another threat actor that executed more than 500,000 LLM API calls in less than eight hours leveraged stolen third-party API keys to power the token routing service jet-night.com. Jet Night passed nearly one million dollars in token costs to the victim organization.
Jet Night は、最上位級のモデルも使えるとうたう使い放題のプランを、月約60ドルで売っていました。Google は、通常なら月100〜250ドルかかる水準より大幅に安く、盗んだ鍵なしでは採算が合わないとみています[1]。買う側にとっては「格安のAI」でも、その料金を払っているのは鍵を盗まれた企業です。
攻撃者は自分で使うだけでなく、被害組織のクラウドで追加の鍵を作り、AIサービスを有効にし、従量課金の契約に申し込んで上位モデルを大量に呼び出しました[1]。回数の制限を避けるため、短時間だけ使うサービスアカウントを作っては消す手口や、請求画面を見て被害額を確かめる行動も確認されています[1]。
鍵はどこから盗まれているのか？
Google によれば、最も多い入口はAIの鍵そのものではなく、漏れたり盗まれたりしたクラウドの認証情報です。具体的には、IAMの認証情報、サービスアカウントの鍵、GitHub の個人アクセストークン、ログイン中のセッショントークンが挙げられています[1]。
| 入口 | 報告された例 | 社内で起こりうる場所 |
|---|---|---|
| クラウドの認証情報 | 設定ミスのあるサービスアカウントの鍵、盗まれたIAM認証情報、GitHub のトークン[1] | Webサイトや社内システムを載せている AWS・Google Cloud・Azure の管理用の鍵 |
| 公開されたAIの鍵 | 公開リポジトリから企業のAIの鍵を収集[1] | GitHub に上げたコードや設定ファイル、社外に共有した資料 |
| 鍵を預けた外部サービス | AI開発基盤の侵害で、保存された環境変数が盗まれた[2][3][4] | アプリの実行基盤、ワークフロー自動化、AIアプリ作成ツールなどに登録した鍵 |
| 公開されたAIサーバー | インターネットから見える Ollama に、自分のモデルを登録しようとする[1] | 社内で試しに立てたローカルLLMのサーバー |
| AIの中継ソフトの脆弱性 | LiteLLM のゲートウェイで、一般の鍵を管理者の鍵に昇格[1] | 複数のAIを束ねるために置いた中継サーバー |
公開リポジトリから鍵を集めた攻撃者は、出力を1トークンに絞った最小限のリクエスト（max_tokens=1）で、鍵が使えるかを確かめていました。呼び出しが少量なので、量の異常を見張る監視には引っかかりにくい手口です[1]。
ローカルでAIを動かす Ollama は、既定では自分のパソコン（127.0.0.1）からの接続しか受け付けません。設定の OLLAMA_HOST で、ほかの機器から接続できるように変えられます[7]。ローカルの API には認証がないため[8]、社内共有のつもりで外から見える状態にすると、誰でも使えるサーバーになります。
盗まれた鍵はどう使われるのか？
Wiz は、侵害されたAI開発基盤から流出したとみられる企業の鍵2本について、その後の使われ方を追跡しました。どちらも Amazon Bedrock（AWS のAIサービス）の鍵です。1本目は、基盤の侵害から30分以内に、複数の組織の鍵をまとめて試す1分間の確認作業で1回だけ呼び出されました[2]。
その後の数日は、1日14〜120回の少ない呼び出しで、鍵がまだ使えるかを確かめる程度でした。4日後に多数の住所から各社のモデルを1回ずつ試す呼び出しがあり、その数時間後に大量の利用が始まりました。30時間後に対処されるまでに約80万回呼び出され、約9割が成功しました[2]。
Wiz は、この2件だけで定価換算10万ドルを超える利用があった可能性があるとしています[2]。呼び出しの中身は、転売されたコーディング用AIエージェントの通信に似ていました。鍵を確かめた住所の一部は、格安でAIを売る転売サイトと結び付いていました[2]。
AIを使っていない会社も狙われるのか？
狙われます。Mandiant が対応した複数の事案では、侵害された時点でAIサービスは有効になっていませんでした。攻撃者が盗んだ鍵でAIのAPIを有効にし、数分から数時間で巨額の請求を発生させています[1]。Webサイトや社内システムのためにクラウドを契約しているだけの会社も、管理用の鍵が漏れれば同じ被害に遭います。
AIを使っている会社では、鍵の置き場所が知らないうちに増えています。社内のチャットボット、業務の自動化ツール、AIアプリの作成ツール、開発会社に任せたシステムなど、鍵を登録した場所の数だけ漏洩の経路があります。10月の侵害はまさに、こうした「鍵を預けた外部サービス」から起きました[2]。
| 置き場所 | よくある例 | 見落としやすい点 |
|---|---|---|
| 外部の実行基盤・自動化サービス | アプリの実行基盤、ワークフロー自動化、AIアプリ作成ツールの設定画面 | 侵害されると、登録したすべての鍵が一度に漏れる |
| コードと設定ファイル | .env ファイル、GitHub のリポジトリ、AIエージェントの設定 | 消しても履歴に残る。公開リポジトリは自動で収集される[1] |
| 社員のパソコン | AIコーディングツールや試作スクリプトに直接書いた鍵 | 退職・異動後も有効なまま残りやすい |
| 委託先 | 開発会社や制作会社が作った社内ツール | 誰の名義の鍵で、請求がどこに来るかを把握していない |
請求の上限はどこまで守ってくれるのか？
上限に達したときに利用を「止める」か「知らせるだけ」かは、提供元によって違います。編集部が2026年11月5日に各社の公式ドキュメントを確認したところ、OpenAI・Anthropic・Google には利用を止める仕組みがありました。一方、AWS と Azure の予算機能は、標準では通知が中心です[10][12][14][16][19]。
| 提供元 | 上限に達すると | 注意点 |
|---|---|---|
| OpenAI（API） | 組織・プロジェクトの上限で「Enforce a hard limit」をオンにすると、エラーを返して止まる[10] | 支出アラートだけでは止まらない。停止は即時ではなく、少し超えることがある[10]。前払いの自動チャージは設定時に既定でオン[11] |
| Anthropic（Claude API） | 利用段階ごとの月の上限で、翌月1日まで止まる。組織やワークスペースに自分で上限も設定できる[12] | 既定のワークスペース（Default Workspace）には上限を設定できない。個別契約（Custom）の段階には月の上限がない[12] |
| Google（Gemini API・Vertex AI） | 「spend cap budget」（1プロジェクト・1サービスごとに設定）で、対象サービスへの新しいリクエストを止める[14]。Gemini API にはアカウントの段階ごとの上限と、AI Studio のプロジェクト単位の上限（試験提供）もある[15] | 通常の予算は通知だけ。上限の発動は即時ではなく、処理中のリクエストは完了し、超えた分も請求される[14]。プロジェクト単位の上限は約10分遅れ、バッチ処理やエージェントは上限を超えることがある[15] |
| AWS（Amazon Bedrock） | Bedrock 単体の金額上限は、公式ドキュメントでは見つからなかった。予算のしきい値を超えたら権限の拒否を自動で当てる「予算アクション」は使える[16] | 予算の情報の更新は1日最大3回[17]。Marketplace の権限があれば、多くのモデルは最初から使える状態[18] |
| Azure（Azure OpenAI） | 予算は通知だけで、利用は止まらない[19] | 予算の評価は24時間ごと[19] |
Wiz が追跡した2本目の鍵では、13時間で100万回を超える呼び出しが成功しました[2]。予算の情報が1日に最大3回しか更新されない AWS や、24時間ごとに評価する Azure では、通知が届く前に被害が広がるおそれがあります[17][19]。こうした環境では、使わないモデルの呼び出しを権限で最初から拒否しておくことが重要です。AWS は、Bedrock のモデルを止めるには bedrock:InvokeModel を拒否するよう案内しており、Marketplace の購読を拒否するだけでは最初の呼び出しを止められないとしています[18]。
今すぐやることは何か？
最初にやるのは、鍵の置き場所を知ることです。どこにどの鍵があるかが分からなければ、漏れたときに作り直すこともできません。Northflank は侵害を受けて、AIの鍵、クラウドの認証情報、決済サービスの鍵、秘密鍵、データベースの認証情報の順に作り直すよう利用者に求めています[3]。
今週中に確認すること
- 社内で使っているAIのAPIキーとクラウドの管理用の鍵を、置き場所（外部サービス・コード・社員のパソコン・委託先）ごとに一覧にする
- Railway・Northflank・Trigger.dev など侵害を公表したサービスに鍵を預けていた場合は、発行元で古い鍵を無効にしてから新しい鍵に替える
- AIの各社の管理画面で、ここ1か月の利用量と請求に見覚えのない増加がないかを確認する
- 各社の利用上限を設定する（OpenAI は「Enforce a hard limit」をオン、Google Cloud は spend cap budget、AWS・Azure は予算アラートに加えて使わないモデルを権限で拒否）
- 予算アラートの通知先が、個人ではなくチームの連絡先になっているかを確かめる
- 使っていないAIサービスやモデルへのアクセスを、クラウドの権限設定で止める
- GitHub の公開リポジトリと共有資料に、鍵が書かれていないかを確認する
- 社内で Ollama などのAIサーバーを立てている場合は、外部から接続できる設定になっていないかを確かめる
鍵を作り直すときは、新しい鍵を作るだけでなく、発行元で古い鍵を無効にしてください。Northflank は、発行元で既存の鍵を失効させ、新しい鍵を作ってから、預けている設定を置き換えるよう案内しています[3]。見覚えのない利用や請求があった場合は、AIの提供元に直接連絡するよう勧めています[3]。
中長期で見直すことは何か？
Google は、クラウドの権限管理と、使っているソフトウェアの安全確保を最優先に挙げています[1]。鍵を一元管理して定期的に作り直すこと、役割に必要な権限だけを与えること、AIサービスへのアクセスも明示的に必要な人以外は拒否することが基本です[1]。
- 鍵の一元管理と自動の作り直し：漏れた鍵が使える期間を短くする[1]
- 鍵の用途を分ける：開発用と本番用、安いモデル用と高いモデル用で鍵を分け、1本が漏れても上位モデルを使えないようにする[1]
- コードの秘密情報スキャン：GitHub などに鍵が入ったら、すぐ見つけて消す[1]
- フィッシングに強い多要素認証：クラウドの管理画面や開発基盤のログインに使う[1]
- ログを有効にして見る：AIサービスの有効化、少量の確認呼び出し（max_tokens=1）、ログ設定の変更を見張る[1]
- AIの中継ソフトも更新の対象にする：LiteLLM のようなゲートウェイの脆弱性も、ほかのサーバーと同じく早く直す[1]
Google Cloud の AI 基盤（Gemini Enterprise Agent Platform、旧 Vertex AI）では、AIの呼び出しは「データアクセス」の監査ログに記録されますが、このログは量と費用の都合で既定では無効です[1]。有効にしていなければ、被害に遭っても何が呼ばれたかを後から追えません。Google は、ログ設定の確認・変更・無効化の試みも監視するよう勧めています[1]。
AIの利用ルールも見直しが必要です。ルールは「どの情報を入れてよいか」に目が向きがちです。今回の攻撃は、入力した情報ではなく、AIを使う権利そのものが盗まれる問題です。社内ルールに、鍵を誰が発行し、どこに保存し、いつ作り直すかを加えておく必要があります。
とくに、社員や委託先が個人の判断でAIの鍵を発行し、外部サービスに登録する運用は見直すべきです。鍵の発行を申請制にし、請求先と上限を決めてから渡せば、漏れたときの被害額と連絡先が最初から決まります。AIの利用ルールの全体像は、AIセキュリティとはでも整理しています。
まとめ
LLMjacking は、盗んだ鍵で他人のAIを使い、料金を持ち主に払わせる攻撃です。Google は1日10万ドル超、累計100万ドルの不正請求を報告し、10月以降、AI開発基盤12社が侵害を公表しました[1][2]。Wiz が追跡した2本の鍵は、盗まれてから30分以内に試され、4〜7日後に大量に使われました[2]。
AIを使っていない会社でも、クラウドの鍵が漏れればAIの機能を有効にされて被害に遭います[1]。今週中に、鍵の置き場所の一覧、侵害を公表したサービスに預けた鍵の作り直し、利用上限とアラートの設定を確認してください。よくある質問はFAQにもまとめています。
よくある質問
LLMjacking とは何ですか？
盗んだAPIキーやクラウドの認証情報を使って、他人の契約で生成AIを勝手に使い、その料金を被害組織に払わせる攻撃です。盗まれた利用権は格安のAIサービスとして転売されることもあります。Google（Mandiant）は、1日で10万ドルを超える不正請求や、累計100万ドルに達した事例を報告しています。
AIのAPIを使っていない会社にも関係がありますか？
関係があります。Mandiant が対応した複数の事案では、侵害時点でAIサービスが有効になっていませんでした。攻撃者はクラウドの管理用の鍵を盗み、AIのサービスを有効にしてから大量に使っています。Webサイトなどのためにクラウドを契約しているだけでも、管理用の鍵の管理と請求アラートの設定が必要です。
APIキーが漏洩したかもしれないときは、まず何をすればよいですか？
発行元の管理画面で、その鍵を無効にしてください。新しい鍵を作るだけでは、古い鍵は使えたままです。そのうえで新しい鍵を作って設定を置き換え、利用量と請求に見覚えのない増加がないかを確認します。不審な利用や請求があれば、AIの提供元に直接連絡してください。
Railway や Northflank を使っていました。何をすればよいですか？
両社とも、預けていた環境変数（鍵などの設定値）をすべて作り直すよう求めています。Northflank は、すべての環境変数が復号されたと想定し、AIの鍵、クラウドの認証情報、決済サービスの鍵、秘密鍵、データベースの認証情報の順に作り直すよう案内しています。不審な動きが見えていなくても対応してください。
請求の上限を設定しておけば安心ですか？
上限やアラートは被害を小さくするために欠かせませんが、それだけで安心とは言えません。サービスによって、上限に達すると利用が止まるものと、通知が届くだけのものがあります。通知だけの場合は、気づいて鍵を無効にするまで請求が続きます。設定の効き方を確認し、通知を受けたら誰が鍵を止めるかまで決めておいてください。
出典・参考資料
- 調査レポートThe Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources
- 調査レポート“Black October” for AI Developer Platforms
- 公式発表Security incident - Incident details - Northflank - Status
- 公式発表Security Disclosure: Wednesday October 21st
- 公式発表Security Disclosure: Sunday November 1st
- 記事Google: LLMjacking attacks rack up $1 million in cloud AI charges
- 公式発表FAQ - Ollama
- 公式発表Authentication - Ollama
- 注意喚起NVD - CVE-2026-40217
- 公式発表Spend limits | OpenAI API
- 公式発表Setting up and managing prepaid API billing | OpenAI Help Center
- 公式発表Rate limits - Claude Platform Docs
- 公式発表API key best practices: keep your keys safe and secure | Claude Help Center
- 公式発表Manage spend cap budgets | Cloud Billing | Google Cloud Documentation
- 公式発表Billing - Gemini API | Google AI Studio
- 公式発表Configuring budget actions - AWS Cost Management
- 公式発表Managing your costs with AWS Budgets - AWS Cost Management
- 公式発表Request access to models - Amazon Bedrock
- 公式発表Tutorial - Create and manage budgets - Microsoft Cost Management | Microsoft Learn
- 公式発表Supported secret scanning patterns - GitHub Docs
- 公式発表Using Gemini API keys - Gemini API | Google AI Studio
本記事の事実関係は、2026.11.05 時点で上記の出典をすべて再確認しています。 独立のファクトチェックで全21出典を開き直して照合。指摘（修正3件・要注記14件）を反映済み。各社の請求上限は2026年11月5日時点の公式ドキュメントで確認。
AIセキュリティの基本は「AIセキュリティとは」で解説しています。
