Claude Code Worktreeで並列開発を安全にブランチ分離する方法

Claude CodeはGit Worktreeを活用し、メインの作業ディレクトリを汚さずに別ブランチでの開発を並列実行できます。並列開発の安全性は、エージェントの賢さではなくディレクトリ構成という「仕組み」で担保するものです。

「AIに任せた作業とレビュー対応がぶつかって、どちらの変更か分からなくなった」「ブランチを切り替えるたびにstashして、戻すのを忘れて事故った」「複数のClaude Codeを同時に立ち上げたら、同じファイルを取り合って壊れた」——並列開発を試した現場から、こうした声をよく聞きます。

Git Worktreeとは、1つのGitリポジトリから複数の作業ディレクトリ（ワークツリー）を作成する機能です。作業がディレクトリ単位で分かれるため、複数のエージェントが同時に動いても通常の編集先が重ならず、ファイルの上書き競合を減らせます（コマンドで別のディレクトリへ書き込むことまでは防げません）。本記事では、この仕組みをClaude Codeの並列開発にどう組み込めるかを、設計の考え方から運用のルールまで整理します。内容は2026年10月時点のClaude Code公式ドキュメントに沿っています。

本記事は、Claude Codeの実践シリーズの一部です。AI活用の全体像はAI活用完全ガイドで解説しています。

この記事でわかること

Claude Codeを1つのウィンドウで使っていて、そろそろ並列で動かしたいと考えている開発者・開発リーダーの方に向けて、設計の考え方から運用のルールまでをまとめました。

• Git Worktreeの基本概念と従来のブランチ切り替えとの違い — git checkoutが作業ディレクトリを置き換えるのに対し、ワークツリーは別ディレクトリに展開します。この差が並列開発の可否を決めます。
• Claude Codeのワークツリー機能の仕組み — claude --worktree（-w）で、ワークツリーの作成からセッション開始までを1コマンドで行えます。サブエージェントを専用のワークツリーで動かす指定もあります。
• 実務での3つの活用パターンと使い分け — 複数エージェントの機能並列開発、レビュー待ち中の別作業、SDK経由の並列タスク実行の3つを、難易度順に整理します。
• 配置パターンの比較とクリーンアップの仕組み化 — プロジェクト外・プロジェクト内・隠しディレクトリの3パターンを表で比較し、ワークツリーが残骸化しない運用ルールを提案します。
• ワークツリーが向かないケースと共有リソースの落とし穴 — node_modulesや.envの扱い、同一ブランチを複数チェックアウトできない制約など、正直な限界を書きます。

最後まで読むと、自分のチームに合ったワークツリーの配置ルールとクリーンアップ運用を、自分で設計できるようになります。

Git Worktreeとは何か｜並列開発の前提を揃える

まず前提となる概念を整理します。Git Worktreeは、1つのGitリポジトリから複数の作業ディレクトリを作成する機能です。通常、Gitリポジトリには作業ディレクトリが1つしかありませんが、git worktree addコマンドで別のディレクトリに別ブランチをチェックアウトできます。この「1リポジトリ＝1作業場所」という暗黙の前提を外すことが、並列開発の出発点になります。

従来のブランチ切り替えとの違い

git checkoutによるブランチ切り替えとの違いを整理すると、次のようになります。

表の4行目が、この記事の核心です。人間が1人で作業している限り、git stashの運用ルールを徹底すれば何とかなります。しかしClaude Codeのようなエージェントが複数同時に動く環境では、ワークツリーによる物理的なディレクトリ分離が前提になります。同じディレクトリで複数のエージェントがファイルを変更すると、意図しない上書きが発生するためです。

「気をつける」ではなく「構造で防ぐ」という発想

並列開発の事故対策には、大きく2つのアプローチがあります。1つは運用ルールで防ぐ方法、もう1つは構造で防ぐ方法です。

私たちは一貫して、人の注意力に依存する運用より、仕組みで事故を起こせなくする設計をおすすめしています。ワークツリーは後者の典型で、「気をつける」を「通常の作業では起こりにくい」に変える仕組みです。属人的な注意力ではなく構造で担保されるため、チームに新しいメンバーが入っても同じ品質で回ります。

Excel管理の限界と同じ構図

