トークントラップとは？AIエージェントの隠れたコスト爆発を防ぐ消費管理の実践

トークントラップとは、AIエージェントがトークンを過剰消費することで、LLM の従量課金コストが制御不能に膨張する罠のことです。クラウド LLM のレート上限（1 分あたりに処理できるトークン数など）は非常に大きく設定されていることが多く、上限が大きいほど意図しない大量消費が見えにくくなります。エージェントループの停止条件が曖昧だったり、コンテキストウィンドウに不要な情報を積み上げたりするだけで、請求額が想定の数十倍に達するケースが報告されています。

本記事は、LLM を活用したシステムの開発・運用担当者を主な対象としています。コスト爆発が起きるメカニズムを理解したうえで、バジェット上限の設定・スロットリング・ループ設計の見直しといった実践的な消費管理の手順を解説します。

結論: LLM API はトークン消費量に応じた従量課金であり、エージェント設計の盲点がコスト爆発を招く。

LLM（大規模言語モデル）の API は入力・出力それぞれのトークン数で課金されます。エージェントが複数ステップを繰り返す中で、コンテキストの肥大化やツール呼び出し結果の積み重ねにより、1 タスクで想定の数倍のトークンを消費するリスクがあります。

LLM の API 利用料は「トークン単位の従量課金」で計算されます。トークンとは、テキストを BPE トークナイザー（Byte-Pair Encoding Tokenizer）が分割した最小単位であり、英語では 1 トークン≒4 文字・0.75 単語、日本語では 1 文字が 1〜2 トークン相当になる傾向があります。

課金の基本構造は次の 3 要素で成り立っています。

• 入力トークン: プロンプト・システムプロンプト・会話履歴の合計
• 出力トークン: モデルが生成したテキストの長さ
• レート制限: RPM・TPM・TPD など複数の軸で上限が設定され、超過時は 429 エラーが返る

最初は「出力が短ければコストは安い」と考えがちですが、実際は入力トークンの積み上がりがコスト爆発の主因になるケースが多いです。会話履歴や検索結果をそのままコンテキストに詰め込むと、1 回の呼び出しで数千〜数万トークンに達し、呼び出し回数が増えるほど費用が乗算的に膨らみます。

料金水準はモデルやプロバイダーによって異なりますが、多くのモデルでは出力トークンの単価が入力トークンの数倍に設定されています。そのため、長文生成を繰り返すエージェントでは出力側のコストも無視できません。最新の単価は、利用するモデルの公式料金表で必ず確認してください。

会話ターン数が増えるほど、コンテキストウィンドウ（Context Window）は際限なく膨らんでいきます。多くの API 実装では過去の全メッセージ履歴をそのまま次のリクエストに連結するため、1 ターンあたりのトークン数がターンを重ねるごとに累積していく構造になっています。

肥大化が連鎖するメカニズム

• 1 ターン目: システムプロンプト（System Prompt）＋ユーザー入力 ＝ 数百トークン
• 5 ターン目: 上記 ＋ 過去 4 往復の全文 ＝ 数千トークン
• 20 ターン目: ツール呼び出し結果・中間出力も蓄積し、数万トークンに達するケースがある

多くのモデルにはデフォルトの最大出力トークン数が設定されており、長い会話履歴を丸ごと渡すと出力に使える余白が急速に圧迫されます。出力上限はパラメータで調整できる場合もありますが、入力側はレート制限（TPM など）が非常に大きく設定されていることが多く、上限が大きいほど意図せず大量消費が起きやすい点に注意が必要です。

コンテキストが上限に近づくと、モデルは重要な前提情報を「見失う」ハルシネーション（Hallucination）リスクも高まります。

コストへの直撃

入力・出力トークンはいずれも課金対象です。会話履歴を全量引き回す設計では、同じ質問に対する回答コストがターンを重ねるごとに増加します。

