Claude Code を複数タブで開いて、それぞれ別タスクをぶん投げる。
そんな使い方、もうやってみましたよね。
あるいは Cursor のマルチエージェントで実装候補を並走させた人もいるかもしれません。
問題は「同時に走らせたら何が起きるか」です。
エージェントが自律的にファイルを書き換える以上、単純にタブを増やすだけでは壊れます。
なぜ git worktree が並列エージェントの土台として機能するのか、そして worktrunk がそのセットアップコストをどこまで下げてくれるのか。
コマンドの具体的な差分と構成例で掘り下げます。
複数エージェントを同一ツリーで走らせると何が起きるか
シナリオを一つ想像してみてください。
エージェントAに「認証モジュールをリファクタリングしてほしい」と指示します。
同時に、別タブのエージェントBには「ユーザーダッシュボードにフィルタ機能を追加してほしい」と指示します。
どちらも同じリポジトリの同じディレクトリで動いています。
最初のうちは問題なさそうに見えます。
ところが、エージェントAが auth/user.ts を書き換えている最中に、エージェントBが同じファイルのインポートパスを変更し始めます。
どちらも「自分の指示に従って正しく動いている」つもりです。
そこには、人間が調停しない限り解消されない矛盾が生まれています。
「ブランチを切れば解決するんじゃ?」という考えが浮かぶかもしれません。
でもブランチはコミット履歴の分岐であって、ディレクトリを分離するものではありません。
ブランチAとブランチBを切ったとしても、あなたのファイルシステム上の作業ディレクトリはどちらか一方だけです。
2つのブランチを 同時に別々のディレクトリで チェックアウトすることは、通常の Git 操作にはできません。
これが根本的な問題です。
エージェントの自律性も、問題を複雑にします。
人間が手動で編集しているなら「あ、上書きした」と気づきます。
でもエージェントは止まらずに書き換え続けます。
競合が「気づいたとき」ではなく、「気づかないまま」進行するのが一番やっかいなところです。
stash も汚染されます。
エージェントAが作業前に stash push していた変更を、エージェントBが誤って pop してしまう。
もしくはエージェントが未コミットの変更を放置したまま次の指示を受け取り、前の作業の残骸が次の作業に混じり込む。
こういった事故は後から原因を特定するのがとにかく難しく、「なんか変な状態になってる」と気づいた時点ですでに傷口が広がっています。
人間がコードを書くときのペアプロなら「ちょっと待って」が言えます。
でも自律的に動くエージェントは待ってくれません。
複数エージェントが同一ツリーを共有することの危険さは、そこにあります。
git worktree の仕組みと、それでも使われない理由
git worktree は Git に標準で備わっている機能です。
1つのリポジトリから複数の作業ディレクトリを同時に展開できます。
仕組みはシンプルです。
.git ディレクトリ本体は元のリポジトリだけが持ちます。
追加したワークツリー側の .git は「本体への参照を書いた1行のファイル」に過ぎません。
だから軽量で速く、Git オブジェクト（コミット・ブロブ・ツリー）は一切複製されません。
エージェント2本分の並列環境を従来のコマンドで作るとこうなります。
# エージェントA用のブランチとワークツリーを作成
git worktree add -b feat/agent-a ../myproject-agent-a
# エージェントB用のブランチとワークツリーを作成
git worktree add -b feat/agent-b ../myproject-agent-b
# 使い終わったら（エージェントAのツリー）
cd ../myproject
git worktree remove ../myproject-agent-a
git branch -d feat/agent-a
# 使い終わったら（エージェントBのツリー）
git worktree remove ../myproject-agent-b
git branch -d feat/agent-b
「これくらい打てばいいじゃないか」と思うかもしれません。
でも問題は手順の数だけではないんです。
まず、パス名を自分で全部決める必要があります。
../myproject-agent-a というパスを今ここで考えて打つのは、最初の1回ならまあいい。
でも3本目・4本目になってくると、命名ルールが揃っているかどうか怪しくなってきます。
「前回は myproject- プレフィックスにしたけど今回は?」という認知負荷が地味に積み上がります。
次に、削除を忘れやすい。
git worktree remove を忘れると、ファイルシステム上にディレクトリが残ったまま Git の管理情報だけが宙に浮く「孤立ワークツリー」状態になります。
git worktree list を叩くたびに見知らぬパスが並び始め、git worktree prune で整理するという作業がまた一つ増えます。
そして VSCode の検索対象問題があります。
リポジトリ内に .worktrees/ のような形でワークツリーをネストさせると、検索結果に全ワークツリーの同名ファイルがずらっと並んで混乱します。
「知ってるけど使ってない」の正体は、こういった構造的な摩擦の積み重ねです。
worktrunk で摩擦を取り除く
worktrunk は git worktree の UX 専用に設計された CLI ツールです。
前節で挙げた摩擦のほとんどを、コマンド1〜2つで解消してくれます。
インストールはこれだけです。
# Homebrew（macOS）
brew install worktrunk && wt config shell install
# Cargo（クロスプラットフォーム）
cargo install worktrunk && wt config shell install
wt config shell install は必ず実行してください。
.bashrc や .zshrc にシェル統合のフックが追加され、wt コマンドがディレクトリ移動まで面倒を見てくれるようになります。
これを省くと wt switch がうまく動きません。
主な操作と従来コマンドの差分を整理すると、こうなります。
- 作成 + エージェント起動: wt switch -c -x claude feat/agent-a の1コマンド。従来は git worktree add → cd → claude の3ステップ。
- 一覧表示: wt list でブランチ名・変更差分・CIステータスを整形して表示。従来の git worktree list はパスしか出ない。
- 後片付け: wt remove でワークツリー削除とブランチ削除が一括。従来は cd → git worktree remove → git branch -d の3ステップ。
- マージ + 後片付け: wt merge で squash / rebase / merge を選んで実行し、ワークツリーとブランチを一括削除。
特に注目してほしいのが wt switch の設計思想です。
# このコマンド1行で以下をすべてやってくれる
# 1. feat/agent-a ブランチを新規作成
# 2. ワークツリーを所定のパスに展開
# 3. そのディレクトリに cd
# 4. claude（Claude Code）を起動
wt switch -c -x claude feat/agent-a
従来なら「ブランチ名を決めてパスを考えて add して cd してエージェントを起動」という手順を頭で組み立てる必要がありました。
worktrunk はその手順ごと吸収して、「タスク名を決めて叩くだけ」に変えています。
これが「ワークフローの土台としての worktree」という考え方です。
git worktree はもともとあった機能ですが、使い始めのコストが高くてワークフローに乗らなかった。
worktrunk はそのコストを下げることで、worktree を 当たり前のスタート地点 に変えようとしています。
並列エージェントのディレクトリ構成と、実務で踏むつまずき
worktree を並列エージェントに使うとき、ディレクトリをどこに置くかで2つのパターンがあります。
sibling レイアウト は、元のリポジトリと同じ階層にワークツリーを並べる構成です。
~/code/
├── myproject/ ← 本体（main ブランチ）
├── myproject-agent-a/ ← エージェントA用
└── myproject-agent-b/ ← エージェントB用
worktrunk のデフォルトはこのパターンです。
VSCode で myproject/ を開いている限り、隣のディレクトリは検索対象に入りません。
ファイル検索が汚染されず、IDE との相性もいいため、まずこちらで始めるのが安牌です。
nested レイアウト は、リポジトリ内の特定ディレクトリ以下にまとめる構成です。
~/code/myproject/
├── .git/
├── .worktrees/
│ ├── agent-a/
│ └── agent-b/
├── src/
└── package.json
リポジトリ直下に収まるので「全体がどこにあるか」が把握しやすい反面、いくつか設定が必要になります。
.gitignore に .worktrees/ を追加しておかないと、メインブランチの git status にワークツリーの中身が大量の未追跡ファイルとして現れます。
VSCode を使っている場合は settings.json の files.exclude にも .worktrees/ を追加しないと、検索結果に全エージェントの同名ファイルが並んで混乱します。
「nested にしてみたら検索が地獄になった」体験は、実際に手を動かすとかなりの確率で踏みます。
先に設定しておくのが得策です。
どちらを選ぶにせよ、 1エージェント・1ワークツリー・1タスク というルールは守る価値があります。
タスクをまたいで1つのワークツリーを使い回し始めると、どのコミットがどのタスクのものか分からなくなります。
レビュー・ロールバック・競合解消のどれをとっても、タスクが混在したワークツリーは作業コストが跳ね上がります。
「1ワークツリー・1タスク」を守るだけで、エージェントが出した成果を人間がレビューするときの見通しがぐっとよくなります。
使い終わったワークツリーをそのまま放置する問題も、地味に効いてきます。
作業が一段落したあとに削除を忘れると、ブランチが散乱し、git worktree list に見知らぬパスが並び始めます。
worktrunk を使っているなら、タスクが終わったら wt remove をすぐ叩く習慣にしてしまうのが一番ラクです。
wt merge を使えばマージ・ブランチ削除・ワークツリー削除が一括で走るので、後片付けの漏れが構造的に起きにくくなります。
git worktree は「なんとなく知っている」状態から「当たり前に使う」状態になるだけで、並列エージェントの運用がかなり変わります。
worktrunk はその移行を、なるべく頭を使わずに実現してくれるツールです。
まず wt switch -c -x claude でエージェントを1本起動してみて、終わったら wt remove で片付ける。
その小さい繰り返しが、ワークフローの土台になっていきます。
株式会社ホコサキは山口県宇部市を拠点とする IT 企業です。
Web 制作・業務システム開発・AI 活用支援を手掛けており、エージェントを活用した開発ワークフローの整備や導入支援も対応しています。
ご相談は お問い合わせページ からどうぞ。