◉ANTIGRAVITY LABEN
記事一覧/Editor View
⟐ Editor View/2026-04-12中級

Antigravity × git worktree で並列開発を加速する — マルチワークスペース実践ガイド

git worktree と Antigravity のマルチワークスペースを組み合わせ、複数ブランチの同時開発を実現する実践ガイド。セットアップからコンフリクト回避まで具体的に解説します。

antigravity435git-worktree3parallel-developmentworkspace6productivity19

ブランチを切り替えるたびに手が止まる問題

フロントエンドの新機能を実装していたら、本番で緊急バグが見つかった。git stash して git checkout hotfix して修正を入れて、また元のブランチに戻して git stash pop します。戻ったら npm の依存関係が壊れていて node_modules を再インストール——こんな経験は一度や二度ではないはずです。

Antigravity のマルチワークスペース機能と git worktree を組み合わせると、この問題が根本から解消します。ブランチごとに独立したディレクトリを持ち、それぞれに AI エージェントを割り当てて並列に作業できます。stash も不要、依存関係の衝突もありません。

ここではgit worktree の基本からAntigravity での実践的な並列開発ワークフローまでを、個人開発で実際に使っているパターンをベースに解説します。

git worktree とは何か — ブランチの物理的分離

git worktree は、1つのリポジトリから複数の作業ディレクトリを作成する Git の標準機能です。通常の git clone と違い、.git オブジェクトを共有するためディスク容量を節約でき、ブランチ間のコミット履歴も即座に参照できます。

# メインリポジトリ（すでに clone 済み）
cd ~/projects/my-app
 
# hotfix 用の worktree を作成
git worktree add ../my-app-hotfix hotfix/payment-bug
 
# 新機能用の worktree を作成
git worktree add ../my-app-feature feature/user-dashboard

この時点で3つの独立したディレクトリが存在する:

  • ~/projects/my-app — main ブランチ（元のディレクトリ）
  • ~/projects/my-app-hotfix — hotfix ブランチ
  • ~/projects/my-app-feature — feature ブランチ

それぞれが完全に独立したファイルシステムを持つため、片方で npm install しても他方に影響しません。ここが git stash + git checkout との決定的な違いです。

Antigravity のワークスペースと worktree を接続する

Antigravity の Agent Manager では、左ペインの「Open Workspace」から任意のディレクトリを開ける。git worktree で作成した各ディレクトリをそれぞれ別のワークスペースとして開くことで、ブランチごとに独立した AI エージェントが稼働する環境が整う。

ステップ 1: worktree の作成と依存関係のセットアップ

# プロジェクトルートで実行
cd ~/projects/my-app
 
# feature ブランチ用の worktree
git worktree add ../my-app-feat feature/new-api
cd ../my-app-feat
npm install  # この worktree 専用の node_modules が生成される
 
# hotfix ブランチ用の worktree
cd ~/projects/my-app
git worktree add ../my-app-fix hotfix/auth-error
cd ../my-app-fix
npm install

ステップ 2: Antigravity で各ワークスペースを開く

Agent Manager を開き、各 worktree ディレクトリをワークスペースとして追加します。ワークスペース名はディレクトリ名から自動的に設定されるが、分かりやすい名前に変更しておくとよい。

Workspace 1: my-app-feat  → "新API開発"
Workspace 2: my-app-fix   → "認証バグ修正"
Workspace 3: my-app       → "main（レビュー・マージ用）"

ステップ 3: 各ワークスペースに AGENTS.md を配置

worktree ごとに異なる AGENTS.md を置くことで、エージェントの挙動をブランチの目的に合わせて制御できます。これは通常のブランチ切り替えでは実現しにくいテクニックです。

<\!-- my-app-feat/AGENTS.md -->
# エージェント指示
 
## コンテキスト
新しい REST API エンドポイントの実装。OpenAPI 仕様に厳密に従うこと。
 
## ルール
- src/api/ 配下のファイルのみ変更可
- テストは必ず src/__tests__/api/ に追加
- 既存のエンドポイントは変更禁止
<\!-- my-app-fix/AGENTS.md -->
# エージェント指示
 
## コンテキスト
認証フローの緊急バグ修正。最小限の変更で問題を解決する。
 
## ルール
- 変更はバグ修正に直接関係するファイルのみ
- リファクタリングは行わない
- 修正前後の動作を示すテストを必ず追加

