git worktree で Claude Code を並列で走らせる方法

同じチェックアウトに対して Claude Code セッションを 2 つ走らせた瞬間から、互いの作業の 踏み荒らしが始まります。git status は混ざり、ビルドは相手タスクの書きかけの 編集を拾い、コミットには無関係な変更が紛れ込む。これを解決するのが git worktree です。 clone は 1 つのまま、セッションごとに専用の作業ディレクトリを持てます。このガイドは 私たちが実際に使っている worktree 運用を、毎日使って 1 週間後に初めて引っかかる 落とし穴まで含めてまとめたものです。

なぜ worktree が他の方法より良いのか

並列セッションに専用のファイル群を与える方法は 3 つあり、うち 2 つには実コストがあります:

• 同じチェックアウトで「気をつけて使う」 — 即座に破綻します。両セッションが互いの 未コミット編集を見てしまい、片方の git checkout がもう片方の読んでいるファイルを黙って書き換えます。
• 複数 clone — 動きはしますが、clone ごとにオブジェクトストアが丸ごと複製され、 fetch も個別に必要で、リモートやローカルブランチの状態が clone 間でずれていきます。
• worktree — リポジトリは 1 つ、オブジェクトストアとリモート設定は共有のまま、 作業ディレクトリを好きな数だけ持てて、それぞれが専用ブランチに固定されます。作成は 1 秒程度です。

基本のセットアップ

# メインのチェックアウトから
git worktree add ../myapp-fix-auth       -b fix-auth
git worktree add ../myapp-new-onboarding -b new-onboarding

# worktree ごとに 1 つの Claude Code セッション
cd ../myapp-fix-auth        && claude   # ターミナルタブ 1
cd ../myapp-new-onboarding  && claude   # ターミナルタブ 2

git worktree add <path> -b <branch> は、ディレクトリ作成・ブランチ作成・ チェックアウトを一度に行います。これで各セッションはクリーンなツリーと専用のビルド成果物を持ち、 ある worktree でのコミットは他の worktree からも即座に見えます — 同じリポジトリなので、 worktree 間で push / pull は不要です。

ディレクトリ名はリポジトリ名ではなくタスク名で付けます。myapp-fix-auth は myapp-2 より明らかに読みやすい。ターミナルのタブ・git worktree list・ ステータスボード — あなたが目にするすべての一覧にはこのディレクトリ名が表示されるので、 この習慣 1 つで全部の一覧が読めるようになります。worktree をメインのチェックアウトの隣 （../myapp-*）に置くと、見つけやすく、バックアップやファイル監視の除外設定もしやすくなります。

worktree が共有するもの・しないもの

worktree はオブジェクトストア・ブランチ・リモート・stash・リポジトリ設定を共有します。 一方、git が追跡していないものは一切共有されません — そして引っかかるのはこちらのリストです:

• .env などのローカルシークレット — 意図的に未追跡なので、新しい worktree には 存在しません。タスクに必要なものをコピーします: cp ../myapp/.env .
• インストール済み依存関係 — node_modules/ や virtualenv の類は ディレクトリ単位です。worktree ごとにインストールを 1 回実行しないと、初回ビルドが分かりにくく失敗します。
• ビルドキャッシュ — 各 worktree の初回ビルドはゼロからです。これは分離の対価で、 以降のインクリメンタルビルドは速くなります。

追跡済みファイルにはこの手当てが不要です。リポジトリ直下の CLAUDE.md が worktree と 相性抜群なのはまさにこのためで、新しい worktree — つまり新しい Claude Code セッション — が毎回、 同じビルドコマンド・テストコマンド・規約を説明し直しなしで持った状態から始まります。 なお、同じブランチを複数の worktree で同時にチェックアウトすることはできず、git が 2 つ目を 拒否します。これは利点です。「このブランチはどのセッションのものか」が常に一意になります。

ライフサイクル: マージ → remove → prune

worktree は使い捨てにできる程度に軽い存在です。ブランチがマージされたら:

git worktree remove ../myapp-fix-auth   # ディレクトリを削除
git branch -d fix-auth                  # マージ済みブランチを削除
git worktree prune                      # 手で消したディレクトリの管理情報を掃除

worktree は住居ではなくセッションとして扱います。タスク開始時に作り、ブランチがマージされたら 消す。長生きした worktree はデフォルトブランチから取り残されて、開くたびにコンフリクトで 出迎えてくれます。数週間生かす必要があるなら、普通の長寿命ブランチと同じく定期的に rebase / merge してください。worktree を消すときに対応する Claude Code セッションも終了しておくと、 どの一覧を見ても実態と一致した状態が保てます。

worktree が解決しないもの: 「今、誰があなたを待っているか」

worktree が分離するのはファイルです。注意（アテンション）には何もしてくれません。 並列の各セッションは予測できないタイミングでブロックします — 編集やシェルコマンドの許可待ち、 プランの承認待ち、選択肢つきの確認質問、あるいは単なる完了。worktree セッションを 3〜4 個 走らせていると、あなたが別のタブを眺めている間に、どれか 1 つは他の出力の陰で止まっています。

Claude Code の hooks を使えば、 そうした瞬間を macOS 通知としてプッシュできます。 そして「どの worktree が今ブロックしているか」という集約ビューのために作ったのが AgentManager です。macOS のメニューバーアプリで、マシン上の全 Claude Code セッションをステータスランプつきの行として一覧します — 入力待ち、 実行中、 完了、 アイドル。 行のラベルは作業ディレクトリ名なので、myapp-fix-auth のようなタスク名 worktree の 効果が二重に効きます。行をクリックすれば、iTerm2・Terminal.app・Ghostty・VS Code 系エディタでは そのセッションが動いているターミナルペインへ直接ジャンプします（tmux のセッションもボードで 検出・追跡されますが、tmux ペインへのジャンプは現状非対応です）。入力待ちのセッションが 発生するとウィンドウが自動で現れ、全て解消すると引っ込みます。

worktree セッションのチェックリスト

• 1 worktree・1 ブランチ・1 セッション。 この 1:1:1 対応が、並列作業をレビュー可能にします。
• worktree ディレクトリはタスク名で。 あなたが見るすべての一覧にその名前が表示されます。
• セットアップはスクリプト化する。 git worktree add・.env コピー・依存インストールをやる 5 行の new-task.sh があれば、共有チェックアウトに戻りたくなる摩擦が消えます。
• worktree の数はレビュー帯域に合わせる。 各セッションはあなたが読むべき diff を生みます。多くの人にとって 2〜4 並列が適正です。
• ブランチがマージされたら worktree を消す。 放置された worktree は、すべての一覧を遺跡調査に変えます。