Claude Code Agent Teams を試す：複数AIエージェントの協調作業

Last updated at 2026-02-06Posted at 2026-02-06

はじめに

Claude Code に Agent Teams という実験的機能が追加されました。複数の Claude Code インスタンスをチームとして動かす仕組みで、1つのセッションがリーダーになり、チームメイトに作業を振って結果を統合します。

従来の Subagent（サブエージェント）は「1セッション内で子プロセスを生やして結果だけ受け取る」構造でしたが、Agent Teams では各メンバーが独立したコンテキストウィンドウを持ち、メンバー同士が直接メッセージをやり取りできるのが大きな違いです。

この記事では、セットアップから実際のユースケース実行、使ってみた所感までをまとめます。

Agent Teams とは

基本アーキテクチャ

コンポーネント	役割
Team Lead	チームを作り、タスクを振り、結果を統合するメインセッション
Teammates	各自が独立した Claude Code インスタンスとして作業する
Task List	全メンバーが共有するタスクリスト
Mailbox	エージェント間のメッセージングシステム

チームの設定やタスクはローカルに保存されます：

チーム設定: ~/.claude/teams/{team-name}/config.json
タスクリスト: ~/.claude/tasks/{team-name}/

Subagent との比較

	Subagent	Agent Teams
コンテキスト	独自ウィンドウ、結果を呼び出し元に返す	独自ウィンドウ、完全に独立
コミュニケーション	メインエージェントへの結果報告のみ	メンバー同士が直接メッセージ可能
コーディネーション	メインエージェントが全管理	共有タスクリストで自律的に調整
適した場面	結果だけほしい集中タスク	議論・協調が必要な複雑な作業
トークンコスト	低い（結果要約のみ返す）	高い（各メンバーが独立インスタンス）

使い分けはシンプルで、メンバー間のやり取りが必要かどうかです。単独で完結する調査なら Subagent、知見の共有や相互検証が要るなら Agent Teams を選びます。

セットアップ

1. 機能を有効化する

Agent Teams はデフォルトで無効です。settings.json に環境変数を追加します：