この構図は、営業データをExcelで複数人管理しているときの問題とよく似ています。同じファイルを複数人が開いて編集すると、誰の変更が残ったのか分からなくなり、「最新版_最終_v3.xlsx」が量産されます。解決策は「気をつけて編集する」ではなく、レコード単位で排他が効くデータベースに移すことです。

ワークツリーも発想は同じで、作業の単位を物理的に切り分けることで、衝突そのものを構造から取り除きます。ツールは違っても、「共有資源への同時書き込みをどう設計するか」という課題の形は共通しています。

Claude Codeでのワークツリー自動活用の仕組み

ここからClaude Code側の挙動に入ります。Claude Codeには、ワークツリーを作成して、そこでセッションを始める機能が組み込まれています。2026年10月時点では、claude --worktree <名前>（短縮形は-w）で起動する方法と、セッション中に「ワークツリーで作業して」と頼む方法があります。

ワークツリー作成で何が起きるか

名前を付けて--worktreeで起動すると、リポジトリ直下の.claude/worktrees/<名前>/に作業ディレクトリが作られ、worktree-<名前>という新しいブランチでセッションが始まります。別のターミナルで別の名前を指定して起動すれば、2つ目の独立したセッションになります。名前を省略した場合は、Claude Codeがbright-running-foxのような名前を付けます。

claude --worktree feature-auth

セッション中に「ワークツリーで作業して」と頼んだ場合は、EnterWorktreeツールで同様に作成されます。ディレクトリ構成としては、次のような形になります。

メインディレクトリ: ~/project/
├── .git/                    ← 共有のGitオブジェクトDB
├── src/                     ← mainブランチの作業ディレクトリ
└── ...

ワークツリー: ~/project/.claude/worktrees/feature-auth/
├── src/                     ← worktree-feature-authブランチの作業ディレクトリ
└── ...

ワークツリー: ~/project/.claude/worktrees/fix-bug-123/
├── src/                     ← worktree-fix-bug-123ブランチの作業ディレクトリ
└── ...

注目したいのは、.git/が1つだけである点です。履歴やオブジェクトは共有され、作業ディレクトリだけが増えていきます。このあと説明するディスク容量の話も、共有リソースの注意点も、すべてこの構造から導かれます。

手動でのワークツリー管理

Gitのコマンドで自分でワークツリーを作ることもできます。特定の既存ブランチをチェックアウトしたいときや、リポジトリの外に置きたいときに向いています。仕組みを理解しておくと、想定外の状態になったときに自分で戻せます。

# 新しいブランチを切ってワークツリーを作成
git worktree add ../.worktrees/feature-new-api -b feature-new-api

# ワークツリーの一覧を確認
git worktree list

# 不要になったワークツリーを削除
git worktree remove ../.worktrees/feature-new-api

以下の画面は、本記事で扱うgit worktree add・git worktree list・git worktree removeなどのコマンドと、git checkoutとの対比をターミナル上に並べたものです。先頭行はバージョン確認の出力で、それ以外は入力するコマンドの形を示しています。既存ブランチを使う場合は-bを付けず、git worktree add <パス> <ブランチ名>の形になります。

自然言語で指示する場合の書き方

Claude Codeに「feature-new-apiブランチでワークツリーを作成して、そこでAPI実装を進めてください」と指示すれば、上記のようなGit操作を実行できます。こうした指示は、目的と制約を明示するほど正確に実行されます。

ここで押さえておきたいのは、AIと人間の役割分担です。ワークツリーの作成・一覧確認・削除といった定型のGit操作はAIに任せて問題ありません。一方で「どのタスクを並列にするか」「どのブランチを切るか」というタスク分割の判断は、プロダクトの構造とチームの事情を知っている人間が決めるべき領域です。私たちは、HubSpotの導入支援でも定型作業は仕組みに任せ、最終判断は人が持つ設計をおすすめしており、Claude Codeの並列開発でも同じ考え方が当てはまると考えています。指示の書き方はClaude Codeのプロンプト設計術で解説しています。

実務での活用パターン3つ｜難易度順に広げる

ワークツリーの使い道は1つではありません。いきなり複数エージェントの同時実行から始めると、どこで問題が起きたのかを切り分けにくくなりがちです。ここでは実務でよく使う3パターンを、理解しやすい順に整理します。

