概要
Claude Codeにはエージェントを並列で動かす仕組みが2つある。ビルトインの/batchコマンドと、Agent Teams機能。どちらも「複数のエージェントを同時に動かして作業させる」という点では同じだが、アーキテクチャが根本的に違う。
最初は「/batchがあるなら、自分が作ったカスタムスキル/x-wt-teamsはもう不要なのでは？」と思った。が、調べてみると全くの別物だった。そのリサーチメモ。
/batch: サブエージェントによる並列実行
/batchはClaude Codeのビルトインコマンドで、大規模なコードベースのリファクタリングやマイグレーション向けに作られている。
ワークフローは以下の通り。
- リサーチフェーズ: コードベースを分析して作業単位を特定
- 5〜30程度の作業単位に分解
- ユーザーが内容を確認・承認
- 各作業単位を並列にサブエージェントで実行
- 各エージェントが独立してPRを作成
内部的にはAgent toolにisolation: "worktree"を指定して起動する、fire-and-forget方式。各エージェントは自分のworktreeで独立して作業し、完了したらPRを出す。エージェント同士は互いの存在を知らない。共有タスクリストもない。
gitのブランチ構造はこうなる。
各PRは独立しているので、ユーザーが個別にレビューしてマージする。典型的なユースケースとしては、moment.jsをdayjsに置換する、全ファイルに型アノテーションを追加する、APIバージョンを移行する、などがある。要するに「同じ種類の作業を多数のファイルに対して繰り返す」パターンに強い。
Agent Teams: 柔軟なエージェント協調システム
Agent Teamsは、TeamCreate、TaskCreate/TaskUpdate/TaskList、SendMessageなどを組み合わせた協調システム。/batchとは設計思想が違う。
/batchとの比較をまとめるとこうなる。
| 項目 | /batch（サブエージェント） | Agent Teams |
|---|---|---|
| 仕組み | Agent tool + worktree | TeamCreate + Agent + SendMessage |
| 通信 | 一方向（結果のみ） | 双方向（メッセージング） |
| タスク管理 | なし（暗黙的） | 共有タスクリスト |
| 調整 | Fire-and-forget | マネージャーが監視・指示 |
| 依存関係 | なし | blockedByで設定可能 |
| 柔軟性 | 決まったパターン | 自分でワークフローを設計 |
Agent Teamsの特徴は、エージェントの協調の仕方を自分で設計できるところにある。
SendMessageはエージェント間のDMで、通常のテキスト出力は他エージェントに見えない。他のエージェントに何かを伝えたければ、SendMessageで明示的に送る必要がある。タスクリストは全エージェントで共有されていて、タスクの状態変化を通じた間接的な連携もできる。blockedByでタスクの依存関係を設定すれば、あるタスクが完了するまで別のタスクが開始されないようにもできる。
tmuxを入れていると、各エージェントが別々のペインに表示される。
左ペインがマネージャーエージェントで、タスク作成、エージェント起動、進捗管理をしている。右ペインに子エージェントがそれぞれのworktreeで作業していて、メッセージのやり取りやタスク状態変化がリアルタイムで流れる。
具体例: 自分の/x-wt-teamsスキル
自分はAgent Teamsを使った/x-wt-teamsというカスタムスキルを作って使っている。これは関連する複数の機能を並列開発するためのスキルで、Agent Teamsの具体的な活用例になる。Agent TeamsそのものについてはいつClaude CodeのAgent Teamsを使うのかに書いた。
ワークフローは以下の通り。
- ベースブランチ（
base/<project>）を作成 - mainに対するルートPRを作成
- トピックごとにworktreeを作成
- 各worktreeにエージェントを配置して並列実行
- 各トピックPRをベースブランチにマージ
- コードレビュー、CIチェック
- ルートPR 1本にまとめてmainにマージ
gitのブランチ構造はこうなる。
/batchとの違いは、最終的に1つのルートPRに収束させるところ。/batchは各作業単位がそれぞれ独立したPRになるが、/x-wt-teamsではトピックPRはベースブランチに対して出されて、最終的にmainに対する1つのルートPRにまとまる。関連する機能をまとめてレビュー・マージしたい場合にこの構造が効く。
結論: 解いている問題が違う
使い分けのポイントはタスクの「大きさ」ではなく「相互依存性」にある。
50個の独立したファイルマイグレーション。これは/batchで十分。タスクとしては大きいが、各作業単位が完全に独立している。エージェント同士が連携する必要がない。
3つの関連する機能の同時開発。型やAPIを共有していて、一方の結果が他方に影響する。これはAgent Teams向き。タスクとしては小さいが、相互依存がある。
/batchがあるからAgent Teamsが不要になるわけではない。逆もまた然り。解いている問題が違う。
余談
最初に「/batchがあるなら/x-wt-teamsは要らないのでは」と思ったのは、「並列でエージェントを動かす」という表面的な共通点だけを見ていたから。中身を見てみると、通信の方向性、タスク管理の有無、PRの収束先まで全部違うので、代替関係ではなく補完関係だった。