同時に動かす。
混ぜない。

AIエージェントを二体に増やせば、開発速度も二倍になる。

この理解は半分だけ正しいものです。

コードを生成する速度は上がります。しかし、複数の変更を読み、前提を揃え、競合を解消し、テストしてmainへ統合する作業も増えます。実装だけを並列化し、統合方法を決めなければ、完成したブランチと未確認のPull Requestが積み上がります。

Netsujoでは、ChatGPT、Claude Code、Codexを設計・実装・監査へ分ける運用を試してきました。その役割分担と、全変更へ三つのAIを直列接続する限界は、ChatGPT・Claude Code・Codexの分業開発で整理しています。

本記事が扱うのは、その次の問題です。

**同じリポジトリで、複数のAIエージェントを同時に動かすとき、どうすれば互いの作業を壊さず、mainへ安全に統合できるのか。**

結論は単純です。

実装は並列化する。mainへの統合は直列化する。

そのために必要なのは、エージェントを増やすことではありません。作業場所、変更責任、実行環境、統合権限を分け、依存関係に沿って一つずつ統合する仕組みです。

開発速度を決めるのは、最も遅い工程である

AIエージェントによる開発は、次の三工程に分けられます。

AIエージェントを増やすと、実装能力は増えます。一方、統合責任者が一人のままなら、統合能力は自動では増えません。

実効的なスループットは、最も遅い工程に制約されます。

たとえば、三つのエージェントが一日に三本のPull Requestを作っても、人間が一日に一本しかレビュー・統合できなければ、二本は在庫になります。翌日も同じ速度で実装を増やせば、古いbase commitを前提とした変更が増え、競合確率も上がります。

この状態で必要なのは四体目のエージェントではありません。

• タスクを小さくする
• 並列化する対象を選ぶ
• 共有部分の所有者を決める
• 統合待ちの上限を決める
• 新しい作業より先に、既存のPull Requestを閉じる

AIエージェント活用の指標を「同時に何体動かしたか」に置くと、未統合の成果物を増やすこと自体が目的になります。見るべきなのは、mainへ安全に入った変更の量と、統合までの時間です。

Gitコンフリクトより危険な「前提のコンフリクト」

複数のエージェントを動かしたとき、最も分かりやすい問題はGitのマージコンフリクトです。

同じファイルの同じ行を二つのブランチが編集すれば、Gitが競合を知らせます。しかし、Gitが検知できるのはテキスト上の衝突です。

実務では、次の四種類を分けて考える必要があります。

1. テキストのコンフリクト

同じファイルの近い行を編集する競合です。

例として、二つのエージェントが同じReactコンポーネントのpropsや同じ設定ファイルを変更した場合があります。これはGitが検知できます。

2. 仕様のコンフリクト

異なるファイルを編集していても、前提としている仕様が食い違う状態です。

たとえば、API担当がレスポンスを次の形へ変更したとします。

ts { goal: { id: string; label: string; } }

一方、UI担当が古い形を前提に実装している場合があります。

ts { goalId: string; goalLabel: string; }

編集ファイルが異なるため、Git上の競合は発生しません。それでも、統合後のtypecheck、build、実行時には壊れます。

3. 実行環境のコンフリクト

worktreeを分けても、次の資源は共有される可能性があります。

• ローカルデータベース
• 開発サーバーのポート
• Redisやキュー
• 外部APIのテスト環境
• オブジェクトストレージ
• キャッシュ
• テストデータ
• 環境変数
• データベースマイグレーション

二つのエージェントが別々のworktreeで作業していても、両方が同じデータベースへマイグレーションを実行すれば、互いの前提を壊します。

4. 統合順序のコンフリクト

依存関係のあるPull Requestを、完成した順にマージすることで発生します。

UI変更が新しいAPI契約へ依存しているのに、UI側を先にmainへ入れれば、一時的に壊れた状態になります。コード単体で正しくても、順序が間違えばmainは正しくありません。

**マージコンフリクトがないことと、安全に統合できることは同じではありません。**

並列化してよいタスクの条件

すべてのタスクを並列化する必要はありません。

