git worktree で開発するのが、現時点の最適解である

AI 時代の開発に、隔離された作業環境が必要になった

AI コーディングエージェントが実用段階に入った 2025 年後半から、ある問題が顕在化した。エージェントが作業する場所をどう確保するか、という問題だ。

人間が 1 人で開発しているなら、作業ディレクトリは 1 つでいい。だがエージェントを並列に走らせたい場合、同じファイルを複数のプロセスが同時に書き換える衝突が起きる。Docker、VM、クローン、worktree——選択肢はいくつかあるが、現時点で最もバランスが良いのは git worktree だ。

この記事では、git worktree の基本から、Claude Code での具体的な活用方法、そして業界全体のトレンドまでを整理する。

git worktree とは何か

git worktree は、1 つのリポジトリから複数の作業ディレクトリを作る仕組みだ。Git 2.5（2015 年）で導入された公式機能で、特殊なツールやプラグインは不要。

通常、git clone したリポジトリには作業ディレクトリが 1 つだけある。ブランチを切り替えるには git checkout や git switch を使い、そのたびにファイルが書き換わる。worktree を使うと、同じリポジトリに対して別のディレクトリを追加し、それぞれ異なるブランチをチェックアウトできる。

公式用語と仕組み

git の用語では、git init や git clone で最初に作られるものを メイン worktree (main working tree) と呼ぶ。これは削除できない。git worktree add で追加するものを リンク worktree (linked working tree) と呼ぶ。

リンク worktree のディレクトリを覗くと、.git がディレクトリではなくファイルになっている。中身は gitdir: /path/to/main/.git/worktrees/<name> のようなポインタで、メイン worktree の .git ディレクトリを参照している。つまり、オブジェクトストア（コミット履歴やファイルの実体）はすべて共有される。新たにコピーされるのはチェックアウトされた作業ファイルだけだ。

なぜ軽量か

200MB のリポジトリを 5 つクローンすれば 1GB のディスクを消費する。だが worktree なら、オブジェクトストアの 200MB は共有したまま、作業ファイル分だけが追加される。軽量なサンドボックスと呼べる所以だ。ここでいう「サンドボックス」とは、外部に影響を与えない隔離された作業領域のことを指す。ただし worktree が隔離するのはファイルシステム（チェックアウトされたファイル群）であり、プロセスやネットワークの隔離は行わない。

起動も速い。git worktree add ../feature-auth feature-auth と打てば、数秒で新しい作業ディレクトリが生まれる。

ブランチの排他制御

安全機構として、同じブランチを 2 つの worktree で同時にチェックアウトすることはデフォルトでは拒否される。--force で上書きは可能だが、通常はこの制約に従うことで、2 つの場所で同じブランチを編集して衝突するという事故を防げる。

主要コマンド

# worktreeを追加（新しいブランチを作成してチェックアウト）
git worktree add ../my-feature -b my-feature-branch

# 既存ブランチでworktreeを追加
git worktree add ../hotfix hotfix-branch

# 一覧を表示
git worktree list

# 不要になったworktreeを削除
git worktree remove ../my-feature

これだけ知っていれば、worktree は使える。「使い捨てのブランチ付き作業ディレクトリを一瞬で作れる」と覚えておけばいい。

なぜ今、worktree なのか

worktree 自体は 2015 年からある機能だ。なぜ今になって注目されるのか。答えは明確で、AI コーディングエージェントが並列実行を必要とするようになったからだ。

エージェントに「認証機能を実装して」と「テストを書いて」を同時に頼みたい場合、それぞれが独立したファイルシステムを必要とする。片方がファイルを書き換えている最中にもう片方が同じファイルを読めば、不整合が生じる。

では、隔離メカニズムの選択肢を比較してみよう。

メカニズム	重さ	起動時間	ディスクコスト	プロセス隔離	適した用途
git worktree	最軽量	秒	作業ファイルのみ	なし	同一リポジトリの並列作業
git clone	中程度	分（大規模リポジトリ）	リポジトリ全体の複製	なし	独立したリポジトリ
Docker	重い	秒〜分	OS＋依存関係＋リポジトリ	完全	環境ごとの隔離
フル VM	最重量	分	OS 全体	完全	完全な隔離

プロセスレベルの隔離が不要な「同じリポジトリでのコード編集」という用途なら、worktree が圧倒的に軽い。

Claude Code における worktree 実装

