「自己完結プロンプト」でサブエージェント運用 — Opus = PM / Sonnet = Worker
TL;DR
最近の悩みは、「Opusが頻繁に馬鹿になるんじゃ」、寺島です。
- Opus(Fable) に設計判断を集中させ、Sonnet/Gemini に探索・実装・検証を委譲すると、品質とスループットのバランスを取りやすい
- サブエージェント委譲の成否は、背景・目的・制約・完了条件を含む「自己完結プロンプト」でほぼ決まる
- 役割分担はコスト削減だけでなく、Opus のコンテキストを判断材料に集中させるための設計でもある
- 委譲結果はそのまま信じず、PM 側が統合・レビュー・最終判断を担う
概要
LLM サブエージェントを使うときに、Opus を PM、Sonnet を Worker として運用するための実践パターンを整理します。単に「安いモデルに投げる」のではなく、どの情報を渡せば Worker が迷わず動けるか、どこを PM 側が握るべきかを扱います。
対象読者は、Claude Code などで複数エージェントを使い始めた開発者、または探索・実装・検証を並列化したいが品質低下を避けたいチームです。
目次
- 状況 / 課題
- 候補 / トレードオフ
- 採用案と理由
- 実装抜粋
- 運用上の学び
- 振り返り
- まとめ
- 参考
状況 / 課題
Claude Code を使い始めると、すべてのタスクを Opus (時点最高性能モデルを使用、以降Opusと呼称) で処理したくなる。しかし Opus はコンテキストウィンドウが有限であり、コードベース全体の探索・大量ファイルの読み込み・テスト実行ログといった「量が多いが低付加価値の情報」でコンテキストを消費すると、設計判断など高付加価値タスクのための推論品質が落ちる。
また Opus 単体では処理が直列化する。独立した複数タスクを同時進行させられない。
この問題を解決するために Opus = PM/Director (司令塔) / Sonnet = Worker (実行担当) の役割分担パターンを構築した。
Claude Code 公式ドキュメントはサブエージェントの目的をこう説明している。
"Subagents are useful for two main reasons. First, they enable parallelization: you can spin up multiple subagents to work on different tasks simultaneously."
— Building agents with the Claude Agent SDK | Anthropic Engineering
"Second, they help manage context: subagents use their own isolated context windows, and only send relevant information back to the orchestrator, rather than their full context."
— Building agents with the Claude Agent SDK | Anthropic Engineering
| 項目 | 内容 |
|---|---|
| ワークロード特性 | 複数の独立タスク (探索・実装・テスト) が同時並走する開発ワークフロー |
| SLA / 可用性 | Opus の推論品質を設計判断に集中させたい。Sonnet は速度・コストで水平スケール |
| コスト制約 | Opus ($15/$75 per MTok) は判断・レビューに限定。Sonnet ($3/$15 per MTok) で実装をカバー |
| 期限 | CLAUDE.md の MO1-MO3 ルールとして定義し常時適用 |
候補 / トレードオフ
候補 A: 全タスクを Opus 単体で処理
- 特徴: すべての処理 (探索・実装・レビュー・設計判断) を Opus が直列で行う
- 長所: コンテキストが分断されない。実装の細部まで Opus の推論が届く
- 短所: 探索・ファイル読み込み等のノイズでコンテキストが消費される。タスクが直列化し処理速度がボトルネックになる。コストが高い
- 見積コスト: すべてのトークンが Opus 料金 ($15 input / $75 output per MTok)
候補 B: Opus = PM / Sonnet = Worker の役割分担
- 特徴: Opus は設計判断・タスク分解・レビュー統括に専念。Sonnet は探索・実装・テスト実行を担う
- 長所: Opus のコンテキストをクリーンに保てる。独立タスクを Sonnet で並列実行できる。Sonnet のコスト効率が高い ($3/$15 per MTok)
- 短所: 「自己完結プロンプト」を書く設計コストが発生する。Opus と Sonnet の間の情報伝達が設計の肝になる
- 見積コスト: 設計判断は Opus、実装・探索は Sonnet。トータルコストは候補 A より大幅に低い
候補 C: 全タスクを Sonnet 単体で処理
- 特徴: すべての処理を Sonnet が担う。コストを最小化する方向
- 長所: コストが最低。レスポンスが速い
- 短所: 複雑な設計判断や大規模リファクタリングで Opus の推論品質が必要な場面で品質が落ちる
- 見積コスト: すべてが Sonnet 料金 ($3/$15 per MTok)。最安だが品質リスクがある
採用案と理由
採用: 候補 B
理由:
- 設計判断・品質に Opus の高度推論が必要な場面がある: アーキテクチャ変更・Gemini 合議・ユーザーへの最終応答など「一発の判断精度が品質全体に影響する」タスクは Opus に任せる価値がある
- 探索・実装・検証は Sonnet で十分かつ高速: ファイル探索・grep・コード読み込み・テスト実行などは処理量が多いが付加価値は低い。Sonnet で十分な精度が出る
- 並列ディスパッチによるスループット向上: 独立した複数タスクを同一メッセージで複数の Sonnet サブエージェントに dispatch することで、直列処理の数倍のスループットが得られる
Anthropic の公式ドキュメントは、サブエージェントのモデル設定についてこう述べている。
"Model alias: Use one of the available aliases:
sonnet,opus, orhaiku· Full model ID: Use a full model ID such asclaude-opus-4-7orclaude-sonnet-4-6."
現行モデル ID: claude-opus-4-8 (Opus 4.8)、claude-opus-4-7 (Opus 4.7) / claude-sonnet-4-6 (Sonnet 4.6) / claude-haiku-4-5-20251001 (Haiku 4.5)
実装抜粋
# .claude/agents/explorer.md — 探索専用サブエージェント定義例
---
name: explorer
description: コードベース探索専用。ファイル検索・grep・Read のみ。実装は行わない
model: haiku
tools: Read, Grep, Glob, Bash
---
コードベースを探索し、依頼された情報を正確に返す。実装や編集は行わない。
# .claude/agents/implementer.md — 実装専用サブエージェント定義例
---
name: implementer
description: 実装・テスト実行を担う Worker。探索結果を受け取り、コードを書いてテストを実行する
model: sonnet
tools: Read, Edit, Write, Bash
---
渡された仕様と制約に従ってコードを実装し、テストを実行する。設計判断は行わない。
CLAUDE.md に記述する MO2 準拠の「自己完結プロンプト」パターン:
## MO2: Sonnet への委譲パターン (自己完結プロンプトの必須要素)
Agent({
subagent_type: "general-purpose",
model: "sonnet",
description: "タスクの一行説明",
prompt: """
## 背景
<なぜこのタスクが必要か。前後の文脈を自己完結で記述>
## 目的
<何を達成するか。成功の定義>
## 対象ファイル / 範囲
<絶対パス or glob パターン>
## 成果物形式
<何を返すか。diff / 要約 / テスト結果 / ファイルパスなど>
## 制約
<やってはいけないこと。触ってはいけないファイル。変更禁止の挙動など>
"""
})
公式のオーケストレーターワーカーパターンとも合致する。
"a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results"
Claude Code のサブエージェントドキュメントは、サブエージェントが「分離されたコンテキストウィンドウ」で動作することを明示している。
"Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions."
運用上の学び
自己完結プロンプトが欠けた時の失敗例
「この機能を実装して」だけを Sonnet に渡すと、Sonnet は「どのファイルに書くか」「既存の型定義との整合はどうするか」を自律的に判断する。これが Opus の意図と齟齬を生み、手戻りが発生した。
背景・目的・対象ファイル・成果物形式・制約の 5 要素を明記したプロンプトに変えてから手戻り率が下がった。
並列ディスパッチの副作用
同一ファイルを複数の Sonnet サブエージェントが同時編集するとコンフリクトが起きる。事前に「どのサブエージェントがどのファイルを担当するか」をパーティショニングしてから dispatch する必要がある。
Opus が手を動かしてよい例外ケース
- 1〜2 ファイルの局所的な Edit (パス・行が既知)
- 既知パスの単発 Read (確認目的)
-
git status/git diff等の短い Bash - ユーザーへの応答テキスト生成
「3 ステップ以上 or 探索を含む or 検証が必要」が Sonnet 委譲の判断基準。
振り返り (ディレクター視点)
- 判断時に重視した軸: Opus のコンテキストをクリーンに保つことと、コスト効率の両立
- どこを譲歩したか: Sonnet に委譲することで「Opus が実装の細部まで把握している」状態は失われる。しかし設計判断のフェーズでは Sonnet からの要約だけで十分なことがほとんどだった
- もう一度判断するなら: 「自己完結プロンプト」のテンプレートをもっと早期に CLAUDE.md に定義すべきだった。テンプレートなしで委譲すると Sonnet の挙動がばらつく
まとめ
- Opus は設計判断・レビュー統括・最終応答に専念し、探索・実装・テストは Sonnet サブエージェントに委譲する
- 自己完結プロンプトには「背景・目的・対象ファイル・成果物形式・制約」の 5 要素が必須
- 独立タスクは同一メッセージで複数 Sonnet を dispatch することで処理速度を向上できる
- モデル指定は
model: "sonnet"(エイリアス) またはmodel: "claude-sonnet-4-6"(フル ID) で行う - サブエージェントは独立したコンテキストウィンドウを持つため、Opus のコンテキストをクリーンに保てる
参考
公式 1 次資料
- Create custom subagents — Claude Code Docs — サブエージェントの定義方法・モデル設定・コンテキスト分離の公式ドキュメント
- Building effective agents | Anthropic Research — オーケストレーターワーカーパターンを含むエージェント設計ベストプラクティス
- Building agents with the Claude Agent SDK | Anthropic Engineering — Claude Agent SDK の設計思想と並列化・コンテキスト管理の解説
- Claude Code Advanced Patterns: Subagents, MCP, and Scaling to Real Codebases | Anthropic Webinar — サブエージェント・MCP を活用した高度なパターンのウェビナー資料
関連事例
- How we built our multi-agent research system | Anthropic Engineering — Anthropic 自身によるマルチエージェントリサーチシステムの構築事例
- Building a C compiler with a team of parallel Claudes | Anthropic Engineering — 並列 Claude チームで C コンパイラを構築した事例。並列ディスパッチの実践例
- Enabling Claude Code to work more autonomously | Anthropic — Claude Code の自律性向上に関する公式発表
補足解説
- Multi-Agent Orchestration: How to Coordinate AI Agents | GuruSup — マルチエージェントオーケストレーションのパターン解説 (Director-Worker パターンの文脈)
- The Orchestration of Multi-Agent Systems | arXiv:2601.13671 — マルチエージェントシステムのアーキテクチャと協調プロトコルに関する学術論文



