複数のAIコーディングツールを併用するとき、役割分担と作業のぶつかりを避ける方法

衝突が起きる場所を先に整理する

併用でぶつかる場面は、大きく3つです。

• 同じ作業ツリーを複数のツールが編集する:エディタ内のAIが開いているファイルを、別のCLIエージェントが同時に書き換える、といった状況です。
• 別ブランチで進めた結果、マージ時に重なる:作業場所は分かれていても、同じ関数や設定を両方が変更していれば、統合時に競合します。
• 共有ファイルを各自が更新する:依存関係のロックファイル、ルーティング定義、スキーマなど、複数タスクが「ついでに」触りがちなファイルです。

1つ目は作業場所の分離で防げます。2つ目と3つ目は、分離だけでは防げないため、担当パスの宣言と統合順序で対処します。

担当範囲の決め方:動作場所で分け、次に作業の種類で分ける

最初に確認したいのは、各ツールが「どこで動き、どこに変更を置くか」です。公式ドキュメントで確認できた範囲(2026年10月27日に閲覧、GitHubの記載は同月29日に再確認)を整理します。

• Cursor クラウドエージェント、動く場所：クラウド上の隔離VM、変更の置き場：別ブランチに作業し、プルリクエストとして反映、併用時の注意(公式記載ベース)：ローカルの作業環境には影響しない。リポジトリへの読み書き権限が必要(Cursor公式)
• Cursor の worktree 実行、動く場所：ローカルの別チェックアウト、変更の置き場：タスクごとに別のファイル一式。結果は /apply-worktree でメイン側へ反映、併用時の注意(公式記載ベース)：保持するworktreeは古いものから自動整理され、既定では端末全体で最大25(Cursor公式)
• GitHub Copilot クラウドエージェント、動く場所：GitHub Actions環境やクラウドサンドボックスなど、変更の置き場：指定したリポジトリ・ブランチで変更し、タスク1件につき作成できるPRは1件、併用時の注意(公式記載ベース)：同時に作業できるのは1ブランチ。単一リポジトリ・最長59分の制限はGitHub Actions環境に適用され、クラウドサンドボックスでは同一組織内の複数リポジトリを扱える(GitHub Docs)
• Claude Code(--worktree)、動く場所：ローカル、変更の置き場：既定で .claude/worktrees/<名前>/ に、worktree-<名前> ブランチを作成、併用時の注意(公式記載ベース)：隔離されるのはファイル編集。.git ディレクトリは共有される(Claude Code公式)

OpenAI Codexについては、今回は公式ページの内容を確認できていないため、表に載せていません。使う場合は「どこで動くか」「別ブランチやworktreeを作るか」の2点を公式ドキュメントで確認し、表の行を1つ足してください。

作業の種類で担当を割り当てる

動作場所が分かったら、作業の種類で担当を割ります。これは公式仕様ではなく、衝突を避けるための編集上の提案です。

• 人が今まさに書いているファイル、割り当ての考え方：メインのチェックアウトは人専用にする、理由：AIが別の場所で動いていれば、手元の編集とぶつからない
• 範囲が明確で独立した修正(バグ1件、テスト追加など)、割り当ての考え方：クラウド型エージェントにIssue単位で任せる、理由：別ブランチ・PRで戻るので、レビューで止められる
• 複数ファイルにまたがる試行錯誤、割り当ての考え方：ローカルのworktree上でCLI/エディタ型エージェントに任せる、理由：失敗しても破棄でき、メインに影響しない
• 共有ファイル(ロックファイル、設定、スキーマ)、割り当ての考え方：担当を1人(1ツール)に固定するか、人が直列で更新、理由：並行更新が最も競合しやすい

衝突を避ける作業ルール例

次の6項目を、チームのREADMEやタスク管理に貼れる形にした例です(説明用の例)。

【併用ルール(例)】
1. 1タスク=1ブランチ=1担当ツール。同じブランチを2つのツールで編集しない。
2. 着手前に、タスクへ「触ってよいパス」と「触らないパス」を書く。
3. メインのチェックアウトでは、人が直接編集する。AIの作業はworktreeかクラウドで行う。
4. 共有ファイル(例: package-lock.json, db/schema.sql, src/routes.ts)は
   担当を1つに決める。他のタスクで変更が必要なら、担当に依頼する。
