Claude Codeには、タスクを複数のエージェントに分散させる仕組みが2つあります。サブエージェント（Subagents）とAgent Teamsです。
名前が似ているため混同されやすいですが、設計レイヤが根本的に異なります。サブエージェントは「働くエージェント」、Agent Teamsは「議論するエージェント」です。
この記事では、両者の構造的な違い、それぞれの得意領域、そしてハイブリッド設計のパターンを整理します。
この記事の対象読者と得られること
| 対象読者 | この記事で得られること |
|---|---|
| Claude Codeでマルチエージェント構成を検討している方 | 2つの仕組みの構造的な違いの理解 |
| サブエージェントを使っているがAgent Teamsは未経験の方 | Agent Teamsで何ができるかの具体的な把握 |
| エージェント設計のコスト最適化に関心がある方 | ハイブリッド構成による効率化の指針 |
サブエージェントとは
サブエージェントは、単一のClaude Codeセッション内で動作するタスク委譲の仕組みです。
親エージェント（メインセッション）がサブエージェントを起動し、タスク完了後に結果だけを受け取ります。構造モデルはFork-Joinです。
親エージェント
├── サブエージェントA（タスク1）→ 結果を返す
├── サブエージェントB（タスク2）→ 結果を返す
└── サブエージェントC（タスク3）→ 結果を返す
特徴を整理します。
- 親のコンテキストを引き継いでフォークされる
- 作業完了後、結果のみを親に返す
- サブエージェント同士の直接通信はできない
- 親がすべてのオーケストレーションを担う
- トークン消費が比較的低い
サブエージェントの本質は「処理の分散」です。親が仕事を切り分けて配り、結果を回収する。工場のラインワーカーに近いイメージです。
Agent Teamsとは
Agent Teamsは、複数の独立したClaude Codeインスタンスをチームとして協調動作させる仕組みです。
Team Lead（統括セッション）とTeammates（独立セッション群）で構成されます。構造モデルはMulti-Agent Systemです。
Team Lead
├── Teammate A（独立セッション）
├── Teammate B（独立セッション）
└── Teammate C（独立セッション）
↕ 相互通信可能
特徴を整理します。
- 各エージェントが独立したコンテキストを持つ
- チームメイト同士で直接通信できる
- 共有タスクリストを通じて自律的にタスクを調整する
- 継続的な議論と協調設計が可能
- トークン消費はインスタンス数に比例して増加する
Agent Teamsの本質は「認知の協調」です。異なる視点を持つメンバーが議論し、合意を形成する。プロジェクトチームのミーティングに近いイメージです。
構造的な違い
両者の違いを一覧で整理します。
| 観点 | サブエージェント | Agent Teams |
|---|---|---|
| 動作スコープ | 単一セッション内 | 複数セッション間 |
| 通信 | 親への結果報告のみ | Peer-to-Peer |
| コンテキスト | 親から分岐（共有） | 完全独立 |
| 調整方式 | 親が集中管理 | 自律協調 |
| トークンコスト | 低 | 高（人数分） |
| 主な用途 | 並列分割処理 | 協調ワークフロー |
| 親への依存度 | 高 | 低 |
最も本質的な違いは「通信モデル」です。サブエージェントは親を経由しないと情報をやり取りできません。Agent Teamsはメンバー同士が直接対話できます。
この違いが、できることの範囲を決定的に分けます。
Agent Teamsでできること
サブエージェントにはできないAgent Teams固有の能力を整理します。
エージェント間の直接通信
チームメイト同士がリーダーを介さずメッセージを送受信できます。BackendエンジニアがFrontendエンジニアに直接「APIのレスポンス形式を変えた」と伝えられます。
サブエージェントでは、すべての情報が親を経由します。AがBに何かを伝えたい場合、A→親→Bという経路になり、親がボトルネックになります。
共有タスク管理
チーム全体で共有するタスクリストを持ち、各メンバーが自律的にタスクを取得・更新します。タスクの依存関係も動的に変わります。
サブエージェントでは、タスクの割り当てと管理はすべて親の責任です。
合意形成と多視点統合
複数の専門家が異なる視点から議論し、意見の衝突を解消して合意に至るプロセスを実行できます。
サブエージェントでは各エージェントが独立に作業するため、「議論」が構造的に発生しません。
途中経過への介入
各メンバーの作業途中の状態を確認し、方針変更を直接伝達できます。
サブエージェントは基本的に「投げて待つ」モデルです。途中で方針を変えるには、サブエージェントを停止して再起動する必要があります。
サブエージェントが適しているケース
Agent Teamsではオーバーヘッドが大きくなるケースがあります。サブエージェントが適しているのは以下の場面です。
軽量な並列処理
独立した単発タスクを高速に分割実行し、結果だけ回収する場合です。
- 複数ファイルの同時解析
- 複数APIの並列呼び出し
- 複数記事の同時生成
トークン効率を重視する処理
大量生成、単純変換、バッチ処理など、エージェント間の対話が不要な処理です。Agent Teamsはインスタンス数分のトークンを消費するため、単純作業にはコストが合いません。
相互依存のないタスク
タスクが明確に分離可能で、他のタスクの結果に依存しない場合です。「このファイルをリファクタリングして」「このテストを書いて」のように、それぞれが完結する作業です。
Agent Teamsの代表的ユースケース
具体的な構成例を4つ示します。
設計レビュー型
複数の専門家が1つの設計を多角的にレビューするパターンです。
構成
- Team Lead
- Architect（スケーラビリティとアーキテクチャ整合性）
- Backend Engineer（実装の実現可能性）
- Security Reviewer（脆弱性と悪用ケース）
プロンプト例
開発チームを編成する。
目標:
以下のAPI設計仕様をレビューし改善する。
役割:
- Architect: スケーラビリティとアーキテクチャの一貫性に注力
- Backend Engineer: 実装の実現可能性に注力
- Security Reviewer: 脆弱性と悪用ケースに注力
協調して作業すること。
意見の衝突は議論で解消すること。
共有タスクリストを更新すること。
最終的に統合された改善案を出力すること。
アーキテクトが「この設計はスケールしない」と指摘し、バックエンドが「実装コストが高い」と補足し、セキュリティが「この認証方式は脆弱だ」と警告する。こうした相互議論はサブエージェントでは実現できません。
並行実装＋同期型
複数の担当者が同時に実装を進めつつ、インターフェースを同期するパターンです。
構成
- Lead
- Backend（API設計）
- Frontend（UI設計）
- QA（テストシナリオ定義）
プロンプト例
新機能を実装する: ユーザーサブスクリプションダッシュボード。
Backend: APIエンドポイントを設計する。
Frontend: UIコンポーネントを設計する。
QA: テストシナリオとエッジケースを定義する。
インターフェースを同期すること。
APIが変更されたらFrontendに通知すること。
UIに必要なデータが不足していたらAPIの更新を依頼すること。
共有タスクボードを維持すること。
BackendがAPIを変更したらFrontendに即座に通知される。QAが発見した問題がBackendとFrontendの両方に伝わる。この双方向の同期がAgent Teamsの強みです。
ブレインストーミング型
アイデアの発散と収束を構造的に行うパターンです。
構成
- Idea Generator（大胆なアイデアを出す）
- Critic（実現可能性・リスク・前提を指摘する）
- Optimizer（有望なアイデアを改善する）
- Synthesizer（最終提案をまとめる）
GeneratorがCriticに論破され、Optimizerが改善案を出し、Synthesizerが統合する。このフィードバックループが自律的に回ります。
リサーチ＋意思決定型
調査から意思決定まで、複数フェーズにまたがるプロジェクト向きの構成です。
構成
- Researcher（情報収集）
- Data Analyst（データ分析）
- Strategist（戦略策定）
- Decision Lead（最終判断）
Researcherの調査結果をAnalystが分析し、Strategistが戦略に落とし込み、Decision Leadが判断する。各フェーズの成果物が次のフェーズの入力になる連鎖型のワークフローです。
ハイブリッド設計パターン
実務で最も効果的なのは、Agent TeamsとSubagentsを組み合わせるハイブリッド構成です。3つのパターンを示します。
パターンA：Team内からSubagentを呼ぶ
Agent Team
└── Backend Teammate
├── Subagent: Code Generator
└── Subagent: Static Analyzer
チームで設計方針を議論し、重い実装作業はSubagentに委譲します。結果をチームに持ち帰って議論を続けます。
協調はAgent Teams、実行はSubagentsという役割分担です。
パターンB：外側のTeam＋内側のSubagents
Outer Team（戦略層）
├── PM
├── Architect
└── Reviewer
Inner Subagents（実行層）
├── Code Writer
├── Test Writer
└── Refactor Agent
戦略層のAgent Teamsが設計を合意し、実行層のSubagentsが大量生成を担います。PMが方針を決め、Architectが設計し、Subagentsが実装し、Reviewerがレビューする。
パターンC：フェーズ分離型
Phase 1: Agent Teams → 設計・合意形成
Phase 2: Subagents → 大量生成・実装
Phase 3: Agent Teams → レビュー・統合
フェーズごとに仕組みを切り替えます。議論が必要な局面ではAgent Teamsを使い、単純作業ではSubagentsに切り替える。
トークン効率が最も良い構成です。Agent Teamsのコストが高い局面をSubagentsで代替し、全体のコストを抑えます。
設計レイヤの整理
両者の関係を抽象化すると、3層のレイヤ構造になります。
Strategic Layer → Agent Teams（認知レイヤ）
Execution Layer → Subagents（実行レイヤ）
Tool Layer → MCP / 外部ツール
Agent Teamsは「何をすべきか」を決める認知レイヤです。Subagentsは「どう実行するか」を担う実行レイヤです。MCPや外部ツールは、実行レイヤがアクセスするツールレイヤです。
この3層を意識すると、設計判断が明確になります。
- 「何を作るか」の議論 → Agent Teams
- 「コードを書く」作業 → Subagents
- 「外部APIを呼ぶ」操作 → MCP / Tools
実務での判断基準
どちらを使うか迷ったときの判断基準を整理します。
Agent Teamsを使うべき条件
- 視点の衝突がある（アーキテクチャ vs セキュリティ vs コストなど）
- タスク間に依存関係がある（Aの結果がBの入力になる）
- 合意形成が必要（設計方針の決定など）
- 仕様が動的に変わる（議論の途中で方向転換する可能性がある）
Subagentsで十分な条件
- タスクが完全に独立している
- 単発の処理で結果だけ欲しい
- コストを最小化したい
- エージェント間の対話が不要
判断に迷う場合は、まずSubagentsで試すのが合理的です。Subagentsで結果の品質が不十分なら、Agent Teamsに切り替えます。安い方から試すほうがコスト効率が良いためです。
まとめ
サブエージェントとAgent Teamsの違いを一言で表現するなら、こうなります。
- サブエージェント = 働くエージェント
- Agent Teams = 議論するエージェント
どちらが上位という関係ではありません。抽象レイヤが異なります。
| 観点 | サブエージェント | Agent Teams |
|---|---|---|
| 構造モデル | Fork-Join | Multi-Agent System |
| 通信モデル | 親経由（Hub-Spoke） | Peer-to-Peer |
| 主な役割 | タスクの並列実行 | 意思形成と協調 |
| 強み | 軽量・高速・低コスト | 多視点・合意形成・柔軟性 |
最適な設計は、両者を組み合わせたハイブリッド構成です。議論が必要な場面ではAgent Teamsで合意を形成し、実行フェーズではSubagentsで効率的に処理する。認知レイヤと実行レイヤを分離することで、品質とコストの両方を最適化できます。