Claude Codeセッションを次々と実行することは、習慣であり要件ではありません。タスクが本当に独立している場合、一方が他方を待つ理由はありません。Gitワークツリーは、各Claudeセッションに独自のチェックアウト済みディレクトリを独自のブランチ上で付与し、すべて同じ.gitオブジェクトストアから利用します。重複したクローンなし、ファイル競合なし、完了時に標準的なgitマージを実行します。このポストでは、ワークツリーが役に立つ場合、セットアップ方法、実際に得られる分離（および得られない分離）、およびコミットされていない作業を失わずにクリーンアップする方法について詳しく説明します。
ワークツリーが役に立つ場合
すべてのタスクに必要というわけではありません。正直に言うと、ワークツリーはかなり限定的な状況で活躍します。
bri による YouTube ウォークスルー（2026年6月）でよく説明されています。2つ以上のタスクが同じファイルを共有しない場合、またはタスクがリスキーで、どちらかに確定する前に2つの異なるアプローチを確認したい場合にワークツリーを使用します。単一のタスクがコードベース全体にまたがる場合は、1つのセッションにとどまります。エージェントが自由に動き回りたい探索的な作業にも同じことが言えます。
もう1つの優れた使用例は、投機的な作業です。3つのワークツリーをスピンアップし、各々に同じ問題に対して少し異なるプロンプトを与え、気に入ったバージョンを選びます。Zylos Researchは、このパターンが4つ以上の並列AI セッションを実行しているチームで一般的になったと指摘しており、これは単一パスに依存するのではなく、非決定論的モデル出力に対してヘッジしているためです。
逆に、大規模なTypeScriptモノレポ、PostgreSQL、Redis、複数の内部パッケージ、Remixフロントエンドを含むプロジェクトの場合、ワークツリーだけではコーディネーション上の問題は解決できません。Trigger.devはこれについて書き、最終的に別のアプローチに移行しました。ファイルシステムの分離は実在します。サービスの分離は自動的ではありません。
分離されたタスク用チェックアウトを作成
ベースブランチから始めて最新版をプルします。次に.claude/worktreesを.gitignoreに一度追加します：
echo ".claude/worktrees" >> .gitignore
Claudeはデフォルトでワークツリーをリポジトリディレクトリ内に配置します。その.gitignoreエントリがなければ、追跡されていないファイルとして表示され、git statusを乱雑にします。それを追加してコミットしたら、忘れてしまいます。
次に、タスクごとにセッションをスピンアップします。2つのターミナルを開きます：
claude --worktree feature-payments
``
claude --worktree bugfix-auth
Dan Does Codeの記事によれば、Claudeは.claude/worktrees/feature-payments/にワークツリーを作成し、新しいブランチをチェックアウトし、セッションをそのディレクトリにスコープします。メインの作業ツリーは全体を通じてそのままです。短いフラグ形式のclaude -w feature-paymentsも使用できます。名前を完全にスキップするとClaudeが自動生成します。
各セッションは完全なファイルシステムの分離で動作します。ターミナル1のエージェントは、ターミナル2のエージェントが作業しているファイルに触れることはできません。異なるディレクトリの異なるブランチにあるからです。これが全体のトリックです。エージェント間の調整ロジックではなく、インフラストラクチャレベルの分離です。（代わりにそれを求めている場合は、Claude Codeサブエージェントガイドがオーケストレーション側をカバーしています。）
各セッションにタスクを割り当て
両方のセッションが実行されたら、各々に指示を与えます。各Claudeインスタンスを新しいコンテキストとして扱います。スコープについて具体的に説明します。ターミナル1が支払い機能を構築している場合、どのファイルに触れるべきか、どのファイルを放置すべきかを指定します。ターミナル2についても同じです。
セッションが終了したら、ターミナルを閉じる前にClaudeにブランチをプッシュしてプルリクエストを開くよう指示してください。そうすることで、作業がローカルマシンから安全に離れ、レビュー準備が整います。
依存関係、ポート、ローカル設定を管理する
ここが面倒なところです。ファイルシステムの分離は自動ですが、それ以外はすべて手動設定が必要です。
ポート。両方のワークツリーが開発サーバーを起動した場合、デフォルトでは同じポートで衝突します。解決策は、各ワークツリーに異なるポート割り当てを持つ独自の.envファイルを用意することです。例えば、一方にはPORT=3001、もう一方にはPORT=3002のように指定します。または起動時にインラインでオーバーライドを渡してもかまいません。どちらでも機能します。
データベース。SQLiteは簡単です。各ワークツリーの.envを異なるファイルパスに指すだけです。PostgreSQLやMySQLはもっと考慮が必要です。ワークツリーごとに独立したデータベースインスタンスか、最低でも同じインスタンス内の独立したスキーマ/データベースが必要です。各ワークツリーの.env環境変数経由で接続文字列を設定してください。2つのエージェントが同時にマイグレーションを書き込むデータベースは共有しないでください。それはデータ破損またはレース条件を招きます。
ローカル設定ファイル。プロジェクトがコミットされていないローカル設定ファイル（.env.localやconfig/local.ymlなど）を使用している場合、ワークツリーごとに1つ作成する必要があります。メインワーキングツリーから自動的に継承されません。
MindStudioのパラレルAIコーディングエージェントガイドでは、これらの分離パターンについてより詳しく説明しています。要点は以下の通りです。ワークツリーは設計によってブランチとディレクトリの分離を提供します。データベースとポートの分離には、事前の明示的な設定が必要です。
もう1つ指摘する価値がある点があります。複雑で高コストなローカルサービスセットアップを持つプロジェクトで複数のワークツリーを実行している場合、セットアップコストがパラレル高速化の価値があるかどうか検討してください。ライブラリやCLIツールの場合は絶対にそうです。6つのサービスを持つフルスタックモノレポの場合はそうではないかもしれません。スコーピングに関するヘルプが必要な場合、Claude Code開発者があなたのスタックにワークツリーまたは別のパラレル戦略が適しているかどうかを評価できます。
両方のブランチをレビューして統合する
両方のエージェントが終了しました。両方のブランチがプッシュされました。これでレビューです。
ここでのワークフローは標準的なgitです。パラレルセットアップはマージプロセスをまったく変えません。典型的な2タスクリポジトリの番号付きシーケンスです。
mainをチェックアウトして最新をプル。- 最初のブランチをレビュー。
git diff main..feature-paymentsで何が変わったかの全体像が見えます。 - 満足したら、
mainにマージまたはリベース。ベースブランチとの競合を通常通り解決してください。 mainを再度プルしてその変更を取得。- 2番目のブランチをレビュー。
git diff main..bugfix-auth。 - マージ。2つのエージェントが重複するファイルに触れた場合（タスクを正しくスコープしていれば起こるべきではありませんが、時には起こります）、ここで競合を解決してください。
- 両方のマージが
mainに含まれたら、mainに対してテストスイートを実行。
このように順序立ててレビューする利点は、1つのマージからの競合が次に複合しないということです。よりシンプルなdiff、より簡単な推論。
コミットされていない作業を失わずにクリーンアップ
クリーンアップは開発者が不安になるところです。ワークツリーにコミットされていない作業があったらどうしよう？
答え：ワークツリーを削除する前にそれをスタッシュしてください。
ワークツリーに保留中の変更があって保持したい場合は、そのワークツリーディレクトリに移動して以下を実行してください:
git stash push -m "wip: payments feature - pre-cleanup"
そのスタッシュは共有 .git オブジェクトストア内に存在するため、元のワークツリー削除後も、メインワーキングツリーまたは他のワークツリーからアクセスできます。スタッシュ後、安全に削除できます:
git worktree remove .claude/worktrees/feature-payments
次に、メインワーキングツリーに戻ってスタッシュをポップします:
git stash pop
実験が完全に失敗してそこから何も必要ない場合は、スタッシュせずに削除してください。git worktree remove に --force フラグを付けると、未コミットの変更があってもワークツリーを削除します。--force を使う前に確認してください。復旧方法はありません。
すべてのワークツリーを削除した後、リストをプルーンして整理します:
git worktree prune
これにより .git/worktrees/ から古い管理参照が削除されます。
ワークツリーが分離しない共有リソース
このことについて明確に述べる価値があります。「分離」という心的モデルが誤解につながる可能性があるためです。
ワークツリーが分離するもの:
- ワーキングディレクトリとその中のすべてのファイル
- 各セッションが操作するブランチ
- ステージされた変更と未ステージの変更
ワークツリーが分離しないもの:
.gitオブジェクトストア(設計上共有)- マシンローカルの自動メモリ(公式メモリドキュメントでは、同一リポジトリのワークツリーがこれを共有していることが確認されています)
- 外部サービス: データベース、キュー、キャッシュ、ネットワーク依存関係
- 環境認証情報と API キー(ワークツリーごとに異なる値を明示的に設定しない限り)
- 両セッションが継承する OS レベルシェル環境のすべて
これはセキュリティにも関係しています。ワークツリーはテナント境界ではありません。両セッションが同じ API キーまたはデータベース認証情報を共有している場合、アクセスも共有されます。ワークツリーを Claude セッションをローカル設定から分離するサンドボックスとしては扱わないでください。そうではありません。
ファイルシステム分離だけでなく、より広いワークフロー全体で複数のエージェントを調整する場合、Claude Code スーパーパワーのポストではより広いパターンについて説明しています。
FAQ
`claude --worktree` は `git worktree add` を手動で実行するのと同じように機能しますか?
機能的には似ていますが、完全には同じではありません。claude --worktree は git worktree add を実行して、ブランチを作成し、Claude セッションをそのディレクトリにスコープする処理を 1 ステップで行います。git worktree add を手動で実行してから、その結果のディレクトリ内で Claude を開始した場合、ファイルシステムの結果は同じですが、Claude の組み込みスコープなしです。--worktree フラグは一般的な場合の高速パスです。
一度に 3 つ以上のワークツリーを実行できますか?
はい。git や Claude Code によって課される厳密な制限はありません。実用的な制限は機械の RAM と CPU です。各 Claude セッションは独立したプロセスであり、独自のコンテキストを持ちます。最新の開発マシンで同時に 3 つまたは 4 つのセッションを実行するのは問題ありません。それ以上になると、git の制限に達する前に、リソース制約に達している可能性があります。
ワークツリーを削除すると、そのブランチはどうなりますか？
ブランチは残ります。git worktree remove を実行すると、作業ディレクトリと .git/worktrees/ 内の管理用参照が削除されますが、ブランチ自体は残り、メインの作業ツリーや他のワークツリーからアクセス可能です。ブランチが不要になったら git branch -d branch-name で個別に削除します。
ワークツリーは Claude が CLAUDE.md プロジェクトメモリを読み書きする方法に影響しますか？
同一リポジトリ内のワークツリーは、公式メモリドキュメントに従ってマシンローカルの自動メモリを共有します。CLAUDE.md ファイルがリポジトリにコミットされている場合、各ワークツリーは自身がチェックアウトしたコピーから読み込みます。あるエージェントがそのワークツリー内の CLAUDE.md に加えた編集は、マージされるまでそのブランチに限定されます。ただし、マシンローカルレイヤーは共有されるため、あるセッションで書き込まれた指示は別のセッションから見えます。
ワークツリーを実行する場合、別々のクローンと比べてパフォーマンスコストはありますか？
ワークツリーはクローンより低コストです。.git オブジェクトストアを共有するため、ディスク上でリポジトリ履歴全体が複製されることはありません。主なコストは作業ディレクトリそのもので、これはブランチの現在の状態にある追跡ファイル全体のフルチェックアウトです。バイナリアセットまたは生成ファイルを含む大規模なリポジトリの場合、そのチェックアウトサイズは増加する可能性があります。ただし、git 操作（fetch、log、diff）はすべて単一のオブジェクトストアに対して実行されるため、速度は速いです。
ワークツリーを別々のクローンより推奨する最も明確な理由は、あるワークツリーで作成されたスタッシュと参照は、同じリポジトリ内の他のすべての場所で即座にアクセス可能だという点です。この共有状態は、上記のクリーンアップワークフローが機能する理由そのものです。