Claude Codeで、リファクタリングと新機能の実装を同時に進めたい、複数の修正案を並行して試したい、と思ったことはないでしょうか。通常のやり方では作業フォルダが1つしかないため、複数の作業を同時に走らせるとファイルの競合（同じファイルを別々の作業が同時に書き換えてしまう衝突）が避けられません。そこで使うのが、Git Worktreeとサブエージェントを組み合わせた並列開発パターンです。

Git Worktree（ワークツリー）とは、1つのリポジトリ（プロジェクトのファイル一式と変更履歴）から、独立した作業フォルダを複数生やせるGitの機能です。この記事で学べることは以下の4点です。

  • そもそもこの機能が必要になるのはどんな時か（判断基準）
  • Claude Codeのサブエージェントにおけるisolation: "worktree"オプションの仕組み
  • 複数エージェントを安全に並列起動するための指示の出し方
  • 並列作業をマージ・破棄するときの実践的ワークフロー

この機能が必要になるのはどんな時か

worktreeは便利ですが、全員に必要な機能ではありません。正直に言うと、Claude Codeを使い始めたばかりの段階では出番がないことの方が多いです。次の3つの質問で判断してください。

  1. 互いに独立した2つ以上の作業を、同時に走らせたいか。 たとえば、記事ページのデザイン修正と、問い合わせフォームの改修は、触るファイルが別なので同時に進められます。
  2. 失敗したら丸ごと捨てたい実験か。 デザイン案を3パターン作って見比べて、採用しなかった案は跡形もなく消したい、といったケースです。
  3. いま動いているものを絶対に汚したくないか。 本番で使っているファイルに、試行錯誤の途中経過を混ぜたくない場合です。

1つでも当てはまるならworktreeを検討する価値があります。逆に、作業が1本道で順番に頼めば済む、同じファイルを直す作業同士でどのみち衝突する、データベースの変更のように順序が決まっている、という場合には不要です。1つずつ順番に頼む通常の使い方で困っていないなら、無理に導入する必要はありません。

イメージとしては、作業机を増やす機能だと考えてください。机が1つだと、書類仕事Aの途中で書類仕事Bを広げると机の上が混ざります。机を3つ用意して仕事ごとに分け、完成したものだけを本棚（本流のブランチ）に戻す。それがworktree並列化の考え方です。

なぜWorktreeが必要なのか

Claude Codeのサブエージェント（メインの会話とは別に動く分身のようなAI。Agentツールで起動します）は、通常は親と同じ作業フォルダで動作します。単発のタスクには効率的ですが、複数を同時に動かすと次のような問題が起きやすくなります。

  • エージェントAがあるファイルを編集中に、エージェントBも同じファイルを書き換えてしまう
  • テストが他エージェントの作業途中の変更を拾って、誤った失敗判定を出す
  • 失敗したエージェントの中途半端な変更が作業フォルダに残り、後続の作業を汚染する

Git Worktreeは、git worktree add ../feature-x feature/x のように使い、独立したフォルダを作ります。各フォルダはファイルとしては完全に分かれていながら、変更履歴のデータベース（.gitディレクトリ）は共有されるため軽量です。

isolation: "worktree" オプションの基本

Claude CodeのAgentツールにはisolationパラメータがあり、"worktree"を指定すると、エージェント起動時に自動で一時worktreeが作成されます。あなたが手でgit worktree addを打つ必要はありません。

Agent({
  description: "認証ミドルウェアのリファクタ",
  subagent_type: "general-purpose",
  isolation: "worktree",
  prompt: `lib/auth/middleware.ts のセッション検証ロジックを
  リファクタしてほしい。
  対象ファイル: lib/auth/middleware.ts:42-118
  完了条件: npm test が通ること。`
})

この呼び出しが行われると、内部的には次の処理が実行されます。

  1. 一時ブランチ（作業の枝分かれ。例: claude/agent-abc123）を作成
  2. git worktree addで隔離フォルダを生成
  3. エージェントをそのフォルダで起動
  4. エージェント終了後、変更があればフォルダのパスとブランチ名を結果として返却
  5. 変更がなければworktreeを自動で片付け

親側の作業フォルダは一切影響を受けません。

複数エージェントの並列起動パターン

本領を発揮するのは、独立した複数タスクを同時並列で投げるケースです。1回の指示の中に複数のAgent呼び出しを含めると、Claude Codeはそれらを並列実行します。

