目次
米国、カナダ・サイバーセキュリティセンター、オーストラリア・サイバーセキュリティセンターなどは、AIトークンの消費を単なる利用料金ではなく、可用性とセキュリティの問題として管理する共同ガイダンスを公表しました。対象は、外部の 、社内チャット、コーディング支援、検索・要約、複数のツールを回るを業務へ組み込む組織です。
優先すべき対応は、サービス単位・利用者単位でトークン消費を計測し、70％・80％・90％の段階的な警告を設けることです。併せて、重要業務用の枠を一般用途から分け、エージェントの反復回数と出力長を制限します。トークン上限へ達すると、正当な利用でも遅延や失敗が起きます。攻撃者が公開インターフェースや自動処理を悪用すれば、利用枠を枯渇させるdenial-of-tokensや、従量課金を膨らませるdenial-of-walletにもつながります。
スポンサーリンク
共同ガイダンスが変えたトークン管理の位置付け
カナダ・サイバーセキュリティセンターのITSM.00.125は、入力、出力、などのトークンが料金、処理能力、応答時間、サービスの継続性に影響すると整理しています。カナダ側の掲載日は2026年10月22日で、オーストラリア側の共同ガイダンスは10月23日付です。
従来の費用管理では、請求額が予算を超えないかが中心でした。今回の資料は、割当量、クォータ、、予算上限の到達によってAI依存の機能が使えなくなることを「トークン枯渇」として扱います。正当な需要の急増、設計の悪いアプリケーション、予想外の処理量でも発生するため、枯渇したという事実だけで攻撃と断定はできません。それでも、可用性に影響する共有資源として監視する必要があります。
誰が何を悪用できるのか
denial-of-tokensは、攻撃者が過剰なAI利用を意図的に発生させ、組織の割当量やレート制限を消費する資源枯渇攻撃です。共同ガイダンスは、公開されたAIインターフェースやツールへの自動リクエスト、異常に大きなデータを処理させるワークフローの操作を例に挙げています。枠を使い切れば、正規利用者の要求が遅延・失敗し、対応や調査など重要な作業もAI機能へ到達できなくなります。
denial-of-walletは、同じ従量課金の仕組みを金銭的な被害へ向ける攻撃です。複雑な入力から長い出力を繰り返させたり、出力を次の入力へ戻すループを作らせたりすると、少数の開始要求が多数のモデル呼び出しへ増幅されます。エージェントが検索、ブラウザー、コード実行、別のモデルを呼ぶ構成では、モデルのトークンだけでなく、外部API、実行時間、ログ保存の費用も連鎖します。
影響条件は「AIを使っている」だけではありません。認証なし、または弱い利用制限で外部から呼べる入口があること、利用者ごとの上限が共有枠から分離されていないこと、エージェントの最大反復回数や停止条件がないこと、長い会話履歴やツール出力を毎回送り直すことが重なるほど、攻撃や事故の増幅率が高くなります。無料機能でも、背後で組織の有料を使っていれば、利用者側の表示と運用側の費用が一致しません。
スポンサーリンク
70・80・90％の警告を実装する
共同ガイダンスは、組織が決めたトークン上限に対し、70％で情報、80％で警告、90％で重大という段階的な通知例を示しています。これは全サービスへ同じ固定値を適用する義務ではありません。請求周期、補充の方法、プロバイダーのレート制限、通常時の変動を踏まえ、自社の復旧時間に間に合う位置へ置くための出発点です。
Webアプリでは、月間累計だけでなく、短時間の消費速度も監視します。月の70％に達していなくても、10分間のtokens per minuteが平常値を大きく超えれば、数時間で枯渇する可能性があります。最低限、入力・出力トークン、キャッシュ利用量、モデル名、利用者またはサービスID、API、要求回数、失敗と再試行、エージェントのステップ数を同じ時系列で追えるようにします。
異常なトークン増加は、データ流出の兆候になり得ると資料は指摘しています。大量の文書をモデルへ送る処理では入力トークンが増えるためです。ただし、増加だけで流出を確定してはいけません。、バッチ開始、利用者ID、、APIアクセス、外向き通信を相関し、正規の大量処理か、認証情報の悪用か、エージェントの暴走かを切り分けます。トークンのテレメトリをSIEMへ送り、既存の・クラウド・システムログと結び付ける提案は、この調査を可能にするためです。
重要業務の枠を一般用途から分ける
資料は、利用量を業務影響に応じた3層へ分ける方法を示しています。共有の一つの残高を監視するだけでは、メール要約や試験中のエージェントが、障害対応用の枠まで消費します。実装では、プロジェクト、APIキー、ゲートウェイのルーティング規則、予算、クォータのいずれかで分離し、優先度を実際の強制点へ落とします。
| 層 | 共同ガイダンスの例 | Web開発・運用での扱い |
|---|---|---|
| Tier 1 | サイバー防御、インシデント対応、脅威インテリジェンス | 専用枠を確保し、一般用途から消費できないようにする |
| Tier 2 | コンプライアンス、政策分析などの業務処理 | 上限と遅延許容時間を決め、枯渇時はキューへ退避する |
| Tier 3 | メール作成、会議要約、一般調査 | 需要集中時に制限・延期できる構成にする |
優先順位はモデルの賢さではなく、業務停止時の影響で決めます。本番障害のログ要約はTier 1でも、同じモデルを使う日常の文章作成はTier 3です。APIキーを部署ごとに分けただけで、背後の契約上限が共通なら完全な隔離にはなりません。プロバイダー側の組織上限、プロジェクト別制限、自社ゲートウェイの制限がどの順で効くかを確認します。
スポンサーリンク
エージェントの増幅を入口と実行側の両方で止める
公開APIの入口では、認証、利用者単位のレート制限、要求サイズの上限、同時実行数、日次予算を設定します。しかし入口で一件を許可した後、エージェントが内部で50回モデルを呼ぶなら、要求数だけでは消費を制御できません。実行側で最大ステップ数、最大ツール呼び出し数、累積入力・出力トークン、経過時間、再試行回数を上限として持たせます。
停止条件は、自然言語の「長くなりすぎたら止める」ではなく、オーケストレーターやゲートウェイが強制する値にします。上限へ近づいたときは、まず追加ツール呼び出しを止め、途中結果と未完了項目を返し、人間の再承認を求めます。モデル自身に継続可否を決めさせると、同じ異常な入力や誤った計画が停止判断にも影響します。
消費量を下げる設計も防御になります。必要な文書の抜粋だけを渡す、重複データを前処理で除く、静的な指示や参照情報をキャッシュしやすい位置へ置く、出力長を制限する、単純な分類は小さなモデルへ振り分ける、といった方法です。ただし、要約やフィルタリングの追加処理が機密情報を別のサービスへ送る場合は、費用削減だけで採用せず、プライバシーとデータ保護も確認します。
枯渇時にAIなしで続ける経路を残す
共同ガイダンスは、プロバイダー障害や高需要時に別の提供元へ経路を切り替える構成と、AIを使わない手作業や従来の自動化を維持することを勧めています。複数プロバイダー化は有効ですが、モデルごとの出力形式、ツール呼び出し、データ保持、地域、評価結果が違うため、切替先を登録しただけでは復旧手段になりません。
定期的に、Tier 1の処理だけを残してTier 3を制限できるか、主系のAI APIを停止して代替モデルへ切り替えられるか、代替モデルが要件を満たさない場合に人手や既存ルールへ戻せるかを試します。フェイルオーバー時にも、権限、入力データ、ログ、費用上限を主系と同じ水準で管理します。緊急時だけ無制限のAPIキーを使う手順は、攻撃や誤操作による消費をさらに増やします。
警告後の対応を自動遮断と調査に分ける
段階警告は、通知を増やすだけでは役に立ちません。70％では担当者が利用内訳と月末までの予測を確認し、正当な増加なら予約処理や低優先度のジョブを調整します。80％ではTier 3の新規処理、長い出力、試験用バッチを制限し、原因となる利用者・サービス・モデルを特定します。90％では、事前に決めた重要業務以外を止め、追加予算や上限解除を一人の判断で行わない運用へ移します。
同時に、攻撃の可能性を調査します。APIキーの新規利用元、通常と異なるIPや地域、認証失敗の増加、同じ入力の連続送信、出力を入力へ戻す反復、急増直前のデプロイを確認します。公開APIを止めると正規利用者にも影響するため、まず利用者単位の遮断、対象機能の縮退、出力上限の短縮など、影響範囲の小さい制御から適用します。認証情報の悪用が疑われる場合は、該当キーを失効し、代替キーを同じ無制限設定で再発行しないことが重要です。
復旧条件も決めておきます。消費速度が基準へ戻ったこと、原因となるループや公開入口を閉じたこと、Tier 1の残容量が確保できたことを確認してから段階的に再開します。単に請求上限を引き上げると、攻撃中の処理へ新しい容量を渡すだけになる可能性があります。
導入前と運用中に確認する項目
- どのAI機能が、割当量、クォータ、レート制限、予算上限を共有しているか。
- 公開インターフェースから一件の要求が、内部で最大何回のモデル・ツール呼び出しへ増えるか。
- 利用者、サービス、環境、業務Tierごとに消費を計測・制限できるか。
- 70％・80％・90％などの警告が、対応できる担当者と運用手順へ結び付いているか。
- 異常増加を、認証、API、クラウド、デプロイのログと相関できるか。
- エージェントの反復、出力、再試行、同時実行をモデル外で強制停止できるか。
- 重要業務の枠が一般用途から分離され、枯渇時の代替経路を実際に試しているか。
この資料は特定の侵害や悪用確認を報告したものではなく、修正版へ更新すれば完了する脆弱性情報でもありません。読者が行う判断は、トークンを請求書の項目だけで終わらせず、容量、可用性、攻撃検知の共通指標へ変えることです。公開入口の制限、実行側の停止、優先度別の割当、代替経路を組み合わせれば、正常な需要増と攻撃のどちらでも、重要なWebサービスを先に守れます。
スポンサーリンク
参考資料
- Canadian Centre for Cyber Security：Managing AI token consumption for operational resilience - ITSM.00.125
- Australian Cyber Security Centre：Managing AI token consumption for operational resilience
