Copilot Agentのコミット追跡をSDLC統制へ: 監査可能なAI開発運用の作り方

追跡機能は「便利機能」ではなく統制基盤

Copilot coding agent のコミットをセッションログに紐づけられるようになると、これまで曖昧だった問いに答えられるようになります。

• どのAI文脈で生成された変更か
• どのレビュー経路を通ったか
• 品質問題や障害とどこで接続するか

これは可視化ダッシュボードの話ではなく、監査可能な開発統制の話です。

最低限そろえるべき証跡モデル

AI支援コミットごとに次を保存します。

• リポジトリ・ブランチ情報
• エージェントセッションID
• プロンプト意図分類
• 生成差分サマリ
• 承認者と承認状態
• マージ後の品質指標（テスト失敗、障害、ロールバック）

この証跡は検索可能な形で保持し、監査やインシデント調査で再利用できるようにします。

既存SDLCに重ねるのが成功パターン

AI専用の別プロセスを作ると現場が疲弊します。既存の流れへ重ねてください。

• PRテンプレートにAI支援申告欄を追加
• CIでtraceメタデータ存在チェック
• 保護ブランチで人手承認を強制
• リリース判定にAI変更リスクラベルを反映

「いつもの流れで守れる」設計が最も定着します。

リスク段階に応じたレビュー強度

• 低リスク（ドキュメント・テスト整形）: 通常レビュー
• 中リスク（業務ロジック）: ドメイン担当レビュー必須
• 高リスク（認証・決済・権限）: 二重レビュー + 脅威観点チェック

traceデータと変更パスを連携すると、レビュー強度を自動提案できます。

指標設計で失敗しないために

有効な指標:

• AI支援変更の障害率（人手変更との比較）
• AIドラフトから承認マージまでの所要時間
• リスク層別のロールバック率
• 欠陥と相関するプロンプトパターン

避けるべき指標:

• AI生成行数だけを追う
• 品質を見ない生産性スコア

量ではなく結果を測るべきです。

プライバシーと法務の扱い

セッションログには秘匿情報が含まれる可能性があります。

• ロールベース閲覧制御
• リポジトリ機密度に応じた保持期間
• 秘密情報/個人情報の自動マスキング
• 重大障害時のリーガルホールド手順

追跡性を高めるほどデータ保護の難易度も上がるため、最初から一体設計が必要です。

45日導入ロードマップ

• Day 1-10: メタデータ仕様とポリシー策定
• Day 11-20: CI/PRテンプレ反映
• Day 21-30: 変更頻度の高いリポジトリで先行導入
• Day 31-45: 全社共通基盤化と監査レポート運用

まとめ

AIコーディングの普及で必要なのは、開発スピードを落とすことではなく、統制を同じ速度で回すことです。コミット追跡はそのための中核機能になります。