Claude Code は Anthropic が提供する CLI ベースの AI コーディングエージェントだ。ターミナルから claude コマンドで起動すると対話セッションが始まり、ファイルの読み書き、コマンド実行、git 操作などを自律的に行う。Claude Code には「ツール」と呼ばれる内部機能があり、エージェントが必要に応じて自動的に呼び出す。worktree 関連のツールもその一部だ。

3 つの利用方法

a) `--worktree`（`-w`）CLI フラグ（v2.1.49 以降）

最もシンプルな方法。起動時にフラグを付けるだけだ。

# 名前を指定して起動
claude --worktree feature-auth

# 名前を自動生成して起動
claude -w

これにより <リポジトリ>/.claude/worktrees/<name> に worktree が作成され、デフォルトのリモートブランチから worktree-<name> というブランチが切られる。作業が終わって /exit すると、変更がなければ worktree とブランチは自動で削除される。変更があれば、残すか削除するか聞かれる。

.claude/worktrees/ を .gitignore に追加しておくと管理が楽だ。

b) EnterWorktree ツール（セッション途中から）

すでに Claude Code のセッションが始まっている状態で「worktree で作業して」と伝えると、エージェントが EnterWorktree ツールを自動的に呼び出す。ユーザーがコマンドを打つ必要はない。--worktree フラグとの重要な違いは、ブランチの起点がデフォルトリモートブランチではなく現在の HEAD（今チェックアウトしているコミット）になる点だ。つまり、今の作業状態を基点にした worktree が作られる。

c) サブエージェントの isolation 設定（v2.1.49 以降）

Claude Code はタスクを分割してサブエージェント（特定の作業を担当する下位の AI エージェント）に委譲できる。このサブエージェントの設定に isolation: worktree を指定すると、各サブエージェントが自動的に専用の worktree を取得する。

サブエージェントの作業が終わり、変更がなければ worktree は自動クリーンアップされる。「エージェントに worktree を使わせて」と Claude Code に伝えるだけでもよい。

ExitWorktree ツール（v2.1.72、新機能）

セッションを終了せずに worktree から抜けるツール。action パラメータで “keep”（残す）か “remove”（削除）を指定する。未コミットの変更がある状態で “remove” を選ぶと安全のため拒否されるが、discard_changes: true を指定すれば強制削除できる。

EnterWorktree で作成された worktree にのみ有効で、worktree セッション外で呼んでも何も起きない。

フック：WorktreeCreate / WorktreeRemove（v2.1.50 以降）

WorktreeCreate フックを設定すると、worktree 作成時のデフォルトの git 動作を置き換えられる。これにより、SVN や Perforce など git 以外のバージョン管理でも worktree 相当の仕組みを実現できる。フックは作成した worktree の絶対パスを標準出力に出力する必要がある。WorktreeRemove はその逆で、クリーンアップ時に呼ばれる。いずれも type: "command" のみサポートしている。

`/exit`時の動作

worktree セッションで /exit すると、以下のように動作する。

変更なし: worktree とブランチが自動で削除される（通知なし）
変更あり: 残すか削除するかの選択肢が表示される

これは --worktree フラグ、EnterWorktree、どちらで作成した場合も同じだ。

worktree と連携する他の機能

/resume コマンドは、同一リポジトリのすべての worktree からセッションを一覧表示する
ステータス行に worktree の情報（名前、パス、ブランチ、元のリポジトリ）が表示される
カスタムエージェントやスキルは、worktree ディレクトリからも正しく検出される（v2.1.47 で修正済み）

実際の生産性への影響

多摩川機構エンジニアリング株式会社では、代表取締役が唯一のエンジニアとして worktree ベースのワークフローを Claude Code と組み合わせて運用している。体感として、生産性は約 3 倍に向上した。

この「3 倍」の内訳は、AI の処理速度ではない。人間の待ち時間がなくなったことが大きい。

従来のワークフローでは、AI にタスクを渡したら完了を待つしかなかった。worktree を使うと、AI が worktree A で機能実装をしている間に、人間はメイン worktree でコードレビューや設計作業を進められる。AI が終わったら結果を確認し、次のタスクを渡す。stash も checkout も不要で、コンテキストスイッチが発生しない。

AI が速くなったのではなく、人間が暇でなくなった。 これが worktree ベースの並列開発の本質だ。

業界の潮流：隔離環境は当たり前になった

worktree は Claude Code 固有の話ではない。2025 年後半から 2026 年にかけて、主要な AI 開発ツールはすべて何らかの形で隔離環境を採用している。

