2026年2月5日、AnthropicがClaude Opus 4.6をリリースし、同時に「Agent Teams」というClaude Codeの新機能を投入した。これが開発者の間で大きな話題となっている。

Agent Teamsは、複数のClaude Codeインスタンスをチームとして並列に稼働させ、共同で作業させる機能だ。

従来の「1つのエージェントが1つのタスクを処理する」というモデルから、人間のエンジニアリングチームのように、それぞれのメンバーが専門領域を担当しながら互いに連携するモデルへと、大きなパラダイムシフトをもたらす機能だ。

Anthropic Head of ProductのScott White氏は「優秀な人間のチームが並行して働いてくれるようなもの」と表現している。

本記事では、Agent Teamsの仕組み・セットアップ方法・実践的なユースケースまで、スクリーンショットを交えながら丁寧に解説していく。

現時点ではリサーチプレビュー（実験的機能）として公開されているが、セットアップは数分で完了するので、Claude Codeユーザーであればぜひ一度試してみてほしい。

Claude Codeの新機能「Agent Teams」とは何か

なぜ「チーム」が必要なのか

従来のClaude Codeは、1つのエージェントがタスクを一つ一つ処理するモデルだった。

小〜中規模の開発であればこれでも十分だが、プロジェクトが大きくなると力不足感が出てくる。

典型的な問題は、待ち時間が開発速度のボトルネックとなることだ。セキュリティレビュー、パフォーマンスチェック、テストカバレッジの検証をひとつひとつ依頼していくと、どうしても「順番待ち」が発生する。

また、もうひとつの大きな問題が、コンテキストの汚染・劣化だ。LLMはコンテキストウィンドウに情報が増えるほど、細部の情報への注意力が低下する。1つのセッションで、認証のリファクタリングを進めながら、テストの記述、APIの設計、フロントエンドの調整を行なったりすると、コンテキストの情報量が膨大になり、どうしても精度が落ちる。

人間のチームでは、専門分野ごとに分業し、必要な時だけコミュニケーションを取る。バックエンドエンジニアがフロントエンドのコードレビューに参加したりはしない。

Agent Teamsは、この人間のチームと同じ「分担」の原理を、AIエージェントに適用したものである。

「Agent Teams」を構成する4つの要素

Agent Teamsは、以下の4つのコンポーネントで構成される。

コンポーネント	役割
Team Lead（チームリード）	チームを作成・管理し、タスクを分配・統括するメインセッション
Teammates（チームメイト）	各自が独立したClaude Codeインスタンスとして動作するメンバー
Task List（タスクリスト）	依存関係の追跡が可能な共有タスクリスト。前提タスクの完了で自動的にブロック解除される
Mailbox（メールボックス）	エージェント間の直接メッセージングシステム。リードを経由せずにメンバー同士が直接やり取りできる

従来の「Subagents」機能との違い

従来から、「Subagents（サブエージェント）」という機能は存在した。

Agent TeamsとSubagentsは、どちらも作業を並列化する仕組みだが、根本的な設計思想が異なる。

項目	Subagents（従来）	Agent Teams（新機能）
コンテキスト	独自のウィンドウを持ち、結果をメインに返す	独自のウィンドウを持ち、完全に独立
コミュニケーション	メインエージェントへの報告のみ	チームメイト同士が直接メッセージ可能
タスク管理	メインエージェントが全て管理	共有タスクリストで自律的に調整
最適な用途	結果だけが重要な単発タスク	議論・協調が必要な複合タスク
トークンコスト	低い（結果を要約して返す）	高い（各メンバーが独立インスタンス）

Subagentsは、「結果だけを親エージェントに報告する単発の作業者」という位置付けだ。

これに対して、Agent Teamsのチームメイトは「同じ部屋で働くチーム」に近い。各メンバーが全体で共有されたタスクリストとメールボックスを介してコミュニケーションしながら、それぞれ独立したコンテキストウィンドウ内で作業を進めてくれる。

使い分けの判断基準はシンプルだ。

並列に動く作業者同士が互いにコミュニケーションを取る必要があるならAgent Teams、各自が独立して作業し結果だけ返せばよいならSubagentsを使う。

Agent Teamsを実際に使ってみる方法

ここからは、実際にAgent Teamsをセットアップして最初のチームを動かすまでの手順を解説する。

ちなみに本記事では、以下のようなNode.js製のTODO追跡ツール「DevTodo Tracker」をサンプルプロジェクトとして使用している。

認証（JWT）、REST API、フロントエンド、CLIツール、テストと、実際のWebアプリケーション開発で必要な要素が一通り揃っているデモだ。

プロジェクトの中身はなんでも良いので、読者は各自の適当なプロジェクトを開いて実践してみると良い。