パターン1: 複数エージェントによる機能並列開発

大規模なプロジェクトでは、複数のClaude Codeインスタンスが同時に異なる機能を開発するケースがあります。ターミナルを3つ開き、それぞれ別の名前でclaude --worktreeを実行する形です。

エージェントA: claude --worktree feature-auth（認証機能実装）
  → ワークツリー: .claude/worktrees/feature-auth/

エージェントB: claude --worktree feature-dashboard（ダッシュボード実装）
  → ワークツリー: .claude/worktrees/feature-dashboard/

エージェントC: claude --worktree fix-performance（パフォーマンス改善）
  → ワークツリー: .claude/worktrees/fix-performance/

各エージェントは物理的に別のディレクトリで作業するため、同じファイルへの競合が起きにくい構造です。それぞれが独立してコミット・プッシュ・PR作成まで進められます。複数のAIエージェントが同時にコードを変更する場面ほど、ワークツリーによる物理的な分離の効果は大きくなると考えられます。

運用面の工夫として、どのウィンドウがどのワークツリーかを見分けやすくするため、テーマやステータスラインを変えておくと混乱を防げます。設定方法はClaude Codeの見た目カスタマイズをご覧ください。別ベンダーのAIにセカンドオピニオンを取らせる構成も可能で、その手順はClaude CodeとCodexの連携方法で解説しています。

パターン2: レビュー中の作業と新規開発の分離

3パターンの中で最も始めやすいのがこれです。PRのレビュー待ちの間に別の作業を進めたい場合に有効で、エージェントは1つのままでも効果が出ます。

# 現在の作業をPRとして提出
git push origin feature-current
gh pr create --title "機能A実装"

# 別のワークツリーで新しい作業を開始
git worktree add ../.worktrees/feature-next -b feature-next
cd ../.worktrees/feature-next

Claude Codeに「現在のブランチのPRを作成してから、新しいワークツリーで次の機能開発に着手してください」と指示すれば、このフローを進められます。レビューの修正指摘が来たら、元のワークツリーに戻って対応できます。ここでstashが不要になる点が効いていて、「戻すのを忘れる」という事故がそもそも発生しません。

外出中に指摘が届いた場合は、Claude Codeのリモート操作方法で手元の端末から対応を始められます。Claude Codeを使った経営データの可視化やコンテンツマーケティングにも、こうした並列の考え方が活かされています。

パターン3: Agent SDKとサブエージェントでの並列タスク実行

Claude Agent SDKを使えば、複数のタスクをプログラムから並列で実行できます。タスクごとに作業ディレクトリをワークツリーへ向けておけば、通常の編集先がタスクごとに分かれ、同じファイルを取り合う干渉はほぼ起きなくなります。また、サブエージェントの定義にisolation: worktreeを書くと、そのサブエージェントは毎回専用のワークツリーで動きます。

SDKで3タスクを並列実行（作業ディレクトリは事前に用意したワークツリー）:
  タスク1: 「テストを追加」 → .worktrees/task-1/
  タスク2: 「ドキュメント更新」 → .worktrees/task-2/
  タスク3: 「リファクタリング」 → .worktrees/task-3/

各タスクの成果は別々のブランチに残るため、PRを分けてレビューとマージを個別に進められます。ただし、並列度を上げるほど人間側のレビュー負荷は積み上がります。PRが同時に何本も並ぶと、結局レビューがボトルネックになって並列化の効果が相殺されるケースがあります。並列度は「同時に自分がレビューできる本数」を上限に考えるのが現実的です。

3パターンの使い分け

まずはパターン2のレビュー待ち中の別作業から始めて、事故なく回ることを確認してからパターン1へ広げるのが実務的な順序です。いきなり並列度を上げず、チームの開発フローに合わせて段階的に拡大していくほうが、結果的に定着します。

ワークツリーの配置設計｜自社のリポジトリ構成に合わせる

ここからは設計の話です。ワークツリーをどこに置くかは、IDEの検索挙動、.gitignoreの運用、チームメンバーの認知負荷に直結します。汎用的な正解はなく、リポジトリの構成とチームの習慣によって最適解は変わります。

3つの配置パターンの比較

ワークツリーの配置場所には、プロジェクトの外に置くパターンとプロジェクト内に置くパターンがあります。

