Claude Squad vs Conductor vs tmux：DIYエージェント環境の比較

遅すぎるからという理由で、コーディングエージェントを2つ同時に走らせ始めた。今では5つ動かしている。難しいのは起動ではない。どのターミナルでどのエージェントが動いているか、それぞれが何を変えたか、どのブランチなら安全にマージできるか、40分前に黙り込んだあいつが終わったのか固まったのか——それを覚えておくことだ。並列化は簡単な勝ちだった。それを追い続けることが、その日以降ずっと払い続ける税なのだ。

その税を軽くしようとするのが、DIYの並列エージェントツールだ。Conductor、Claude Squad、そして手書きのtmux＋git worktreeスクリプトは、いずれも最初の同じ問題を解いている。つまり、各エージェントに専用の隔離されたワークスペースを与え、複数の実行がお互いのファイルを踏みつけ合わずに同時に進めるようにする、ということだ。これはうまく解かれているし、1台のマシンで作業するソロ開発者なら、それだけで十分なこともある。本記事は、それぞれが何をして、どこで止まり、ウィンドウ管理が静かにチームの問題へと変わる境界線がどこにあるのかを、正直にまとめたものだ。

その境界線の先にあるのがSharklyであり、本記事で順を追って紹介するワークフローでもある。SharklyはClaude CodeやCodex、あるいはDIYランナーの代替ではない。すでに使っているツールの周りに、共有されたTask、Computer、コンテキスト、レビューの層をかぶせるものだ。そうすることで、エージェントの仕事がプライベートなターミナルに消えていくのではなく、リクエストからリリースまで見える状態で保たれる。まだ1画面に収まる構成なら、そのまま続ければいい。何週間も前に収まらなくなっているなら、本記事の後半が役に立つはずだ。

TL;DR

Conductor、Claude Squad、そして生のtmux＋git worktreeは、自分のマシン上で複数のAIコーディングエージェントを並列実行する3つの方法だ。Conductorはソロのローカル実行向けに作られた無料のMacアプリ。Claude Squadはtmuxセッションとgit worktreeの上にスイッチャーを重ねたクロスプラットフォームのターミナルアプリ。生のtmux＋worktreeスクリプトは、完全な制御とゼロの抽象化を手に入れる。3つとも並列実行を極めている。しかし、いずれもチームに共有の可視性やレビュー、引き継ぎを与えるために作られたものではない。そして、まさにその地点で、Sharklyのようなオーケストレーション層へと進むことになる。

本当のボトルネックは並列化ではない

隔離はすでに解決済みの問題だ。git worktreeを使えば、1つのリポジトリが複数のブランチを同時に別々のディレクトリへチェックアウトできるので、各エージェントは自分専用のコードのコピーを編集し、自分のブランチへコミットする。共有の作業ツリーはなく、中途半端に適用された差分が衝突することもない。この比較に登場するツールはすべて、同じこのプリミティブの上に成り立っている。仕組みを詳しく知りたいなら、AIコーディングエージェントとgit worktreeのガイドでコマンドと落とし穴を解説している。

では、隔離がタダで手に入るのなら、なぜ多くのエージェントを動かすのは依然として混沌と感じられるのか。それは、エージェントが生み出した仕事を、人間が見つけて読み、判断し、行動できる場所へ届けなければならないからだ。1台のマシンでは、その「場所」は自分の短期記憶とスクロールバックのバッファにすぎない。エージェントが2つならそれでももつ。5つになるとほつれ始める。2人目の人間が、あなたのエージェントが何をしたのかを知る必要が出た瞬間に、それは壊れる。

ここで重要なのはこの分かれ目だ。エージェントを並列で走らせるのはランタイムの問題である。プロセスを起動し、隔離されたディレクトリを渡し、働かせる。それに対して、彼らが生み出したものをレビューし調整するのはワークフローの問題である。結果はどこに存在するのか、誰が承認するのか、止まってしまったものはどうなるのか。DIYツールは最初の問題において卓越している。以下の3つのセクションでは、それぞれをその立場で評価し、その後で、構成が大きくなるにつれて2つ目の問題がどうなるかを見ていく。

Conductor：ソロの並列実行のための無料Macアプリ

