LLMトークン闇市場の実態｜OpenAI・Claude APIキーを狙うLLMjacking

---

午前2時。誰もAIを使っていないはずなのに、APIの利用額だけが静かに増え続けている。

異変に気づいた担当者が管理画面を開くと、普段は使わない高性能モデルへの大量リクエストが記録されていた。障害対応のバッチ処理か、開発者の負荷テストか。社内へ確認しても、誰にも心当たりがない。

そこで浮かび上がったのが、会社のAPIキーが盗まれ、世界のどこかで第三者に使われている可能性である。

本当に怖いのは、高額請求だけではない。盗まれたAPIキーは、格安AIサービスの「在庫」として転売され、攻撃ツールを動かす「盗まれた頭脳」へ変わり始めている。

LLMjackingとは何か

LLMjackingとは、盗んだAPIキーやクラウド認証情報を使い、他人の費用で大規模言語モデルを不正利用する攻撃である。

「LLMjacking（LLMジャッキング）」という名称は、クラウドセキュリティ企業Sysdigが2024年に使い始めました。同社が確認した初期の攻撃では、盗まれたクラウド認証情報を使い、Anthropic、OpenAI、AWS Bedrock、Azure、Google Vertex AIなど、複数のAIサービスへ接続できるかが自動的に調べられていました。

APIキーを理解するには、会社名義のガソリンカードを想像すると分かりやすいでしょう。社員が業務で使えば、会社が料金を支払います。しかし、そのカードを盗んだ人物が何台もの車へ給油しても、請求はカードを契約した会社へ届きます。

APIキーも同じです。攻撃者は自分で利用料金を支払わず、被害企業の契約で文章、画像、コードなどを大量に生成できます。しかも、AIのAPIは人間が画面から一回ずつ質問する仕組みではありません。プログラムから毎秒、毎分、休みなく呼び出せるため、人が眠っている間にも料金を積み上げられます。

Sysdigは、AWS Bedrock上のClaude 2.xを複数リージョンでクォータ上限まで悪用した場合、1日4万6,080ドルに達する可能性があると試算しています。これは実際に確認された請求額ではなく、4リージョンで利用上限まで24時間消費する最悪ケースを想定した数値です。

APIキーは、単なる開発用の文字列ではありません。利用するたびに企業の費用が発生する、AI時代の決済手段でもあるのです。

盗まれたAPIキーはどこへ行くのか

盗まれたAPIキーは一度使われて終わるのではなく、有効性を確認され、複数まとめて管理され、継続販売できる商品へ変わる。

APIキーが盗まれた後、攻撃者はすぐに使い捨てるとは限りません。最初に行うのは、その鍵が本当に使えるかの確認です。

• どのAIサービスへ接続できるか
• どのモデルを利用できるか
• どれほどの利用枠が残っているか
• どの地域から利用できるか
• ログや監視が有効になっているか

これは、盗んだ鍵を一本ずつドアへ差し込み、「この鍵は倉庫用」「こちらは金庫用」と価値を調べる作業に似ています。

次に、使えると判断した複数のキーを「リバースプロキシ」と呼ばれる中継サーバーへ登録します。リバースプロキシ自体は、正規のWebサービスでも負荷分散やセキュリティのために使われる仕組みですが、問題はその裏側へ盗難キーを大量に登録する使い方です。

利用者から見えるのは、一つの格安AIサービスです。しかし裏側では、世界中から盗まれた可能性のあるキーが順番に切り替えられます。一つのキーが失効しても、別のキーへ切り替えれば営業を続けられます。

リバースプロキシは、盗んだ何十本もの鍵を裏側で交換しながら営業する「違法なAIレンタル店」になり得ます。

盗まれたAPIキーが商品へ変わる流れ

段階	攻撃者の行動	企業側で起きること
漏洩	GitHub、設定ファイル、端末などから認証情報を取得	企業は漏洩に気づかないまま利用権を奪われる
検査	利用可能なモデル、権限、利用枠を確認	盗難キーが価値のある「在庫」として分類される
集約	複数のキーをリバースプロキシへ登録	一つのキーを止めても別の盗難キーで利用が続く
販売	格安AIサービスとして第三者へアクセス権を提供	企業の費用で複数の利用者がAIを動かす