Claude Codeの--worktreeでは、既定でリポジトリ直下の.claude/worktrees/にワークツリーが作成されます。.gitignoreに.claude/worktrees/を追加しておくことをおすすめします。これを忘れると、ワークツリーの中身が未追跡ファイルとして見えてしまい、レビューのノイズになります。置き場所を変えたい場合は、WorktreeCreateフックで作成処理を置き換える方法が公式に用意されています。なお、このフックを使うと.worktreeincludeは処理されなくなるため、.envなどのコピーはフックの中に書く必要があります。

どのパターンを選ぶかの判断軸

選択の判断軸は、おおむね次の3点に整理できます。

• 全文検索の誤ヒットが気になるか — 同じコードが複数ディレクトリに存在するため、IDEの検索結果が重複します。これが業務の妨げになるならプロジェクト外か隠しディレクトリを選びます。
• チームで統一したいか — プロジェクト内配置は、パスが相対的に短く、CLAUDE.mdなどのドキュメントに書いて共有しやすい形です。新しいメンバーが迷いにくいのは、この配置です。
• 複数リポジトリを横断するか — 扱うリポジトリが多いなら、~/.claude-worktrees/配下にリポジトリ名でまとめる形が管理しやすくなります。

ただし、企業様によって最適な形は異なります。モノレポで1リポジトリのサイズが大きい場合と、小さなリポジトリを多数抱えている場合では、答えは変わります。まずはデフォルトのプロジェクト内配置で運用してみて、検索の誤ヒットや認知負荷が問題になった時点で移すのが、無駄の少ない進め方です。

配置ルールをドキュメント化して仕組みにする

配置パターンを決めたら、それを個人の記憶に置かず、リポジトリのドキュメントに書き残します。CLAUDE.mdに「ワークツリーはclaude --worktreeで.claude/worktrees/配下に作成する」「--worktreeに渡した名前はディレクトリ名になり、ブランチ名はworktree-<名前>になる」といったルールを明記しておけば、Claude Code自身がそのルールに従って動きます。

これは、SFAで不要なプロパティが乱立しないように入力ルールを設計するのと同じ発想です。ルールを人の頭ではなくシステム側に置くことで、担当者が変わっても同じ運用が続きます。引き継ぎ資料を書かなくても新しいメンバーが同じ形で作業できる状態が、仕組み化のゴールです。

クリーンアップの運用設計｜残骸を溜めない仕組み

ワークツリーは作るのは簡単ですが、消すのを忘れがちです。長期間運用していると、マージ済みブランチのワークツリーが残り続け、どれが生きている作業か分からなくなります。ここは運用ルールを決めておく価値が大きい領域です。

基本のクリーンアップコマンド

定期的なクリーンアップでよく使うのは、次の3つのコマンドです。

# ワークツリーの一覧確認（マージ済みかどうかに関係なく、全件が表示される）
git worktree list

# マージ済みブランチの確認（mainにマージ済みのブランチだけが表示される）
git branch --merged main

# 一覧とマージ済みブランチを突き合わせたうえで、不要なワークツリーを削除
git worktree remove .worktrees/feature-completed

# ディレクトリが失われたワークツリーの管理情報を整理
git worktree prune

git worktree listはマージ済みのものだけでなく、すべてのワークツリーを表示します。一覧を見ただけで削除すると、作業中のものまで消しかねません。削除する前にgit branch --merged mainで、対象ブランチがmainにマージ済みかを確認する手順を挟んでください。git worktree pruneは、ディレクトリがすでに無くなったワークツリーの管理情報を整理するコマンドで、マージ済みのワークツリーを探して消すものではありません。

Claude Codeに「マージ済みブランチのワークツリーをクリーンアップしてください」と指示すれば、上記の操作をまとめて進められます。--worktreeで作ったワークツリーは、対話セッションを終了するときに、変更がなければ自動で削除されます（名前を付けたセッションでは削除するかを確認されます）。変更やコミットが残っている場合は、残すか削除するかを選ぶ画面が出ます。ここでも、一覧を取って判断する部分はAIに任せられますが、「このブランチはまだ使う予定があるか」の最終判断は人間が持ったほうが安全です。

クリーンアップを習慣ではなくトリガーに紐づける