「エージェントを複数組み合わせれば、単体より賢く動くはず」——そう期待して設計したマルチエージェントシステムが、想定外の請求額を叩き出す現場は少なくありません。

マルチエージェントシステムでは、トークン消費が単純に「エージェント数 × 単体消費量」に留まりません。エージェント間でメッセージをやり取りするたびに、それぞれのコンテキストウィンドウ（Context Window）に会話履歴が蓄積されるため、消費量は乗算的に膨張する傾向があります。

増幅が起きる主な経路は以下の通りです。

• オーケストレーター → サブエージェントへの指示転送: 親エージェントが持つ全コンテキストをそのままサブエージェントに渡すと、同じ情報が複数エージェントのプロンプトに重複して積み上がります
• A2A（Agent-to-Agent Protocol）経由の中間結果共有: エージェント同士が中間出力を互いに参照し合うループが形成されると、1 回のタスク完了までの API 呼び出し回数が急増します
• 並列実行時の重複コンテキスト: 同一のシステムプロンプト（System Prompt）や RAG 検索結果を複数エージェントが個別に保持するため、重複トークンが静かに積み重なります

プラットフォーム側の上限設定にも注意が必要です。クラウド LLM ではレート制限が TPM（Tokens Per Minute）単位で管理され、その上限は非常に大きく設定されていることが多いため、重複コンテキストによる消費増が見過ごされやすくなります。

**結論: AIエージェントのトークン過剰消費は、設計上の構造的な問題から生じます。**停止条件のないループ、CoT（思考連鎖）推論の内部展開、RAG によるコンテキスト肥大化という三つの要因が重なり、意図せずコストが膨らみます。各メカニズムを順に整理します。

「エージェントに自律的にタスクをこなさせれば、あとは放置でよい」と考えがちですが、実際は停止条件を明示しないと際限なくループが回り続け、請求額が想定の数十倍に膨らむリスクがあります。

これが「無制限リソース消費（Unbounded Consumption）」と呼ばれる状態です。AIエージェントは目標を達成するまで自律的にツール呼び出しや LLM への問い合わせを繰り返します。停止条件が曖昧なまま設計されると、以下のような連鎖が起きます。

• エージェントが「まだ十分な情報がない」と判断し、追加の検索・要約を繰り返す
• 各ステップの出力が次のステップの入力に積み上がり、コンテキストウィンドウが肥大化する
• トークン数が増えるほど 1 回の API コストが上昇し、ループ回数と掛け算で膨張する

典型的な失敗例として、ウェブ調査エージェントに「競合他社をすべて調べてレポートを作れ」と指示した場合が挙げられます。終了基準が「すべて」という曖昧な言葉に依存しているため、エージェントは際限なく検索を続けることがあります。クラウド LLM のレート上限は非常に大きく設定されていることが多く、上限が大きいほど暴走ループによる大量消費が見えにくくなる点に注意が必要です。

対処の要点は次の 3 点です。

CoT（思考連鎖）や推論モデル（Reasoning Model）は、回答精度を高める一方で、思考プロセス自体がトークンとして課金対象になるという見落とされがちなコスト構造を持っています。

通常のプロンプト呼び出しでは入力と出力のトークン数が課金の基本単位ですが、推論モデルでは「考えるための中間ステップ」が大量の出力トークンを生成します。複雑な数学的推論や多段階の計画立案を依頼した場合、思考トークンが最終回答の数倍に達するケースが報告されています。

タスクの性質によって、適切なモデル選択は大きく異なります。

• 単純な分類・要約タスクの場合: 推論モデルよりも標準モデルのほうがコスト効率が高い傾向があります
• 複雑な多段階推論が必要なタスクの場合: 推論モデルの精度向上がリトライ回数の削減につながり、結果的にコストを抑えられることもあります

エージェントループ内で推論モデルを呼び出す場合は特に注意が必要です。ループが 10 回繰り返されるだけで、1 回あたりの思考トークンが増幅され、請求額に直結します。

