GitHubのAI脆弱性検査と自動修正が正式提供。警告・修正案・承認を分ける

この記事でわかること

• 役割分担：AI ScanとAgentic Autofixがそれぞれ担当する範囲
• 利用条件：対象リポジトリ、例外、費用で確認する点
• 運用例：警告の処理とマージ承認を混ぜない運用例

PRの検査と、見つかった警告の修正は別の入口

AI Scanは変更内容を調べる

AI Scanはプルリクエストの変更を調べ、脆弱性の発見を支援します。CodeQLが対応していない言語やファイルも補完対象になり、公式発表ではPHP、Bash、HCL、Dockerfileなどが例示されています。

ただし、その結果は助言として扱われ、AI Scanの指摘だけでチェックが失敗したり、マージが自動的に止まったりするわけではありません。警告が出た際に誰が読み、どう対応するかを決めておく必要があります。forkからのPRやDependabotのPRは対象外です。

Agentic Autofixは修正して再検査し、ドラフトPRを作る

Agentic Autofixはコードスキャンの警告について、コードベースを調べ、修正を作り、CodeQLを再実行したうえでドラフトPRを準備する流れです。default branchの警告が対象で、最大25件を一つのPRへまとめられるとされています。

つまり、発見から修正案までの作業を進める機能であり、確認なしに本番へ反映するものとして理解すべきではありません。また、AI Scanが出したすべての指摘が、そのままAgentic Autofixへ連続して処理されると決めつけず、それぞれの対象を確認してください。

利用条件と費用を、機能ごとに照合する

「Copilotの契約が不要」という説明を「追加費用なし」と読み替えないようにしましょう。組織のポリシー、対象プラン、課金設定、リポジトリでの有効化は管理者と照合します。料金の総額は実行内容や回数で変わるため、一定額で無制限と考えないことが重要です。

最初の運用は、警告を一つ選んで最後まで追う

警告の説明と実際の影響を確認する

AIの指摘を受けたら、まず対象ファイル、入力経路、想定される影響、再現できる条件を確認します。判断できないまま「AIが危険と言ったから修正」「AIが直したから完了」と進めると、必要な機能を変えてしまう可能性があります。

たとえば入力値の扱いが問題とされた場合は、正しい入力が通ることだけでなく、不正な入力を拒否できるか、既存の利用方法を壊さないかをテストの観点にします。具体的な修正方法は、対象コードと組織の設計に合わせて判断します。

再検査の成功と、業務上の正しさを分ける

CodeQLの再実行は重要な検証ですが、それだけですべての動作や脆弱性を保証するものではありません。通常のテスト、差分レビュー、必要なら関係者の確認も残します。警告が消えた理由を、レビュー担当が説明できる状態にするのが目標です。

1. 影響を把握しやすい警告を一件選ぶ。
2. AIによる修正案と根拠、再検査結果を読む。
3. 既存動作のテストと、変更箇所に合う追加確認を行う。
4. 担当者が取り込みを判断し、費用と処理時間を記録する。

複数の警告をまとめる運用は、一件の流れを理解してから検討するとよいでしょう。最大25件という上限は、毎回まとめるべき件数ではありません。

実務上の注意

今回扱うのはコードの脆弱性検出と修正支援です。APIキーなどの秘密情報の流出を検出・防止する仕組みとは役割が異なります。どちらかを有効にしただけで、もう片方の対策も済んだと判断しないでください。

まとめ

AI ScanはPRの変更を調べ、Agentic Autofixは対象警告の修正と再検査を進めます。導入時は機能ごとの対象と費用を確認し、警告の評価・修正案のレビュー・マージ承認を分けて運用しましょう。

よくある質問

出典・参考情報

• GitHub：AI Scan for pull requests generally available
• GitHub：Agentic Autofix for code scanning alerts general availability

公式情報の確認日：2026年10月16日（日本時間）。提供条件は変更される場合があります。