7月7日、AWSが「What does it cost to answer one question? Measuring per-request cost in agentic workloads」と題した記事を公開した。同記事はAWSのPublic Sectorブログに掲載されており、政府・公共機関向けの社会サービス申請案内エージェントを実例に、AIエージェントワークロードの「リクエスト単位コスト」という盲点を解剖している。ツール呼び出しのたびに会話履歴全体が再送される構造的問題により、月次請求書を見て初めてコスト膨張に気づく——この典型的な失敗パターンを避けるための計測・削減手法が実践的にまとめられている。
「1リクエストいくら？」が答えられない問題
LLMを使ったエージェントワークロードを運用している組織の多くは、月次のトークン消費量は把握できても、ユーザーの質問1件あたりのコストを把握できていない。この「リクエスト単位の可視性」の欠如が、コスト管理の盲点になっている——というのが本記事の出発点だ。
エージェントのコストが単純なLLM推論より高くなる仕組みを理解しておく必要がある。
ツール呼び出しでコストが累積的に膨らむ構造
エージェントワークロードでは、LLMが質問に直接答えられない場合、ツール呼び出しを挟む。問題はここだ。ツールを呼び出すたびに、会話履歴全体が再度LLMに送り返される。
記事中の具体例で示すと、ユーザーリクエストが100トークン、ツール呼び出し要求が50トークン、ツール結果が50トークンのケースでは、3回のツール呼び出しで入力トークンが次のように積み上がる：
- 1回目のLLM呼び出し：100トークン
- ツール呼び出し1回目後：200トークン（100＋50＋50）
- ツール呼び出し2回目後：300トークン（200＋50＋50）
- ツール呼び出し3回目後：400トークン（300＋50＋50）
4回の呼び出し合計：1,000入力トークン。ユーザーの元のリクエスト（100トークン）と比べて10倍だ。
この増加パターンは等差数列的（呼び出しごとに一定量が加算される）であり、厳密な指数増加ではない。ただし呼び出し回数が増えるほど1回あたりのコスト寄与が大きくなる「複利」的な性質を持っており、後半のツール呼び出しが前半の累積コストをさらに押し上げる点が問題の本質だ。
モデル選定はトークン単価ではなく「問題解決あたりコスト」で考える
記事では、食料支援・住宅・育児・医療等の社会サービス申請案内を行うエージェントを実際に構築し、コスト計測を行っている。公共セクター向けのユースケースとして選ばれたのは、問い合わせ件数が多く・かつ回答品質の一貫性が求められる典型的なシナリオだ。使用したのはAmazon Bedrock上のClaude（Anthropic製）の2モデル：Haiku 4.5とOpus 4.8。
※ 本記事執筆時点でのAnthropicの一般的なモデル命名規則（例：Claude 3 Haiku、Claude 3 Opus）とは表記が異なる。元記事に記載されたモデル名をそのまま引用しているが、最新のモデルラインナップについてはAnthropicの公式ドキュメントを参照されたい。
結果は明確だった：
- Haiku 4.5：リクエストあたり約**$0.006**
- Opus 4.8：リクエストあたり約**$0.14**
コスト差は23倍。にもかかわらず、このワークロードでは両モデルの出力品質は同等だったという。
月間1,000リクエスト/日で換算すると：
- Opus 4.8：約**$4,200/月**（$0.14 × 1,000 × 30）
- Haiku 4.5：約**$180/月**
トークン単価で選ぶのではなく、「そのタスクを解くのにいくらかかるか」で選ぶべき、という主張だ。
コスト削減の3つのアプローチ
1. エージェントサイクル数の上限を設ける
記事では、p50（中央値）のツール呼び出し回数が2回以下、p90でも3回以下という計測結果が示されている。90%以上のリクエストは3回以内のツール呼び出しで完了する。
4回目以降のツール呼び出しは、それまでの積み上がったトークン履歴のせいで、1〜2回目の合計より高コストになることもある。Strands Agents SDK（AWSによる紹介ブログ）では「インターベンション（interventions）」機能を使い、ツール呼び出しを3回で打ち切って部分的な回答を返す、といった制御をコードで実装できる。
2. ツールの設計を見直す
ツールの応答は会話履歴に残り、以降の全呼び出しで再送される。ツールが不要なデータを返していると、その冗長なトークンが複利的にコストを押し上げる。
記事の例では、search_programs というツールがプログラム名・説明・応募資格・連絡先情報を返していたが、実際に使われるのはプログラム名と説明だけだった。出力を最小化するだけでコストが削減できる。
また、常に同じ順番で呼ばれるツールチェーンが存在する場合は、複数ツールを1つに統合して呼び出し回数そのものを減らすのも有効だ。ただし柔軟性とのトレードオフがある。
3. メトリクスの収集から始める
コスト最適化の前提として、まず計測基盤を整える必要がある。AWSの推奨はCloudWatch Embedded Metric Format（EMF）を使ったテレメトリの出力だ。ツール呼び出しごとに入出力トークン数・モデルID・呼び出し番号をログに記録することで、コストドライバーを可視化できる。Strands Agents SDKを使っている場合は、組み込みのメトリクス取得機能も利用できる。
記事では、まず20〜30件の代表的なプロンプトでエージェントを動かし、リクエストあたりのトークン数とツール呼び出し回数を記録することを推奨している。
まとめ
エージェントワークロードのコストは、会話履歴の再送という構造上の理由から、通常のLLM推論よりも高くなりやすい。月次の請求書が届くまでこれに気づかないのは、リクエスト単位の可視性がないからだ。本記事がAWSのPublic Sectorブログに掲載されていることからも、政府・公共機関のような大量問い合わせを処理する組織にとって、このコスト構造の把握は特に重要な課題といえる。計測→モデル選定の見直し→ツール呼び出し上限の設定→ツール出力の最小化、という順番でアプローチするのが実践的だ。
詳細はWhat does it cost to answer one question? Measuring per-request cost in agentic workloadsを参照していただきたい。
