サブエージェントのモデル使い分け｜判断と照合で分けた実例

サブエージェントのモデルは、書かなければ本体と同じになる

最初に、モデルがどう決まるかを確認します。Claude Code のサブエージェントの仕様は公式ドキュメントにあります。

定義ファイルの model に書けるのは、sonnet・opus・haiku・fable の別名、完全なモデルID、inherit のいずれかです。実際に使われるモデルは、次の順番で決まります。

1. 呼び出しごとの model 指定
2. 定義ファイルの model（inherit なら本体の会話と同じ）
3. 環境変数 CLAUDE_CODE_SUBAGENT_MODEL
4. 本体の会話のモデル

つまり、定義に書かず環境変数も設定していなければ、サブエージェントは本体の会話と同じモデルで動きます。本体が Opus なら、単純な作業も Opus で走ります。

指定なしの定義を埋めた

2026年9月30日の定義の点検で、model の指定がなかった16体に値を書きました。この16体には、8月16日より後に足した書籍制作の7体が含まれます。内訳は Opus 13体、Sonnet 3体です。

Sonnet にした3体の仕事は、参照画像の再現、メールの配線、Word への変換です。Opus にした13体は、販売ファネルの戦略・オファー・執筆や、書籍の設計から校正までを受け持ちます。

書かれていない役は、何も選ばれていないのではなく、本体のモデルが選ばれています。使い分けの前に、まず全定義に model を明示します。

定義を持たない一度きりの調査

その場限りの調査を振るときも同じです。model を渡さなければ、本体が Opus なら Opus で動きます。relmea では、単純な探索はその都度 sonnet か haiku を指定します。

最初は「モデルを分ければ視点が独立する」と考えていた

2026年5月20日に、検品役を Sonnet で動かす変更を入れました。当時の記録の要旨は、実装は Opus、検品は Sonnet として、モデルを分けて視点の独立性を上げる、というものです。費用の比較でも、品質の実測でもありません。

現在の検品役の定義は、この考えを使っていません。文面の要旨は次のとおりです。

• 検品役は実装の作業役と同じモデルで動く（どちらも Sonnet）
• 独立性はモデルの格でなく、コンテキストの分離で担保する
• 実装役の会話の文脈と「うまくいった」という主張は受け取らない
• 成果物と仕様と、自分で再実行したコマンドの結果だけで判断する

検品役が独立して見られる理由は、モデルの違いではなく、実装役の会話を受け取らないことに置き直しました。この訂正をいつ入れたかは、特定できていません。

2026年8月16日に、照合が主体の工程を Opus から Sonnet へ移した

使用量の上位を見た

この日、エージェントごとの使用量の内訳を見ました。上位7つの合計は45%で、内訳は次のとおりです。

• バックエンド実装の統括: 12%
• デプロイ: 9%
• 単体テストの実装: 7%
• 拡張機能の実装: 5%
• 本番診断: 4%
• 検品役: 4%
• バックエンド実装の作業役: 4%

このうち単体テストの実装、バックエンド実装の作業役、検品役の3つは、すでに Sonnet でした。残る4つ（合計30%分）は Opus でした。

同じ日に、検品役が本番診断の誤りを見つけた

同じ日、検品役がある動画アップロードツールの本番診断を点検し、3点を見つけています。

• 診断の中核の主張「非破壊の試行で、動画は1本も作っていない」が事実と違った。実際は、実チャンネルに公開状態を含む2本のレコードが作られていた
• わざと壊しても失敗しない、形だけのテストが2件あった
• 診断報告書の中に自己矛盾があった

誤った主張を書いたのは、Opus で動く本番診断の役でした。見つけたのは、Sonnet で動く検品役です。

検品役がやったのは3つです。申告を信じず、合否の検査を自分で実行し直すこと。テストに変異を入れて、失敗するか確かめること。画像を開いて実際に見ることです。この日の記録は、検証の質を決めたのはモデルの格ではなく、自分で実行して確かめる手順だった、と結論づけています。

変えた5体と、残した役

この日、次の5体を Opus から Sonnet に変えました。

• バックエンド実装の統括
• 受入試験の統括
• 本番診断
• デプロイ
• 拡張機能の実装

受入試験の統括は、使用量の上位7つには入っていません。実行と照合が主体の工程なので、一緒に移しました。

Opus に残したのは、要件定義・設計の3体、書き手、エージェントを作る役です。変更時の記録には「実行と照合が主体の工程は Sonnet で足りる」とあります。品質が落ちたときの受け皿には、検品役を置きました。変更後の内訳は Opus 50体、Sonnet 59体、指定なし7体（計116体）でした。

1. 誤りOpus の本番診断役が「動画は1本も作っていない」と報告した。実際は実チャンネルに2本作られていた
2. 発見Sonnet の検品役が、検査の再実行、テストへの変異の注入、画像の実見で見つけた
3. 判断検証の質を決めたのはモデルの格ではなく、自分で実行して確かめる手順だった
4. 変更実行と照合が主体の5体を Sonnet へ移し、受け皿に検品役を置いた。費用と品質の前後比較はしていない

