top of page
VL_logo_B_color&gray_260702..png

Share

topnews_button_2.png

【完全解説】LLMジャッキングとは?仕組みとAI防御策まとめ

10月15日
読了時間: 12分
【完全解説】LLMジャッキングとは?仕組みとAI防御策まとめ


「LLMジャッキング(LLMjacking)」とは、攻撃者が不正に入手したAPIキーやクラウド認証情報を悪用し、正規契約者の費用負担で高性能なAIモデルを不正利用する攻撃手法です。※参考:2

Google脅威インテリジェンスグループ(GTIG)をはじめとする世界的なセキュリティ機関が警鐘を鳴らすこの脅威は、漏えいしたAPIキーを悪用して被害者のアカウントで膨大な計算資源を消費させ、利用料金を肩代わりさせる攻撃手法です。


本記事では、LLMジャッキングの仕組み、発生要因、最新事例から実践的な10の防御策、AI-SPMによる監視手法まで網羅的・専門的に解説します。



最先端AIセキュリティ|CatoAIセキュリティ




INDEX













LLMジャッキングとは?Googleも警告するAI利用料の不正課金被害


LLMジャッキングとは?Googleも警告するAI利用料の不正課金被害


▶︎Google脅威インテリジェンスグループ(GTIG)が示すLLMジャッキングの最新動向


かつて攻撃者にとってAIは、フィッシングメールの文面生成やマルウェアコードのデバッグなど「単発で利用する道具」に過ぎませんでした。しかし現在では、標的の偵察・脆弱性探索・認証情報収集・悪意あるインフラ構築といった一連の攻撃工程を、AIが自律的に実行する「攻撃型AIエージェント」へと進化しています。これにより、人手を介さない全自動の攻撃ワークフローが現実のものとなっています。


Google脅威インテリジェンスグループ(GTIG)が公開した「From Prompting to Autonomy: The Evolution of Adversarial AI」レポートによると、攻撃者がクラウド上の誤設定や、GitHubの公開リポジトリを24時間体制でボット探索し、見つかったAPIキーを即座に自動化スクリプトへ組み込んで消費する「LLMジャッキング」が確認されています。※参考:1





▶︎他人にAI利用料を払わせる攻撃者の目的と仕組み


攻撃者がLLMジャッキングを行う目的は、単なる嫌がらせではありません。極めて現実的かつ金銭的な動機が存在します。



自前インフラ費用の完全ゼロ化


自前のインフラや有償契約を用意せず、標的企業のAPIキーを使ってサイバー攻撃の自動化スクリプトやスパム配信、自前の開発作業を実行します。

高性能モデルを使用すると、大量のトークン処理に伴い莫大な従量課金が発生します。攻撃者はスパム生成、サイバー攻撃ツールの開発、独自AIのファインチューニングなどの計算コストをすべて被害企業に支払わせます。



モデル蒸留(Model Distillation)の踏み台


最先端の商用モデルに対して組織的な攻撃キャンペーンが定期的に確認されており、GTIGは1億回を超えるプロンプト送信事例を報告しています。攻撃者はその出力データを自前のオープンソースモデルに学習させ、推論コストを他者に負担させた形で「模倣モデル」を生成します。※参考:1



窃取したAPIキーの転売・現金化


攻撃者は、窃取したAPIキーを2通りの方法で現金化します。 ①動作確認済みのキー単体をダークウェブ・テレグラムで直接転売する方法と、②複数のキーを集約して独自の格安AI利用サービスとして提供・販売する方法です。


LLMジャッキングの典型的な攻撃フローの図



▶︎暗号資産マイニング(クリプトジャッキング)とLLMジャッキングの違い


これまでクラウドインフラを狙う代表的なリソース搾取攻撃は「クリプトジャッキング(Cryptojacking:不正マイニング)」でした。しかし現在、攻撃者の関心は急速にLLMジャッキングへとシフトしています。

両者の相違点を整理すると、攻撃者の動機と企業側の検知難易度の違いが明確になります。









なぜ発生する?LLMジャッキングを引き起こす3大要因


なぜ発生する?LLMジャッキングを引き起こす3大要因

LLMジャッキングの根本原因は、①コード内へのAPIキーの平文埋め込み、②クラウドIAMの過剰な権限付与、③社員による無許可なシャドーAI利用の3点に集約されます。




