GitHub Copilot CLIの/security-reviewとは？何を検査し、どう使い分ける？

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

/security-reviewは何をする？

まずは、/security-reviewがどの役割のコマンドなのかを押さえます。

/security-reviewは、GitHub Copilot CLIでローカルのコード変更を対象に、セキュリティ観点へ絞ってレビューを返すためのコマンドです。コミット前やPR作成前に、危ない書き方が混ざっていないかを素早く点検したい場面に向いています。

ポイントは、汎用レビューの代わりではなく、あくまで軽量な事前チェックだということです。重い継続検査を置き換えるのではなく、手元で早く気付くための最初の網として使うと、役割を誤解せずに導入できます。

何を検査できる？

ここでは、/security-reviewがどこまで見てくれるのかを整理します。

GitHubの案内では、injection、XSS、path traversal、insecure data handling、weak cryptography など、実装の仕方しだいで事故につながりやすい論点が主な対象です。AIが生成したコードや、急いで書いた差分に危ないパターンが紛れていないかを、ローカル変更ベースで洗うイメージに近いです。

ただし、これでリポジトリ全体を監査できるわけではありません。見つけやすいセキュリティ臭を早めに拾う用途と捉え、深い継続検査は別の仕組みへ任せる前提で使うのが現実的です。

使う前の前提

ここでは、実行前に引っかかりやすい前提だけ先に押さえます。

/security-reviewは執筆時点では experimental preview に含まれるため、普通にCLIを開いただけでは使えない場合があります。さらに、Copilot CLIは実行中の操作内容に応じて権限確認を挟む設計なので、途中で承認を求められても故障ではありません。

最初につまずきやすいのは、機能が無効のまま試すことと、承認プロンプトの意味が分からず止まることです。次の2つだけ理解しておけば、導入時の混乱はかなり減らせます。

experimentalを有効化する

執筆時点では、Copilot CLI の experimental 設定は既定で無効です。そのため、/security-reviewを試す前に experimental mode を有効にする必要があります。ここを飛ばすと、コマンドが出てこない段階で止まりやすくなります。

有効化の入口は、セッション単位で /experimental を使う方法と、実行時に –experimental を付ける方法です。まずは一時的に有効化して挙動を確かめ、その後に常用するかを判断すると安全です。常時有効化よりも、試す範囲を切って確認する運用のほうが混乱を減らせます。

権限プロンプトを理解する

Copilot CLI では、read-only の操作は自動で許可されやすく、変更や破壊的な操作、URL へのアクセスを含むものは明示的な承認が必要になります。つまり、レビューの途中で確認が出ても、それは危険信号ではなく通常の安全設計です。

大事なのは、何を許可しようとしているのかを読んで判断することです。セキュリティ確認のために使っているのに、意味を見ずに許可を連打すると本末転倒です。承認プロンプトは面倒な壁ではなく、実行内容を可視化する最後の確認と考えると扱いやすくなります。

何とどう使い分ける？

/security-reviewをうまく使うには、既存のレビューやGitHub security機能と競わせないことが重要です。

迷いやすいのは、似た名前の /review と、すでに使っている CodeQL や Dependabot、secret scanning との距離感です。/security-review はそれらの代用品ではなく、ローカル変更に対して早めに気付くための前段チェックとして置くのが自然です。

広く品質を見るもの、継続的に監視するもの、手元で先に危険を拾うものを分けて考えると、役割の衝突ではなく分担として整理できます。この視点があると、どこへ差し込むべきかを判断しやすくなります。

/reviewとの違い

/review は、ローカル変更に対して広くコードレビューを頼みたいときの入口です。設計、保守性、読みやすさなども含めて見てもらえるぶん、視点は汎用的です。

一方の /security-review は、同じCLI上で動いていても焦点がかなり絞られています。注目するのは、差分の書き方がセキュリティ事故につながりやすいかどうかで、一般的なリファクタ提案を受ける場ではありません。

そのため、普段は /review で全体を見て、公開前やコミット前に /security-review を重ねる使い方が噛み合います。片方に寄せるより、見る論点を分担させたほうが抜け漏れを減らせます。

CodeQLとの違い

CodeQL や Dependabot、secret scanning は、継続的にリポジトリを守る側の仕組みとして考えると分かりやすいです。対して /security-review は、自分が今触っている差分に対して、その場で不安を減らすためのオンデマンド確認です。

GitHub も、この新機能が既存の security 機能を置き換えるのではなく補完すると案内しています。つまり、後段のガードを外して /security-review だけに寄せる判断は危険です。

先にローカルで気付き、公開前後では既存の継続検査でもう一度守る。この二段構えで考えると、役割の衝突ではなく守備範囲の分担として理解できます。

向いている場面と限界

最後に、/security-reviewをどこで使うと効果が出やすいかを整理します。

向いているのは、コミット前の軽い確認、PRを出す前のセルフチェック、AIが生成したコードをそのまま入れる前の初動確認です。特に、急いで実装した差分や、動けばよいで進めた箇所に一度ブレーキを掛けたいときは相性が良いです。

一方で、これだけで運用を閉じるのは無理があります。継続的な監視、履歴をまたいだ検出、公開後も含めた守りは別の仕組みが必要です。手元で早く気付くための用途に限定すると、期待値のズレを避けられます。

よくある質問

まとめ

最後に、/security-review をどこへ置くべきかだけ持ち帰ってください。

まずは小さな変更やAI生成コードの取り込み前に1回挟み、既存の継続検査はそのまま残してください。手元で早く気付き、後段でも守る二段構えが、現時点ではもっとも無理のない使い方です。