この記事自体がひとつの事例です
この記事を書く前に、私はClaude Code内でCodexとGeminiという2つの外部LLMを同時に起動し、それぞれ公式ドキュメントでサブエージェントとエージェントチームの相違点を調べさせました。さらに、Claude自身が調べた結果も加え、3つの結果を相互に照合しました。3つすべてが一致したものを高信頼度とみなし、意見が分かれた点についてはドキュメントを参照して結論を出しました。
この作業そのものが、まさにサブエージェントパターンの実例となっています。つまり、1つのメインエージェントが3つのサブエージェントを派遣して独立して作業させ、報告を受けた後に統合するというものです。もし私がエージェントチームパターンを採用していたら、エージェント同士が対話して相互に誤りを訂正し合うことになり、結果は全く異なるものになっていたでしょう。
多くの人は、Claude Codeの並列化について実際には半分しか理解していない。
1つの表で違いがわかる
視点 | サブエージェント | エージェントチーム |
|---|---|---|
本質 | メインセッション内の分身 | 独立したClaude Codeインスタンス。総称して「チームメイト」 |
コンテキスト | 独自のコンテキストを持ち、ライフサイクルは短い | 各teammateはそれぞれ1MBを占有し、永続的 |
コミュニケーション | 一方向：作業完了時にテキストを報告 | 双方向： |
Sibling 間の対話 | ❌ | ✅ チームメイト同士で直接pingが可能 |
ネスト構造 | ❌ サブエージェントを再生成できない | ❌ チームメイトはチームを再作成できない |
ライフサイクル | 完了後終了 | セッションが存続している間は有効；ただし /resume、/rewind では in-process のチームメイトは復元されない |
協調 | メインエージェントによる手動でのタスク割り当て | タスクリストを共有し、依存関係を自動的に解決 |
トークンコスト | 基準 | 公式ドキュメント：planモードで約7倍 |
安定性 | 正式機能 | 実験的、フラグ設定が必要 |
アーキテクチャの違いの根本
サブエージェントは、メインセッションから派遣される使い捨てのワーカーです。独自のコンテキストを持ちますが、処理完了後は消滅し、返されるのは1つの応答テキストのみです。メインエージェントが調整と統合を担当します。これはスター型トポロジーです。
Agent Teamsの各teammateは、あなたと同等の別の完全なClaude Codeです。同じプロジェクトのCLAUDE.md、skills、MCPサーバーを読み取りますが、あなたの会話履歴は継承しません——あなたがどのようなspawnプロンプトを与えるかによって、そのteammateが何を知っているかが決まります。teammate同士は、ファイルシステム層のメールボックスを介してメッセージをやり取りします。これはメッシュトポロジーです。
トポロジーによって可能なことが決まります。スター型の場合、3人のレビュアーがそれぞれレポートを提出し、あなたがそれを統合します。メッシュ型の場合、セキュリティレビュアーがレースコンディションを発見すると、パフォーマンスレビュアーに直接「あなたのベンチマークは不正確かもしれない」と通知できます。
コスト構造：なぜ7倍なのか
公式ドキュメントの数値は「プランモードのエージェントチームは~7×トークン」となっています。その根拠は2つあります：
各チームメイトが個別にコンテキストを消費する：3人をspawnすれば、3つの1Mが実行される
調整メッセージ自体にトークンが必要：メールボックスのメッセージを相手のコンテキストウィンドウに書き込む必要がある
これが、公式が「Agent Teamsは、協調そのものが課題となるタスクに適している」と繰り返し強調している理由だ。もしタスクをきっぱりと分割でき、それぞれが独立して実行できるなら、サブエージェントの方が常にコスト効率が良い。
いつどちらを使うか
実用的な意思決定フレームワーク：
サブエージェントを使用すべき場合：
タスクの内容が一度で明確に説明でき、途中で対話が必要ない場合
結果さえ得られればよく、過程は問わない場合
複数の作業が互いに独立している場合（研究、翻訳、テスト実行など）
コンテキストの維持やコストを削減したい場合
以下の場合は「Agent Teams」を使用してください：
複数のチームメンバーの発見が互いに影響する場合（セキュリティがパフォーマンスに影響するケースなど）
長時間のやり取りが必要な場合（継続的なデバッグ、レビューの往復など）
真の並列処理が必要で、各チームメンバーが1Mのコンテキストを完全に保持する必要がある場合
複雑な依存関係を自動的に解決したい場合
不確かな場合はデフォルトで：まずサブエージェントを使用する。Agent Teamsの7倍のコストは、「調整そのものが価値である」場合にのみ元が取れる。
Windowsでの使用方法
Agent Teamsは2つの表示モードをサポートしています：
In-process（デフォルト）：すべてのチームメイトがあなたのターミナルを共有します。Shift+Downキーで切り替え可能です。Windows Terminal / cmd / PowerShell / VS Codeのターミナルで動作します。
Split panes：各チームメイトに1つのペイン。tmuxまたはiTerm2のみ対応。Windows Terminalは対応リストに含まれていません。
WindowsでSplit panesを使用したい場合、唯一の方法はWSL2 + tmuxです：
# WSL (Ubuntu)
sudo apt install tmux
npm install -g @anthropic-ai/claude-code
tmux
claudeフラグを有効にする（~/.claude/settings.json）：
{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }推奨：スプリットペインのためだけにWSLを導入するのは控えてください。in-processモードは機能が充実しており、画面の同時表示というUXだけが異なります。実際に一度使ってみて必要だと確信してから導入してください。
Resumeには落とし穴があります
Agent Teamsは実験的な機能であり、最も顕著な制限はセッションの再開にあります：
/resume や /rewind では、in-process モードの teammate は復元されません——メインセッションの再開に成功しても、それらの teammate は実際にはすでに存在していないからです
復元後、リードは古いteammateへの参照を保持したままになるため、存在しないteammateに対してメッセージを送信してしまう可能性があります
SendMessageもしそのような状況が発生した場合は、リードに「そのチームメイトはもう存在しないので、新たにspawnしてください」と明確に伝えてください
実務上のアドバイス：重要なチーム作業が完了したら、明確にシャットダウンし、resumeに依存して続行しないこと。Split panesモードではtmuxによってプロセスが保持されるため、制限は多少少ないですが、それでも手動で再接続することを推奨します。
よくある3つの落とし穴
2つのTeammateが同じファイルを編集：上書きし合う。タスクを切り替える際は、各Teammateに独自のファイルセットを持たせる
Spawnプロンプトのコンテキストが少なすぎる：teammateはメインセッションの会話履歴を継承しないため、与えられた情報しか認識しない
タスクの分割が細かすぎる：3人のチームメイトがそれぞれ2分間の作業を行う場合、調整コストが単一セッションで完了させる場合よりも高くなってしまう
次回
この記事の作成方法——Claude内でCodexとGeminiを呼び出して独立した検証を行う——それ自体がトークンを節約するパターンです。次回は、具体的な設定方法、どのタスクにどの外部LLMを使うべきか、そしてなぜこれがClaudeに3回実行させるよりも安上がりなのかについて解説します。