demo-project/
├── src/
│   ├── auth/          # JWT認証（トークン生成・検証・ミドルウェア）
│   ├── api/           # Express REST API（認証・TODO・プロジェクト）
│   ├── frontend/      # フロントエンド（HTML/CSS/JS）
│   ├── db/            # Mongooseモデル・DB接続
│   ├── cli/           # CLIツール（TODOコメントスキャナー）
│   └── utils/         # 共通ユーティリティ
├── tests/             # テスト（unit / integration / e2e）
├── config/            # 設定ファイル
├── .claude/           # Claude Code設定（Agent Teams有効化済み）
└── CLAUDE.md          # プロジェクトのコンテキスト情報

Step 1：Agent Teamsを有効化する

Agent Teamsはデフォルトでは無効になっている。

有効化するには、環境変数を設定する方法と、settings.jsonに記述する方法の2つがあるが、settings.jsonに記述する方法が推奨されている。

~/.claude/settings.json（グローバル設定）またはプロジェクトルートの.claude/settings.jsonに以下を追加する。

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

環境変数で設定する場合は、ターミナルで以下を実行する。

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Step 2：表示モードを選択する

Agent Teamsには2つの表示モードがある。

1つ目は「In-process」モード。すべてのチームメイトが1つのターミナルウィンドウ内で動作する。Shift+Up/Downキーでチームメイトを選択してメッセージを送れる。追加のツールは不要で、あらゆるターミナルで動作する。

2つ目は「Split panes」モード。各チームメイトが独立したペインを持ち、全メンバーの出力を同時に確認できる。こちらはtmuxまたはiTerm2（it2 CLIが必要）が必要となる。

Split panesモードを使いたい場合は、settings.jsonに以下を追加する。

{
  "teammateMode": "tmux"
}

tmuxのインストールは、macOSの場合はbrew install tmuxで完了する。

デフォルトは「auto」で、tmuxセッション内で起動した場合はSplit panesモード、それ以外ではIn-processモードが自動選択される。

特にこだわりがなければ、まずはデフォルト（auto）のまま試してみるのがよい。tmuxセッション外であれば自動的にIn-processモードで動作する。

Step 3：最初のチームを作成する

settings.jsonでAgent Teamsの有効化が完了したら、Claude Codeを開いて、チームの作成を文章で指示するだけでよい。

タスクの内容とチーム構成を伝えれば、Claudeが自動的にチームメイトを生成し、タスクを分配してくれる。

以下は公式ドキュメントで紹介されているプロンプト例だ。

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

このプロンプトでは、UX担当、技術アーキテクチャ担当、「悪魔の代弁者（反論役）」役の3つのチームメイトがそれぞれ独立して調査を行い、発見を共有し合う。

Agent Teamsでは、スポーンプロンプトが具体的であるほど、チームメイトは的確に作業を開始できる。それぞれのチームメイトに作業してほしい具体的なファイルパスや、着目ポイントを書き込むのも有用だ。

チームメイトの数や、モデル（Opus / Sonnet）を明示的に指定することも可能だ。

4人のチームメイトでこれらのモジュールを並列にリファクタリングしてください。
各チームメイトにはSonnetを使用。

チームメイトにSonnet（より安価なモデル）を使い、リードにOpus（高性能モデル）を使うことで、コストを抑えつつ全体の品質を確保する戦略もある。

主要なキーボードショートカット

Agent Teamsの操作で知っておくべきキーボードショートカットを以下にまとめる。

キー	動作
Shift+Up/Down	チームメイト間の切り替え（選択）
Enter	選択したチームメイトのセッションを表示
Escape	チームメイトの現在のターンを中断
Ctrl+T	タスクリストの表示/非表示切り替え
Shift+Tab	権限モードのサイクル（Delegate Modeを含む）

チームメイトがスポーンされたら、Shift+Up/Downでチームメイトを選択し、個別のチームメイトにメッセージを送信することが可能である。

また、Ctrl+Tで、タスクリストの表示／非表示を切り替えられる。

タスクリストを表示すると、現在の完了／未完了のタスクと、それぞれを担当しているチームメイトが表示される。

Agent Teamsの便利な機能

Delegate Mode：リードをコーディネーション専用にする

Shift+Tabで、プランモードやオートエディットモードなどを切り替えることができるが、Agent Teamsで有用なモードとして「Delegate Mode」がある。

リードを「Delegate Mode」に切り替えると、リードのツールがコーディネーション専用（チームメイトの生成・メッセージ送信・シャットダウン・タスク管理のみ）に制限され、コード編集ができなくなる。

それによって、リードは指揮官に徹し、実装は全てチームメイトに任せることが強制される。

