AIエージェントがトークンを浪費する理由(そして請求額を抑える方法)
チャットの1ターンはわずか1セントの何分の一かで済む。同じ質問をエージェントに渡す — ファイルを読み、ツールを呼び、完了するまでループするエージェントに — と、コストは数ドルに跳ね上がる。チームはこれを痛い形で学びつつある。コーディングエージェントを走らせっぱなしにすると、キーボードの前に座った人間なら決してしないような請求額が積み上がる。恐ろしいのは平均値ではない。事前に予測できないこと、そして同じタスクのコストが大きく振れることだ。
このページでは、エージェントがなぜトークンを浪費するのか(そのメカニズムはほとんどの人の予想と違う)を説明し、経験豊富なビルダーですら驚く数字を示し、請求額を実際に削減する4つのレバーを紹介する — Claude Code、Cursor、Codex、あるいはどんなモデル上の自作ループであっても同じレバーだ。
- コンテキストの雪だるま式増加を説明する — なぜエージェントのコストがステップ数に対して線形ではなくおおよそ二次関数的に増えるのか
- 実際の倍率を挙げる:エージェントタスクはチャットの約1000倍のトークン、そして同じタスクでも最大30倍の変動
- 2つ目のエージェントが割に合うのはいつか — そして通常は割に合わないことを示すベンチマーク
- 実際に効く4つのコストレバーを引く:予算上限、プロンプトキャッシュ、モデルティアのルーティング、コンテキストの剪定
- 暴走するエージェントの請求を診断し、ハードな上限を設定する
コンテキストの雪だるま式増加:なぜコストは二次関数的に増えるのか
ここに罠がある。チャットは1ターン — 1つの入力、1つの出力、それで終わりだ。エージェントはループである。タスクを読み、アクションを取り、結果を読み、次のアクションを取る、これを仕事が終わるまで繰り返す。厄介なのは、各ステップで、モデルがそれまでに蓄積された会話全体を読み直すことだ — 元のプロンプト、それまでのすべてのアクション、すべてのツール結果を、次に何をするか決める前に。
だから入力は各ステップで大きくなり、雪だるまが転がるたびにその全体を再び支払う:
- ステップ1はプロンプトを処理する。
- ステップ2はプロンプト + ステップ1のアクション + 結果を読み直す。
- ステップ3は そのすべて + ステップ2のアクション + 結果を読み直す。
- …と続く。
実行全体で入力を合計すると、総量はステップ数に対して線形ではなく、おおよそステップ数の二乗でスケールする。Stanford Digital Economy Labは、エージェントタスクが*「独特に高コストで、コードの推論やコードチャットの1000倍のトークンを消費する」*ことを発見した — そして重要なのは、支配的なのは入力トークンであって出力ではない、という点だ。エージェントは多く書いているのではなく、多く読み直しているのだ。
- コストの原動力は思考ではなく再読み込みだ。各ループステップは全トランスクリプトを再処理するので、20ステップの実行は初期コンテキストに対して約20回分を支払う。
- だから「エージェントに任せて考えさせればいい」は高くつく。エージェントが取る余計なステップ1つひとつが、それ以前のすべてに対して掛け算される。
- 出力重視のタスク(エッセイを書いて)は比較すると安い。入力重視のループ(このリポジトリを探索して、それからバグを直して)こそがお金の出ていく場所だ。
人々を驚かせる数字
3つの数字がほとんどの人の直感をリセットする:
- 約1000倍。 エージェントタスクは、同等のチャットやコード補完のおよそ千倍のトークンを消費しうる。Stanfordの分析による — 大きなモデルのせいではなく、上記の雪だるま式増加によって駆動される。
- 同じタスクで最大30倍のばらつき。 同じエージェントを同じタスクで走らせても、ある回は別の回より最大30倍高くつくことがある — 取る経路(何回ツールを呼ぶか、どこまでさまようか)が非決定的だからだ。実行が終わるまで請求額は本当にわからない。だからエージェントの「成果ベースの価格設定」は非常に難しい。コストが見えるのはすべてが実行された後だけなのだ。
- エージェントを増やしても元が取れることはめったにない。 2026年の本番ベンチマークは、マルチエージェント構成が、うまく設定された単一エージェントに対して、64%のタスクで2倍のコストでわずか約2.1%の精度しか上乗せしないことを発見した。階層型スーパーバイザーのパターンはドキュメントタスクを85% → 95%の精度に押し上げた — が、単一エージェントの**$0.003に対して約$0.15/タスク**(約50倍)だった。エージェントを増やすことは、多くのお金でわずかな精度を買うことになる。
- 同じタスクが最大30倍変動するので、平均ベースの予算は必ずテール(裾)に吹き飛ばされる。平均を予算化するのではなく、上限を設けよ。
- 「念のため」エージェントを追加すると、たいてい精度が増すよりはるかに速くコストが倍増する。2つ目のエージェントに手を伸ばすのは、タスクが本当に並列で独立したサブタスクに分解できるときだけにせよ。
ツールの表面積も請求の一部だ
ループが始まる前ですら、エージェントがツールにどう到達するかがコストの下限を決める。一連のMCPサーバーを接続すると、雪だるまのすべてのステップに数万トークンのツール定義を注入しうる。多くのビルダーが直面するざっくりした比較:素のCLIコマンドは平均約200トークンだが、同等のMCP操作は32k〜82kトークンかかりうる — ツールスキーマとラッピングを数えると。その差はすべてのループステップに乗ってくる。
これはMCPが間違っているという意味ではない — 認証、マルチテナンシー、統制されたアクセスにとっては正しい選択だ。ツールの表面積は、設計時にあなたが選んだコストレバーだという意味である。AILmanacには専用の詳細解説がある:MCPトークン税が、Tool Search、遅延読み込み、コード実行という3つの修正策を扱っている。
請求額を実際に削減する4つのレバー
最適化のアドバイスは無限にあるが、数字を実質的に動かすのは4つのレバーだけだ。おおよそレバレッジの大きい順に:
- エージェントをハード停止させる、実行ごと・ユーザーごとのトークン/ドル上限を設定する。同じタスクが悪い実行では30倍高くつきうるので、天井だけがテールを縛る唯一のものだ。ほとんどのエージェントハーネスはmax-tokensやmax-stepsの制限を公開している — それを使え。これが最も重要な単一の制御だ。
- システムプロンプト、ツール定義、ハウスルールは各ループステップで再送される(雪だるま)。プロンプトキャッシュは、それら繰り返しトークンを入力レートの何分の一かで課金する。長いエージェント実行では、これがしばしば単一の最大の節約になる。キャッシュされる部分こそ、最も多く読み直される部分だからだ。
- ループ全体を1つのフロンティアモデルで走らせるな。単純作業 — ファイルの読み込み、整形、定型的なツール呼び出し — には安く速いモデル(Haikuクラス、または小さなオープンモデル)を使い、難しい推論やオーケストレーターの役割には高価なフロンティアモデルをとっておく。より安いワーカーによるオーケストレーター・ワーカー分割は、本番ベンチマークでほぼ同等の精度を保ちつつコストを40〜60%削減した。
- 雪だるまが問題なので、それを縮めよ。古いターンを圧縮し、エージェントがもう必要としないツール出力を捨て、生のトランスクリプトを持ち回る代わりに要約し、ひとつの絶えず膨らむスレッドではなくクリーンなコンテキストで新しいサブタスクを始める。取り除いたトークン1つひとつは、残るすべてのステップで支払いをやめるトークンだ。
暴走するエージェントを監査する(実行のトークン内訳を貼り付ける)
You are a cost engineer. Here is a token-usage breakdown of one agentic run (input vs output tokens per step, tool calls, model used). Diagnose where the money went, in priority order: 1. Is input or output driving cost? (Agents are almost always input-heavy.) 2. Which repeated content should be prompt-CACHED (system prompt, tools, rules)? 3. Which steps could run on a CHEAPER model without losing correctness? 4. Where is context snowballing — what can be pruned, compacted, or summarized? 5. What is a safe per-run token CAP that stops the worst tail without hurting the median run? Give me the estimated % saving per fix and the ONE change to make first.
エージェントが間違ったツールであるとき
最も安いエージェント実行は、あなたがしない実行だ。タスクが単一の、明確に指定された変換 — これを要約して、あれを分類して、これを書き直して — なら、素のチャット/補完呼び出しが、その何分の一かのコストで、雪だるまなしにやってくれる。エージェントに手を伸ばすのは、仕事が本当に変化する環境に対して、読み・決め・行動し・ループの中で再確認することを必要とするとき(リポジトリを探索する、ファイル横断でデバッグする、ブラウザを操作する)だ。厳密なステップを自分で書けるなら、それをスクリプト化せよ — 毎回モデルにそれを再導出させるために金を払うな。
Check yourself
0/3出典とさらなる読み物
- How Are AI Agents Spending Your Tokens? — Stanford Digital Economy Lab — 約1000倍の数字、再読み込み/雪だるまのメカニズム、そして同じタスクで最大30倍の変動。
- Benchmarking Multi-Agent LLM Architectures: Orchestration Patterns and Cost-Accuracy Tradeoffs (arXiv 2603.22651) — 単一 vs マルチエージェントのドルあたり精度、階層型スーパーバイザーのコスト数値。
- Uno-Orchestra: Parsimonious Agent Routing via Selective Delegation (arXiv 2605.05007) — 単純なクエリではオーケストレーションを単一の安いワーカーに畳み込む。
- Anthropic — Advanced tool use / MCP token cost — ツール定義のトークンオーバーヘッドとCLI対MCPの差(当サイトのMCPトークン税を参照)。
- AILmanacの関連記事:AIが実際にかかるコスト(プロバイダー横断) · トークン経済 · コスト計算機。