先日、とある方に相談していたことがあります。worktreeです。
AIがですね、ガシガシ使おうとするのです。ブランチ戦略だけでも、少し注意が必要だったのに、wokrtreeまでメンバーに伝えるのは、ちょいと大変。そもそも私も大変です。
ですが、現実を見ると、もはや待ったなし。ということで、一旦まとめてみることにしました。
目次
git worktree とは
git worktreeは Git 2.5（2015年）で追加された標準機能です。外部ツールではなく、Gitに組み込まれた機能なので、特別なインストールは不要です。以前は、私自身外部ツール？と勘違いしていたくらい、あまり使っていない機能でした。
# Git本体のコマンドとして存在
$ git worktree list
$ git worktree add
$ git worktree remove
ブランチと Worktree の違い
ここが混乱しやすいポイントです。
ブランチ = Git内部の「線」（論理的）
リポジトリ内の履歴
main ●───●───●───●
↑
develop ●───●───●───●───●───●
↑
feature ●───●───●───●───●───●───●
ブランチは Git が管理する履歴の分岐 です。目に見えるフォルダではありません。
Worktree = 実際のフォルダ（物理的）
Finder / エクスプローラで見える状態
~/projects/
├── my-app/ ← Worktree 1（developをチェックアウト中）
│ ├── src/
│ ├── package.json
│ └── .git/ ← 本体の.gitがここにある
│
├── my-app-feature-auth/ ← Worktree 2（feature/authをチェックアウト中）
│ ├── src/
│ ├── package.json
│ └── .git (ファイル) ← 本体を参照するリンク
│
└── my-app-hotfix/ ← Worktree 3（hotfix/loginをチェックアウト中）
├── src/
├── package.json
└── .git (ファイル) ← 本体を参照するリンク
Worktree は 物理的に別のフォルダ として存在します。
一言でまとめると
| 概念 | 何か | どこにある |
|---|---|---|
| ブランチ | 履歴の分岐線 | Gitの中（見えない） |
| Worktree | 作業フォルダ | ファイルシステム（見える） |
Worktree = 「ブランチを物理フォルダとして展開したもの」 と考えるとわかりやすいです。
「チェックアウト」とは
Worktreeを理解するには「チェックアウト」の概念も押さえておく必要があります。
チェックアウト = 「取り出して作業机に広げる」
【Gitリポジトリ = 倉庫】
倉庫の中には全ブランチの全履歴が保管されている
┌─────────────────────────────────┐
│ main の履歴 │
│ develop の履歴 │
│ feature/auth の履歴 │
│ ...（全部圧縮して保管中） │
└─────────────────────────────────┘
│
│ git checkout develop
↓
┌─────────────────────────────────┐
│ 【作業フォルダ = 作業机】 │
│ │
│ src/ │
│ package.json │
│ README.md │
│ │
│ ← develop の中身が展開されている │
└─────────────────────────────────┘
「チェックアウト中」とは、今作業フォルダに展開されているブランチのことです。
$ git branch
main
* develop ← * がついている = チェックアウト中
feature/auth
通常の運用 vs Worktree運用
通常（Worktreeなし）
~/my-app/ ← このフォルダ1つで全部やる
$ git checkout develop → フォルダの中身が develop に変わる
$ git checkout feature → フォルダの中身が feature に変わる
$ git checkout main → フォルダの中身が main に変わる
この方法の問題点は以下の通りです。
- 切り替えるたびに
npm installが必要になることも - 作業中のファイルを stash しないと切り替えられない
- 「今どのブランチ？」を常に意識する必要あり
Worktree運用
~/my-app/ ← 常に develop
~/my-app-feature/ ← 常に feature
~/my-app-hotfix/ ← 常に hotfix
メリットは明確です。
- 切り替え不要、フォルダを移動するだけ
- 各フォルダで別々のターミナル/エディタ/AIセッションを開ける
- 並列作業が物理的に可能
なぜ AI エージェントとの協働で有効なのか
ここが本題です。
セッションごとに文脈が分かれる
たとえば「検索機能のリファクタリング」と「決済機能の実装」という2つのタスクがあるとします。
~/my-project/ # develop ブランチ
~/my-project-search/ # feature/search-refactor
~/my-project-payment/ # feature/payment
それぞれ別のWorktreeで、別々のClaude Codeセッションを起動すると以下のようになります。
セッション1（検索機能）: 「このクエリの最適化について...」
セッション2（決済機能）: 「Stripeのwebhook処理について...」
→ 互いに干渉せず、それぞれの文脈で深い議論ができる
通常のブランチ切り替えでは、1つのフォルダで作業するため、AIセッションも1つになりがちです。Worktreeなら物理的にフォルダが分かれるため、複数のAIエージェントを同時に走らせる「擬似チーム開発」 が可能になります。
そして、私がもう一つ思うのは、物理的に分かれているので、壊れる心配が少ないということです。
基本的な使い方
Worktree の追加
# メインのリポジトリで作業中
cd ~/my-project
git branch # developにいることを確認
# featureブランチを作成してWorktreeを追加
git worktree add ../my-project-feature -b feature/new-function
これで ~/my-project-feature ディレクトリが作成され、feature/new-function ブランチがチェックアウトされます。
Worktree の一覧確認
$ git worktree list
/Users/yourname/my-project abc1234 [develop]
/Users/yourname/my-project-feature def5678 [feature/new-function]
作業完了後のクリーンアップ
# Worktreeを削除
git worktree remove ../my-project-feature
# ブランチも削除（マージ済みなら）
git branch -d feature/new-function
チームで運用する際の禁止事項
Worktreeを使ったチーム開発では、以下のルールを明確にしておくと事故を防げます。
Git操作の禁止事項
| 禁止事項 | 理由 |
|---|---|
| main への直接 push | 本番破壊リスク |
| main / develop への force push | 履歴破壊、他メンバーの作業が消える |
| 他人の feature ブランチへの無断 push | 作業衝突、責任の曖昧化 |
コミットの禁止事項
| 禁止事項 | 理由 |
|---|---|
| 動作未確認のままコミット | バグの混入 |
| 複数機能の一括コミット | revert が困難、履歴が追えない |
| 機密情報のコミット（APIキー等） | セキュリティ事故 |
AIエージェント関連の禁止事項
| 禁止事項 | 理由 |
|---|---|
| AI に勝手にコミットさせる | 意図しない変更の混入 |
| AI に勝手に push させる | 上記より深刻 |
| AI の出力をレビューせずマージ | 品質担保できない |
これらのルールは CLAUDE.md などに明記しておくと、AIエージェントにも伝わります。
まとめ
git worktreeは2015年から存在する機能ですが、AIエージェントとの協働が増えた今、改めて価値が見直されています。
- ブランチは論理的な履歴の分岐、Worktreeは物理的なフォルダ
- Worktreeを使えば、複数ブランチを同時に開いて並列作業できる
- AIエージェントごとに別のWorktreeを割り当てれば、文脈が混ざらない
- チーム運用では禁止事項を明確にして事故を防ぐ
個人開発でもチーム開発でも、AIエージェントを活用するなら知っておいて損はない機能です。