AI駆動開発で重要になるGit worktreeとは？branchとの違いをやさしく整理
AI駆動開発では、複数のAIエージェントに別々の作業を同時に進めてもらう場面が増えてきました。
たとえば、
- AI A：ログイン機能
- AI B：検索機能
- AI C：テスト追加
- 人間：不具合修正
といった進め方です。
このような並列開発で便利なのが、Gitの worktree です。
ただ、Gitに慣れていないと、
branchがあるのに、worktreeは何のためにあるの？
と少し分かりにくいところがあります。
結論から言うと、役割はこう違います。
branch
= 変更履歴を分ける
worktree
= 作業場所を分けるこの違いを押さえると、かなり理解しやすくなります。
branchは「変更を分ける」
branchは、機能や修正ごとに変更履歴を分ける仕組みです。
たとえば、
main
├─ feature/login
├─ feature/search
└─ fix/paymentのように分けます。
ログイン機能が完成したら、feature/loginをmainへマージします。
つまりbranchは、
- 機能を分ける
- 修正を分ける
- Pull Requestの単位を作る
- 変更履歴を管理する
ためのものです。
worktreeは「作業フォルダを分ける」
通常、Gitでは1つのフォルダでbranchを切り替えながら作業します。
git switch feature/login次に検索機能を触りたければ、
git switch feature/searchと切り替えます。
一方、worktreeを使うと、
project/
→ main
project-login/
→ feature/login
project-search/
→ feature/searchのように、複数のbranchを別フォルダで同時に開けます。
つまり、
branchを切り替えるのではなく、作業場所そのものを分ける
のがworktreeです。
branchとworktreeの違い
簡単に整理するとこうなります。
| branch | worktree | |
|---|---|---|
| 役割 | 変更履歴を分ける | 作業場所を分ける |
| フォルダ | 基本1つ | 複数作れる |
| 同時作業 | branch切替が必要 | 同時に開ける |
| PR・マージ | branch単位 | worktree内のbranch単位 |
| AI並列開発 | △ | ◎ |
重要なのは、
worktreeはbranchの代わりではない
という点です。
基本的には、
branch + worktreeで使います。
なぜAI駆動開発と相性がいいのか
人間だけで開発していたときは、
作業
↓
commit
↓
branch切替
↓
次の作業でも大きな問題はありませんでした。
ところがAIエージェントを複数動かすと、
Agent A → ログイン実装中
Agent B → 検索実装中
Agent C → テスト作成中となります。
1つのフォルダを共有すると、
- AIが編集中なのにbranchを切り替える
- 未コミット変更が残る
- 同じファイルを複数AIが書き換える
- AIが認識している状態と実際のファイルがズレる
といった問題が起きやすくなります。
worktreeなら、
Agent A → project-login/
Agent B → project-search/
Agent C → project-test/と作業場所を分離できます。
これはAI並列開発ではかなり大きなメリットです。
基本的な使い方
たとえばmainからログイン機能を作るなら、
git worktree add -b feature/login ../project-login mainとします。
すると、
project/
→ main
project-login/
→ feature/loginという2つの作業場所ができます。
一覧は、
git worktree listで確認できます。
作業終了後は、
git worktree remove ../project-loginで削除します。
必要であればbranchも削除します。
git branch -d feature/loginAI開発では「1作業 = 1branch = 1worktree」
運用ルールとして分かりやすいのが、
1 Issue
=
1 branch
=
1 worktree
=
1 AI Agentです。
たとえば、
Issue #123
ログイン機能追加
↓
feature/123-login
↓
worktrees/123-login/
↓
AI Agent Aという形です。
これなら、
「どのAIが何を触っているのか」
がかなり分かりやすくなります。
なお、worktreeを増やすとDocker側で別の問題が出ることがあります。詳しくは並行開発で増えすぎるDockerネットワークの対処をご覧ください。
worktreeを使っても競合はなくならない
ここは注意が必要です。
worktreeで防げるのは、
同じ作業フォルダを複数人・複数AIが同時に触る問題
です。
一方で、
feature/login
→ user.tsを変更
feature/profile
→ user.tsを変更のように、別branchから同じコードを変更すれば、マージ時に競合する可能性があります。
つまり、
作業中のファイル衝突
→ worktreeで分離
変更履歴の衝突
→ merge時に解決です。
worktreeを使えばmerge conflictがなくなる、というわけではありません。
マージ方法は普通のGitと同じ
worktreeだから特別なマージ方法が必要になるわけではありません。
基本は、
実装
↓
commit
↓
push
↓
Pull Request
↓
レビュー
↓
mainへmergeです。
マージするのはworktreeではなく、
worktree内で作業しているbranch
です。
並列化しすぎないことも重要
AIを使うと何でも並列化したくなりますが、依存関係が強い作業には向きません。
たとえば、
① DB変更
↓
② API実装
↓
③ 画面実装のような作業は、無理に同時に進めるより順番に進めたほうが安全です。
逆に、
ログイン機能
検索機能
ドキュメント更新
独立したテスト追加のように独立性が高ければ、worktreeを使った並列開発が効果的です。
重要なのは、
AIをたくさん動かすことではなく、独立した仕事を安全に並列化すること
です。
どこまで並列化するかの判断基準は、AIに一度に任せすぎないための8つの原則でも触れています。
まとめ
branchとworktreeの違いは、まずこれだけ覚えておけば大丈夫です。
branch
= 変更履歴を分ける
worktree
= 作業場所を分けるAI駆動開発では、
Issue
↓
branch
↓
worktree
↓
AI Agent
↓
Pull Requestという形にすると、並列開発を整理しやすくなります。
特におすすめしたいルールは、
1作業
=
1branch
=
1worktree
=
1Agentです。
AIによってコードを書く速度が上がるほど、
複数の変更をどう安全に分離し、最後に統合するか
が重要になります。
Git worktreeは、そのための地味ながら非常に強力な仕組みです。
こうした並行開発の進め方を含めて開発をお任せいただくこともできます。生成AI仕様駆動開発による受託開発をご覧ください。
