Claude Code の Agent teams を使うべき理由

Claude Code の Agent teams を試して分かった決定的な違い

複数の Claude が同時に独立して考えて、しかもお互いに直接メッセージをやりとりできる

これが Claude Code の Agent teams なんやけど、2026 年 2 月上旬に実験的機能として公開され、Opus 4.6 の話題と同時期に注目を集めた機能で、使ってみたらサブエージェントとは全然別物やった

バグ調査で複数の仮説を同時に検証させたり、セキュリティ・パフォーマンス・テストの 3 軸で並列レビューさせたり、できることのレベルが一段上がる

コンテキストが汚染されないから、巨大な PR や長期調査でも文脈がぐちゃぐちゃになりにくいし、各チームメイトが独立した視点で考えるから仮説の競合が自然に起きるんよね

X で毎日 AI 情報を配信してるコムテです。Agentic AI / AI 駆動開発 / Claude Code などを中心に情報を配信しています

参考リンク

この記事は Anthropic 公式ドキュメントの Agent teams ガイドと、Lydia Hallie 氏の投稿（いいね 3,567 件、表示 80.4 万回）にインスピレーションを受けて、実際に試した結果をまとめたもの。Addy Osmani 氏のブログ記事や Anthropic の公式リリース記事も参照してる

Agent teams とは何か - なぜサブエージェントと違うのか

Agent teams は複数の Claude Code インスタンスが協調して動く仕組みなんやけど、既存のサブエージェントとは根本的に違う

サブエージェントは「調べて返す部下」やけど、Agent teams は「議論できるチーム」なんよね

具体的には、1 つのセッションがリード（team lead）として全体を統括して、残りのセッションがチームメイト（teammates）として独立して動く

各チームメイトは独自のコンテキストウィンドウを持つから、リードのコンテキストが汚染されることがない

そして決定的なのが、チームメイト同士が直接メッセージをやりとりできる点

サブエージェントはメインエージェントにしか結果を返せなかったけど、Agent teams ではチームメイトが互いに議論したり、意見を戦わせたりできる

これによって、複数の視点から同時に問題にアプローチできるようになった

サブエージェントと Agent teams の比較 - 使い分けの基準

両者の違いを明確にするために、公式ドキュメントの比較表をベースに整理した

Subagents の特徴

Agent teams の特徴

要するに、単純に並列処理したいだけならサブエージェントで十分

でも複数の視点から同時に考えさせて、その結果を議論させたいなら Agent teams を使うべき

例えばバグ調査で「メモリリークの可能性」「非同期処理のタイミング問題」「外部 API の仕様変更」という 3 つの仮説を同時に検証させて、チームメイト同士で議論させながら絞り込むような使い方ができる

アーキテクチャ - 4 つのコンポーネントで動く仕組み

Agent teams は 4 つのコンポーネントで構成されてる

実際のファイルとしては以下の場所に保存される

チーム設定は ~/.claude/teams/{team-name}/config.json に、タスクリストは ~/.claude/tasks/{team-name}/ に配置される

この仕組みのおかげで、リードは全体の進捗を把握しつつ、各チームメイトは独立して作業できる

タスクリストは pending → in progress → completed の 3 段階で管理されて、チームメイトが自分でタスクをクレームして進めていく

タスク間には依存関係も設定できて、依存先が完了するまでブロックされる仕組みになってる。依存タスクが完了すると自動でアンブロックされるから、手動介入は不要

複数のチームメイトが同時にタスクをクレームしようとしても、ファイルロックで競合が防がれるようになってる

リードがいちいち指示しなくても、チームメイトが自律的に動くようになってるのがポイント

有効化方法 - 設定ファイル 1 行で使える

Agent teams は実験的機能やから、環境変数で有効化する必要がある

~/.claude/settings.json に以下を追加するだけ

これだけで準備完了

あとは自然言語で「3 人のチームを作って」と指示すれば、自動的にチームが組まれる

ちなみに自分からチーム作成を頼まなくても、Claude が「このタスクはチームでやった方がいい」と判断したら提案してくれることもある。ただし勝手には作らず、必ず承認を求めてくるから安心

モデルも指定できて、例えば「Sonnet を使ってチームを作って」と言えば、全チームメイトが Sonnet になる

コスト削減したいときは明示的に Haiku を指定するのもあり

表示モードの選択 - tmux か iTerm2 があると捗る

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

in-process モード はメインターミナル内で全チームメイトが動く形式

Shift+Up と Shift+Down でチームメイトを巡回して、直接メッセージを送れる

split panes モード は各チームメイトが独自のペインを持つ形式

