security-reviewとCodeQLの違い — Claude Codeでの使い分け
security-reviewはブランチ差分をモデルが読み、CodeQLはコードをデータベース化してクエリで調べます。検知の仕組み・対象言語・PRでの見え方・費用の条件を並べ、両方を置く場所を示します。
Claude Codeの/security-reviewとGitHubのCodeQLは、どちらも脆弱性を探しますが、探し方がまったく違います。/security-reviewは現在のブランチの差分をモデルが読んで指摘します。CodeQLはコードをデータベースに変換し、書かれたクエリで問題を探します。前者は手元で1回きり、後者はGitHub上でPRごとに自動で動く、という置き場所の違いも出ます。
結論から言うと、二者択一にする必要はありません。出荷前の手元確認に/security-review、PRとmainブランチの定常監視にCodeQL、と層を分けるのがsecurity-guidanceのドキュメントにある層の表とも合います。このページでは、その根拠になる違いを5つの軸で並べます。コマンド自体の使い方とエラー対処はClaude Code security-reviewでブランチの脆弱性を検知するに任せ、ここでは比較に絞ります。
一目で分かる違い
| 軸 | /security-review | CodeQL |
|---|---|---|
| 検知の仕組み | /security-reviewモデルがブランチ差分を読む | CodeQLコードのデータベースにクエリを実行 |
| 対象 | /security-revieworiginのデフォルトブランチとの差分 | CodeQLリポジトリのコード(PR・定期スキャン) |
| 実行場所 | /security-review手元のClaude Codeセッション | CodeQLGitHub Actions(または外部CI) |
| 結果の出方 | /security-reviewセッション内の指摘 | CodeQLcode scanning alertとPRのチェック |
| 前提条件 | /security-revieworiginリモートが必要 | CodeQL対応言語、公開リポジトリか有料ライセンス |
検知の仕組み — モデルの読解とクエリの実行
/security-reviewのコマンド説明は、ブランチとoriginのデフォルトブランチとの差分をレビューし、インジェクション、認証の問題、データ漏出のようなリスクを特定する、というものです。見るのは差分で、リポジトリ全体を毎回調べるわけではありません。
CodeQLは、コードをデータのように扱うための言語とツールです。手順は3段階です。
CodeQLが問題を見つけるまで
- 1
データベースを作る
コードベースを表すCodeQLデータベースを生成します。
- 2
クエリを実行する
そのデータベースに対してCodeQLクエリを走らせ、問題を探します。
- 3
アラートとして表示する
GitHubでcode scanningと組み合わせると、結果はcode scanning alertとして出ます。
CodeQLのデータフロー分析では、データがコード内をどう流れるかがGitHub上に表示されます。ユーザー入力が危険な関数まで届く経路や、機密情報が漏れる箇所を、経路つきで追えます。
この違いが、使い分けの核心です。クエリは書かれたとおりに動くので、同じクエリパックを使う限り結果が揃います。GitHubのドキュメントは、公開されたクエリパックでは依存関係とコンパイルキャッシュが同梱され、パックかCLIを更新するまで毎回同じ結果になると説明しています。
モデルによるレビューには、この保証を書いた記述がありません。security-guidanceプラグインのドキュメントは、モデルを使うレビューは問題を見逃すことがあるため、防御の1層として扱うよう述べています。再現性が必要な判定は、後述のとおりCI側のクエリ型に置くのが筋です。
対象の広さと言語の縛り
/security-reviewは言語を選びません。モデルが読めるコードなら、差分に入っていれば対象です。ただし差分に入っていない既存コードは、この1回では見ません。
CodeQLは対応言語が決まっています。
- C/C++
- C#
- Go
- Java/Kotlin
- JavaScript/TypeScript
- Python
- Ruby
- Rust
- Swift
- GitHub Actionsのワークフロー
GitHubのドキュメントは、これ以外の言語、たとえばPHPやScalaでは、アラートが出ないか解析が不完全になることがあると明記しています。PHPのプロジェクトでCodeQLを有効にしても、期待した検知にならない可能性がある、ということです。独自のフレームワークや依存ライブラリがモデル化されていない場合は、VS CodeのCodeQL拡張でモデルを作って解析を広げる手段があります。
リポジトリ全体を、モデルを使って掘り下げたい場合は、/security-reviewではなくClaude Securityプラグインが受け持ちます。複数のエージェントが脅威モデルを作り、見つけた問題を独立に確認してからレポートする仕組みです。差分スキャンもでき、ブランチの差分・PRの差分・単一コミットが対象になります。
PRでの見え方と、マージを止められるか
ここが運用上いちばん差が出ます。
CodeQLのcode scanningは、既定でデフォルトブランチへの定期解析とPR時の解析を行います。PRに出るアラートは、アラートの該当行がすべてPRの差分に含まれるときだけです。アラートは、重大度(Error / Warning / Note)に加えて、CodeQLの検知にはセキュリティ重大度(Critical / High / Medium / Low)が付きます。この値はCVSSの考え方に沿った、業界標準の段階です。
マージを止められるかどうかで、3つの役割が分かれます。PR上でClaudeのレビューを受けたい場合は、Code Review(TeamとEnterpriseプラン)が/security-reviewとは別にあります。
マージ判断への関わり方
CodeQL
必須チェックにすれば、アラートが残るPRのマージを止められます。
/security-review
手元の確認用です。結果をマージの条件にする仕組みはありません。
Claude Code Review
PRにコメントとチェックを残しますが、承認もブロックもしません。
「マージを機械的に止めたい」要件があるなら、その役はCodeQLのようなクエリ型のCI検査が担います。Claude Code側のドキュメントも、セキュリティ確認の層の表で、CIの行を「既存の静的解析や依存関係スキャナ。言語固有のルールやサプライチェーン検査」としています。モデルによるレビューが置き換える対象ではなく、並べて置く対象です。
費用と前提条件
どちらにも条件があり、満たせない場合の逃げ道が異なります。
CodeQLのcode scanningは、公開リポジトリでは使えます。組織所有のリポジトリではGitHub Code Securityを有効にした場合に使えます。さらに、code scanningはGitHub Actionsで動くため、ワークフローの実行ごとにActionsの分数を消費します。プライベートリポジトリで使うにはGitHub Code Securityのライセンスが必要です。
/security-reviewの前提は技術的なものです。originリモートが無いと、origin/HEADとの差分を作れず失敗します。
置き場所の決め方
この2つは競合ではなく、置く場所が別です。
どこに置くか
コミット前〜push前
/security-reviewで、ブランチの差分を一度確認します。自分の手を離れる前に、典型的な脆弱性を拾う目的です。PRとmainブランチ
CodeQLを必須チェックにして、対応言語のコードを機械的に監視します。
既存コード全体の点検
リポジトリ全体は
/security-reviewの対象外です。Claude Securityプラグインか、CodeQLの定期スキャンを使います。
手元では次のように流します。差分の確認が終わったら、ブランチを開いて/security-reviewを実行します。
/diff
/code-review
/security-review/diffで変更内容、/code-reviewで正確性、/security-reviewで脆弱性、という順がコマンド一覧の挙げる出荷前の流れです。その後のPRでは、CodeQLのチェックが同じ差分を別の仕組みで見直します。
両方が指摘した問題と、片方だけが指摘した問題
同じ箇所を両方が指摘したなら、優先して直す根拠になります。片方だけの指摘は、仕組みの違いから読み解けます。
- CodeQLだけが指摘: 既存コードとの組み合わせで成立するデータフロー上の問題。差分だけを読む
/security-reviewには見えにくい領域です。 /security-reviewだけが指摘: クエリに無い種類の不備、たとえば仕様の取り違えや、ロジックの読解が要る認証の穴。CodeQLのクエリは書かれた問題の型にしか反応しません。- どちらも指摘しない: 通ったことは安全の証明になりません。security-guidanceプラグインのドキュメントも、モデルのレビューは問題を見逃すことがあると述べています。
見落としやすい前提
比較で見落としやすい点が3つあります。
- 対応言語の外では、CodeQLのアラートが出ないことがあります。0件でも、その言語が対象かどうかを先に確かめます。
/security-reviewが読むのはチェックアウトしたソースコードで、動いているサイトやデプロイ済みのサービスは調べません。CodeQLの対象もコードで、動いているサービスの設定ではありません。- GitHub Action版の
anthropics/claude-code-security-reviewは、CLIのコマンドとは別の実装です。誤検知フィルタに関する不具合の報告があり、security-reviewのHaiku廃止で誤検知フィルタが無効化する理由に整理があります。
セッション内の自動チェックまで含めた層全体はClaude Code security-guidanceで脆弱性を自動検知するで、外部のスキャナをセッションに組み込む例はClaude CodeへのSnyk Studio導入手順で扱っています。
まとめ
/security-reviewは、手元で出荷前に差分を読ませる確認です。CodeQLは、対応言語のコードをクエリで継続的に監視し、PRの必須チェックにもできる仕組みです。再現性とマージ制御が必要な部分はCodeQL、柔軟な読解が効く部分は/security-reviewに分けると、片方の弱点をもう片方が埋めます。
導入の順番に迷うなら、対応言語のリポジトリでは先にCodeQLの既定セットアップを有効にします。次に、push前の習慣として/security-reviewを足します。プライベートリポジトリでは、CodeQL側にだけGitHub Code Securityのライセンスという条件が付きます。