Agent Teams（エージェントチーム）　会話で協調させる

一行でいうと

複数のClaude Codeが、共有タスクリストとメッセージで直接やり取りしながら進める仕組みです。まだ実験的機能で、自分でオンにして使います。

エージェントチームが共有タスクを見ながら互いに直接相談する仕組み

中央の仕事を共有しながら、メンバー同士が横に相談できるのが特徴です。

サブエージェントとの違いは一点だけ

Agent Teamsとサブエージェントの違いは、部下同士が直接話せるかどうかの一点です。

前のレッスンのサブエージェントは、上司にしか報告できません。部下同士は会話できない。Agent Teamsでは、そこが変わります。1人のリード（メインのセッション）が複数のチームメイトを生成し、共有のタスクリストとメールボックスを持たせる。チームメイト同士が直接メッセージを送り合えます。

会社にたとえるなら、サブエージェントはそれぞれが部長にだけ報告書を上げる状態、Agent Teamsは部門横断の会議です。営業担当の指摘を聞いた開発担当が、自分の提案を修正できる。この「その場での調整」が起きるかどうかが分かれ目です。

使い方

実験的機能なので、環境変数で自分で有効化します。

Terminal

$export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
$claude
$3人のチームで、この資料を「構成」「エビデンス」「表現」の観点から並列レビューして。指摘が食い違ったら相談して統一見解にまとめて

最後の一文が効きます。食い違いを相談させるのがAgent Teamsの本領で、ここを指示しないとサブエージェントと変わりません。

向いている仕事・向かない仕事

判定の軸はシンプルです。メンバー同士が話す必要があるか。ないなら、下の階層で足ります。

実際の効果も測られています。Anthropicが自社のマルチエージェント型リサーチシステムを検証したところ、単一エージェントより社内評価で90.2%上回る結果が出ました。体数の目安も分かっていて、単純な事実確認なら1体（ツール呼び出しは3〜10回程度）、比較検討なら2〜4体、複雑な調査になると10体を超えることもあるとしています。

よくある誤解と罠

罠1: いきなり大編成を組む

公式の推奨開始規模は3〜5人です。人間のカンファレンスと同じで、人数を増やせば議論の質が上がるわけではありません。

罠2: トークン消費を見積もらずに常用する

公式ドキュメントに、単一セッションよりかなり多くのトークンを使うと明記されています。同じくAnthropicのマルチエージェント研究の実測では、トークン消費が通常のチャット1回分の約15倍にのぼったと報告されています。全員が読み、全員が書き、そのうえで互いにメッセージを送るので当然です。

日常業務は1体か、せいぜいサブエージェント数体。Agent Teamsは「ここぞ」の場面だけ、と決めておくのが実務的です。

注意

常時オンにしない

実験的機能で、仕様も変わります。環境変数を .zshrc に書き込んで常時オンにするのではなく、必要なときだけ立ち上げるのが安全です。

罠3: 体数を増やすこと自体を目的にする

体数を増やせば、成果も比例して伸びるとは限りません。ほしいのは成果であって、エージェントの数ではないからです。

VoicesBLOG / NEWSLETTER

“Five agents can work on this codebase simultaneously. Five people can't. That's backwards.”
筆者訳
5体のエージェントは同じコードベースで同時に作業できるが、5人の人間にはできない。これは順序が逆だ。

Kent BeckTDD考案者・アジャイルソフトウェア開発宣言共同著者Kent Beck's Newsletter2026年4月23日newsletter.kentbeck.com/p/genie-lessons-nobody-wants-agents

TDDの考案者であるKent Beckは、マルチエージェント自体を目的にすることに疑問を投げかけています。体数を増やすほど、今度はエージェント同士の調整という別の問題が生まれるからです。この回で判定の軸としてきた「メンバー同士が話す必要があるか」も、体数を増やすための基準ではなく、増やさなくて済む場面を見極めるための基準だったことを思い出してください。