tmux か iTerm2 が必要やけど、全員の進捗が同時に見えるから視認性が段違い

公式は iTerm2 を使う場合 tmux -CC で起動するのを推奨してる。it2 CLI のインストールと、iTerm2 の Settings → General → Magic → Enable Python API の有効化も必要

設定は ~/.claude/settings.json で指定できる

CLI フラグで指定することも可能

デフォルトは auto で、tmux セッション内なら split panes、そうでなければ in-process になる

チームの作り方と操作方法 - 自然言語でほぼ完結

チームの作成は自然言語で指示するだけ

例えばこんな感じ

これだけで 3 人のチームメイトが生成されて、それぞれの視点でレビューが始まる

チームメイトの数やモデルも自由に指定できる

plan approval を有効にすると、チームメイトに計画承認を要求できる

これによって、勝手に実装が走るのを防げる。チームメイトは read-only の plan mode で作業して、計画ができたらリードに承認リクエストを送る

リードが承認すれば実装フェーズに進むし、却下すればフィードバック付きで差し戻される。リードの判断基準は「テストカバレッジを含む計画のみ承認して」とか「DB スキーマを変更する計画は却下して」みたいにプロンプトで指定できる

特にリスクの高い操作をする場合は、plan approval を使うのが安全

delegate mode は Shift+Tab で有効にできて、リードがコードを一切触らずに指揮だけに専念するモード

大規模な並列作業では、リードが実装に手を出さず全体を見渡す方がうまくいく

直接メッセージ は in-process モードなら Shift+Up と Shift+Down でチームメイトを選んで送信できる

Enter でチームメイトのセッションを直接表示して、Escape でそのターンに割り込みできる。Ctrl+T でタスクリストの表示/非表示を切り替えられる

split panes モードなら、チームメイトのペインをクリックするだけで直接操作できる

特定のチームメイトに追加指示を出したいときに使う

タスク管理 は共有タスクリストで行われる

リードがタスクを作成して、チームメイトが pending 状態のタスクをクレームして in progress にして、完了したら completed にマークする

タスクのサイズは 5〜6 個 / チームメイトが目安

小さすぎるとオーバーヘッドが大きくなって、大きすぎるとチェックインなしに長時間作業することになる

シャットダウンとクリーンアップ はリードから指示する

シャットダウンはリードから「Ask the researcher teammate to shut down」のように指示する。チームメイトは承認してグレースフルに終了するか、理由を付けて拒否することもできる

シャットダウンが遅い場合があるけど、これはチームメイトが現在のリクエストやツール呼び出しを完了させてから終了するため

Hooks で品質ゲートを設ける - タスク完了前に自動レビュー

Agent teams では 2 つの Hooks が使える

TeammateIdle Hook はチームメイトがアイドルになりそうなときに発火する

exit code 2 を返すと、フィードバックを送信して作業を続行させられる

例えば「まだテストが足りない」「ドキュメントを書いてない」といったフィードバックを自動で返せる

TaskCompleted Hook はタスク完了時に発火する

exit code 2 を返すと、完了を阻止してフィードバックを送れる

例えば「テストカバレッジが 80% 未満だから完了させない」みたいなゲートを設けられる

Hooks を使うことで、チームメイトが勝手に終了するのを防いで、品質基準を満たすまで作業を続けさせることができる

設定例はこんな感じ

こうすることで、人間がチェックしなくても自動で品質を担保できる

実践ユースケース 1 - 並列コードレビューで抜け漏れを防ぐ

最も実用的なのが並列コードレビュー

1 人でレビューすると、セキュリティのことを考えてるときにパフォーマンスのことが見えなくなったり、テストカバレッジのことを考えてるときにアクセシビリティのことが抜けたりする

Agent teams を使えば、3 人のチームメイトにそれぞれ専門分野を担当させられる

実際に試したら、セキュリティ担当が「この API エンドポイントに認証チェックがない」と指摘して、パフォーマンス担当が「この SQL クエリが N+1 になってる」と指摘して、テスト担当が「この条件分岐のテストがない」と指摘した

3 つの視点が同時に動くから、抜け漏れが物理的に減る

しかもチームメイト同士が直接メッセージできるから、「この認証チェックを追加するとパフォーマンスに影響ある？」みたいな議論が自然に発生する

これはサブエージェントでは絶対にできなかった

実践ユースケース 2 - 競合仮説による科学的バグ調査

バグ調査で威力を発揮するのが、競合仮説アプローチ

例えば「アプリが 1 メッセージ後に終了する」という報告があったとき、考えられる仮説は複数ある

