複数人のリポジトリを運用していて、リベースやマージのたびにコンフリクトが多発するチームに向けた内容です。最近、AIアシスタント付きのマージツールがVS CodeやCursor（AIコーディング機能を統合したエディタ）向けに増えています。便利さの裏にある落とし穴を、アーキテクチャ・非機能要件の観点から整理しました。
代表例として、MergeForgeというオープンソース拡張機能があります。JetBrains系IDE（IntelliJ・WebStormなど）のような三分割マージ画面をVS Code / Cursorに持ち込み、GitHub CopilotやAnthropic・OpenAIなどのAIモデルにコンフリクト解消の提案をさせる仕組みです。この仕組み自体は便利ですが、導入判断を誤るとコード品質やセキュリティ面で見えにくい負債を抱えることになります。
何が起きるか：AI解消コンフリクトの見えないリスク
AIにコンフリクト解消を任せると、表面的には「両方の変更を残す」「片方を優先する」といった提案がスムーズに出てきます。
ただし、これはあくまで「構文的に成立するコード」を生成しているだけです。ビジネスロジックの整合性やテストカバレッジの妥当性までは保証されません。
たとえば、片方のブランチが排他制御のロック処理を追加し、もう片方が同じ関数の戻り値の型を変更していたケースです。AIが両方の変更を機械的に統合すると、コンパイルは通っても実行時にデッドロックや型不整合が起きる可能性があります。マージ後のCIが通っても、本番投入後に初めて発覚する類の不具合です。
さらに、AIプロバイダーに自前のAPIキーを設定する運用では、コードの一部が外部サービスに送信されます。読み取り専用ツール（ファイル参照・履行履歴の検索・シンボル検索など）を使ってリポジトリの文脈を読み込む設計になっているツールほど、送信される情報量は増えます。
なぜ起きるか：原因を段階的に分解する
1. コンフリクトマーカーは「意図」を持たない
Gitの <<<<<<< ======= >>>>>>> は、テキストの差分位置を示すだけです。なぜその変更が入ったのか、どういう仕様変更を意図していたのかという情報は含まれません。AIが読むのはコードの表層だけで、Issueやレビューコメントに書かれた「本当の意図」までは自動で把握できません。
2. マージロジックと機械的パターンの境界が曖昧
MergeForgeの「Magic Resolve」機能は、両方のブランチが単に行を追加しただけの場合に両方を残す判断をします。これは安全な機械的パターンです。しかし、同一箇所の書き換え（rewrite）が発生している場合は判断を保留する設計になっています。つまりツール自体は慎重に線引きしていますが、AIモデルにFix all（一括解消）を実行させると、この境界を越えて「それらしいコード」を生成してしまう場面が出てきます。
3. レビュープロセスがマージ解消を素通りする
コンフリクト解消はプルリクエストのレビュー対象になりにくいという構造的な問題があります。差分としては「マージコミット」の中に埋もれてしまい、レビュアーが個別に目を通さないまま承認されるケースが少なくありません。AIが解消したコンフリクトほど、この見落としリスクが高まります。
自分のプロジェクトが該当するか確認する方法
以下の観点で、自分たちのリポジトリがリスクを抱えているか確認できます。
- リポジトリの
.git/configでmerge.conflictstyleの設定を確認する（diff3になっていれば、マージ元の共通祖先も表示され、AIやツールが判断しやすくなります） - 過去のマージコミットを
git log --merges --statで洗い出し、コンフリクト解消の変更行数が多いファイルを特定する - CI設定（GitHub Actionsなら
.github/workflows/*.yml）で、マージコミット後に必ずテストが実行される構成になっているか確認する - 拡張機能やAIツールに外部APIキーを渡す運用がある場合、社内の情報取り扱いポリシーでリポジトリ内容の外部送信が許可されているか確認する
# マージコミットの一覧と変更規模を確認
git log --merges --stat --since="3 months ago"
# 現在のマージ戦略設定を確認
git config --get merge.conflictstyleこれらのコマンドで、コンフリクトが多いファイル・頻度の高いブランチの組み合わせが見えてきます。特定のモジュールに集中していれば、そこはアーキテクチャ上の責務分割が甘い可能性があります。
対策の手順
ステップ1: コンフリクトスタイルをdiff3に変更する
git config --global merge.conflictstyle diff3共通の祖先（merge base）が表示されるようになり、AIやツールが「どちらが元の状態からの変更か」を判断しやすくなります。MergeForgeの結果ペインも、この祖先データをもとに初期状態を作っています。
ステップ2: AI解消後は必ず差分レビューを挟む
マージコミットを直接pushせず、一度ローカルブランチとして残し、git diff <merge-base> <resolved> で解消内容だけを確認してからpushする運用に変えます。レビュープロセスに「マージ解消差分の確認」を明示的なチェック項目として加えます。
ステップ3: 機械的パターンとロジック変更を分離する
MergeForgeの「Apply All Non-Conflicting Changes」のように、明らかに安全な変更（両側での単純追加など）だけを先に自動処理し、残った「本当に判断が必要な箇所」だけを人間かAIが個別に見る運用にします。すべてを一括でAIに投げる運用は避けます。
ステップ4: APIキー運用のスコープを確認する
AnthropicやOpenAIなどのAPIキーを個人が自由に設定できる状態を避け、組織のシークレット管理（VS Codeのsecret storageや社内のシークレットマネージャー）で一元管理します。読み取り専用ツールがどこまでリポジトリ情報にアクセスするか、ツールのドキュメントで確認しておくと安心です。
ステップ5: マージ後のテストカバレッジを可視化する
マージコミットに対してもカバレッジレポートを出力するよう、CIのジョブ条件を確認します。on: pull_request だけでなく on: push でmainブランチへのマージも対象にしているか、ワークフローファイルを見直します。
導入前に確認すること
AI付きマージツールは、コンフリクトの多いチームにとって作業時間の短縮につながる可能性があります。ただし、非機能要件の観点では次の3点を導入前に確認しておくと安心です。
- コンフリクトマーカーだけでなく、共通祖先（diff3形式）を含めた文脈をツールが参照できているか
- 機械的に安全な変更と、ロジック判断が必要な変更をツールが明確に切り分けているか
- AIプロバイダーへのコード送信がリポジトリの情報取り扱いポリシーに違反していないか
これらを確認したうえで、マージ解消の差分を通常のコードレビューと同じ重みで扱う運用に変えていくのが、技術的負債を溜め込まない現実的な一歩になります。