この方法の利点は、エージェントがスコープ外のファイルを意図せず変更するリスクを大幅に減らせることです。「hotfix ブランチなのに関係ないリファクタリングをされた」という事故は、個人開発でも時間のロスが大きいです。

実践パターン: 個人開発での3ワークスペース構成

私が日常的に使っているのは「開発・修正・レビュー」の3ワークスペース構成です。

# セットアップスクリプト（プロジェクトルートに置いておく）
#\!/bin/bash
PROJECT_ROOT=$(pwd)
PROJECT_NAME=$(basename "$PROJECT_ROOT")
 
# 作業用 worktree の作成
setup_worktree() {
  local branch=$1
  local suffix=$2
  local dir="../${PROJECT_NAME}-${suffix}"
  
  if [ -d "$dir" ]; then
    echo "✓ ${dir} は既に存在します"
    return
  fi
  
  # ブランチが存在しなければ作成
  git branch "$branch" 2>/dev/null || true
  git worktree add "$dir" "$branch"
  
  # 依存関係のインストール（package.json がある場合）
  if [ -f "${dir}/package.json" ]; then
    cd "$dir" && npm install && cd "$PROJECT_ROOT"
  fi
  
  echo "✓ ${dir} をセットアップしました"
}
 
setup_worktree "develop" "dev"
setup_worktree "hotfix/current" "fix"
 
echo ""
echo "Antigravity で以下のディレクトリを開いてください:"
echo "  1. ${PROJECT_ROOT}         → main（レビュー・マージ）"
echo "  2. ../${PROJECT_NAME}-dev  → develop（新機能開発）"
echo "  3. ../${PROJECT_NAME}-fix  → hotfix（緊急修正）"

ワークスペースごとの役割分担

ワークスペース 1（develop）: ここがメインの開発場所。新機能の実装、UI の構築、テストの追加を AI エージェントと協力して進める。Plan Mode を使って大きなタスクを分解し、段階的に実装します。

ワークスペース 2（hotfix）: 本番で見つかったバグの修正専用。エージェントには最小限の変更のみを許可する AGENTS.md を設定します。修正が終わったらすぐに main にマージして deploy します。

ワークスペース 3（main）: コードレビューとマージの拠点。他の worktree で完了した PR をここで確認し、AI にレビューを依頼します。git log --oneline --all で全ブランチの進行状況を俯瞰できます。

コンフリクトを未然に防ぐ3つのルール

並列開発で最も厄介なのがマージコンフリクトです。以下の3つのルールを守ることで、コンフリクトの発生率を大幅に下げられます。

ルール 1: ファイルの担当を worktree ごとに分離する

# AGENTS.md で変更可能なパスを制限する
# develop worktree
- src/features/ 配下のみ変更可
 
# hotfix worktree  
- src/lib/auth/ 配下のみ変更可

同じファイルを2つの worktree で同時に編集しません。これが最も効果的なコンフリクト防止策です。

ルール 2: 共通ファイルの変更は main でのみ行う

package.json、設定ファイル、共通ユーティリティなど複数の機能が依存するファイルは、main ワークスペースでのみ変更します。変更後は各 worktree で git pull origin main --rebase を実行します。

# 各 worktree で定期的に main の変更を取り込む
cd ~/projects/my-app-dev
git fetch origin main
git rebase origin/main

ルール 3: 短いサイクルでマージする

worktree を長期間放置すると、main との差分が広がりコンフリクトのリスクが高まる。hotfix は即日マージ、feature は3日以内を目安にします。

worktree のライフサイクル管理

作り放題にすると管理が煩雑になります。使い終わった worktree は速やかに削除します。

# 現在の worktree 一覧を確認
git worktree list
# 出力例:
# /home/user/projects/my-app       abc1234 [main]
# /home/user/projects/my-app-dev   def5678 [develop]
# /home/user/projects/my-app-fix   ghi9012 [hotfix/current]
 
# マージ済みの hotfix worktree を削除
cd ~/projects/my-app
git worktree remove ../my-app-fix
 
# ブランチも不要なら削除
git branch -d hotfix/current

Antigravity 側では、削除した worktree のワークスペースも閉じておくこと。存在しないディレクトリを参照したワークスペースはエラーになります。

git-worktree-runner で自動化する

手動のセットアップが面倒なら、git-worktree-runner を使うと worktree の作成から依存関係のインストール、エディタ連携まで一括で処理できます。