並列化するかどうかは、エージェントの能力ではなく、タスク間の依存関係で決めます。

並列化しやすいタスク

• 独立したページやコンポーネントの実装
• 既存仕様に対するテスト追加
• ドキュメント作成
• ログや計測処理の追加
• 変更を伴わないコード調査
• 読み取り専用のセキュリティレビュー
• 異なるパッケージやサービスの修正

共有契約を固定すれば並列化できるタスク

• バックエンドAPIとフロントエンドUI
• 共通コンポーネントと利用側画面
• データモデルとバリデーション
• 実装とE2Eテスト
• デザインシステムと各画面

この場合は、API型、props、スキーマ、イベント名、エラー形式、空値の扱いなどを先に確定します。

直列で進めるべきタスク

• 同じデータベースマイグレーションの変更
• 認証・認可の中核ロジック
• 共通型定義の大規模変更
• 依存ライブラリの一括更新
• lockfileを伴う複数のパッケージ変更
• リポジトリ全体を横断するリネーム
• 方針が未確定な大規模リファクタリング

並列化の前には、次の三問へ答えます。

1. それぞれのタスクを独立して完了判定できるか
2. 変更するファイルやディレクトリを事前に予測できるか
3. 一方の結果によって、もう一方の前提が変わらないか

一つでも明確に答えられない場合は、分割方法を見直すか、直列で進めます。

並列開発を支える四つの分離

安全な並列開発には、四つの分離が必要です。

1. 作業場所を分ける

エージェントごとにworktreeを分けます。

同じ作業ディレクトリで複数のエージェントを動かすと、未コミット変更、生成ファイル、依存関係の更新が混在します。どのエージェントが何を変えたか分からなくなり、片方の検証中にもう片方がファイルを書き換えることもあります。

2. 変更責任を分ける

各エージェントが変更してよいパスを定義します。

「UI担当」「API担当」という機能名だけでは不十分です。UI実装中に共通型、設定、依存関係まで変更する可能性があるため、許可パスと禁止パスを明示します。

3. 実行環境を分ける

開発サーバー、ポート、データベース、テストデータ、外部サービスの名前空間を分けます。

環境を分けられない場合は、同時実行を禁止し、利用順序を決めます。

4. 統合権限を分ける

実装者とmainへの統合責任者を分けます。

エージェントが自分で実装し、自分で競合を解消し、自分でmainへマージする構成では、判断の独立性がありません。実装エージェントはPull Requestまで、mainへの統合は一人の責任者が行う方が追跡しやすくなります。

Git worktreeで作業場所を分ける

Git公式ドキュメントでは、一つのリポジトリに複数のworking treeを関連付け、複数のブランチを同時にcheckoutできる仕組みとしてworktreeが説明されています。

Claude Codeには、分離されたworktreeでセッションを開始する --worktree オプションがあります。Codexアプリにもworktreeの組み込みサポートがあり、複数のエージェントが同じリポジトリで別々のコピーを扱う構成が案内されています。

手動で作成する場合は、最初にmainを最新化します。

bash git fetch origin git switch main git pull --ff-only

UI実装用のworktreeを作ります。

bash git worktree add ../project-wt-goal-ui -b feat/goal-ui origin/main

API実装用のworktreeを作ります。

bash git worktree add ../project-wt-goal-api -b feat/goal-api origin/main

読み取り専用に近いレビュー用途では、detached HEADのworktreeも使えます。

bash git worktree add --detach ../project-wt-goal-review origin/main

現在のworktreeを確認します。

bash git worktree list

Gitは通常、同じブランチを複数のworktreeへ同時にcheckoutすることを拒否します。したがって、原則は**一つのタスクにつき、一つのブランチと一つのworktree**です。

Claude CodeをCLIから起動する場合は、公式ドキュメントで次の形が案内されています。

bash claude --worktree feature-auth

ただし、worktreeが分離するのは、主にファイル編集とGitの作業状態です。

次は自動では分かれません。

• API仕様
• データベース
• ポート
• 外部サービスのテスト環境
• gitignoredな環境ファイル
• キャッシュ
• lockfileの意味
• マージ順序