「分業」することの意義を徹底するのであれば、リードの権限は基本的にDelegate Modeにしておくのが良いだろう。

Plan Approval：実装前に計画を承認する

リスクの高い作業（データベースのスキーマ変更、認証モジュールのリファクタリングなど）では、チームメイトに「まず計画を立て、承認を得てから実装に着手する」ことを求められる。

データベース担当のチームメイトをスポーンし、スキーマ移行を担当させてください。
変更前に必ずPlan Approvalを要求し、ロールバック手順を含む計画のみ承認してください。

チームメイトは読み取り専用のプランモードで計画を策定し、リードに承認リクエストを送る。

リード（AI）は自律的に計画を評価し、承認または却下を判断する。

却下した場合はフィードバック付きで差し戻され、チームメイトは計画を修正して再提出する。

承認されると、チームメイトはプランモードを解除して実装に着手する。

Plan Approvalはリード（AI）による自律判断であり、ユーザーに承認・拒否を求めるボタンが表示されるわけではない。

リードの承認基準はプロンプトで制御できる。「テストカバレッジを含む計画のみ承認せよ」「データベーススキーマを変更する計画は却下せよ」など、条件を事前に指示しておくとよい。

チームメイトに直接話しかける

各チームメイトは完全に独立したClaude Codeセッションであるため、リードを介さず直接メッセージを送ることも可能だ。

In-processモードの場合、Shift+Up/Downで対象のチームメイトを選択し、テキストを入力するだけでよい。追加の指示、フォローアップの質問、アプローチの修正など、柔軟に対応できる。

Split panesモードの場合は、対象のペインをクリックすれば、そのチームメイトと直接やり取りできる。

Agent Teamsが役立つ典型的なシナリオ

並列コードレビュー

セキュリティ、パフォーマンス、テストカバレッジなど、幅広い観点からコードレビューを行いたい場合、ひとつのエージェントに頼むと網羅性に限界がある。

特化した役割を与えたエージェントに、個別の観点での詳細レビューを依頼した方が良い。

Agent Teamsなら、観点ごとに専門のレビュワーを配置できる。

PR #142をレビューするチームを作成してください。3人のレビュワーをスポーン：
- セキュリティ観点
- パフォーマンス観点
- テストカバレッジ観点
それぞれレビューして結果を報告させてください。

各レビュワーは同じPRを異なるフィルターで精査し、リードが最終的に全レビューの結果を統合して説明してくれる。

競合仮説によるディベート風のデバッグ

バグの原因が不明な場合、1つのエージェントに調査させると、最初にもっともらしい仮説を見つけた時点で調査を打ち切る傾向がある。

Agent Teamsでは、複数のチームメイトにそれぞれ異なる仮説を検証させ、互いの仮説を反証し合う議論のスタイルを取ることができる。

ユーザーから「XXXXX」との報告あり。
5人のチームメイトをスポーンし、それぞれ異なる仮説を調査させてください。
科学的ディベートのように互いの仮説を反証し合い、合意が得られた結論を
findings docに記録してください。

複数の独立したレビュワーが、互いの仮説を反証し合うことで、最終的に生き残った仮説が真のバグの原因である確率が高まる。

クロスレイヤー開発

フロントエンド、バックエンド、テストにまたがる機能開発は、Agent Teamsの得意分野だ。

例えば、バックエンドのチームメイトに「APIの応答形式をフロントエンドのチームメイトに共有」することを要求する。

また、フロントエンドに対しては、「バックエンドが連絡をしてくるまで待機」するように指示する。

GitHub/Google OAuthを実装するチームを作成してください。
既存のパスワードレスOTP認証（MongoDB）に追加する形で。

バックエンド担当：OAuth設定・コールバック・アカウント連携を実装。
レスポンス形式とセッション構造が固まり次第、フロントエンド担当に共有。

フロントエンド担当：OAuthボタンと連携管理UIを追加。
データ層はバックエンド担当の仕様が届くまで待機。

テスト担当：両チームメイトの実装を観察し、結合テストを作成。

こうすることで、チームメイト同士が直接メッセージを送り合い、バックエンドの仕様が送られてきて初めてフロントエンドが作業に着手するので、並行作業でも不一致が起きにくい。

Agent Teamsを使う上での注意事項

小さすぎる／大きすぎるタスクは御法度

Agent Teamsで最も重要なのは、タスクの粒度だ。

タスクが小さすぎると、1つのエージェントにまとめて依頼した方がコーディネーションのコストが無く効率的だ。

逆にタスクが大きすぎると、チームメイトが長時間チェックインなしで作業を続け、手戻りのリスクが増大してしまう。

同じファイルを複数のチームメイトに触らせない

2人のチームメイトが同じファイルを同時に編集すると、競合・上書きが発生する。

