従量課金のAI APIは、リクエスト数ではなく「焼いたトークン量」と「占有した計算資源」で課金される。ここに、外部の攻撃者が正規の入口から意図的に高コストな入力を送り込み、あなたの推論費・レート枠・同時実行キャパを枯らす——という新しい攻撃面が生まれた。OWASP LLM Top 10（2025）が「Unbounded Consumption（LLM10）」を独立項目に格上げし、実務界では「Denial of Wallet（DoW／財布枯渇攻撃）」と呼ばれる脅威である。本記事は、この「正規に見えるが意図的に高コストな入力」に焦点を絞り、トークン予算上限・複雑度制限・同時実行/レート遮断・スポンジ入力検知・テナント別クォータによる多層防御を、貴社の入口から運用まで通しで設計する。
- はじめに——守る対象が「可用性（DoS）」から「請求書（DoW）」へ
- 前提——DoW／Unbounded Consumptionを4つの手口で整理する
- 攻撃の見え方——「正常な高負荷ユーザー」と「枯渇攻撃」はどう違うか
- 第1の防御層：入口——トークン予算上限と複雑度制限
- 第2の防御層：同時実行・レート遮断とテナント別クォータ
- 第3の防御層：スポンジ入力検知と増幅ループの遮断
- コスト×セキュリティの交差点——AI FinOps・可視化ダッシュボードとの連携
- 検知→遮断→監査のインシデント連携
- 多層防御チェックリスト
- よくある質問（Q&A）
- まとめ——「止まらないまま財布が枯れる」を前提に設計する
- 参考リンク・関連記事
はじめに——守る対象が「可用性（DoS）」から「請求書（DoW）」へ
従来のDoS/DDoSは、サービスを止めることが目的だった。狙いは可用性であり、防御の指標は「落ちないこと」だった。生成AIの従量課金時代に現れたDenial of Wallet（DoW）は、サービスを止める必要すらない。止まらないまま、請求額だけが青天井に膨らむのが本質である。攻撃者は正規のチャットUIやAPIキー発行フローという「表玄関」から入り、1リクエストで大量のトークンを消費させる入力を投げ込む。レスポンスは正常に返る。監視ダッシュボードのエラー率も上がらない。ところが月末、推論費とレート超過分の請求が跳ね上がる。
この非対称性がDoWの厄介さである。攻撃者側のコストはリクエスト1本ぶんのわずかな帯域だが、防御側のコストは入力トークン × 出力トークン × モデル単価 × 増幅係数で膨れ上がる。エージェント化とマルチステップ推論が普及したことで、「1リクエストが内部で何十回もモデルを呼ぶ」構造が当たり前になり、この増幅係数が桁で効くようになった。守るべき対象は、もはやサーバの稼働率ではなく請求書そのものだ、という前提の転換から本記事は始まる。
前提——DoW／Unbounded Consumptionを4つの手口で整理する
「高コストな入力」と一口に言っても、コストを膨らませる経路は異なる。防御を層に分けるためにも、まず攻撃の見え方を4つに分解する。
手口1：高コストクエリ（最大出力・長文脈の強制消費）
もっとも素朴で、もっとも多いのがこれだ。攻撃者は「できるだけ長く」「一字一句すべて」「10万語で」といった指示や、巨大な貼り付け入力によって、入力トークンと出力トークンの両方を上限まで焼かせる。max_tokensを大きく取っているエンドポイントや、長文脈モデル（数十万〜百万トークン）を無制限に開放しているエンドポイントほど被害が大きい。1リクエストあたりの単価が跳ね上がるため、少ない回数でも請求が膨らむ。
手口2：反射ループ／再帰的増幅（エージェントの多段呼び出しを踏み台にする）
自律エージェントやツール連携（function calling、ReActループ）を公開している場合、1回の入力が内部で「思考→ツール呼び出し→再推論」を何十回も繰り返す。攻撃者は、終了条件を満たしにくい曖昧なゴールや、自己参照的に膨張するタスク（「この結果をさらに詳しく、それをまた詳しく…」）を与えることで、1リクエストの裏で大量のモデル呼び出しを誘発する。ユーザーから見える入力は1本でも、課金対象の内部呼び出しは指数的に増える。
手口3：検索増幅（RAG／ツール連携のコストを爆発させる）
RAG構成では、入力→検索→大量チャンクの詰め込み→推論、という流れでコンテキストが膨らむ。攻撃者は、ヒット件数が爆発するような広いクエリや、大量ドキュメントの再ランキングを強制する入力を送り、検索・埋め込み・再推論の各段でコストを増幅させる。外部API（検索、埋め込み、リランカー）にも従量課金が乗っている場合、被害はモデル費だけにとどまらない。
手口4：スポンジ入力（Sponge Examples／計算量そのものを狙う）
スポンジ入力（sponge examples）は、出力の長さではなく「同じ長さでも異常に計算コストが高くなる」入力を意図的に作る手口だ。トークナイザを膨張させる特殊文字列・多言語混在・無意味なUnicodeの連なり、あるいはモデルが停止しにくい入力によって、単位トークンあたりの処理時間とメモリを引き上げる。レート制限（リクエスト数）やトークン上限をすり抜けながら、GPU占有時間＝キャパを枯らすのが狙いである。
標準フレームワークでの位置づけ
DoWはOWASP LLM Top 10（2025）の「LLM10:2025 Unbounded Consumption」に正面から対応する。同項目は、旧「Model Denial of Service」を拡張し、可用性の枯渇だけでなく「Denial of Wallet」「モデル抽出のための大量クエリ」までを射程に含めた。攻撃者視点の戦術・技術としてはMITRE ATLASの「Cost Harvesting／LLM Denial of Service」系テクニックに紐づく。つまりDoWは、思いつきの嫌がらせではなく、標準フレームワークに位置づけられた設計で対処すべき脅威カテゴリだと捉えるべきだ。
攻撃の見え方——「正常な高負荷ユーザー」と「枯渇攻撃」はどう違うか
DoW対策が難しいのは、ヘビーユーザーと攻撃者が同じ入口を、同じくらい正規に見える形で使う点にある。単純なレート制限（1分◯回）では、正規のパワーユーザーを巻き込むか、攻撃者を取り逃がすかの二択になりやすい。見るべきは「回数」ではなく「1リクエストが焼くコストの分布」だ。
| 観点 | 正常な高負荷利用 | 枯渇攻撃（DoW）の疑い |
|---|---|---|
| 1リクエストあたりトークン | タスクに応じて分布し、平均近傍に収まる | 常に上限に張り付く（max_tokens飽和が連続） |
| 入出力比 | 入力に見合った出力量 | 短い入力から異常に長い出力、または逆に巨大入力 |
| 内部呼び出し数 | タスク完了で収束する | 1入力あたりのツール／再推論回数が発散的 |
| 入力の性質 | 自然言語として一貫 | 反復・自己参照・無意味Unicode・停止しにくい構造 |
| コスト効用 | 出力が実際に利用される | 大量生成だが利用シグナルが乏しい／即座に再要求 |
この表の右列は、そのまま検知メトリクスの設計図になる。回数ベースの閾値ではなく、「トークン消費の分布」「内部呼び出しの発散」「入力の異常性」を軸に据えることで、正規ユーザーを守りながら枯渇攻撃だけを浮かび上がらせられる。
第1の防御層：入口——トークン予算上限と複雑度制限
最初の層は、1リクエストが焼けるコストの絶対上限を入口で固定することだ。ここが緩いと、後段の検知がどれだけ賢くても「1発の高コストクエリ」を止められない。
1. リクエスト単位のトークン予算上限
すべてのエンドポイントで、入力トークン・出力トークン（max_tokens）・両者合計にハード上限を設ける。用途に応じて上限を分ける（要約系は短く、生成系はやや長く）ことで、「10万語で書いて」を入口で機械的に頭打ちにできる。長文脈モデルを公開する場合は、コンテキスト長そのものにも上限を課し、必要なユーザーだけを審査つきで解放する「最小公開原則」を採る。
2. 入力複雑度の事前見積り（プリフライト・コスト計算）
推論を走らせる前に、入力トークン数・想定出力・（RAGなら）想定検索件数からコストを見積もり、閾値超過なら実行前に拒否または降格する。「まず走らせてから止める」ではなく「走らせる前に値付けする」——プリフライトでの見積りが、高コストクエリに対する最も費用対効果の高い一手だ。
3. 反射ループの深さ・反復・実行時間の上限
エージェントには、最大ステップ数・最大ツール呼び出し回数・最大ウォールクロック時間・累積トークン予算を必ず設定する。これは自社エージェントの暴走を止めるキルスイッチ／サーキットブレーカーと同じ機構を、外部入力に起因する発散にも適用するという発想だ。1リクエストの内部で使えるトークン総量に天井を設けておけば、手口2の再帰的増幅は天井で頭を打つ。
第2の防御層：同時実行・レート遮断とテナント別クォータ
入口で1発の上限を固めたら、次は「積み重ね」による枯渇を止める。個々のリクエストが健全でも、同時多発・高頻度で積み上がればレート枠とキャパは枯れる。
1. コスト建てのレート制限（回数ではなくトークン／金額で絞る）
「1分◯リクエスト」ではなく「単位時間あたりの消費トークン（または推定金額）」でレートを敷く。これにより、少数だが超高コストなクエリも、多数の中コストクエリも、同じ「予算の物差し」で公平に絞れる。トークンバケット方式で、消費トークン量に応じてバケットを減らす実装が扱いやすい。
2. 同時実行数の遮断とキュー制御
スポンジ入力や長時間ジョブがGPUを占有し続けると、リクエスト数が少なくてもキャパが枯れる。ユーザー／テナントごとの同時実行上限と、超過分をキューイング（または即時降格）する制御を入れ、1テナントが全体の計算資源を独占できないようにする。実行時間の長いジョブには強制タイムアウトを併用する。
3. テナント別クォータ（ブラスト半径の分離）
マルチテナントSaaSやAPI提供では、テナント（顧客・APIキー）ごとに日次／月次のトークン・金額クォータを設ける。1テナントが枯渇攻撃を受けても、被害と請求増をそのテナントの枠内に閉じ込め、他顧客と自社全体の財布に波及させない。クォータは「ハード上限（遮断）」と「ソフト上限（警告・降格）」の二段で持つと、正規の急増を殺さずに済む。無料枠・トライアル・匿名アクセスには、より厳しいクォータと（可能なら）本人確認を課す。
第3の防御層：スポンジ入力検知と増幅ループの遮断
上限とクォータをすり抜ける「賢い」入力に対しては、内容ベースの検知が要る。ここは手口4（スポンジ）と手口2・3（増幅）を直接叩く層だ。
1. スポンジ入力の検知
入力段で、トークン数に対する文字数比の異常・無意味Unicodeや制御文字の連なり・極端な多言語混在・反復パターンをスコアリングし、閾値超過を降格または拒否する。推論中は、「トークンあたりの処理時間・メモリ使用の異常上昇」を監視し、単位コストが跳ね上がったジョブを早期に打ち切る。出力長ではなく計算コストを見張るのがスポンジ対策の勘所だ。
2. 増幅ループの遮断（RAG・エージェント）
RAGでは、検索ヒット件数・詰め込みチャンク数・再ランキング対象数に上限を課し、「広すぎるクエリ」によるコンテキスト爆発を抑える。エージェントでは、同一・類似のツール呼び出しが短時間に反復したらループ検知で打ち切る。手口3の検索増幅は、検索段の上限と結果キャッシュの併用で、コストの二重・三重取りを防げる。
3. 段階的レスポンス（観測→警告→緩和→遮断）
検知は即遮断だけが正解ではない。正規ユーザーの誤検知を避けるため、条件に応じて段階的に対応する。
| 段階 | 条件の例 | レスポンス |
|---|---|---|
| 観測 | コスト分布がやや高め | ログ強化・タグ付けのみ（利用は継続） |
| 警告 | ソフトクォータ超過／異常スコア上昇 | ユーザーへ通知・レート緩やかに低下 |
| 緩和 | max_tokens飽和が連続／同時実行超過 | 出力上限を圧縮・低コストモデルへ降格・キューイング |
| 遮断 | ハードクォータ超過／明確なスポンジ・ループ | 当該キー／テナントを一時遮断し監査へ回送 |
コスト×セキュリティの交差点——AI FinOps・可視化ダッシュボードとの連携
DoW対策は、セキュリティ単独では完結しない。「いくら焼けているか」をリアルタイムで見える化できて初めて、上のクォータや閾値を正しく設定・運用できる。ここが本記事を、貴サイトのセキュリティ系記事とコスト系記事の交差点に置く理由だ。
攻撃検知の一次シグナル（テナント別トークン消費、1リクエストあたりコスト分布、内部呼び出し数）は、そのままコスト可視化ダッシュボードで監視すべきメトリクスと重なる。異常なコスト急増は、財務イベントであると同時にセキュリティイベントでもある。AI FinOpsの予算アラート・単価最適化の枠組みに「枯渇攻撃の検知条件」を組み込み、財務チームとセキュリティチームが同じダッシュボードを見る体制にすることで、月末の請求書で初めて気づく事態を防げる。
関連する脅威との棲み分けも押さえておきたい。自社エージェントの内部暴走を止めるのがキルスイッチ／サーキットブレーカー、正規アカウント乗っ取りによる推論のタダ乗りがLLMjacking。本記事のDoWはその中間——正規の入口に、正規に見えて意図的に高コストな入力を送りつける攻撃に位置する。三者を並べて設計することで、コストを起点とした脅威を面で塞げる。
検知→遮断→監査のインシデント連携
検知して遮断したら終わり、ではない。DoWは反復・進化するため、証拠を残し、閾値を鍛え直すループが要る。遮断イベントは、対象キー／テナント・入力の特徴（スポンジスコア、反復パターン）・消費トークンと推定金額・発火した閾値をひとまとまりで監査ログに残す。この記録が、正規ユーザーの誤検知を切り分け、クォータと閾値を継続的にチューニングする材料になる。
運用面では、コスト急増アラートを課金の実額に紐づけてオンコールに飛ばし、一定額を超えたテナントは自動でソフト降格→要調査キューへ、という自動化を組む。財務の予算アラートとセキュリティのインシデント対応を、同じトリガー・同じダッシュボードで動かすのが、DoW時代のインシデント連携の形だ。
多層防御チェックリスト
| 層 | 対策 | 主に効く手口 |
|---|---|---|
| 入口 | 入力・出力・合計トークンのハード上限、コンテキスト長上限、最小公開原則 | 手口1（高コストクエリ） |
| 入口 | プリフライトのコスト見積り（実行前拒否／降格） | 手口1・3 |
| 入口 | エージェントの最大ステップ・ツール回数・時間・累積トークン上限 | 手口2（反射ループ） |
| 流量 | コスト建てレート制限（トークン／金額のトークンバケット） | 手口1・2・4 |
| 流量 | 同時実行上限・キュー制御・強制タイムアウト | 手口4（スポンジ） |
| 流量 | テナント別クォータ（ハード＝遮断／ソフト＝警告）、匿名・無料枠の厳格化 | 全手口（ブラスト半径分離） |
| 内容 | スポンジ入力検知（文字/トークン比・Unicode異常・反復） | 手口4 |
| 内容 | RAGの検索件数・チャンク上限、エージェントのループ検知 | 手口2・3 |
| 運用 | コスト可視化ダッシュボードと予算アラートの連携（FinOps×セキュリティ） | 全手口（早期検知） |
| 運用 | 遮断イベントの監査ログ化と閾値の継続チューニング | 全手口（再発防止） |
よくある質問（Q&A）
Q1. DoWと従来のDDoSは何が違うのですか。
DDoSはサービスを止めて可用性を奪う攻撃で、防御指標は「落ちないこと」です。DoW（Denial of Wallet）はサービスを止めず、正常に応答させたまま従量課金を膨らませる攻撃で、守る対象は請求書です。監視のエラー率が上がらないまま被害が進む点が最大の違いで、コスト分布の監視が不可欠になります。
Q2. レート制限（1分◯回）を厳しくすれば防げませんか。
回数ベースのレート制限だけでは不十分です。1発で上限まで焼く高コストクエリやスポンジ入力は少ない回数ですり抜け、逆に厳しくしすぎると正規のパワーユーザーを巻き込みます。「回数」ではなく「単位時間あたりの消費トークン／推定金額」で絞る、コスト建てのレート制限に切り替えるのが有効です。
Q3. スポンジ入力はトークン上限で止められますか。
完全には止められません。スポンジ入力は「同じトークン数でも計算コストが跳ね上がる」ことを狙うため、トークン上限やレート制限をすり抜けてGPU占有時間（キャパ）を枯らします。トークンあたりの処理時間・メモリの異常を監視し、単位コストが急上昇したジョブを早期に打ち切る内容ベースの検知が必要です。
Q4. マルチテナントSaaSで最優先の対策はどれですか。
テナント別クォータによるブラスト半径の分離です。1テナントが攻撃を受けても被害と請求増をその枠内に閉じ込められます。ハード上限（遮断）とソフト上限（警告・降格）の二段で持ち、無料枠・トライアル・匿名アクセスにはより厳しいクォータを課すのが基本形です。
Q5. コスト管理（FinOps）とセキュリティのどちらの担当ですか。
両方です。DoWは財務イベントであると同時にセキュリティイベントであり、同じシグナル（テナント別トークン消費、リクエスト単価分布、内部呼び出し数）で検知できます。コスト可視化ダッシュボードと予算アラートに枯渇攻撃の検知条件を組み込み、財務とセキュリティが同じ画面を見る体制にするのが理想です。
まとめ——「止まらないまま財布が枯れる」を前提に設計する
Denial of Wallet／Unbounded Consumptionは、サービスを落とさずに請求書だけを膨らませる、従量課金時代に固有の攻撃だ。攻撃者は正規の入口から、正規に見える高コストな入力を送り込む。だからこそ守りは、単一のレート制限ではなく入口（トークン予算上限・複雑度制限）→流量（コスト建てレート・同時実行遮断・テナント別クォータ）→内容（スポンジ検知・ループ遮断）→運用（コスト可視化との連携・監査）という多層で組む必要がある。
鍵は、セキュリティとコスト管理を分けないことだ。「いくら焼けているか」を見える化し、その同じ物差しで攻撃を検知する。可用性ではなく請求書を守る——この前提の転換ができたとき、DoWは「月末に気づく事故」から「設計で封じ込める既知の脅威」に変わる。
参考リンク・関連記事
- OWASP Top 10 for LLM Applications（2025）— LLM10:2025 Unbounded Consumption
- MITRE ATLAS — Cost Harvesting / LLM Denial of Service 系テクニック
- 関連記事：AIエージェントのコスト可視化ダッシュボード構築ガイド
- 関連記事：AI FinOps 連載⑪（予算アラート・単価最適化）
- 関連記事：自律エージェントのキルスイッチ／サーキットブレーカー設計
- 関連記事：LLMjacking——正規アカウント乗っ取りによる推論のタダ乗り対策
※本記事は一般的な情報提供を目的としたものであり、特定のセキュリティ対策や法的判断を保証するものではありません。実装にあたっては、自社の要件に即してセキュリティ専門家・法務の助言を得たうえでご判断ください。
コメント