株式会社CAENのロゴ

Git worktreeでAI駆動開発を並列化する|個人開発が5人チームになる実践術

この記事で分かること

AI 駆動開発で「個人開発者なのにチーム並みに速い」という状態を作る最大のカギは、Git worktree による並列化です。

  • Claude Code / Codex CLI / Cursor を同じリポジトリで同時に走らせると、ブランチを奪い合って壊れる
  • 解決策は git worktree作業ツリーを物理的に別ディレクトリに分けて、AI エージェントごとに別ブランチを持たせる
  • 大森翔吾 が Mac mini 1 台で 3 AI を 24 時間動かしている具体構成・コマンド・運用ルールを公開する

この記事は AI駆動開発の爆速フロー全公開worktree 特化・実装編 です。概念より一歩踏み込んで、「明日から自分のリポジトリで再現できる」粒度で書きます。

なぜ worktree なしで並列 AI を走らせると壊れるのか

まず前提から。AI 駆動開発では、1 人の開発者が複数の AI コーディングエージェントを同時に動かす ことが普通になりました。僕の構成は、Cursor 内に Codex 拡張、ターミナルに Codex CLI、別タブで Claude Code。これらが 24 時間フル稼働しています。

ここで初心者が最初にぶつかる壁が ブランチの奪い合い です。

/Users/you/repo         ← このディレクトリが 1 つだけ
├─ Codex が feat/image-upload で実装中
├─ Claude Code が feat/profile-cover に切り替えたい
└─ Cursor は fix/notification で動いていたい

Git の標準構成では、1 リポジトリにつき 作業ツリー(working tree)は 1 つだけ。つまり git checkout でブランチを切り替えるたびに、手元のファイルがまるごと書き換わります。

この状態で AI を 3 つ並列に走らせると何が起きるか。

  • Codex が feat/image-upload でファイルを書き換えている最中に
  • Claude Code が勝手に git switch feat/profile-cover を実行して
  • Codex の未コミット変更が消える / 別ブランチに混入する

実際に一度やってみるとわかりますが、原因不明のコンフリクトと差分消失 が頻発します。個人開発者にとって最悪のタイムロスです。

僕も DYSTOPIA の全面リニューアルを始めた 2025 年 5 月、この地獄を踏みました。作業ツリーが 1 つしかない以上、物理的に 3 並列は不可能だったのです。

Git worktree = 1 リポジトリから複数の作業ディレクトリを生やす機能

答えが git worktree です。これは Git に標準搭載されている機能で、1 つのリポジトリから複数の作業ディレクトリを物理的に生やせる というもの。

概念図

~/repo            ← メイン(main ブランチ)
~/repo-wt/
├─ feat-image/    ← feat/image-upload ブランチ専用のディレクトリ
├─ feat-profile/  ← feat/profile-cover ブランチ専用のディレクトリ
└─ fix-notify/    ← fix/notification ブランチ専用のディレクトリ

各ディレクトリは 完全に独立した作業ツリー です。.git 本体は共有しているので、ディスクは節約できます。でも git switch の取り合いは起きません。3 AI が別々のディレクトリで別々のブランチを触り続けるだけです。

実際のコマンド

僕が実運用している最小セットです。

# 1. メインリポジトリの親ディレクトリで準備用ディレクトリを作る
mkdir -p ~/repo-wt

# 2. 新しいブランチを切ると同時に worktree を生やす
cd ~/repo
git worktree add -b feat/image-upload ../repo-wt/feat-image

# 3. 別の AI を走らせるブランチも生やす
git worktree add -b feat/profile-cover ../repo-wt/feat-profile

# 4. 確認
git worktree list

git worktree list で現在生えている worktree が一覧できます。使い終わったら git worktree remove ../repo-wt/feat-image で片付け。ブランチ自体は残るので、そのまま PR を作って問題ありません。

3 レーン同時実装の具体例

僕の 2025 年 10 月の DYSTOPIA リニューアル中の運用を晒します。

レーンディレクトリ動かす AIタスク
A~/repoCursor + Codex 拡張メイン画面 UI の改装
B~/repo-wt/feat-imageCodex CLI(ターミナル)画像投稿機能の実装
C~/repo-wt/fix-notifyClaude Code(別ターミナル)通知バグ調査・修正
DCodex Cloud(ブラウザ)クラウド Codex同一タスクを 4 バリアント生成

A〜C は Mac mini 1 台で同時稼働。D はクラウドなのでスマホから投げるだけ。

ポイントは 「同じ物理マシンなのに、AI から見ると別プロジェクトに見える」 こと。各 worktree は .git をリンクしているだけで、作業ディレクトリ・node_modules・ビルド成果物は分離されます。つまり Codex が feat/image-uploadnpm install しても、隣のレーンのビルドは巻き込まれません。

