はじめに
2026年2月5日、Anthropicは Claude Opus 4.6 のリリースと同時に、Claude Codeの新機能 エージェントチーム を研究プレビューとして公開しました。
これは複数のClaude Codeインスタンスを「チーム」として協調させる仕組みです。
1つのセッションが 「リーダー」 として全体を統括し、複数の 「チームメイト」 がそれぞれ独立したコンテキストで並列に作業を進めます。
今回はシンプルなTodoアプリを基に、エージェントチームを発足したうえで実際の動きを見ていきます。
そもそも エージェントチーム って既存のサブエージェントと何が違うの？
まず、既存のサブエージェントとの違いを整理します。
| サブエージェント | エージェントチーム | |
|---|---|---|
| 関係性 | 親子関係 | 相互関係 |
| コンテキスト | 親セッション内で動作 | それぞれ独立したセッション |
| コミュニケーション | 親への一方通行 | 直接メッセージ |
| タスク管理 | 親が制御 | 共有タスクリストを自律的に取得 |
| トークン消費 | 中（~440k） | 大（~800k） |
| 用途 | 素早い調査・単発タスク | 大規模な並列開発・レビュー |
テーブルだけだとわかりにくいので説明します。
サブエージェントだと、必ず親を経由した伝言ゲームになります。
リーダー→A 「A、バックエンドがおかしいから調査して。」
A→リーダー 「フロントからの呼び出しがおかしいです。」
リーダー→B 「B、呼び出しがおかしいらしいよ。」
B→リーダー 「ログを調査すると、バックエンドがエラーを起こしています。」
リーダー→A 「A、やっぱりバックエンドがおかしいみたいだよ。」
... 上司を経由するので、速度が劣るし情報が劣化しやすい。
エージェントチームはAとBがリーダーを通さずに直接メッセージを送り合えるのが最大の違いです。
リーダー→A+B 「Aはバックエンド、Bはフロントエンドを調査して。」
A→B 「想定通りにレスポンスが返ってきていない。」
B→A 「こっちのログでも返してない。でもリクエストパラメータに指定されてないからじゃない？」
A→B 「たしかに。フロントの指定の条件分岐の問題かも。」
A+B→リーダー 「フロントの問題でした。」
... 直接やり取りするので速いし、情報の劣化が少ない
エージェントチームって何者なの！？
エージェントチームは4つのコンポーネントから成り立ちます。
1. チームリーダー
メインのClaude Codeセッション。
チームの作成、タスクの割り振り、全体の進捗管理を行います。
2. チームメイト
独立したClaude Codeインスタンス。
それぞれが自分のコンテキストウィンドウを持ち、割り当てられたタスクを自律的に実行します。
3. 共有タスクリスト
全エージェントがアクセスできるタスク管理システム。
タスクは 実行待ち → 進行中 → 完了 のライフサイクルで管理され、ファイルロックにより競合を防ぎます。タスク間の依存関係（DAG）もサポートされています。
4. メールボックス
エージェント間の直接メッセージングシステム。
リーダーを経由せず、チームメイト同士が直接やり取りできます。
セットアップ
前提条件
- Claude Code がインストール済み
- Claude Opus 4.6 が利用可能（2026/2/10時点で無料プランは対象外）
エージェントチーム の有効化
エージェントチームは実験的機能のため、明示的に有効化する必要があります。
settings.json に以下を追加します。
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
settings.jsonの場所は以下の通りです。
| スコープ | パス |
|---|---|
| グローバル | ~/.claude/settings.json |
| プロジェクト |
.claude/settings.json（リポジトリ直下） |
面倒なら、チャットで有効にしてもらうのもいいと思います。
有効にしたらClaude Codeを再起動します。
実際に動かしてみる。
ここからは実際にエージェントチームを使って、シンプルなTodoアプリに複数の機能を並列に追加してみます。
題材のTodoアプリ
React + Hono + better-sqlite3 で作ったシンプルなTodo REST APIです。
apps/
api/ … API サーバー (Hono + SQLite) :3000
web/ … フロントエンド (React + Vite) :5173
エージェントチーム でやりたいこと
以下の3つの機能を、それぞれ別のチームメイトに並列開発させます。
- チームメイトA：タグ機能の追加（DBスキーマ変更 + API）
- チームメイトB：検索・フィルタ機能の追加（クエリパラメータ対応）
- チームメイトC：フロントエンドの改善（タグ表示・検索UI）
指示するとプランを設計したうえで、下記の様にチームが発足。実行を始めます。
メッセージログに下記の様に出力されていきます。
連携していますね。
完成が報告されたので確認します。
タグの追加とフィルターが実装されました。
余談
進捗をGUIからではなく、チャットで聞くこともできます。
リーダが催促したりします。現実ぽくて怖いですね。
実践Tips
タスク設計のコツ
タスクを設計するときに正しく指示しないとかえって非効率になります。
この辺りはSkill.mdなどにまとめるのがいいかなと思います。
良い例：
- ファイルの担当範囲が明確に分かれている
- 1チームメイトあたり5〜6タスク
- 依存関係が明示されている
悪い例：
- 同じファイルを複数チームメイトが編集する
- タスクが大きすぎる/小さすぎる
- 依存関係が曖昧
コスト意識
エージェントチームはトークン消費量が大きいため、すべての場面で使うべきではありません。
| シナリオ | 推奨 |
|---|---|
| 独立した複数機能の並列開発 | エージェントチーム |
| 大規模なコードレビュー | エージェントチーム |
| デバッグ（複数仮説の並列検証） | エージェントチーム |
| 単一ファイルの修正 | 通常セッション |
| 小さなバグ修正 | 通常セッション / サブエージェント |
今回のように、モノレポ構成だったりする場合に向いていると考えられますね！
Quality Gate Hooks
エージェントチームには品質を担保するためのHookが用意されています。
-
TeammateIdle：チームメイトがアイドル状態になったとき実行。Exit code 2 を返すとフィードバックを送り、作業を継続させます。 -
TaskCompleted：タスクが完了マークされたとき実行。Exit code 2 を返すと完了を拒否してフィードバックを送ります。
これにより、自動テストやリント結果をフィードバックとして組み込むことが可能です。
エージェントチーム の現在の制限事項
研究プレビューのため、いくつかの制限があります。
-
/resumeや/rewindでチームメイトは復元されない - 1セッションにつき1チームまで
- チームメイトが自分のチームを作ることはできない（ネスト不可）
- リーダーの交代はできない
- 権限モードはリーダーのものを全員が継承
- Split panesはtmux/iTerm2のみ対応（VS Code Terminal、Windows Terminal等は未対応）
Cコンパイラを16体のClaudeが自律開発した話
Anthropicのエンジニアがストレステストとして、16体のClaudeエージェントにRust製Cコンパイラを自律開発させた 事例が公開されています。
- 約2,000セッション、2週間にわたる開発
- 10万行のRustコード
- Linuxカーネルのコンパイルに成功
- GCCテストスイートの99%をパス
- QEMU、FFmpeg、SQLite、PostgreSQL、Redisのビルドにも成功
- 費用は約 $20,000（20億入力トークン）
この事例は、エージェントチームが単なる実験にとどまらず、実際の大規模開発にも応用可能であることを示しています。
まとめ
Claude Code Agent Teamは、AIによるソフトウェア開発を「1対1のペアプログラミング」から「チーム開発」へと進化させる仕組みです。
AIは指示を間違えると、想定したものと違うものを完璧に作成します。
チームを作成することで、お互いを監視させるのでリスクを減らすことができ複数視点のレビュワーも設置できます。
- 独立性の高いタスクを並列に進められる
- エージェント同士が直接コミュニケーションを取り、依存関係などを自律的に解決する
- ファイル競合を避けるタスク設計がカギ
まだ研究プレビューの段階ですが、特にレビュー、新機能開発、デバッグの仮説検証といったシナリオでは、単一セッションでは得られない効率を発揮します。
トークンコストは高いので、すべてに適用するのではなく、「並列化で本当に効率が上がるか」 を判断基準にすると良いと思います。