RAG（Retrieval-Augmented Generation）を導入したとたん、「なぜかトークン消費量が想定の倍以上になっている」と気づく現場は少なくありません。

RAG のトークンコストは、検索結果をそのままコンテキストウィンドウ（Context Window）に詰め込む構造から生まれます。典型的な流れは以下のとおりです。

• ユーザーの質問をエンベディングに変換してベクトルデータベースを検索
• 上位 K 件のチャンクをシステムプロンプト（System Prompt）に連結
• 連結されたプロンプト全体を LLM（大規模言語モデル）に送信

問題は「上位 K 件」の設定です。K=5 でチャンクサイズが 512 トークンなら、検索結果だけで 2,560 トークンが毎回消費されます。これに元のシステムプロンプトや会話履歴が加わると、1 リクエストあたりのトークン数は容易に 5,000〜8,000 トークンを超えます。

エンベディング生成のコストも見落とされがちです。クエリごとのリアルタイムエンベディング生成を無制限に走らせると、本体の推論コストとは別のトークン消費が積み重なります。

削減の要点は次の 3 点です。

トークン削減の施策を講じる前に、「今どれだけ消費しているか」を正確に把握することが不可欠です。クラウド LLM のレート上限は非常に大きく設定されていることが多く、上限の大きさゆえに過剰消費が見えにくくなるため、まずは計測環境を整えることが出発点になります。

最初は「ログを後から見ればわかる」と考えがちですが、実際にはリアルタイムのトークン消費可視化ツールを先に整備しておくほうが、コスト爆発の早期検知に効果的です。

AIオブザーバビリティ（AI Observability）ツールは、LLM への各リクエストで消費されたトークン数・レイテンシ・コストを自動集計し、ダッシュボードで確認できる仕組みを提供します。代表的な選定基準は以下の通りです。

• マルチモデル対応: 複数のプロバイダーを横断して計測できるか
• エージェントループの追跡: マルチステップ推論やマルチエージェントシステムの連鎖呼び出しをトレース ID で紐づけられるか
• アラート連携: トークン消費が閾値を超えた際に Slack 等へ通知を飛ばせるか
• コスト換算の自動化: トークン数を料金単価に自動換算し、日次・月次のコスト推移を可視化できるか

なお、クラウド LLM のレート上限は非常に大きく設定されていることが多く、上限が大きいほど意図せず大量消費が起きやすいため、オブザーバビリティツールによる常時監視が不可欠です。

導入手順としては、まず SDK やミドルウェアレイヤーにトレーシングライブラリを組み込み、各 API 呼び出しにスパン（span）を付与します。

ベースラインの計測は、「何もしていない状態でどれだけトークンを消費するか」を数値で把握することから始まります。この基準値がなければ、後述するアラートやスロットリングの閾値を適切に設定できません。

計測の手順は以下の通りです。

• 代表的なユースケースを 3〜5 パターン選定する: チャット応答・RAG 検索・ツール呼び出しなど、実運用で頻繁に発生するフローを対象にします
• 入力トークン・出力トークン・合計トークンを分離して記録する: 入力と出力の比率は最適化の方向性を決める重要な指標です
• 1 リクエストあたりの平均・最大・P95 値を算出する: 外れ値に引っ張られないよう、パーセンタイル値で評価します
• 日次・週次の累積消費量をグラフ化する: 単発の計測ではなく時系列での変動を把握することが目的です

計測ツールの選択には条件分岐があります。単一モデルのクラウド API を利用している場合は、API レスポンスの usage フィールド（prompt_tokens・completion_tokens）を直接ログに記録するのが最短経路です。一方、複数モデルを横断するマルチエージェントシステムの場合は、AIオブザーバビリティ（AI Observability）ツールを経由して一元集計するほうが管理コストを抑えられます。