5. マージ順序は人が決める。先にマージしたPRの内容を、後続ブランチへ取り込んでから確認する。
6. AIが作ったPRも、通常のPRと同じ手順でレビューする。

6番に関連して、GitHubの公式ドキュメントでは、Copilotに作業を依頼した人がそのPRを承認しても、必須承認数には数えられず、別のレビュアーによる承認が必要と説明されています。また、既定ではCopilotがプッシュしても GitHub Actions は自動実行されず、人が内容を確認してから「Approve and run workflows」で実行します。人の承認なしで実行する設定も可能です(GitHub Docs)。変更を頼むときは、PRコメントで @copilot にメンションするか、ブランチへ直接コミットできます。

依頼文テンプレート

どのツールにも使える形で、担当パスと完了条件を入れた依頼文の例です(説明用の例。括弧内は置き換えてください)。

タスク: [注文一覧APIのページネーション不具合を修正する]
触ってよいパス: [src/api/orders/, tests/api/orders/]
触らないパス: [package.json, package-lock.json, db/, src/routes.ts]
共有ファイルの変更が必要になったら、変更せず、必要な内容を報告してください。
完了条件: [tests/api/orders/ のテストが通る]
最後に、変更したファイルの一覧と、実行したコマンドを報告してください。

「触らないパス」を書いても、ツールが守る保証はありません。あくまで依頼の指示なので、後述の差分確認で人が検証します。

ローカルで並行させる手順と、人が確認する点

worktreeを分けて始める

Claude Codeでは、名前を変えて2つのターミナルから起動すると、別の作業場所で並行できます。

claude --worktree orders-pagination
# 別のターミナルで
claude --worktree report-export

公式ドキュメントでは、.claude/worktrees/ を .gitignore に入れておくと、メイン側に未追跡ファイルとして出ないと案内されています。また、worktreeは新規チェックアウトなので、.env のような git 管理外のファイルを引き継ぎたい場合は .worktreeinclude に列挙します(Claude Code公式)。

注意点もあります。同ドキュメントによると、ファイル編集や git の向き先は隔離チェックで防がれますが、cp やシェルのリダイレクトのように、git を使わずメイン側へ書き込むコマンドは、これらのチェックでは拒否されません。権限設定やサンドボックスも併用してください。

Cursorでも、worktreeで動かした結果は /apply-worktree でメインの作業領域へ戻せます。戻す前に、次の差分確認を行ってください。

マージ前に、ファイルの重なりを調べる

2つのブランチが同じファイルを変更していないかは、git で確認できます。次は説明用の例で、ブランチ名とベースは置き換えてください(bash を想定。この記事では実行確認していません)。

git diff --name-only origin/main...orders-pagination | sort > /tmp/a.txt
git diff --name-only origin/main...report-export      | sort > /tmp/b.txt
comm -12 /tmp/a.txt /tmp/b.txt

最後のコマンドが何か出力したら、両方が変更したファイルです。次のように対処します。

• 共有ファイルなら、先にどちらかをマージし、もう一方に取り込んで再確認する
• 担当パスの外のファイルが含まれていたら、依頼文の範囲を守れていないので、その変更を取り除くか理由を確認する
• 重ならなくても、片方が関数の仕様を変え、もう片方がその関数を呼んでいる場合は壊れる。マージ後にテストを実行する

運用を始めるときの最小構成

最初から全部を整えなくても構いません。次の順で十分です。

1. 今使っているツールごとに、上の表の「動く場所」と「変更の置き場」を埋める
2. 共有ファイルを3〜5個洗い出し、担当を決める
3. 依頼文テンプレートの「触ってよいパス」を、毎回書く習慣にする
4. マージ前に差分の重なりを確認する

ツールの機能や上限は更新されます。この記事の表は2026年10月27日に閲覧した公式ページ(GitHubの記載は同月29日に再確認)に基づくので、実際に導入する前に、各ドキュメントの最新の記載を確認してください。