要点
AI エージェントのトークンコストは、各ステップで指示、会話履歴、ツール結果、中間状態を繰り返し処理するほど増大します。
実行レベルの予算、ツール結果のフィルタリング、コンテキストの圧縮、リトライ上限、制御された推論でトークン量を削減してください。安定した繰り返し入力にはプロンプトキャッシュを使いつつ、より安価なモデルに切り替える前にエージェントループ自体を最適化します。
本番で最も有用な指標は、完了した1回の実行全体を通じて測定する「成功タスクあたりのコスト」です。リクエスト単価や最終呼び出しのコンテキストサイズではありません。
このガイドはとくにマルチステップの AI エージェントに焦点を当てます。繰り返されるコンテキストが実行全体でどのように累積するか、最大のムダを特定する方法、最初に導入すべき制御を説明します。
はじめに
チャットボットはユーザーのメッセージごとに1回のモデル呼び出しで済むかもしれません。AI エージェントは1つのタスクを完了するまでに10回、20回、あるいはそれ以上の呼び出しを行うことがあります。
各ステップでは、指示、会話履歴、ツール結果、中間状態を再送することがあります。リトライ、推論、サブエージェントがさらに使用量を増やすため、最終的な回答が短くても大量のトークンを消費し得ます。
利用が拡大すると、これらのコストは予測しづらくなり、製品のマージンを急速に圧迫します。コスト削減には、単により安価なモデルに切り替えるのではなく、エージェントループ全体の最適化が必要です。
この記事はエージェント固有のコストに特化します。プロンプトキャッシュ、厳密な応答キャッシュ、セマンティックキャッシュ、モデルルーティング、一般的な API コスト管理についての包括的なガイドは「How to Reduce AI API Costs」を参照してください。(https://www.cometapi.com/reduce-ai-api-costs/)
なぜ AI エージェントのトークンコストは複利的に増えるのか？
マルチステップのエージェントでは、1つのタスクのコストは最終応答だけでなく、すべてのモデル呼び出しの合計です。
エージェントのトークン使用量の主な要因は次のとおりです。
| コスト源 | 原因 | 優先的に試す制御 |
|---|---|---|
| 指示の繰り返し | システムプロンプト、ツールスキーマ、ポリシー、例 | 再利用可能なプレフィックスを安定化 |
| 履歴の肥大化 | 各ステップで以前のやり取りが再送される | 状態を圧縮する／選択的に取得する |
| ツール結果 | 検索ページ、ファイル、ログ、データベースレコード | コンテキストに加える前にフィルタリング |
| 中間出力 | 計画、ステータスメッセージ、冗長なツール判断 | コンパクトな構造化出力を使用 |
| 推論トークン | 定型ステップで過剰な推論 | タスクの複雑さに推論の強度を合わせる |
| リトライ | 無効な出力、タイムアウト、ツールエラー、レート制限 | 失敗を分類しリトライ回数を上限設定 |
| サブエージェント | ワーカーがコンテキスト・ツール・分析を重複 | 各ワーカーに絞り込んだコンテキストを送る |
請求を減らす方法は2つあります。
- フィルタリング、圧縮、出力制限、ループ制御によって処理するトークンを減らす。
- プロンプトキャッシュやモデル選択で必要トークンの実効価格を下げる。
重要な違い：プロンプトキャッシュは繰り返し入力のコストを下げます。コンテキスト圧縮は、その繰り返し入力そのものを減らします。
12ステップのエージェントがどうして 147,000 トークンを処理するのか？
次のような仮想のサポートエージェントを考えます。
- 4,000 トークンの安定したプレフィックス
- 各ステップ後に 1,500 トークンの新規追加
- すべてのリクエストに累積履歴を完全に再送
- 合計 12 回のモデル呼び出し
ステップ n での入力は次のとおりです。
Input at step n = 4,000 + 1,500 × (n - 1)
12回の呼び出しにわたる累積入力は次のとおりです。
Total input
= 4,000 × 12 + 1,500 × (0 + 1 + ... + 11)
= 48,000 + 99,000
= 147,000 input tokens
最終呼び出しの入力は 20,500 トークンにすぎませんが、実行全体では 147,000 トークンの累積入力を処理しています。
ここで2つの制御を適用します：
- 最初の呼び出し後に、安定した 4,000 トークンのプレフィックスをキャッシュする。
- 6ステップ目以降の履歴を 2,500 トークンの状態サマリーに圧縮する。
| シナリオ | 非キャッシュ入力 | キャッシュ入力 | 処理済み入力合計 | 変化 |
|---|---|---|---|---|
| 毎ステップで全履歴を送信 | 147,000 | 0 | 147,000 | ベースライン |
| 安定プレフィックスをキャッシュ | 103,000 | 44,000 | 147,000 | ボリューム同等、より安価な内訳 |
| キャッシュ＋圧縮 | 64,000 | 44,000 | 108,000 | 処理トークンが26.5%削減 |
これは計画上の試算であり、プロバイダのベンチマークではありません。
各リクエストが累積履歴全体を含む前提です。古いメッセージを要約したり、関連情報のみを選択的に構築・取得するエージェントは異なるコスト曲線になる可能性があります。
コスト増加のルール： 実行全体の累積入力を測定してください。最終コンテキストのサイズは処理されたトークン総数を表しません。
どの指標がエージェントのトークンのムダを可視化するか？
モデルを変えるところから始めないでください。まず、結果を改善しないトークン消費箇所を特定します。
各エージェントステップについて、次の項目を記録します。
| 項目 | 重要な理由 |
|---|---|
run_id, step_id, parent_step_id | エージェントとサブエージェントのツリーを復元 |
| Rendered input tokens | 呼び出し間でコンテキストがどう増加したかを示す |
| Cached and uncached input | 再利用分と新規コンテキストを区別 |
| Output and reasoning tokens | 高コストな生成ステップを特定 |
| Tool result size and retained tokens | 後続プロンプトに入る生データ量を把握 |
| Retry reason and attempt number | 繰り返しの失敗を特定 |
| Compaction tokens before and after | 実際のコンテキスト削減を測定 |
| Worker ID and returned tokens | サブエージェントの重複作業を可視化 |
| Accepted, rejected, or escalated result | コストをタスク品質と結び付ける |
主指標は次のとおりです。
cost per successful task
= total workflow cost
/ accepted tasks
安価な実行でも、失敗増加、ツールの再実行、人手修正が増えるなら改善ではありません。
問題箇所を絞り込むうえで役立つエージェント固有の4つの指標があります。
コンテキスト増幅
context amplification
= cumulative input tokens
/ final-step input tokens
この値が高いほど、初期コンテキストが繰り返し処理されていることを示します。
ツール保持率
tool retention ratio
= tool-result tokens retained in context
/ tokens originally returned by tools
この比率が高い場合、過剰な生データをステップ間で持ち運んでいる可能性があります。
リトライ税
retry tax
= retry and repair cost
/ total workflow cost
推論比率
reasoning share
= reasoning-token cost
/ total model cost
ワークロードごとに個別に測定してください。リサーチ、コーディング、ブラウザ、カスタマーサポートのエージェントは共通の基準を共有すべきではありません。
AI エージェントのトークンコストを削減する6つの方法
1. 実行全体の予算を設定する
リクエスト単位の出力制限では、マルチステップのエージェントは制御できません。
次の実行レベルの上限を設定します。
- 総モデルステップ数
- 入出力トークンの累積
- ツール呼び出し回数とツール結果サイズ
- 失敗タイプごとのリトライ回数
- サブエージェント
- 総経過時間または推定コスト
次のプロバイダ非依存の Python 例では、各モデル呼び出し前に実行を評価します。
from dataclasses import dataclass
from enum import Enum
class Action(str, Enum):
CONTINUE = "continue"
COMPACT = "compact"
STOP = "stop"
@dataclass(frozen=True)
class Budget:
max_steps: int = 12
max_input_tokens: int = 120_000
max_output_tokens: int = 18_000
compact_at: float = 0.80
@dataclass
class Usage:
steps: int = 0
input_tokens: int = 0
output_tokens: int = 0
def evaluate_budget(usage: Usage, budget: Budget) -> Action:
if (
usage.steps >= budget.max_steps
or usage.input_tokens >= budget.max_input_tokens
or usage.output_tokens >= budget.max_output_tokens
):
return Action.STOP
input_ratio = usage.input_tokens / budget.max_input_tokens
if input_ratio >= budget.compact_at:
return Action.COMPACT
return Action.CONTINUE
各モデルリクエストの前にチェックを実行し、プロバイダが報告するトークンデータで Usage を更新します。
入力予算の80%に達したら状態を圧縮するか、次のツールクエリを絞ります。100%に達したら、構造化された理由とともに停止します。
よくある誤り： 各応答にだけ制限を設け、ステップ・ツール・リトライを無制限にする。
2. トランスクリプトに入る前にツール結果をフィルタリングする
次の判断に必要な証拠だけを返しましょう。
次のような全体を追加しないでください。
- ウェブページ
- ログファイル
- リポジトリツリー
- データベースレスポンス
- ターミナルセッション
- API ペイロード
次のステップで必要なのが数フィールドだけのとき。
検索ツールは次のように返すかもしれません。
{
"source_id": "search_17",
"title": "Relevant page title",
"url": "https://example.com/page",
"relevant_passage": "A short evidence block"
}
完全な成果物はプロンプト外に保存し、あとでより狭いセクションを取得します。
ツールフィルタリングの原則： 次の判断に必要なフィールドだけを返し、「後で役に立つかもしれない」すべてのフィールドは返さない。
よくある誤り： JSON ペイロードの先頭 1,000 文字を切り捨てる。これは構造を壊したり、本当に必要なレコードを落とす可能性があります。
まずペイロードをパースし、構造的にフィールドを選択し、配列を制限し、有効な JSON としてシリアライズしてください。
3. 会話テキストだけでなく作業状態を圧縮する
圧縮は、タスク継続に必要な情報を保持し、次のアクションに影響しない履歴を削除するべきです。
有用な圧縮済み状態には次が含まれます。
- ユーザーの目標と成功基準
- 既に下した判断
- 検証済みの事実とソースID
- 変更されたファイルやレコード
- 失敗したアプローチ
- 未解決の問い
- 次のアクション
- 安全性・出力の制約
会話の全文を語り直すべきではありません。
OpenAI は長期の Responses API インタラクションにおける圧縮を文書化しています。Anthropic は古いコンテンツのクリアや要約に関するコンテキスト管理コントロールを提供しています。実装は異なるため、統合前に最新のプロバイダ項目を確認してください。
圧縮の原則： 決定事項と未処理の作業を残し、再取得可能な叙述や証拠は削除する。
よくある誤り： ソースID、変更ファイル名、却下したアプローチ、未解決の制約を落としてしまう。
圧縮を導入したら、エージェントが検索やツール呼び出しを繰り返していないか測定してください。プロンプトが短くなっても、失われた状態を再構築する必要があれば安くなりません。
4. 再利用可能なプレフィックスを安定化する
エージェントのプロンプトには再利用可能な大きなブロックが含まれることがよくあります。
- システム指示
- ツールスキーマ
- セーフティポリシー
- 出力フォーマット
- 共有リファレンス資料
- リポジトリやプロダクトの指示
これらの安定要素をリクエスト固有データより前に配置：
1. System instructions
2. Policies and constraints
3. Tool definitions
4. Stable examples
5. Shared reference material
6. Request-specific data
タイムスタンプ、リクエストID、セッションデータ、頻繁に変化する値を冒頭付近に置かないようにします。
プレフィックスが長く、安定しており、再利用される場合にキャッシュは最も有効です。短いセッションや頻繁に変わるプロンプトでは節約にならない可能性があります。
よくある誤り： キャッシュヒット率だけを最適化し、キャッシュの書き込み・読み出し・ストレージコストを測定しない。
プロバイダごとのプロンプトキャッシュ、厳密な応答キャッシュ、セマンティックキャッシュの広範な比較については「How to Reduce AI API Costs」を参照してください。(https://www.cometapi.com/reduce-ai-api-costs/)
5. リトライで同じコンテキストを再送しない
リトライは別のエージェントステップであり、しばしば同じ大きなプロンプトを再送します。
失敗原因を変えずにリクエストを繰り返さないでください。
| 失敗 | より良い対応 |
|---|---|
| 構造化出力が無効 | 検証エラーを返して1回だけ再試行 |
| ツールのタイムアウト | 冪等な操作は1回だけ再試行し、その後は停止またはフォールバック |
| コンテキスト溢れ | 状態を圧縮するか、取得する証拠を減らす |
| ツール呼び出しの重複 | 操作ハッシュで重複排除 |
| レート制限 | バックオフするか、検証済みフォールバック経路を使う |
| 低信頼の結果 | 不足情報を要求するかエスカレーション |
支払い、メール、デプロイ、DB 書き込みなど副作用のある操作には、冪等性キーを使用してください。
よくある誤り： レート制限中のモデルに対し、エージェントのコンテキスト全体を毎回再送しながら複数回リトライする。
失敗タイプ別にリトライ税を追跡し、最大のループから修正します。
6. 推論とサブエージェントは必要なステップに限定する
すべてのステップで深い推論が必要なわけではありません。
抽出、整形、分類、検証、定型的なツール選択は、低い推論強度とコンパクトな構造化出力で済むことが多いです。
高い推論強度は次のようなタスクに割り当てます。
- 複雑な計画
- 困難なコーディング
- 複数文書の統合
- 曖昧な意思決定
- 実行失敗からの復旧
推論の原則： 受理率を維持できる範囲で、最も低い推論強度を使う。
サブエージェントにも明確な境界が必要です。各ワーカーに次を与えます。
- 狭いタスク
- タスク固有のコンテキスト断片
- ツールの許可リスト
- トークン予算
- コンパクトな出力スキーマ
ルートエージェントに必要なのは、発見事項、証拠ID、確信度、未解決の課題であり、ワーカーの全トランスクリプトではありません。
サブエージェントの原則： 独立作業を並列化し、コンテキストの重複は避ける。
よくある誤り： 狭いタスクを割り当てる前に、ルートエージェントの履歴全体を全ワーカーへ送ってしまう。
まずどの最適化から適用すべきか？
エージェントのテレメトリを用いて最初の介入を選びます。
以下のしきい値は調査開始の目安であり、普遍的な基準ではありません。
| 観測シグナル | 着手点 |
|---|---|
| コンテキスト増幅が高い | 履歴を圧縮し、選択的に状態を取得 |
| ツール出力がプロンプトの大半 | フィールドをフィルタし、完全な成果物は外部に保存 |
| リトライ税が高い | 検証、タイムアウト、ツール呼び出し重複を修正 |
| 推論比率が高い | 定型ステップの推論強度を下げる |
| サブエージェントが同じ証拠を反復 | ワーカーのスコープとコンテキスト片を絞る |
| キャッシュ入力が伸びない | 再利用プレフィックスを安定化 |
| ループの整理後もコストが高い | 低コストのモデルルートを比較 |
安全な実装手順は次のとおりです。
- 累積入力、ツール保持、リトライ、推論を測定する。
- ステップ数、ツール、リトライ、総トークンのハードリミットを追加。
- 大きなツール結果をフィルタ。
- 測定したしきい値で古い状態を圧縮。
- 再利用プロンプトのプレフィックスを安定化。
- エージェントループが整理された後にモデルルートを比較。
主要な変数は一度に1つだけ変更し、同じ評価セットで再実行してください。
比較する項目：
- タスク受理率
- 成功タスクあたりのコスト
- 累積入力
- ツール呼び出し回数
- リトライ税
- 推論比率
- p50 と p95 のレイテンシ
- 人によるレビュー時間
トークン節約のためにタスク品質を下げたり、必要な証拠を削除してしまう変更はロールバックします。
CometAPI でエージェントワークフローをテストする
マルチモデル評価を実行する前に、CometAPI の pricing ページ(https://www.cometapi.com/pricing/?utm_source=chatgpt.com) とコスト見積もりガイド(https://apidoc.cometapi.com/guides/how-to-estimate-cost-before-calling-a-model) を使って、入力・出力・キャッシュ対象トークン・推論コストを見積もってください。
次に、model catalog(https://www.cometapi.com/models/?utm_source=chatgpt.com) で候補ルートを特定し、Quickstart(https://www.cometapi.com/quickstart/?utm_source=chatgpt.com) を使って OpenAI 互換クライアントを設定します。
本番のフォールバックには、CometAPI の model fallback ガイド(https://apidoc.cometapi.com/guides/model-fallback-with-cometapi) に従い、完了済みのツール呼び出しを繰り返したり、検証済みの状態を破棄したりせずにルートを切り替えてください。
統一されたアクセスはモデル比較とフォールバック統合を簡素化します。トークン予算、圧縮、検証、ツールフィルタリング、リトライ上限、受理基準はアプリケーション側で管理します。
FAQ
なぜエージェントはチャットボットより多くのトークンを使うのですか？
エージェントは複数回のモデル呼び出しを行い、各ステップで前のメッセージ、ツール結果、指示、中間状態を再送することがあります。これにより、初期のコンテキストが繰り返し処理されます。
プロンプトキャッシュはコンテキストウィンドウ使用量を減らしますか？
いいえ。プロンプトキャッシュは繰り返し入力の実効価格やレイテンシを下げられますが、キャッシュされたトークンも処理コンテキストの一部です。プロンプトサイズを減らすには、圧縮、フィルタリング、選択的取得を使ってください。
エージェントはいつコンテキストを圧縮すべきですか？
コスト、レイテンシ、利用可能な出力領域に影響が出始める前に圧縮します。圧縮後の状態が、決定事項、証拠ID、変更ファイル、未解決の問い、安全制約を保持していることを確認してください。
サブエージェントはトークンコストを削減しますか？
自動的には削減しません。独立作業の経過時間短縮やカバレッジ向上につながる場合はありますが、コンテキスト重複や分析の重複によって総トークン使用量が増えることが多いです。
AI エージェントのコスト最適化に最適な指標は何ですか？
主指標は成功タスクあたりのコストです。累積入力、コンテキスト増幅、ツール保持、リトライ税、推論比率、レイテンシ、人によるレビュー時間で診断してください。