これを始めた結果、実装スループットが 1 日 30 コミット超 まで跳ねました。2025 年 5 月に Claude Code 単独で詰んでいた機能が、9 月には 3 レーン並列でサクサク通るように。正社員エンジニア 5 人チームでも、コミュニケーションコストを考えるとこの速度は出せません。

ディレクトリ設計の勘所

worktree を導入した直後、僕自身が何度かハマった落とし穴です。

1. worktree はリポジトリと同じ階層に並べる

最初、~/repo/worktrees/ のようにリポジトリ配下に置いていました。これは エディタの再帰検索やファイル監視が誤作動する のでやめた方がよいです。.gitignore で除外する手もありますが、事故りやすい。

僕のおすすめは ~/repo~/repo-wt/ を兄弟ディレクトリにする構成。Cursor で ~/repo-wt/feat-image を別ウィンドウで開けば、完全に独立したプロジェクトとして扱えます。

2. ブランチ名とディレクトリ名は揃える

feat/image-upload ブランチなら feat-image ディレクトリ。スラッシュはディレクトリ名に使いづらいので、ハイフンに落とすか、スラッシュ対応 FS 前提で feat/image-upload/ のまま掘る。揃えておくと、ディレクトリを見るだけでどのブランチか即判別 できます。3 AI 並列で走らせていると、これが効いてきます。

3. 環境変数ファイル(.env 系)はシンボリックリンク

worktree を作ると .env.local などの gitignore 対象ファイルはコピーされません。毎回コピペするのは事故のもとなので、シンボリックリンクで親から引きます。

cd ~/repo-wt/feat-image
ln -s ~/repo/.env.local .env.local

これで環境差分ゼロで走り出せます。

AI エージェントごとの役割分担

worktree で並列化するだけでは足りません。各レーンでどの AI を走らせるか の使い分けがワークフロー全体の完成度を決めます(詳しくは マルチ AI コーディングエージェントのワークフロー)。僕の 2026 年 4 月時点の使い分けは:

  • Codex(2026 年 4 月時点は GPT-5 Codex 系、推論ティア high):堅実レーン。課金ロジックや決済、既存コードのリファクタリング
  • Claude Code(2026 年 4 月時点は Claude Opus 4.7 / Sonnet 4.6 系):中間レーン。UI の細かい調整、レビュー対応
  • Gemini 3 Pro(Antigravity 経由、2026 年 4 月時点):暴れ馬レーン。ゼロからの UI デザインや大きな改装

Codex は秀才、Gemini は天才で正義を聞かない、Claude Code はその中間。タスクの性質に合わせてどの AI にどの worktree を持たせるかを決めます(料金・プラン条件は 2026 年 4 月時点、為替・改定で変動)。

初心者が最初にやるべきこと

「worktree、便利そうだけど怖い」という方へ、僕がおすすめする導入ステップ。

  1. AI を 1 つだけ動かす ことに慣れる(Cursor の導入ガイド を参照)
  2. 2 並列を試すgit worktree add -b feat/try ../repo-wt/try で 1 本だけ生やし、そこで別 AI を走らせる
  3. 仕様駆動開発 と組み合わせる:各 worktree に 1 つの spec を貼って AI に実装させる。レーンが増えるほど仕様明確化が効く

いきなり 4 並列は脳が焼けます。1 → 2 → 3 と段階を踏んでください。

よくあるトラブルと回避策

  • 「同じブランチを 2 つの worktree で開けない」エラー:1 ブランチ 1 worktree が原則。AI レーンごとに別ブランチを切ってください
  • node_modules がレーンごとに膨らむ:pnpm の store や npm の cache 共有で 1/3 程度まで削れます
  • worktree ディレクトリが残ってしまうgit worktree remove --force <path> で強制削除 → git worktree prune で掃除

注意:AI 駆動開発の並列化は 1〜2 ヶ月で最適解が変わる

AI モデルとツールが激変しているので、今この記事で書いた構成も数ヶ月後には古くなっているはずです。2025 年 5 月は Claude Code 単独、9 月は Codex 3 並列、12 月は Gemini 3 Pro + Codex + Claude Code の 3 レーン。毎月の再評価 が前提です。

それでも git worktree という土台そのものは当面変わらない と思っています。これは Git の機能であって AI の機能ではないからです。土台を先に固めておけば、その上に載せる AI を差し替えるだけで済みます。これが、僕が worktree を「AI 駆動開発の必修技術」と言い切る理由です。

関連する記事

AI駆動開発のご相談・お仕事のご依頼

株式会社CAEN(代表:大森翔吾)では、Git worktree を使った並列 AI 開発ワークフローの導入支援、チーム向けの AI 駆動開発ハンズオン、マルチ AI 運用の設計コンサルを承ります。

「Claude Code / Codex / Cursor を同時に走らせたいが壊れるのが怖い」「個人開発者のワークフローをチームに展開したい」など、お気軽にご相談ください。