5 人のチームメイトがそれぞれ異なる仮説を検証して、お互いに議論しながら絞り込んでいく

「メモリリークの可能性」を検証する人、「非同期処理のタイミング問題」を検証する人、「外部 API の仕様変更」を検証する人、「WebSocket の切断」を検証する人、「例外処理の不備」を検証する人

チームメイト同士が「この仮説は再現しなかった」「この仮説は部分的に正しい」と議論して、最終的にコンセンサスが形成される

これは人間のチームが科学的にバグを追い詰めるプロセスと同じなんよね

1 人で全仮説を順番に検証するより、5 人が並列で検証して議論する方が圧倒的に早い

実践ユースケース 3 - CLI ツール設計を多角的に検討

設計段階でも Agent teams は有効

例えば新しい CLI ツールを設計するとき、UX・技術アーキテクチャ・悪魔の代弁者の 3 つの視点から検討させられる

UX 担当は「開発者が普段使ってるワークフローに溶け込むか」を考えて、技術アーキテクチャ担当は「スケールするか」「保守できるか」を考えて、悪魔の代弁者は「本当に必要か」「既存ツールで十分じゃないか」を問い詰める

3 つの視点が同時に動くことで、設計の穴が早期に見つかる

しかもチームメイト同士が議論するから、UX と技術のトレードオフとか、既存ツールとの差別化ポイントとかが自然に浮き彫りになる

公式ドキュメントのベストプラクティスでも「まずはリサーチとレビューから始めろ」と推奨されてて、コードを書かないタスクで慣れるのが良い

ベストプラクティス - チームを効果的に動かすコツ

実際に使ってみて分かったベストプラクティスをまとめる

チームメイトに十分なコンテキストを与える のが最重要

spawn プロンプトに詳細を含めないと、チームメイトが何をすべきか分からなくて迷走する

「セキュリティ担当」だけじゃなくて「セキュリティ担当。特に認証・認可周りと SQL インジェクション・XSS のリスクをチェック」みたいに具体的に指示する

タスクサイズを適切に保つ のも大事

5〜6 タスク / チームメイトが目安で、これより小さいとオーバーヘッドが大きくなって、これより大きいとチェックインなしに長時間作業することになる

リードが勝手に実装し始めないように するのもポイント

リードは指揮に専念すべきで、実装はチームメイトに任せる

もしリードが実装し始めたら「Wait for your teammates」と指示すれば止まる

delegate mode（Shift+Tab）を使えば、リードが自動的に指揮専念モードになる

まずはリサーチとレビューから始める のが公式推奨

いきなり並列実装をやるとファイル競合が発生しやすいし、調整コストが高い

並列レビュー、バグ調査、ライブラリ調査、設計検討あたりで慣れてから、並列実装に移行するのが安全

ファイル競合を避ける ために、各チームメイトが異なるファイルを担当するように分ける

同じファイルを複数人で触ると、後から保存した方が勝つから、片方の作業が消える

フロント担当・バック担当・テスト担当みたいに、ファイル単位で分けるのが確実

定期的に進捗確認・軌道修正 するのも忘れずに

完全放置はダメで、たまにチームメイトの進捗を見て「そっちじゃなくてこっちを優先して」みたいな指示を出す

split panes モードなら全員の進捗が同時に見えるから、これがやりやすい

トラブルシューティング - よくある問題と解決法

実際に使ってて遭遇した問題と解決法を並べる

チームメイトが表示されない ときは、Shift+Down で巡回して探す

split panes モードなら tmux ls でセッション一覧を確認する

パーミッション確認が多すぎる ときは、permission settings で事前承認しておく

特に --dangerously-skip-permissions を使うと、全チームメイトもスキップするようになる

ただしセキュリティリスクが上がるから、信頼できるタスクのみで使う

エラーで停止した チームメイトは自動復旧しないから、直接指示するか、新しいチームメイトに置き換える

Shift+Up でエラーが出たチームメイトを選んで「このエラーを解決して」と指示すれば再開する

リードが早期終了する 問題もある

全タスク完了前に「終わった」と判断して終了することがあるんよね

その場合は「続けて」「まだタスクが残ってる」と指示すれば再開する

孤立 tmux セッション が残ることがある

tmux ls で確認して、不要なセッションは tmux kill-session -t <session-name> で削除する

タスクステータスが遅延する ことがあって、チームメイトが完了したのにタスクリストが更新されないことがある

その場合はリードから「タスクリストを更新して」と指示すれば同期される

/resume や /rewind で in-process チームメイトが復元されない のは既知の制限

