AIの並列開発で衝突を減らす｜worktreeと共有ファイルの分担

worktreeを増やすと、複数のAIや担当者が同じ作業ディレクトリを奪い合う状態は避けやすくなります。Git公式ドキュメントによれば、ひとつのリポジトリには複数のworking treeを関連付けられ、複数ブランチを同時にcheckoutできます。新しいworktreeはHEADやindexなどworktree固有のファイルを分け、それ以外を元のリポジトリと共有します。これは2026-09-21時点の[git-worktree公式仕様](https://git-scm.com/docs/git-worktree)で確認できる範囲です。

ここで分離されるのは作業状態です。各AIに別ブランチと別worktreeを割り当てれば、一方の未commit変更が他方の作業場所へ混ざる問題を抑えられます。さらにGitは、あるブランチが別worktreeですでにcheckoutされている場合、既定では同じブランチを使うworktreeの追加を拒否します。並列作業の入口としては有効なガードです。

worktreeを分けても競合そのものは消えません。複数worktreeでは、HEADなど一部のrefを除き、原則としてrefs配下のrefとリポジトリ設定が共有されます。何より、別々のブランチで作った変更は最後に統合されます。Gitのmergeは重ならない変更を取り込めますが、共通祖先から見て両側が同じ領域を変えたときは一方を自動選択せず、解決を利用者へ委ねます。自動解決できない競合があればmergeは停止します。これは2026-09-21時点の[git-merge公式仕様](https://git-scm.com/docs/git-merge)に基づく事実です。

worktreeが受け持つのは作業状態の分離までです。各AIへ別ブランチと別worktreeを渡し、複数作業の前提になりやすいスキーマ・lockfile・共通型は共有変更対象として扱います。この分類はGitが定める義務ではありません。公式仕様が示す分離と統合の性質から導いた、実務上の管理方法です。

共有ファイルを一律に編集禁止へすると、関係する変更がすべて待ち行列になります。自由な同時更新にも、生成物の更新順や型の前提が食い違う危険があります。編集できる人を固定するより、同じ領域の変更を誰がどの順序で統合するかを決める方が、並列作業を維持しやすくなります。

そのため、共有変更対象の台帳をリポジトリ内でチームが参照できる場所に置きます。台帳へ記録する項目は次のように絞れます。

たとえば、APIスキーマの変更と、その定義を利用する共通型の変更を別のAIへ割り当てる状況を考えます。台帳ではスキーマの統合担当を先行判断者とし、「フィールドや型の前提が変わるなら共通型の統合を止める」と宣言します。スキーマのpull requestがreviewされ、取り込まれたことを引き渡し条件にします。共通型の担当は最新のスキーマを取り込んだ後の差分で、型の整合と競合を解決します。

lockfileは、依存関係の決定が変わるときに引き渡し対象へ加えます。該当する場合は先行差分を取り込んだ状態を渡し、lockfileの差分を作り直して統合判断を集約します。依存関係の決定に影響しない作業は、そのまま並列で進められます。自動生成された差分も、どの入力変更に伴うものかをpull request上で結び付けて確認します。

台帳には、対象ごとの条件と順序の判断をひと続きで記録します。

台帳に担当名を書くだけでは、判断材料が各worktreeへ散らばります。GitHubのpull requestは変更のmerge提案であり、merge前の議論とreviewに使えます。画面にはcommit履歴、checks、変更差分、mergeを妨げる条件などがまとまります。2026-09-21時点の[GitHub公式のPull requests解説](https://docs.github.com/en/pull-requests/reference/pull-requests)が示すこの文脈を、台帳の引き渡し確認に利用します。

先行するpull requestには、変更した共有対象、停止条件への該当、引き渡し先を記します。後続側には、取り込んだ先行差分、更新後に解決した競合、確認済みのchecksを残します。技術的にmerge可能な状態と、定めた順序に照らして今mergeしてよい状態を区別できます。

対象ごとに統合担当を一人へ定めること、台帳の項目、pull requestでの引き渡し手順は、GitやGitHubの原典所定の分類・義務ではありません。同じ領域の変更は利用者の解決を要し、pull requestには統合判断の文脈が集まるという一般原則から組み立てた運用例です。導入時は、チームのreview権限や既存の承認フローに合わせて調整してください。

停止対象はファイル名よりも、変更される前提で決めます。別ファイルでも、スキーマが共通型の前提を変えるなら順序を付けます。同じlockfileを触る作業でも、先行変更を取り込んだ状態で担当が差分を再確定できれば、実装まで全面停止する必要はありません。「同じ前提」に触れる差分だけを待たせる判断が、並列性を残します。

並列化を続けられるのは、作業ブランチとworktreeが分かれ、共有変更対象の前提が確定しており、各pull requestの統合順序が互いに依存しない場合です。いったん統合を止めるのは、スキーマが後続の型定義を変える場合、共通型の決定前に利用側の差分を確定できない場合、依存関係の変更によってlockfile担当の統合判断が必要になる場合です。これらは調査した一般原則から導く運用上の条件例であり、製品仕様が定める条件ではありません。

AIへタスクを渡す前に、実装の進め方もそろえておくと台帳が孤立しません。タスク分解からreviewまでの流れはAI駆動開発のワークフロー設計で確認できます。また、AIへ渡せる情報や実行権限の境界は統合順序とは別の論点です。Claude Code利用時のセキュリティ設計も合わせ、作業領域と権限の両方を定義してください。

自社で実行できる条件は明快です。AIごとにブランチとworktreeを分けられること、スキーマ・lockfile・共通型の統合担当を置けること、同時変更の停止条件と引き渡し条件を台帳へ書けること、pull request上で差分・checks・mergeを妨げる条件を確認できることです。欠ける条件があれば、worktreeの数を増やす前に統合責任を整えます。

条件がそろったら、独立した変更は別worktreeで進め、同じ前提へ触れる変更だけを台帳の順序へ戻します。worktreeは作業場所を分け、台帳は統合判断をつなぎます。停止対象は、後続の前提を変える差分に限定します。スキーマ・lockfile・共通型に該当しても、前提に影響しない差分は並列のまま進めます。先行差分のreviewと取り込みが終わり、後続担当が更新後の前提とchecksを確認できたら再開します。

自社の台帳やreview手順へ落とし込む際に第三者の整理が必要なら、AI駆動開発の研修、導入支援、技術顧問の範囲で相談できます。料金は研修30万円、導入パッケージ50万円から、技術顧問15万円／月で、[初回60分の相談](https://aidev.cotomu.jp)は無料です。このサービスに特定ツールの公式パートナーまたは認定という位置付けはなく、生産性や品質の向上も保証していません。