同じ作業をする2つの会社のAI請求書が、ちょうど2倍差をつけ始めている。
高いモデルをたくさん使うからではなく、1つのモデルで全部やらせるからです。Augment Codeが2026年4月に公開したコストモデルによると、200コールのコーディングセッション1回はOpus 4.6単独で$2.02、同じ作業を4役割に分けると$0.98。51%の差が、モデル価格ではなくモデル配置から生まれているんです。
1モデルで全部やると、何が問題なんですか?
単一モデルは2種類の失敗を同時に起こします。単純なタスクには過剰な計算リソース(お金の無駄)、複雑なタスクには推論力不足(品質の無駄)。同じモデルが2方向に同時に失敗するのが核心です。
具体的なコスト差を見てみましょう。Anthropicの2026年4月公式価格基準です。
| モデル | 入力 ($/Mトークン) | 出力 ($/Mトークン) | 主な用途 |
|---|---|---|---|
| Opus 4.6 | $5.00 | $25.00 | 複雑な推論、アーキテクチャ判断 |
| Sonnet 4.6 | $3.00 | $15.00 | 一般コード生成、マルチファイル作業 |
| Haiku 4.5 | $1.00 | $5.00 | ファイル探索、簡単な編集、リント |
OpusとHaikuは入力5倍、出力5倍の差。ところがコーディングエージェントが送る200コールの半分以上は、grep、ディレクトリ探索、import追跡などのパターンマッチング作業。これをOpusで処理するのは、フェラリでスーパーに行くのと同じです。
DEV Communityの分析では、コーディングエージェントが使うトークンの70%が無駄 — 過剰なファイル読み込み、繰り返し探索、冗長なツール出力。この70%領域をHaikuに移すだけで、5倍のコスト削減ができるんです。
では「4役割」って具体的に何ですか?
2026年に入ってAnthropic、OpenAI、Augment Code、CrewAIが同時に採用したパターンが4役割ルーティング。コーディングエージェントの全タスクを4種類の役割に分類し、役割ごとに違うモデルを割り当てます。
- Coordinator(調整役) — Opus 4.6
要件をサブタスクに分解し、下位エージェントを調整。最も推論の深さが必要な役割。ここで間違えると下位タスクが全て破綻します。SWE-bench Verified 80.84%、MCP Atlasツール使用ベンチマーク1位。 - Implementor(実装役) — Sonnet 4.6
実際のコード生成、マルチファイル編集、テスト作成。1回の生成あたり出力トークンがOpus比67%安い。SWE-bench 79.6%でOpusとの差はわずか1.2点。 - Navigator(探索役) — Haiku 4.5
ファイル検索、grep、シンボル解決、ボイラープレート生成。Opus比で入力5倍・出力5倍安い。パターンマッチング作業ではSonnetとの品質差はほぼ計測不能。 - Reviewer(レビュー役) — GPT-5.2
非同期コードレビュー、セキュリティ分析。ツール呼び出しが多い = 深い分析。DryRun Securityレポートでは Codex(GPT-5.2)はセキュリティ問題-1、Claudeは+4。レビューは速度より徹底さが重要な領域です。
実際のコスト差はどれくらい?
Augment Codeが公開した200コール標準セッションのシミュレーション。同じ作業を2つの方法で処理した時の差です。
| タスク種別 | 頻度 | 単一Opus | 4役割ルーティング |
|---|---|---|---|
| アーキテクチャ計画 | 1回 | $0.140 | $0.140 (Opus) |
| 複雑な実装 | 3回 | $0.780 | $0.468 (Sonnet) |
| 素早い編集 | 8回 | $0.420 | $0.084 (Haiku) |
| コードレビュー | 4回 | $0.300 | $0.060 (Haiku) |
| テスト生成 | 4回 | $0.380 | $0.228 (Sonnet) |
| セッション合計 | 20回 | $2.02 | $0.98 (51%↓) |
最大の削減は素早い編集とコードレビュー領域です。$0.72 → $0.14に減り、これが全削減量の56%を占めます。AWS BedrockのIntelligent Prompt Routingも最大30%削減を報告、AnthropicとOpenAIは非同期作業に50%バッチ割引まで上乗せできるんです。
Static·Dynamic·Hybrid — どのルーティングを選ぶべき?
役割分担は決まっても、「どう振り分けるか」を決めるルーティング方式は3種類が共存します。それぞれ適した状況が違います。
| 方式 | 適した場面 | 遅延追加 | 設定難易度 |
|---|---|---|---|
| Static(事前ルール) | 役割が固定されたパイプライン | なし | 低 — agentごとにモデル指定 |
| Dynamic(RouteLLM等) | 同じ役割内でタスク難易度がばらつく | 50〜200ms/コール | 中 — ルーティング分類器の学習 |
| Hybrid(OpenAIパターン) | プランナーが実行モデルも選ぶ | プランニング段階のみ | 中 — プランナー + プール |
1日の呼び出しが500回未満ならStaticが最も効率的。Dynamicルーティングは分類器の運用コストが削減効果を食いつぶします。Claude Codeのsub-agents API、CrewAIのLLMインスタンスパターンはどちらもStatic方式で、ほとんどの1人/小規模チームはここから始めます。
核心だけ整理: 始め方
- 1週間のトークン使用量をタスク種別に分解する
Claude CodeやCursorのログから、5つの種類(アーキテクチャ/実装/編集/レビュー/テスト)に分類。どこにトークンが最も流れているかを見ないと、ルーティングのROIは見えません。 - 最も頻度が高いタスク種別をHaikuに移す
たいていはファイル探索・grep・lint。1週間運用してHaiku結果をそのまま受け入れられる比率を測定。80%以上ならそのまま、未満ならSonnetに昇格。 - Coordinator席は絶対にダウングレードしない
ここで間違えると下位エージェントが全て無駄に動きます。OpusのMCP AtlasスコアがSonnetより15〜19点高いのはまさにこの差。素早い反復が必要なプロトタイプの時だけ一時的にSonnetに下げてもOK。 - エージェントに反復上限25回を設定する
トークン無駄の大部分はルーティングではなくエージェントループ(同じ試行の繰り返し)から生まれます。Aider、Cline、Claude Code全てがmax-iterationsパラメータをサポート。25回で解けないなら50回でも解けません。