「定期的に掃除しましょう」という呼びかけは、たいてい守られません。そこで、削除のタイミングを作業フローの特定イベントに紐づけます。

ポイントは、「気づいたら掃除する」ではなく「この操作をしたら、これもやる」という形にすることです。営業がステージを進めるときに必須入力プロパティを設定しておくと、入力漏れが構造的に起きなくなるのと同じ考え方です。人の善意ではなく、フローの中に組み込んで初めて継続します。

ただし、自動削除は慎重に

クリーンアップを完全自動化したくなりますが、そこは慎重に設計したほうがよい部分です。未コミットの変更が残っているワークツリーを自動削除すると、作業内容が失われます。自動化するとしても、削除対象の一覧を提示して人が確認してから実行する形をおすすめします。

AIエージェントに削除系の操作を委ねる場合も同様で、実行前の確認を挟む運用のほうが安全です。破壊的な操作は、便利さより復旧可能性を優先する——これは、AIを業務に組み込むときの一般的な原則だと考えています。

ワークツリー運用を仕組みにする3つのポイント

ここまでの内容を整理すると、ワークツリーを事故なく運用するための工夫は、次の3点に集約できます。

1. 配置ルールの明文化 — どこにワークツリーを作るかをCLAUDE.mdに書き、個人の記憶に頼らない
2. 削除トリガーの明確化 — 「いつ消すか」を作業フローの特定イベントに紐づけ、習慣ではなく仕組みにする
3. 共有リソースの初期セットアップ手順の共有 — node_modulesや.envの扱いを事前にドキュメント化し、.worktreeincludeも用意する

この3点は個別のTipsではなく、セットで設計して初めて効果が出ます。どれか1つだけ整えても、別の箇所で残骸や事故が発生しやすくなります。

ワークツリー間の共有リソースと正直な限界

ワークツリーは万能ではありません。導入後につまずきやすいポイントを、率直に書いておきます。ここを知らずに始めると、「ワークツリーを作ったのにビルドが通らない」という状態になりがちです。

Git管理外のファイルはコピーされない

ワークツリーは独立したディレクトリですが、.gitオブジェクトデータベースは共有しています。逆に言えば、Git管理外のものは共有されません。

• node_modulesや.venvはワークツリーごとに独立して存在するため、各ワークツリーでnpm installやpip installが必要です
• .envファイルはGit管理外のため、そのままではワークツリーに入りません。プロジェクト直下に.worktreeincludeファイルを置いて.envなどのパターンを書いておくと、Claude Codeがワークツリーを作る際に、.gitignore対象のファイルのうち一致したものをコピーします。手でGitコマンドを使って作ったワークツリーには適用されないため、その場合は手動でコピーしてください。WorktreeCreateフックで作成処理を置き換えている場合も.worktreeincludeは処理されないため、フックのスクリプトの中でコピーします
• ロックファイル（package-lock.json、poetry.lock）はブランチごとに異なる可能性があるため、ワークツリー作成後に依存関係の再インストールをおすすめします

この3点は、ワークツリーを作ったあとの初期セットアップ手順としてCLAUDE.mdに書いておくと、毎回の手戻りがなくなります。

同じブランチを複数のワークツリーで開けない

Gitの仕様上、同じブランチを複数のワークツリーで同時にチェックアウトすることはできません。各ワークツリーは異なるブランチを担当する必要があります。「同じブランチで2つのエージェントに別々の作業をさせる」という使い方はできないため、タスク分割の段階でブランチを分ける前提で設計します。

ワークツリーが向かないケース

正直なところ、ワークツリーは「並列作業をしている人・チーム」にとっての道具です。1タスクずつ丁寧に進めているなら、導入しないほうがシンプルに回ります。ツールを入れること自体が目的にならないよう、自分の作業スタイルに照らして判断していただければと思います。

周辺機能との組み合わせ｜開発フロー全体に位置づける

ワークツリーは単体で価値を出す機能というより、Claude Codeの開発フロー全体を支える土台です。ここでは、SDK・パーミッション設定との関係を整理します。

SDK経由での並列実行

Claude Agent SDK（旧Claude Code SDK）を使えば、事前にgit worktree addで用意した複数のワークツリーを作業ディレクトリに指定して、プログラムから並列でタスクを実行できます。

