はじめに
いえらぶＧＲＯＵＰの開発部で執行役員を務めています、和田です。わだけんです。
Claude Codeの Agent Teams（/agents コマンド）、使ってますか。
最近、Chrome拡張機能の開発を Agent Teams でやってみたんですが、そのときのトークン消費量を計測してみたら、事前の見積もりと7倍ズレてまして。
「いやいや、7倍て」と。
自分でも笑ってしまったんですが、よくよく分析してみると、マルチエージェント構成でのトークンコストって、直感に反する振る舞いをいくつもしていて、これは共有しておいた方がいいなと思って記事にしています。
特に「安いモデルに調査させて、高いモデルで設計すればコスト最適でしょ」と思っている方（昨日の自分です）には、ちょっと立ち止まってもらえるかもしれません。
ちょっとシリーズです
やったこと
Chrome拡張機能を作りました。要件定義 → 詳細設計 → 実装を一気通貫で。
エージェント構成はこんな感じです。
Phase 1: 並列調査（2エージェント同時実行）
├── Agent 1: 既存パターン調査（haiku）
└── Agent 2: 対象サイト技術調査（sonnet）
Phase 2: 統合設計（1エージェント順次実行）
└── Agent 3: 多観点設計（opus）
Phase 3: レビュー・承認（人間）
Phase 4: 実装（エージェントなし、メインコンテキストで直接）
調査は軽いモデル、設計は重いモデル。並列で時間短縮。理にかなってるな〜、と思ってたんですよ。思ってたんですけどね。
見積もりが7倍ズレた
事前に計算してたやつ
Agent 1（haiku）: 入力 ~5K + 出力 ~2K = ~7K
Agent 2（sonnet）: 入力 ~3K + 出力 ~3K = ~6K
Agent 3（opus）: 入力 ~15K + 出力 ~8K = ~23K
合計: ~36K tokens
まあ36Kくらいかなと。
実際のやつ
| エージェント | モデル | 総トークン | ツール使用回数 | 実行時間 |
|---|---|---|---|---|
| Agent 1: 既存パターン調査 | haiku | 113,631 | 27回 | 2分16秒 |
| Agent 2: サイト技術調査 | sonnet | 75,079 | 28回 | 3分34秒 |
| Agent 3: 多観点設計 | opus | 64,073 | 15回 | 6分17秒 |
| 合計 | - | 252,783 | 70回 | 12分7秒 |
253Kでした。7倍。
なんでそんなにズレたのか
結論から言うと、見積もりのときに**「入出力トークン」と「総トークン」を混同していた**のが原因です。
エージェントがツールを1回使うたびに、APIとしては1ターンのやりとりが発生します。そして毎ターン、システムプロンプト + 過去の会話履歴 + ツール結果がまるごと再送信されるんですよね。
総トークン = Σ（各ターンの入力トークン + 出力トークン）
= Σ（システムプロンプト + 累積会話履歴 + ツール結果 + 応答）
つまり、27回ツールを使うエージェントは、27ターン分の累積コンテキストの再送信が走っている。これが最大のコスト要因でした。
ざっくりモデル化すると：
27ターンの場合:
Σ(n=1→27) [システムプロンプト(~2K) + 累積履歴(n×~1K) + ツール結果(~2K) + 応答(~1K)]
≈ 130K tokens（コンテキスト圧縮を考慮して）
見積もるべきは「入力 + 出力」じゃなくて「ツール回数 × 累積コンテキストサイズ」だったわけです。
安いモデルが一番トークンを食ってた
ここからがちょっと面白い話です。
| モデル | 総トークン | ツール使用回数 | トークン/ツール使用 |
|---|---|---|---|
| haiku（最安） | 113,631（最大） | 27回 | 4,209 |
| sonnet | 75,079 | 28回 | 2,681 |
| opus（最高額） | 64,073（最小） | 15回 | 4,271 |
haiku が 113K、opus が 64K。安いモデルが一番トークンを消費している。
なんでこうなるかというと、haiku は1回の応答で得られる情報量が少ないので、たくさんツールを呼ぶ必要がある。ツール回数が増えると累積コンテキストが膨張する。結果、総トークンが一番大きくなる。
一方 opus は1回の応答が濃いので、15回のツール呼び出しで済んでいる。単価は高いけど、総トークン量は一番少ない。
金額で見ると（概算）:
haiku: 113K × $0.25/MTok = $0.028
sonnet: 75K × $3.00/MTok = $0.225
opus: 64K × $15.00/MTok = $0.961
金額ベースでは当然モデル単価の差が支配的です。ただ、コンテキストウィンドウの消費量という観点では逆転が起きている。これはAgent Teamsの設計を考えるうえで意識しておいた方がいいポイントかなと思っています。
「安いモデルで多くのターン」は「高いモデルで少ないターン」より総トークンが多くなりうる。
観点分離はエージェント分割より「プロンプト内Step分割」が効率的だった
今回、PdM・利用者・エンジニアの3つの観点で設計をしたんですが、当初は観点ごとにエージェントを分ける案もありました。
案A: Role-based（観点ごとにエージェント分割）
├── PdMエージェント: 共通コンテキスト + PdM分析
├── 利用者エージェント: 共通コンテキスト + UX分析
└── Engエージェント: 共通コンテキスト + 技術分析
→ 共通コンテキストが3重複
案B: Prompt-based（1エージェント内でStep分割）★採用
└── 統合エージェント:
├── Step 1: PdM観点
├── Step 2: 利用者観点
├── Step 3: エンジニア観点
└── Step 4: 統合
→ コンテキスト重複なし
コスト的には案Aが約135K tokens、案B（実際に採用した方）が64K tokens。約2.1倍の差。
品質面では、Role-basedの方が各観点の深掘りはできるかもしれません。ただ、今回のようにスコープが明確で単機能な開発では、1つのエージェントがコンテキストを保持したまま観点を切り替える方が整合性も取りやすかった印象です。
大規模で複雑なタスクだったらまた話は変わるかもしれませんが。
170行のコードにエージェントは要らなかった
Phase 4の実装（Chrome拡張、約170行）はエージェントを使わず、メインコンテキストで直接やりました。
もしエージェントに任せていたら、設計書の内容を伝えるためのコンテキスト伝達コストが15〜20K tokensくらい発生していたはずです。170行のコードを書くためにそれだけのコストをかけるのは、さすがに割に合わない。
しかも、エージェント経由だと設計書の「要約」が渡されるので、設計意図の伝達ロスもある。メインコンテキストなら設計書をそのまま参照できるので、そのロスがない。
小規模な実装にはエージェントを挟まない方が良い、というのは実感としてかなり強くあります。
まとめ：得られた経験則
今回の実験（n=1なので経験則というのもおこがましいですが）から、自分の中で以下が整理されつつあります。
トークン見積もりの話：
事前見積もりの5〜10倍が実コスト。「入出力の合計」ではなく「ツール回数 × 平均コンテキストサイズ × 1.5（安全係数）」で計算するようにしています。
モデル選択の話：
安いモデルが安く済むとは限らない。ターン効率（1回のツール呼び出しでどれだけ進むか）が総トークンに効いてくる。探索的なタスクでhaikuを使うと、ツール回数が膨らんでコンテキストが爆発しがちです。
エージェント分割の話：
分割するかどうかの判断軸は「コンテキスト伝達コスト」と「分割による期待効果」のバランス。目安として、実装が200行以下ならエージェント化しない方が効率的でした。観点分離もプロンプト内Step分割で十分なケースが多い。
エージェント分割の判断:
分割の期待効果 > コンテキスト伝達コスト + 調整コスト
→ 満たさないなら分割しない
並列実行の話：
時間は39%短縮できた一方で、トークンコストは変化なし。時間短縮したいときには有効、コスト削減したいときには効かない。当然といえば当然なんですが。
おわりに
n=1の実験なのであくまで参考値ですし、タスクの性質やスコープによって結論は変わると思います。
ただ、「安いモデルに投げとけば安い」「エージェント分けた方がスマート」みたいな直感は、累積コンテキストの構造を考えるとだいぶ揺らぐな〜というのが正直な感想です。
この辺りの設計判断は、もう少し異なるタスクでも試してデータを取っていきたいと思っています。
引き続きジタバタしていきます。
おわり。
CM
こんな感じでAIエージェントの設計をあーだこーだ言いながら開発してる仲間を、いえらぶは常に募集中です。
新卒採用サイト：