[Git] AI駆動開発で必須の git worktree、使えてますか？

こんにちは。

Claude CodeやCodexにタスクを投げた後、終わるまでの数分間、ぼーっと待っていませんか？

私はずっと待っていました。「リファクタリングお願い」と投げて、進捗のログが流れるのを眺めて、終わったらレビューして、次のタスクを投げて、また眺めて……。AIが速くなればなるほど、逆に「自分が待っている時間」が目立つようになってきたんですよね。

今回はその待ち時間を潰してくれた git worktree の話をします。

結論から言うと

AI駆動開発における git worktree の価値は「作業ディレクトリを増やせること」ではなく「AIを並列に走らせられること」です。

git worktree 自体はGit 2.5(2015年)からある、決して新しくない機能です。私も存在は知っていましたが、正直「ブランチ切り替えが面倒なときの裏技」くらいの認識で、ほとんど使っていませんでした。

ところが、AIにコードを書かせるようになってから評価が完全にひっくり返りました。理由は単純で、AIエージェントは1つの作業ディレクトリを丸ごと占有するからです。ここが人間と決定的に違います。

なぜAI駆動開発だと worktree が効くのか

人間は「頭の中」で並列できるが、AIはできない

人間が複数タスクを抱えるとき、実は作業ディレクトリは1つで足ります。タスクAを途中まで書いて、git stash して、タスクBに切り替えて、また戻ってくる。切り替えのコストは「自分の頭の中」で吸収できるからです。

でもAIエージェントは違います。エージェントはファイルを読んで、書き換えて、テストを走らせて、また読む、というループを回します。この最中に別のブランチへ git switch したら何が起きるか。AIが読んでいるファイルの中身が、AIの知らないうちに書き換わります。 これは事故です。

つまり、AIエージェント1体につき、作業ディレクトリ1つが必要ということになります。

じゃあリポジトリを複数cloneすればいいのでは？

はい、それでも動きます。実際、私も最初は corporate-site-2 みたいなディレクトリを作って git clone していました(お恥ずかしい)。

ただ、これはこれで面倒でした。

• cloneし直すのでダウンロードが走る(モノレポだとそこそこ待つ)
• リポジトリが物理的に別なので、ブランチやコミットが共有されない
• 片方でコミットしたものを、もう片方で見るのに fetch が要る
• どれが何のディレクトリなのか分からなくなる

git worktree はここを綺麗に解決します。1つの .git を共有したまま、作業ディレクトリだけを複数持てるんです。

git worktree って何？

超ざっくり言うと、**「同じリポジトリの、別ブランチの実体を、別のディレクトリに同時に展開する」**機能です。

普通のGitだと、リポジトリ1つに対して作業ディレクトリは1つ、チェックアウトできるブランチも1つです。

corporate-site/          ← .git と作業ディレクトリがセット
  .git/
  app/
  _posts/

worktree を追加すると、こうなります。

corporate-site/          ← メインの作業ディレクトリ(.git の本体はここ)
  .git/
  app/
  _posts/

corporate-site-feature-a/   ← worktree その1(feature-a ブランチ)
  .git                      ← ディレクトリではなく「ファイル」。本体への参照が書いてある
  app/
  _posts/

corporate-site-feature-b/   ← worktree その2(feature-b ブランチ)
  .git
  app/
  _posts/

ポイントは、追加した worktree の .git がディレクトリではなくファイルになっているところです。中身を見ると、本体の .git への参照が1行書いてあるだけです。

$ cat ../corporate-site-feature-a/.git
gitdir: /Users/kenji/GitHub/corporate-site/.git/worktrees/corporate-site-feature-a

コミット履歴もブランチもstashも、全部メインの .git に集約されています。だから、worktree Aでコミットしたものは、worktree Bから fetch なしで即座に見えます。cloneし直す必要もありません。**「実体は1つ、窓が複数」**というイメージが一番近いと思います。

実際の使い方

覚えるコマンドは実質3つです。

1. 追加する

# 新しいブランチを切りつつ worktree を作る(一番よく使う)
git worktree add ../corporate-site-feature-a -b feature-a

# 既存のブランチをチェックアウトする場合
git worktree add ../corporate-site-hotfix hotfix/urgent

第1引数がディレクトリのパス、-b が新しく切るブランチ名です。私はリポジトリの隣に <リポジトリ名>-<ブランチ名> で並べる運用にしています。

作ったらそこに cd して、いつも通りAIを起動するだけです。

cd ../corporate-site-feature-a
claude

これで、元のディレクトリにいるAIとは完全に独立して動きます。片方が app/page.tsx を書き換えても、もう片方には一切影響しません。

2. 一覧を見る

$ git worktree list
/Users/kenji/GitHub/corporate-site             7ac075d [main]
/Users/kenji/GitHub/corporate-site-feature-a   3f21ab9 [feature-a]
/Users/kenji/GitHub/corporate-site-hotfix      d5d9d6e [hotfix/urgent]

「あれ、今いくつ並列で走らせてたっけ？」となったときに叩きます。私は割と頻繁に叩いています(すぐ忘れるので……)。

3. 消す

作業が終わってマージしたら、必ず消します。

git worktree remove ../corporate-site-feature-a

rm -rf でディレクトリを直接消してしまうと、Gitの管理情報だけが残ってゾンビになります。その場合は次のコマンドで掃除できます。

git worktree prune

うっかり rm -rf してしまったときの救済策として覚えておくと安心です。

AI駆動開発での実際の運用