worktreeは並列化の開始地点であり、コンフリクト対策の完成形ではありません。

Task Contractで変更範囲を固定する

複数のエージェントへ依頼するとき、詳細な実装方法をすべて指示する必要はありません。

一方で、境界は細かく指定する必要があります。

特に重要なのは、「何を変更するか」よりも**何を変更してはいけないか**です。

Netsujoでは、エージェントへ渡す実装指示を、検証可能なTask Contractとして整理します。

```md

Task ID

goal-ui

目的

顧客の目標確認画面を追加する。

Base Commit

<開始時点のcommit SHA>

担当

UI実装エージェント

変更してよい範囲

• src/features/customer-goal/**
• src/components/customer-goal/**
• tests/customer-goal-ui/**

変更してはいけない範囲

• db/migrations/**
• src/shared/contracts/**
• src/server/**
• package.json
• pnpm-lock.yaml

依存する仕様

• GoalResponse v1
• POST /api/customer-goal
• error.codeは既存の列挙値を使用する

受け入れ条件

• 目標の確認・修正・保存ができる
• 既存画面の導線を維持する
• エラー時に再試行できる
• typecheckが通る
• 対象テストが通る

停止条件

次の場合は実装を停止し、変更せずに報告する。

• shared/contractsの変更が必要
• DBスキーマの変更が必要
• API仕様とTask Contractが矛盾する
• 担当外ファイルを変更する必要がある

完了報告

• commit SHA
• 変更ファイル一覧
• 実行した検証
• 残っている懸念
• Task Contractから逸脱した箇所

`

停止条件を入れる理由は、AIエージェントに無理やり完了させないためです。

担当範囲外の問題を発見したとき、その問題まで自動で修正させると、別エージェントの作業領域へ侵入します。

「必要なら関連箇所も改善してください」という指示は、単独作業では便利でも、並列開発では危険です。改善範囲が無制限になり、担当境界が消えるからです。

関連問題は直さず、次の形式で別タスクへ切り出します。

• 発見した問題
• 影響範囲
• 今回のタスクを止めるか
• 次に必要な担当者
• 依存するPull Request
• 推奨するマージ順

ファイル所有権は「予定」と「実績」の二段階で確認する

Task Contractを渡しても、実装中に変更範囲が広がることがあります。

そこで、編集前と完了時の二回、ファイル境界を確認します。

編集前

エージェントに変更予定を出させます。

```text 変更予定:

• src/features/customer-goal/GoalForm.tsx
• src/features/customer-goal/useGoal.ts
• tests/customer-goal-ui/goal-form.test.tsx

変更しない:

• src/shared/contracts/goal.ts
• db/migrations/**

`

別エージェントの予定ファイルと重なっていたら、その時点でタスクを分割し直します。

完了時

実際の差分を取得し、Task Contractと比較します。

bash git diff --name-only origin/main...HEAD

予定外のファイルがあれば、次のどれかを選びます。

1. 担当範囲を正式に拡張する
2. 予定外の変更を元に戻す
3. 別Pull Requestへ分離する
4. 依存タスクとして直列化する

予定外の変更を「ついでの改善」として黙って残すことが、後の競合を増やします。

実行環境もworktree単位で識別する

ファイルだけ分けても、実行環境が同じなら干渉は残ります。

最低限、次をworktreeごとに決めます。

分離できない共有資源には、ロックが必要です。

たとえば本番相当の共有ステージングDBへマイグレーションできるのは一つのタスクだけ、というルールを置きます。並列化できないものを無理に並列化しないことも、並列運用の一部です。

サブエージェントとworktreeは別の仕組みである

サブエージェントを増やせば、並列編集も安全になると考えやすいのですが、二つは別の問題です。

サブエージェントが主に分離するのは、役割、コンテキスト、プロンプト、利用できるツールです。

worktreeが分離するのは、ファイルを編集する作業場所です。

同じ作業ディレクトリを共有したままサブエージェントだけ増やしても、ファイル競合は解消されません。

実装は並列、統合は直列

