サブエージェントのモデルなんてどれでも同じだろう──そう思っていた時期が、私にもありました。

結論：サブエージェントのモデル選択は「コスト最適化の余地」ではなく「成否を分ける設計判断」

Claude Codeのサブエージェント（subagent）に使うモデルを5種類切り替えて、同一のバグ修正タスク5件をそれぞれ3回ずつ試行しました。結果、成功率は最低20%から最高100%まで大きく割れました。

この記事では、実験の設計・結果・考察をすべて公開し、タスクの粒度に応じたモデル選択の実務ガイドラインを提案します。

検証の動機：v2.1.248→251でサブエージェントモデル指定の仕様が変わった

Claude Code v2.1.248以前では、サブエージェントが使用するモデルはメインエージェントと同一モデルに固定されていました。v2.1.251でmodel_configによるサブエージェント単位でのモデル指定が可能になり、設定の自由度が大きく向上しています。

// ~/.claude/settings.json の設定例
{
  "model_config": {
    "subagent": {
      "model": "claude-sonnet-4-20250514"
    }
  }
}

この変更を受けて、次のような疑問が浮かびました。

サブエージェントに安いモデルを割り当てればコスト削減できるのでは？
逆に、高性能モデルを割り当てると成功率はどれだけ上がるのか？
そもそもモデル間で差は出るのか？

定量的に答えている記事が見当たらなかったため、自分で検証することにしました。

環境・前提条件

項目	値
Claude Code バージョン	v2.1.251
メインエージェントモデル	Claude Sonnet 4（固定）
OS	macOS Sequoia 15.5
対象リポジトリ	TypeScript製のWebアプリ（約15,000行）
Node.js	v22.x
試行回数	各バグ × 各モデル × 3回

重要な前提： メインエージェントのモデルはClaude Sonnet 4で統一し、サブエージェントのモデルのみ差し替えて比較しました。サブエージェントはメインエージェントから呼び出される調査・修正の子タスク実行を担います。

実験設計

用意したバグ5件

実際のプロジェクトから抽出した、再現性のあるバグを5件選定しました。

#	バグ概要	難易度	分類
B1	`null`チェック漏れによるランタイムエラー	低	単純修正
B2	APIレスポンスの型不一致（フィールド名typo）	低	単純修正
B3	useEffectの依存配列不備による無限レンダリング	中	リファクタ
B4	認証ミドルウェアの処理順序バグ	中	リファクタ
B5	状態管理の設計不備（複数コンポーネント間の競合）	高	設計判断

比較モデル5種

略称	モデル	入力単価（/1Mトークン）
Sonnet	Claude Sonnet 4	$3
Opus	Claude Opus 4	$15
Haiku	Claude Haiku 3.5	$0.80
GPT-4o	GPT-4o (2025-04)	$2.50
Gemini	Gemini 2.5 Flash	$0.15

※ GPT-4oとGemini 2.5 FlashはClaude Codeの外部モデルプロバイダ連携機能を使用して接続しました。価格は2025年6月時点の公開価格です。

成功判定

npm test で既存テストがすべてパス
該当バグに対して事前に書いた回帰テスト（非公開）がパス
生成されたdiffが論理的に正しいことを目視確認

3条件すべて満たした場合のみ「成功」としました。

結果テーブル

成功率（3回中の成功回数 / 3）

バグ	Sonnet	Opus	Haiku	GPT-4o	Gemini
B1（null チェック）	3/3 ✅	3/3 ✅	3/3 ✅	3/3 ✅	2/3
B2（型不一致）	3/3 ✅	3/3 ✅	2/3	3/3 ✅	3/3 ✅
B3（useEffect）	3/3 ✅	3/3 ✅	2/3	1/3	1/3
B4（認証順序）	2/3	3/3 ✅	1/3	1/3	0/3 ❌
B5（状態管理設計）	2/3	3/3 ✅	1/3	0/3 ❌	0/3 ❌
総合成功率	87%	100%	60%	53%	40%

実行時間・トークン消費・コスト（全15回の中央値）

モデル	中央実行時間	中央トークン消費（入+出）	中央コスト/回
Sonnet	48秒	28,000	$0.14
Opus	72秒	35,000	$0.75
Haiku	32秒	31,000	$0.04
GPT-4o	55秒	26,000	$0.11
Gemini	25秒	24,000	$0.01