購入者に渡されるのも、元のAPIキーそのものとは限りません。中継サービスへ接続するための別のトークンだけを渡し、本物のAPIキーは利用者から隠します。

この仕組みによって、APIキー漏洩は一度きりの盗難ではなく、継続的に収益を生む犯罪ビジネスへ変わります。

LLMトークン闇市場はどう組織化されているのか

LLMトークン闇市場は、個人による無断利用から、探索・検証・販売が分業された犯罪サプライチェーンへ変化している。

この実態を象徴するのが、2026年1月に公表された「Operation Bizarre Bazaar」です。Pillar Securityは、2025年12月から2026年1月にかけて、公開されたAIインフラを狙う3万5,000件以上の攻撃セッションを観測しました。

攻撃は主に次の役割へ分かれていました。

• インターネット上から公開されたAIサーバーを探す
• 利用可能なモデルやアクセス権を確認する
• 確認済みのアクセスを商品として販売する

販売サービスは、30以上のLLM事業者への接続をうたい、DiscordやTelegramなどで宣伝されていました。ここで注目すべきなのは、3万5,000という数字だけではありません。

盗む人、価値を調べる人、商品として売る人が分業されていたことです。

一般の商品市場にも、品物を集める人、鑑定する人、店舗で販売する人がいます。LLMトークン闇市場でも、それに似た役割分担が生まれています。

APIキーを漏らした企業は、どこかの攻撃者に数回使われるだけでは済まないかもしれません。その鍵が「利用可能な在庫」として登録され、複数の顧客を支える格安AIサービスの裏側で使い回される可能性があります。

APIキー漏洩は、開発者個人の小さなミスではありません。企業の計算資源を犯罪市場へ供給してしまう重大なセキュリティ事故です。

なぜAPIキーなどの認証情報は次々と漏れるのか

問題の根は攻撃者の巧妙さだけではなく、認証情報の所在、所有者、用途、権限を企業が把握できていないことにある。

セキュリティ分野では、APIキーやパスワードなど、第三者に知られてはいけない認証情報をまとめて「シークレット」と呼びます。システムやクラウドサービスの扉を開ける「デジタルな鍵」と言えるでしょう。

本記事では専門用語を繰り返さず、以降は原則として「APIキーなどの認証情報」と表記します。

攻撃者が市場をつくれるのは、販売できる認証情報が大量に供給されているからです。GitGuardianによると、2025年に公開GitHubへ新たに書き込まれたAPIキーやパスワードなどの認証情報は、2,865万件に達しました。

また、AIと外部ツールを接続するMCPの設定ファイルからも、2万4,008件の固有な認証情報が確認されました。さらに深刻なのは、2022年に有効だった漏洩認証情報のうち64％が、2026年時点でも利用可能な状態だったという事実です。

APIキーなどの認証情報が漏れる理由は、決して特別ではありません。

• テストのため、ソースコードへ一時的に書いた
• .envファイルを誤ってGitHubへ登録した
• CI/CDのログへキーが表示された
• 社内チャットへ貼り付けた
• 信頼できないIDEプラグインへ入力した
• 開発用と本番用で同じキーを使った
• 退職者や委託先のキーを失効し忘れた
• MCPやAIエージェントの設定ファイルへ平文で保存した

いずれも、スピードを求められる開発現場では決して珍しくない日常の一コマです。しかし、本当の脅威は鍵が漏れること以上に、漏れたことに気づけず、どこから漏れたかも特定できない構造にあります。

一つのキーを複数人や複数システムで共有していれば、不正利用を発見しても、漏洩元をすぐに判断できません。キーを失効すれば、どの本番サービスが停止するかも分からないため、対応が遅れます。

厳格な管理とは、認証情報を秘密の場所へ隠すことではありません。漏洩時に、そのキーだけを迷わず止められる状態にすることです。

MCPを含むAIツール連携の基本構造は、MCPとは？AIツール連携の仕組み・APIとの違い・安全な始め方を解説【2026年版】で詳しく解説しています。

格安AIサービスの本当の代金

問題は価格の安さではなく、誰の認証情報で動き、誰が通信内容を閲覧・保存できるのか分からない点にある。

