#ai#llm#devops#ci/cd#security
GitHub Copilot×GPT-5.4時代のリスク階層ルーティング実践
GitHub CopilotでGPT-5.4が一般提供されたことで、単なる「精度向上」以上の変化が起きています。生成速度が上がり、1回の提案で触る差分範囲が広がり、もっとも厄介なのはそれらしい誤りが増えることです。見た目は正しいのに、運用やセキュリティ境界では危険、というケースが増えます。
だからこそ有効なのが、モデルを一律に使うのではなく、変更リスクに応じてルーティングする運用です。本稿では、実務で回る構成を整理します。
なぜGPT-5.4導入で運用が崩れやすいのか
現場でよく起きるのは次の3点です。
- 受け入れ提案数が増え、PR本数が急増する
- 1PRあたりの差分が長くなり、レビュー集中力が分散する
- 「妥当そうな説明」に引っ張られ、根拠確認が甘くなる
つまり、モデル性能が上がるほど、誤り1件あたりの影響範囲（blast radius）も増える、という構造です。
先にやるべきはリスク分類
モデル設定を触る前に、リポジトリ面を明確に階層化します。
- Tier 0（低リスク）: ドキュメント、コメント、非実行メタデータ
- Tier 1（中リスク）: テストが厚い内部ロジック
- Tier 2（高リスク）: 認証認可、決済、個人情報、秘密情報処理
- Tier 3（最重要）: 本番インフラ定義、移行スクリプト、障害対応ツール
この分類をCode OwnersやCIルールに接続し、機械的に判定可能にすることが重要です。
階層別ルーティング設計
Tier 0-1
- GPT-5.4を広く許可
- レビューは軽量、ただしAI利用ラベルを必須化
- 速度優先で学習サイクルを回す
Tier 2
- GPT-5.4は許可するが、プロンプトをテンプレート化
- SAST・Secret Scan・依存脆弱性検査を必須ゲート化
- ドメイン担当者の承認を最低1名必要にする
Tier 3
- 生成利用を限定（テスト雛形や局所リファクタ中心）
- 権限・配備・ポリシー変更の自動編集を禁止
- 2名レビュー＋脅威モデリングチェックリストを強制
「AIを信用しない」のではなく、コードベース内で危険度が偏在している事実に合わせる設計です。
PRテンプレートを“根拠提出”型に変える
AI支援PRでは、次の項目を必須にします。
- 変更意図（なぜ必要か）
- リスク階層と影響境界
- 実施した検証（単体/結合/セキュリティ）
- ロールバック条件
- 未検証事項・残課題
これがないとレビューは「よさそう」で流れ、後工程でコストが爆発します。
測るべき指標
採用率だけでは不十分です。以下をセットで追います。
- AI支援PRのマージ後障害率
- 階層別のRevert率
- レビュー時間の中央値とばらつき
- Tier 2/3におけるセキュリティ指摘密度
- 追加テストの有効性（実際に退行を捕捉したか）
速度向上とRevert増加が同時に起きているなら、改善ではなく“前倒しされた負債”です。
導入ステップ例
- 1〜2週目: Tier 0のみ有効化、基準値を収集
- 3〜4週目: Tier 1へ拡張、PR契約を厳密運用
- 5週目以降: Tier 2を限定サービスで試行
- Tier 3は設計審査を通過したケースのみ解放
段階導入により、速度と品質を同時に管理できます。
まとめ
GPT-5.4の価値は、万能化ではなく高スループットな貢献者を統制下で活かすことにあります。リスク階層、証拠中心のPR運用、CIゲートを組み合わせれば、AI導入は「速いけど危ない」から「速くて再現性がある」へ変えられます。
