Claude Code Sub-agents徹底活用｜並列タスク分散でコーディング速度を数倍に引き上げる実践パターン【2026年版】
こんにちは、株式会社TIMEWELLの濱本です。
Claude Codeシリーズの5本目は、Sub-agents（サブエージェント）をテーマにします。スキルや設定ファイルの記事を書いてきて、最後に残ったのがこの「並列でClaudeを走らせる」領域です。ここを押さえると、単発のコーディングAIが一気に小さな開発チームに変わります。
去年までは「複数セッションを自分でターミナルに並べて回す」という荒業が主流でした。2026年に入ってからはAgentツールを使った自動dispatchが安定し、コード読解、テスト実行、ドキュメント生成といった副次タスクを親セッションから切り離せるようになっています。体感としては、書籍1冊分のコードベースを読みに行っている間も、自分の会話窓はクリーンなまま保てる。この違いは地味に大きいです。
この記事では、2026年4月時点の公式仕様を踏まえて、Sub-agentsの基本から、Explore–Plan–Codeの使い分け、3つの実践パターン、そしてコスト管理までを整理します。Claude Codeのスキル機能まとめと併せて読むと、.claude/フォルダの全体像が見えるはずです。
Sub-agentsの基本構造と3種類の組み込みエージェント
Sub-agentsは、親のClaude Codeセッションが必要に応じてspawnする子エージェントです。それぞれ独立した200Kトークンのコンテキスト窓と、独自のシステムプロンプト、そして絞られたツール権限を持ちます。親が「このタスクは任せたい」と判断したときに呼び出され、作業が終わったら結果のサマリーだけを親に返す。親の会話窓にログや検索結果を流し込まずに済むのが最大の利点です。
Anthropicが公式に用意している組み込みSub-agentは3種類あります。ExploreはHaikuで動作する読み取り専用の高速調査役で、コードベースの検索や構造把握を担当します。PlanはPlan Mode時に呼ばれる研究員で、同じく書き込み権限は剥奪されており、計画策定前のリサーチに特化します。そしてgeneral-purposeは全ツール権限を持つ万能型で、探索と修正を両方こなさないといけない複雑なタスクを任されます。親はユーザーの依頼内容と各subagentのdescriptionを照合し、どの子に投げるかを自動で判断します。
ここで一つ押さえておきたいのが、2025年10月のversion 2.1.63でTaskツールがAgentツールにリネームされている点です。古い記事や設定ファイルにあるTask(worker)という書き方は、互換エイリアスとしていまも動きますが、新規に書くならAgent(worker)が公式表記になります。ドキュメントも既に全面的にAgentへ移っているので、社内で誰かがサブエージェントを書くときはここだけ注意しておけばつまずきません。
もう一つ重要な仕様として、subagentはsubagentをspawnできません。無限ネストを防ぐためのハードリミットで、「Planエージェントが中でさらにExploreを呼ぶ」ようなことは起きないようになっています。並列化の設計をするときは、この1段制限を前提に考える必要があります。
AI駆動開発を、実務で使えるところまで
トレンドを追うだけで終わらせないための実践プログラムがWARPです。元大手DX・データ戦略の専門家が、現場で動かすところまで伴走します。
カスタムSub-agentの書き方とYAMLフロントマター
組み込み3種類で足りる局面は実はそれほど多くありません。チームのコーディング規約に合わせたコードレビュー役、特定のフレームワークに詳しい実装役、リリースノートを書くドキュメント役。こうした職務固定のエージェントを定義しておくと、親が毎回長い指示を書かなくて済むようになります。
カスタムSub-agentはMarkdownファイルとして.claude/agents/（プロジェクト単位）または~/.claude/agents/（ユーザー単位）に置きます。ファイル冒頭のYAMLフロントマターでメタデータを宣言し、本文部分がそのままシステムプロンプトになる、というシンプルな構造です。
---
name: code-reviewer
description: コード変更後に自動で呼び出される熟練レビュアー。品質、セキュリティ、慣習違反を指摘する
tools: Read, Grep, Glob, Bash
model: sonnet
memory: project
---
あなたはシニアコードレビュアーです。diffを読み、品質・セキュリティ・ベストプラクティスの観点で具体的かつ実行可能なフィードバックを返してください。
必須フィールドはnameとdescriptionの2つだけ。toolsを書かなければ親セッションが持つツールをすべて引き継ぎ、書けば明示したツールだけに制限されます。ここで徹底的に絞り込むのがプロの書き方で、Read/Grep/Glob以外が不要なレビュアーに書き込み権限を渡す理由はありません。権限が広いsubagentほど予期せぬファイル変更で事故を起こしやすく、デバッグも面倒になります。
モデルはサブエージェント単位で切り替え可能で、haikuを指定すれば高速・低コストな読み取り作業に、opusやclaude-opus-4-7のようなフルモデルIDを書けば複雑な推論向けに、といった形で役割に応じた最適化ができます。調査系を全部Haikuにするだけでも、月あたりのトークン消費はかなり減ります。
命名で意外とハマりやすいのが、descriptionの書きぶりです。Anthropicのエンジニアリングブログによれば、親エージェントはsubagentのdescriptionを「ルーティングヒント」として使います。description: フロントエンド全般のような抽象的な書き方ではルーティング精度が落ち、description: React Server Componentsの境界線と'use client'の配置を検査するのように具体化したほうが、呼び出される確率が上がります。job-shaped（職務が一目でわかる）な名前と説明にするのがコツです。
Explore–Plan–Codeパターンと実践的な起動例3つ
Sub-agentsの真価は、1つの大きなタスクを「調べる」「計画する」「書く」の3段階に分解して、それぞれを別コンテキストに閉じ込めたときに発揮されます。Anthropicが公式best practicesで推奨しているのがこのExplore–Plan–Codeパターンで、私自身もこの3段階を意識してからClaude Codeの出力が安定しました。
パターン1：並列Explore＋中央Plan＋逐次Code
大きめの機能追加に入る前の調査フェーズで、読み取り専用のExploreを2〜4体並列で走らせる構成です。たとえば「認証周りをOIDC対応に移行したい」という依頼なら、以下のように親がAgentツール経由で複数のExploreをdispatchします。
- Explore A：既存の認証関連ファイル一覧とエントリーポイントの洗い出し
- Explore B：テストカバレッジとモック状況の調査
- Explore C：CI設定、環境変数、依存ライブラリのバージョン確認
それぞれが独立した200Kコンテキストで走り、親には結果のサマリーだけが返ってきます。親はそのサマリーを束ねてPlan subagentに渡し、thinkモードで設計書を作らせる。最後にgeneral-purposeがコードを書く。調査と実装のコンテキスト汚染が起きないので、親の会話窓はずっときれいなままです。
パターン2：isolation worktreeによる破壊的実験
isolation: worktreeを指定すると、そのsubagentは一時的なgit worktreeの中で動きます。親のワーキングディレクトリには一切影響が出ないので、リファクタの実験やライブラリの大規模バージョンアップなど、失敗してもロールバックしたい作業に向いています。
---
name: migration-explorer
description: 依存ライブラリのメジャーバージョンアップを試験的に実行し、差分と影響範囲をレポート
tools: Read, Edit, Write, Bash, Grep, Glob
isolation: worktree
model: sonnet
---
作業後、subagentが変更を残さなかった場合はworktree自体が自動削除される仕様になっています。「とりあえずやってみて、駄目だったら捨てる」が物理的に安全にできるのは、心理的ハードルが大きく下がる変化だと感じました。
パターン3：code-reviewer agent＋自動dispatch
コミット前やPR作成前に自動で走らせる、専門のcode-reviewer agentを1つ飼っておくパターンです。memory: projectを指定しておくと、~/.claude/agent-memory/配下にレビューで気づいたパターンや再発する指摘を蓄積してくれるため、使えば使うほど指摘の鮮度が上がります。
私の環境では、descriptionに「プッシュ前に自動で呼び出される」という文言を入れておき、親がコード変更を検知したタイミングで呼び出されるようにしています。Reviewerが返すのは「重大・警告・提案」の3レベルに分類されたフィードバックだけ。実装系subagentのログが混ざらないので、レビューの精度と親の可読性が両立できます。
これら3パターンを組み合わせると、1回の/feat相当の依頼で、Explore×3・Plan×1・Reviewer×1・Coder×1の合計6体が走ることもあります。やりすぎに見えるかもしれませんが、各subagentは役割が明確でmaxTurnsも絞っているので、暴走することは稀です。
Agent Teamsとの違いと使い分けの軸
Sub-agentsとよく混同されるのが、2026年に実験機能として登場したAgent Teamsです。公式ドキュメントでも明確に別機能として扱われていて、CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1で有効化する必要があります。初見の印象は「どっちも並列じゃん」なのですが、設計思想が違います。
Sub-agentsは1つのセッション内で親子関係を作るモデルで、子同士は互いを直接認識しません。結果は常に親に戻り、子は独立したファンアウト構造をとります。オーケストレータ・ワーカーパターンと言い換えてもよく、Anthropicが公開しているマルチエージェント・リサーチシステムの設計とも重なります。単発の調査や並列実装に向いていて、応答も早いです。
Agent Teamsはそれに対して、複数のClaude Codeセッションが共有タスクリストを介して協調するモデルです。メンバーエージェントは他のメンバーの進捗をリアルタイムで参照でき、依存関係を宣言したり、衝突を回避しながら仕事を進められます。実装としては各メンバーが独立したプロセスで動き、Anthropicが「単に複数ターミナルで並列実行するのと違い、メンバー同士が互いを認識している」と強調しているのはこの点です。
どちらを使うかの判断軸はシンプルで、「短時間で終わる単発作業か、日をまたぐ協調作業か」で切り分けています。朝の30分で機能追加を片付けたいときはSub-agentsで十分、週をまたぐリファクタリングプロジェクトならAgent Teams、という具合です。Finoutの2026年料金ガイドによれば、Agent Teamsは通常利用の約15倍、Sub-agents併用は4〜7倍のトークン消費になるため、コスト感覚としてもこの切り分けは合理的だと感じます。
ちなみに両者は組み合わせられます。Agent Teamsの各メンバーがさらに自分のSub-agentを呼ぶ構成も可能で、上位で協調・下位でファンアウトという二層設計ができます。この二層を運用に乗せるのはさすがに重いので、最初からそこを狙うのは避けたほうが無難です。
コスト管理と現場運用のチェックポイント
「強力だけどトークンを食う」が並列エージェントの宿命です。対策を仕組みに落とし込まないと、月末の請求でびっくりすることになります。ここでは現場で効いた4つの運用ルールを共有します。
1つ目は、調査系は徹底してHaikuに倒すことです。ExploreがデフォルトでHaiku固定なのはこの思想の表れで、自作の調査用subagentもmodel: haikuにしておくだけでトークン単価が大幅に下がります。逆に判断や設計を担当するPlan相当のsubagentはSonnetやOpusに寄せる。モデルの振り分けで、品質と料金のバランスが取れます。
2つ目は、tools権限を「最小から増やす」方式で書くことです。最初にtools: Readだけから始めて、不足があれば追加する。WriteやEditを安易に入れないのはもちろん、Bashも必要最小限の用途でしか渡さない。権限が広いsubagentほど意図しないトークン消費（不要なgit status連打、テスト走らせっぱなし、など）を起こしがちです。
3つ目は、maxTurnsを明示的に設定することです。何も書かないと親セッションの設定を引き継ぐため、暴走時に気づきにくくなります。調査用なら5〜8ターン、実装用でも15ターン程度を上限にしておくと、異常時の損失を数百トークン単位で止められます。
4つ目は、振り返りの仕組みをCLAUDE.mdに書き込むことです。よく使うsubagentの組み合わせ、dispatchの判断基準、失敗したパターンをCLAUDE.mdに短く追記していくと、次回のセッションから賢くなります。.claudeフォルダの全体像を整理した記事でも触れましたが、メモリの育て方がClaude Codeの満足度を決める最大の変数だと思っています。
余談ですが、私の環境ではコードレビューとセキュリティチェックをそれぞれsubagent化して、superpowersプラグインの考え方に倣って/reviewと/securityというスラッシュコマンドに束ねています。朝イチでこの2つを回すだけで、レビュー観点の漏れがだいぶ減りました。仕組み側に仕事を寄せていくと、人間は判断と意思決定に時間を使えるようになります。
並列Sub-agentsが変えるチーム開発のかたち
Claude Codeが面白いのは、「個人が使う生産性ツール」から「疑似チーム開発の環境」へと意味が変わりつつあるところです。Sub-agentsは単なる並列化機能ではなく、自分の開発プロセスを職務分担で分解し、マネジメントする発想を求めてきます。コードを書く時間が減って、agentの設計を考える時間が増える。この変化をどう評価するかは人それぞれですが、私は歓迎しています。
弊社のクライアントワークでも、DX推進のコンサルティングでWARPのAIコンサルタントが、社内のClaude Code活用基準を整備するお手伝いをしています。CLAUDE.mdのテンプレート、サブエージェントのライブラリ、権限とコストのガードレール設計までセットで設計するのが定番メニューで、導入から定着までの期間を3〜6カ月で設計することが多いです。社内ナレッジを守りながらAI開発環境を標準化したい場合は、エンタープライズ向けのGraphRAG基盤であるZEROCKと組み合わせて、社内規約や設計パターンをAIが常に参照できる形にする構成もご提案しています。
2026年のAI開発ツールはここから先、さらに並列度を上げていく方向に進むと見ています。Sub-agentsを1体ずつ真面目に設計して、名前と説明で勝手に呼ばれるように仕立てておく。今のうちからこの筋肉を鍛えておくと、来年にはもうひとつ大きな変化が来ても慌てずに対応できるはずです。まずは.claude/agents/にcode-reviewerを1体書いてみるところから始めてみてください。それだけでも、景色が少し変わります。
