#ai#agents#security#devops#compliance
AIエージェントのコミットを監査可能にする：Session証跡コントロールプレーン設計
コード生成AIが本番リポジトリに常時入る時代、問うべきは「書けるか」ではなく「説明できるか」です。GitHub側で、エージェントコミットとセッションログの接続性が強化されている流れは、まさにここを示しています。
何が問題なのか
人手だけの開発では、コミット履歴・レビュー履歴・CI結果で説明責任を満たせる場面が多くありました。しかしAIエージェントが加わると、次のギャップが出ます。
- 最終コミットに至るまでの試行が見えない
- どのプロンプト文脈で生成されたか追いにくい
- ツール実行が外部状態を変更している可能性がある
この状態では、インシデント時に「なぜこの変更が入ったか」を高精度で再現できません。
最低限必要な証跡束
コミットSHAごとに、以下を束ねるのが実務上の最小ラインです。
- セッションID
- 実行主体（ユーザー/エージェント）と権限スコープ
- プロンプト/ポリシーのハッシュ
- CI・静的解析・ガード判定結果
- 時系列イベント（生成→編集→コミット→マージ）
生の全文ログを全部保存する必要はありません。重要なのは再現可能性です。
推奨アーキテクチャ
収集層
- VCS監査ログ
- エージェントセッションメタデータ
- CIポリシー判定
- ブランチ保護イベント
を共通スキーマへ正規化。
相関層
コミットSHAを主キーにして、証跡レコードをイミュータブルに生成します。
実行制御層
- 証跡不足コミットはマージ停止
- 高リスク領域は人手承認を必須化
- 規制対象リポジトリは保持期間を長期化
参照層
- セキュリティ調査
- 内部監査
- 事後検証
の検索速度を重視。遅いと現場が使いません。
追うべき運用指標
- 完全証跡付きAIコミット率
- インシデント調査の平均検索時間
- チーム別の例外発生率
- 誤検知によるマージ阻害件数
「統制強化」と「開発速度」のバランスを定量で管理します。
45日導入プラン
- 1〜10日目：証跡スキーマ・リスク区分定義
- 11〜20日目：SHA相関とCIゲート接続
- 21〜30日目：高リスクリポジトリで試験運用
- 31〜45日目：保持ルール込みで全社標準化
まとめ
AI時代の開発統制は、レビューコメントの丁寧さではなく、証跡の再現性で決まります。セッション連携型のコミット証跡は、今後の標準基盤になります。
