AIセキュリティレビューはどこで止めるべきか: 作業中・PR・修正の三段階設計¶

対象 / ポイント

対象: AIコーディングエージェントを使いながら、既存のCodeQLやPR承認を維持する開発チーム。

ポイント:

作業中レビュー、PR検出、alert修正は、対象も停止力も異なる。
PR上のAI security detectionはinformationalであり、それ自体はmergeを止めない。
AIの判定数ではなく、各段階から次へ渡す証拠と責任者を設計する。

公開日: 2026-07-17

開発者が作業中に/security-reviewを実行し、PRにもAIの検出結果が表示され、alertの修正をCopilotへ任せられるようになった。三つの画面が緑になっても、同じ保証を三回通したことにはならない。

GitHubは2026年7月、これらを相次いでpublic previewとして公開した。¹²³ この記事の問いは、AIセキュリティレビューをどの工程で止め、何を次の工程へ渡すかである。

ここで問いを変える必要がある。どのAIレビューを追加するかではなく、どの証拠が欠けた時に、誰が変更を止めるかを決める。

三つの機能を一本のゲートと呼ばない¶

三段階は直列の自動パイプラインではない。起動者、対象、必要契約、費用、結果の強制力がそれぞれ異なる。

段階	対象と起動	提供条件・費用	その結果だけで止められるもの
作業中レビュー	開発者がCopilot appで現在の変更へ`/security-review`を実行	public preview中はCopilot Free、Pro、Business、Enterpriseで利用可能	開発者がPR作成を保留する判断
PR上のAI検出	PRのopen・update時にAI detection engineが実行	Code Security、CodeQL default setup、Copilot license、AI Creditsが必要	informational findingの提示。merge自体はblockしない
alert修正	code scanning alertをCopilotへ割り当てる	Code SecurityまたはAdvanced Security、cloud agent対応Copilot license、AI CreditsとActions minutesが必要	修正用draft PRの作成。採用やmergeは止めない

作業中レビューは、現在の変更へ高確度のfindingと修正案を返す軽量な補助である。 GitHub自身も、code scanning、Dependabot、secret scanningを補完する機能と説明する。¹

PR上のAI検出は、CodeQL未対応の言語やframeworkへ対象を広げる一方、結果は明示的にinformationalである。ここをrequired checkと読み違えると、画面には警告があるのにbranch protectionはmergeを許すという事故が起きる。²

agentic autofixはさらに別の仕事だ。 alertを探索し、修正を提案し、analysisを再実行してdraft PRを開くが、そのPRの妥当性まで自動承認する機能ではない。³

停止主体を三段階へ割り当てる¶

停止条件はAI findingの有無ではなく、誰がどの証拠を見て再開を許すかで定義する。同じ「security review済み」ラベルへ潰すと、段階間の責任移動が見えなくなる。

段階	停止主体	停止条件	次へ渡す証拠
作業中	変更の作成者	対象diffが固定されていない、未処理findingがある	commit、review実行時刻、findingと処置
PR	repository ownerまたはsecurity owner	required check失敗、重要領域の承認不足、未処理alert	PR、scanner種別、status、承認者
修正	fix PRのreviewer	元alertとの対応不明、analysis未再実行、回帰test不足	alert ID、fix commit、再検査、CI、rollback

第一段階は作者の停止である。 PRを開く前に対象diffを固定し、findingを修正するか、誤検知として扱う根拠を残す。

第二段階はrepositoryの停止である。 AI detection自体にblock能力がない以上、止める必要がある領域ではCodeQLなどのrequired status check、CODEOWNERS、security owner承認へ接続する。

第三段階は修正変更の停止である。 autofixが開いたdraft PRは元alertへの応答であり、新しい変更でもある。元alertが閉じても、認証仕様の破壊や回帰がないことは別に確かめる必要がある。

シナリオ: 認証middlewareの変更を流す¶

AI coding agentが認証middlewareを変更し、未認証時のdefault動作も触ったと仮定する。この一件を三段階へ流すと、各機能の限界が見える。

作業中で対象を固定する。 agent sessionの最後にcommit候補を作り、そのdiffへ/security-reviewを実行する。findingにはfile、severity、confidence、処置を紐付ける。
PRで検出元を分ける。 AIラベルのfinding、CodeQL結果、secret scanning、testを別行で記録する。AI findingがinformationalであることもPR本文へ残す。
実際の停止力を接続する。 認証領域はsecurity owner承認をrequiredにし、CodeQLとtestをrequired checkにする。AI findingはその判断材料に置く。
修正を新しい変更として扱う。 alertをCopilotへ割り当てた場合、生成されたdraft PRにalert ID、再実行したanalysis、回帰test、rollback方法を要求する。
元PRへ結果を戻す。 findingを消した事実だけでなく、どのfix commitと証拠で処置したかを元PRから追えるようにする。

この流れではAIを三回信頼していない。 一段階の不確実な出力を、次の段階で検証可能な証拠へ変換している。

課金と保証の台帳を分ける¶

AI security機能の費用を一つのCopilot席代へまとめると、どの段階が増えたか分からない。少なくともPR検出とagentic autofixは、public preview中にAI Creditsを消費する。autofixはActions minutesも使う。²³

運用台帳には次の5項目を残す。

scope: branch、commit、diff、対象repository。
source: Copilot app、AI detection、CodeQL、第三者scannerの別。
semantics: advisory、informational、requiredの別。
disposition: 修正、誤検知、risk acceptance、保留とその所有者。
lineage: alertからfix PR、再検査、merge判断までの関連。

finding件数だけをKPIにすると、広い検出ほど優秀に見える。見るべきなのは、確認済み欠陥、誤検知率、処置時間、再発、段階別のAI CreditsとActions minutesである。

運用開始を止める5条件¶

次のどれかが残るなら、AI security reviewを必須工程として扱わない。

AI detectionとCodeQL findingを同じstatusへ混ぜている。
informationalな結果をrequired checkと誤表示している。
findingの処置者とrisk acceptance承認者が決まっていない。
alert、fix PR、再検査、元PRを相互に追えない。
AI CreditsとActions minutesの上限、停止、集計責任者がいない。

AIの検出精度はpreview中に変わり得る。だから停止設計は、特定modelの賢さではなく、証拠が欠けた時に確実に止まる仕組みへ置く。

まとめ¶

作業中レビュー、PR上のAI検出、agentic autofixは、それぞれ作者、repository、修正reviewerの判断を補助する。一つの「AI security pass」へ統合せず、対象、強制力、費用、証拠を分ける必要がある。

レビュー回数を増やすだけではdefense in depthにならない。 各段階が異なる失敗を止め、前段の主張を検証できる証拠へ変えた時に初めて、多層防御になる。