はじめに
Claude Code でマルチエージェント開発をしていると、必ずぶつかる問題があります。
「全部 Opus で走らせるとトークンが溶ける。かといって Sonnet だと判断をミスる」
この記事では、
- Sonnet 4.6 / Opus 4.7 / Opus 4.8 の違い（ベンチマーク・料金）
- 「Opus は Sonnet の5倍燃える」という体感の正体
- マルチエージェント構成で、エージェントごとにモデルを自動振り分けする実践
を、実際に運用している「大名システム」（殿＝メインエージェント、家老＝設計エージェント、足軽＝実装エージェント、というロールプレイ型のマルチエージェント運用）を題材にまとめます。
本記事のベンチマーク・料金は 2026年5月時点の公開情報に基づきます。最新の正確な数値は必ずClaudeCode公式 Pricing ページで確認してください。
1. モデル3世代の違い
1-1. API 料金（100万トークンあたり 入力 / 出力）
| モデル | 入力 | 出力 | Sonnet比（単価） |
|---|---|---|---|
| Opus 4.7 / 4.8 | $5.00 | $25.00 | 約 1.67倍 |
| Sonnet 4.6 | $3.00 | $15.00 | 1.0倍 |
| Haiku 4.5 | $1.00 | $5.00 | 0.33倍 |
ポイントは、Opus 4.7 → 4.8 で単価は据え置きだということ。値上げなしで性能だけ上がった世代です。乗り換えに金銭的デメリットはありません。
1-2. Opus 4.8 のベンチマーク（4.7比）
| ベンチマーク | Opus 4.7 | Opus 4.8 |
|---|---|---|
| SWE-bench Verified | 87.6% | 88.6% |
| SWE-bench Pro（難） | 64.3% | 69.2% |
| Terminal-Bench 2.1 | 66.1% | 74.6% |
| OSWorld（PC操作） | 82.8% | 83.4% |
| MCP-Atlas | 77.3% | 82.2% |
数値の伸び以上に、実務で効くのは次の2点です。
① コードの自己検証が約4倍厳格に
Opus 4.8 は「自分が書いたコードの欠陥を見逃さず指摘する」確率が 4.7 比で約4倍改善したとされています。エージェント運用での「黙って間違ったコードを通してしまう」事故が減った、というのが体感的に一番大きい変化です。アラインメント面でも同社の最高水準（Mythos Preview 相当）まで来ています。
② Fast mode が約2.5倍速・3倍安く
/fast（Claude Code の高速モード。小さいモデルに落とすのではなく Opus のまま出力を速くする）が、約2.5倍速・コスト3分の1に改善。Opus 4.8 / 4.7 / 4.6 で利用できます。
リリースは 2026-05-28、Opus 4.7 のわずか6週間後というハイペース。驚愕。
2. 「Opus は Sonnet の5倍燃える」の正体
ここが誤解されやすいポイントです。
トークン単価で見ると、Opus は Sonnet の約 1.67倍であって、5倍ではない。
では、なぜ体感は「5倍燃えてる」になるのか?
答えは トークンの「消費量」です。
- Opus は拡張思考（thinking）と出力のトークンを Sonnet より多く吐く傾向がある
- つまり「1トークンの値段」ではなく「タスク1件あたりに吐くトークン量」が多い
- 単価 1.67倍 × 消費量 2〜3倍 ＝ 実コストで体感 3〜5倍
実コスト ≒ トークン単価(1.67x) × 消費トークン量(2〜3x)
≒ 体感 3〜5倍
なので「5倍燃えてた」という直感は、単価ではなく消費量込みの実コストとしては概ね正しいわけです。
そして、ここから導かれる結論はシンプルです。
軽いタスクを Sonnet / Haiku に振り分けるだけで、実コストは大きく下がる。
3. マルチエージェントでモデルを「自動振り分け」する
3-1. 大前提：Agent ツールの model パラメータ
Claude Code の Agent ツール（サブエージェントを起動するツール）には model パラメータがあり、起動1回ごとにモデルを指定できます。
優先順位は次の通り。
① 起動時の model 指定 > ② エージェント定義の frontmatter > ③ 親（呼び出し元）のモデルを継承
ここで効いてくる重要な性質が2つあります。
性質1：明示指定は親継承より強い
model を明示すれば親（メインエージェント）のモデルに関係なく、そのモデルで子エージェントが起動します。
性質2：だから「安い親が、高い子を雇える」
これがマルチエージェント運用での肝です。
メインエージェントが Sonnet でも、子エージェントに
model: "opus"を渡せば、子だけ Opus 4.8 で走る。
つまり、こういう逆転構成が組めます。
メイン(オーケストレーター) = Sonnet 4.6 ← 安い。調整・中継で量を出す役
├─ 設計エージェント = Opus 4.8 ← 重い設計判断だけ高いモデルに任せる
└─ 実装エージェント = Opus 4.8 / Sonnet ← 内容で振り分け
「安いオーケストレーターが、重い思考だけ高いモデルにアウトソースする」という構成です。
3-2. 「自動」の正体（誤解を避けるために）
ここは正直に書いておきます。
裏で機械学習ルーターがタスク難易度を判定して勝手に振り分けてくれる、という機能ではありません。
「自動」の実体は、オーケストレーター（メインエージェント）が起動時にルールに従ってmodelを選ぶことです。
裏を返せば、振り分けルールを明示的にスキル定義へ書き込んでおけば、メインが Opus でも Sonnet でも同じルールで確実に振り分けが効くということです。親継承に頼らず毎回 model を明示するのがコツです。
4. 大名システムへの実装
自分の Claude Code は、ロールプレイ型のマルチエージェント運用「大名システム」で動いています。
| 役職 | 実体 | 責務 |
|---|---|---|
| マスター | 人間 | 大方針・最終承認 |
| 殿 | メイン Claude | 軍議主催・指示・統合判断（直接コーディングはしない） |
| 家老 | Explore / Plan サブエージェント | 偵察・設計・タスク分解 |
| 足軽 | worktree 隔離エージェント | 個別タスクの実装・テスト |
これに「役職別モデル振り分け」を組み込みました。
4-1. 確定版の振り分け表
| 役職 | タスク | 指定する model
|
|---|---|---|
| 殿 | 軍議主催・レビュー・統合判断 |
opus(4.8) 推奨固定 |
| 家老 | 設計・タスク分解・大規模偵察 |
opus(4.8) |
| 家老 | 軽い調査（ファイル探索・規約確認のみ） | sonnet |
| 足軽 | 認可・セキュリティ・DB設計(DDL)・根治治療・複雑な型 |
opus(4.8) |
| 足軽 | FE/BE 実装・テスト・E2E・ビルド確認・調査 | sonnet |
| 足軽 | 単純 grep/置換・ファイル列挙・定型雑務 | haiku |
設計指針：
- 迷ったら重い方（opus 4.8）に倒す。 間違えると影響が大きい領域（認可・セキュリティ・DB・根治治療）は必ず Opus。
- コスト最重要なのは量が出る実装・テスト系の足軽。 ここを Sonnet にするのが節約で一番効く。
- 殿（メイン）を Sonnet にするのは要注意。 殿は全エージェントの成果を読んで最終判断する役なので、ここをケチると判断ミス→手戻りで余計に燃やす「偽の節約」になりがち。原則 Opus 4.8 固定、割り切った調整役運用としてのみ Sonnet を許容。
4-2. スキル定義への組み込み
Claude Code のカスタムスラッシュコマンド（スキル）に、振り分けルールを直接書き込みます。これでコマンドを叩くたびに自動適用されます。
/出陣（実装フェーズ）のスキルに追記したルール抜粋：
## モデル振り分けルール【必須】
各エージェントを `Agent` 起動する際は、`model` パラメータを毎回明示指定する。
親（殿）のモデル継承に頼らないこと。これにより殿が Opus 4.8 でも Sonnet でも、
同一ルールで自動的に同じ振り分けが効く。
`Agent` の `model` 指定は親継承より優先されるため、
殿が Sonnet でも家老・足軽を opus(4.8) に振り向けられる。
| 役職 | タスク | 指定する model |
|------|--------|----------------|
| 殿 | 軍議主催・レビュー・統合判断 | opus(4.8) 推奨固定 |
| 家老 | 設計・タスク分解・大規模偵察 | opus(4.8) |
| 家老 | 軽い調査（探索・規約確認のみ） | sonnet |
| 足軽 | 認可・セキュリティ・DB・根治治療・複雑な型 | opus(4.8) |
| 足軽 | 実装・テスト・E2E・ビルド確認・調査 | sonnet |
| 足軽 | 単純 grep/置換・ファイル列挙・定型雑務 | haiku |
/軍議（設計フェーズ）のスキルでは、タスク分解の表に model 列を足しておくと、設計段階で「どの部隊をどのモデルで走らせるか」まで決まります。
| 部隊 | 担当範囲 | 依存 | model |
|------|----------|------|-------|
| Entity/Repo | ... | なし（先行） | sonnet（DDL/認可絡みは opus 4.8） |
| Service | ... | Entity完了後 | sonnet（根治治療・複雑な型は opus 4.8） |
| Controller/DTO | ... | Service完了後 | sonnet（認可・セキュリティは opus 4.8） |
| Test | ... | 全部隊完了後 | sonnet |
4-3. 並列でもモデル混在OK
worktree 隔離（Agent(isolation: "worktree")）を使えば、各エージェントは物理的に別ディレクトリで動きます。そこにモデル指定を組み合わせると：
足軽A (sonnet) ← FE実装 ┐
足軽B (sonnet) ← テスト作成 ├─ 並列・各worktree隔離・モデル混在
足軽C (opus4.8)← 認可ロジック設計 ┘
ディレクトリも別、モデルも別、で完全独立に走ります。
5. できること / できないこと（正直な整理）
| やりたいこと | 可否 | 補足 |
|---|---|---|
| 子エージェントごとにモデルを変える | ✅ |
Agent の model パラメータ |
| デフォルトを Opus 4.8 に固定 | ✅ | セッションモデル設定 or 親継承 |
| メインが Sonnet でも子を Opus 4.8 に | ✅ | 明示指定は親継承より優先 |
| ルールで自動振り分け | ✅ | スキル定義にルールを書き込む |
| メイン自身のモデルを自動で切り替える | ❌ | メインのモデルはユーザー設定（/model・/fast）固定。ターン中に自律的には変わらない |
最後の行が唯一の制約です。「重い議論のときだけメインが勝手に Opus、雑談は勝手に Sonnet」という自己切り替えはできません。切り替えられるのは、あくまで自分が起動する子エージェントです。
6. まとめ
- Opus 4.7 → 4.8：同価格で「速く・安く（fast mode）・自分のコードを間違えにくく（自己検証4倍）」なった純粋な上位互換。乗り換えデメリットほぼなし。
- Sonnet vs Opus：単価差は約1.67倍だが、消費量込みの実コストは体感3〜5倍。だから振り分けが効く。
-
マルチエージェント運用の定石：
- 量が出る実装・テスト → Sonnet（節約の主戦場）
- 判断が重い設計・認可・DB・根治治療 → Opus 4.8
- 統合判断するメイン → 原則 Opus 4.8 固定（ケチると偽の節約）
-
実装は
Agentのmodelを毎回明示し、ルールをスキル定義に書き込めば、メインのモデルに依存せず自動で振り分けが効く。
「全部 Opus で溶かす」でも「全部 Sonnet でミスる」でもなく、役職とタスクでモデルを使い分ける。これだけで体感コストはかなり変わります。
ここまでくると完全な実力社会の模倣段階です。重たいタスクは有能な管理職が部下の能力ごとに振り分ける・・・。
トークン節約になれば、なんでもオッケーですね！
4.7は結構微妙だな。と思いSonnet4.6メインで開発していましたが、Opus4.8 は体感、「賢っ！」となったので、トークン抑えつつ、使えるときは使っていきたいと思っています。