1. 設定ファイルにAPIキーをそのまま書いてしまう「平文放置」の危険性


LLMジャッキングにおいて、最も頻繁に見られる原因が、ソースコードや設定ファイルへのAPIキーのハードコード(平文埋め込み)による放置です。

開発段階で一時的に記述したコードを、うっかりGitHubなどのパブリックリポジトリや社外共有ストレージにアップロードしてしまうミスが後を絶ちません。攻撃者のクローラーボットやAIエージェントは公開後わずか数秒〜数分で検知し、即座にキーを奪取します。


GTIGのレポートでは、DUSTMAKERと呼ばれるマルウェアが .claude/、.cursor/、.vscode/ といったAI開発ツールの構成フォルダ内にファイルを隠蔽し、EDR(エンドポイント検知)を回避する手口が報告されています。また別の攻撃手法として、Clineの secrets.json や、Continue AIの config.yaml といった設定ファイルも認証情報窃取の標的として言及されています。※参考:1




2. 「誰でも何でもできる」クラウド権限設定(IAMの過剰付与)が生む隙


2つ目の要因は、クラウド環境におけるIAM(Identity and Access Management)の権限設計が甘いケースです。

開発スピードを優先するあまり、開発用アカウントやサービスアカウントに対して、AdministratorAccessや広範なBedrockFullAccess、Vertex AI Administratorなどの権限を付与していると、万が一1つの開発者アカウントやサーバーが侵害された際、攻撃者はクラウド全体のLLM呼び出し権限を自由に行使できるようになります。最小権限の原則が破綻している環境は、攻撃者にとって格好の餌食となります。




3.社員が勝手に使う「シャドーAI」が招くAPIキー漏えいリスク


3つ目の要因は、IT部門やセキュリティ部門の許可を得ずに現場主導で導入される「シャドーAI(Shadow AI)」の蔓延です。

個人のPC環境に保存されたAPIキーは社内EDR(エンドポイント監視)の対象外であることが多く、マルウェア感染やフィッシング詐欺によって簡単に窃取されます。会社側が把握していないため、不正課金が発生してクレジットカードの請求書が届くまで被害に気付けません。







LLMジャッキングによる企業への金銭的・法的リスクと最新事例


LLMジャッキングによる企業への金銭的・法的リスクと最新事例

LLMジャッキング被害は単なるAPI課金(数百万円超)にとどまらず、モデル蒸留による独自ノウハウの流出、ダークウェブでの認証情報転売、さらにはコンプライアンス違反による賠償責任へと波及します。




▶︎わずか6時間で構築された自動攻撃システムと2万件超の漏えい事例


GTIGが確認した侵害事例の一つでは、攻撃者が6時間以内に大規模な認証情報収集キャンペーンを計画・構築・実行したことが判明しています。

また別の事例では、攻撃者が管理する公開状態のダッシュボードが発見され、2万3,800件超のAPIキーを含む機密情報がリアルタイムで管理されていました。※参考:1



  1. AIエージェントを用いた認証情報収集パイプラインの稼働


  2. 2万3,800件超のシークレット情報(APIキー、DBパスワード、トークン)の抽出


  3. 抽出した2万件以上の鍵情報を分類・整理し、外部からいつでもアクセス・悪用できるダッシュボードの開設 



人間が気づいて緊急対応を開始する前の「深夜帯の数時間」で、企業のインフラが完全に攻撃者の認証情報流通プラットフォームへと作り替えられてしまったのです。




▶︎1億回超のリクエストによるモデル蒸留の脅威


LLMジャッキングの深刻な形態として「モデル蒸留(Model Distillation)」を目的とした悪用があります。

Googleの脅威レポートでは、最先端商用モデルを標的とした組織的なモデル蒸留キャンペーンが定期的に観測されており、なかには1億回を超えるプロンプトを送信したケースも報告されています。


攻撃者は、企業の独自ノウハウが詰まった専門AIの回答結果を「タダで吸い出し」、自前のオープンソースモデルに転写します。

被害企業は他人のAI開発費用を肩代わりさせられた上に、API呼び出しの上限枠を枯渇させられ、自社の正規サービスが全面停止するダウンタイム被害を被ることになります。※参考:2,3


悪意あるモデル蒸留の概念図