Cursor Cloud Agents: エージェントごとにフルの Ubuntu VM を割り当てる。社内のマージ済み PR の 35% がエージェント由来と公表されている
Codex CLI: OS レベルのサンドボックス（Linux では seccomp と landlock、macOS では Seatbelt によるセキュリティ制限）を採用。クラウド版では隔離されたコンテナで各タスクを実行する
Claude Code: git worktree による最軽量のアプローチ
Devin: クラウド上にワークステーション級のフルサンドボックスを提供。実運用での PR マージ率の高さが報告されている
Replit Agent: コンテナと Copy-on-Write スナップショットの組み合わせ
OpenHands: セキュリティ設定を強化した Docker コンテナで動作する

アプローチは異なるが、方向性は同じだ。隔離環境はもはやオプションではなく、AI 支援開発の前提条件になった。

この先に来るもの：隔離の次はマージ、マージの次は一貫性

worktree で隔離の問題は解決した。だが、エージェントを増やせば増やすほど、別の問題が浮上する。ボトルネックは隔離→マージ→タスク分割→意味的一貫性の順に移動していく。

第一の壁：マージと意味的衝突

エージェント 3 体を並列に走らせたとする。それぞれが worktree で隔離されているから、作業中の衝突はない。だが作業が終わった瞬間、3 つのブランチをマージしなければならない。

ここで問題になるのは、git のテキストレベルのコンフリクトだけではない。意味的な衝突だ。エージェント A が関数のシグネチャを変え、エージェント B が旧シグネチャで呼び出しコードを書いている。git はコンフリクトを検出しない。ビルドして初めてエラーになる。あるいはビルドは通るが、実行時に壊れる。

エージェントが 2〜3 体なら人間がレビューで拾える。だが 10 体、20 体と増えた場合、マージの組み合わせが爆発する。3 ブランチなら 3 通りの衝突可能性だが、30 ブランチなら 435 通り（30C2）になる。

第二の壁：worktree が隔離できないもの

worktree はチェックアウトされたファイルを隔離する。だが、ソフトウェア開発には worktree では隔離できない共有状態がある。

ロックファイル（package-lock.json、yarn.lock）。エージェント A が zod を追加し、エージェント B が ajv を追加する。それぞれの worktree ではロックファイルは整合するが、マージ時にバイナリ非互換になる。「消して再生成」すれば推移的依存が暗黙にアップグレードされ、別の場所が壊れる
データベースマイグレーション。3 体のエージェントが全員 migration_042 を作る。番号の衝突は機械的に直せるが、実行順序の依存関係——エージェント C の外部キーがエージェント A の追加カラムに依存する、など——は自動検出できない
ポートやプロセス。開発サーバーのポート 3000、共有データベース、ビルドキャッシュ。worktree はファイルシステムを隔離するが、プロセスやネットワークは隔離しない。30 体のエージェントが同時にテストを走らせれば、ポート競合やレート制限に引っかかる

これらの問題は、エージェントが 3 体のうちは手作業で対処できる。だが並列数が増えれば、ロックファイル専任エージェントやマイグレーション直列化キューのような仕組みが必要になる。

第三の壁：タスク分割

マージの痛みを減らすには、そもそも衝突しないようにタスクを分割するしかない。

Cursor が FastRender プロジェクトで約 2,000 の並列エージェントに Web ブラウザ（約 100 万行）を構築させたとき、最初にフラットな協調（全エージェントが対等に連携）を試みて失敗した。20 体のエージェントが 2〜3 体分のスループットしか出せなかった。機能したのは Planner-Worker-Judge の階層構造——計画者がタスクを分割し、作業者が実行し、審判者が整合性を検証する構造だ（Cursor 社ブログ）。

Anthropic の C コンパイラプロジェクトでも、16 の並列 Claude インスタンスが約 10 万行の Rust コードを生成したが、エージェント同士が互いの修正を上書きしてしまう問題が発生した。解決策は、GCC をオラクル（正解判定器）として使うランダム化されたタスク割り当てと、重複コードを統合する専任エージェントの設置だった（Anthropic ブログ）。

スループットの実効上限も見えてくる。機能が DB スキーマ、API コントラクト、UI の状態、アナリティクスにまたがるなら、有効に並列化できるのは 3〜4 体まで。5 体目は重複作業とレビュー負荷を増やすだけだ。並列化の上限はエージェント数ではなく、独立してテスト可能な接合面の数で決まる。

本当のボトルネック：意味的一貫性

タスク分割がうまくいっても、最後に残る問題がある。30 体のエージェントが作ったコードが、1 つのシステムとして一貫しているか、だ。

