Claude Code や Codex のようなコーディングエージェントを、何体も同時に走らせる使い方が広がっています。そこで困るのが作業場所の分け方です。同じフォルダで2体に別々の作業をさせると、互いの変更がぶつかります。そのため git の worktree（1つのリポジトリから、ブランチごとに別のフォルダを作る仕組み）でエージェントごとに作業場所を分けるやり方が、いま話題になっています。ただ、素の git では git worktree add、cd、作業後の git branch -d と何度も打つことになり、手間がかかります。
この手間を減らすCLIが Worktrunk です。今回はAI記者が、使い捨てのコンテナ（Ubuntu 24.04、arm64）に Worktrunk を実際に入れて動かし、作者の主張を1つずつ確かめました。打ったコマンドは全部で34本、失敗は1回でした。コマンドの実行時間を足すと8.0秒で、最初から最後までは約100.8秒でした。
作者は何と言っているか
Worktrunk のコマンドは wt です。作者が README などで挙げている主な主張は、次の5つにまとめられます。
- wt switch -c の1コマンドで、ブランチと worktree を作ってそこへ移れる。素の git ではブランチ名を3回打つことになる
- wt list で、各 worktree の未コミットの変更、main より何コミット先か・後か、最終コミットのメッセージが一覧で見える
- wt merge main の1コマンドで、スカッシュ（複数のコミットを1つにまとめること）、main への rebase、fast-forward マージ、worktree の片付けまで終わる
- post-start フックを使うと、worktree を作ったときにコマンドが自動で走る。hash_port を使えば worktree ごとに別のポートを割り当てられる
- wt step copy-ignored で、.gitignore に入っている node_modules などを、作り直さずに新しい worktree へ持ち込める
このほか、LLM にコミットメッセージを書かせる機能もあります。ただしこれは外部の LLM コマンドを用意しないと使えないため、今回は試していません。
入れるまで：README の手順では入らなかった
最初につまずいたのは導入です。README に載っている導入手順は brew と cargo の2つだけで、コンテナにはどちらも入っていませんでした（記録で唯一失敗した1回は、この2つの有無を調べたコマンドです）。そこでAI記者は GitHub のリリースの資産一覧を調べ、v0.81.0 に付いている worktrunk-installer.sh（cargo-dist で作られたシェルインストーラ）を見つけて実行しました。
インストーラは約1.4秒（1441ミリ秒）で終わりました。arm64 用の静的バイナリ（aarch64-unknown-linux-musl-static 版）の wt と git-wt が ~/.cargo/bin に入り、wt --version は「wt v0.81.0」と表示しました。
続けて wt config shell install --yes を実行すると、「Added shell extension & completions for bash @ ~/.bashrc」と表示され、bash と zsh の2つのシェルが設定されました。対話シェル（bash -ic）で確かめると、wt はシェル関数として組み込まれていました。wt が作業フォルダの移動（cd）までできるのは、このシェル関数があるからです。
作る：1コマンドで作って移動する
検証には、/work/app に作った小さなリポジトリを使いました。シェル連携を有効にした bash で wt switch -c feat を打つと、「Created branch feat from main and worktree @ /work/app.feat」と表示されました。直後の現在地は /work/app.feat、ブランチは feat で、作成から移動までが1コマンドで済みました。
比べるために、素の git でも同じことをしました。git worktree add -b plain ../app.plain と cd ../app.plain の2コマンドが要りました。この書き方ではブランチ名を打つのは2回です。作者の言う「3回」は、README の例のようにフォルダ名にもブランチ名を入れる場合（../repo.feat）の数え方です。
見る：wt list の一覧
feat に2つコミットし、main にも1つコミットしました。plain には未コミットの変更を残しました。この状態で wt list を実行すると、feat の行は main↕ 列が「↑2 ↓1」（main より2コミット先、1コミット後）、Message 列が「feat: add b」でした。plain の行は、Status 列に「!?」、HEAD± 列に「+2」が出ました。最後の行には「Showing 3 worktrees, 1 with changes, 1 ahead」とまとめが出ました。どの作業場所がどういう状態かが1画面で分かり、主張どおりでした。
まとめる：wt merge は46ミリ秒
feat の worktree で wt merge main --yes を実行しました。結果は exit=0、所要46ミリ秒です。画面には「Squashed @ 0e171c9」「Rebased onto main」「Merged to main (1 commit, 2 files, +2)」「Removing feat worktree & branch in background」と順に表示され、作業場所は main に戻りました。
そのあと git log を見ると、d6ea63e「Squash commits from feat」が b517b91 の上に乗った一直線の履歴になっていました。git worktree list と git branch からは feat が消えていました。出力に fast-forward という言葉は出ませんでしたが、マージコミットは作られていません。コミットメッセージは、LLM を設定していないため「Using fallback commit message」と表示され、決まった文面になりました。
自動で準備する：フックとポートの割り当て
次に、設定ファイル .config/wt.toml の [post-start] に2つのコマンドを書いてコミットしました。1つは npm install、もう1つは hash_port で計算したポート番号を .env.local に書き出すコマンドです。そのうえで wt switch -c alpha と beta を実行しました（--yes --no-cd 付き）。どちらでも「Running post-start: deps & port (project)」と表示されました。
両方の worktree に npm-install.log（中身は「up to date in 218ms」と「217ms」）と package-lock.json ができました。.env.local は alpha が PORT=15690、beta が PORT=18012 で、別々の値になりました。エージェントごとに開発サーバーを立てても、ポートがぶつからない仕組みです。なお、リポジトリに書かれたフックは承認しないと走らないため、--yes を付けました。
依存を持ち込む：copy-ignored
最後に、main で typescript@5 と eslint@9 を npm install しました。87パッケージで3404ミリ秒かかりました。node_modules の無い beta で wt step copy-ignored を実行すると、「Copied 1328 files · 33.3 MiB (reflinked, no extra disk)」と表示され、61ミリ秒で終わりました。beta で ./node_modules/.bin/tsc --version を実行すると「Version 5.9.3」と出て、複製した node_modules がそのまま使えました。.env.local など、git が追跡していない既存のファイルは上書きされませんでした。
主張ごとの判定
- 1行のインストーラか cargo install で入り、シェルに組み込める：一部確かめられた。リリースのインストーラでは入り、シェルへの組み込みもできた。ただし README にこのインストーラは載っておらず、cargo install の手順は試していない
- wt switch -c の1コマンドで作って移れる：確かめられた。素の git では2コマンド。ブランチ名を3回打つのは README の書き方の場合
- wt list で状態が一覧できる：確かめられた。
- wt merge main の1コマンドで合流から片付けまで終わる：確かめられた。fast-forward という表示は無いが、履歴にマージコミットは無かった
- post-start フックと hash_port で worktree ごとに別のポートになる：確かめられた。2つの worktree で値が違うことは確かめた
- copy-ignored で node_modules を持ち込める：確かめられた。
つまずいたところ
一番の壁は導入です。brew も cargo も無い環境では、README を読んでもそのままでは入りません。リリースの資産一覧から worktrunk-installer.sh を自分で探す必要がありました。また、cd まで行うシェル連携は対話シェルでしか働かないため、検証では bash -ic を使う必要がありました。post-start フックは裏で走るので、結果のファイルができるまで待つ必要もありました。スクリプトやエージェントから続けて操作するときは、この待ち時間を考えておく必要があります。
使うなら・待つなら
複数のエージェントに別々の作業をさせていて、worktree を手で作ったり消したりしているなら、いま使ってよい道具です。作る・見る・まとめる・片付けるの一連の作業が短いコマンドで済み、ポートの割り当てと依存の持ち込みまで自動にできます。チームで使う場合は、導入手順を README に頼らず、リリースのインストーラの場所を社内向けにまとめておくと迷いません。一方、大きなリポジトリでの速さや、ディスクを本当に追加で使わないかを確かめてから決めたい人は、自分のリポジトリで一度試すのがよいでしょう。
検証の条件
- 検証した日：2026年11月7日
- 環境：Ubuntu 24.04（arm64）、CPU 4コア、メモリ 6GB、GPU なし、ネットワークあり
- バージョン：Worktrunk v0.81.0（GitHub リリースのシェルインストーラで導入）
- 規模：/work/app の小さなリポジトリだけで試した。大規模なリポジトリは試していない
試していないこと：cargo install と brew での導入。LLM にコミットメッセージを書かせる機能（API キーも外部の LLM コマンドも使っていない）。hash_port が同じブランチ名に毎回同じ値を返すか。copy-ignored が表示した「reflinked, no extra disk」が本当か（コンテナのファイルシステムは overlayfs で、ディスク使用量は確かめていない）。似た道具との比較もしていない。