import { query } from "@anthropic-ai/claude-agent-sdk";

const tasks = [
  { branch: "feature-auth", prompt: "認証機能を実装してください" },
  { branch: "feature-api", prompt: "REST APIを実装してください" },
];

const results = await Promise.all(
  tasks.map(async (task) => {
    const messages = [];
    for await (const message of query({
      prompt: task.prompt,
      options: {
        maxTurns: 30,
        cwd: `/path/to/project/.worktrees/${task.branch}`,
        // 作業ディレクトリ内のファイル編集を自動で許可する
        permissionMode: "acceptEdits",
        // テスト実行など、必要なコマンドだけを追加で許可する
        allowedTools: ["Read", "Grep", "Glob", "Bash(npm test *)"],
      },
    })) {
      messages.push(message);
    }
    return messages;
  })
);

cwdにワークツリーのパスを渡している点が本質です。あわせて、権限の指定も必要です。公式ドキュメントによると、Claude Code v2.1.302以降では、権限モードの指定も設定ファイルのpermissions.defaultModeもない場合はdefaultモードで始まり、承認が必要なツール呼び出しは許可ルールや承認用のコールバックなどで承認しない限り拒否されます。そのため、人が確認できない並列実行では、実装に必要な編集やテスト実行が止まります。例ではpermissionMode: "acceptEdits"で作業ディレクトリ内のファイル編集を自動承認し、allowedToolsでテスト実行などの必要なコマンドだけを許可しています（Pythonではpermission_modeとallowed_tools）。acceptEditsはファイル編集とmkdir・rm・mvなどのファイル操作が対象で、作業ディレクトリの外は自動承認されません。許可は必要な範囲にとどめ、それ以外の判断は実行時に可否を決めるコールバックで扱う設計にすると安全です（公式）。なお、query()の呼び出し形式はSDKのバージョンで変わることがあるため、実装時は公式ドキュメントで確認してください。各インスタンスの作業場所を明示的に分けることで、通常の編集先の分離をコード上で表現できます。ただし、cwdの指定は「どこで作業を始めるか」を決めるだけで、ほかのディレクトリへの書き込みを禁止するものではありません。作業ディレクトリの外へ書かせたくない場合は、権限ルールやサンドボックスで制御します（公式）。逆に言えば、cwdを分け忘れると同じディレクトリで複数タスクが動いてしまうため、SDK利用時はここを設計上の必須項目として扱うことをおすすめします。

パーミッションモードとの関係

ワークツリーでの作業にも、通常のセッションと同じパーミッション設定の仕組みが適用されます。Gitで管理している.claude/settings.jsonはワークツリーのチェックアウトにも含まれます。また、ワークツリーのセッションで「今後は確認しない」を選んだBashコマンドの許可は、メインのチェックアウトにある.claude/settings.local.jsonに保存されます。そのためメインや他のワークツリーにも効き、ワークツリーを削除しても残ります。ただし、Windowsなど、Claude Codeがリポジトリのルートを基準にしない場合は、許可はそのワークツリーの中にとどまり、共有されません。

設定が共有される分、ワークツリーごとに権限を変えたい場合は、あらかじめ運用で切り分けておく必要があります。権限設計はリポジトリ単位で決め、その許可が（上記の例外を除き）全ワークツリーに効くという前提で組み立ててください。

開発フロー全体の中での位置づけ

ワークツリーを、Claude Codeを使った開発の流れの中に置くと、次のような位置になります。これは、HubSpotで1つの商談がコンタクト獲得から契約・請求まで複数のフェーズを通過し、各フェーズで異なる機能が連携するのと同じ発想です。ワークツリーも単体の機能として覚えるより、フェーズごとの役割で理解するとつながりが見えます。

この表で見ると、ワークツリーは実装フェーズだけの話ではなく、タスク分割から後片付けまでの一連の流れに関わっていることが分かります。個別のコマンドとして覚えるのではなく、開発フロー全体の設計要素として捉えると、導入判断がしやすくなります。

よくある質問

Q1. ワークツリーを使うとディスク容量は2倍必要ですか？

いいえ、Gitのオブジェクトデータベース（.git/）は全ワークツリーで共有されるため、リポジトリの履歴データは重複しません。増えるのは作業ディレクトリのファイル（ソースコード、node_modulesなど）のみです。ソースコード自体のサイズは通常小さいため、実質的な増加はnode_modulesなどの依存関係が主です。

