10月30日、Machine Learning Masteryが「7 Ways Your AI Agent Is Wasting Tokens (And What to Do Instead)」と題した記事を公開した。この記事では、AIエージェントが本番環境でトークンを無駄に消費する7つのパターンと、それぞれのアーキテクチャ的な改善策について詳しく紹介されている。

AIエージェントの週末プロトタイプは誰でも作れる。問題は3ヶ月後のAPIコストだ。多くの実装エンジニアが見落としている根本的な設計ミスが、コストとレイテンシを破綻させる。

記事の核心にある指摘はシンプルだ。「コンテキストウィンドウをデータベース代わりに使っている」こと自体が間違いである。コンテキスト（リクエストごとに送るトークンのペイロード）と状態（エージェントの進捗を永続化したもの）を混同すると、推論呼び出しのたびにDB読み取りコストを払い続けることになる。

最も見落とされやすい2つの問題

1. コンテキストの追記地獄（Append-Only Trap）

エージェント設計で最も多い失敗が、プロンプト配列をデータベースのように使うことだ。ターンを重ねるごとにユーザーメッセージ・ツール出力・中間推論・応答をすべて追記していくと、ターン20の時点でエージェントは毎回全履歴を再読している。アテンションコストは二次関数的に増加する。

改善策：スライディングウィンドウ＋セマンティック要約

直近のNターンだけをそのまま渡し、古いターンは密な背景サマリーに圧縮する。構造的な状態はSQLiteやRedisのような決定論的なストアに切り出し、プロンプトに直接埋め込まない。

ただしサマリーは本質的に非可逆だ。UUID・ハッシュ値・コードスニペットのような精度が必要な情報はセマンティック圧縮で幻覚（ハルシネーション）が起きる。これらはキーバリューのルックアップツールで正確な文字列を取得する仕組みと組み合わせること。

2. ツールスキーマのスタティックな肥大化

30〜50個のツールを持つエージェントが全スキーマ定義を毎回のLLM呼び出しに注入すると、現在のタスクフェーズに無関係なスキーマを読むためだけに数千トークンを消費する。

改善策：有限状態機械（FSM）によるコンテキスト依存のツールプルーニング

エージェントが「探索」フェーズにあれば検索・読み取りツールのみを注入し、「実行」フェーズに遷移したら変更・書き込みツールのみに切り替える。無関係なスキーマはトークンを一切消費しない。

ここには重要なトレードオフがある。動的なツールスキーマはプロンプトキャッシュと相性が悪い。ツールのサブセットが変わるたびにLLMプロバイダーはKVキャッシュを再計算するため、キャッシュヒット率が下がる。後述する「プロンプトプレフィックス戦略」と方向性が逆になる点については、後述のまとめで改めて触れる。

残り5つのパターン：手短にまとめる

3. ツール結果の無圧縮注入
StripeやAWSのAPIレスポンスをそのままコンテキストに投入すると、1レスポンスだけで数千トークンを消費する。ミドルウェア変換層でnull値の除去・不要キーのフィルタリング・深いJSONのYAML/Markdown変換を挟む。ただしページネーションカーソルのような必要なメタデータまで削ると処理が壊れるので注意。

4. RAGの「Grep & Dump」問題
コーディングエージェントで1つの関数が必要なだけなのに、4,000行のファイル全体をコンテキストに放り込む実装は多い。Tree-sitterなどのASTパーサーを使ったチャンク分割・コールグラフ検索に切り替えれば、ファイル全体の代わりに関数シグネチャと直接依存だけの約300トークンで済む。

5. 無制限チェーンオブソート（CoT）ループ
ツール呼び出しが失敗してリトライを繰り返すと、1タスクで数万の出力トークンを消費しうる。出力トークンは多くのプロバイダーでは入力トークンより高い単価で課金される。オーケストレーター側にサーキットブレーカーを実装し、最大リトライ数と出力トークン上限を強制する。LangChainやLlamaIndexは組み込みのリトライフックを持っており、これを基盤にできる。

6. KVキャッシュとプロンプトプレフィックスの無視
タイムスタンプやユーザーIDなどの動的変数をプロンプトの冒頭に置くと、AnthropicのPrompt CachingやOpenAIのPrompt Cachingの恩恵を受けられなくなる。静的コンテンツ（システムプロンプト・スキーマ）を先頭に固め、動的変数は後方に置くのが基本だ。ただしキャッシュのTTLはプロバイダーによって5〜15分程度と短く、低トラフィック環境では効果が薄い。

7. モノリシックなルーティング（フロンティアモデルへの依存）
JSONのパースや意図分類・ログ要約のような単純タスクにGPT-4クラスのモデルを使うのはコストが見合わない。LiteLLMのようなルーティングライブラリを使い、Haiku・Gemini Flashクラスの小型モデルで処理できるタスクを仕分けする。注意点は、分類層が誤ルーティングすると不正なパラメータがフロンティアモデルに送られ、その呼び出しのトークンコストが実質2倍になることだ。

記事が追加で言及する2つのパターン

元記事は7パターンに加えて、見落とされがちな2つも取り上げている。

• 出力トークンの無制限生成： 構造化データを抽出する際にフォーマット制約をかけないと、モデルは余計な前置きを生成する。プロバイダーネイティブの構造化出力モードを使えば根絶できる。
• 同一情報の重複注入： システムプロンプト・ユーザーターン・ツール結果確認の3箇所に同じ情報を入れているケースは多い。正規注入箇所を1つに絞る監査パスで、タスクパフォーマンスを落とさずに入力トークンを10〜20%削減できるとされる。

まとめ

記事が強調するのは「トークン最適化はコスト削減ではなくシステム安定性の問題だ」という点だ。コンテキストが肥大化すれば推論レイテンシが上がり、ハルシネーションとオーケストレータータイムアウトの発生面積が広がる。最低限必要なコンテキストに絞ることで、エージェントの動作はより決定論的になる。

各改善策は独立していない点にも注意が必要だ。たとえばツールスキーマのプルーニングはトークン削減に効果的だが、スキーマのサブセットが変わるたびにキャッシュが無効化されるため、KVキャッシュによるプロンプトプレフィックス戦略とは逆方向のトレードオフを持つ。最適解はツールレジストリのサイズ、リクエスト量、プロバイダーのキャッシュ実装によって変わる。実際の本番トレースを観察することが、どこで線引きするかを判断する唯一の方法だと記事は結んでいる。

詳細は7 Ways Your AI Agent Is Wasting Tokens (And What to Do Instead)を参照していただきたい。