Gitワークツリー（Git worktree）とは、既存のGitリポジトリに紐付けられた追加の作業ディレクトリです。専用のチェックアウトブランチ、独自のインデックス、独立した未追跡ファイルを保持しながら、Gitのオブジェクトストア、参照（Refs）、全体設定はメインリポジトリと完全に共有します。並行して動作するAIコーディングエージェントにとって、これは理想的な隔離単位です：各エージェントは他者が書き込まない独立ディレクトリを持ち、専用のブランチにコミットを積み上げ、ディレクトリの作成は重いリポジトリクローンやコンテナ起動ではなく、一瞬のチェックアウト操作で完了します。本記事では、主要コマンド、なぜ共有ディレクトリよりもワークツリーが優れているのか、直面するトラブルパターン、そしてIvy Tendrilが計画ごとにワークツリーを自動生成・自動削除する仕組みを解説します。
ワークツリーの基本構造
通常、すべてのGitリポジトリはデフォルトで1つの作業ディレクトリを持ちます。git worktree addを実行することで、複数の作業ディレクトリを自由に追加できます。追加された各ディレクトリは完全なチェックアウト環境であり、cdで移動してコード編集、ビルド、コミットを自由に行えます。
# 1つ上の階層に新しいブランチでワークツリーを作成
git worktree add ../feature-x -b feature-x
# このリポジトリの全ワークツリーを一覧表示
git worktree list
# /Users/dev/app a1b2c3d [main]
# /Users/dev/feature-x a1b2c3d [feature-x]
新規作成されたディレクトリ内には、.gitディレクトリではなく.gitという単一のファイルが配置されます。このファイルはメインリポジトリ内の.git/worktrees/feature-xを参照しており、そこにインデックスとHEADポインタが格納されています。オブジェクト、参照、Gitフック、各種設定はすべてメインリポジトリから共有されます。../feature-x内で行われたコミットは、プッシュやフェッチを行うことなく、メインリポジトリからgit log feature-xですぐに参照可能です。
このアーキテクチャから2つの重要な制約が生じます：1つのブランチは同時に1つのワークツリーでしかチェックアウトできません（同一ブランチに対する重複チェックアウトはGitによって拒絶されます）。また、ワークツリーのパスはメインディレクトリの外部に配置する必要があります（内部にあるとメインリポジトリから未追跡ファイルとして誤認されるためです）。
なぜエージェントにとってワークツリーが最適なのか
コーディングエージェントはファイルを読み書きし、テストを実行し、コミットを行います。2つのエージェントが同一ディレクトリで同時に作業すると、混ざり合った差分（Diff）が生成され、各エージェントの変更のみを対象としたテスト実行が不可能になります。代替案としては、エージェントごとの完全クローン、個別Dockerコンテナ、またはGitワークツリーが挙げられます。
| アプローチ | 独立したツリーとブランチ | オブジェクトストア共有 | 起動オーバーヘッド | ランタイム分離 |
|---|---|---|---|---|
| 共有ディレクトリ | なし | あり | ゼロ | なし |
| エージェントごとの個別クローン | あり | なし（完全コピー） | 完全クローン＋依存関係再インストール | なし |
| エージェントごとのコンテナ | あり | なし（マウント時を除く） | イメージ取得＋コンテナ起動 | あり |
| エージェントごとのワークツリー | あり | あり | 一瞬のチェックアウトのみ | なし |
ワークツリーは、コーディング作業の正確性に必要な要素（専用ファイルツリーと専用ブランチ）を、仮想化ランタイムのような過剰なオーバーヘッドなしに提供します。オブジェクトストアが共有されるため、数年分の履歴を持つ巨大リポジトリであっても、消費されるのは現在のスナップショット1回分の領域のみです。pnpm、Cargo、NuGetなどのパッケージマネージャーのキャッシュもユーザーディレクトリ内で共有されます。
もちろん、システムパッケージのインストールやネットワークポートのバインドが必要な場合にはDockerコンテナが適しています。両者は排他的ではなく、ワークツリーをコンテナにマウントすることも可能です。一般的なコード修正、テスト、静的解析、コミット作業であれば、ワークツリー単体で完璧に機能します。
オーケストレーション全体の設計についてはエージェントオーケストレーションパターンもご参照ください。
よくある障害パターンと対策
ワークツリーはディレクトリの衝突を完全に解決しますが、以下の3つの問題には別途ルールが必要です。
1. 異なるブランチで同一ファイルを同時に編集する競合
ワークツリーはディレクトリを分離しますが、開発の意図までは自動調整しません。2つの計画が同時にauth/session.tsを変更した場合、それぞれのブランチは問題なくコミットされますが、後からマージする側で必ずコンフリクトが発生します。これは計画フェーズで検知すべき課題です：各タスクがどのモジュールに触れるかを事前に把握し、実行順序を整理するか、1つの計画がモジュール全体を所有するよう分割します。
2. 未コミットの残留ファイル（ダーティツリー）
エージェントが異常終了した場合やテストによって一時ファイルが生成された場合、ワークツリーに未コミットの変更が残ります。git worktree removeは安全のためダーティツリーの削除を拒否します。適切なオーケストレータの設計としては、エージェントが作成した変更を一度そのブランチに安全にコミットし、レビュー担当者が確認できる状態にしてから削除を実行します。
# 削除前に未コミット差分を確認
git -C ../feature-x status --short
# クリーンなワークツリーを削除
git worktree remove ../feature-x
# 不要と判断した場合の強制削除
git worktree remove --force ../feature-x
3. 放置された不要ワークツリーの蓄積
手動で作成したワークツリーは放置されがちです。ブランチをロックし続け、ディスク容量を消費します。万が一ディレクトリをgit worktree removeではなくrm -rfで削除してしまうと、Git内部に不整合な参照が残ってしまいます。
# クリーンアップ対象を事前確認
git worktree prune --dry-run --verbose
# 存在しないワークツリーの参照を破棄
git worktree prune
根本的な解決策は1つです：ワークツリーを作成したシステムが、ライフサイクルの明確なタイミングで責任を持って削除することです。
Ivy Tendrilにおけるワークツリー活用
Ivy Tendrilは、計画からレビュー済みプルリクエストまでを制御するローカルファーストのデスクトップアプリです。ワークツリーはその基本実行単位となっています。製品概要およびライフサイクルの定義も併せてご確認ください。
- 1計画につき1ワークツリー： 計画が承認されて実行に移ると、Tendrilは自動的にワークツリーと専用ブランチを生成します。多数の計画が同時実行されても、mainブランチは完全にクリーンに保たれます。
- ワークツリー内での自己完結検証： テスト、Linter、差分計算はそのツリー内だけで行われ、Review画面に直接レポートされます。
- マージ後の自動破棄： GitHub上でプルリクエストがマージされると、Tendrilが自動的にワークツリーをクリーンアップします。
- あらゆるエージェントに対応： Claude Code、OpenAI Codex CLI、Copilot CLI、Gemini CLI、OpenCodeなど、計画ごとにエージェントを選択可能です。
- 完全ローカル管理： ワークツリー、コード、計画、ログはすべてお手元のマシン上に保持されます。ローカルファーストAI開発をご覧ください。
Ivy Tendrilで開発を始める
Gitワークツリーによる強力な分離環境で、安全かつ高速な並行エージェント開発を体験してください：
- オープンソースコード: GitHubのIvy Tendrilリポジトリを確認
- 技術ドキュメント: tendril.ivy.appで詳細なガイドを閲覧
- エンジニアと相談: renco@ivy.appまで30分のテクニカルセッションをご予約ください