// 1メッセージ内で3つのworktreeエージェントを並列起動
[
  Agent({
    description: "記事フェッチャーのRSS対応強化",
    isolation: "worktree",
    prompt: "lib/fetchers/rss.ts でAtom 1.0の\n名前空間バリエーションを処理できるよう修正。\nテスト: lib/fetchers/rss.test.ts を追加。"
  }),
  Agent({
    description: "AI分析のプロンプトキャッシュ導入",
    isolation: "worktree",
    prompt: "lib/ai/analyze.ts にプロンプトキャッシュを導入。"
  }),
  Agent({
    description: "X投稿スケジューラのリトライ実装",
    isolation: "worktree",
    prompt: "lib/social/x.ts にリトライ処理を追加。最大3回、初回1秒。"
  })
]

3つのエージェントはそれぞれ別のworktreeで動くため、同じ設定ファイルを3つとも触っても、統合は後段で個別に処理できます。逐次実行に比べて所要時間はおよそ3分の1になります。worktreeの切り方から検品・マージまでの全工程は、git worktree × 並列サブエージェントで3倍速開発を実現する実践記事で6つのレイヤーに分けて詳しく解説しているので、実際に手を動かす前にそちらも読んでみてください。

マージワークフローの設計

並列実行が終わると、各エージェントはブランチ名とworktreeパスを返してきます。これをどう統合するかが運用の鍵です。一般的なパターンは3種類あります。

パターン1: 個別PR化

各worktreeをそのままpushしてPR（プルリクエスト。変更の提案とレビューの単位）にします。レビュー単位を小さく保てるのが利点です。

cd ../claude-agent-abc123
git push -u origin claude/agent-abc123
gh pr create --title "feat: RSS Atom 1.0対応" --body "..."

パターン2: 統合ブランチへのcherry-pick

複数エージェントの成果を1つの統合ブランチに集約します。関連するタスクをまとめてリリースしたいときに使います。

git checkout -b feature/sprint-42
git cherry-pick claude/agent-abc123
git cherry-pick claude/agent-def456
npm test  # 統合後のテスト

パターン3: 破棄

試行錯誤的な実験では、結果を見て採用しないという判断も普通にあります。

git worktree remove ../claude-agent-abc123
git branch -D claude/agent-abc123

git worktree listで現存するworktreeを確認できます。放置するとディスク容量を圧迫するので、定期的な掃除をおすすめします。

競合回避と運用上の注意点

worktree並列化には固有の注意点があります。

順序が決まっている作業は並列化しない

データベースのマイグレーションファイル（変更履歴を順番に適用する仕組み）は作成順に依存するため、並列で生成すると番号が衝突します。この種の作業は逐次実行が安全です。

node_modulesの扱い

worktreeは変更履歴を共有しますが、node_modules（外部部品の置き場）は共有しません。各worktreeでインストールが必要になる場合があり、初回起動が遅くなります。

機密情報の扱い

.env.local（APIキーなどの秘密情報を置くファイル）はworktreeにコピーされないことが多いです。エージェントが必要とする場合は明示的にコピーするか、テスト用の値を渡します。

親エージェントの責務

並列エージェントを起動した親は、結果を集約して理解した上で次のアクションを決める必要があります。3つの結果を見て良しなにマージしておいて、という丸投げはアンチパターンです。各エージェントが何をしたか、テストが通ったか、副作用がないかを親が確認する責任を持ちます。サブエージェントに何をどこまで任せるかの設計は、サブエージェント委譲パターン集が参考になります。

実際のプロジェクトでの適用例

本メディアClaude Worksでは、次のようにworktree並列化を活用しています。

  • データ取得機能の追加: 5つの情報ソース対応を、5つのworktreeエージェントで並列開発
  • AI分析の改善実験: プロンプトのバリエーションを3案並走させ、結果を比較してから本流に取り込み
  • デザイン微調整: 配色案A/B/Cをworktreeで並走させ、スクリーンショットを見比べて採用案を決定

特に、捨てる前提の試行と、並列でPR化できる独立タスクへの効果が大きいと感じています。

まとめ: 並列化は分割と検品がすべて

isolation: "worktree"オプションは、サブエージェント並列化の現実的な解です。運用のコツは3点に集約されます。(1) 並列化に向くタスク（独立した実装、試行錯誤）と向かないタスク（順序依存の変更）を見極める、(2) マージ戦略を事前に決めておく、(3) 親が結果を理解する責任を放棄しない。最終的な判断は人間とその代理である親エージェントが担う、という原則を忘れずに活用してください。

サブエージェントそのものの設計パターン（レビュアー・調査役・テスターの分業）はClaude Codeのサブエージェント活用パターン集にまとめています。また、導入から並列運用までを1冊に整理した教材ライブラリを見るを無料配布していますので、社内展開の資料としてもご活用ください。