Claude Code を使い始めると、最初は1つのプロンプトで全部済ませようとします。しかし複雑な業務になるほど、1つのエージェントに「考える・作る・検証する」を全部やらせると品質が落ちる ことに気づきます。
そこで使うのが サブエージェント（subagent） です。役割の異なる小さなエージェントを並べ、Claude Code 本体から呼び出して連携させる仕組み。私の実運用でも、これを導入してから 品質と速度の両方が安定してきました。
本記事では、Claude Code のサブエージェント機能を 実運用レベルで使い切るための設計パターン を解説します。「Planner（計画）→Generator（実装）→Evaluator（検証）」という3層構造を中心に、設計から実装、呼び分けまで具体的に紹介します。
サブエージェントとは何か：単一エージェントの限界
Claude Code のサブエージェントは、メインのエージェントから呼び出せる 「役割専用の小さなエージェント」 です。プロジェクト配下の .claude/agents/ にマークダウンファイルを置くだけで定義できます（ファイルを直接編集した場合はセッション再起動、もしくは /agents コマンド経由で反映できます）。
なぜ役割を分けるのか。1つのエージェントに全部任せると、以下の問題が起きるからです。
- 視点の混線: 設計を考えながらコードを書くと、設計が曖昧なまま実装が走る
- 自己検証の甘さ: 自分が書いたコードを自分でレビューしても、見落としが多い
- コンテキスト肥大: 全部を1セッションでやると、長くなった会話の中で重要情報が埋もれる
これらは 「役割を分けて、別のエージェントに渡す」 ことで解決します。設計者・実装者・レビュアーがそれぞれ独立して仕事をする ── これは現実の開発組織と同じ構造です。
代表的な3層パターン：Planner / Generator / Evaluator
サブエージェントの設計には流派がありますが、私が最も再現性が高いと感じているのは 3層パターン です。それぞれの役割を整理します。
| 役割 | 担当 | 出力物 |
|---|---|---|
| Planner | 要件分析・設計・タスク分解 | 実装計画書／タスク一覧 |
| Generator | 計画に従ってコード／資料を生成 | 実装ファイル／成果物 |
| Evaluator | 成果物を5観点で検証 | 合否判定／修正提案 |
この3層を順に呼べば、設計→実装→検証という 「自然な開発サイクル」 がそのままClaude Code内に再現できます。Planner が出した計画を Generator が読み、Generator の成果物を Evaluator がレビュー。各エージェントは 自分の役割だけに集中 するので、思考が散らからず品質が安定します。
実装方法：マークダウン1枚で定義する
Claude Code のサブエージェントは .claude/agents/ 配下にマークダウンファイルを置けば自動的に認識されます。フォーマットは以下のとおりシンプルです。
--- name: planner description: 要件分析・設計・タスク分解を行うアーキテクト tools: Read, Glob, Grep, Bash, TodoWrite --- あなたは要件分析と設計を専門とするアーキテクトです。 ユーザー要件を受け取ったら、以下を必ず実施してください。 1. 既存コードと関連ドキュメントを読む 2. 要件を満たすための実装方針を3案以上検討する 3. 採用案の理由と却下案の理由を明示する 4. タスクを「1コミット単位」に分解する 5. 受け入れ基準（Definition of Done）を書く 実装には踏み込まないでください。計画書だけを出力します。
ポイントは 「ツール権限の絞り込み」 です。Planner には Read 系のみ、Generator には Write／Edit 系まで、Evaluator にはテスト実行系まで ── このように 役割に必要な権限だけ を与えることで、エージェントが「自分の領分」を理解しやすくなります。
3層の具体例：Planner の中身
Planner エージェントには「設計者として何を考えるか」を明文化したシステムプロンプトを書きます。私が実運用で使っている要素を挙げます。
- 既存コードを必ず読む（推測で設計しない）
- 代替案を3つ以上挙げ、トレードオフを明示する
- 採用理由・却下理由を残す（後でレビューできるように）
- タスクは1コミット単位に細かく分解する
- 各タスクに受け入れ基準を明記する
これらを書いておくと、毎回プロンプトで指示する必要がなくなります。「Planner を呼べば、自動的にこの考え方で動く」 という資産になります。
3層の具体例：Generator の中身
Generator は計画書を読み、実装に集中します。重要なのは 「計画に書かれていない設計判断をしない」 こと。判断が必要な場合は、メインエージェントに差し戻して再計画させます。
- Planner の出力したタスク一覧をそのまま受け取る
- 各タスクを順に実装する
- 新たな設計判断が必要な場合は実装を止めて報告する
- 各タスク完了時に「何を変更したか」をログに残す
Generator が暴走する典型パターンは 「ついでに〇〇も直しておきました」。これは品質低下とコンフリクトの温床になります。計画外の変更を禁じる 一行をシステムプロンプトに必ず入れます。
3層の具体例：Evaluator の中身
Evaluator は完成した成果物を 「複数観点でチェック」 します。観点を明文化しておくと、毎回均質なレビューが返ってきます。私のテンプレートは以下の5観点です。
- ① 機能の正しさ（要件を満たすか）
- ② エッジケース／例外処理
- ③ コード品質（命名・構造・可読性）
- ④ パフォーマンスとセキュリティ
- ⑤ テストカバレッジ
出力は 「🚨重大／⚠️軽微／✅問題なし」 の3段階判定で揃えると、修正の優先順位がはっきりします。重大が1件でもあれば差し戻し、軽微だけなら採用 ── というルールを運用に組み込めます。
並列実行で時間を圧縮する
サブエージェントの真価は 「並列実行」 で発揮されます。Claude Code は1つのメッセージで複数のサブエージェントを同時に起動できます。
たとえば 3本の独立した検証 を同時に走らせれば、所要時間はほぼ最長1本分まで圧縮されます。私が実運用で使っている代表例を挙げます。
- ブログ記事の並列検証: 事実／SEO／表現リスクを3エージェントで並列レビュー
- コードの並列レビュー: テスト視点／セキュリティ視点／可読性視点を同時実行
- 資料の並列調査: 競合A／競合B／市場動向の3方向を同時に調べる
私の体感では、順次やれば30分かかる作業が、並列なら10分程度に収まります。「待ち時間」がコストになるAI時代 において、並列実行は投資対効果の高い設計のひとつです。
実運用パターン：私の業務適用例
パターン①：新規開発タスク
機能追加や新規ツール開発では、3層をフルに使います。流れは次のとおりです。
- Planner に要件を渡し、設計書とタスク一覧を出させる
- 計画書を人間が3分で確認・調整する
- Generator に計画書を渡し、実装させる
- Evaluator にレビューさせる
- 重大があれば Generator に差し戻し、軽微なら自分で修正
このフローを回すと、「設計→実装→レビュー」が30〜60分 で完了します。従来なら半日かかっていた作業が、1〜2時間で完成度の高い状態まで進みます。
パターン②：調査・リサーチタスク
市場調査・競合分析・技術選定では、専用の Researcher エージェント を複数並列で走らせます。「Web検索」「ドキュメント精読」「コードベース探索」の3種を分けるのが定石。
並列で集めた情報を、メインエージェント側で統合・要約。これだけで 調査の質と速度が大きく改善 します。
パターン③：レビュー・検証タスク
ブログ記事・契約書・提案書のレビューには、観点別のレビュアーエージェントを並列で呼びます。事実チェック、表現チェック、構成チェック、法的リスクチェック ── 観点が違えば見つかる問題も違います。
サブエージェント運用で陥りがちな落とし穴
落とし穴①：役割が曖昧で結局メインが全部やる
「使いどころが分からないからメインで全部やる」が一番もったいないパターン。役割定義（description フィールド）に「いつ呼ぶか」を明記 しておけば、Claude Code が自動で適切なサブエージェントを選んでくれます。
落とし穴②：ツール権限を絞らない
サブエージェントに全ツールを開放すると、役割を逸脱して暴走しがちです。権限は必要最小に絞る のが鉄則。Planner には書き込み権限を渡さない、Evaluator には実装ツールを渡さない、というだけで品質が大きく安定します。
落とし穴③：システムプロンプトを書きすぎる
逆に システムプロンプトを長く書きすぎる と、エージェントが指示の優先順位を見失います。「役割」「やること」「やらないこと」「出力フォーマット」の4ブロックに絞り、200〜400文字程度に抑えるのが扱いやすい目安です。
落とし穴④：並列で呼びすぎてコンテキストが混乱
並列実行は強力ですが、多数を一度に呼ぶと結果のマージで疲弊 します。私の経験則では同時並列は3〜5個までに留めるのが扱いやすく、それ以上は段階に分けるのがおすすめです（公式に明示された上限値ではなく、コンテキスト消費とのバランスを取った目安です）。
サブエージェント導入の3ステップ
これからサブエージェントを使い始めるなら、いきなり3層を作らず 「1体ずつ」 育てるのが近道です。
- Step 1: Evaluator から作る。普段のレビュー観点をマークダウン化するだけ
- Step 2: Planner を追加。設計が曖昧なまま実装が走る問題が消える
- Step 3: Generator を分離。計画→実装→検証の3層が揃う
Evaluator が最初に効くのは、「自分のアウトプットを別視点でチェックしてくれる存在」 の価値を体感しやすいからです。1体作って効果が腹落ちすれば、2体目以降は自然に作りたくなります。
まとめ：エージェントを「分業させる」だけで品質が変わる
Claude Code のサブエージェントは、技術的には「マークダウンを1枚置くだけ」ですが、運用としては 「組織設計をAIに持ち込む」 行為です。1人で全部やる人より、役割を分けたチームが成果を出すのと同じ構造。
まずは Evaluator から1体。それだけでアウトプットの安定感が変わります。「AIに役割を与える」 という発想を持ち込めば、Claude Code はソロのアシスタントから、チームに近い動き方ができるツールへと進化していきます。
コメント