二つのPull Requestが完成しても、同時にmainへ入れる必要はありません。

一つ目をマージした後、二つ目のブランチを最新のmainへ追従させ、検証をやり直します。

推奨する依存関係

text PR 0: 共有型・API契約 ├─ PR 1: バックエンド実装 └─ PR 2: フロントエンド実装 └─ PR 3: 統合テスト・監査修正

PR 0をmainへ入れた後、そのcommitを起点としてPR 1とPR 2を並列化します。

統合手順

1. 共有契約を先に確定する
2. 全エージェントを同じbase commitから開始する
3. 変更予定ファイルを申告させる
4. 各worktreeで対象検査を実行する
5. Pull Request単位で差分監査する
6. 依存関係に沿って一つずつマージする
7. 残っているブランチを最新mainへ追従させる
8. typecheck、test、buildを再実行する
9. マージ済みworktreeを削除する

main追従の例です。

bash git fetch origin git merge origin/main --no-edit

チームでrebaseを採用している場合は、同じ目的でrebaseしても構いません。重要なのは、統合方法を一つに固定し、追従後に検証をやり直すことです。

Claude CodeとCodexを実装競争させない

同じ目的に対してClaude CodeとCodexの両方へ実装させると、二つの実装案を比較し、片方を破棄し、必要な部分を再統合する作業が発生します。

比較実験が目的でなければ、実装競争は開発速度を下げます。

基本形は次です。

実装担当が出した差分を別のエージェントが監査し、修正は原則として元の実装担当へ戻します。

監査エージェントが別ブランチから直接修正を始めると、変更の所有者が増えます。緊急時を除き、監査と修正の権限を分けた方が履歴を追いやすくなります。

mainブランチを品質ゲートにする

「mainへ直接pushしない」というルールは、注意事項ではなくGitHub側の設定として強制します。

最低限、次を設定します。

• Pull Request経由の変更を必須にする
• required status checksを設定する
• レビューコメントの解決を必須にする
• mainへの直接pushを制限する
• 高リスク領域にはCODEOWNERSを設定する

GitHubの保護ブランチでは、required status checksが成功するまでマージを禁止できます。strict設定では、対象ブランチが最新のbase branchへ追従していることも要求できます。

ただし、strict設定ではmainが更新されるたびに、残りのPull RequestでCIを再実行する回数が増えます。

CI利用量を抑えたい場合は、検査を省略するのではなく、実行タイミングを分けます。

安価な検査を早く、高コストな検査を統合前へ置く構成です。

並列タスク管理表

複数のエージェントを起動する前に、次の表を作ります。

重要なのは担当者名ではありません。

• 変更可能範囲
• 依存先
• マージ順

この三つが空欄のままエージェントを起動すると、並列作業ではなく、無調整の同時作業になります。

統合待ちの上限を決める

AIエージェントは実装が速いため、人間は新しいタスクを起動し続けやすくなります。

しかし、未レビューのPull Requestが増えるほど、各ブランチのbase commitは古くなります。仕様変更、依存更新、他のマージが積み重なり、後から統合する費用が増えます。

運用上は、Work in Progressの上限を置きます。

例として、統合責任者一人なら次のように制限します。

• 実装中は最大二件
• レビュー待ちは最大二件
• Highリスク変更は同時に一件
• 上限に達したら、新規着手より統合を優先する

AIに仕事をさせ続けることより、mainを前へ進めることを優先します。

よくある失敗パターン

「関連箇所も含めて改善する」と指示する

担当範囲がリポジトリ全体へ広がります。

並列運用中は、発見した関連問題を修正させず、別タスクとして報告させます。

二つのエージェントへ同じブランチを渡す

未コミット変更や生成ファイルが混在し、どちらの変更か判別できなくなります。

一つのタスクにつき、一つのブランチと一つのworktreeを割り当てます。

共通型を各エージェントが独自に変更する

異なるファイルへ類似の型が作られ、統合時に仕様が分岐します。

共有型、API契約、DBスキーマには一人の所有者を置きます。

完成した順にマージする

依存先より利用側が先にmainへ入り、一時的に壊れた状態になります。