# インストール
git clone https://github.com/coderabbitai/git-worktree-runner.git
cd git-worktree-runner
chmod +x wt.sh
 
# 新しい worktree を作成（設定ファイルのコピーと npm install も自動実行）
./wt.sh create feature/payment-v2
 
# Antigravity で自動的にワークスペースとして開く
./wt.sh open feature/payment-v2 --editor antigravity

このツールは .env、.vscode/settings.json などの設定ファイルを自動でコピーしてくれるため、worktree ごとに環境設定をやり直す手間がありません。

Before/After: stash ワークフローとの比較

Before（従来の stash ワークフロー）:

  1. 作業中のコードを git stash — 未保存の変更があると stash が複雑化
  2. git checkout hotfix — ブランチ切り替え
  3. npm install — 依存関係が異なれば再インストール（数十秒〜数分）
  4. バグ修正 → コミット → プッシュ
  5. git checkout feature — 元のブランチに戻る
  6. git stash pop — stash の衝突が起きることも
  7. npm install — また再インストール

所要時間: 10〜15分（作業の中断 + 復帰のオーバーヘッド）

After（worktree + Antigravity ワークフロー）:

  1. Agent Manager で hotfix ワークスペースをクリック
  2. バグ修正を指示 → エージェントが修正 → コミット → プッシュ
  3. 開発ワークスペースに戻って作業を継続

所要時間: 2〜3分（ワークスペース切り替えのみ。stash なし、npm install なし）

コンテキストスイッチのコストがほぼゼロになるのが最大の利点です。特に、AI エージェントが各ワークスペースで独立した会話履歴を保持するため、「さっきまで何をしていたか」を再説明する必要もありません。

注意点: 同一ブランチを複数 worktree で開かない

git worktree には「同一ブランチを2つ以上の worktree で同時にチェックアウトできない」という制約があります。

# これはエラーになる
git worktree add ../my-app-2 main
# fatal: 'main' is already checked out at '/home/user/projects/my-app'

この制約は安全装置として機能しています。同じブランチを2箇所で編集すると、どちらのコミットが正しいか分からなくなるためです。ブランチを共有したい場合は、一方を新しいブランチにして作業後にマージする設計にすること。

全体を振り返って: 次にやること

git worktree add を1つ試してみること。既存のプロジェクトで hotfix ブランチ用の worktree を1つ作り、Antigravity の別ワークスペースとして開くだけでいい。stash に戻れなくなるはずです。

プロジェクト固有のルールを AGENTS.md で worktree ごとに設定する方法は、Antigravity のコンテキスト制御テクニックで詳しく解説しています。コンフリクトが発生した場合の AI アシスト解決法は、git コンフリクト AI 解決ガイドを参照してほしい。

並列開発のスケーリングに興味があるなら、Antigravity のワークスペース最適化テクニックも合わせて読むと、ワークスペースの管理がさらに効率化できます。

シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • ✦コピー&ペーストで使える実装コード付き
  • ✦毎日新しい上級ガイドを追加
  • ✦¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

もしこの記事がお役に立ちましたら、チップ（¥150）で応援いただけると大変励みになります。広告なしでの運営を続けるため、皆さまのご支援が大きな力になっています。

関連記事

⟐ Editor View2026-03-31
Antigravity Editor 上級カスタマイズガイド — キーバインド・スニペット・AIルール・ワークスペース設定で生産性を極限まで引き上げる
Antigravity Editorのキーバインド、カスタムスニペット、AIルール、ワークスペース設定を徹底的にカスタマイズし、開発生産性を最大化する上級テクニックを解説します。
⟐ Editor View2026-07-08
Antigravity がクラウド同期フォルダのファイルを空として読む問題—オンラインオンリー・プレースホルダーの落とし穴
Finder には確かに見えているファイルを、Antigravity のエージェントが「空」「見つからない」と言い張る――クラウド同期フォルダのオンラインオンリー・プレースホルダーが原因です。症状の見分け方から実体の取得、作業フォルダの設計までを順にまとめました。
⟐ Editor View2026-06-15
Antigravity 2.0 デスクトップで複数エージェントを同時監督するときの画面と割り込みの設計
Antigravity 2.0 が『エージェント管制塔』へ再定義された今、デスクトップで複数エージェントを同時に走らせるときの画面構成・割り込み判断・状態の見える化を、実作業の手順とともに整理しました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →