複数人・複数AIの同時変更で壊れる原因と、PMが押さえる衝突防止の5原則

複数の開発者やAI（Claude Code、Cursorなど）が同じシステムを同時に触ると、「せっかくの修正が消えた」「動いていた機能が急に壊れた」が起きます。この記事では、非エンジニアのPMが原因を理解し、Git・ブランチ・Pull Requestといった仕組みでどう防ぐかを、専門用語を最小限にして解説します。読み終えると、チームに何を依頼すべきかが判断できます。

この記事の結論

• 衝突は「同じファイルの同じ箇所を、別々の人・AIが同時に変えた」ときに起きる（事実）
• 防止の核は「作業を分ける仕組み」＝ブランチ（作業の枝分かれ）と担当範囲の明確化
• 変更は必ずPull Request（変更を提案してレビューを受ける仕組み）を通して統合する
• 統合前に「自動チェック（テスト）」を通すと、壊れた状態の合流を防げる
• PMの役割はコードを書くことではなく、「誰がどこを・どう合流させるか」のルール設計

この記事が役立つ人

• エンジニアやAIツールに開発を任せているが、進行管理に不安があるPM・ディレクター
• 「変更が消えた」「本番が壊れた」トラブルの原因を自分の言葉で理解したい方
• 前提知識は不要。GitやPull Requestという言葉を聞いたことがある程度でOKです。

なぜこの問題が起きるのか（背景と原因）

システムのソースコードは「大量の文書ファイルの集合」です。複数人が同じ文書を同時に上書き保存すると、後から保存した人の内容で前の人の内容が消えます。これがシステム開発でも起きる、衝突の正体です。

さらに近年はAIコーディングツールが加わり、人間1人＋AI複数が並行して同じファイルを書き換える状況が増えました。AIは高速で広範囲を変更するため、人間同士より衝突が起きやすい傾向があります（筆者の観察）。

> 強調ボックス：衝突＝喧嘩ではない

> 「衝突（コンフリクト）」はGitが「どちらの変更を採用すべきか自動判断できない」と知らせる正常な警告です。放置や強制上書きが本当の事故を生みます。

```mermaid

graph TD

A[元のファイル] --> B[Aさんが3行目を変更]

A --> C[Bさん/AIが3行目を変更]

B --> D{同じ場所を別内容に}

C --> D

D --> E[衝突発生：どちらを残す?]

```

図: 同じ箇所を同時変更すると、システムが判断できず衝突になる流れ

衝突を防ぐための5つのポイント

1. ソースを1か所で共有する（Gitという仕組み）

結論：全員が同じ「共有の正本」を見て作業すれば、バラバラのコピーで食い違うことを防げます。Gitはこの共有と履歴管理を担う仕組みで、GitHubやGitLabがその置き場所です。

具体例：メールでファイルを送り合う運用は「誰の版が最新か」が分からなくなり事故の温床。Gitなら履歴が全部残り、いつでも元に戻せます。

実践方法：PMは「作業は必ずGit上で。ローカルのコピーを直接本番に上げない」をチームの前提として合意します。

2. 担当範囲を分けて「同じ場所」を触らせない

結論：そもそも同じ箇所を同時に触らなければ、衝突の大半は起きません。機能・画面・フォルダ単位で担当を割ると効果的です。

具体例：「決済まわりはAさん、通知まわりはAIとBさん」のように分ける。逆に「共通設定ファイル」は全員が触りがちなので、変更を1人に集約します。

実践方法：タスク分解時に「触るファイル領域」を書き添える。AIに依頼するときも変更範囲を指定します。

3. ブランチ（作業の枝分かれ）で本番から隔離する

結論：各作業を「枝分かれした作業コピー」で行えば、途中の壊れた状態が他人や本番に影響しません。これがブランチです。

具体例：木の幹（本番）から枝を伸ばし、その枝で作業。完成したら幹に合流させる、というイメージです。

```mermaid

gitGraph

commit id: "本番"

branch feature-A

commit id: "Aの作業"

checkout main

branch feature-B

commit id: "Bの作業"

checkout main

merge feature-A

merge feature-B

```

図: 幹（main）から枝を分け、完成したものだけを合流させる

実践方法：「1タスク＝1ブランチ」を基本ルールに。AIツールにも作業ごとにブランチを切らせます。

4. Pull Requestで「合流前に必ず確認」する

結論：Pull Request（プルリクエスト、略称PR）は「この変更を合流させたい」という提案書です。合流前に第三者が中身を確認できる関所になります。

具体例：Bさんの枝を幹に合流する前に、AさんがPR上で「この変更で問題ないか」を見る。AIが書いたコードも人間がPRでレビューします。

実践方法：PMは「PRなしの直接合流は禁止」「最低1人のレビュー承認を必須」をルール化。PMはコードでなく「変更の意図と影響範囲」を確認します。

5. 統合前に自動チェック（テスト）を通す

結論：合流前に「機能が壊れていないか」を自動で検査すれば、壊れた状態の合流を機械的に止められます。

具体例：PRを出すと自動でテストが走り、失敗すると合流ボタンがロックされる、という設定にできます。

実践方法：CI（継続的インテグレーション：変更のたび自動検査する仕組み）の導入をエンジニアに依頼。PMは「テストが緑（成功）でないと合流不可」の運用を守らせます。

| 仕組み | 役割 | PMが確認すること |

|---|---|---|

| Git | ソースの共有・履歴管理 | 全作業がGit上か |

| 担当範囲 | 同時変更の予防 | 誰がどこを触るか明記 |

| ブランチ | 作業の隔離 | 1タスク1ブランチか |

| Pull Request | 合流前レビュー | 承認なしで合流していないか |

| 自動テスト | 壊れの検知 | テスト成功が合流条件か |

AIやツールで自動化する方法

AIコーディングツールに指示する際、ブランチ運用とPR作成まで含めて依頼すると、勝手に本番を書き換える事故を減らせます。以下はPMがそのまま渡せる指示テンプレートです（特定ツールに限定しません）。

```markdown

AIへの作業依頼テンプレート（コピペ用）

あなたはチーム開発のルールに従うエンジニアです。以下を厳守してください。

作業ルール

1. main（本番）ブランチを直接変更しない

2. 作業前に「feature/〈タスク名〉」ブランチを作成する

3. 変更してよいファイル領域は〈対象フォルダ/ファイル〉のみ

4. 共通設定ファイル（〈ファイル名〉）は変更しない。必要なら先に相談

5. 作業後はPull Requestを作成し、以下を本文に記載：

- 変更の目的（1〜2文）

- 変更したファイル一覧

- 想定される影響範囲とリスク

6. テストがあれば実行し、結果を報告する

タスク

〈やってほしいことを具体的に記述〉

```

GitHub Actions（変更時に自動で検査を走らせる仕組み）を使えば、PRごとにテストを強制できます。導入自体はエンジニアに任せ、PMは「この設定が有効か」を確認すれば十分です。

> 強調ボックス：AI特有の注意

> AIは指示範囲を超えて広く書き換えることがあります。「変更してよい範囲」と「触ってはいけないファイル」を必ず明示してください。

実践チェックリスト

• [ ] 全員・全AIの作業がGit上で行われている
• [ ] タスクごとに「触るファイル領域」を割り当てている
• [ ] 1タスク＝1ブランチのルールが守られている
• [ ] mainへの直接変更を禁止している
• [ ] Pull Requestに最低1人のレビュー承認を必須にしている
• [ ] 統合前に自動テストが走り、成功が合流条件になっている
• [ ] AIへの依頼にブランチ・PR・変更範囲の指示を含めている

まとめ（結論と最初に着手する行動）

衝突は「同じ場所を同時に変える」ことで起き、防止の鍵は作業を分けて、合流前に確認することです。ブランチで隔離し、Pull Requestで確認し、自動テストで壊れを止める——この3点をルール化すれば、人もAIも安全に並行作業できます。

最初の一歩：まず「mainへの直接変更禁止」と「PRレビュー承認必須」の2つを、チームに合意させてください。設定変更はエンジニアに依頼できます。

次に読む記事

• 基礎：「Gitとは何か——非エンジニアのための履歴管理入門」
• 実践：「Pull Requestレビューでバグを減らす観点チェックリスト」
• 発展：「GitHub Actionsで自動テストを導入し、壊れた合流をゼロにする」

よくある質問

Q. PMもGitやコードを覚える必要がありますか？

コードを書く必要はありません。ただし「ブランチ」「PR」「テスト」という言葉の意味と、それぞれが何を守る仕組みかは理解しておくと、進行管理とリスク判断が正確になります。

Q. 小さなチームでもブランチやPRは必要ですか？

2人以上、あるいはAIを併用するなら必要です。人数が少ないほど「まあ大丈夫」と直接変更しがちですが、それが一番事故を招きます。ルールは小規模なうちに定着させる方が楽です。

Q. AIに任せれば衝突は自動で解決しますか？

自動では解決しません。AIは高速に変更する分むしろ衝突を増やすことがあります。作業範囲の指定とPRによる人間の確認を組み合わせて、初めて安全になります。