「自己完結プロンプト」でサブエージェント運用 — 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, or haiku · Full model ID: Use a full model ID such as claude-opus-4-7 or claude-sonnet-4-6."

— Create custom subagents — Claude Code Docs

現行モデル 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"

— Building effective agents | Anthropic

Claude Code のサブエージェントドキュメントは、サブエージェントが「分離されたコンテキストウィンドウ」で動作することを明示している。

"Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions."

— Create custom subagents — Claude Code Docs

運用上の学び

自己完結プロンプトが欠けた時の失敗例

「この機能を実装して」だけを 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 — マルチエージェントシステムのアーキテクチャと協調プロトコルに関する学術論文