クラウド LLM を利用している場合は、TPM（Tokens Per Minute）などレート上限の設定値も併せて確認しておくと、計測の前提が明確になります。

「アラートを設定したつもりが、気づいたときには月次予算の大半を消費していた」という経験は、エージェント開発の現場でよく聞かれます。計測環境が整ったら、次は実際に歯止めをかける仕組みを実装しましょう。

コスト上限アラートとスロットリング（Throttling）は、トークントラップへの最初の防衛線です。設定すべき項目は大きく三つに分かれます。

① クラウド側の予算アラート

Google Cloud Budgets ではデフォルトで予算の 50%・90%・100% 到達時にアラートが発火します。閾値は任意に変更可能なため、エージェント用途では低めに設定しておくと異常検知が早まります。

② API レート制限の活用

OpenAI API では TPM（tokens per minute）・TPD（tokens per day）単位でレート制限を設けており、上限超過時は HTTP 429 が返ります。Azure OpenAI ではモデルごとにデフォルトの出力上限が設定されていますが、入力側は TPM で別途管理されます。上限が大きいほど意図せず大量消費が起きやすくなる点に注意が必要です（具体的なクォータ値はご利用のリージョン・モデル・デプロイ設定により異なるため、自社環境での確認が必要です）。デプロイ単位で TPM クォータを意図的に絞ることで、暴走ループへの安全弁として機能させられます。

結論: トークン消費削減は、プロンプト圧縮・コンテキスト最適化・モデル分離の 3 ステップで体系的に進めることが効果的です。

計測で把握したボトルネックに対し、入力側・検索側・モデル選択の順に手を打ちます。各ステップは独立して適用できるため、優先度の高い箇所から着手できます。

「詳しく説明すれば精度が上がる」と考えてプロンプトを長くしがちですが、実際は不要な情報を削ぎ落とした簡潔なプロンプトのほうが、コストと品質の両面で優れた結果をもたらすケースが多く報告されています。

入力トークンの削減は、最も即効性の高いコスト対策です。以下の観点から見直しを進めてください。

• 冗長な前置きを排除する: 「あなたは優秀なアシスタントです」のような定型文は、タスク遂行に寄与しないトークンを消費します。システムプロンプトは役割定義と制約条件だけに絞り込みます
• Few-shot 例を最小化する: 例示は品質向上に有効ですが、1 例あたりのトークン消費は見落とされがちです。Zero-shot で対応できるタスクに例示を追加するのは避けましょう
• 構造化フォーマットで冗長表現を置き換える: 長文の説明より、JSON や箇条書きで情報を渡すほうがトークン効率が高くなります
• 動的な変数部分だけを差し替える設計にする: テンプレート化したプロンプトの固定部分を短くし、実行時に注入する変数のみを変化させます

モデル選択の観点も重要です。クラウド LLM のレート上限は非常に大きく設定されていることが多く、高い上限を持つモデルほど、プロンプト圧縮を徹底しないと意図せぬ大量消費につながります。

RAG パイプラインでは、チャンクサイズの設定がトークン消費量に直結します。チャンクが大きすぎると不要な文脈まで LLM に渡り、小さすぎると意味が分断されて検索精度が落ちる——この二律背反を解消するのがコンテキスト・エンジニアリングの核心です。

チャンクサイズの判断軸はタスクの性質によって異なります。 事実参照型のクエリ（FAQ・仕様書検索など）には小チャンクが適しており、必要な箇所だけを抽出してコンテキストウィンドウへの流入を絞れます。一方、文書要約や長文推論が必要なタスクには大チャンクが向いていますが、その分リトリーバルの件数を絞り込むことでバランスを取ります。

コンテキスト・エンジニアリングの観点では、取得したチャンクをそのまま連結して渡すのではなく、関連度スコアによる足切りが重要です。類似度スコアが閾値を下回るチャンクをフィルタリングするだけで、1 リクエストあたりの入力トークンを大幅に削減できるケースが報告されています。