// ~/.claude/settings.json
{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

設定したら Claude Code を再起動すれば反映されます。

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS は実験的オプションです。正式機能に昇格すれば、この設定自体が不要になる可能性があります。

Agent Teams はチームメイトごとに独立した Claude インスタンスが動くため、トークン消費がかなり激しいです。実質的に Claude MAX プランまたは Pro プランの利用が前提になります。API 従量課金で使う場合はコストに注意してください。

2. 表示モードを選ぶ

モード	説明	要件
in-process	メインターミナル内で全メンバーが動く。Shift+Up/Down で切り替え	なし
split panes	メンバーごとに独立ペイン。全員の出力を同時に見られる	tmux

デフォルトは "auto" で、tmux セッション内なら split panes、それ以外は in-process になります。明示的に指定したい場合：

{
  "teammateMode": "in-process"
}

または起動時に：

claude --teammate-mode in-process

3. tmux の準備（split panes を使う場合）

brew install tmux

今回は tmux セッション内で実行し、split panes モードで各メンバーの出力を同時に見ながら作業しました。

ユースケース実行

並列コードレビュー

背景: 1人のレビュアーはどうしても特定の観点に偏りがちです。セキュリティ・パフォーマンス・テストカバレッジを同時に見ることで、抜け漏れを減らせます。

プロンプト例:

PR #142 をレビューするエージェントチームを作ってください。3人のレビュアーを生成して：
- 1人はセキュリティの観点
- 1人はパフォーマンスへの影響
- 1人はテストカバレッジの妥当性
それぞれレビューして結果を報告してください。

動作の流れ:

リーダーがチームを生成し、3つのタスクを作成
各メンバーが同じPRを異なるフィルタで分析
リーダーが3つの観点を統合してレポートにまとめる

考察: 単一セッションでの逐次レビューに比べて、観点の独立性が保たれます。人間のレビューでも「セキュリティレビュー」「パフォーマンスレビュー」を分けるのと同じ発想ですね。ただしトークンコストは3倍以上になるので、重要なPRに絞るのが現実的です。

実際に試してみた:

あるNext.jsプロジェクトの+1,500行のPR（Route Handler追加、ユーティリティライブラリ、テスト23件を含む）で、セキュリティ・パフォーマンス・テストカバレッジの3観点で並列レビューを回しました。

所要時間の内訳（実測値）:

フェーズ	所要時間	内容
PR情報取得	~5秒	`gh pr view` + `gh pr diff` 並列実行
差分読み込み	~3秒	1,600行の差分ファイル読み込み
チーム作成+タスク作成	~5秒	`spawnTeam` + `TaskCreate` x3
3エージェント起動	~3秒	`Task` x3 並列起動
レビュー実行（並列）	~60-70秒	ボトルネック = test-reviewer
- performance-reviewer	~55秒	最速で完了
- security-reviewer	~70秒
- test-reviewer	~80秒	最遅で完了
シャットダウン送信	~3秒	`shutdown_request` x3
シャットダウン応答待ち	~15-20秒	各エージェントの承認待ち
クリーンアップ（1回目失敗）	~5秒	メンバーがまだactive判定
タスク更新+リトライ	~10秒	`TaskUpdate` x5 + `cleanup`
クリーンアップ（2回目も失敗）	~5秒	まだactive判定
クリーンアップ（最終成功）	~5秒	全員terminated後に成功
合計	約3分〜3分半

ボトルネック:

クリーンアップが一番非効率 - シャットダウン承認後もactive判定が残って、3回試行が必要でした（約20秒のロス）。エージェント終了の伝播にラグがあります
シャットダウンのラウンドトリップ - request → 応答待ち → terminated通知が各エージェントで逐次処理される感じで、~20秒かかりました
レビュー本体は妥当 - 3エージェント並列で最遅80秒。ここは許容範囲です

レビュー本体（~70秒）に対して後始末（シャットダウン+クリーンアップ）が~30-40秒。全体の約1/3が片付け作業で、まだ experimental だなと感じる部分です。

トークンコスト（推定値）:

項目	推定トークン
リーダー（Opus）
- PR情報取得・差分読み込み	~8K input
- チーム管理・サマリー生成	~15K input + ~5K output
security-reviewer（Sonnet）	~10K input + ~4K output
performance-reviewer（Sonnet）	~10K input + ~4K output
test-reviewer（Sonnet）	~10K input + ~4K output
合計（概算）	~50-70K input / ~15-20K output

3エージェント並行なので実時間は1エージェント分とほぼ同じですが、トークン消費は3倍です。チームメイトのモデルはリーダーと同じものが自動で選ばれますが、プロンプトで「Sonnet を使って」と指示すれば変更できます。今回はレビュアーを Sonnet で動かしたところ、Opus 比でコストは約1/5に抑えられました。

レビュー品質:

各レビュアーが重要度（CRITICAL / HIGH / MEDIUM / LOW）付きの構造化レポートを返しました。検出内容はこんな感じです：

セキュリティ: HIGH 1件、MEDIUM 3件。入力値のサニタイズ漏れやエラーログの情報漏洩リスクなどを指摘
パフォーマンス: HIGH 2件。同期I/Oのブロッキングやキャッシュ不在による不要な再計算を検出
テストカバレッジ: CRITICAL 2件。コアロジックの未テストを指摘し、推定カバレッジ40-50%で目標80%に未達と報告

面白かったのは、3人の指摘に重複がなかった点です。セキュリティレビュアーがパフォーマンスの問題に言及したり、その逆が起きたりすることはなく、観点の独立性がきれいに保たれていました。各レビュアーが独立したコンテキストウィンドウで、それぞれ特化したプロンプトで動いた結果でしょう。

1,500行のPRに対して約3分で3観点のレビューが揃うのは、人間のレビューと比べるとかなり速いです。ただしトークンコストは合計で約65-90K（input + output合算）になるので、日常の小規模PRには過剰です。大規模な機能追加やセキュリティ上重要な変更など、多角的レビューが本当に要るPRに絞るのが良さそうです。

マルチロール分析：サッカーの試合メンバー選出（split panesを試してみる）

背景: Agent Teams の本質は「複数の独立した視点から並列分析して統合する」ことです。これはコードレビューに限りません。ここではコードと無関係な題材——サッカーの試合メンバー選出——で、split panes モードの動作と多角的分析の雰囲気を紹介します。

お題: インテル・ミラノの次節（vs サッスオーロ、2026年2月8日アウェイ）に最適なスターティング11人を選出する。

プロンプト例:

エージェントチームを作ってください。インテルの次節のスターティングメンバーに最適な11人を選んでください。
エージェントチームは監督、分析官、医療スタッフ、コーチ、広報で設定してね

チーム構成:

エージェント名	役割	分析の観点
`kantoku`	監督	フォーメーション選択、戦術プラン、対戦相手対策
`analyst`	データ分析官	ゴール数・パス成功率・走行距離等の統計データに基づく選出
`medical`	医療スタッフ	負傷者の回復段階、疲労リスク、高齢選手の起用可否
`coach`	アシスタントコーチ	練習でのコンディション、若手の成長度、チームケミストリー
`pr-staff`	広報	メディアの注目度、ファンの期待、移籍噂への対応、ブランディング

動作の流れ:

リーダーがWeb検索でインテルの最新スカッド・負傷者情報・対戦相手情報を収集
TeamCreate でチームを作成し、5つのタスクを TaskCreate で登録
5エージェントを Task で並列起動。各エージェントにスカッド情報・負傷者リスト・対戦相手の予想フォーメーションをコンテキストとして渡す
各エージェントがそれぞれWeb検索して、自分の専門視点で分析・スターティング11を提案
リーダーが5つの報告を統合し、意見が分かれたポイントを整理して最終メンバーを決定

各エージェントの提案の違い:

同じ11人を選ぶタスクでも、役割によって推薦が分かれるのが面白いところです：

論点	監督・分析官	コーチ	医療	広報
CB3枚目	アカンジ（対戦相手対策）	アチェルビ（経験・リーダーシップ）	アチェルビは60分交代推奨	アチェルビ温存してユベントス戦へ
中盤の構成	経験者3枚	同左	ムヒタリアン70分交代	スチッチ（新戦力露出）
フラッテージ起用	戦術的に必要	バレッラ不在のカバー	特に制限なし	移籍騒動後のスタメン起用で忠誠アピール

広報が「フラッテージのスタメン起用はノッティンガム・フォレスト移籍破談後のメッセージとして重要」と指摘するのは、他の役割からは出てこない観点です。医療スタッフが「チャルハノールはヒラメ筋損傷の再発リスクが高いため緊急時のみ15分」と具体的な制限を出すのも同様です。

最終統合結果（3-5-2）:

              ゾマー

    ビセック  -  アカンジ  -  バストーニ

 ルイス・エンリケ - フラッテージ - ジエリンスキ - ムヒタリアン - ディマルコ

        ラウタロ・マルティネス  -  テュラム

所要時間と実行特性:

フェーズ	所要時間	内容
Web検索（リーダー）	~10秒	スカッド・負傷者・対戦相手情報の収集
チーム作成+タスク作成	~5秒	`TeamCreate` + `TaskCreate` x5
5エージェント起動	~5秒	`Task` x5 並列起動
分析実行（並列）	~90-120秒	各エージェントがWeb検索+分析+提案
統合レポート作成	~30秒	リーダーが5報告を統合
シャットダウン+片付け	~30秒	`shutdown_request` x5 + クリーンアップ
合計	約3-4分

考察:

コード開発とは無関係ですが、Agent Teams の特性がよく出ています：

split panes モードの視認性: tmux のペインに5つのエージェントが並んで、それぞれWeb検索→分析→レポート作成を行う様子がリアルタイムで見えます。「何が起きてるか分からない」という Subagent の課題が解消されます
観点の独立性: コードレビューと同じく、各エージェントが自分の専門に集中して他の視点に引きずられません。広報が戦術を語り出したり、医療スタッフがファンの期待に言及したりすることはありませんでした
意見の衝突が価値を生む: CB3枚目の選出で4つの異なる意見が出たことで、「ユベントス戦を見据えてアカンジを使いアチェルビを温存する」という統合判断につながりました。単一エージェントだと最初に思いついた1案に固定されがちです
コンテキスト配分が大事: 各エージェントにスカッド情報を丁寧に渡す必要があります。チームメイトはリーダーの会話履歴を引き継がないので、プロンプトの情報量が分析品質に直結します

Agent Teams は「プログラミング専用」ではなく、独立した専門視点からの並列分析を統合するという汎用パターンとして機能します。サッカーのスタメン選出でも、事業戦略の検討でも、技術選定でも、同じ構造が使えます。

操作リファレンス

チームメイトへの直接対話

in-process モード: Shift+Up/Down でメンバー選択、タイプして送信。Enter でセッション表示、Escape で中断。Ctrl+T でタスクリスト表示
split panes モード: ペインをクリックして直接操作

Delegate モード

リーダーが自分で実装し始めてしまう問題への対策です。Shift+Tab で delegate モードに切り替えると、リーダーはコーディネーション専用ツール（チームメイト生成・メッセージ・タスク管理）だけ使えるようになります。

ベストプラクティス

1. チームメイトに十分なコンテキストを渡す

チームメイトはプロジェクトの CLAUDE.md や MCP サーバー設定は自動で読みますが、リーダーの会話履歴は引き継ぎません。プロンプトにタスク固有の情報を含めるのが大事です。

セキュリティレビュー担当のチームメイトを以下のプロンプトで生成してください：
「src/auth/ の認証モジュールをレビューしてください。JWTトークンは
httpOnly cookieに保存しています。トークン処理、セッション管理、
入力バリデーションに注目し、問題を重要度付きで報告してください。」

2. タスクサイズは適切に

サイズ	問題
小さすぎ	コーディネーションのオーバーヘッドが利益を上回る
大きすぎ	チェックインなしに長時間作業して手戻りリスクが増える
ちょうどよい	明確な成果物がある自己完結した単位（関数、テストファイル、レビューなど）

1メンバーあたり5-6タスクくらいが目安です。

3. ファイル競合を避ける

2人のメンバーが同じファイルを編集すると上書きが起きます。作業分担時に各メンバーの編集対象ファイルが重複しないようにしてください。

4. リーダーが自分で実装し始めたら止める

チームメイトのタスク完了を待ってから進めてください

もしくは最初から Delegate モード（Shift+Tab）を有効にしておきます。

制限事項

現時点での既知の制限です：

制限	内容
セッション再開不可	`/resume` や `/rewind` で in-process のチームメイトは復元されない
タスクステータスの遅延	メンバーがタスク完了をマークし忘れることがあり、依存タスクがブロックされる
シャットダウンの逐次処理	リクエスト→応答待ち→terminated通知がメンバーごとに逐次発生。3人チームで約15-20秒
クリーンアップの不安定さ	シャットダウン承認後も `active` 判定が残り、`cleanup` が失敗することがある。複数回リトライが必要
後始末コスト	シャットダウン+クリーンアップが全体の実時間の約1/3。短いタスクほどオーバーヘッド比率が高い
1セッション1チーム	同時に1つのチームしか管理できない
ネストチーム不可	メンバーが自分のチームやメンバーを作ることはできない
リーダー固定	チームを作ったセッションがずっとリーダー。交代はできない
権限はスポーン時に統一	全メンバーがリーダーの権限を引き継ぐ。個別設定はスポーン後のみ
split panes の環境制限	VS Code統合ターミナル、Windows Terminal、Ghostty では非対応

考察と所感

トークンコストとの付き合い方

Agent Teams の一番のトレードオフはトークンコストです。各メンバーが独立した Claude インスタンスなので、3人チームなら単純に3倍以上消費します。「何でも Agent Teams」ではなく、並列探索が本当に価値を生むケースに絞るのが現実的でしょう。

3人レビュアー構成でPRレビューを実行した際の実測値です：

トークン消費: 合計で約50-70K input / 15-20K output
実時間: 並列実行で約80秒で3人分完了。ただしシャットダウン+クリーンアップに+30-40秒
コスト削減: プロンプトで「チームメイトは Sonnet を使って」と指示すれば Opus 比で約1/5に抑えられます

モデルはデフォルトでリーダーと同じものが自動選択されます。プロンプトで明示すればチームメイトだけ別モデルにできるので、レビュー・調査系は Sonnet で十分、実装系は Opus の方が安全という使い分けが可能です。

コスト vs 品質のトレードオフ

構成	推定コスト	実時間	ユースケース
Opus リーダー + Sonnet x3（プロンプトで指定）	~$0.5-1.0	~3分	PRレビュー、調査
Opus リーダー + Opus x3（デフォルト）	~$2-4	~3分	複雑な実装、設計判断
Sonnet 単独（逐次）	~$0.1-0.2	~5-8分	単一観点のレビュー

※コストは概算。実際の金額はトークン量次第です。

使い分け：

効果が高い: コードレビュー（多角的観点）、バグ調査（競合仮説）、新規モジュール実装（レイヤー分離）
コストに見合わない: 単一ファイルの修正、逐次的な依存関係が多いタスク、ルーチン作業

Subagent との棲み分け

実務では「まず Subagent で試して、メンバー間のやり取りが必要だと分かったら Agent Teams に切り替える」のが良さそうです。Subagent で足りる場面に Agent Teams を使うのはコストの無駄です。

今後試したいパターン

今回はコードレビューとマルチロール分析を試しましたが、他のユースケースも気になります：

競合仮説デバッグ: 原因不明のバグに複数メンバーが異なる仮説を立て、互いに反証させる「科学的ディベート」構造。AIには「同僚の意見を否定しづらい」みたいな心理的ハードルがないので、率直な反証が期待できます
クロスレイヤー実装: フロントエンド・バックエンド・テストを別メンバーが並行実装。plan_mode_required でプラン承認を挟むのが重要になりそうです
デビルズアドボケイト: 推進派と反対派を意図的に生成して、設計判断の盲点を見つける

Delegate モードの重要性

リーダーが自分で実装し始めてしまう問題は、わりと遭遇しやすいです。Delegate モードを最初から有効にしておくのがベターだと思います。人間のPMも「自分でコードを書き始めると管理がおろそかになる」のと同じ構造で、AIにも当てはまるのが面白いところです。

まとめ

Agent Teams は、Claude Code を「1人のアシスタント」から「協調するチーム」に拡張する実験的機能です。3人チームでPRレビューを試したところ、約3分で3観点の構造化レポートが揃い、各レビュアーの指摘に重複がないことを確認できました。トークンコストは合計で約65-90Kと安くはないですが、Sonnet をレビュアーに使えばコストは抑えられます。

まだ experimental で、クリーンアップの不安定さやシャットダウンのオーバーヘッドなど荒削りな部分はあります。ただ、多角的レビューのような「並列探索が本質的に価値を生む」タスクでは、単一セッションでは出せない品質が得られます。まずはコードレビューやリサーチから試して、チームとしてのAI活用の感覚を掴んでいくのが良いでしょう。

最後に運動通信社について

運動通信社は「日本を世界が憧れるスポーツ大国にする」というビジョンを達成するべく、一緒に働く仲間を募集しています！
PMやアプリエンジニア、Webエンジニアなど色んな職種を募集しておりカジュアル面談大歓迎なので是非採用フォームよりご連絡ください！
ぜひ一緒に、自分たちも世の中もワクワクするサービスを作りましょう！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up