測っていないこと

費用の削減額は測っていません。Sonnet に移した5体の品質について、変更前後の比較もありません。

したがって「品質が落ちなかった」とは書けません。比較していない、が事実です。1日の実例から「Sonnet は Opus と同等」や「検品は常に Sonnet でよい」とも言えません。

現在の内訳は Sonnet 67体・Opus 63体

2026年11月5日に定義ファイルを数えた内訳は、全130体で Sonnet 67体、Opus 63体、指定なし0体です。主な群を見ると、次のようになります。

すべて Sonnet の群

• ソフトウェア開発の作業役: 14体
• 学習サイトの専属: 4体

すべて Opus の群

• ウェビナー台本: 14体
• YouTube運用: 7体
• 広告運用: 3体
• エージェントの保守: 3体
• セールスコピー: 3体

分かれている群

ソフトウェア開発のフェーズの統括13体（検品役を含む）は、Sonnet 8体、Opus 5体です。Opus の5体は、要件定義、ページ実装、バックエンド計画、エージェント構築、拡張要件を担当します。

要件や計画を決める工程が Opus に残り、バックエンド実装、受入試験、デプロイ、検品は Sonnet です。ページ実装だけは実装の工程なのに Opus で、デザイン案を選ぶ段を含むとはいえ、この基準だけでは説明しきれません。

判断が主体（Opus）

• 要件定義
• バックエンド計画
• 拡張要件
• エージェントを作る役

実行と照合が主体（Sonnet）

• バックエンド実装の統括
• 受入試験の統括
• 本番診断
• デプロイ
• 検品役

自分の環境で 2026年11月5日に定義ファイルを数えた値です

基準と実物が揃っていない所

基準どおりになっていない箇所が、ほかにもあります。確認できたものを書きます。

検品の工程でも Opus のままのもの

動画の公開前検品、書籍の校正、エージェントの出荷判定は、検品の性格を持つ工程ですが Opus です。基準に沿えば移す候補ですが、まだ見直していません。

書き手の記録と実物が食い違う

8月16日の記録には、書き手は Opus に残したとあります。ウェビナーや書籍の書き手は Opus ですが、note の書き手3体は Sonnet です。8月以降に変更した履歴は無いので、この時点ですでに Sonnet でした。

工程の種類で見直していない群

YouTube運用の7体は、まとめて Opus で入れた群です。企画と検品では工程の種類が違いますが、判断か照合かで分けてはいません。

1. 検品なのに Opus動画の公開前検品、書籍の校正、エージェントの出荷判定
2. 実装なのに Opusソフトウェア開発のページ実装の統括。デザイン案を選ぶ段を含む
3. 記録と違う書き手書き手は Opus に残したという記録に対し、note の書き手3体は Sonnet
4. まとめて Opus の群YouTube運用の7体は、工程の種類で分けていない

検品役の限界と、モデルを上げる前に確かめること

検品役が確かめられる範囲

検品役は万能ではありません。2026年7月13日には、別のツールで0件返却のバグが、検品3回の合格、カバレッジ98%、68テスト全緑を通り抜けました。テストの偽物の応答が、実装と同じ誤解で書かれていたためです。

検品役は渡された成果物の範囲で確かめます。実物のAPI応答が無ければ、想定そのものが外れていても気づけません。実物との突き合わせは別の工程が要ります。そのため、検品役の合格を人のレビューが要らない唯一の根拠にはしていません。詳しくは評価データの設計の記事と検証設計の記事に書きました。

行き詰まったときの格上げ先

2026年10月1日に、行き詰まったときの格上げ先を決めました。格上げ先はモデルとは限りません。

• 原因が分からない: 専門のエージェントに回す
• 主張を確かめたい: 自分で実行して確かめる検品役に回す
• 判断が割れる、または高リスク: 立場の違う並列レビューに回す
• 推論の深さが足りない: 上位モデルに上げる

上位モデルは、推論の深さが足りないときの行き先で、4つのうちの1つです。結果が怪しいときに、まずモデルを上げる形にはしていません。

分け方のまとめ

工程ごとにモデルを分ける定石としては、運用コストの記事に書いた「前段は下位、最終判断は上位」があります。それに沿えば最後の点検は上位に置きたくなりますが、この日に誤りを書いたのは上位モデルの診断役で、見つけたのは Sonnet の検品役でした。実行と照合の振り分けは役割分担の記事でも扱っています。

relmea の分け方は、工程が判断なら Opus、実行と照合が主体なら Sonnet を基本にしています。ただし根拠は2026年8月16日の1件で、費用の削減額も品質の前後比較も測っていません。自分の環境で試すなら、まず全定義に model を書き、そのうえで照合が主体の役を1つ移し、検品役に自分で実行させて確かめるところから始められます。