7月10日、Datadogが「Making agentic token costs visible in production」と題した記事を公開した。プロダクション環境におけるAIエージェントのトークンコストの発生源と、それを可視化・制御するための具体的な手法について詳しく解説している。

Datadogの「2026 State of AI Engineering report」によれば、Datadogが監視するサービスにおいて、リクエストあたりのトークン使用量は中央値で前年比2倍以上、90パーセンタイルのヘビーユーザーでは4倍に達した。「トークンをたくさん使う＝生産性が高い」という奇妙な風潮（tokenmaxxing）がエンジニアリングチームの間で広まりつつある中、本番環境ではそのコストがセッション・ユーザー・ツール呼び出しをまたいで静かに積み上がっていく。

トークンコストの三大発生源

単一ターンのプロンプトと異なり、エージェント型AIはコストが複合的に積み重なる。発生源は主に以下の3つだ。

1. ツール定義（最も見落とされやすい）

エージェントが利用できる各ツールには、その機能・パラメータ・呼び出し方を記述したスキーマが存在する。このスキーマは必要・不要にかかわらず、毎回のLLM呼び出し時にコンテキストへ読み込まれる。MCP（Model Context Protocol）サーバー経由でツールカタログに接続するエージェントでは、ネストされたオブジェクトを含む複雑なスキーマが数百〜数千トークンを消費し、それがユーザーとのやり取りが始まる前から毎回課金される。MCPはAnthropicが提唱するオープン標準で、LLMがファイルシステム・データベース・外部APIなどの外部リソースを統一的なインターフェースで呼び出せるようにする仕組みだ。接続するツール数が増えるほど、スキーマのトークン消費も線形に増加する点に注意が必要だ。

対策：ツールカタログのトリミング

ユーザーの意図をあらかじめ判定し、該当タスクに必要なツールのサブセットだけをモデルへ渡す。例えばカスタマーサポートエージェントなら、決済関連の質問には請求ツールを、アカウント管理の質問には別のツールセットをロードする、という形だ。

より細かい制御が必要な場合はプログレッシブディスカバリーも有効だ。起動時はツール名と説明のみを読み込み、実際に必要になった時点でフルスキーマを取得する。これにより機能を損なわずにベースラインのトークンコストを大幅に削減できる。

また、システムプロンプトや静的な指示など毎回読み込まれるコンテンツにはプロンプトキャッシングを活用する。主要なプロバイダーの多くがAPIレベルでサポートしており、変更のないトークンの再処理を回避できる。ここで重要なのがKVキャッシュだ。KVキャッシュとはLLMの推論過程で生成されるKey-Valueの中間表現をメモリ上に保持し、同一プレフィックスを再計算せずに再利用する仕組みである。セッション途中でツールを動的に追加・削除するとこのキャッシュが無効化される場合があるため、ツールカタログの変更はセッション境界で行うのが望ましい。

2. セッション履歴の肥大化

ReActスタイルのエージェントでは、ツール呼び出しのたびにAPIレスポンス・ファイル内容・エラートレースがコンテキストに追記される。ReActとは「Reasoning（推論）」と「Acting（行動）」を交互に繰り返すエージェントの動作パターンで、思考→ツール呼び出し→観察→次の思考、というループを形成する。このループごとに会話履歴が蓄積されるため、圧縮なしではコンテキストウィンドウがあっという間に埋まり、モデルが必要とするシステム指示や初期タスクのコンテキストが押し出される。

対策：履歴増加のキャップ

• スライディングウィンドウ：直近N件のメッセージのみ保持し、古いターンを破棄する。トークン制御には効果的だが初期コンテキストが失われるリスクがある
• 履歴サマリー化：古いターンを定期的に要約して圧縮する。詳細は若干失われるが、コンテキストのフットプリントを小さく保てる

どちらが適切かはエージェントの性質による。早期ターンがすぐに不要になるタスク特化型エージェントにはウィンドウ方式、過去の決定を参照し続けるコーディングアシスタントにはサマリー化が向く。効果の確認方法は、セッション内のターンごとの入力トークン数を追跡し、増加曲線が平坦化しているかを確認することだ。

3. 検索ループの重複

LLMが検索のタイミングと内容を自律的に決定するエージェント系では、検索サイクルごとにチャンクがコンテキストに注入される。重複検索を検出・排除する仕組みがなければ、エージェントは過剰にループしてコストを膨らませる。

対策：検索スパンのトークン数をログとして記録し、異常な増加がないかを監視する。重複排除はメタデータIDだけでなくチャンクの内容で比較すること。ベクトルストアでは同一パッセージが別エントリとしてインデックスされているケースが多い。

トークンコストを可視化するために必要な4つのデータ

どの最適化も、可視化なしには効果を検証できない。把握すべきデータは以下の4カテゴリだ。

• LLM呼び出し・ツール呼び出し・検索ステップ別のコスト内訳（スパン単位のトレース）
• 入力・出力トークンの分割：モデルやプロバイダーによって価格体系は異なり（Anthropic・OpenAI・Googleの料金体系を参照）、スケール時にはツール定義や履歴による入力トークンの肥大化が大きなコスト要因になりやすい
• セッション・ターンごとのトークン推移：集計値だけでは複合的な増加を見逃す
• トークンコスト異常のアラート：コストスパイクはバグのシグナルであることが多い（エージェントの予期せぬループ、検索システムの誤動作、コンテキストウィンドウの最大値への誤設定など）

Datadog LLM Observabilityでは、プロバイダーの公開料金に基づくコール単位のコスト内訳、スパンレベルのトークントレース、ダッシュボードやモニターに接続可能なメトリクスを提供している。

トークンバジェットの設定と強制

可視化の次のステップはガバナンス層の構築だ。トークン予算をメモリやコンピュートの制限と同様に、エージェント・サービス・チームごとに割り当てる。Agent Observabilityで代表的な期間の現在の消費量をベースライン化し、そこから閾値を設定して異常を検知する形が現実的な出発点だ。

エージェント設定には「セッションあたりの最大コンテキストウィンドウ」「最大ツールカタログサイズ」「最大検索深度」といった制約を明示的にエンコードすることを推奨している。これにより各開発者が自律的にコストを管理できるようになり、大規模な組織では集中管理よりもスケールしやすい。tokenmaxxingの風潮が広まる中で、こうした定量的な制約を組織のデフォルトとして埋め込む姿勢が、本番運用の持続可能性を左右すると言えるだろう。

詳細はMaking agentic token costs visible in productionを参照していただきたい。