この記事の対象読者と得られること
| 対象読者 | この記事で得られること |
|---|---|
| 複数 AI を並列で動かしたいエンジニア | worktree による衝突の根本解決 |
| workmux を試したい方 | セットアップと実運用の具体例 |
| 認知負荷に悩むシニア開発者 | 並列数と生産性の現実的な落とし所 |
はじめに
AI コーディングエージェントを 2 つ同時に動かし、同じブランチで型エラーが 40 件積み上がった経験はありますか。筆者は最初に試した日、昼休みから戻ったら tsc --noEmit が通らず、どちらが壊したかの特定だけで 30 分を使いました。この問題はエージェント側を賢くしても解けません。本質は「同じ作業ツリー」を複数が触る点にあるからです。本記事では Raine Virta 氏の workmux を軸に、git worktree と tmux で複数 AI を物理的に隔離する方法と、同じ Issue を 3 AI に並走させた実測を共有します。
本記事中の所要時間・勝率・コストは筆者の小規模プロジェクトでの擬似的な観測値を含みます。読者の環境で同じ傾向になるとは限りませんので、参考程度にお読みください。
背景: なぜ worktree × tmux が並列 AI 開発に刺さるのか
git worktree の原理とエージェント並列の相性
git worktree を最初に触ったとき、筆者は「ただの別ディレクトリ」だと思って軽く見ていました。実際には Git 内部の設計が練られていて、AI エージェント並走の土台としては他の選択肢より向いている、と感じる場面が増えています。
仕組みを軽くなぞると、worktree は .git/ を 1 つだけ共有しつつ、作業ツリーを複数持つ構造です。メインの worktree には .git/ ディレクトリがあり、追加した worktree には .git という「テキストファイル」が置かれ、メインの .git/worktrees/<name>/ への gitdir リンクが書かれています。オブジェクトデータベース・パックファイル・config・refs が 1 箇所に集約されているので、同じコミットを 2 重に持つ無駄は発生しません。
一方で、各 worktree は独立した HEAD と index、独立した作業ファイル群を持ちます。ブランチを 3 本同時にチェックアウトできるのはこのおかげで、node_modules や dist/ のような生成物まで完全に分離されます。代替案としてよく挙がる「リポジトリの複数 clone」「rsync」「symlink で node_modules を共有」は、筆者の経験では実運用で破綻しやすい印象でした。複数 clone は通信・ストレージが重く、rsync は履歴がずれると事故り、symlink 共有は pnpm/yarn 内部の .modules.yaml 等で競合します。
加えて ブランチ参照が 1 箇所で管理される のもエージェント並列に効きます。git fetch ../agent-codex のように別 worktree を remote 的に扱えるので、後述する git range-diff が自然に動きます。別 clone だと git remote add を双方向に張る必要があり、手数が増えます。
tmux 側は「セッション > ウィンドウ > ペイン」の 3 階層で空間を区切る仕組みです。エージェント並走で便利なのは、各ウィンドウが独立した PTY を持ち、出力バッファも独立している点で、ANSI エスケープの取り合いによる表示崩れがほぼ起きません。attach/detach できるので、SSH が切れても裏で実行が続くのも、長時間タスクでは安心材料になります。
workmux の設計思想はこの 2 つを素直に掛け算した形で、1 tmux ウィンドウ = 1 worktree = 1 エージェント CLI と割り切り、状態管理を Git と tmux に任せているのがポイントだと感じています。スクリプトが薄く、挙動が想定と違っても Bash のトレースで原因までたどり着きやすいのは、長く使う上で地味ながら大きな利点かもしれません。
並列 AI 開発の変遷 2023〜2026
なぜ今この話が盛り上がっているのか、筆者なりの時系列整理です。体感ベースなので厳密な年表ではない点は先に断っておきます。
- 2023: Copilot と ChatGPT を「賢い補完」「相談相手」として使うペアプログラミング期。コードを書くのは人間で、並列化の必要自体がありませんでした
- 2024: Cursor、Cline、Aider などの単一エージェント型 IDE・CLI が広がり、人間はレビューに回る場面が増加。それでもまだ「1 人 : 1 エージェント」の関係が主でした
- 2025 Q4: Claude Code の Agent Teams 的発想が公に。Codex も Rust で書き直されて起動コストが下がり、CLI として複数立ち上げる敷居が心理的に下がります。ただし同ブランチでの衝突事故は各所で観測されていました
-
2025 Q4 末（2025/12/25）: Raine Virta 氏が
workmuxを公開。ブログ "Introduction to workmux" が最小構成を具体的に示し、普及のきっかけになりました - 2026 Q1: Addy Osmani 氏の "Code Agent Orchestra" が公開され、並列運用の経済性とレビュー負荷の議論が整理されます
-
2026/3: Hacker News で "agentastic.dev" が盛り上がり、
vibe-kanbanやconductorも相次いで登場。「CLI 派 vs GUI 派」「Docker 派 vs ネイティブ派」の分岐が生まれつつあるのが現在地だと感じています
こうして並べてみると、workmux は「最小で地味、しかし壊れにくい」ポジションに落ち着いています。派手な UI はありませんが、tmux と git が動けば動く頑丈さが、長く付き合えるツールとしての安心感につながっているのかもしれません。
1. 複数 AI エージェントが同一リポジトリで衝突する理由と、git worktree による分離
AI エージェントが破壊するのは典型的に、共通の node_modules とロックファイル、生成物キャッシュ（.next/, dist/ 等）、Git インデックスの 3 箇所です。Codex が pnpm add zod@3.23、Claude が別セッションで pnpm add zod@4 を走らせれば、ロックは後勝ちで上書きされ、前者の生成コードは型が合わなくなります。プロンプトで排他制御するのは現実的ではありません。
ここで効くのが git worktree です。Git 2.5 から入っているこの機能は、同じリポジトリから複数の作業ディレクトリを同時にチェックアウトできます。
git worktree list
git worktree add ../repo-feature-a feature/a
git worktree remove ../repo-feature-a
物理ディレクトリが別なので node_modules も .next/ も分離され、.git/ は共有されるためストレージも節約できます。これを「AI エージェントの住処」として使うのが workmux のコアアイデアです。
2. workmux とは
workmux は Raine Virta 氏が公開している薄いラッパースクリプトで、tmux のウィンドウ 1 つ = git worktree 1 つ という対応関係を作ります。各ウィンドウには設定で指定したコマンド（典型的には AI CLI）が自動起動されます。
設定には <agent> のようなプレースホルダを置けて、ウィンドウごとに異なるエージェントを割り当てられます。やっていることは「worktree を作る」「tmux ウィンドウを開く」「指定コマンドを送る」の 3 つだけで、壊れにくく読みやすいのが魅力です。
3. セットアップ手順
macOS 14 / Ubuntu 22.04 を想定した 2026 年 4 月時点の手順です。tmux 3.4 以上を推奨します。併用する AI CLI は Claude Code（claude）、Codex CLI（codex）、Gemini CLI（gemini）の 3 つです。
brew install tmux # macOS
sudo apt install tmux # Ubuntu
workmux は YAML で振る舞いを記述します。3 AI を同じ Issue に並走させる設定例です。パスは匿名化しています。
# ~/.config/workmux/config.yaml
project: shop-service
base_dir: ~/dev/worktrees/shop-service
branches:
- { name: agent/claude, agent: claude }
- { name: agent/codex, agent: codex }
- { name: agent/gemini, agent: gemini }
window_cmd: "<agent> --task 'Issue #482 を実装'"
<agent> は起動時に各 CLI 名へ置換されます。workmux up を叩くと tmux セッションが立ち上がり、ウィンドウ 3 つが作られます。tmux a -t shop-service で入れば、Ctrl-b n で次のウィンドウへ切り替えられます。
CLI をネットから curl | sh で入れる際は、必ずスクリプトの中身を確認してから実行してください。AI 時代でもサプライチェーン面の注意は変わりません。
4. 3 AI 同一タスクの並走
お題は Next.js 15 系の EC サイトに対する Issue #482「カート画面の小計にクーポン適用後価格を追加する」です。UI・状態管理・型・テストに軽く触る、比較しやすい大きさのタスクを選びました。
5.1 Issue を 3 worktree に配布
for w in 1 2 3; do
tmux send-keys -t shop-service:$w \
"Issue #482 を担当してください。要件は docs/issue-482.md を参照。" Enter
done
3 AI は独立にコードを書きます。筆者の観測では最初の実装コミットまでの時間は以下のようなレンジでした。
| AI | 最初のコミットまで | 備考 |
|---|---|---|
| Claude Code | 約 6 分 | テストから書き始めた |
| Codex CLI | 約 4 分 | 型定義の更新が早い |
| Gemini CLI | 約 5 分 | UI 側を先行して変更 |
あくまで一例で、タスク性質で順序は入れ替わります。重要なのは「3 本のコミット履歴がそれぞれ独立して進む」ことで、どれを捨てても他に影響しない点です。
5.2 git range-diff で 3 案を比較
worktree が同じリポジトリなので、git range-diff もそのまま使えます。
cd ~/dev/worktrees/shop-service/agent-claude
git fetch ../agent-codex agent/codex:refs/remotes/codex/work
git fetch ../agent-gemini agent/gemini:refs/remotes/gemini/work
git range-diff main...HEAD main...codex/work
git range-diff main...HEAD main...gemini/work
range-diff は「やろうとしていることが同じか」「差分の粒度が違うか」という観点で 2 本のコミット列を並べてくれます。ファイル単位の diff より 3 案の違いが見やすいと感じました。
5. best-of-N 選定
3 案が揃ったら採用を決めます。筆者は 2 段構えにしています。まずレビュアー役として、実装を担当していない別セッションの AI に以下のプロンプトで順位付けを依頼します。LLM の自動採点はぶれるため、参考指標として扱う前提です。
あなたはレビュアーです。以下 3 つの diff を読み、
採用順位と理由を述べてください。観点は可読性・
テスト充実度・型安全性・Issue 要件の充足です。
最終採用は人間が決めます。diff 量が 200 行以内なら 3 案を縦並びで読むのが早く、超えるときは「落ちたときに原因が分かるか」で 1 つ落とすことが多いです。
6. 実測: 3 AI の得意分野の傾向
2026 年 1 月以降に回した小さめのタスク 24 件の雑な集計です。擬似データを含む概算で、ベンチマークを名乗れるほど厳密ではない点に留保してください。
| タスク種別 | Claude | Codex | Gemini | 体感の強み |
|---|---|---|---|---|
| UI 実装（React/TSX） | 25% | 25% | 50% | Gemini はレイアウトの第一案が綺麗 |
| ロジック・型 | 25% | 55% | 20% | Codex は型推論を崩さない |
| テスト追加 | 55% | 30% | 15% | Claude は境界値の網羅が丁寧 |
| リファクタ | 35% | 40% | 25% | 設計提案は Claude と Codex が拮抗 |
「勝率」はレビュアー AI と人間の合議で「最初にマージした案」の割合です。他案が必ずしも劣っているわけではなく、2 位の案も十分使えるケースが多くありました。面白かったのは 同じ Issue でも制約条件を変えると勝者が入れ替わる ことで、「既存テストを全てパス」を強制すると Claude、「200 行以内で終える」を強制すると Codex という具合でした。得意不得意はモデルのクセというより、制約との相性で決まっている印象があります。
7. コスト 3 倍問題と、どこに効かせるか
単純な現実として、3 AI 並走は API コストが約 3 倍、タスクによっては 5 倍以上になります。全タスクを常に 3 並列にするのは、少なくとも筆者の規模では合いませんでした。
筆者が使い分けている基準です。
- 並走が効くタスク: 設計方針が割れる／最初の一歩で質が決まる／見た目の好みが割れる UI
- 並走が効かないタスク: 機械的な置換／既存の型に完全従属する追加／調査主体
コストはチームや契約で前提が違うので、最終的には各自の財布の感覚で決めるのが良いと思います。Addy Osmani 氏の記事は並列運用の経済性を論じていて参考になります。
8. 認知負荷と落とし穴
tmux の切り替えは一瞬なので、物理的には 4 〜 6 並列も作れます。問題は人間側で、筆者の体感では 同時にリアルタイム監視できるのは 2 〜 3 並列が上限 でした。4 本目を足すと「さっき Claude が何を言っていたか」の再確認に 1 分以上かかるようになりました（Hacker News での議論）。5 並列でも平気な方もいるので、自分の集中力の上限を知るほうがツール選定より重要かもしれません。
運用上踏みやすい落とし穴は以下です。
-
ロックファイルの衝突: 3 worktree で別々に
pnpm installすると内容がずれます。共通ブートストラップで揃えておくと安全です -
ブランチ名の衝突: 3 AI が同じ
feature/482に向かうとエラーになります。agent/claude/482のようなプレフィックスを入れると安全です - AI の勝手な push: 一番怖い落とし穴です。各 AI 側で push を許可しないポリシーにし、push は人間だけが行う運用が無難でした
AI が勝手に force push することは worktree を分けても防げません。権限と自動化ポリシーは Git サーバ側で二重化しておくことを強くおすすめします。
並列開発ツールの比較と選び方
workmux と競合・補完関係にあるツールを同じ土俵で整理します。どれが絶対的に優れているという話ではなく、前提条件が違うだけだと筆者は感じています。
並列開発ツール 4 種の比較
2026 年 4 月時点で触った範囲の情報です。workmux は 2025/12/25 公開版、vibe-kanban は 2026/3 時点の Docker イメージ、conductor は 2026 Q1 リリースの macOS 専用アプリを基準にしています。tmux 3.4 以上、git 2.5 以上が前提です。
| 軸 | workmux | vibe-kanban | conductor | 生 git worktree |
|---|---|---|---|---|
| セットアップ | tmux + npm | Docker | macOS アプリ | git のみ |
| 並列数上限 | tmux 制約 | UI 制約 | UI 制約 | 制限なし |
| 進捗可視化 | tmux pane | kanban UI | GUI | なし |
| AI 別起動 | コマンドで明示 | UI 選択 | UI 選択 | 手動 |
| 学習コスト | tmux 必須 | Docker 必須 | 低 | Git 力必要 |
項目を簡単に補足します。
-
セットアップ: workmux は
npm i -g workmuxと tmux の 2 ステップ。vibe-kanban は Docker Compose 前提、conductor は.dmgで済みます。生 worktree は追加ツール不要な代わりに、スクリプトを自作する必要があります - 並列数上限: 理屈上は数十動きますが、実運用では 3〜5 で頭打ちになる印象です。UI 系は一覧性で事実上の制約がかかります
- 進捗可視化: workmux は tmux ペインでログを直接見る形で、情報量は多めです。vibe-kanban と conductor は非エンジニアを巻き込みたい場面で楽です
- AI 別起動: workmux は YAML で CLI を明示。UI 系は切り替えが楽な反面、設定を Git 管理に乗せにくい面もあります
- 学習コスト: tmux や Docker に慣れている人には気にならない水準ですが、未経験者には心理的ハードルが残ります
どのツールを選ぶか
判断マトリクスを共有しておきます。軸の重みは人や組織で違うので、あくまで一例です。
- workmux: CLI 中心、2〜3 並列、tmux に慣れていて設定を Git に乗せたい
- vibe-kanban: チームで進捗共有、非 tmux ユーザー混在、Docker 環境が整っている、kanban で俯瞰したい
- conductor: GUI 好み、macOS 専用で問題ない、クリックで済ませたい
- 生 worktree: 1〜2 並列で十分、ツールを増やしたくない、Git と Bash で自作できる
1 つに絞る必要はありません。筆者は個人プロジェクトは workmux、チームは vibe-kanban、登壇や動画撮影は conductor、と状況で使い分けています。選定に時間を使いすぎるより、素直に合うものを 1 つ選び、半年粘って使い込むのが結果的に早いと感じています。
並列数と認知負荷の現実
筆者の観測では、生産性が素直に伸びるのは 3 AI までで、4 つ目を足した瞬間にレビューの順番待ちが詰まり、合計スループットが下がる傾向がありました。tmux の性能ではなく、人間のワーキングメモリがボトルネックになっている理解です。
技術的に踏みやすい落とし穴もあります。
-
ブランチ名の設計:
feature/482-claude/-codex/-geminiのようにエージェント名をサフィックスに入れると、事故時の切り分けが早くなります -
DB ポートの衝突: 3 worktree それぞれが
localhost:5432を取り合うので、.env.localでPOSTGRES_PORTを5432/5433/5434のようにズラす運用が安定しやすいです -
生成物の取り違え:
dist/や.next/は worktree ごとに独立しますが、手動比較時に迷うので CI で成果物にラベルを打つのをおすすめします
「10 並列で AI を走らせる」といった派手な事例もありますが、走らせるだけなら tmux は平気で動きます。問題はレビューで、人間が採否を決めるのは 3 本でも重労働でした。並列数を先に決めるより、1 日で責任を持ってレビューできる本数 を先に決めるほうが現実的だと考えています。
9. まとめ
-
git worktreeは 10 年以上前からある機能ですが、AI エージェント時代に再評価されています -
workmuxは tmux ウィンドウと worktree を紐づけるだけの薄いツールです - 3 AI 並走は、設計方針が割れるタスクで有効で、機械作業では割に合いにくい印象でした
- 勝率はモデルの優劣より制約条件との相性で決まる傾向があります
- 並列はゴールではなく手段です。人間が見切れる範囲に並列数を合わせるのが結局いちばん効率的でした
試すなら、まずは 2 並列から始めるのをおすすめします。2 案が出たときに「比べて選ぶ」行為自体に慣れてから 3 並列に広げると、コストに対して取り返しがつきやすいと感じています。