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

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

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

Git Worktreeとは、1つのGitリポジトリから複数の作業ディレクトリ（ワークツリー）を作成する機能です。作業がディレクトリ単位で物理的に分かれるため、複数のエージェントが同時に動いてもファイルの上書き競合が起きません。本記事では、この仕組みをClaude Codeの並列開発にどう組み込むかを、設計の考え方から運用のルールまで整理します。

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

この記事でわかること

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

• Git Worktreeの基本概念と従来のブランチ切り替えとの違い — git checkoutが作業ディレクトリを置き換えるのに対し、ワークツリーは別ディレクトリに展開します。この差が並列開発の可否を決めます。
• Claude Codeがワークツリーを自動活用する仕組み — Claude Codeには、ワークツリーを自動的に作成・管理する機能が組み込まれています。複数インスタンスの並列実行時も各タスクが独立したワークツリーで動きます。
• 実務での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には、ワークツリーを自動的に作成・管理する機能が組み込まれています。利用者が毎回コマンドを打たなくても、新しいブランチでの作業開始時にエージェント側でワークツリーを用意する動きになります。

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

Claude Codeで新しいブランチを作成して作業を始める場合、エージェントが自動的にワークツリーを作成します。複数のClaude Codeインスタンスで並列実行する際にも、各タスクが独立したワークツリーで実行されます。ディレクトリ構成としては、次のような形になります。

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

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

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

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

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

自動任せにせず、Claude Codeのセッション中に手動でワークツリーを操作することも可能です。仕組みを理解しておくと、想定外の状態になったときに自分で戻せます。

# 新しいワークツリーを作成
git worktree add ../.worktrees/feature-new-api feature-new-api

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

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

上の画面は、本記事で扱うgit worktree add・git worktree list・git worktree removeなどのコマンドと、git checkoutとの対比をターミナル上に並べたものです。先頭行はバージョン確認の出力で、それ以外は入力するコマンドの形を示しています。

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

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

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

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

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

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

大規模なプロジェクトでは、複数のClaude Codeインスタンスが同時に異なる機能を開発するケースがあります。

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

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

エージェントC: fix-performance ブランチ（パフォーマンス改善）
  → ワークツリー: .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: SDK経由での並列タスク実行

Claude Code SDKを使えば、複数のタスクを並列で実行できます。各タスクは独立したワークツリーで実行されるため、タスク間の干渉を気にする必要がありません。

SDK経由で3タスクを並列実行:
  タスク1: 「テストを追加」 → .worktrees/task-1/
  タスク2: 「ドキュメント更新」 → .worktrees/task-2/
  タスク3: 「リファクタリング」 → .worktrees/task-3/

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

3パターンの使い分け

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

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

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

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

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

Claude Codeのデフォルトでは、プロジェクト内の.worktrees/ディレクトリにワークツリーが作成されます。.gitignoreに.worktrees/を追加しておくことをおすすめします。これを忘れると、ワークツリーの中身がGitの差分として見えてしまい、レビューのノイズになります。

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

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

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

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

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

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

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

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

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

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

定期的なクリーンアップには、次の3つのコマンドを使います。

# マージ済みワークツリーの一覧確認
git worktree list

# 不要なワークツリーを削除
git worktree remove .worktrees/feature-completed

# 残骸の一括クリーンアップ
git worktree prune

Claude Codeに「マージ済みブランチのワークツリーをクリーンアップしてください」と指示すれば、上記の操作を安全に実行します。ここでも、一覧を取って判断する部分はAIに任せられますが、「このブランチはまだ使う予定があるか」の最終判断は人間が持ったほうが安全です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• node_modulesや.venvはワークツリーごとに独立して存在するため、各ワークツリーでnpm installやpip installが必要です
• .envファイルはGit管理外のため、ワークツリーには自動的にコピーされません。手動でコピーするか、シンボリックリンクを設定してください
• ロックファイル（package-lock.json、poetry.lock）はブランチごとに異なる可能性があるため、ワークツリー作成後に依存関係の再インストールをおすすめします

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

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

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

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

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

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

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

SDK経由での並列実行

Claude Code SDKを使えば、プログラムから複数のワークツリーを作成し、並列でタスクを実行できます。

import { claude } from "@anthropic-ai/claude-code";

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

const results = await Promise.all(
  tasks.map((task) =>
    claude({
      prompt: task.prompt,
      options: {
        maxTurns: 30,
        cwd: `/path/to/project/.worktrees/${task.branch}`,
      },
    })
  )
);

cwdにワークツリーのパスを渡している点が本質です。各インスタンスの作業場所を明示的に分けることで、並列実行の安全性がコード上で担保されます。逆に言えば、cwdを分け忘れると同じディレクトリで複数タスクが動いてしまうため、SDK利用時はここを設計上の必須項目として扱うことをおすすめします。

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

ワークツリーでの作業は、メインディレクトリと同じパーミッション設定が適用されます。.claude/settings.jsonはメインリポジトリの設定が共有されるため、ワークツリーごとに権限を変える必要はありません。

設定が一元化されているのは運用上ありがたい一方で、「このワークツリーだけ権限を緩める」といった細かい調整はできないことを意味します。権限設計はリポジトリ単位で一度しっかり決め、その設定が全ワークツリーに効くという前提で組み立ててください。

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

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

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

よくある質問

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

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

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

ファイルシステム上は完全に分離されているため、あるワークツリーでの変更が別のワークツリーのファイルに影響することはありません。ただし、同じブランチを複数のワークツリーで同時にチェックアウトすることはGitの仕様上できません。各ワークツリーは異なるブランチを担当する必要があります。

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

Claude Codeのデフォルト設定では、プロジェクトルートの.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つあり、企業様によって最適な形は異なる。まずはデフォルトのプロジェクト内配置から
• クリーンアップは習慣ではなくトリガー（PRマージ時・週次棚卸し）に紐づけて仕組みにする
• Git管理外のnode_modulesや.envは共有されないため、初期セットアップ手順をドキュメント化しておく
• 1人で1タスクずつ進めているなら、ワークツリーを導入しないほうがシンプルに回る

最初の一歩としては、レビュー待ちの間に別作業を進めるパターン2から始めてください。次の3ステップで試せます。

1. .gitignoreに.worktrees/を追加する
2. レビュー待ちのPRを出したら、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のキー操作