▶︎闇市場で取引価格が2倍以上に高騰するClaude・Gemini等の認証情報


アンダーグラウンドのサイバー犯罪市場(ダークウェブ)において、現在もっとも高値で取引されているデジタルアセットの一つが「検証済みのAIクラウドアカウント」です。

GTIGの調査データによると、サイバー犯罪フォーラムにおけるAI関連アカウントの取引価格は、2026年時点で従来の2倍以上に高騰しています。※参考:1



高額取引される主要ターゲット


  • Anthropic Claude(Claude 3.5 Sonnet / Opus等のAPIアクセス枠)


  • Google Cloud Vertex AI / Gemini API


  • AWS Bedrock / Azure OpenAI Serviceの企業契約キー


  • Cursor、GitHub Copilotなどの開発支援AIツールのアカウント



GTIGの調査では取引価格が2倍以上に高騰しているとされ、複数のセキュリティ研究者の報告によると数百ドル〜数千ドル規模で取引される事例も報告されています。

攻撃者にとって、LLMキーの強奪は極めて現金化しやすい「高利回り商品」となっているのです。






明日から実践!LLMジャッキング対策の基本チェックリスト【全10項目】


まとめ:安全なAI活用が企業の競争力を決める|イメージイラスト

LLMジャッキング対策には、MFA適用や平文排除といった基本衛生管理に加え、利用枠の上限設定・IP制限・定期的な鍵ローテーションなど、多層的な防御設計が不可欠です。

LLMジャッキング被害を防ぐため、情シスや開発現場が直ちに取り組むべき対策を10項目にまとめました。

参考:4





AI-SPM(AI資産管理)でLLMジャッキングを防ぐアプローチ


AI-SPM(AI資産管理)でLLMジャッキングを防ぐアプローチ


個々のエンジニアの注意力や手動の監査だけに頼るセキュリティ対策には、組織が拡大するにつれて必ず限界が訪れます。こうした課題に対応するアプローチとして、近年注目が高まっているのが「AI-SPM」です。社内のモデル・APIキーの自動可視化、設定不備の是正、トークン消費のリアルタイム監視により強固な防御を実現します。




【可視化】開発環境・設定ファイル内に潜むAPIキーの自動スキャン


AI-SPMの第1の柱は、組織内に存在するすべての「AI資産」を自動検知して可視化する機能です。



シャドーAIの完全あぶり出し


組織内のマルチクラウド環境、SaaS環境、GitHub等のソースコードリポジトリを網羅的にクローリングし、管理者の知らないところで発行・放置されているAPIキーやエンドポイントを自動抽出して「AI資産台帳」を自動生成します。



設定ファイル・シークレットの常時スキャン


ローカル設定ファイル(config.yaml、.cursor 等)や公開ストレージ、コンテナイメージの内部にAPIキーが生のテキストで埋め込まれていないかをディープスキャンし、リスクスコアを付与して警告します。




【設定管理】クラウドの設定不備やGPU計算資源要求の異常検知


第2の柱は、クラウドインフラの設定不備と過剰なアクセス権限の是正です。



過剰権限のプロアクティブな削減 


「どのサービスアカウントが、どのLLMモデルに対して、過去何日間に呼び出しを行ったか」を詳細に追跡します。利用実績のない過剰なフルアクセス権限を検知し、安全な最小権限ポリシーへと自動縮小を提案・適用します。



GPUリソース・クォータ引き上げ要求の即時検知


攻撃者がLLMジャッキングを行う前段階として、クラウド事業者に対してLLM APIのレートリミットやトークン消費クォータの引き上げ申請を行うケースが多く見られます。AI-SPMはこうした異常な構成変更リクエストを即座に捕捉し、管理者の承認がない限り自動でブロックします。

※参考:5




【監視】異常なトークン消費とコスト跳ね上がりの早期警戒


第3の柱は、ランタイム(稼働中)におけるトークン消費動向のモニタリングとインシデントへの即時自動対応です。



行動ベースの異常検知


普段は平日日中に日本語で1リクエストあたり平均500トークンを消費しているシステムが、突如として深夜帯に海外IPから英語で数万トークンのプロンプトを秒間数百回リクエストし始めた場合、これを「LLMジャッキングの疑い」として即時フラグ付けします。



連携による自動キルスイッチ


