複数のAIエージェントを連携させるシステムを運用していて、月末の請求額の内訳が説明できずに困っていないでしょうか。この記事では、B-TAP（Bureau of Token Attribution and Provenance、トークンの帰属と出所を管理する架空の標準化団体）という風刺的な提案を切り口に、マルチエージェント構成で発生するトークン費用を分解して可視化する考え方を整理します。
B-TAPという団体自体は実在しません。税務申告書のパロディを使ってAIインフラのコスト管理の杜撰さを皮肉った読み物ですが、そこで挙げられている「費用の分類」自体は、実務のコスト分析にそのまま転用できる視点です。架空の制度を借りて、現実のオブザーバビリティ（システムの内部状態を外部から観測できるようにする仕組み）設計に使える発想を取り出してみます。
なぜ「使った額」と「使った理由」は別問題なのか
典型的なマルチエージェント構成を思い浮かべてみます。ユーザーの質問に対して、オーケストレーション層（複数エージェントの呼び出し順序や役割分担を制御する層）が3つのエージェントにリクエストを振り分けます。
1つはベクトルデータベースへの検索、1つはナレッジグラフへの問い合わせ、もう1つは会話履歴全体を受け取る担当です。最後の1つは「半年前に誰かがチェックボックスを入れて、理由は誰も覚えていない」設定だったりします。
これらの出力はスーパーバイザー（複数エージェントの結果を統合する監督役のエージェント）に渡り、4万7000トークンの文脈を受け取って600トークンの回答を返します。HTTPステータスは200、ダッシュボードは緑、しかし請求額だけが膨らんでいく、という状況です。
一般的なコスト監視ツールは「いくら使ったか」は教えてくれます。しかし「なぜそれだけ使ったか」までは教えてくれません。この2つを分けて考える視点こそが、B-TAPの提案する分類の核心です。
5つの税目に分けてコストを読む
B-TAPの枠組みでは、トークン消費を5種類の「税」に見立てて分類しています。実務のタグ付けやログ設計に置き換えて読むと理解しやすくなります。
- Context Tax（文脈税）: 指示文・取得文書・会話履歴・他エージェントの出力など、モデルの文脈窓に載せ続けている情報すべてにかかるコスト
- Retrieval Tax（検索税）: モデル呼び出しの外側で発生する、検索・ランキング・再ランキング・フィルタリングの処理コスト
- Prose Tax（冗長表現税）: 本来の情報量に対して、文章量が過剰になっている場合に発生する無駄なコスト
- Ingestion Tax（取り込み税）: パース・正規化・重複排除・分類・埋め込み生成など、データを使える形に変換する書き込み側の処理コスト
- Observer's Tax（観測税）: システムが高コストな理由を調べるために導入した監視機構自体が、新たなコストを生む現象
この最後のObserver's Taxは特に見落とされがちです。トレーシング（処理の流れを記録して追跡する仕組み）やログ収集を手厚くするほど、その収集・保存・解析自体がAPI呼び出しやストレージ費用を生みます。監視を増やすほど請求書が厚くなるという皮肉な構造です。
既存のオブザーバビリティ手法との違い
LangSmith やLangfuse、OpenTelemetryベースのLLMトレーシングツールは、すでに「どのエージェントが」「何トークン使ったか」をスパン単位で記録できます。これらのツールが提供するのは主に時系列・呼び出し単位の可視化です。
B-TAPの分類が補完するのは、その先の「用途別の意味づけ」です。同じ1万トークンでも、ユーザーの質問文に由来するのか、検索結果の埋め込みに由来するのか、エージェント間の引き継ぎメッセージに由来するのかで、削減すべき対象も対策も変わります。
たとえば「会話履歴全体を毎回送っている」設定が見つかった場合、これはContext Taxの典型例です。対策は履歴の要約化や直近N件のみの保持に絞ることです。一方、検索結果のランキング処理が重い場合はRetrieval Taxの問題であり、対策は候補数の絞り込みやキャッシュの導入になります。原因ごとに打ち手が違う以上、まず分類すること自体に価値があります。
今日から確認できること
手元のマルチエージェント構成で、実際にこの5分類を当てはめてみることができます。
# OpenAI API利用時の例: レスポンスのusageフィールドで
# prompt_tokens / completion_tokens を呼び出しごとに記録する
curl https://api.openai.com/v1/chat/completions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"..."}]}' \
| jq '.usage'出力される prompt_tokens のうち、どこまでがシステムプロンプト、どこまでが検索結果の埋め込み、どこまでが会話履歴かをログに分けてタグ付けしてみます。多くのLLM SDKはコールバック機構を持っているため、呼び出し元の関数名やエージェント名をメタデータとして付与するのは難しくありません。
分類の判断基準としては次のように整理できます。
- 固定の指示文やシステムプロンプトが肥大化していないか → Context Tax
- 検索結果を毎回フルで渡していないか、要約や上位N件に絞れないか → Context Tax / Retrieval Tax
- プロンプトや出力の文章が冗長になっていないか、簡潔な指示で同じ精度が出ないか → Prose Tax
- バッチ処理での前処理（埋め込み生成・分類タグ付け)にどれだけのAPI呼び出しが発生しているか → Ingestion Tax
- トレーシングツールの導入によって追加のAPI呼び出しやストレージコストが発生していないか → Observer's Tax
これらをダッシュボードの列として追加するだけでも、どの工程に削減余地があるかが見えやすくなります。
まとめ
マルチエージェント構成のコストは「いくら使ったか」だけでなく「どの工程で、何のために使ったか」まで分解して初めて対策が立てられます。
B-TAPという架空の税務フレームワークは皮肉混じりの読み物ですが、Context・Retrieval・Prose・Ingestion・Observerという5分類は、既存のトレーシングツールのタグ設計にそのまま応用できる視点です。
まずは直近1週間分のAPI呼び出しログを抜き出し、usage フィールドのトークン数をこの5分類に手作業でマッピングしてみることから始められます。どの税目が一番重いかが見えてくれば、次に削るべき場所の優先順位がはっきりします。