すべての非公式APIやモデルゲートウェイが違法なわけではありません。正規契約に基づき、複数のAIモデルを一つのAPIから提供する事業者も存在します。しかし、公式料金より極端に安く、運営企業やデータの取扱方針が分からないサービスには注意が必要です。

安さの裏側に、盗難キー、不正アカウント、盗難カード、モデルのすり替えなどがある可能性を、利用者は外から確認できないからです。

さらに、プロキシを利用した場合、入力した情報は公式のAI事業者へ届く前に、プロキシ運営者のサーバーを通過します。

そこには、次のような情報が含まれるかもしれません。

• 顧客名や個人情報
• 社内文書や会議資料
• ソースコード
• システム構成
• 障害ログ
• AIエージェントが利用したツールやデータ

運営者が必ず情報を盗むとは限りません。しかし、通信内容を保存、分析、二次利用できる技術的な位置にいることは事実です。

2025年2月にMicrosoftが公表したStorm-2139の事例では、攻撃者が公開情報から取得した顧客の認証情報を使って生成AIサービスへ不正アクセスし、安全対策を回避する仕組みを第三者へ提供していました。利用者はそのサービスを、有害な合成画像などの生成へ使っていました。ここでも、認証情報を取得する人、仕組みを作る人、悪用する人の分業が確認されています。

格安AIの本当の代金を支払うのは、購入者とは限りません。

認証情報を盗まれた企業が費用を負担し、入力データの持ち主が情報漏洩リスクを負い、生成された有害コンテンツの被害者が別に生まれます。

AIセキュリティの全体像を整理したい方は、AIが変えるセキュリティ｜ゼロトラスト・RBVM・最新脅威を徹底解説もあわせてご覧ください。

格安チャットから「盗まれた頭脳」へ

盗まれたAI資源の用途は、格安チャットの販売だけでなく、攻撃ツールの判断やコード生成を支える計算資源へ広がり始めている。

当初、盗まれたAIアクセスの用途は、無料または格安でチャットやコード生成を利用することが中心でした。つまり、悪い人が盗んだロボットを、別の人へ安く貸していたのです。

しかし現在は、そのロボットに攻撃方法を考えさせる動きが始まっています。Sysdigは2026年6月、認証なしでインターネットへ公開されていたOllamaサーバーが、自動攻撃ツールの推論エンジンとして利用された事例を報告しました。

AIは、標的情報の整理、脆弱性の分析、攻撃コード候補の作成、実行結果に基づく次の行動の判断などに使われていました。

これは、AIが自ら悪意を持ち、勝手に犯罪を始めたという意味ではありません。人間が標的と目的を決め、AIに調査、判断、コード作成を手伝わせています。また、この事例はOpenAIやClaudeの盗難APIキーではなく、認証なしで公開された自己運用型AIサーバーを利用したものです。

それでも、本質は共通しています。

他人が所有するAIの計算能力を奪い、自分の攻撃を動かす「頭脳」として使っていることです。

AIエージェントに外部システムの操作を任せる企業では、接続後の統制まで含めて考える必要があります。詳しくは、AIエージェントセキュリティ｜MCP・A2A時代に企業が守るべきものをご覧ください。

企業が失うのは利用料金だけではない

APIキー漏洩は、費用増加、業務停止、情報流出、監査不能、犯罪への間接利用を同時に引き起こす複合インシデントである。

APIキー漏洩で最初に目に入るのは、身に覚えのない請求です。しかし、企業が失うものはお金だけではありません。

不正利用でレート制限やクォータへ到達すれば、正規の業務システムがAIを使えなくなります。顧客対応、社内検索、文書作成、開発支援などにAIを組み込んでいれば、API停止がそのまま業務停止につながります。

キーに広い権限が与えられていれば、保存済みファイルやプロジェクト内の資源などへ影響が及ぶ可能性もあります。一つのキーを複数の部署やシステムで共有していれば、正規利用と不正利用が混ざり、誰が何のデータを送ったのか追跡できなくなります。

さらに、自社名義のAI資源が詐欺メール、有害画像、攻撃コードなどの生成へ利用されれば、企業の説明責任や信用問題にも発展します。

APIキーは、パスワード、クレジットカード、クラウドの操作権限を合わせたような資産として扱う必要があります。

AIの業務利用と統制の関係は、2026年、AIエージェント「実装元年」へ──“行動するAI”を使いこなし、統制する技術でも整理しています。