これはAgent Teamsで最も起きやすいトラブルの一つだ。

タスクを分割する際は、各チームメイトが担当するファイルが重複しないよう設計することが望ましい。

CLAUDE.mdとスポーンプロンプトに十分な情報を含める

チームメイトはプロジェクトのCLAUDE.mdを自動的に読み込むため、プロジェクトの構成や開発ルールをCLAUDE.mdにしっかり記述しておくと、スポーンプロンプトを短くできる。

CLAUDE.md以外には、MCPサーバー、スキルなどのコンテキストも自動的にロードする。

一方で、リードの会話履歴は引き継がない。

そのため、チームメイトを生成する際のプロンプト（スポーンプロンプト）には、タスクに必要な具体的な情報を含める必要がある。

対象のファイルパス、使用技術、着目すべきポイントなど、できる限り具体的に指示するとよい。

高額なトークンコストに注意（Maxプランじゃないと…）

Agent Teamsは、各チームメイトが独立したClaudeインスタンスとして動作するため、チームメイトの数に比例してトークン使用量が増加する。

単純なタスクをAgent Teamsで処理するのは、明らかにコストパフォーマンスが悪い。

1つのエージェントで事足りる場面では、素直にシングルセッションやSubagentsを使うのがコスト面では合理的である。

できるだけトークン消費を抑えるには、チームメイトにはSonnetを使い、リードにはOpusを使うなどの工夫もあるだろう。

Agent Teamsの機能上の制約

Agent Teamsは現在「リサーチプレビュー」として提供されている実験的な機能であり、今後さらに仕様が変わる可能性もある。

現時点で気をつけておくべき点としては、以下などがあるだろう。

• 1セッションにつき1チーム：同時に複数のチームを管理することはできない。新しいチームを作る前に、現在のチームをクリーンアップする
• チームのネスト不可：チームメイトがさらにチームを作ることはできない。チームを管理できるのはリードのみ
• リードの固定：チームを作成したセッションがそのチームのリードとして固定され、チームメイトの昇格やリーダーシップの委譲はできない
• 権限の継承：全チームメイトがリードの権限設定を引き継ぐ。--dangerously-skip-permissionsで起動した場合、全チームメイトも同様の権限で動作する点に注意
• セッションの再開に非対応：/resumeや/rewindではIn-processモードのチームメイトは復元されない

チームのネストやリードの委譲まで可能になれば、相当に複雑な開発チームをマネジメントすることができるようになるだろう。

今後、さらにAgent Teamsの機能が改善されていくことに期待したい。

象徴的な事例：16エージェントで10万行のCコンパイラを構築

Agent Teamsの可能性を最も象徴的に示すのが、Anthropicの研究者Nicholas Carlini氏によるCコンパイラ構築プロジェクトだ。

16のエージェントを並列に稼働させ、約2,000のClaude Codeセッション、2週間の開発期間、約20,000ドルのAPIコストで、10万行のRust製Cコンパイラをゼロから構築した。

このコンパイラはLinux 6.9をx86、ARM、RISC-Vの3アーキテクチャでコンパイルでき、GCC torture test suiteで99%のパスレートを達成している。

SQLite、Redis、QEMU、FFmpegのコンパイルにも成功しており、さらにはDoomのコンパイル・実行まで可能だ。

Carlini氏が挙げている教訓は、一般のClaude Codeユーザー／Agent Teamsユーザーにも非常に参考になる。

• テストの品質が全てを決める。エージェントはテストが示す目標に向かって最適化するため、テストが不完全だと間違った問題を解決してしまう
• エージェント向けにテスト出力を設計する。大量のログをそのまま流し込むのではなく、エラーの要約を数行で出力するようにする（コンテキストウィンドウの汚染を防ぐため）
• 並列化しやすいタスク設計が重要。独立したテストケースが多数ある段階では並列化は容易だが、全体が1つの巨大なタスク（Linux カーネルのコンパイルなど）になると、全エージェントが同じバグに取り組んでしまい効率が激減する

AIエージェントの「チーム化」が開く可能性

Carlini氏のCコンパイラプロジェクトは、複数のAIエージェントが協調することで、個人では到底手が届かない規模のソフトウェアを現実的な期間で構築できることを示した。

AIエージェントの使い方が「1対1の対話」から「チームのオーケストレーション」へと拡張されようとしている。

これは、開発者とAIの関係における大きなパラダイムシフトだ。

開発者の役割は、コードを書く人から、AIチームに的確な指示を出し、成果物をレビューするマネージャーへと変わっていくのかもしれない。

Agent Teamsはその未来を一足先に体験できる機能だ。

ぜひ手元のプロジェクトで試してみてほしい。