ここからが本題です。私が普段どう使っているかを書きます。

パターン1: 待ち時間をなくす(これが本命)

一番効果があったのはこれです。

# ターミナル1
cd ~/GitHub/corporate-site-feature-a
claude  # 「この画面のリファクタリングお願い」

# ターミナル2
cd ~/GitHub/corporate-site-feature-b
claude  # 「このバグの原因調査お願い」

AIが1つ目のタスクを回している間、2つ目のターミナルで別のタスクを投げる。片方が終わったらレビューして、その間にもう片方が進んでいる。「AIを待つ時間」が「別のAIをレビューする時間」に変わります。

正直、これに気づいたときは結構な衝撃でした。感覚的には、AIの速度が上がったというより「自分のアイドル時間が消えた」に近いです。効率が何倍、みたいな数字を出したいところですが、タスクの重さでブレブレなのでやめておきます(体感としては、待ち時間がほぼゼロになったのが一番大きいです)。

パターン2: 「壊してもいい場所」を用意する

AIに大きめのリファクタリングを頼むとき、正直ちょっと怖くないですか。

worktree なら、失敗しても git worktree remove でディレクトリごと消せば無かったことにできます。メインの作業ディレクトリは一切汚れません。心理的なハードルが下がるので、思い切った指示を出しやすくなりました。

パターン3: レビューしながら次を書く

PRを出した後のレビュー対応と、次の機能の実装を同時に進められます。レビューコメントが来たら worktree Aで直して、そのまま worktree Bで次の実装を続ける。git stash の出番がほぼ無くなりました。

ハマったところ(正直に書きます)

万能ではないです。実際に踏んだものを挙げておきます。

1. node_modules と .env.local は付いてこない

これが最大の落とし穴です。 worktree はGitの管理下にあるファイルしか展開しません。.gitignore されているものは当然コピーされないので、新しい worktree では毎回インストールが必要です。

git worktree add ../corporate-site-feature-a -b feature-a
cd ../corporate-site-feature-a
npm install                        # 毎回必要
cp ../corporate-site/.env.local .  # これも忘れがち

.env.local を忘れて「なんかビルド通らないんだけど？」と5分くらい悩んだことがあります。恥ずかしい。私は面倒になったので、この2行をまとめたシェル関数を作りました。

wt() {
  local name=$1
  local repo=$(basename $(git rev-parse --show-toplevel))
  local dir="../${repo}-${name}"
  git worktree add "$dir" -b "$name" || return 1
  cd "$dir"
  [ -f "../${repo}/.env.local" ] && cp "../${repo}/.env.local" .
  npm install
  echo "✨ $dir の準備ができました"
}

wt feature-a で一発です。リポジトリごとに事情が違う(uvだったりbundlerだったり)ので、そこは適宜書き換えてください。

2. 同じブランチを2箇所でチェックアウトできない

$ git worktree add ../corporate-site-2 main
fatal: 'main' is already checked out at '/Users/kenji/GitHub/corporate-site'

これは仕様です。というか、むしろ安全装置として正しい挙動だと思います。--force で無理やり通すこともできますが、AIを並列で走らせている文脈でこれをやると、同じブランチを2体のAIが同時に書き換えることになるので、素直に別ブランチを切るのが吉です。

3. ディスクは普通に食う

.git は共有されますが、作業ディレクトリの実体とnode_modulesは worktree の数だけ増えます。node_modulesが重いプロジェクトだと、3つ4つ並べたときにそれなりに効いてきます。

とはいえ、SSDの容量より私の待ち時間の方が高いので、私は気にしないことにしました。

4. 「どこで作業してたか」を見失う

worktree を4つも5つも作ると、普通に迷子になります。ターミナルのタブ名を変えるとか、シェルのプロンプトにブランチ名を出すとか、何かしら目印は必要です。あと、こまめに消すのが結局一番効きます。

余談：Claude Codeにはサブエージェントやチーム機能もありますが、あれは「1つの作業ディレクトリの中で複数のAIが動く」ものなので、worktree とは目的が違います。詳しくはこちらの記事に書きました。worktree は「完全に別のタスクを、完全に独立させたい」ときの道具です。

clone と worktree、結局どっちがいいの？

比較表にしておきます。

同じリポジトリで並列作業するなら、worktree 一択でいいと思います。 clone を複数持つ意味があるのは、フォーク元と自分のフォークを別々に持ちたいとか、そういう特殊なケースくらいかなと。

まとめ

• git worktree は「1つの .git を共有したまま、作業ディレクトリだけを複数持つ」機能
• 人間には地味な機能だったが、AIエージェントが作業ディレクトリを1つ占有するので、AI駆動開発だと一気に必須級になる
• 覚えるのは add / list / remove の3つだけ
• 最大の効果は「AIの待ち時間が、別のAIのレビュー時間に変わる」こと
• 落とし穴は node_modules と .env.local が付いてこないこと。シェル関数を1つ作れば解決
• 作ったらこまめに消す。これだけは守った方がいいです

AI駆動開発の話題って、どうしても「どのモデルが賢いか」「どのツールが速いか」に寄りがちですが、実際に効いてくるのはこういう地味な足回りだったりします。少なくとも私は、モデルを乗り換えるより worktree を覚えた方が体感の改善は大きかったです。

まずは1つ、git worktree add ../<リポジトリ名>-test -b test を叩いてみてください。それだけで感覚が掴めるはずです。

同じように「AIを待っている時間」がもったいないと感じている方の参考になれば幸いです！それではまた！