はじめに
Claude CodeなどのAIエージェントを使い込んでいると、ある壁にぶつかる瞬間があります。
「このタスク、1つの Agent だけでは限界があるな」と。
たとえば、大規模なリファクタリング。アーキテクチャの調査と実装を同時に進めたい。あるいは、コードレビューでセキュリティ・パフォーマンス・テストカバレッジを同時に見たい。こうした場面では、Agent が 1つだと順番に取りかかるしかなく、しかも 1つのコンテキストウィンドウに全てを詰め込むことになります。
2026年2月、Claude Opus 4.6 のリリースとともに、Anthropic はこの問題に対する回答を出しました。Agent Teams です。
複数の Claude Code インスタンスがチームを組み、タスクを分担し、互いに直接やり取りしながら協働する。この記事では、Agent Teams の「使い方」だけでなく、なぜこう設計されたのかを、Claude Code の内部構造と Anthropic の設計思想から掘り下げていきます。
Anthropic の設計思想から理解する
Agent Teams の設計を理解するには、まず Anthropic が公開している「Building a C compiler with a team of parallel Claudes」というブログ記事を押さえておくと見通しがよくなります。
https://www.anthropic.com/engineering/building-c-compiler
ここでは、LLM ベースのシステムを構築する際の設計パターンが整理されています。
3つの関連パターン
Agent Teams に深く関わるのは、以下の3つです。
Orchestrator-Workers（編成者と実行者）
中央の LLM がタスクを動的に分解し、ワーカーに委託して、結果を統合するパターンです。事前にサブタスクが決まっていない複雑な問題に向いています。Agent Teams の Team Lead がまさにこの編成者の役割を担っています。
Parallelization（並列処理）
複数の LLM が同時に作業し、結果をまとめるパターンです。タスクを独立したサブタスクに分割して並列に実行する「Sectioning」と、同一タスクを複数回実行して多様な出力を得る「Voting」の2つのバリエーションがあります。Agent Teams では主に Sectioning の形で並列化が活用されています。
Evaluator-Optimizer（評価と改善の循環）
一方が生成し、もう一方が評価してフィードバックする。この繰り返しで品質を上げていくパターンです。Agent Teams では Teammate 同士が互いの成果物を評価し合い、疑問を投げかけることができます。
ここで大事なのは、Agent Teams がこの3つのパターンを1つの仕組みに統合しているという点です。Lead が動的にタスクを分解し（Orchestrator-Workers）、Teammate が並列に作業し（Parallelization）、互いに結果を評価し合う（Evaluator-Optimizer）。単なる「並列実行ツール」ではなく、複数の設計パターンが自然に連携する構造になっています。
シンプルさ
もう1つ、Anthropic が一貫して強調しているのがシンプルさの追求です。
Building Effective Agents では「できる限りシンプルな解決策を見つけ、必要なときだけ複雑さを加える」ことが繰り返し推奨されています。そして「成功とは最も洗練されたシステムを作ることではなく、あなたのニーズに合った正しいシステムを作ることだ」と。
この原則は Agent Teams の設計にも色濃く反映されています。後ほど詳しく見ますが、Agent Teams の協調メカニズムは驚くほどシンプルです。共有メモリもデータベースもなく、ただのファイルシステムとファイルロックだけで成り立っています。
Claude Code の実装から見る4つの柱
ここから本題に入ります。Agent Teams のアーキテクチャは、4つの核心コンポーネントで構成されています。
Team Lead と Teammate
Team Lead は、チームを作成した Claude Code セッションそのものです。Lead の仕事は自分で実装することではなく、タスクの分解・委託・結果の統合です。実際、Lead が勝手にコードを書き始めてしまう問題を防ぐために、Delegate Mode（Shift+Tab で切替）という機能があり、Lead を協調専用の動作に制限できます。
一方、各 Teammate は完全に独立した Claude Code インスタンスです。Subagent も独自のコンテキストウィンドウを持ちますが、結果を呼び出し元に返して終わるのに対して、Teammate は自律的に動き続け、互いに直接通信できる点が決定的に異なります。
Teammate は起動時にプロジェクトの CLAUDE.md や MCP サーバー設定、スキルなどを読み込みますが、Lead の会話履歴は引き継ぎません。各 Teammate のコンテキストが完全に分離されているため、ある Teammate の作業が他のコンテキストを汚染することがありません。Anthropic が C コンパイラを16個の並列 Claude で構築した事例でも、この「コンテキスト分離」が重要な設計判断として言及されていました。
共有タスクリスト
チーム全体の作業は、共有タスクリストで管理されます。各タスクは ~/.claude/tasks/{team-name}/ に JSON ファイルとして保存されます。
タスクには3つの状態があります。
タスク間に依存関係を設定することもできます。前提タスクが完了していなければ、そのタスクは認領できません。前提タスクが完了した瞬間に、ブロックされていたタスクが自動的にアンロックされます。
Teammate は自律的にタスクリストを確認し、未割り当ての空きタスクを自分で認領します。複数の Teammate が同時に同じタスクを取ろうとした場合は、ファイルロックで競合を防ぎます。専用のタスク管理サーバーではなく、ファイルとファイルロックだけで済ませている点は、後述する設計思想と深く関係しています。
Mailbox（メッセージシステム）
Agent Teams と Subagent の最も本質的な違いがここにあります。
Subagent は「仕事をして結果を返す」だけの存在です。主 Agent に結果を渡したら終わり。Subagent 同士は互いの存在すら知りません。
Agent Teams の Teammate は違います。特定の Teammate に直接メッセージを送ったり、全員にブロードキャストしたりできます。Lead を経由せずに、Teammate 同士が質問を投げたり、相手の結論に異議を唱えたりできるのです。メッセージは自動的に受信者に届くため、Lead が手動で中継する必要もありません。
公式ドキュメントに面白いユースケースがあります。バグの原因を調査するとき、5人の Teammate にそれぞれ異なる仮説を持たせて、互いの仮説を積極的に否定させる。科学の討論のように反証し合うことで、生き残った仮説は真の原因である可能性がずっと高くなります。これは1つの Agent が順番に仮説を検証するのとは質的に異なるアプローチです。単一 Agent だと最初に見つけた仮説にアンカリングされやすいのに対して、複数の独立した調査者が対立的に検証し合う構造は、この偏りを構造的に回避しています。
UNIX 哲学としてのファイルシステム協調
ここまで読んで気づかれたかもしれませんが、Agent Teams の協調メカニズムは一貫してファイルシステムに依存しています。
| コンポーネント | 保存先 |
|---|---|
| チーム設定 | ~/.claude/teams/{team-name}/config.json |
| タスクリスト | ~/.claude/tasks/{team-name}/ |
公式ドキュメントにはこの2つのパスが明記されています。Mailbox も同様にローカルファイルで管理されていますが、具体的なパスは公式には記載されていません。
共有メモリもデータベースもクラウドサービスも使っていません。すべてローカルのファイルだけで完結しています。
これは意図的な設計判断です。ファイルベースであることの利点をまとめると、
- デバッグが容易：問題が起きたらファイルを直接見れば状態が分かる
- 透明性が高い：何が起きているかをいつでも確認できる
- 永続性がある：プロセスが落ちても状態はディスクに残る
-
ツールとの相性がよい：
cat、grep、jqなど既存のツールでそのまま操作できる
C コンパイラのプロジェクトでも、同様のアプローチが採用されていました。各 Agent が current_tasks/ ディレクトリにロックファイルを作成してタスクを認領し、Git の自然な衝突解決メカニズムで重複作業を防いでいたのです。
Subagent との違いを整理する
ここまでの内容を踏まえて、Subagent と Agent Teams の違いを改めて整理してみます。
| 観点 | Subagent | Agent Teams |
|---|---|---|
| コンテキスト | 独立ウィンドウだが結果を呼び出し元に返す | 完全に独立したセッション |
| 通信 | 主 Agent への結果報告のみ | Teammate 間の直接メッセージ |
| 協調 | 主 Agent が全てを管理 | 共有タスクリストで自己協調 |
| ネスト | 子 Agent がさらに子を生成できない | Teammate が自分のチームを作ることもできない |
| 適するケース | 結果だけ欲しい集中的な作業 | 議論と協調が必要な複雑な作業 |
| トークンコスト | 低い（結果の要約が返る） | 高い（各 Teammate が独立インスタンス） |
わかりやすくたとえると、Subagent は関数呼び出しです。引数を渡して、結果を受け取る。一方 Agent Teams はチーム会議です。参加者が自分の意見を持ち、互いに議論し、合意に至る。
Subagent では A と B は互いの存在を知りませんが、Agent Teams では全員が直接やり取りできます。
Claude Code の委任レイヤーには3つの段階があると捉えることができます。
- 単一セッション — あなたと Claude の1対1
- Subagent — 並列のワーカーが主 Agent に報告する
- Agent Teams — ワーカー同士が直接協調する
この進化は「集中型」から「分散型」への移行です。各段階で自律性が上がり、扱える問題の複雑度も上がります。ただし、その分コスト（トークン消費量）も増えます。3人チームでおよそ単一セッションの4倍程度のトークンを消費するので、タスクの性質に応じた使い分けが大事になってきます。
Claude Code で使ってみる
設計思想を理解したところで、実際の使い方を簡単に見ておきます。
1. Agent Teams を有効にする
Agent Teams は実験的機能のため、デフォルトでは無効です。~/.claude/settings.json（グローバル設定）または プロジェクトの .claude/settings.local.json に以下を追加します。
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
2. Claude Code を起動する
Agent Teams には2つの表示モードがあります。
-
in-process（デフォルト）：追加インストール不要。
Shift+Up/Downで Teammate を切り替えます - split panes：tmux や iTerm2 上で各 Teammate を分割表示。macOS / Linux 向け
Windows 環境では in-process モードが基本になります。分屏が欲しい場合は WSL 内で tmux を使う方法もあります。
3. 自然言語でチームを作る
あとはプロンプトでチームの構成を指示するだけです。
Agent Team を作成して、メンバーは以下の通り：
- アーキテクト：全体設計、技術選定、方案レビュー、リスク管理
- 開発エンジニア：コード実装、機能開発、デバッグ最適化
- テストエンジニア：機能テスト、バグ検出、テストケース設計、品質保証
Lead が自動的にチームを作成し、Teammate を生成して、タスクの分解と割り当てを行います。
補足
-
Delegate Mode（
Shift+Tab）を使うと、Lead を協調専用にできます - Plan Approval を要求すると、Teammate は実装前にプランの承認を受けます
- チームが終わったら
チームをクリーンアップしてと Lead に指示します。Teammate を先にシャットダウンしてから行うのが推奨です
まとめ
Agent Teams を触ってみて感じたのは、この機能の価値は「並列に速くなる」ことよりも、**「独立した視点を持つ複数のエージェントが、互いに議論しながら問題に取り組める」**という構造的な強みにあるということです。
設計面では、Anthropic の「シンプルさを追求する」が随所に表れています。ファイルシステムベースの協調、ファイルロックによる競合防止、共有メモリを使わないシンプルな設計。派手さはないですが、透明性が高くデバッグしやすい、実用的な設計だと感じました。
もちろん現時点ではまだ実験的機能で、トークンコストの高さやセッション再開の制限など課題はあります。ただ、「AI が AI を管理する」というコンセプトが Claude Code の中で実際に動いている事実は、エージェントの使い方を考える上で参考になるのではないかと思います。