取得チャンクの設計が甘いと、そのまま入力トークン量に直結します。クラウド LLM はレート上限が大きく設定されていることが多いため、上限に頼らず、チャンク戦略側で入力量を制御することが求められます。

また、システムプロンプトの肥大化も見落とされがちなコスト要因です。

「このタスク、毎回大規模 LLM に投げる必要があるのか？」——現場でそう感じた瞬間こそ、タスク分離を見直すサインです。

汎用 LLM はあらゆる質問に答えられる反面、単純なルーティングや分類タスクにも大きなコンテキストウィンドウを消費します。ここで有効なのが、ファインチューニング済みの SLM（Small Language Model）に特定タスクを切り出すアプローチです。

**分離の判断基準は「タスクの定型度」**です。

• 高定型タスク（感情分類・カテゴリ振り分け・短文抽出）→ SLM またはファインチューニングモデルに委譲
• 中程度の推論タスク（要約・翻訳・構造化抽出）→ 軽量モデルで対応可能なケースが多い
• 複雑な推論・創造タスク（マルチステップ計画・コード生成）→ 大規模 LLM を維持

モデル選定の際はトークン単価だけでなく、出力トークンの上限設定にも注目が必要です。多くのモデルにはデフォルトの最大出力トークン数が設定されており、エージェントループ内では各モデルの上限値を把握したうえで明示的な制限を設けることが重要です。

結論: 個別設定だけでは不十分で、アーキテクチャレベルでトークン消費を制約する設計が不可欠です。

AIガードレールとオーケストレーション設計を組み合わせることで、トークントラップを構造的に封じ込められます。予算管理・インジェクション対策・HITL（Human-in-the-Loop）の三層から実装方法を解説します。

エージェントオーケストレーション層は、複数のサブエージェントが連携するシステム全体のトークン消費を一元管理できる唯一の制御点です。

最初は「各サブエージェントが自律的にコストを調整できる」と考えがちですが、実際にはオーケストレーター側で予算を一括管理するほうが効果的です。サブエージェントは自身の消費量を俯瞰できないため、分散管理では上限超過を防ぎにくい傾向があります。

オーケストレーション層で実装すべき主な施策は以下のとおりです。

• トークン予算の事前割り当て: タスクグラフの各ノードに対して、実行前にトークン上限を設定する。残量が閾値を下回った場合はサブタスクを打ち切るか、SLM（Small Language Model）へ切り替える
• 累積消費のリアルタイム追跡: API レスポンスに含まれる使用量フィールドを集計し、セッション単位・エージェント単位の消費量をオーケストレーターが常時保持する
• スロットリングと優先度制御: 高優先タスクに予算を優先配分し、低優先タスクはキューイングまたは間引きで処理する

クラウド LLM のレート上限は非常に大きく設定されていることが多く、上限に頼った制御は機能しにくいため、オーケストレーター内にフォールバックロジックを組み込み、一定のトークン消費率に達した時点で自動的に軽量モデルへ切り替える設計が有効です。

プロンプトインジェクション（Prompt Injection）は、セキュリティリスクであると同時に、トークン消費を急増させる隠れた要因でもあります。

攻撃者が悪意ある指示を外部データに埋め込むと、エージェントはその指示を正規タスクとして処理しようとします。結果として、本来不要な追加推論・ツール呼び出し・再確認ループが発生し、トークン消費が膨らみます。レート上限が大きい環境ほど、注入攻撃による意図せぬ大量消費は見えにくくなる点に注意が必要です。

対策の選択は状況によって異なります。 外部データソース（Web 取得・ユーザー入力・データベース）を扱う場合はプロンプトファイアウォール（Prompt Firewall）と入力サニタイズを優先し、内部データのみを扱う閉じた環境では、システムプロンプト（System Prompt）の構造化と権限スコープの絞り込みが効果的です。

