トークンは多いのに、コストは安い——トークン数で測るとAIエージェントのコスト順位は逆転する
要約: トークン数とAIエージェントのコストは、逆方向を指すことがあります。2026-08-15の実際のAWSサンドボックスでは、トークン消費量が最も多い3つのエージェントが最も安価に稼働し、トークン消費量が最も少ない3つのエージェントが最も高価でした。完全な逆転です。理由はトークンではなくコンピュートにあります。各エージェントはそれぞれ長時間稼働するFargateサービスとして動作しており、完全なリソース内訳がある3つのワークロードでは、Fargateが日次コストの57〜80%を占め、より軽量な4つ目のワークロードでは26%まで下がりました。AWS Cost Explorerではエージェント別のコストはまったく表示できず、すべてのエージェントがサービスレベルの1行にまとめられます。請求書の裏にある順位を明らかにするのは、ワークロード別のリソース内訳です。
AIエージェントのコストをトークン消費量で順位付けしているなら、まさに正反対の順序で並べているかもしれません。
2026-08-15(UTC)、確定済みの1日について、us-east-1のdoit-apj-attribute-sandboxアカウントでは、あるアプリケーション内でトークン消費量が最も多い3つのエージェントが最も安価な3つでもあり、トークン消費量が最も少ない3つのエージェントが最も高価な3つでした。両グループ間のトークン差は2.5倍に達し、しかも金額とは逆方向です。表示上の丸め誤差では、この差はとても説明できません。
以下のドル金額とトークン数はすべて、このサンドボックスアカウントの5枚のスクリーンショット(稼働中のAWS Cost Explorerレポート1枚と、稼働中の DoiT Attributeビュー4枚)から直接読み取ったものです。いずれもレートカードから推計した数値ではありません。パーセンテージや100万トークンあたりの単価は、表示された数値をもとに当社が独自に計算したもので、該当箇所にその旨を明記しています。また、Cost Explorer自身の「推定料金」という注記がその列に適用されます。記事後半の6枚目の画像は説明用のアーキテクチャ図であり、ダッシュボードのスクリーンショットではありません。
AWS Cost ExplorerがAIエージェントのコストについて教えてくれないこと
まずはその日のAWS Cost Explorerから見ていきましょう。日次粒度、サービス別グルーピング、償却コスト表示です。
2026-08-15の列:
Total costs $9.98Elastic Container Service $5.99Claude Haiku 4.5 (Bedrock Edition) $2.24VPC $1.01Claude Opus 5 (Bedrock Edition) $0.70正確ではありますが、この問いには役に立ちません。アプリケーション内のすべてのエージェントが、この$5.99のFargate行と$2.24のHaiku行を共有しています。請求書にはサービスというディメンションとアカウントというディメンションはありますが、エージェントというディメンションはありません。したがって、どちらの方向であれ、エージェントを順位付けすることはそもそもできないのです。
レポート自体の注記にも留意してください。日付はUTCであり、現在の請求期間の数値には推定値であることを示すフラグが付いています。
AIエージェントのコスト順位の逆転
同じ日、Attributeでワークロード粒度に切り替え、サンドボックスアカウントのluminara-*ワークロードで絞り込んだ結果です。
このビューに表示されている合計 Cost (1 Day) $8.8 は、ここに表示された7つのluminara-*ワークロードを、この1つのアカウントで絞り込んで合算した値です。これは上記のCost Explorerの合計$9.98とは比較できません。後者はこれら7つのワークロードのFargateとモデルの支出だけでなく、アカウント内のすべてのコストを含んでいるためです。
このリストから、6つのluminara-*オーケストレーションおよびスペシャリストワークロードを読み取ると次のとおりです。
| ワークロード | トークン | コスト | トークン順位 | コスト順位 |
|---|---|---|---|---|
luminara-orchestrator |
125.75K | $1.48 | 4 | 1 |
luminara-chain |
123.73K | $1.48 | 5 | 1 |
luminara-conditional |
115.27K | $1.46 | 6 | 3 |
luminara-route |
315.01K | $1.23 | 1 | 4 |
luminara-sites |
265.49K | $1.16 | 2 | 5 |
luminara-dining |
169.64K | $1.07 | 3 | 6 |
グループ分けを見ると、きれいに逆転しています。**トークン消費量が最も少ない3つのワークロードがコスト上位3つを占め、トークン消費量が最も多い3つのワークロードがコスト下位3つを占めているのです。**最も対照的なペアはluminara-routeとluminara-orchestratorで、トークン数は2.5倍なのに、その日のコストは$0.25安くなっています。
上位3つは互いに$0.02以内に収まっているため、この表示精度ではグループ内の順序に意味はありません。ただ、グループ単位の逆転はその誤差幅よりはるかに大きなものです。
ダッシュボードがトークンカウンターであれば、このアプリケーションのコストはluminara-routeに支配されているように見えます。しかし実際には、これが6つの中で最も安価なワークロードなのです。
AIエージェントのコスト順位を決めるのが、トークンではなくコンピュートである理由
各luminara-*エージェントは、それぞれ長時間稼働するECS Fargateサービスとして動作し、推論のためにBedrockを呼び出します。この構造的な事実こそが、モデル行とは別にFargate行が存在する理由です。Fargateはプロビジョニングされたコンピュートに対して時間で課金され、Bedrockは消費トークンごとに課金されます。この2つは独立したコスト軸なのです。
- クライアントがエージェントのECS Fargateサービスにリクエストを送信します。
- Fargateサービスがエージェントループを実行し、LLM推論のためにAmazon Bedrockを呼び出します。
- BedrockがモデルのレスポンスをFargateサービスに返します。
luminara-toolcallのみ、FargateサービスがBedrock AgentCore Gatewayを呼び出してツールを実行します。- Gatewayは、4つのツールの背後にある3つのLambda関数にファンアウトします。
luminara-orchestratorのみ、Fargateサービスが監査イベントをluminara-trajectory-auditSQSキューに書き込みます。- Fargateサービスが最終レスポンスをクライアントに返します。
Attributeは各ワークロードをリソース単位に分解します。両極端にある2つのワークロードのドリルダウンを見れば、この逆転の理由がわかります。
luminara-orchestrator — Total resources cost: $1.48 (1 - 3 Out of 3)
luminara-poc EC2-ECS $1.18 20%us.anthropic.claude-haiku-4-5-20251001-v1 AmazonBedrock $0.30 125.75K Tokens 13%luminara-trajectory-audit AWSQueueService $0.00 --
luminara-route — Total resources cost: $1.23 (1 - 2 Out of 2)
luminara-poc EC2-ECS $0.70 12%us.anthropic.claude-haiku-4-5-20251001-v1 AmazonBedrock $0.53 315.01K Tokens 24%luminara-routeは確かにモデルへの支出が多く、$0.53対$0.30です。それでも総額では負けています。オーケストレーターのFargate行が$1.18であるのに対し、routeは$0.70だからです。
上の2枚のスクリーンショットに表示されているパーセンテージ(20%、13%、12%、24%)は、リソース行ごとのAttribute自身のResource Accountability指標であり、ワークロードコストに占める割合ではありません。表示のまま転記しています。以下のFargate比率は、ドル建て合計をもとに当社が独自に計算した、それとは別の数値です。
これらの数値から比率を計算すると次のようになります。
| ワークロード | Fargate | モデル | Fargate比率 |
|---|---|---|---|
luminara-orchestrator |
$1.18 | $0.30 | 80% |
luminara-route |
$0.70 | $0.53 | 57% |
どちらのケースでも日次コストの過半を占めるのはコンピュートであり、順位を決める変数もコンピュートです。トークンはコスト全体の中では小さな項目にすぎないのに、トークンベースのダッシュボードはそれがすべてであるかのように扱います。
luminara-diningを見れば、2つのデータポイントだけの偶然という可能性も排除できます。
luminara-dining — Total resources cost: $1.07 (1 - 2 Out of 2)
luminara-poc EC2-ECS $0.70 12%us.anthropic.claude-haiku-4-5-20251001-v1 AmazonBedrock $0.38 169.64K Tokens 17%luminara-routeと同じ$0.70のFargate行が表示されており、同規模にサイジングされた2つのスペシャリストサービスであることがわかります。一方、オーケストレーターは$1.18です。4つ目のワークロードであるluminara-toolcallは、1日$0.93のうちFargateが$0.24、つまり26%で、同じ傾向の中でも低い側に位置しています。この数値の背後にあるリソース内訳はエビデンスセットに保持していますが、本記事には掲載していません。
コンピュートが支配的であること自体を新しい発見として主張しているわけではありません。保持している2026-08-21までの30日間のダッシュボードキャプチャでは、luminara-orchestratorのEC2-ECS比率がすでに**71%**と測定されており、ここでは同じ傾向が別の期間でも成り立つことを示すために引用しているにすぎません。新しいのはその帰結です。コンピュート項目が支配的で、しかもワークロードの役割によって変動するため、それが順位を決め、その結果生まれる順位はトークン順位の逆になるのです。これらのワークロード以外のアーキテクチャについては何も主張しません。
オーケストレーターの3つ目のリソースであるluminara-trajectory-auditは、$0.00のAWSQueueService行です。Attributeは、その日のコストがゼロでもリソースを一覧に含めます。このエージェントがキューに依存していることにそもそも気づけるのは、そのためです。
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
AIエージェントのコスト追跡における意味
トークン数はAIエージェントの総コストの指標にはならない
トークン数はモデル行のコスト指標にすぎず、詳細を確認した3つのワークロードでは、モデル行はワークロードの日次コストの20%から43%の範囲でした。usageオブジェクトだけで構築されたエージェント別コストビューは、コンピュートフットプリントが異なる場合には必ずエージェント群の順位を誤って評価します。つまり、中央のオーケストレーターと範囲の狭いスペシャリストワークロードのように、エージェントのオーケストレーション上の役割が異なる場合は、常にそうなるということです。
AIエージェントのコスト順位付けにはコンピュートのワークロード別ビューが必要だった
クライアントサイドのトークン計上では、Fargateはまったく見えません。請求書はFargateを認識しますが、1つの行にまとめてしまいます。上記のワークロード別の分解こそがAttributeがここで果たした具体的な貢献であり、答えを覆したのはまさにそれです。
とはいえ、どちらもこれを効率性の順位にするものではありません。これらのワークロードは、異なるリクエスト量で異なる仕事をこなしています。ここで測定したのはワークロードごとの日次コストであり、リクエストあたり、達成したゴールあたり、品質単位あたりのコストではありません。1日あたりのコストが安いことは、作業単位あたりのコストが安いことと同じではないのです。
FAQ
トークン使用量が多いほどAIエージェントのコストは高くなりますか? 必ずしもそうではありません。この分析では、トークン消費量が最も多い3つのエージェントが最も安価に稼働し、トークン消費量が最も少ない3つのエージェントが最も高価でした。トークン量が追跡できるのはモデル行だけであり、エージェントを稼働させる総コストではありません。
AWS Cost ExplorerでAIエージェント別のコストを表示できないのはなぜですか? Cost Explorerはサービスとアカウントでグルーピングし、エージェント単位では分けません。アプリケーション内のすべてのエージェントが同じFargateおよびBedrockの明細行を共有するため、請求書には個々のエージェント別にコストを分割するディメンションが存在しないのです。
トークンでないなら、AIエージェントのコストを決めるのは何ですか? コンピュートです。完全なリソース内訳がある3つのワークロードでは、Fargateのコンピュート行が日次コストの57〜80%を占め、モデル行は20〜43%でした。より軽量な4つ目のワークロードでは、Fargate比率は26%まで下がりました。コストは、ワークロードが消費するトークン数ではなく、オーケストレーション上の役割によって変わります。
共有インフラ上でAIエージェント別のコストをどのように測定しますか? トークン数やプールされた請求行に頼るのではなく、各ワークロードをコンピュート、モデル呼び出し、キューなどその他の課金対象リソースといった基盤リソースに分解することで測定します。Attributeは、タグではなくランタイムデータを用いて、これをワークロードレベルで行います。
トークンベースのコスト推計は、エージェント型AIシステムに対して信頼できますか? それ単体では信頼できません。トークンはモデル行のみの代理指標です。コンピュートコストが異なる場合、トークンのみのビューはワークロードの順位を誤る可能性があります。ここで測定した6つのワークロードでは、実際にそうなりました。
AIエージェントのコストを正しく把握するために必要なのは、トークン数ではなくワークロード別のコンピュートビューです。
