複数人・複数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が「どちらの変更を採用すべきか自動判断できない」と知らせる正常な警告です。放置や強制上書きが本当の事故を生みます。

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. ブランチ（作業の枝分かれ）で本番から隔離する

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

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

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がそのまま渡せる指示テンプレートです（特定ツールに限定しません）。

# 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による人間の確認を組み合わせて、初めて安全になります。

誰かの変更で別の人の作業が壊れる問題をAIでどうやって防ぐか