Claude Codeサブエージェント設計｜model明示指定と役割分担の実際

model を指定しないサブエージェントは、呼び出し元セッションのモデルを継承する（2026-07-16 時点、Claude Code v2.1.211 で確認）。設計を怠れば、探索の grep にも素材の列挙にも最上位の推論が走る。結論から言えば、サブエージェントは役割ごとに model を明示し、権限を絞り、生成役と検証役を別コンテキストに分けて設計するのがよい。本稿は筆者が実運用している定義ファイルの実物で、その設計を整理する。

モデル継承の罠

サブエージェントは frontmatter に model を書ける。書かなければどうなるか——呼び出し元のセッションで走っているモデルをそのまま継承する。上位モデルで設計や執筆を進めている最中に、探索用の使い捨てエージェントを起動すると、その grep や一覧作成にまで最上位の推論が動員される。列挙や読み取りのような判断の余地がない使い捨て作業に、能力の上限を張る必要はない。ここで浪費が生まれる。

この継承は便利であると同時に落とし穴でもある。明示しなければ「上位モデルで作業中はすべてが上位モデルになる」既定が静かに効くからだ。だから対策は一つで、役割にかかわらず frontmatter で必ず固定する。筆者の配分計画は、この点をサブエージェント節の冒頭に明記している。

未指定はセッションのモデルを継承するため、必ず frontmatter で明示する（本スキャフォールドは指定済み）。

役割別エージェント設計 — scanner / writer / reviewer

役割ごとに model を固定するとは、具体的にどういう定義になるか。まず探索・列挙を担う content-scanner の frontmatter を実物で示す。ここでは model だけでなく tools も絞っている点に注目してほしい。

# .claude/agents/content-scanner.md（frontmatter 実物）
name: content-scanner
description: 記事素材（devlog・自作スキル…）を列挙する読み取り専用スキャナ。…  # 説明は一部省略
model: haiku
tools: Read, Grep, Glob

model: haiku で最下位に固定し、tools を読み取り系（Read, Grep, Glob）だけに制限している。列挙役に書き込み権限は要らないし、最上位の推論も要らない。本文にも「評価・要約・記事化の提案はしない」「推測で埋めない」と規約を書き、列挙のみに役割を狭く保っている。使い捨てで大量に spawn する探索役には、この二重の絞り込み（安いモデル＋狭い権限）が効く。

一方、本文の生成と検証を担う2つは opus に固定する。

# article-writer.md
model: opus
# article-reviewer.md
model: opus   # writer とは別コンテキストで spawn される

なぜ役割で差をつけるのか。配分計画のサブエージェント表が、その理由を列で持っている。

| エージェント | model 指定 | 理由 |
| content-scanner | haiku | 探索・列挙。大量・使い捨て。継承させない |
| article-writer | opus | 本文品質は審査に直結。実装系既定（sonnet）より1段上げる固有事情 |
| article-reviewer | opus | 生成と検証の分離。writer と同等以上 |

writer を opus に置くのは、本文品質が AdSense 審査の結果に直結するという固有事情による。実装系の既定（sonnet）より1段上げた、この記事ワークストリーム固有の判断である。reviewer も opus とするのは、後述する生成と検証の分離のため、検証側を生成側と同等以上に保つ必要があるからだ。判断の影響度が高い役割は上げ、使い捨ては下げる。この差配を frontmatter に固定するのが役割別設計の要である。

生成と検証の分離

writer と reviewer をなぜ別のエージェント・別コンテキストに分けるのか。同一の文脈で「書いて、そのまま自分で採点する」と、評価が甘くなるからである。生成の途中で積み上げた判断や前提が、そのまま採点の物差しになってしまう。自分の書いたものを自分で通したくなるバイアスから、検証を切り離す必要がある。

article-reviewer の定義は、この分離を明示している。frontmatter には「writer とは別コンテキストで…spawn される」「blocker ゼロが合格条件」とあり、生成の文脈を引き継がない独立の目で、合否を機械的な条件に落として判定する。

同じ原則はコードの委譲でも守っている。公開ツール「国会議事録 AI要約」の開発で、Web 公開モジュール一式をサブエージェントに委譲した際、完了報告（全テスト pass）をそのまま信じず、親セッションで pytest を独立に再実行して裏を取った。委譲先の自己申告は生成側の主張であり、それだけでは合格にしない。この委譲は結果として修正の再委譲ゼロで完了したが、それは完了報告と実際の整合を親側の再現で確かめたうえでの判定である。

委譲の実務 — コールド起動を前提に書く

委譲先のサブエージェントは、コールド起動である。親が把握している実装済みコードを委譲先は知らない。この前提を忘れると、存在しない関数や食い違ったシグネチャを掴んで詰まる。実務では次の三点で防いだ。

第一に、依存先の実在確認。委譲の前に、依存するデータ層などが実装済みかを ls や grep で確かめてから起動する。ルールに書いてある「はず」ではなく、実コードの定義を先に見る。第二に、シグネチャの明示確認。委譲プロンプトに「使う前に必ず Read で実シグネチャ（引数名）を確認してから呼ぶこと」と書き込む。仕様書と実コードのズレによる取り違えは、前のセッションで実際にリスクが顕在化していた。第三に、確定済み成果物の保護。作成済みのプロンプトテンプレート5本には「再作成しないこと」と明示し、上書きを防いだ。コールド起動を前提に、前提・確認手順・触ってはいけない範囲を委譲プロンプトへ書き切るのが勘所である。

よくある質問

サブエージェントは何個まで並列に走らせてよいか。 明確な最適値は実測していないので断定はしない。目安として、独立した読み取り（探索・列挙など）は並列に向く一方、同じファイルへ書き込む作業は競合を避けて直列にするか担当範囲を分けるのが安全だと考えている。

レビューを生成と同じセッションでやると何が起きるか。 生成の文脈を引き継いだまま採点すると、自分の判断を正当化する方向の、自己弁護的な評価になりやすい。だからこそ検証は別コンテキストに切り出す。

まとめ

Claude Code のサブエージェント設計は、model の継承という既定を理解するところから始まる。未指定なら呼び出し元のモデルを継承する——だから役割ごとに frontmatter で明示し、探索役は安いモデルと狭い権限に絞り、生成役と検証役は別コンテキストに分ける。委譲先はコールド起動だと割り切り、依存の事前確認とシグネチャの明示確認を委譲プロンプトへ書き切る。どのモデルをどの役割に割り当てるかの全体像はモデルと effort の配分計画で扱い、失敗回数に応じた昇格・降格の規約は別記事で単独に整理する予定である。