1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

「自己完結プロンプト」でサブエージェント運用 — Opus = PM / Sonnet = Worker

1
Last updated at Posted at 2026-06-22

「自己完結プロンプト」でサブエージェント運用 — Opus = PM / Sonnet = Worker

TL;DR

最近の悩みは、「Opusが頻繁に馬鹿になるんじゃ」、寺島です。

image.png

  • Opus(Fable) に設計判断を集中させ、Sonnet/Gemini に探索・実装・検証を委譲すると、品質とスループットのバランスを取りやすい
  • サブエージェント委譲の成否は、背景・目的・制約・完了条件を含む「自己完結プロンプト」でほぼ決まる
  • 役割分担はコスト削減だけでなく、Opus のコンテキストを判断材料に集中させるための設計でもある
  • 委譲結果はそのまま信じず、PM 側が統合・レビュー・最終判断を担う

image.png

概要

LLM サブエージェントを使うときに、Opus を PM、Sonnet を Worker として運用するための実践パターンを整理します。単に「安いモデルに投げる」のではなく、どの情報を渡せば Worker が迷わず動けるか、どこを PM 側が握るべきかを扱います。

対象読者は、Claude Code などで複数エージェントを使い始めた開発者、または探索・実装・検証を並列化したいが品質低下を避けたいチームです。

目次

  • 状況 / 課題
  • 候補 / トレードオフ
  • 採用案と理由
  • 実装抜粋
  • 運用上の学び
  • 振り返り
  • まとめ
  • 参考

状況 / 課題

Claude Code を使い始めると、すべてのタスクを Opus (時点最高性能モデルを使用、以降Opusと呼称) で処理したくなる。しかし Opus はコンテキストウィンドウが有限であり、コードベース全体の探索・大量ファイルの読み込み・テスト実行ログといった「量が多いが低付加価値の情報」でコンテキストを消費すると、設計判断など高付加価値タスクのための推論品質が落ちる。

image.png

また 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

理由:

  1. 設計判断・品質に Opus の高度推論が必要な場面がある: アーキテクチャ変更・Gemini 合議・ユーザーへの最終応答など「一発の判断精度が品質全体に影響する」タスクは Opus に任せる価値がある
  2. 探索・実装・検証は Sonnet で十分かつ高速: ファイル探索・grep・コード読み込み・テスト実行などは処理量が多いが付加価値は低い。Sonnet で十分な精度が出る
  3. 並列ディスパッチによるスループット向上: 独立した複数タスクを同一メッセージで複数の 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 の挙動がばらつく

まとめ

image.png

  • Opus は設計判断・レビュー統括・最終応答に専念し、探索・実装・テストは Sonnet サブエージェントに委譲する
  • 自己完結プロンプトには「背景・目的・対象ファイル・成果物形式・制約」の 5 要素が必須
  • 独立タスクは同一メッセージで複数 Sonnet を dispatch することで処理速度を向上できる
  • モデル指定は model: "sonnet" (エイリアス) または model: "claude-sonnet-4-6" (フル ID) で行う
  • サブエージェントは独立したコンテキストウィンドウを持つため、Opus のコンテキストをクリーンに保てる

参考

公式 1 次資料

関連事例

補足解説

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?