TL;DR
- Claude Code・Codex CLI・OpenCode といった ターミナル常駐型のAIコーディングエージェント を 1 つのリポジトリで複数同時に走らせると、同じ作業ディレクトリを取り合って ファイルの競合・ビルドの破壊・ブランチの混線 が起きる。
- これを解決する定番が
git worktreeだ。1 つの.gitオブジェクトストアを共有しながら、ブランチごとに独立した作業ディレクトリ を切り出せる。フルクローンと違ってディスクも履歴も二重化しない。 - 本記事は 標準の
git worktreeコマンドだけ で 2 つのエージェントを競合なく並列実行する最短ワークフロー（誰でも再現可能）を示し、node_modules/.envのハマりどころ、差分のレビュー＆マージ、後片付けまでをハンズオンでまとめる。 - 最後に、この手順を GUI / CLI で自動化する OSS ツール（
parallel-codeほか）も紹介する。ツールに乗る前に 素の git で原理を理解しておく と、どのエージェントでも応用が利く。
なぜ「並列実行」で git worktree なのか
AI コーディングエージェントは、ファイルの読み書き・テスト実行・コミットまでを 作業ディレクトリ上で直接 行う。1 つのタスクなら問題ないが、「機能 A の実装」「バグ B の修正」「リファクタ C」を 同時に別エージェントへ投げたい ときに壁にぶつかる。
素朴に同じディレクトリで 2 つのエージェントを起動すると、次が起きる。
- エージェント A が編集中のファイルを、エージェント B が別の意図で上書きする
- 一方が
git checkoutでブランチを切り替えると、もう一方の作業中ファイルが巻き戻る -
npm run buildやpytestが、互いの未完成の変更を巻き込んで失敗する
対策として「タスクごとにリポジトリをまるごと git clone する」方法もあるが、履歴とオブジェクトを毎回コピーするためディスクを浪費し、依存関係の再インストールも重い。
git worktree は、この問題のために存在する Git 標準機能だ。1 つのリポジトリの .git オブジェクトストアを共有したまま、追加の作業ディレクトリ（ワークツリー）を任意の場所に展開 できる1。各ワークツリーは独立したブランチを HEAD として持つため、エージェントごとに作業を完全分離しつつ、コミット履歴は 1 か所に集約される。Git worktree が「同一コードベースで複数の AI コーディングエージェントを並列実行するための支配的な分離プリミティブ」になっている、と複数の実践記事が指摘している2。
ハンズオン1: 2 つのエージェントを競合なく並列起動する
ここでは標準の git worktree コマンドだけを使う。特定ツールに依存しないので、Claude Code でも Codex CLI でも、手元の好きなエージェントで再現できる。
Step 1: ワークツリーを 2 つ切り出す
既存のリポジトリのルートで、タスクごとに 新しいブランチ付きのワークツリー を作る。
# プロジェクトのルートにいる前提（例: ~/work/myapp）
cd ~/work/myapp
# 機能Aのワークツリーを、リポジトリの外の隣接ディレクトリに作る
git worktree add ../myapp-feature-a -b feature-a
# バグBのワークツリーをもう1つ作る
git worktree add ../myapp-fix-b -b fix-b
git worktree add <パス> -b <ブランチ名> は、指定パスに作業ディレクトリを作り、そこで 新規ブランチ をチェックアウトする1。-b を付けなければ既存ブランチをそのワークツリーに割り当てる。
ポイント: ワークツリーは リポジトリの外（隣接ディレクトリ） に置くのが安全だ。リポジトリ内に作ると、エージェントが誤って自分のワークツリーを成果物としてコミット対象に含めてしまうことがある。
現在のワークツリー一覧はいつでも確認できる。
git worktree list
/home/user/work/myapp a1b2c3d [main]
/home/user/work/myapp-feature-a e4f5a6b [feature-a]
/home/user/work/myapp-fix-b 7c8d9e0 [fix-b]
Step 2: それぞれのワークツリーでエージェントを起動する
ターミナルを 2 枚開き、各ワークツリーのディレクトリで別々のエージェントを走らせる。
# ターミナル1
cd ../myapp-feature-a
claude # 機能Aの実装を依頼
# ターミナル2（別タブ）
cd ../myapp-fix-b
codex # バグBの修正を依頼
両者は 物理的に別ディレクトリ で動くため、ファイルの取り合いも、ブランチ切り替えによる巻き戻しも発生しない。.git は共有しているので、片方でコミットした内容はもう片方からも git fetch 不要で（同じローカルリポジトリの参照として）見える。
ハンズオン2: node_modules と .env のハマりどころ
ここが並列ワークツリー運用の最大のつまずきポイントだ。git worktree add で作られるのは 追跡対象ファイルのチェックアウトだけ で、.gitignore 済みの node_modules/ や .env は新しいワークツリーには 含まれない。
そのままだと各ワークツリーで npm install をやり直すことになり、時間もディスクも食う。実用上は次のどちらかで解決する。
方法A: 依存ディレクトリをシンボリックリンクで共有する
ビルド済み依存を使い回したいときは、本体のワークツリーから node_modules を symlink する。
cd ../myapp-feature-a
ln -s ../myapp/node_modules ./node_modules
ただし、ワークツリー間で 依存バージョンが食い違うタスク を走らせるなら共有は危険だ。その場合は方法 B を採る。
方法B: 環境ファイルだけコピーし、依存は個別インストール
.env のような小さな設定ファイルはコピー、依存は各ワークツリーで個別に入れる。
cd ../myapp-feature-a
cp ../myapp/.env ./.env # 秘匿情報はコミットしないこと
npm install # このワークツリー専用の依存を入れる
parallel-code のような自動化ツールは、この「node_modules などの ignore 済みディレクトリをワークツリーへ symlink する」処理を タスク作成時に自動で行う3。手動運用でも、上の 1〜2 行をワークツリー作成直後の定型作業にしておくと事故が減る。
セキュリティ注意:
.envや認証トークンを含むファイルを複数ワークツリーに展開する場合、それらが各ワークツリーの.gitignoreでも除外されていることを必ず確認する。ワークツリーを増やすほど、秘匿情報をうっかりコミットする経路も増える。
ハンズオン3: 差分をレビューして「勝ち」だけマージする
並列エージェントの強みは、複数の案を同時に走らせて、良いものだけ採用 できる点にある。各ワークツリーはブランチなので、レビューもマージも通常の Git フローそのままだ。
各ワークツリーの成果を確認する
# 機能Aブランチの変更を、メインのワークツリーから差分表示
cd ~/work/myapp
git diff main..feature-a --stat
git diff main..fix-b --stat
良い変更だけ取り込む
採用すると決めたブランチを main にマージする。
git switch main
git merge --no-ff feature-a # 機能Aを採用
不採用のワークツリーは、後片付け（次節）でブランチごと破棄すればよい。「ダメな案はワークツリーごと捨て、良い案だけ main に集約する」——これが並列ワークツリー運用の基本リズムだ3。
後片付け: ワークツリーとブランチを安全に消す
タスクが終わったらワークツリーを削除する。ディレクトリを rm -rf で消すだけでは Git の管理情報が残るため、専用コマンドを使う。
# ワークツリーを削除（未コミットの変更・未追跡ファイルがあると拒否される=安全）
git worktree remove ../myapp-feature-a
# ディレクトリを手動削除してしまった場合は管理情報を掃除
git worktree prune
# 不採用ブランチを削除
git branch -D fix-b
git worktree remove は、未コミットの変更や未追跡ファイルが残っている「clean でない」ワークツリーを デフォルトでは削除しない ので、うっかり作業を失う事故を防げる1。強制削除したいときだけ --force を付ける。
自動化する: OSS ツール群
素の git worktree で原理を押さえたら、定型作業（ワークツリー作成 → 依存リンク → エージェント起動 → 差分レビュー）を自動化するツールに乗ると速い。代表的な OSS を挙げる。
-
parallel-code（MIT ライセンス）: タスクを作ると自動で「main からブランチ作成 → ワークツリー展開 →
node_modules等を symlink → エージェント起動」まで行い、複数タスクの差分を並べてレビュー・マージできる。Claude Code・Codex CLI・Gemini CLI・Copilot CLI・Antigravity CLI に対応する3。デスクトップアプリ（Electron）として動く。 -
その他の CLI / 並列ランナー:
agentree・ccswarm・各種 worktree ランナーなど、ターミナルからgit worktreeベースの並列実行を扱うツールが揃ってきている。最新の一覧は、CLI コーディングエージェントを網羅したキュレーションawesome-cli-coding-agentsが参考になる4。
ツール選定の指針はシンプルだ。GUI で差分レビューを重視するなら parallel-code 系、ターミナル内で完結させたいなら CLI ランナー系。いずれも内部でやっていることは本記事のハンズオンと同じ git worktree なので、挙動が読めなくなったら素の git コマンドに立ち返ればよい。
ハマりどころまとめ
| 症状 | 原因 | 対策 |
|---|---|---|
| 新ワークツリーでビルドが通らない |
node_modules は worktree に含まれない |
symlink（方法A）か個別 npm install（方法B） |
| エージェントが自分のワークツリーをコミットしようとする | ワークツリーをリポジトリ内に作った | リポジトリ 外 の隣接ディレクトリに作る |
git worktree remove が失敗する |
未コミットの変更が残っている（安全装置） | 変更を確認・コミットしてから削除。捨てるなら --force
|
ディレクトリを消したのに worktree list に残る |
管理情報が残存 |
git worktree prune で掃除 |
ブランチが消せない（-d が拒否） |
そのブランチがどこかのワークツリーで HEAD になっている | 先にワークツリーを remove してから削除 |
| 同じブランチを2つのワークツリーで開けない | Git の仕様（1 ブランチ = 1 ワークツリー） | タスクごとに別ブランチを切る |
まとめ
- 複数の AI コーディングエージェントを 1 リポジトリで並列に走らせるなら、
git worktreeでタスクごとに独立した作業ディレクトリ を切るのが競合ゼロの王道だ。 - 手順は「
git worktree addで切る → 各ディレクトリでエージェント起動 → 差分をレビューして良い案だけmainにマージ →git worktree removeで片付け」の 4 ステップに集約される。 - つまずくのはたいてい
node_modules/.envまわり。symlink か個別インストールを ワークツリー作成直後の定型作業 にしておけば事故は激減する。 - 自動化ツール（
parallel-codeほか）は便利だが、中身は同じgit worktree。素の git で原理を理解しておく ことが、どのエージェント・どのツールでも応用が利く最短経路になる。
-
git-worktree 公式ドキュメント（コマンド仕様・
add/list/remove/pruneの挙動）。https://git-scm.com/docs/git-worktree ↩ ↩2 ↩3 -
"Git worktrees for parallel AI coding agents" — Upsun Developer。git worktree が並列 AI エージェント実行の分離プリミティブとして定着している点の解説。https://developer.upsun.com/posts/ai/git-worktrees-for-parallel-ai-coding-agents ↩
-
johannesjo/parallel-code（MIT）。タスク作成時にブランチ作成・ワークツリー展開・
node_modules等の symlink・エージェント起動を自動化。対応エージェントの一覧を含む。https://github.com/johannesjo/parallel-code ↩ ↩2 ↩3 -
bradAGI/awesome-cli-coding-agents — CLI コーディングエージェント・並列ランナー・自律ループのキュレーション（2026-06-15 更新）。https://github.com/bradAGI/awesome-cli-coding-agents ↩