Conductorは、複数のClaude Codeエージェントを並べて動かすためのネイティブMacデスクトップアプリだ。リポジトリを指定して変更内容を伝えると、git worktreeを裏に持つ各実行専用のワークスペースを立ち上げてくれる。ターミナルのタブをやりくりする代わりに、ウィンドウ表示が手に入る。エージェントごとの列があり、それぞれに会話、差分、ステータスがある。チャットを切り替える感覚で、それらをクリックして渡り歩ける。

うまくやっているのは、1人のためのターミナル管理をなくすことだ。tmuxのコマンドを打つ必要はない。どのペインがどれかを覚える必要もない。アプリがworktreeを追跡し、本物の差分ビューアで差分を見せ、位置を見失わずにエージェント間を移動させてくれる。Macで1つのコードベースに対して3つか4つのClaude Codeセッションを回し、正気を保ちたいソロ開発者にとって、これはクリーンで摩擦の少ない答えだ。ダウンロードは無料で、サーバーがないのでサーバー側で設定することも何もない。

境界は、そうした強みの裏返しだ。ConductorはmacOS専用なので、Linuxのチームメイトはあなたの構成を共有できない。ランタイムとしてClaude Codeを中心に作られており、複数のエージェントを混ぜることは想定されていない。そして単一ユーザー向けのデスクトップアプリだ。ワークスペースも差分も判断も、あなたのMac上に存在する。他のエンジニアがあなたのConductorを開いて、あなたのエージェントが何をしているか見ることはできないし、誰がどの変更を承認したかの共有記録もない。それは欠陥ではない。スコープなのだ。Conductorは1人のパイロットのためのコックピットだ。

Conductorを使うべきときは、MacでClaude Codeを動かすソロ開発者で、「たくさんのターミナル」から「1つの落ち着いたウィンドウ」へ最速で移りたいとき。別のものに手を伸ばすべきときは、2人目の人間がそれらの実行を見たり、レビューしたり、引き継いだりする必要が出たときだ。

Claude Squad：tmuxとworktreeにTUIをかぶせたもの

Claude Squadは、複数のエージェントを隔離されたワークスペースで管理するオープンソースのターミナルアプリだ。内部では、慎重なエンジニアが手でスクリプトを書くであろうことをやっている。エージェントごとにgit worktreeを作成し、各エージェントを専用のtmuxセッション内で実行し、その上にテキストUIをかぶせて、エージェントを一覧表示し、どれかに切り替え、どれが作業中で待機中で完了なのかを見られるようにする。クロスプラットフォームでmacOSとLinuxで動作し、単一のランタイムに縛られない。Claude Code、Codex、Aider、その他のCLIエージェントを動かせるので、ツールを混ぜて使う開発者に愛用されている。ソースはGitHubのClaude Squadリポジトリにある。

魅力は、信頼しているプリミティブを隠すことなく、本物のツールの使い勝手を与えてくれる点だ。worktreeとtmuxはそのままなので、魔法はなくすべて検査可能だが、接着剤を手書きする必要はなくなる。新しいエージェントの立ち上げはキーストローク1つで、3コマンドの儀式ではない。エージェントを一時停止すればリソースが解放され、ブランチは保持される。すでにターミナルで暮らしていて、タブで渡り歩けるエージェント群が欲しいなら、Claude Squadは生のスクリプトとデスクトップアプリのどちらも逃すスイートスポットを突いている。複数のClaude Codeエージェントを並列で実行する方法のウォークスルーでは、これが自動化しているのと同じtmuxとworktreeのパターンを示している。

その限界は、それが暮らすターミナルの限界だ。状態はあなたのマシンとシェルにローカルだ。セッションを閉じれば、共有された全体像も一緒に閉じる。マネージャーが開けるタイムラインはなく、あなた以外のレビュアーが変更を承認・却下できる場所もなく、チームメイトが次のタスクを引き出せるキューもない。Claude Squadは優れた単一オペレーターのコマンドセンターだ。チームの記録システムになろうとしていたわけではなく、それにしようと求めるのは間違ったツールに頼むことだ。

Claude Squadを使うべきときは、ターミナル第一の開発者で、1台のマシンで複数のエージェントを混ぜて動かし、worktreeとtmuxを手放さずに高速なスイッチャーが欲しいとき。別のものに手を伸ばすべきときは、実行を他の人に割り当てたり、あなたのキーボードの前にいない誰かがレビューしたりする必要が出たときだ。

