AIコーディングエージェントを1体動かすのは簡単です。同じコードベースで3体を並列に動かすとなると面白くなってくる——そして、そのとき必要になるのがツール選びです。
「ベスト」なオーケストレーターはありません。あなたのワークフローに合う「正しい」ものがあります。ここでは、マルチエージェント構成を何か月も回して見えてきたトレードオフを踏まえ、5つのアプローチを正直に比較します。
選択肢
1. 生のtmuxスクリプト
それは何か: tmuxのペインでエージェントを起動するシェルスクリプト。DIYのオーケストレーションです。
メリット:
- tmux以外の依存関係ゼロ
- 細部まで完全な制御ができる
- 戦うべき抽象化がない
- 仕組みをすでに理解している
デメリット:
- 状態管理がない——すべて手作業で追跡する
- エージェント間のメッセージルーティングがない
- テストゲートがない——検証なしで「done」を宣言する
- エージェントがクラッシュしたりコンテキスト制限に当たると壊れる
- あなたがオーケストレーターになってしまう
向いているケース: 午後の間に2〜3体のエージェントが必要な単発タスク。協調が50行程度のスクリプトに収まるなら、スクリプトを使えば十分です。
向いていないケース: 繰り返しのあるワークフロー、徹夜セッション、あるいは「作業を離れて戻ったら、PRがマージされていることが重要」な状況。
2. CrewAI
それは何か: 役割ベースの協調を持つマルチエージェントシステムを構築するためのPythonフレームワーク。
メリット:
- 豊富なエージェント定義（役割、目標、バックストーリー、ツール）
- 内蔵のタスク委譲と、逐次/並列実行
- ツールと連携の大規模なエコシステム
- アクティブなコミュニティと良いドキュメント
- 複数のLLMプロバイダーをサポート
デメリット:
- フレームワークであってツールではない——エージェントを設定するためにPythonを書く必要がある
- エージェントはCrewAIのエージェントであり、既存のCLIツールではない（Claude Code、Codex）
- 端末での可視性がない——Pythonプロセスとして動作する
- フレームワークの概念を学ぶ学習曲線がある
- 冗長なエージェント同士のやり取りだとトークンコストが高くなり得る
向いているケース: Pythonでカスタムのマルチエージェントアプリを作ること。プログラム的な制御を望む研究、分析、コンテンツ生成ワークフロー。
向いていないケース: 既存のCLIコーディングエージェントをオーケストレートすること。すでにClaude CodeやCodexを使っていて、それを複数並列に動かしたいなら、CrewAIはPythonでエージェント構成を作り直すことになります。
3. AutoGen
それは何か: Microsoftによるマルチエージェントの会話と協調のためのフレームワーク。 注（2026年4月）: MicrosoftはAutoGenがメンテナンスフェーズに入ることを発表しており、新しいMicrosoft Agent Frameworkに置き換えられます。AutoGenは引き続きバグ修正やセキュリティ更新を受けますが、新機能は追加されません。新しく始めるなら検討する価値があります。
メリット:
- エージェント間の会話パターンが高度
- 強い研究的裏付け（Microsoft Research）
- グループチャット、ネストした会話、教えられるエージェント
- 複雑な推論の連鎖に向く
- ヒューマン・イン・ザ・ループ（人が介入する）サポート
- 大規模なコミュニティ（GitHubスター56K+）
デメリット:
- メンテナンスモードに入っている——MicrosoftはAgent Frameworkへの移行を推奨
- 重いフレームワーク——単純なユースケースには準備が大きい
- Pythonと.NETのみ
- 会話型エージェント向けに設計されており、コーディングワークフローではない
- git統合がなく、worktreeの分離もない
- 「コーディングエージェントを3体並列に動かす」にはやり過ぎ
向いているケース: 既にAutoGenで作られた既存プロジェクト。研究環境における複雑なマルチステップ推論と、エージェント同士の会話。
向いていないケース: 新規プロジェクト（代わりにMicrosoft Agent Frameworkを検討）。並列コード実行——AutoGenはエージェント同士の会話で力を発揮し、gitブランチやテストスイートの管理には向いていません。
4. vibe-kanban
それは何か: AIエージェントのタスク管理のためのWebベースのkanbanボード。Rustで作られており、TypeScriptのフロントエンドがあります。
メリット:
- 視覚的インターフェース——全エージェントとタスクを一目で把握できる
- ドラッグ＆ドロップによるタスク管理と、リアルタイムのエージェントログストリーミング
- エージェントごとのGit worktree分離——Battyと同様の分離コンセプト、ただし別のインターフェース
- マージ前にエージェントの出力を確認するための、組み込みのdiffレビューUI
- MCP連携（クライアント/サーバ両方）——エージェントがボードをプログラム的に管理できる
- Claude Code、Codex、Gemini CLI、その他のコーディングエージェントと連携可能
- 大規模なコミュニティ（GitHubスター24K+）
デメリット:
- Web UIのため端末から離れる必要がある
- テストゲートがない——diff UIを通じたレビューが手作業
- 動作中のWebサーバが必要
- 端末ネイティブのワークフローとは異なるメンタルモデル
向いているケース: 視覚的インターフェースを好むチーム。ブラウザ上でdiffを見て、エージェントの作業をレビューしたい開発者。ドラッグ＆ドロップによるタスク管理や視覚的な監督が「機能」であり、「手間（オーバーヘッド）」ではないようなワークフロー。
向いていないケース: tmuxで作業するのが当たり前の開発者で、すべてを端末で完結したい場合。ブラウザにAlt-Tabするのがコンテキストスイッチングに感じられるなら、vibe-kanbanはあなたのワークフローに不要な摩擦を追加します。
5. Batty
それは何か: tmuxでAIコーディングエージェントを監督（supervise）する、ターミナルネイティブなRust CLI。
メリット:
- 各エージェントが実際のtmuxペインで動作——キーバインド、SSHでのアタッチ、pipe-paneなどがすべてそのまま使える
- エージェントごとのGit worktree分離——ファイル競合がない
- テストゲート——テストが通るまでマージされない
- タスク配布のためのMarkdown kanban——
catでボードを見て、git diffで状態を確認する - すべてファイルベース——YAML設定、Maildirインボックス、JSONLログ
- 単一バイナリ（
cargo install batty-cli）で、ランタイム依存がない - 既存のCLIエージェントと連携可能（Claude Code、Codex、Aider）
デメリット:
- tmuxが強い依存関係——WSLなしではWindowsでは動かない
- Web UIがない——視覚的なダッシュボードが欲しいなら他を探すべき
- 初期段階（v0.1.0）——APIはまだ落ち着いていない
- Rustコントリビュータの壁——Pythonツールよりカジュアルな貢献が難しい
- フレームワーク型の代替案よりコミュニティが小さい
向いているケース: すでにtmuxで作業していて、端末を離れずに1体から多数のエージェントへスケールしたい開発者。テストゲートやコード品質ゲートを重視するチーム。
向いていないケース: 非端末ユーザー。Windows中心の開発者。最初から自作でエージェントシステムを組み立てたい人（その場合はCrewAI/AutoGenを使う）。
意思決定マトリクス
| 必要 | 最適な選択 |
|---|---|
| すぐに終わる単発の並列タスク | 生のtmuxスクリプト |
| カスタムのマルチエージェントPythonアプリ | CrewAI |
| 複雑なエージェントの推論/討論 | AutoGen（またはMicrosoft Agent Framework） |
| diffレビュー付きの視覚的タスク管理 | vibe-kanban |
| テストゲート付きのターミナルネイティブ | Batty |
| Windowsのみの環境 | CrewAIまたはvibe-kanban |
| 既存のCLIエージェントをオーケストレート | Batty、vibe-kanban、またはtmuxスクリプト |
重要な問い
ツールを選ぶ前に、次のことを自問してください：私はエージェントシステムを作っているのか、それとも既存のエージェントを調整（コーディネート）しているのか？
ゼロから構築している場合――エージェントのふるまい、ツールへのアクセス、会話のパターンを定義する場合――には、フレームワークが必要です。CrewAIとAutoGenなら、構成要素が手に入ります。
すでにClaude Code、Codex、またはAiderを使っていて、それらを複数並行で動かしたいなら――監督役（スーパーバイザー）が必要です。Batty、vibe-kanban、tmuxのスクリプトはこの層で動作し、それぞれに異なるトレードオフがあります。vibe-kanbanは差分レビュー付きのビジュアルボードを提供し、Battyはテストによるゲーティング付きのターミナルネイティブな監督を提供し、tmuxスクリプトは抽象化なしで完全な制御ができます。
私の率直な見解
私はBattyを作ったので、偏りがあります。それでも作ったのは、他の選択肢が私のワークフローに合わなかったからです：
- CrewAIとAutoGenはフレームワークです――Claude Codeがすでにうまく動くのに、エージェントのセットアップをPythonで書き直したくありませんでした
- vibe-kanbanはWebベースです――私はtmuxに留まりたかった
- 生のスクリプトは、エージェントがクラッシュしたときに壊れましたし、離席する必要がある場面でも対応が難しかった
Battyが埋めるのは特定のニッチです。つまり、CLIベースのコーディング用エージェントをすでに使っている人向けに、テストによるゲーティング付きのターミナルネイティブな監督です。もしそれがあなたの状況なら、試してみてください。そうでないなら、他のツールはそれぞれが得意なことについては本当に優れています。
Battyを試す： cargo install batty-cli — GitHub | デモ
代替案を試す：
- CrewAI — Pythonのマルチエージェント・フレームワーク
- AutoGen — Microsoftのエージェント会話フレームワーク（メンテナンスフェーズに入っています）
- vibe-kanban — ビジュアルAIエージェント・カンバン