セッションを再開すると、チームメイトが消えてる

split panes モードでも完全復元は保証されないが、in-process より状況把握はしやすい

長期作業の場合は定期的にチェックポイントを作っておく

制限事項 - 知っておくべき現時点の限界

Agent teams は実験的機能やから、いくつか制限がある

1 セッション 1 チームのみ で、複数のチームを同時に動かすことはできない

ネストチーム不可 で、チームメイトがさらにチームを作ることはできない

リードは固定 で、途中でリードを変更することはできない

パーミッションはスポーン時に設定 されて、リードの権限設定を引き継ぐ

スポーン後に個別変更は可能やけど、デフォルトではリードと同じ権限になる

スプリットペインは tmux or iTerm2 必須 で、VS Code の統合ターミナル、Windows Terminal、Ghostty では split panes モードが使えない

/resume と /rewind で in-process チームメイトが復元されない から、セッション再開時は注意が必要

タスクステータスが遅延する ことがあって、リアルタイムで同期されないことがある

シャットダウンが遅い 場合があって、数秒から場合によっては 10 秒以上かかることがある

これらの制限を理解した上で使えば、十分実用的に動く

トークンコストとパーミッション - 運用で気をつける点

トークンコストはチームメイト数に比例して跳ね上がる

各チームメイトが独立した Claude インスタンスやから、3 人チームなら単純計算で 3 倍のトークンを消費する

ただし実際には、リードのコンテキストが汚染されないから、長期的には効率が良くなることもある

特に巨大な PR や長期調査では、コンテキストがぐちゃぐちゃになって何度もリセットするより、最初からチームで分担した方がトータルコストが低くなる

broadcast は全チームメイトにメッセージを送るから、コストが高い

特定のチームメイトにだけ伝えたいなら message を使う

パーミッションはリードの設定を引き継ぐから、リードで --dangerously-skip-permissions を使うと、全チームメイトもスキップするようになる

セキュリティリスクが上がるから、信頼できるタスクのみで使う

スポーン後に個別のチームメイトだけパーミッションを変更することも可能やけど、基本的にはリードで事前に設定しておく方が安全

コンテキストと通信 - 各チームメイトが見えるもの

各チームメイトは独自のコンテキストウィンドウを持つ

CLAUDE.md、MCP サーバー、Skills はロードされるから、リードと同じ設定が使える

ただしリードの会話履歴は引き継がれない

だからチームメイトに十分なコンテキストを与えるには、spawn プロンプトに詳細を含める必要がある

メッセージは自動配信されて、チームメイトが何かを報告したらリードに届く

アイドル通知もあって、チームメイトが何もすることがなくなったらリードに通知が来る

message は 1 対 1 のメッセージで、特定のチームメイトにだけ送られる

broadcast は全チームメイトに送られるから、全員に共有したい情報を伝えるときに使う

ただし broadcast はコストが高いから、必要なときだけ使う

海外での実践事例 - 実際にどう使われてるか

海外の開発者コミュニティでも Agent teams は早速活用されてる

Addy Osmani 氏のブログによると、6 人の Claude チームで大規模なコードベースをレビューさせた結果、数時間で 13 件の即時修正可能な問題と 22 件の中長期課題を発見したとのこと

さらに極端な事例として、Anthropic のエンジニアリングブログでは 16 エージェントが約 2,000 セッション、API コスト約 $20,000 をかけて Rust ベースの C コンパイラを一から構築し、10 万行のコードで Linux 6.9 をビルドできるレベルまで到達した事例が紹介されてる

これらの事例から分かるのは、Agent teams はレビューや調査のような「読み中心」のタスクでは即座に実用的やし、実装タスクでもファイル分担さえしっかりすれば大規模プロジェクトにも対応できるということ

ただし、トークンコストは確実に跳ね上がるから、費用対効果を見極めた上で使うのが大事

まとめ - Agent teams を使うべきタイミング

Agent teams は複数の視点から同時にアプローチしたいときに使う

並列コードレビュー、競合仮説によるバグ調査、多角的な設計検討あたりが特に相性良い

サブエージェントは結果だけ返してくれればいいタスク向けで、Agent teams は議論と協調が必要なタスク向け

トークンコストは高いけど、コンテキスト汚染を防げるから、長期的には効率が良くなることも多い

制限はあるけど、並列で探索する価値があるタスクには既に実用レベル

まずはリサーチとレビューから始めて、慣れてきたら並列実装にも使っていくのが良い

リードが指揮に専念して、チームメイトが自律的に動く形を作れれば、開発速度が段違いに上がる