完成時刻ではなく、依存関係で順序を決めます。

AIへ意味判断を含むコンフリクト解消を丸投げする

import整理やファイル移動のように意図が明確な競合は任せられます。

一方、次の競合は統合責任者が残す仕様を決めます。

• API契約
• 認証・認可
• データベーススキーマ
• 料金・契約ロジック
• 共通型
• lockfile
• 環境設定

AIには、判断後の機械的な修正を担当させます。

長期間mainへ追従しない

worktreeを分けたまま長期間作業すると、base branchとの差が広がります。

小さな単位でPull Requestを作り、統合までの時間を短くします。競合リスクはエージェント数だけではなく、共有変更範囲と枝分かれしている時間によって増えます。

最低限の運用ルール

AIエージェントを並列で動かす場合、最低限、次を固定します。

1. 一つのタスクにつき、一つのブランチと一つのworktreeを使う
2. 全タスクのbase commitを記録する
3. 各エージェントへTask Contractを渡す
4. 変更可能パスと変更禁止パスを明記する
5. 共有契約、DBスキーマ、認証には一人の所有者を置く
6. DB、ポート、テストデータを分離する
7. エージェントからmainへ直接pushさせない
8. 完了時にcommit SHA、変更ファイル、検証結果、懸念点を報告させる
9. 実装担当と監査担当を分ける
10. mainへの統合は一人の責任者が順番に行う
11. 一つマージするたびに、残りのブランチをmainへ追従させる
12. マージ後にworktreeと不要ブランチを削除する

作業完了後は整理します。

bash git worktree remove ../project-wt-goal-ui git branch -d feat/goal-ui git worktree prune

終了条件には、コードのマージだけではなく、worktreeの削除まで含めます。

まとめ

AIエージェントを並列で動かすと、コードを書く能力は増えます。

その結果、ボトルネックは実装から統合へ移ります。

必要なのは、より多くのエージェントではありません。

• worktreeによる作業場所の分離
• Task Contractによる変更責任の分離
• ポートやDBを含む実行環境の分離
• Pull RequestとCIによる統合ゲート
• 一人の責任者による最終的な統合判断

複数のAIエージェントを同時に動かすことと、複数の変更を同時にmainへ入れることは別です。

**実装は並列化し、統合は直列化する。**

この原則を守ることで、AIエージェントの速度を、ブランチ混乱や手戻りではなく、実際にmainへ届く開発速度へ変えられます。

よくある質問

worktreeを使えばコンフリクトはなくなりますか

なくなりません。

worktreeは作業ディレクトリとGitの作業状態を分けますが、API仕様、共通型、データベース、ポート、外部サービス、マージ順序の競合は残ります。Task Contractと実行環境の分離、統合順序を併用する必要があります。

フロントエンドとバックエンドは並列開発できますか

API契約を先に固定すれば可能です。

リクエスト、レスポンス、エラー形式、認可条件、空値の扱いまで決めてから分割します。API契約が実装途中で変わる状態では、直列で進めた方が手戻りを減らせます。

同じ機能をClaude CodeとCodexの両方に実装させるべきですか

通常は不要です。

実装案を比較する実験でなければ、一方を実装担当、もう一方を読み取り専用の監査担当に分けた方が統合コストを抑えられます。

何体まで同時に動かせますか

モデルやPCの上限ではなく、統合責任者がレビューとマージを処理できる範囲で決めます。

未レビューのPull Requestが積み上がる場合、エージェントを追加しても処理能力は上がりません。新しいタスクを起動する前に、現在の変更をmainへ統合します。

AIにマージコンフリクトを解消させてもよいですか

意図が明確な機械的競合は任せられます。

API仕様、DBスキーマ、認証、料金、契約など、意味の判断を伴う競合は、人間が残す仕様を決めます。AIには判断後の修正を担当させます。

参考資料

• Git git-worktree Documentation
• Anthropic Run parallel sessions with worktrees
• OpenAI Introducing the Codex app
• GitHub About protected branches

製品仕様と公式ドキュメントの記載は、2026年8月14日時点のものです。