Copilotの競合解消エージェントを本番導入する前に: 破綻しないガバナンス設計

GitHubで@copilotにPRのマージ競合解消を依頼できる機能は、統合作業の待ち時間を確実に減らします。一方で、運用設計なしに全社展開すると「機械が直したから大丈夫」という誤信が蓄積し、意味的な不整合が本番へ流入しやすくなります。

参考: https://github.blog/changelog/

競合解消は“単なる整形作業”ではない

競合は種類でリスクが変わります。

• lockfile・生成物・ドキュメント: 低リスク
• 共通ユーティリティ・APIスキーマ: 中リスク
• 認可、課金、データ移行順序: 高リスク

同じ「競合解消」でも、監督強度を変えないと事故確率が上がります。

先に決めるべきリスク階層

• Tier A（自動許容）: docs / generated files / format差分
• Tier B（条件付き許容）: 共通ライブラリ・設定
• Tier C（人手必須）: セキュリティ境界・課金・権限・移行

この分類をpathベースでCIに実装すると、個人裁量ではなく組織ルールで運用できます。

AI競合解消PRに必須の証跡

1. 静的証跡: lint / type / unit test
2. 動的証跡: 影響範囲に対する統合テスト
3. 意図証跡: 「何を、なぜ残したか」の短い説明（AI+人間）

特に3がないと、レビュアーは“解消された差分”を意味的に検証しづらくなります。

ブランチ保護と連携した実装パターン

• AI解消時に ai-conflict-resolved ラベル付与
• Tier B/CはCode Owner承認を必須化
• 制限パスが含まれる場合はauto-merge禁止
• 可能ならエージェント変更の署名/検証を追加

禁止よりも「危険な自動化だけ狭める」方が現場定着しやすいです。

効果測定は“速さ”だけで判断しない

見るべき指標:

• AI解消PRの再オープン率
• 本番障害への関連率
• レビュアーの差し戻し頻度
• Tier別の時間削減効果

この4指標で、運用ルールを継続的に調整できます。

導入ロードマップ

• フェーズ1: Tier Aのみ解放
• フェーズ2: 一部チームでTier B試行
• フェーズ3: Tier Cを恒久的に手動維持するか判断

各フェーズで月次サンプリングレビューを行い、意味的ドリフトを検査します。

まとめ

競合解消エージェントは“レビューを不要にする機能”ではなく、“統合速度を上げる補助機能”です。信頼境界と証跡要件を先に作るほど、スピードと品質を両立できます。