Q2. ワークツリーでの変更が他のワークツリーに影響することはありますか？

通常の編集はそれぞれのワークツリーのディレクトリ内で行われるため、あるワークツリーでの編集が別のワークツリーのファイルを書き換えることは基本的にありません。ただし、これは「ディレクトリが分かれている」という構造上の分離で、書き込みを禁止する仕組みではありません。--worktreeで起動したセッションやisolation: worktreeのサブエージェントなど、Claude Codeがワークツリーに隔離したセッションでは、メインのチェックアウトを対象にしたEdit・Writeや、メインのチェックアウトへ向けたgit操作をブロックするチェックが働きます。一方、公式ドキュメントによると、このチェックはシェルコマンドが書き込むファイルまでは追跡しないため、cpやリダイレクト（>）で別のディレクトリへ書き込むコマンドは止められません。そうした書き込みは、通常どおり権限設定とサンドボックスの設定で制御します（公式）。また、同じブランチを複数のワークツリーで同時にチェックアウトすることはGitの仕様上できません。各ワークツリーは異なるブランチを担当する必要があります。

Q3. Claude Codeが作成したワークツリーはどこに保存されますか？

--worktreeで作成した場合は、既定でプロジェクトルートの.claude/worktrees/<名前>/配下に作られます。git worktree listコマンドで全ワークツリーの場所を確認できます。不要になったワークツリーはgit worktree removeで削除するか、Claude Codeに「ワークツリーをクリーンアップしてください」と指示してください。

Q4. 並列で動かすエージェントは何個くらいが適切ですか？

一律の正解はなく、レビューできる体制によって変わります。実装が並列化されてもレビューは人間が行うため、同時に走らせる数は「自分またはチームが同時にレビューできるPRの本数」を上限に考えるのが現実的です。まず2つから試し、レビューが滞らないことを確認してから増やすことをおすすめします。

Q5. ワークツリーを削除したらブランチも消えますか？

git worktree removeは作業ディレクトリを削除する操作で、ブランチ自体は残ります。ブランチも不要であれば別途削除が必要です。逆に、ディレクトリだけを手動で消した場合はGit側に管理情報が残るため、git worktree pruneで残骸を整理してください。

まとめ

Git Worktreeは、Claude Codeの並列開発能力を安全に引き出すための基盤技術です。物理的なディレクトリ分離により、複数エージェントが同時に作業しても、同じファイルを取り合う競合が起きにくくなります。本記事の要点を整理します。

• 並列開発の安全性は、注意力ではなくディレクトリ構成という構造で担保します
• 配置パターンは3つあり、企業様によって最適な形は異なります。まずはデフォルトのプロジェクト内配置（.claude/worktrees/）から始めます
• クリーンアップは習慣ではなくトリガー（PRマージ時・週次棚卸し）に紐づけて仕組みにします
• Git管理外のnode_modulesや.envは共有されないため、.worktreeincludeと初期セットアップ手順を整えておきます
• 1人で1タスクずつ進めているなら、ワークツリーを導入しないほうがシンプルに回ります

最初の一歩としては、エージェント1つのままで始められるパターン2（レビュー待ち中の別作業）が、比較的始めやすい入口です。次の3ステップで試せます。

1. .gitignoreに.claude/worktrees/を追加する
2. レビュー待ちのPRを出したら、claude --worktree <名前>（またはgit worktree add）で次の作業用ワークツリーを1つ作る
3. PRがマージされたタイミングでgit worktree removeし、削除までを1セットの手順として定着させる

ここまで回ったら、エージェントを2つに増やしてパターン1へ広げ、チームの開発フローに合わせて並列度を拡大していくのが実務的な進め方です。Claude Codeの全コマンド一覧はClaude Codeチートシート、AI活用の全体像はAI活用完全ガイドをご覧ください。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• Claude Codeでバグ調査・修正を体系化する方法｜エラーログ解析から本番障害対応まで
• Claude Codeでプロジェクト管理を効率化する方法｜CLAUDE.md・タスク分割・進捗管理の実践
• Claude Codeキーボードショートカット一覧｜操作速度を2倍にする18のキー操作