「AIにコードを見せれば、プロジェクト全体の脆弱性を自動的に見つけてくれる」と考えていないでしょうか。実際のGitHub Copilot App /security-reviewの使い方は、もっと範囲が限定されています。
このコマンドは、GitHub Copilot AppのアクティブなAgentセッションで進行中のコード変更を確認し、信頼度の高いセキュリティ上の問題を優先表示する機能です。つまり、コミット前やPull Request作成前の短い確認には向いていますが、CodeQLや依存関係監査を置き換えるものではありません。(github.blog)
GitHub Copilot App /security-reviewの使い方と役割
/security-reviewは、2026年7月14日にGitHub Copilot Appへ追加されたパブリックプレビュー機能です。現在のワークストリーム変更を対象に、重大度と信頼度を付けた発見事項、修正案、同じセッション内での再検証を提示します。(github.blog)
対象になりやすいのは、インジェクション、クロスサイトスクリプティング、安全でないデータ処理、パス・トラバーサル、弱い暗号処理などです。ただし、検査対象は「現在の変更」とその周辺コンテキストが中心であり、未変更の古いコードや実行環境の設定まで完全に保証する仕組みではありません。(github.blog)
GitHub Copilot App安全審査を開発フローに置くなら、次の位置が現実的です。
- 実装直後に、開発者自身が一次確認する
- コミット前に、入力値・認証・ファイル操作を見直す
- Pull Request作成前に、修正後の再検証を行う
- CI上のCodeQL、Dependabot、secret scanningへ引き渡す
実行前の準備
必要なセッション
/security-reviewは、Quick chatではなく、コード変更を持つアクティブなAgentセッションで実行します。GitHub Copilot Appでは、セッションごとに分離されたワークスペースが用意され、ローカルリポジトリ、作業ツリー、クラウドサンドボックスなどを選択できます。(docs.github.com)
必要な変更
変更がない状態では、レビュー対象が不足して結果が限定的になる可能性があります。まずテスト用ブランチで、入力値をそのままSQLやシェルへ渡す処理、認証情報の扱い、パスを組み立てる処理など、確認したい変更を明確にします。
アカウントと公開状態
GitHub公式ドキュメントでは、GitHub Copilot AppはFree、Pro、Business、Enterpriseの各Copilotプランで利用できると案内されています。ただし、BusinessとEnterpriseでは管理者によるCopilot CLIポリシーの有効化が関係する場合があります。/security-review自体はパブリックプレビューであり、仕様や表示は変更される可能性があります。(github.blog)
注意：本番ブランチでいきなりAgentに修正を任せるのではなく、ロールバック可能な検証ブランチ、または専用の作業ツリーを使う方が安全です。AIが提案した変更も、適用前に差分を確認してください。
実行手順
GitHub Copilot App /security-reviewの使い方は、次の5段階に分けると迷いにくくなります。
-
プロジェクトを開く
対象リポジトリをGitHub Copilot Appで開き、レビューしたいブランチや作業ツリーを選びます。別タスクの変更が混ざっている場合は、先に不要な差分を整理します。 -
Agentセッションを開始する
サイドバーから新しいセッションを作成し、InteractiveまたはPlanモードを選びます。安全審査では、最初からAutopilotにせず、変更内容を人間が確認しやすいモードにする方が扱いやすいです。セッションモードにはInteractive、Plan、Autopilotの3種類があります。(docs.github.com) -
変更範囲を確認する
「今回の変更だけを対象に、認証、入力値、外部コマンド、ファイルパスを重点確認してください」のように、見るべき領域をプロンプトで補足します。特定ファイルだけを確認したい場合は、対象ファイルやディレクトリを明示します。 -
コマンドを実行する
プロンプト欄へ/security-reviewと入力し、Enterキーを押します。公式手順でも、コード変更を持つアクティブなセッションを開き、コマンドを入力して結果を確認する流れになっています。(docs.github.com) -
結果と差分を確認する
発見事項を読んだ後、修正案を適用するか、手動で修正します。修正したらテストを実行し、再度/security-reviewを実行して、問題が解消されたかを確かめます。
実行時の確認ポイントを整理すると、次のようになります。
| 確認項目 | 成功の目安 | 失敗・不足時の対応 |
|---|---|---|
| セッション | Agentセッションが起動している | Quick chatではなく新しいセッションを作る |
| 差分 | 審査対象の変更が存在する | 変更を保存し、対象ブランチを確認する |
| コマンド | /security-reviewが認識される |
Appの更新状態、プレビュー提供状況を確認する |
| 出力 | 重大度、信頼度、修正案が表示される | 対象範囲を狭め、関連ファイルを追加する |
| 再検証 | 修正後に同じ問題が再表示されない | テストと差分確認を行い、別の原因を調べる |
重大度と信頼度の読み方
重大度が高くても、直ちにコードを全面的に書き換える必要はありません。まず、攻撃者が入力を制御できるか、危険な処理までデータが到達するか、認証や権限の境界を越えられるかを確認します。
信頼度は、AIがその発見をどの程度確実だと判断しているかを示す指標です。高信頼度の警告は優先度を上げるべきですが、信頼度が高いことと、実際の影響度が高いことは同じではありません。
次の順番で人間が再確認すると、機械的な修正を避けられます。
- 警告されたファイルと行を読む
- 外部入力から該当処理までのデータフローを追う
- 認証、認可、サニタイズ、エスケープの有無を確認する
- 修正によって仕様や互換性が壊れないかテストする
- 修正後の差分をもう一度レビューする
経験則：重大度と信頼度がともに高い発見は、まず再現条件を確認します。再現できない場合でも、誤報と決めつけず、入力制御や実行環境の前提が抜けていないかを調べてください。
修正と再検証の流れ
Copilot本地コード漏洞扫描という使い方を期待する場合でも、/security-reviewは単独のスキャナーとしてではなく、修正まで含む対話的な確認として使うと効果的です。
1. トリガーを特定する
「どの入力が、どの関数を通って、どの危険な処理へ到達するのか」を確認します。例えば、Webフォームの値がSQL文へ連結されているなら、問題は単なる文字列処理ではなく、入力境界とクエリ実行の設計にあります。
2. 修正案の前提を確認する
修正案が入力検証を追加するものなのか、パラメータ化クエリへ置き換えるものなのか、権限チェックを移動するものなのかを確認します。修正案をそのまま適用する前に、既存のAPI仕様とテストケースを照合します。
3. 最小限の変更を適用する
複数の問題がある場合でも、一度に大規模なリファクタリングを行わない方が原因を追跡しやすくなります。まず危険なデータ経路を閉じ、必要に応じて共通関数や型定義を改善します。
4. テストを実行する
ユニットテストだけでなく、認証失敗、権限不足、異常な入力、空値、長すぎる値などの境界条件を確認します。セキュリティ修正では、脆弱性が消えたことと、正規ユーザーの処理が壊れていないことの両方が必要です。
5. 再度レビューする
修正後に/security-reviewを実行し、同じ発見が消えたか、別の警告が出ていないかを確認します。その後、Pull Request上でCI、CodeQL、依存関係、秘密情報の検査結果を確認します。
既存ツールとの役割分担
「Copilot安全審査とCodeQLの違い」は、検査対象と実行タイミングで考えると整理できます。
| ツール | 主な対象 | 実行タイミング | 向いている確認 |
|---|---|---|---|
/security-review |
現在のローカルコード変更 | 開発中、コミット前、PR前 | 変更箇所の一次確認と修正案 |
| CodeQL | コードのデータフローや脆弱性 | CI、Pull Request、定期実行 | 継続的なコードスキャン |
| Dependabot | 依存パッケージの脆弱性や更新 | 依存関係の更新時 | 脆弱なライブラリの把握 |
| secret scanning | トークンや鍵などの秘密情報 | push後やリポジトリ監視 | 誤公開された認証情報の検出 |
GitHubのセキュリティ機能では、CodeQLのコードスキャン、Dependabot、secret scanningはそれぞれ別の種類のアラートとして管理されます。CodeQLはコード上の脆弱性、Dependabotは依存関係、secret scanningは秘密情報を主な対象とします。(docs.github.com)
そのため、/security-reviewだけで「提出コード前の安全確認」を完結させるのは危険です。開発者がローカル変更を素早く確認し、Pull RequestではCIやGitHubの継続的な検査を組み合わせる構成が現実的です。
結果が出ない場合の確認
変更範囲が不足している
セッションに変更がない、別の作業ツリーを開いている、対象ファイルがまだ保存されていない、といった状態では十分な結果が得られません。まずGitの差分と、GitHub Copilot Appが表示している作業場所を確認します。
コンテキストが足りない
脆弱性の原因が別ファイルの設定、ミドルウェア、ルーティング、権限管理にある場合、対象ファイルだけを指定すると判断材料が不足します。関連する呼び出し元と設定ファイルを明示し、何を境界として確認したいかを伝えます。
誤報が疑われる
「/security-reviewの誤報はどう処理するか」という場合、警告を無視する前に、入力が本当に外部から到達するか、フレームワークが自動的にエスケープしているか、認証済みの内部処理だけなのかを確認します。根拠をコメントやPull Requestへ残しておくと、後のレビューで同じ調査を繰り返さずに済みます。
漏れが疑われる
AIによるレビューは、未知の脆弱性、複雑な実行環境、ビジネスロジック上の権限不備を完全には保証しません。結果が空でも安全とは限らないため、CodeQL、依存関係検査、secret scanning、手動レビューを継続します。/security-reviewはパブリックプレビューで変更される可能性がある点も忘れないでください。(docs.github.com)
Kvmzen検証リポジトリで行うケース
本番コードを直接試すより、Kvmzenの検証リポジトリまたは専用ブランチで、意図的に再現可能な問題を作る方が安全です。例えば、外部入力をサニタイズせずにHTMLへ出力する処理、ユーザー指定のパスをそのままファイル操作へ渡す処理、開発用設定にテスト用の秘密値を置く処理を、実サービスから切り離して用意します。
検証は次の順番で行います。
- 可逆的なテストブランチを作る
- 影響範囲を限定したコード変更を加える
- GitHub Copilot AppでAgentセッションを開始する
/security-reviewを実行する- 重大度と信頼度、該当行、攻撃経路を記録する
- AIの提案と手動修正を比較する
- テストを実行してから再度レビューする
- CodeQLなどの結果と照合する
このケースで重要なのは、結果の件数を実績値として誇張しないことです。検出件数、所要時間、誤報の有無は、使用モデル、変更量、言語、フレームワーク、プロンプトによって変わるため、実測した日付とリポジトリ条件を添えて社内記録に残します。
macOS上で複数の検証ブランチを分けて試す場合は、Macレンタルの利用方法を確認し、検証用の作業環境と本番開発環境を分離する方法も検討できます。
開発環境の選び方
手元のWindowsやLinux環境だけで検証を続けると、macOS固有のビルド、署名、Xcode、iOSシミュレーターを含む確認で環境差が発生します。さらに、複数のAgentセッションを並行稼働させると、CPU、メモリ、ストレージ、ネットワーク接続、権限管理の負担が増えます。
既存環境の主な弱点は、次の3点です。
- ローカル端末の設定変更が、別の検証へ影響しやすい
- 一時的なMac開発需要でも端末購入が必要になりやすい
- 長時間のAgent処理やCI確認中に、端末を占有されやすい
継続的にmacOSの検証環境が必要なら、日本向けMacレンタル環境や、利用地域に合わせたKvmzenのMac環境を確認すると、購入前に必要な期間だけ構成を試せます。特に、可逆的なブランチで安全審査を繰り返す用途では、環境を分けて運用できることが、単純な端末性能より重要になる場合があります。
ただし、Macレンタルを選んでも、/security-reviewの結果を無条件に信頼してはいけません。アクセス権、リポジトリの秘密情報、ログの保存先、作業終了後のデータ削除方針を確認し、AIによる一次確認と人間の承認を分けて運用してください。
最後に、提出コード前に何を確認すべきかを一言で整理すると、まず/security-reviewで今回の変更を確認し、次にテスト、CodeQL、Dependabot、secret scanning、手動レビューを組み合わせます。現在の環境が端末占有や設定差分、macOS検証の不足でボトルネックになっているなら、無理にWindowsやLinuxだけで長期運用するより、KvmzenのMacレンタル環境で分離した検証スペースを確保する方が、レビューを継続しやすい選択肢になります。