生のtmux＋git worktree：自分が所有するスクリプト

最も正直なDIY構成は、最も古くもある。worktreeを作成し、エージェントごとにtmuxウィンドウを開く、いくつかのシェルスクリプトだ。こんな感じになる。

# one worktree and one branch per parallel unit of work
git worktree add ../app-auth    -b feature/auth
git worktree add ../app-billing -b feature/billing

# a named tmux window per agent, launched in its worktree
tmux new-window -n auth    -c ../app-auth    'claude'
tmux new-window -n billing -c ../app-billing 'claude'

機能ごとに2コマンドで、隔離されたエージェントが並列で動く。それぞれ自分のブランチにいて、キーストロークで切り替えられるラベル付きのウィンドウの中にいる。これをループで包めば、十数個だって起動できる。あなたとツールの間には何も挟まらない。すべての行を読み、どこでも変えられるし、かかるコストは書く時間だけだ。

ある種の開発者にとって、これは永遠に正しい答えであり、誰かを説得してやめさせるよりも尊重する価値がある。自分で書いたのだから、何が動くか正確に理解している。ベンダーもなければ、フローを壊すアップデートもなく、間違ったタイミングで漏れ出す抽象化もない。ニーズが安定していて個人的なものなら、借りるツールより自分が所有するスクリプトのほうが勝る。

コストは構成が大きくなるにつれて現れ、それは機能ではなくメンテナンスとして現れる。クリーンアップは自分の責任だ。古いworktreeは、git worktree pruneとtmux kill-sessionの掃除が日課になるまで溜まっていく。名前の衝突も自分の責任だ。クラッシュしたエージェントは死んだウィンドウと中途半端なブランチを残し、それに気づくのも自分の責任だ。そして何もマシンの外には出ないので、チームメイトが「今週あなたのエージェントは何を出荷したの？」と聞いた瞬間、答えはあなたのスクロールバックの中にしかない。スクリプトはスループットを拡張する。だが結果を共有する能力は拡張しない。

生のtmuxとworktreeスクリプトを使うべきときは、完全な制御が欲しく、自分のツールを所有することを楽しみ、仕事の受け手が自分自身であるとき。別のものに手を伸ばすべきときは、ステータス追跡やクリーンアップ、引き継ぎのロジックを再構築している自分に気づき、それが書くつもりのなかった製品のように見え始めたときだ。

並べて比較：各DIY構成が得意なこと

最後の2行は批判ではない。これがパターンなのだ。これらのツールはどれも、1台のマシン上の1人のオペレーターのために作られており、その範囲内では良いものから優れたものまで幅がある。空っぽの列は3つとも同じで、その列こそが、仕事があなただけのものではなくなる日に重要になる列だ。このカテゴリのより広い地図については、AIエージェントオーケストレーションの概要を参照してほしい。

卒業の境界線：ウィンドウ管理が問題でなくなる瞬間

兆候はこれだ。「どうすればもっと多くのエージェントを同時に動かせるか」と問うのをやめ、DIYツールには答えられない問いを立て始める。

• 自分のエージェントの変更のうち、誰かがレビューしたのはどれか？
• 自分が病気で休んだら、チームメイトは進行中のものを確認して引き継げるか？
• この差分を承認し、あの差分を却下した理由の記録はどこにあるか？
• どの実行がブロックされていて、何によって、どれくらいの間ブロックされているか？

これらはワークフローの問いであり、ランタイムの問いではない。どんなに優れたスイッチャーや、どんなにきれいな差分ビューアでも答えられない。足りないピースはあなたの画面の上にはないからだ。それは、仕事が住む共有の場所だ。これが卒業の境界線である。ボトルネックがウィンドウの管理から、可視性・レビュー・引き継ぎの管理へと移る日だ。

Sharklyはその境界線の向こう側のために作られている。コンテキスト、進捗、ブロッカー、結果、人間によるレビューを、プライベートなターミナルに散らばらせるのではなく、1つの共有ワークフローの中で、リクエストからリリースまで見える状態に保つ。役割分担は意図的だ。Claude Code、Codex、および類似のツールが実行を担い、Sharklyがそれらのツールをまたいで、チームレベルの割り当て、接続されたComputer、タスクのコンテキスト、進捗、ブロッカー、結果、人間によるレビューを管理する。信頼しているランタイムとworktreeはそのまま。そこに、複数の人間が仕事を見て方向づけられる層を加えるのだ。