一つの共有キーが初動を遅らせる

厳格管理の価値は、平常時の整理整頓ではなく、事故の夜に迷わずキーを止められることにある。

ここで、ある企業の状況を想像してみましょう。その会社では、開発を早く進めるため、一つのAPIキーを開発環境、検証環境、本番環境で共有していました。委託先にも同じキーを渡し、複数のバッチ処理や社内ツールが利用しています。

深夜に異常利用を発見しても、担当者はすぐにキーを止められません。

止めれば、どのシステムが停止するか分からないからです。

顧客向けサービスが止まるかもしれない。翌朝の集計処理が失敗するかもしれない。委託先が作業中かもしれない。

関係者へ確認している間も、不正利用は続きます。

これは攻撃手法が巧妙だから起きるのではありません。企業側の管理方法が被害を拡大させる例です。

反対に、システムと環境ごとにキーが分かれ、所有者と用途が台帳へ記録されていれば、異常なキーだけをすぐに止められます。本番への影響も予測できます。

厳格管理の価値は、事故の夜に「このキーは止めてよい」と迷わず決断できることにあります。

厳格管理とは「漏らさない」だけではない

管理の本質は、誰が、どの認証情報を、何のために使い、異常時に何分で止められるかを説明できることにある。

もしこの記事を読んでいる今、自社のAPIキーの所在を三つ挙げられないなら、次の項目は特に重要です。

最初に、APIキーをソースコード、ブラウザ、モバイルアプリ、共有チャットへ置かないことです。本番環境では、APIキーやパスワードなどの認証情報を暗号化して保管し、必要なシステムだけへ安全に渡す専用サービスを利用します。これは「シークレット管理基盤」と呼ばれ、AWS Secrets Manager、Azure Key Vault、Google Secret Manager、HashiCorp Vaultなどが代表例です。

次に、開発、検証、本番、システム、委託先ごとにキーを分けます。OpenAIも、個人のAPIキーを複数人で共有せず、プロジェクト単位で管理するよう案内しています。プロジェクトごとに権限、利用モデル、レート制限などを管理できるためです。

さらに、必要な操作だけを許可する最小権限を徹底します。キーが漏れる可能性を前提に、GitHub Push Protection、GitGuardian、gitleaks、TruffleHogなどを使い、外部へ送信される前に認証情報を検出します。

監視すべきなのは、請求額だけではありません。

• 通常と異なる時間帯
• 見知らぬIPアドレスや地域
• 普段使わないモデル
• 突然増えたトークン数
• 認証エラーの急増
• 権限やログ設定の変更

特に注意したいのは、予算設定を「自動停止装置」だと思い込むことです。OpenAIのプロジェクト予算はソフトしきい値であり、設定額を超えてもAPI処理は継続します。予算通知は異常を見つける仕組みであり、被害を強制停止するハード上限ではありません。

管理状況は、次の四つの質問で確認できます。

• そのキーの所有者は誰か
• 何のシステムが、どの環境で使っているか
• どのモデルや機能へアクセスできるか
• 異常を検知してから、何分で失効できるか

一つでも答えられなければ、認証情報は「保管」されていても「管理」されてはいません。

認証情報を含むゼロトラスト設計の考え方は、AIエージェントのゼロトラスト設計｜信頼しない前提でどう守るかでも解説しています。

漏洩を疑ったら、調査より先に止める

インシデント対応で最初に行うべきことは原因究明ではなく、該当キーを失効させて被害の拡大を止めることである。

APIキーの漏洩が疑われたとき、最初に原因を探したくなるかもしれません。しかし、調査中にも攻撃者はAIを使い続けます。

対応の順番は次のとおりです。

1. 該当キーを直ちに失効する
2. 新しいキーを安全に発行する
3. 本番システムを新しいキーへ切り替える
4. 利用履歴、接続元、モデル、請求額を確認する
5. 漏洩経路と影響範囲を調査する
6. 関連するほかのキーも棚卸しする

ソースコードからAPIキーの文字を消しただけでは不十分です。Gitの履歴、フォーク、キャッシュ、開発者の端末に残っている可能性があります。一度外部へ出たキーは、すでに誰かが取得したものとして扱う必要があります。