具体的に有効な対策は以下のとおりです。

「エージェントに任せたら、いつの間にか意図しない API を何十回も呼び出していた」という状況は、過剰エージェント権限（Excessive Agency）の典型例です。エージェントが自律的に判断できる範囲を絞らなければ、トークン消費は際限なく拡大します。

HITL（Human-in-the-Loop）は、エージェントの行動を人間が確認・承認するチェックポイントを設ける設計手法です。トークントラップの文脈では、承認なしに次のステップへ進めない「ゲート」として機能します。

配置すべき主なゲートポイント

• 高コストアクション前: 外部 API 呼び出し・大量データ取得・長文生成など、単発でトークンを大量消費する処理の直前
• ループ継続判断: エージェントが「再試行」や「追加調査」を自己判断する前に人間の承認を要求する
• 予算閾値到達時: 1 セッションのトークン消費が設定した上限の 80% に達した段階で一時停止し、継続可否を確認する

承認フローは非同期で設計するのが現実的です。Slack や Teams への通知と承認ボタンを組み合わせることで、人間の待機時間を最小化しながらゲートを維持できます。

トークントラップに陥る典型的なケースは、「観測できない」と「止まらない」の二つに集約されます。クラウド LLM のレート上限は非常に大きく設定されていることが多く、上限の大きさゆえに意図せぬ大量消費が起きやすい点にも注意が必要です。それぞれの失敗パターンと対処法を見ていきます。

「請求額は月次で確認すれば十分だ」と考えがちですが、実際にはリアルタイムのトークン消費ログがなければ、異常検知が数週間遅れることになります。月末に請求書を見て初めて問題に気づいた時点では、すでに被害が確定しています。

ログ不在が招く典型的な失敗パターンは、三つに整理できます。

• モデル別・エンドポイント別の集計なし: どのエージェントが消費しているか特定できず、原因調査に余分な時間がかかります
• 入出力トークンの未区別: 出力トークンは入力より単価が高いモデルも多く、出力量の増加を見落とすと損失が拡大しやすくなります
• エラー時の再試行ログの欠落: タイムアウトや API エラーで自動再試行が走ると、同一タスクのトークン消費が倍増しても気づけないままになります

また、多くのモデルにはデフォルトの最大出力トークン数が設定されている一方、入力側はレート上限（TPM など）が非常に大きく設定されていることが多く、上限が大きいほど意図せず大量消費が起きやすくなります。リアルタイムのログがなければ、こうした異常に気づけません。

これらに共通するのは、ログ収集を「後から追加する機能」として後回しにした設計判断です。

停止条件が曖昧なまま再帰呼び出しを実装すると、請求額が短時間で数十倍に膨れ上がるケースが報告されています。

典型的なパターンは次のとおりです。

• エージェントが「タスク未完了」と判断するたびに自身を再呼び出しする
• 各呼び出しで前のターンの出力をコンテキストに丸ごと引き継ぐ
• コンテキストウィンドウが蓄積されるにつれ、1 回あたりのトークン数が急増する

クラウド LLM のレート上限は非常に大きく設定されていることが多く、上限が大きいほど意図せず大量消費が起きやすくなります。エラーハンドリングが不十分な場合、外部 API のタイムアウトを「タスク失敗」と誤解釈したエージェントが同じリクエストを繰り返し投げ続けるケースが典型例です。ループが 10 回転するだけで、コンテキストの累積によりトークン消費量は当初の数十倍に達することがあります。

対処の判断軸は状況によって異なります。ループ回数が予測可能な場合は最大反復回数（max_iterations）をハードコードで制限するのが最も確実です。一方、動的なタスクで反復回数が不定な場合は、累積トークン数がしきい値を超えた時点で強制終了し、HITL（Human-in-the-Loop）に引き渡す設計が適切です。

再発防止のために有効な対策をまとめます。