AIが書いたコードを、コミット前にAIが疑う──GitHub Copilotの/security-reviewが編集画面まで降りてきた
GitHubがCopilotアプリに /security-review を追加し、全プランで公開プレビュー開始。コミット前に差分を走査し、深刻度つきで脆弱性を指摘します。検査がPRの手前へ動く意味と、AI検査に頼りすぎない線引きを読み解きます。
ターミナルにいた検査役が、編集画面へ移る
GitHubは7月14日、Copilotアプリに /security-review コマンドを追加したと発表しました。公開プレビューとしての提供です。いま手元で書き換えている差分をその場で走査し、セキュリティ上の問題を報告します。
この機能自体は新顔ではありません。6月10日に、Copilot CLI向けの実験的機能として先行搭載されていました。今回はそれが、日常的に使う編集画面へ移ってきた形です。
地味な移設に見えます。ただ「どこで検査するか」は、実際に検査が回るかどうかを大きく左右します。
何を拾い、どう見せるか
走査の対象は、リポジトリ全体ではなく作業中の変更内容です。GitHubの説明によれば、返ってくるのは次の3点です。
- 深刻度と確信度で採点された検出結果: 確信度の高いものに絞って提示されます。
- その場で適用できる修正案: Copilotを離れずに適用し、再検証まで行えます。
- 優先順位のついた一覧: コードが取り込まれる前に、重要なものから着手できます。
検出が狙うのは、被害が大きくなりやすい定番の脆弱性です。アプリ版の告知では、以下が例として挙げられています。
| 脆弱性の種類 | ざっくり言うと |
|---|---|
| インジェクション | 入力値がそのまま命令として解釈されてしまう |
| クロスサイトスクリプティング（XSS） | 他人のブラウザで意図しないスクリプトが動く |
| 安全でないデータの取り扱い | 秘匿すべき情報が不適切に扱われる |
| パストラバーサル | 想定外のファイルへ手が届いてしまう |
| 弱い暗号 | 強度の足りない方式で情報を守ってしまう |
先行したCLI版では、対象範囲がさらに広く説明されていました。SSRF、安全でないデシリアライズ、プロトタイプ汚染、ハードコードされた認証情報、アクセス制御の不備なども含まれます。
興味深いのは、その一覧に「LLMを組み込んだコードを狙うクロスプロンプトインジェクション」が入っている点です。AIを使う開発を、AIが検査する。検査項目そのものが、開発のかたちの変化を映しています。
「PRを出してから」から「コミットする前」へ
GitHubにはすでに、code scanning、Dependabot、シークレットスキャンといった仕組みがあります。ただ、これらが働くのは主にリポジトリやPR、CIの層です。つまり、コードを押し出したあとに指摘が返ってきます。
/security-review はその手前に立ちます。GitHubはこれを、既存の仕組みを置き換えるものではなく、必要なときに手元で走らせる軽量な検査だと位置づけています。
手戻りは、発見が遅いほど高くつきます。PRのレビューで指摘されれば、文脈を思い出すところからやり直しになります。書いた直後に気づけるなら、まだ頭の中に設計が残っています。
無料枠にまで配る、という選択
公開プレビューの提供範囲は、Copilot Free / Pro / Business / Enterprise の全プランです。有償の上位プラン限定ではありません。
ここには、セキュリティ検査を「特別なもの」から「既定の作法」に寄せる意図が読み取れます。経営目線では、レビュー担当者の負荷分散に効く可能性があります。定型的な指摘を機械が先に引き受ければ、人は設計や業務ロジックの妥当性に時間を使えます。
AI生成コードの量が増えるほど、レビューの人手はボトルネックになります。書く速度だけが上がり、確かめる速度が据え置きなら、詰まる場所が移動するだけです。
ただし「出てこなかった＝無い」ではない
便利さの裏で、AIによる脆弱性検査の限界も指摘されています。ここは冷静に見ておきたいところです。
2026年6月に公表された調査では、セキュリティチームの78%が、自動走査ツールが重大な脆弱性を見逃す偽陰性を経験したと報告されています。同じ調査では、テストを完全にAI任せにする組織の割合が29%から9%へ下がったとされます。47%はAIと人を組み合わせる方式を選ぶ、という結果でした。
研究の側からも、LLMによる検出はハルシネーション、文脈長の制約、知識のカットオフといった弱点を抱えると指摘されています。再現率は上がる一方で、誤検知が増えやすいという傾向も報告されています。
つまり /security-review は、網ではなくふるいと捉えるのが実態に近いはずです。通ったから安全、ではありません。既存の code scanning や人のレビューを外す理由にはならない、と考えるのが無難です。
試すなら、この順で
導入のハードルは高くありません。実際の手順は次のとおりです。
- Copilotアプリでプロジェクトを開きます。
- いつもどおりコードを変更します。
/security-reviewを実行し、変更分を走査します。- 提示された修正案を適用し、その場で再検証します。
運用として組み込むなら、まずは外部入力を扱う箇所から試すのが現実的でしょう。フォーム、API、ファイルの読み書きといった、脆弱性が集まりやすい場所です。
そのうえで、検出ゼロを合格印にしない運用ルールを決めておくことをおすすめします。AIに任せる範囲と、人が必ず見る範囲。この線引きをチームで言語化できるかどうかが、こうした道具の効き目を決めます。
参照: Security reviews now available in the GitHub Copilot app（GitHub Changelog） / Dedicated security review command now available in Copilot CLI（GitHub Changelog） / Security reviews are now available in Copilot CLI (experimental)（GitHub Community） / 78% of Security Teams Experience Critical False Negatives From Automated Scanning Tools（Business Wire）