その安心感は、仕組みと同じくらい重要だ。Sharklyの導入は、プロセスの再構築やツールの放棄を求めるものではない。サブスクリプションは自分で持ち込む。モデルの利用は、チームがすでに動かしているツールで設定されたサブスクリプションやAPIキーを通じて続く。Computerを接続し、Sharklyを同じリポジトリに向け、何も解体せずに仕事のルーティングを始めればいい。これをローカルボードと比べているなら、Vibe Kanbanの代替に関する記事で、同じ「持っているものをそのまま使う」道筋を扱っている。

同じ並列ワークフローがSharklyではどう見えるか

DIYツールは各エージェントにworktreeとウィンドウを与える。Sharklyは仕事の単位ごとにTaskを与え、Agentが同じように隔離されたworktreeでそれを実行できるようにする。違いは1つだけ。結果がスクロールバックに残るのではなく、Taskへ戻ってくるのだ。

TaskはSharklyにおける仕事の主要な単位だ。目標、スコープ、差分、ディスカッション、レビューを1つの共有レコードにまとめて運ぶ。TaskをAgentに割り当てると、Agentがそれを引き受け、専用の隔離されたworktreeで作業し、型チェックとテストとビルドを実行し、変更の要約、検証結果、既知の制限をそのTaskに添付して返す。次に見る人はあなたのターミナルを必要としない。Taskを開けばいい。

最小の役に立つバージョンは、あえて退屈にしてある。Computerを1台接続し、Agentを1つ作り、リスクの低いTaskを1つ割り当てる。最初のタスクのウォークスルーでも同じように設定している。そこから並列の話は、あなたのスクリプトが望んでいたようにスケールする。複数のAgentが準備完了のTaskを引き受けて同時に働き、それぞれが隔離され、その間フロントエンド、バックエンド、バグ修正、テストカバレッジが並行して進む。tmuxウィンドウの壁との違いは、すべての実行が人に割り当て可能で、あなた以外の誰かがレビューでき、後から追跡できることだ。

人間とエージェントの契約こそ、レビュー層がその存在価値を発揮する場だ。Agentは調査し、実行し、テストし、報告する。人間は方向性を定め、権限を与え、結果を承認する。自動化はチームの判断が必要なところで止まり、完全なコンテキストと検査可能な証拠を伴うデリバリーを返す。DIY構成はエージェントを走らせることはできる。だがその契約を保つことはできない。あなた以外の人間が承認・却下するための共有の場所がないからだ。そのゲートの仕組みを知りたいなら、Cursorのバックグラウンドエージェントに関する記事で、似たレビューフローを紹介している。

チームが使う形での実例を挙げる。SH-312のようなタスクが「公開APIにレート制限を追加する」と言っているとする。Agentがスコープを形作り、自分のworktreeで作業し、テストを実行し、要約と差分をそのTaskへ返す。レビュアーはSH-312を開き、証拠を読み、承認するか変更を依頼する。ソロだったときは、このループ全体があなたの頭と1つのターミナルの中にあった。今はそれがチームが見られる場所に住んでいる。これが卒業するということの本質だ。

留まるべき人、卒業した人

上へ上へと勧めるだけの比較は正直ではないので、率直なバージョンを書く。移るべきでない人もたくさんいて、上のツールは彼らにとって正しい住処だ。

• Conductorに留まるのは、ソロのMac開発者で、並列のClaude Code実行を落ち着いたウィンドウで行いたく、誰もそれを覗く必要がない場合。その仕事をクリーンにこなし、サーバーには何も求めない。
• Claude Squadに留まるのは、ターミナルで暮らし、複数のランタイムを混ぜて動かし、自分の仕事のためにworktreeとtmuxの上に高速なスイッチャーが欲しい場合。強力な単一オペレーターのコマンドセンターだ。
• 生のtmuxとworktreeスクリプトに留まるのは、完全な制御を重んじ、ワークフローが安定していて、成果物の受け手が自分だけの場合。ニーズが個人的なものであれば、所有するツールは借りるツールに勝る。
• Sharklyへ卒業するのは、仕事があなただけのものではなくなったとき。チームメイトが実行をレビューする必要が出たとき、あなたが不在の間に誰かが引き継がなければならないとき、マネージャーが何がブロックされているかを見る必要があるとき、あるいはステータスと引き継ぎのロジックを手作業で再構築している自分に気づいたとき。オーケストレーションの概要が、各層がどこで交わるかを示している。