閾値を超える急激なトークン消費や不審なプロンプトの連続を検知した瞬間、AI-SPMが製品と連携し、該当するAPIキーをシステムがミリ秒単位で自動無効化します。これにより、深夜にインシデントが発生しても、被害額を数千円〜数万円の最小限に抑え込むことが可能となります。※参考:2,3





LLMジャッキングについてよくある質問(FAQ)



Q. LLMジャッキングとプロンプトインジェクションの違いは何ですか?


A. 標的と攻撃手法が根本的に異なります。プロンプトインジェクションは、AIに入力する文章を工夫して「AIの安全ガードレールを回避し、不正な出力や内部指示を暴く」攻撃です。一方、LLMジャッキングは「APIキーやクラウドアカウント自体を盗み、正規ユーザーの金銭負担でAIリソースをタダ乗り・濫用する」インフラ乗っ取り攻撃です。



Q. 無料版のChatGPTやGeminiを使っていても被害に遭いますか?


A. 無料版や月額固定制(Webブラウザ版のChatGPT Plus等)の個人利用であれば、利用料が青天井に膨らむ金銭的被害は発生しません。ただし、アカウントのログイン情報(ID/パスワード)が盗まれた場合、チャット履歴に含まれる機密情報・個人情報の漏えいリスクや、アカウントがスパム発信の踏み台に悪用されるリスクは同様に存在します。



Q. 万が一LLMジャッキングで高額請求が発生した場合、AIベンダーに返金・免除してもらえますか?


A. 原則として返金や請求免除は保証されません。主要なAIプロバイダやクラウド事業者の利用規約では「APIキーおよび認証情報の管理責任はユーザー側にある」と明記されています。プロバイダ側の善意や例外的な特例措置で減免される事例もありますが、全額自己負担となるケースが大半です。※参考:8



Q. 被害に気づいた場合、最初に何をすべきですか?


A. 直ちに以下の3ステップを実行してください。

  1. 侵害されたAPIキーの即時無効化(Revoke)

  2. クラウド管理コンソールの該当IAMユーザー/ロールの無効化と全セッションの強制ログアウト

  3. APIキー再発行と、環境変数およびシークレット管理サービスへの移行

原因調査や社内報告を行う前に、まずは利用料の課金を物理的に止めることが最優先です。







まとめ


AI-SPMの導入と適切な鍵管理で安全なLLM運用を実現しよう


まとめ:AI-SPMの導入と適切な鍵管理で安全なLLM運用を実現しよう

AIの活用が企業の競争力を左右する時代において、LLMジャッキングは避けて通れない重大なサイバー脅威となっています。攻撃者はAIエージェントを駆使して自律的に侵入し、わずか数時間で莫大な経済的損失と知的財産の流出をもたらす可能性があります。※参考:7


まずは自社のアカウントに多要素認証が設定されているか、従量課金のアラートが正しく機能しているかを直ちに確認してください。

そして、「平文キーの排除」「最小権限の徹底」「利用枠上限の設定」といった基本対策を今すぐ実行するとともに、将来的にはAI-SPMを活用した資産の可視化とリアルタイム監視体制を構築し、安全で持続可能なAI活用を推進していきましょう。





出典・参考一覧


  1. Google Cloud「From Prompting to Autonomy: The Evolution of Adversarial AI」 https://cloud.google.com/blog/topics/threat-intelligence/from-prompting-to-autonomy-the-evolution-of-adversarial-ai

  2. Sysdig「LLMjacking: Stolen Cloud Credentials Used in New AI Attack」 https://www.sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack

  3. Sysdig「Growing Dangers of LLMjacking」 https://www.sysdig.com/blog/growing-dangers-of-llmjacking

  4. OWASP「OWASP Top 10 for LLM Applications 2026」 https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/


  5. NIST「NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0)」 https://www.nist.gov/itl/ai-risk-management-framework

  6. CSA「AI Model Risk Management Framework」 https://cloudsecurityalliance.org/artifacts/ai-model-risk-management-framework


  7. IPA「情報セキュリティ10大脅威 2026」https://www.ipa.go.jp/security/10threats/10threats2026.html

  8. AWS「AWS 責任共有モデル」 https://aws.amazon.com/jp/compliance/shared-responsibility-model/

bottom of page