Anthropicも、漏洩が疑われる場合は該当キーを削除して無効化し、新しいキーを安全な認証情報管理サービスへ保存するよう案内しています。

調査してから止めるのではありません。止めてから調査します。

一次情報からどこまで言えるか

確認された犯罪市場と将来の脅威予測を分けることで、過度に煽らず、LLMjackingの危険性を正確に伝えられる。

現時点で、次の事実は一次情報から確認できます。

• 盗難認証情報を使ったLLMの不正利用
• 利用可能なモデルやクォータの自動検査
• 複数の盗難アクセスをリバースプロキシへ集約する仕組み
• DiscordやTelegramなどを使ったアクセス権の販売
• 探索、検証、販売を分業する犯罪サプライチェーン
• GitHubやMCP設定ファイルからの大量の認証情報漏洩
• 他人のAI推論環境を攻撃ツールの判断処理へ使った事例

一方、すべての非公式APIサービスが盗難キーを使っている、すべてのプロキシが利用者のデータを転売している、AIが人間の指示なしに完全自律で犯罪を始めている、と一般化することはできません。

Arpable編集部が注目するのは、漏洩件数の多さではなく、その先にある仕組みです。

盗難アクセスを探し、価値を確認し、束ね、再販売する――この一連の流れが、継続的な犯罪ビジネスとして成立したことこそ、本質的な変化だと考えます。

AI開発の拡大によって大量のAPIキーやサービスアカウントが作られ、その管理が追いつかない。そこへ、盗難アクセスを商品化する市場が現れました。

この供給と需要がつながったことが、LLMjackingを単発事故から犯罪産業へ変えています。

まとめ

AIを本番業務へ組み込むなら、APIキーなどの認証情報も本番システムと同じ厳しさで管理しなければならない。

午前2時。管理画面には、まだ身に覚えのないAPI利用が並んでいます。

以前なら、担当者は「誰かがキーを使った」と考えたかもしれません。しかし、LLMトークン闇市場の構造を知った今は、見え方が変わります。

そのキーはすでに使えるか検査され、ほかの盗難キーと束ねられ、格安AIサービスの在庫になっているかもしれません。

そのAIが、誰かのチャットを動かしているだけとは限りません。詐欺コンテンツを生成し、攻撃ツールの判断を助ける「盗まれた頭脳」として使われている可能性もあります。

ここで担当者がすべきことは、請求書を眺め続けることではありません。

キーを止める。利用履歴を確認する。同じ管理方法で発行されたキーをすべて洗い出す。

そして翌朝、開発チームへ一つの質問を投げかけることです。

「当社のAPIキーは、今どこにあり、誰が使い、漏れたら何分で止められるのか」

この問いに答えられなければ、まだ管理できているとは言えません。

APIキーは、AIを呼び出すための文字列ではありません。企業が購入した知能、計算資源、予算、信用を守る金庫の鍵です。

LLMjackingという言葉がいつか使われなくなっても、盗まれた認証情報を商品へ変える構造は消えません。AIを本番業務へ組み込むなら、認証情報管理も本番システムと同じ厳しさへ変える必要があります。

参考文献 / 出典

本記事は、AI事業者、セキュリティ企業、開発プラットフォームが公開した一次情報を中心に構成している。

次に読むならこの3本

補足Q&A

Q1.
APIキーをGitHubから削除すれば安全ですか？

A1.
削除するだけでは安全になりません。

過去のコミット履歴、フォーク、キャッシュ、開発者の端末などに残っている可能性があります。外部へ公開されたキーは漏洩済みと判断し、管理画面から直ちに失効してください。

Q2.
格安のOpenAI互換APIはすべて違法ですか？

A2.
すべてが違法とは限りません。

正規契約に基づくAPIゲートウェイも存在します。ただし、運営主体、データ保存方針、実際に使われるモデル、事故時の連絡先を確認できないサービスへ、企業の機密情報を送信すべきではありません。

Q3.
予算上限を設定すれば、不正利用を自動停止できますか？

A3.
予算設定が必ずしも自動停止を意味するわけではありません。

OpenAIのプロジェクト予算はソフトしきい値であり、設定額を超えても処理は継続します。予算通知、レート制限、権限制限、異常検知、緊急失効手順を組み合わせてください。