このカテゴリ全体の判断基準は短い。制約が自分のマシンと自分の時間なら、DIYツールを使えばいい。制約がチームの、エージェントが何をしたかについての共有理解なら、オーケストレーション層を使えばいい。ほとんどの開発者は左から始め、仕事に2人目の名前が現れた週に越えていく。

実際のシナリオ

そのまま留まるソロビルダー。フリーランスの開発者がMac上で3つか4つのClaude Codeエージェントを使ってクライアントの機能を出荷している。ConductorかClaude Squadで答えは完結しており、チーム層を加えるのは見返りのない重りでしかない。留まることが正しい判断だ。

ちょうど境界線を越えた2人チーム。創業者と最初のエンジニアが、それぞれ自分のtmuxスクリプトを走らせていた。どちらも相手のエージェントの仕事を画面共有なしではレビューできなかった。実行をSharklyの共有Taskに移すことで、互いの差分を開き、承認し、マージできるようになった。どちらもすでに使っていたランタイムは変えずに。

チームを標準化するリード。エンジニア5人を抱えるテックリードは、全員が少しずつ違うworktreeスクリプトを持ち、共有レビューがないことに気づいた。共有Agentと共通のTaskフローによって、5つのプライベートな構成がチームで再利用できる1つのワークフローになった。各エンジニアは自分のComputerと自分のモデルサブスクリプションを持ち続けたまま。

FAQ

Claude SquadとConductorの違いは何ですか？Claude Squadはtmuxとgit worktreeの上でエージェントを管理し、複数のランタイムをサポートするクロスプラットフォームのターミナルアプリです。ConductorはClaude Codeをウィンドウ表示のインターフェースで実行することに焦点を当てたmacOSデスクトップアプリです。どちらも各実行を専用のworktreeに隔離しますが、違いはターミナルかネイティブアプリか、そしてクロスプラットフォームかMac専用かです。

すでにgit worktreeを使っていれば、Claude SquadやConductorは必要ですか？必ずしも必要ではありません。どちらも同じworktreeプリミティブの上に載せた利便性です。tmuxとgit worktreeのコマンドをいくつか書くことに抵抗がなければ、生のスクリプトで同じ隔離をより多くの制御とともに得られます。ツールが買ってくれるのは使い勝手とクリーンアップであり、新しい能力ではありません。

これらのDIYツールはチームのレビューに対応できますか？いいえ、そして対応すると主張してもいません。Conductor、Claude Squad、tmuxスクリプトはいずれも、1人のオペレーターのために1台のマシン上に状態を保ちます。共有レビュー、他者による承認、決定の永続的な記録は、ローカルランナーではなくオーケストレーション層に属するワークフロー機能です。その区別についてはVibe Kanbanの代替の記事を参照してください。

SharklyはClaude CodeやClaude Squadの代替ですか？いいえ。SharklyはClaude Code、Codex、その他の実行ツールの代替ではありません。チームがすでに使っているツールの周りに、共有されたTask、Computer、コンテキスト、制御、レビューの層を加えるものです。ランタイムとworktreeはそのままに、その上にチームレベルの可視性を得られます。

Sharklyへ移行するとgit worktreeを失うことになりますか？いいえ。SharklyもAgentを隔離されたworktreeで実行するので、頼っている隔離はそのまま残ります。変わるのは結果の行き先です。プライベートなターミナルバッファではなく、共有されたTaskへ戻ります。

切り替えたとき、モデルの利用とコストはどう保てますか？サブスクリプションは自分で持ち込みます。モデルの利用は、チームが接続するツールで設定されたサブスクリプションやAPIキーを通じて続き、モデルのクォータはそれらのツール、プラン、APIアカウントに依存します。Sharklyが加えるのは調整の層であり、新しい請求関係ではありません。

境界線を越える準備はできましたか？Sharklyをダウンロードし、Computerを接続して、1つの実際の要件を1つのAgentに割り当ててみてください。信頼しているランタイムとworktreeはそのままに、仕事がチーム全体に見える場所へ戻り始めるようにしましょう。各概念の詳細はdocs.sharkly.aiのドキュメントで扱っています。