目次
GitHubは2026年10月15日、プルリクエスト向けAI Scanの一般提供を発表しました。CodeQLがカバーしていない言語やフレームワークの変更をAIで検査し、既存のコードスキャンを補完する機能です。PHP、Shell/Bash、TerraformのHCL、Dockerfile、JSP、Blazorなどが例として挙げられています。
本稿は10月21日に確認した機能の導入解説です。検出率や修正品質を本サイトが実測した記事ではありません。既存のAIレビュー一般論から一歩進め、GitHub上でいつ動き、どこへ結果が出て、どの変更が対象外になり、誰が費用と最終判断を持つかを整理します。
一次資料：AI Scan for pull requests generally available（GitHub）、AI Scan for pull requests（GitHub Docs）。以下の運用手順と仮想例は本サイトの提案です。
スポンサーリンク
最初に理解したいのは助言型の結果
公式資料は、AI Scanの検出結果は助言であり、Code scanningのチェックを失敗させず、rulesetの要件としてPRのマージを阻止できないと明記しています。結果が表示される機能を導入しても、自動で危険な変更が止まる構成にはなりません。ここを既存の必須チェックと混同しないことが重要です。
本サイトでは、AIの指摘が出たときに誰が読み、どの条件なら修正し、根拠を残して採用しない場合に誰が判断するかを決めることを提案します。人が見る運用と、テストや静的解析で機械的に止める条件を対応付ければ、助言の見落としを減らせます。
たとえば、Terraformの変更で公開範囲に関する指摘が出た場合、担当者は実際のリソース、継承する設定、適用先を確かめます。AIが危険と書いたことだけを理由に機能を削除するのでも、チェックが緑だから無視するのでもなく、変更の意図と影響を確認して判断を残します。これは説明用の仮想例です。
CodeQLとの関係を正しく整理する
AI ScanはCodeQLの対象外領域を補完します。公式によるとCodeQLのdefault setupを必須とせず、CodeQL解析が失敗または待機状態でもAI Scanは動作できます。二つの結果が返る順序も固定ではありません。片方の完了をもう片方の成功と読み替えないよう、表示上のAIの印を確認します。
AI Scanの結果はPR上に表示され、CodeQLのようにリポジトリーのSecurity画面へバックログのアラートとして蓄積されるものではないと説明されています。後から未解決の問題を追跡したいチームでは、PR内の会話だけに対応を残さず、課題管理へ引き継ぐ条件を用意します。
導入の目的は、既存のテストや解析を一括で置き換えることではありません。認可の設計、データの扱い、依存関係、実行環境など、コード差分だけでは判断しにくい事項も残ります。AI Scanを追加した範囲と、引き続き人や別の検査が担当する範囲をレビュー表で明確にします。
スポンサーリンク
動くPRと動かないPRがある
公式資料では、code scanningとAI Scan設定が有効で、対応する変更を含むPRが対象です。フォークからのPRとDependabotが作成したPRでは実行されません。PR作成時と新しいコミット時に動く仕組みのため、対象外の変更をどの経路で確認するかを設計する必要があります。
外部コントリビューターの変更が多いプロジェクトでは、フォーク由来のPRこそ重点的に確認したい場面があります。AI Scanが付かないことを正常な対象外として識別し、別のレビュー、テスト、依存検査を使います。動かすためだけに信頼境界を緩めたり、外部コードへ強い秘密情報を渡したりする運用は避けます。
DependabotのPRにも別の確認が必要です。依存のバージョン変更はコードの行数が少なくても、実行時の挙動や推移依存が変わります。AI Scanの指摘がないことを安全性の証拠にせず、変更履歴、テスト、ロックファイル、既知の脆弱性情報を確認します。
所有者と公開範囲で提供条件が異なる
公式資料では、組織や個人が所有する公開リポジトリーで利用でき、組織所有の非公開・内部リポジトリーではGitHub Code SecurityまたはGitHub Advanced Securityが必要です。個人所有の非公開リポジトリーは利用対象外とされています。Copilotライセンスは必須ではありません。
ただし、ライセンスの要否と実行料金の有無は同じではありません。AI ScanはCode Security AI Creditsを消費します。公開リポジトリーだから実行費用が無条件に無料だと考えず、どのアカウントへ請求され、含まれるクレジットがあるか、予算上限がどう効くかを確認します。
ドキュメントは、利用可能なクレジットがハード予算によりなくなると検出結果を生成できず、予算の変更や新しい請求期間などで再開すると説明しています。結果がない状態には、問題を見つけなかった場合と、実行できなかった場合があります。運用担当がこの違いを見分けられる監視が必要です。
スポンサーリンク
導入前に小さな評価用変更を用意する
本サイトでは、自社が扱う言語と典型的な修正を含む検証用リポジトリーで、機能が発火する条件を確認することを勧めます。正常な変更と、レビューで気付いてほしい単純な問題を、秘密や実データを含めずに用意します。結果の有無だけでなく、説明が実際の差分と一致するかを人が評価します。
評価で見る項目は、重大な問題の見逃し、誤った指摘、説明に必要な追加調査、修正案が機能を壊さないか、レビューの所要時間です。検出件数だけを増やす目標にすると、ノイズが増え、重要な指摘が読まれなくなるおそれがあります。導入前の基準と導入後の測定方法をそろえます。
自動修正案も、そのままマージする前に試験が必要です。たとえば入力を一律に拒否すれば問題が消えたように見えても、正規機能まで使えなくなる場合があります。認証済みと未認証、別利用者、境界値、エラー時の挙動を確認し、修正の意図をコードへ落とし込みます。
結果を待つ運用とマージ後の追跡
PR上で結果が順次表示されるなら、レビューをいつ完了とするかを決めます。AI Scanの実行を待つことと、必須チェックとしてブロックすることは別です。チームのルールとして確認担当を置く場合も、公式のマージ阻止機能があるかのように案内しないようにします。
見逃しが後から見つかった場合は、その差分を評価データへ戻し、検出できなかった条件を記録します。入力の文脈が不足していたのか、対象言語ではなかったのか、予算で動かなかったのかを分ければ、単にAIは役に立たないという結論より改善につながります。
誤検知を採用しない場合にも、短い理由と確認した根拠を残します。後から同じ指摘が繰り返されても判断を再利用できます。一方で、過去に誤検知だったという理由だけで新しい差分も自動的に無視しないよう、影響条件を見直します。
導入の完了条件をレビュー全体で考える
指摘を修正の根拠へ変える実務例
仮想のPHPアプリで、利用者IDを受け取って文書を返す処理へAI Scanが認可の問題を指摘したとします。担当者はその関数だけでなく、呼び出し元の認証、利用者と文書の関係、共通ミドルウェアを調べます。実際の認可が別の層にあるなら、その根拠を確認し、存在しないなら修正と回帰テストへ進めます。
このとき、AIの説明をそのまま課題の本文へ転載するだけでは、どこまで確認したかが分かりません。再現する利用者の権限、対象データ、期待する拒否、実際の結果を短く記録します。実データの識別子や個人情報を公開PRへ貼らず、検証用データへ置き換えることも必要です。
修正案を採用した後は、許可された本人の操作が通り、別利用者の操作が拒否されることを確認します。単にエラーが消えた、警告が消えたという結果では不十分です。必要な業務を維持した状態で境界が守られることを、機械的に再実行できるテストへ残します。
誤検知が続く場合は、共通の認可処理や設定をレビュー担当が理解しやすい形で示せるかを検討します。ただし、AIに理解させるためだけに必要な設計を崩すのは適切ではありません。コードの責任範囲と検証結果を人にも読みやすくし、指摘の判断コストを下げる改善を優先します。
運用評価では、指摘を受けたPRの数だけでなく、採用した修正、採用しなかった理由、後から見つかった問題、結果を読む担当の負担を対応付けます。毎回の件数が変わっても比較できるよう、評価対象の言語、変更規模、対象外PRの割合をそろえることを勧めます。
予算を使い切ったときの連絡先とレビュー手順も決めます。結果が出ないまま通常どおり進めるのか、別の解析や重点レビューへ切り替えるのかは業務次第です。AI Creditsの残量を確認する管理者と、PRを承認する開発担当が別でも、その状態が伝わる経路を用意してください。
AIによる修正提案の採用率を成果として使う場合にも注意が必要です。採用しやすい細かな変更が増えても、重大な設計上の問題を見逃していれば安全性の改善とはいえません。影響の大きい問題を確実に見つけたか、誤った提案で業務を壊していないかを、同じ評価用変更で継続して確認することを提案します。
試行後は、対象リポジトリー、対象外PR、費用の負担先、予算通知、結果の確認担当、課題への引き継ぎを文書化します。これらが決まっていなければ、機能を有効にしただけで運用が止まります。小さなチームでも、対応しない指摘の扱いと不在時の代行は必要です。
AI Scanは、カバーしにくかった変更へ追加の検査を届ける機能です。その価値を出すには、助言型であること、実行対象の制限、従量課金、結果の保存場所を理解する必要があります。自社のコードで検証し、最終判断が誰に戻るかまで設計してから対象を広げてください。
スポンサーリンク
