Claude Code には /security-review というスラッシュコマンドが最初から入っています。プロジェクトのディレクトリで打つと、まだコミットしていない変更を読み、SQL インジェクションや XSS といった観点で脆弱性を探して報告します。同じ解析は GitHub Action としてプルリクエストにも掛けられます。ここでは手元での使い方、Action の設定、検査内容の調整のしかたを整理します。
security-review とは何か
/security-review は、Claude Code が既定で備えているスラッシュコマンドです。追加のインストールは要りません。中身は Anthropic が公開している GitHub Action anthropics/claude-code-security-review と同じ解析で、それを開発環境の中から直接呼べるようにしたものです。
特徴として公式が挙げているのは次の4点です。
- 差分を対象にする。プルリクエストに対しては変更のあったファイルだけを読みます
- パターンマッチで終わらせない。文字列の一致ではなくコードの意味を追って判断します
- 言語を選ばない。特定の言語向けのルールセットを持たない作りです
- 誤検知を絞り込む。ノイズを減らすためのフィルタが後段に入っています
利用できるのは、個人の有料プラン（Pro または Max）を使っている場合と、従量課金の API Console アカウントを持っている個人・企業です。
公式のヘルプ記事は、この機能について「既存のセキュリティ対策や人手のコードレビューを補完するものであって、置き換えるものではない」と明記しています。よくある脆弱性のパターンは拾いますが、これだけで安全性が担保されるわけではありません。導入するときは、既存のレビュー工程を減らす前提で設計しないでください。
手元で実行する
手順は2つだけです。Claude Code を最新版に更新し、対象プロジェクトのディレクトリで開いて、コマンドを打ちます。
# プロジェクトのディレクトリで Claude Code を開いてから
/security-review引数はありません。実行すると保留中の変更（pending changes）すべてが対象になります。つまり、いま書きかけの差分をコミットや push の前に一度通す、という使い方が想定されています。
他のスラッシュコマンドと同じように打てるので、コミット前の git diff を見るのと同じ感覚で挟めます。レビュー結果は指摘ごとに、どのコードのどこが問題で、どう直すかという形で返ってきます。
検出する脆弱性と、あえて除外するもの
探す対象として公式リポジトリが列挙しているのは次の10分類です。
| 分類 | 具体例 |
|---|---|
| インジェクション | SQL インジェクション、コマンドインジェクション、LDAP インジェクション、XPath インジェクション、NoSQL インジェクション、XXE |
| 認証・認可 | 認証の不備、権限昇格、安全でない直接オブジェクト参照、判定ロジックの迂回、セッションの欠陥 |
| データの露出 | ハードコードされた秘密情報、機微なデータのログ出力、情報漏えい、個人情報の取り扱い違反 |
| 暗号 | 弱いアルゴリズム、鍵管理の不備、安全でない乱数生成 |
| 入力検証 | 検証の欠落、サニタイズの不備、バッファオーバーフロー |
| 業務ロジックの欠陥 | 競合状態、TOCTOU（検査時と使用時のずれ） |
| 設定 | 安全でない既定値、セキュリティヘッダの欠落、緩すぎる CORS |
| サプライチェーン | 脆弱な依存パッケージ、タイポスクワッティング |
| コード実行 | デシリアライズ経由の RCE、pickle インジェクション、eval インジェクション |
| XSS | 反射型、蓄積型、DOM ベース |
逆に、意図的に報告しないものも決められています。誤検知が出やすく、出しても影響の小さい種類を落とすためです。
- サービス拒否（DoS）
- レート制限に関する指摘
- メモリ・CPU の枯渇
- 影響が実証されていない、一般論としての入力検証不足
- オープンリダイレクト
この除外リストは固定ではなく、後述の設定で組織のポリシーに合わせて上書きできます。「DoS も見たい」という要件があるなら、除外を外す指示を書く側の作業になります。
GitHub Actions でプルリクエストごとに走らせる
同じ解析を、プルリクエストが開かれるたびに自動で走らせられます。公式リポジトリが載せているワークフローはこれです。
name: Security Review
permissions:
pull-requests: write # PR にコメントするために必要
contents: read
on:
pull_request:
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha || github.sha }}
fetch-depth: 2
- uses: anthropics/claude-code-security-review@main
with:
comment-pr: true
claude-api-key: ${{ secrets.CLAUDE_API_KEY }}fetch-depth: 2 は差分を取るために要ります。1 だと直前のコミットが手元に無く、変更されたファイルを絞り込めません。
指定できる入力は次のとおりです。
| 入力 | 既定値 | 意味 |
|---|---|---|
claude-api-key | 必須 | 解析に使う API キー。Claude API と Claude Code の両方で有効になっているキーが要ります |
comment-pr | true | 指摘をプルリクエストにコメントするか |
upload-results | true | 結果をアーティファクトとしてアップロードするか |
exclude-directories | なし | 走査から外すディレクトリをカンマ区切りで指定する |
claude-model | claude-opus-4-1-20250805 | 解析に使うモデル名 |
claudecode-timeout | 20 | 解析のタイムアウト（分） |
run-every-commit | false | コミットごとに走らせる（キャッシュ判定を飛ばす）。コミット数の多い PR では誤検知が増えうる、と公式が注意している |
false-positive-filtering-instructions | なし | 誤検知フィルタの独自指示を書いたテキストファイルのパス |
custom-security-scan-instructions | なし | 監査プロンプトに追記する独自の走査指示を書いたテキストファイルのパス |
出力は findings-count（指摘の総数）と results-file（結果 JSON のパス）の2つです。件数を後続ステップの条件に使えます。
注意すべき制約があります。 公式リポジトリは、このアクションがプロンプトインジェクションに対して堅牢化されていないため、信頼できるプルリクエストのレビューにだけ使うようにと書いています。外部からの貢献を受けるリポジトリでは、GitHub 側の「外部コントリビューターすべてに承認を必須にする」設定を有効にして、メンテナが目を通してからワークフローが動くようにしてください。解析対象のコードにワークフローへの指示が仕込まれうる、という前提の話です。
検査内容をプロジェクトに合わせて変える
スラッシュコマンド側は、定義ファイルを自分のリポジトリに置くと上書きできます。
- 公式リポジトリの
security-review.mdを、自分のプロジェクトの.claude/commands/フォルダにコピーする - コピーした
security-review.mdを編集して、解析の内容を書き換える（誤検知フィルタに組織固有の方針を足す、など）
.claude/commands/ はカスタムスラッシュコマンドの置き場所なので、同名のファイルを置けば標準のものより優先されます。リポジトリに置けばチーム全員に同じ基準が配られる、という点も普通のカスタムコマンドと同じです。
GitHub Action 側は、ファイルをコピーするのではなくパスを渡す方式です。custom-security-scan-instructions に走査の追加指示を書いたテキストファイルを、false-positive-filtering-instructions に誤検知フィルタの指示を書いたテキストファイルを指定します。前者は監査プロンプトへの追記として効きます。
手元の /security-review と CI の Action で基準を揃えたいなら、両方に同じ方針を書く必要があります。片方だけ直すと、手元では通るのに PR で落ちる（またはその逆）という状態になります。
出典: anthropics/claude-code-security-review ／ Automated Security Reviews in Claude Code（Anthropic ヘルプセンター）