FastRender のコードを SIG（Software Improvement Group）が分析した結果、保守性スコアは 5 段階中 1.3——下位 5% だった（SIG 分析）。ブラウザとしては動く。だがコードベースとしては、密結合で、モジュール性が低く、保守できない。2,000 のエージェントがそれぞれ局所的に正しい判断をした結果、全体としては誰も設計していないシステムが生まれた。

これが起きるメカニズムは明確だ。

重複の発生。エージェント A が src/utils/string.ts に slugify() を書く。エージェント B が独立に src/helpers/text.ts に slugify() を書く。どちらもテストに通る。マージ後、コードベースに微妙に挙動の異なる 2 つの slugify が残る
規約のドリフト。エージェント A は userId、B は user_id、C は authorId と名付ける。同じ概念を指している。リンターは通る。テストも通る。だがコードを読む人間には 3 つの流儀が混在して見える
設計思想の分裂。エージェント A はエラーを Result 型で返す。B は例外をスローする。C はエラーコードを返す。各サブシステムは内部的に一貫している。だが呼び出し側は、関数ごとにどのエラーハンドリング規約が使われているか知る方法がない

Anthropic のコンパイラプロジェクトが重複コード統合専任エージェントと設計批評専任エージェントを設置したのは、この問題が「プロンプトを改善すれば解決する」類のものではなく、並列開発の構造的な帰結だと認識したからだ。

エージェントには記憶がない

人間のチームは、コードレビューや日常の会話を通じて暗黙の規約を共有する。「うちではエラーは Result 型で返す」「この名前空間は触るな」といった知識が、チームの中に蓄積される。

エージェントにはこれがない。各セッションがゼロから始まる。 CLAUDE.md やプロジェクト設定で文脈を注入しても、コンテキストウィンドウには限りがある。プロジェクトが成長するにつれ、「なぜこうしているか」の履歴がエージェントに伝わらなくなる。

これは単にコンテキストが足りないという量の問題ではない。学習が蓄積しないという質の問題だ。人間のチームでは、コードレビューのフィードバックが次の開発に反映される。エージェント A のレビューで指摘された問題を、エージェント B は知らない。同じ間違いが何度も繰り返される。フィードバックをテストやリントルールに変換しない限り、永遠に同じ制約をプロンプトに書き続けることになる。

ボトルネックの全体像

整理するとこうなる。

隔離 — worktree やコンテナで解決済み（この記事の主題）
マージ — 並列数が増えると意味的衝突が増える。人間のレビューではスケールしない
タスク分割 — 衝突を最小化する分割戦略。独立してテスト可能な接合面の数が並列化の上限を決める
意味的一貫性 — コードが動くだけでなく、1 つのシステムとして一貫しているか。現時点で最も困難な課題
記憶と学習 — プロジェクトが時間とともに蓄積する知識を、ステートレスなエージェントにどう伝えるか。未解決の領域

エンジニアの役割は、「コードを書く人」から「エージェントを指揮する人」へ移りつつある。worktree が隔離を当たり前にした今、次に問われるのは分割と一貫性の技術だ。どのタスクは並列化できて、どのタスクは直列にすべきか。どうすれば 30 体のエージェントが、30 個のバラバラなシステムではなく、1 つの一貫したシステムを作れるか。

あるいは、こういう見方もできる。並列化は、現在のモデルの限界——限られた推論能力、限られたコンテキスト——を補うための過渡的なアプローチかもしれない。十分に賢く、十分に大きなコンテキストを持つ単一のエージェントが実現すれば、調整コストも一貫性の問題もゼロになる。その日が来るかどうかはわからないが、少なくとも今は、worktree で並列化しつつ一貫性を保つ方法を探る段階にある。

まとめ

今日の時点で、git worktree は AI 支援開発における最適なバランスポイントだ。

軽量で即座に使える。ディスクを浪費しない。クラウドインフラもコンテナも特別なセットアップも不要。git worktree add と打つだけで、隔離された作業環境が手に入る。

だが、隔離は出発点に過ぎない。エージェントの数が増えれば、マージ、タスク分割、そして意味的一貫性——30 体のエージェントが 1 つのシステムを作れるか——が順番にボトルネックになる。worktree が「隔離」を当たり前にしたように、次は「一貫性」を当たり前にする仕組みが求められている。

特別な技術ではない。git の標準機能だ。だからこそ、どこでも、誰でも、今すぐ使える。そして、その先の課題に取り組む土台になる。