3行まとめ
このテーマをもう少し広げて見るなら、GitHub Copilot code reviewに組織単位runner設定：content exclusion、custom instructionsの確認ポイント と GitHub Actionsのbot作成PRが承認後にCI実行可能に：github-actions[bot]、GITHUB_TOKEN、承認運用の確認ポイント も合わせて確認してください。CLIでの事前レビューに加えて、Pull Request上のCopilot code reviewを組織設定でどう制御するかを確認できます。
2026年6月10日に、GitHub Copilot CLIの /security-review slash commandがexperimentalなpublic previewとして告知された。
GitHub code scanning、Dependabot、GitHub secret scanningの代替ではなく、コミット前の追加チェックとして読む。
experimental mode、組織ポリシー、AI Credits、承認プロンプト、信頼ディレクトリ、sandbox、人間の確認フローを決めておく。
導入判断では、開発者の手元で行う追加レビューと、継続的な公式スキャンを分けて考える。
- GitHubは2026年6月10日、GitHub Copilot CLIで
/security-reviewslash commandをexperimentalなpublic previewとして告知した。ローカル変更に対してAI駆動のセキュリティレビューを実行するための機能だ。 - 公式Changelogは、このスキャンをGitHub code scanning、Dependabot、GitHub secret scanningの代替ではなく補完として説明している。導入判断では「コミット前の追加チェック」と「継続的な公式スキャン」を分けて読む必要がある。
- 試す前に、Copilot CLIのexperimental mode、組織ポリシー、AI Creditsなどの利用枠、承認プロンプト、信頼ディレクトリ、sandbox、結果を人間が確認する流れを決めておきたい。
GitHub Copilot CLIの周辺では、2026年6月にエージェント、レビュー、ターミナル操作、セキュリティ確認の更新が続いている。直近でも、同じ6月10日のGitHub ChangelogにCopilot Chatからagent sessionsを見られる更新や、GitHub CLIでdiscussionsやsub-issuesを扱う更新が並んだ。需要シグナルとしては、開発者が「ターミナルの中でどこまで任せ、どこを既存のセキュリティ運用に残すか」を知りたい局面に入っている。
この記事では、/security-reviewを新しい便利コマンドとしてだけ扱わない。GitHubが確認できる範囲で何を発表したのか、既存のCodeQL、Dependabot、secret scanningとどう分担するのか、管理者や開発チームがpreview段階で何を見ておくべきかを整理する。Microsoft Watch JapanはMicrosoftおよびGitHubとは非提携の情報整理サイトであり、本文は2026年6月11日JST時点の公開一次情報に基づく。
/security-reviewは何をするコマンドか
- 1experimental mode
Copilot CLIでexperimental modeを有効にし、任意のprojectで /security-review を実行する。
- 2ローカル変更
レビュー対象は、開発者の手元にあるコード変更や差分内のセキュリティ懸念になる。
- 3finding
高い確度のsecurity findingsをseverityとconfidence付きで返すと説明されている。
- 4suggestion
ターミナルを離れずに、適用を検討できる修正提案を確認する。
- 5人間の確認
AI駆動のレビューは補助線であり、言語、フレームワーク、入力経路、権限境界まで完全に判定するとは限らない。
例示された脆弱性クラスは検出保証ではなく、疑わしいパターンを見つけるための追加チェックとして扱う。
GitHub Changelogによると、/security-reviewはGitHub Copilot CLIでローカルのコード変更をレビューし、セキュリティ上の懸念をターミナル内で確認するためのslash commandだ。告知時点ではexperimental featureのpublic previewであり、一般提供済みの安定機能として読むべき段階ではない。
GitHubは、このコマンドが高い確度のsecurity findingsをseverityとconfidence付きで返し、ターミナルを離れずに適用を検討できる提案を出すと説明している。対象として例示されているのは、injection flaws、cross-site scripting、insecure data handling、path traversal、weak cryptographyなどの高影響クラスだ。
ここで重要なのは、例示された脆弱性クラスを「検出保証」と読まないことだ。AI駆動のレビューは、差分に対して疑わしいパターンを示す補助線になる。一方で、言語、フレームワーク、入力経路、実行時設定、権限境界、依存関係の状態まで完全に判定するとは限らない。
experimental modeを有効にして試す
条件
GitHub Changelogは、試すにはCopilot CLIでexperimental modeを有効にし、その後に任意のprojectで/security-reviewを実行すると案内している。GitHub Copilot CLIのREADMEでは、experimental modeはcopilot --experimentalで起動するか、CLI内の/experimental slash commandで有効化できると説明されている。いったん有効にすると設定に保存され、次回以降もexperimental modeが使われる扱いになる点も確認対象だ。
注意点
チームで使う場合は、個人が手元で一度だけ試すのか、検証端末や検証リポジトリに限定するのか、あるいはpreview機能を組織として許可するのかを分けたい。experimental modeは新機能に早く触れられる反面、仕様や表示、利用条件が変わる可能性が高い。
/reviewとは目的が違う
根拠
Copilot CLIには、コード変更のレビューを依頼する/reviewもある。GitHub Docsでは、/reviewはCLIからコード変更を分析し、コミット前に素早いフィードバックを得るための機能として説明されている。pathやfile patternで範囲を絞ることもでき、Copilotがコマンド実行を提案した場合は利用者が承認する流れになる。
使い分け
/security-reviewは、その中でもセキュリティ上の懸念に焦点を当てるコマンドとして読むと分かりやすい。通常のレビューは可読性、設計、実装上の改善点も含む可能性がある。一方、/security-reviewは高影響の脆弱性パターンに意識を寄せる。両方を使う場合も、同じ結果が出る前提ではなく、目的別の確認として扱うほうが安全だ。
どこで使うべきか
- 変更直後
認証まわり、ユーザー入力を扱うAPI、ファイルパス、暗号やトークン、テンプレート出力などの変更後に見る。
- コミット前
ローカル変更、未追跡ファイル、生成物、設定ファイルの扱いを確認しながら追加チェックとして使う。
- PR前
findingのseverity、confidence、根拠、修正提案を人間の差分レビューやテストにつなげる。
- 本番コード
指摘されたファイル、該当diff、入力源、出力先、権限チェック、ログ出力、secretの扱い、既存アラートを突き合わせる。
- 止める条件
false positive、費用や利用上限、承認設定、ログ、セキュリティ担当の評価体制に問題があれば検証に戻す。
AIが出したfindingは、脆弱性確定でも修正完了でもなく、次の確認につなげるきっかけとして扱う。
/security-reviewが効きやすいのは、差分を書いた直後からPRを出す前までの短い区間だ。たとえば、認証まわりの変更、ユーザー入力を扱うAPI、ファイルパスを組み立てる処理、暗号やトークンを扱う処理、テンプレートへの出力処理などを変更したあと、コミット前の追加チェックとして使うイメージになる。
ただし、これだけで「セキュリティレビューが終わった」とは考えないほうがいい。AIが出したfindingは、修正候補を探すきっかけであって、脆弱性確定でも修正完了でもない。人間の差分レビュー、テスト、既存のスキャン、必要ならセキュリティ担当者の確認につなげて初めて運用に載せられる。
まず小さな非本番リポジトリで見る
検証条件
最初に試すなら、secretを含まず、本番権限も持たない小さなリポジトリがよい。目的は「どれだけ賢いか」を一度で判定することではなく、Copilot CLIが何を読もうとするか、どのような承認を求めるか、findingの表現は開発者にとって扱いやすいか、suggestionを適用したあとにテストできるかを知ることだ。
評価基準
検証では、以下を記録しておくとチーム運用に移しやすい。
| 確認項目 | 見るポイント |
|---|---|
| 対象範囲 | ローカル変更、未追跡ファイル、生成物、設定ファイルをどう扱うか |
| findingの粒度 | severity、confidence、根拠、修正提案がレビューに使えるか |
| 既存ツールとの重なり | CodeQL alert、secret scanning alert、Dependabot alertと同じ問題か |
| 承認の流れ | CLIがコマンド実行やファイル操作を求める場合に人間が判断できるか |
| 修正後の確認 | unit test、integration test、静的解析、人間レビューまで戻せるか |
本番コードでは差分と既存スキャンを突き合わせる
確認項目
本番リポジトリに持ち込む場合は、/security-reviewの出力を単独で採用しない。指摘されたファイル、該当diff、入力源、出力先、権限チェック、ログ出力、secretの扱い、依存関係、既存アラートを突き合わせる。AIのsuggestionをそのまま入れると、過剰なvalidation、互換性低下、例外処理の欠落、ログ不足といった別の問題が入る可能性もある。
止める条件
止める条件も先に決めておきたい。false positiveが多すぎる、費用や利用上限が読めない、承認設定が強すぎる、ログを残せない、セキュリティ担当が結果を評価できない、といった状態なら、全社展開ではなく検証に戻すほうがよい。
CodeQL・Dependabot・Secret scanningとは役割が違う
セキュリティ機能の比較では勝敗ではなく、対象、タイミング、残る証跡、責任分界を分けて読む。
GitHub Changelogは、/security-reviewについて「GitHub code scanning、Dependabot、GitHub secret scanningに依存しないCopilot-driven scan」と説明し、同時にそれらを補完するものだと位置づけている。ここを読み違えると、導入判断を誤る。
要点は、実行タイミングと責任分界だ。/security-reviewは開発者の手元でローカル変更を見やすい。CodeQLはGitHub上のcode scanning alertsとして継続的に結果を扱いやすい。Secret scanningは認証情報の漏えい検出とpush protectionに強い。Dependabotは脆弱な依存関係の検出や更新PRに向いている。
| 機能 | 主な対象 | 実行タイミング | 結果を見る場所 | 代替できない理由 |
|---|---|---|---|---|
Copilot CLI /security-review | ローカル変更、差分内のセキュリティ懸念 | コミット前、PR前、任意実行 | Copilot CLIのターミナル | AI駆動の事前レビューであり、継続的な公式alertや組織レポートとは役割が違う |
| CodeQL code scanning | コード上の脆弱性やエラー | push、PR、schedule、CIなどの設定に応じて実行 | GitHubのcode scanning alerts | クエリとデータベースに基づく静的解析で、監査やtriageに残しやすい |
| Dependabot alerts/security updates | 既知の脆弱性を含む依存関係 | dependency graphやadvisoryの更新に応じて通知、更新PR | GitHubのDependabot alertsやPR | 依存関係とadvisory情報を扱うため、ローカル差分レビューだけでは代替できない |
| Secret scanning/push protection | token、credential、secret pattern | push前後、repository/organizationの設定に応じて検出 | Security and quality tab、push時のブロック表示など | credential leakの検出と防止が目的で、AIレビューが見逃しても無効化すべきではない |
CodeQLは継続的な静的解析の軸
根拠
GitHub Docsでは、CodeQLはコードをデータとして扱い、クエリを実行して潜在的な脆弱性やエラーを見つけ、GitHubのcode scanning alertsとして結果を表示すると説明されている。C/C++、C#、Go、Java/Kotlin、JavaScript/TypeScript、Python、Ruby、Rust、Swift、GitHub Actions workflowsなど、対応言語も定義されている。
確認項目
このため、/security-reviewで出た指摘は、CodeQLのalertと照合するとよい。同じ問題がCodeQLにも出るなら、組織の既存triage手順に乗せられる。出ない場合でも、CodeQLのquery範囲外、言語/フレームワークの制約、設定不足、あるいはAI側の過剰指摘の可能性がある。どちらか一方だけを絶対視しないほうがいい。
Secret scanningは認証情報漏えいの防波堤
根拠
Secret scanningは、露出したcredentialを検出し、不正利用される前に対処するための機能だ。GitHub Docsでは、credential leakが見つかった場合にrepositoryのSecurity and quality tabへalertが生成され、影響を受けたcredentialをすぐにrotateするよう案内されている。Push protectionは、hardcoded credentialsがrepositoryへ届く前にpushを止めるためのsecret scanning機能として説明されている。
注意点
/security-reviewで「insecure data handling」やsecretに近い扱いが見つかることはあり得る。しかし、それはsecret scanningやpush protectionを外してよい理由にはならない。secret scanningはcredential pattern、providerとの連携、push時のブロック、alert運用に関係する。AIレビューは、設計や差分の文脈から危なそうな扱いを見つける補助線だ。
Dependabotは依存関係の脆弱性を見る
根拠
Dependabot alertsは、脆弱な依存関係を見つけ、修正につなげるための機能だ。Dependabot security updatesを有効にすると、既知の脆弱性を含む依存関係を安全な版へ上げるPRを自動で作成できる場合がある。
注意点
/security-reviewは、dependency graphやGitHub Advisory Databaseの更新を監視する仕組みではない。たとえば、差分内で安全そうに見えるコードでも、使っているpackageに既知の脆弱性があればDependabot側で見る必要がある。逆に、依存関係が安全でも、入力値の検証や権限チェックが足りなければ/security-reviewや人間レビューの出番になる。
CLIエージェントの権限と承認を先に見る
対象repositoryのroot、対象branch、変更範囲、読み取り可能なファイルを決める。
cloud and local sandboxes、VM、container、専用systemの利用を検討する。
最初の検証では、Copilot CLIが提案するコマンドやファイル操作を人間が確認する。
関係のないsecret、個人ファイル、別案件のコードが読み取り対象にならないようにする。
MCP server、環境変数、外部通信をどこまで許すかを導入判断の中心に置く。
/security-review自体は安全確認のためのコマンドだが、実行環境の権限が強すぎるとCLI操作のリスクが大きくなる。
セキュリティレビューのコマンドを使うときほど、Copilot CLIに与える権限を軽く見ないほうがいい。GitHub Docsは、Copilot CLIが利用者の代わりにファイルを変更したり、シェルコマンドを実行したりする可能性があるため、承認を求められたコマンドを慎重に確認するよう案内している。
/security-review自体は安全確認のためのコマンドだが、実行環境の権限が強すぎると、レビュー対象よりもCLI操作のリスクが大きくなる。自動承認、信頼ディレクトリ、secretを含む作業ツリー、MCP server、環境変数、外部通信をどこまで許すかが導入判断の中心になる。
信頼ディレクトリを確認する
根拠
GitHub Docsでは、trusted directoriesはCopilot CLIがどこでファイルを読み、変更し、実行できるかを制御するものとして説明されている。信頼できないファイルが含まれるディレクトリや、機密データを含むディレクトリで起動しないよう注意が書かれている。特にhome directoryで起動しないことが例として挙げられている。
確認項目
この注意は、/security-reviewにもそのまま当てはまる。便利だからといって、広すぎるディレクトリで実行すれば、関係のないsecret、個人ファイル、別案件のコードが読み取り対象になる可能性がある。まず対象repositoryのroot、対象branch、変更範囲、読み取り可能なファイルを決めるべきだ。
sandboxを検討する
条件
GitHub Docsは、automatic approval optionsのリスクを下げる方法として、GitHub Copilotのcloud and local sandboxes、あるいはVM、container、専用systemを使う選択肢を示している。preview機能を試す段階では、sandboxの有無が運用上の大きな差になる。
注意点
すでにGitHub Copilot sandboxesがpublic preview：ローカル/クラウド実行、権限、課金の確認ポイントでも整理したように、sandboxは万能の免罪符ではない。ローカルファイル、ネットワーク、認証情報、CLIの許可設定をどう隔離するかを確認してから使う必要がある。
自動承認は最後に検討する
セキュリティレビューを速く回す目的で、承認プロンプトを広く自動化したくなる場面はある。しかし、preview段階の機能で自動承認を広げるのは慎重に扱いたい。少なくとも、最初の検証ではCopilot CLIが提案するコマンドやファイル操作を人間が確認し、何を必要としているかを把握してから判断するほうがいい。
チーム運用にするなら、以下を決める。
- 誰がexperimental modeを有効にしてよいか
- どのrepositoryで
/security-reviewを許可するか - secretや本番credentialを含む作業ツリーで実行してよいか
- MCP serverや外部ツールを併用する場合、どの権限まで認めるか
- findingやsuggestionをどこに記録し、誰が採否を決めるか
組織ポリシー、利用枠、管理者の確認ポイント
preview段階では、全社標準化より先に対象repository、実行回数、採用率、false positive率、既存スキャンとの重なりを見る。
GitHub Docsでは、Copilot CLIはすべてのCopilot plansで利用できる一方、組織からCopilotを受けている場合は、組織設定でCopilot CLI policyが有効になっている必要があると説明されている。個人の端末でコマンドが動くかどうかだけでなく、組織としてpreview機能をどう扱うかを確認したい。
また、Copilot CLIの利用はモデルや処理するtoken量に応じてAI Creditsを消費する、とDocsで説明されている。モデル変更、拡張context window、reasoning levelなども消費量に影響する。/security-reviewの実行がどの利用枠として見えるかは、公開時点のDocs、契約、管理画面、usage reportで確認する必要がある。
管理者が先に見るべき表
確認項目
| 領域 | 確認するもの | 決めること |
|---|---|---|
| preview許可 | experimental mode、対象ユーザー、対象repository | 個人検証に限るか、チーム検証に広げるか |
| 利用枠 | AI Credits、usage limits、契約上の上限、レポート | 何回程度の実行を許すか、budget到達時にどう止めるか |
| 権限 | trusted directories、approval prompts、sandbox、MCP server | 自動承認を許すか、secretを含む環境で禁止するか |
| ログ | findingの保存先、suggestionの採否、監査証跡 | どの結果をPRやissueに残すか |
| 責任分界 | 開発者、レビュアー、セキュリティ担当、管理者 | AI指摘を誰が確認し、誰が却下できるか |
全社標準化より先に検証条件を置く
評価基準
/security-reviewは、security-mindedな開発者には魅力的な機能だ。PR前に明らかな危険パターンを拾えれば、レビュー待ちやCI後の手戻りを減らせる。教育用途としても、なぜ危ないかを差分の文脈で説明してくれる可能性がある。
注意点
それでも、最初から「全PRで必ず実行」と決める必要はない。preview段階では、対象repositoryを絞り、実行回数、finding採用率、false positive率、修正後のテスト成功率、既存スキャンとの重なり、開発者の負担、AI Creditsの消費を見てから判断するのが現実的だ。
非ライセンスユーザーやbot起点の扱いも確認する
Copilot CLIを利用するには、利用者のplanや組織ポリシーが関係する。チーム内で誰が実行するのか、外部contributorやbotが作ったPRに対して誰がローカルレビューするのか、結果をどこに残すのかを先に決めたい。/security-reviewをCIの代わりに自動化するような設計は、公式Changelogの説明からは読み取れないため、本文公開時点では人間がCLIで実行するpreview機能として扱う。
導入パターン別チェックリスト
非本番repositoryで試し、該当diff、入力値、出力先、既存テスト、既存alertを照合する。
対象repository、対象branch、実行タイミング、結果の共有先を決める。
Copilot CLI policy、preview機能の許可、利用枠、sandbox、ログ、監査証跡を確認する。
CodeQL、secret scanning、Dependabot、branch protection、required reviews、security manager権限とのつなぎ方を見る。
/security-reviewのfindingをissue化するのか、PRコメントに残すのか、ローカルの参考情報にとどめるのかで監査と再現性が変わる。
導入判断は、開発者個人、チーム、セキュリティ管理者で見る場所が違う。ひとつのコマンドを全員が同じ意味で使うと、期待値のずれが出やすい。
開発者個人が試す場合
確認項目
まずは非本番repositoryで、copilot --experimentalまたはCLI内の/experimentalを使い、/security-reviewを実行する。結果を見たら、該当diff、入力値、出力先、既存テスト、既存alertを照合する。suggestionを適用する場合も、修正後にテストと通常のレビューを通す。
評価基準
見るべき点は、findingが具体的か、severityとconfidenceが自分の判断に役立つか、修正提案がコードベースの設計に合っているか、余計なファイルやsecretに触れようとしていないかだ。便利さだけでなく、承認の分かりやすさも評価する。
開発チームで検証する場合
チームでは、対象repository、対象branch、実行タイミング、結果の共有先を決める。たとえば、認証/認可、支払い、ファイルアップロード、管理画面、外部API連携など、セキュリティ影響が大きい差分に限って試す形が考えられる。
false positiveや見逃しの議論も避けない。AI指摘を採用しなかった理由、既存スキャナで見えなかった理由、修正したあとに通したテストを記録すると、あとで標準化するか止めるかを判断しやすい。
セキュリティ/管理者が見る場合
管理者は、Copilot CLI policy、preview機能の許可、利用枠、sandbox、ログ、監査証跡を確認する。セキュリティレビュー機能であっても、CLIエージェントが強い権限を持つなら、利用ルールを決める必要がある。
また、CodeQL、secret scanning、Dependabot、branch protection、required reviews、security manager権限とどうつなぐかも見る。/security-reviewのfindingをissue化するのか、PRコメントに残すのか、ローカルの参考情報にとどめるのかで、監査と再現性が変わる。
2026年6月時点の読み方
GitHub Copilot CLIの刷新、Copilot sandboxes、第三者コーディングエージェントの安全検証、periodic code scanningなどの更新が続いている。
CodeQL、Secret scanning、Dependabotは引き続き別の役割を持つ。
/security-reviewは、開発者が自分の差分を見直すための前段の追加レイヤーとして読む。
experimentalから一般提供へ進むのか、利用条件や既存セキュリティ機能との連携が更新されるのかを見る。
現時点では、継続的静的解析、credential漏えい防止、依存関係監視を置き換える機能として扱わない。
今回の/security-reviewは、Microsoft/GitHubの開発者向けAIエージェント機能が「コードを書く」だけでなく「変更の安全性を確認する」方向へ広がっていることを示す更新だ。直近では、GitHub Copilot CLIの刷新、Copilot sandboxes、第三者コーディングエージェントの安全検証、periodic code scanningなど、関連するセキュリティ/エージェント更新が続いている。
一方で、preview機能を過大評価するのは危ない。CodeQLのような継続的静的解析、Secret scanningのようなcredential漏えい防止、Dependabotのような依存関係監視は、引き続き別の役割を持つ。/security-reviewは、その前段で開発者が自分の差分を見直すための追加レイヤーとして読むのが現時点では自然だ。
Microsoft Watch Japanの月次まとめでは、2026年6月のMicrosoft/GitHub関連更新を継続して追っている。今後、/security-reviewがexperimentalから一般提供へ進むのか、Copilot CLIのDocsで利用条件が更新されるのか、CodeQLやsecret scanningとの連携が明示されるのかを確認したい。
次に読むなら
参照した主な情報源
- GitHub Changelog, "Dedicated security review command now available in Copilot CLI"。2026年6月11日JST確認。https://github.blog/changelog/2026-06-10-dedicated-security-review-command-now-available-in-copilot-cli/
- GitHub Docs, "About GitHub Copilot CLI"。2026年6月11日JST確認。https://docs.github.com/en/copilot/concepts/agents/about-copilot-cli
- GitHub Docs, "Requesting a code review with GitHub Copilot CLI"。2026年6月11日JST確認。https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/agentic-code-review
- GitHub Copilot CLI repository README。2026年6月11日JST確認。https://github.com/github/copilot-cli
- GitHub Docs, "Code scanning with CodeQL"。2026年6月11日JST確認。https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql
- GitHub Docs, "Secret scanning"。2026年6月11日JST確認。https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
- GitHub Docs, "Push protection"。2026年6月11日JST確認。https://docs.github.com/en/code-security/concepts/secret-security/push-protection
- GitHub Docs, "Dependabot alerts"。2026年6月11日JST確認。https://docs.github.com/code-security/dependabot/dependabot-alerts/about-dependabot-alerts
更新履歴
- 2026年6月11日JST
GitHub Changelog、GitHub Docs、GitHub Copilot CLI READMEを確認し、public preview、experimental mode、既存セキュリティ機能との分担を整理した。
- 次回確認
GitHub DocsのCopilot CLIページ、Copilot billing/usage limits、CodeQL/secret scanning/Dependabot Docs、GitHub Changelogの後続発表、GitHub Communityでの公式回答を確認する。
本文は2026年6月11日JST時点の公開一次情報に基づく。
- 2026年6月11日JST: GitHub ChangelogとGitHub Docs、GitHub Copilot CLI READMEを確認し、
/security-reviewのpublic preview、experimental mode、既存セキュリティ機能との分担を整理した。 - 次回確認: GitHub DocsのCopilot CLIページ、Copilot billing/usage limits、CodeQL/secret scanning/Dependabot Docs、GitHub Changelogの後続発表、GitHub Communityでの公式回答を確認対象にする。