深掘り：なぜHaikuが健闘し、Geminiが苦戦したのか

Haikuの意外な健闘（成功率60%）

正直、Haikuには期待していませんでした。しかし、単純修正タスク（B1, B2）での成功率は83% と高く、コストあたりの成功率では全モデル中トップです。

理由を分析すると、以下の特徴が見えてきました。

メインエージェント（Sonnet）が的確に指示を出せている場合、サブエージェント側は「指示に従って修正するだけ」で済む
Haikuの弱点はコンテキスト理解の浅さだが、スコープが狭いサブタスクではこの弱点が顕在化しにくい
応答速度が速いため、失敗しても再試行のコストが低い

Geminiの苦戦（成功率40%）

Gemini 2.5 Flashが最も苦戦しました。特にB4（認証順序）とB5（設計判断）は3回とも全滅です。

Geminiの失敗はほとんどが失敗パターン1と2に該当しました。Claude Code のツール呼び出し規約（XML形式のレスポンス構造）との相性の問題もあると考えられます。Claude Codeは元々Claudeモデルに最適化されたプロンプト設計になっているため、外部モデルでは指示の解釈にズレが生じやすいと言われています。

GPT-4oの中途半端さ（成功率53%）

GPT-4oは単純修正では安定していましたが、中〜高難易度タスクで急激に成功率が落ちました。特にB5（設計判断）は0/3です。

原因として推測されるのは以下の点です。

Claude Code のシステムプロンプトはClaude向けに最適化されており、GPT-4oではツール使用の精度が落ちる
複数ファイルにまたがる修正で、ファイル間の整合性を保つ能力にモデル差が出る

実務での使い分けガイドライン

タスク粒度別モデル選択フローチャート

以下のフローチャートは、サブエージェントに割り当てるモデルをタスクの粒度に応じて選択するためのガイドラインです。

具体的な設定例

コスト最適化構成： 日常的な開発作業向け

{
  "model_config": {
    "mainAgent": { "model": "claude-sonnet-4-20250514" },
    "subagent": { "model": "claude-haiku-3.5-20241022" }
  }
}

品質最優先構成： 重要なリファクタリングや設計変更時

{
  "model_config": {
    "mainAgent": { "model": "claude-sonnet-4-20250514" },
    "subagent": { "model": "claude-opus-4-20250514" }
  }
}

バランス構成： 多くのチームにおすすめ

{
  "model_config": {
    "mainAgent": { "model": "claude-sonnet-4-20250514" },
    "subagent": { "model": "claude-sonnet-4-20250514" }
  }
}

コストシミュレーション

1日にサブエージェントが50回呼ばれると仮定した場合の月間コスト（20営業日）：

構成	月間コスト	想定成功率
Haiku構成	$40	60%
Sonnet構成	$140	87%
Opus構成	$750	100%

失敗時の手動修正コスト（エンジニアの時間）を考慮すると、Sonnet構成がトータルコストで最も効率的という結論になりました。Haikuは単純タスクが多いプロジェクトでは十分選択肢に入ります。

実験の限界と注意点

この実験には以下の限界があります。

サンプルサイズが小さい（5バグ × 3回試行）。統計的に有意な差とは言い切れません
単一のTypeScriptプロジェクトでの検証であり、言語やフレームワークが変わると結果も変わる可能性があります
LLMのバージョンアップにより、結果は数週間で変わり得ます
外部モデル（GPT-4o, Gemini）はClaude Codeとの統合レイヤーで追加のオーバーヘッドがある可能性があり、純粋なモデル性能の比較とは言い切れません

まとめ

サブエージェントのモデル選択で成功率は20%〜100%まで割れる。「どれでも同じ」ではなく、タスク難易度に応じた使い分けが必要
コスパ最強はSonnet（メインと同一モデル）。 単純タスク限定ならHaikuも有力。設計判断を伴うタスクにはOpusが圧倒的
Claude Code外部モデル（GPT-4o, Gemini）はサブエージェント用途では現時点で非推奨。 ツール呼び出し規約との相性問題があり、成功率が安定しない

参考リンク