この記事について（広告・アフィリエイトリンクはありません）
紹介しているソフトは無料で入手できます。
Worktrunk は、Git の worktree を「ブランチ名だけ」で扱えるようにするコマンドです。AI エージェントを何体も同時に動かすとき、作業フォルダーを分ける手間を減らします。
Windows 11 の使い捨てのリポジトリで、作成から合流までを試しました。流れは動きましたが、Windows では wt の名前の衝突、署名なしの配布、.env のコピー、PowerShell のプロファイルの場所を押さえておく必要があります。
先に結論（今回のテスト条件で）
| 確かめたこと | 結果 |
|---|---|
| 作成、一覧、合流、削除 | 動いた。日本語とスペースを含むパスでも動いた |
| 3つの worktree で同時に作業 | 互いのファイルは混ざらなかった |
| 同じファイルを変更して合流 | 競合で止まる。解決は自分で行う |
| 変更が残っている worktree の削除 | 拒否された（安全側） |
| フック | 動いた。初回は承認が必要 |
.gitignore のファイルのコピー | 動いた。ただし .env もコピーされた |
| Claude Code との組み合わせ | 未確認（後述） |
- 向いているのは、同時に複数の変更を走らせる人です。1本ずつ作業するなら、普通のブランチで足ります。
- worktree の作成は、素の
git worktree addより約0.6秒遅くなります。手で打つなら気にならない差です。 - Windows では
wtが Windows Terminal と衝突するので、git-wtで呼びます。
配布の Windows 版にはコード署名がなく、Windows Defender が誤検知するという報告もあります。
worktree は何のためにある？
Git の worktree は、1つのリポジトリから作業フォルダーを複数作る機能です。ブランチを切り替えなくても、フォルダーごとに別のブランチを開けます。
エージェントを2体、同じフォルダーで動かすと、ファイルを取り合います。フォルダーを分けるのは、この衝突を避けるためです。
素の Git でもできることですが、ブランチ名とパスを毎回指定する手間があります。
| やること | Worktrunk | 素の Git |
|---|---|---|
| 作成して移動 | git-wt switch -c feat | git worktree add -b feat ../repo.feat と cd ../repo.feat |
| 一覧 | git-wt list | git worktree list |
| 片付け | git-wt remove | git worktree remove ../repo.feat と git branch -d feat |
試した環境
| 項目 | 内容 |
|---|---|
| OS | Windows 11 |
| Worktrunk | v0.81.0（2026-10-20）の zip を使い捨てのフォルダーに展開 |
| Git | 2.52.0（Git for Windows） |
| シェル | PowerShell 7 |
| リポジトリ | 検証用に新しく作ったもの。普段のリポジトリは使っていません |
| 検証日 | 2026年11月4日 |
入れ方
Windows の公式の手順は winget です。
winget install max-sixty.worktrunkwt という名前は、Windows Terminal がすでに使っています。そのため winget 版は git-wt という名前でも入ります。この記事の例も git-wt で統一しました。
私は PC の環境を変えないように、winget は実行せず、同じ zip を展開して試しました。winget show が示す zip の SHA-256 は、リリースの .sha256 および手元のファイルと一致しています。
確かめておきたい署名
| 確認 | 結果 |
|---|---|
| zip の SHA-256 | 389b595cb67482085419968939e329d61901cca9e959e4b6c288f01387b768b8（公式の値と一致） |
git-wt.exe の署名 | なし（Authenticode: NotSigned） |
README には SignPath による署名の案内があります。ただし Issue #3355 の作者の説明によると、v0.78.0 以降は署名なしに戻っていて、本番の証明書を待っている状態です。
この Issue には、Windows Defender が Trojan:Win32/Wacatac.B!ml と判定して入らないという報告もあり、開発側は誤検知としています。今回の PC では止まりませんでした。
移動を効かせる設定
git-wt は別のプログラムなので、そのままでは今のシェルの場所を変えられません。何もしないと、次のように表示されます。
Cannot change directory — shell integration not installed公式の手順は git-wt config shell install です。これは PowerShell のプロファイルを書き換えます。先に --dry-run で書き込み先を確かめてください。
git-wt config shell install powershell --dry-run私の環境では、書き込み先は WindowsPowerShell の側でした。ところが PowerShell 7 の $PROFILE は PowerShell の側を指しています。PowerShell 7 を使う人は、別の場所を指していないか確かめてください。 実際のプロファイルは書き換えていません。
代わりに、そのセッションだけで次を実行して確かめました。作成後に、新しいフォルダーへ移動しました。
Invoke-Expression (& git-wt config shell init powershell | Out-String)毎回使うなら、自分で $PROFILE にこの行を足します（足した状態は試していません）。
基本の使い方
git-wt switch -c feat-a # 作って移動
git-wt list # 一覧
git-wt merge main # main へ合流して片付け
git-wt remove feat-b # 消す既定の場所はリポジトリの隣で、repo.feat-a のような名前です。
merge がしてくれること
git-wt merge main の1回で、次の順に処理されました。
- 複数のコミットを1つにまとめる（squash）
- main へ取り込む
- worktree とブランチをバックグラウンドで消す
まとめるのをやめるときは --no-squash を付けます。LLM の設定がないと、コミットメッセージは Squash commits from feat-a という定型文になりました。
コミットしていない変更があると消せない
| 状態 | git-wt remove の結果 |
|---|---|
| コミットしていない変更がある | 拒否。--force が必要 |
| 合流していない | worktree は消え、ブランチは残る。-D でブランチも消える |
| 合流済み | 両方消える |
3つ同時に動かしてみた
エージェントの代わりに、別々のフォルダーでファイルを書いてコミットする処理を、3つ同時に動かしました。
| 確認 | 結果 |
|---|---|
| コミット先 | それぞれ自分のブランチ（p1、p2、p3） |
| 作業後の未コミット | 0件 |
| 別のフォルダーのファイル | 混ざらなかった |
ただし 全員が同じ shared.txt を変更すると、合流のときに競合します。1本目は通り、2本目は次のように止まりました。
Rebase onto main incomplete
CONFLICT (add/add): Merge conflict in shared.txt自動では解決しません。ファイルを直して git add、git rebase --continue のあと、もう一度 git-wt merge main で通りました。worktree はフォルダーの衝突を防ぐものです。変更の内容がぶつかるのは防げません。 エージェントに渡す仕事は、触るファイルが重ならないように分けておくと安全です。
Claude Code は試せていない
-x で作成後にプログラムを起動できます。公式の例は -x claude です。今回の PC には claude のコマンドが PATH になかったので、代わりに cmd、git、npm で起動を確かめました。
Claude Code そのものを Worktrunk から動かす確認は、していません。 使い勝手は、実際に試した人の評価を参考にしてください。
-x の書き方でつまずいた
引数はまとめて書けません。-- のあとに分けます。
| 書き方 | 結果 |
|---|---|
-x 'cmd /c cd' | 失敗（パスが見つからない） |
-x cmd -- /c cd | 成功 |
最初はパスの日本語が原因かと思いました。英数字だけのパスでも同じだったので、書き方の問題でした。
フックは動くが、初回は承認が要る
.config/wt.toml に書くと、作成や合流のときにコマンドを動かせます。
[pre-start]
stamp = "echo pre-start $(pwd) > .wt-pre-start.txt"
[post-start]
stamp = "sleep 1; echo post-start {{ branch }} port {{ branch | hash_port }} > .wt-post-start.txt"
[pre-merge]
check = "test -f must_exist.txt"| 確認 | 結果 |
|---|---|
| 初回 | 実行前に承認を求められた。プロンプトが出せない環境では --yes がないと失敗 |
pre-start、post-start | 動いた。ブランチごとのポート番号も作られた |
pre-merge が失敗 | 合流が止まった |
公開の説明では、フックは Windows でも Git Bash で動きます。PowerShell で使う場合も Git for Windows が必要です。 .wt-pre-start.txt のパスも /l/... のような形でした。
承認の仕組みは、他の人のリポジトリのコマンドが勝手に動くのを防いでくれます。ただし --yes はこれを飛ばすので、知らないリポジトリでは使わないでください。
キャッシュのコピーは SSD で1.2秒、NTFS では容量を節約しない
git-wt step copy-ignored は、.gitignore の対象のファイルを新しい worktree にコピーします。node_modules などの作り直しを省くためのものです。
小さなファイル2,000個で測りました。
| 場所と方法 | 時間 |
|---|---|
SSD、git-wt step copy-ignored | 1.2秒 |
| SSD、robocopy | 0.2秒 |
USB の HDD、git-wt step copy-ignored | 80秒〜493秒 |
| USB の HDD、robocopy | 114秒 |
HDD の値は、別のダウンロードが動いていた間のものなので、参考程度に見てください。
README の「コピーせずに共有」は、APFS、btrfs、XFS などの話です。NTFS では実際にファイルをコピーします。 出力にも (full copy) と出ました。ディスクの節約にはなりません。
.env もコピーされる
既定では、.gitignore の対象のファイルが広くコピーされます。今回も .env がコピーされました。秘密の情報を別の場所に増やしたくないときは、.worktreeinclude で対象を絞ります。
node_modules/このファイルを置くと、--dry-run の表示は node_modules だけになりました。
作成は素の Git より約0.6秒遅い
SSD の上で5回ずつ測りました。
| 操作 | Worktrunk | 素の Git |
|---|---|---|
| worktree の作成 | 約0.7秒 | 約0.07秒 |
| 一覧（11個） | 0.48秒 | 0.05秒 |
一覧のほうは状態も調べるので、単純には比べられません。
ライセンスは MIT か Apache-2.0 の選択式
GitHub の表示は「NOASSERTION」ですが、LICENSE の原文は MIT と Apache-2.0 のどちらかを選べるデュアルライセンスです。Cargo.toml も MIT OR Apache-2.0 です。
確認時点でスターは 10,458、フォークは 375。README の「最も人気のある worktree マネージャー」は作者自身の説明で、私は比べていません。スターは品質の保証ではありません。
よくある質問（FAQ）
Q. 無料ですか？
Worktrunk は無料です。LLM のコミットメッセージなどで有料の API を使う設定にすると、その料金がかかります。
Q. Windows Terminal の wt と衝突しませんか？
衝突します。git-wt で呼ぶか、Windows の設定の「アプリ実行エイリアス」で Terminal 側を切ります。
Q. worktree を増やすとディスクを食いますか？
作業ファイルの分だけ増えます。Windows の NTFS では、キャッシュのコピーも実際の容量を使います。
Q. エージェントが同じファイルを触ったらどうなりますか？
合流のときに競合で止まります。自動では解決しません。
Q. Defender に止められました。
誤検知の報告が Issue #3355 にあります。入手元とハッシュを確かめ、不安なら無理に入れないでください。
まとめ
- 作成から合流までの流れは、Windows でも動きました。
- フォルダーは分かれますが、変更のぶつかりは防げません。
git-wtの呼び方、署名なし、.envのコピー、PowerShell のプロファイルの場所に注意が必要です。
検証メモ
エージェントの代役：並行のテストは、ファイルを書いてコミットするだけのスクリプトです。AI エージェントの動きそのものではありません。
計測：作成の時間は5回で、ファイルの少ない小さなリポジトリの値です。大きなリポジトリでは変わります。
Defender：止まらなかったのは今回の PC での結果で、環境によって変わります。誤検知かどうかを私が確かめたわけではありません。
隔離：USERPROFILE などを検証用のフォルダーに向けて実行しました。ただし --dry-run の書き込み先は本物のプロファイルを指していたので、実際の書き込みはしていません。
未確認のこと：winget の実行、Claude Code や Codex との組み合わせ、対話のピッカー、LLM のコミットメッセージ、CI の表示、pr: の切り替え、Git Bash でのシェル連携、ReFS、大きなリポジトリ。
