Claude Codeの/security-reviewコマンド｜コード変更のセキュリティリスクをAIで自動検出する

Claude Codeの/security-reviewコマンドは、直近のコード変更に対してSQLインジェクション・XSS・認証バイパスなどの脆弱性をAIが自動検出し、修正案まで提示します。CI/CDへの組み込みで開発フロー内にセキュリティゲートを構築できます。

——「コードレビューでセキュリティ観点が抜ける」「専任のセキュリティエンジニアがいないチームでも脆弱性を検出したい」——Claude Codeの/security-reviewコマンドがこの課題を解決します。

Claude Codeの/security-reviewコマンドは、直近のコード変更に対してセキュリティ観点のレビューを自動実行します。SQLインジェクション、XSS、認証バイパスなどの脆弱性パターンをAIが検出し、修正案まで提示します。手動レビューだけでは見落としがちなセキュリティリスクを、開発フローの中で自動的に洗い出せる機能です。

この記事でわかること

• /security-reviewコマンドの基本的な仕組みと実行方法
• 検出できる脆弱性パターンの分類（OWASP Top 10対応）
• 実務での活用パターン3選（PR前チェック、CI/CD組み込み、定期監査）
• Hooksとの組み合わせによるセキュリティゲートの構築方法
• /security-reviewの検出精度を高める設定テクニック

/security-reviewとは

/security-reviewは、Claude Codeに組み込まれたスラッシュコマンドの一つです。実行すると、現在のGit差分（ステージ済み・未ステージの変更）を対象に、セキュリティ上の問題がないかをAIが分析します。

従来のセキュリティレビューは、専門知識を持ったエンジニアが手動でコードを精査するか、SonarQubeやSemgrepといった静的解析ツールを導入する必要がありました。/security-reviewはその中間に位置づけられます。静的解析ツールのようにルールベースで機械的にパターンマッチするのではなく、コードの文脈を理解した上でリスクを評価します。

出典: Anthropic公式ドキュメント: Claude Code Overview

静的解析ツールとの違い

静的解析ツールが「既知のパターンを高速に検出する」のに対し、/security-reviewは「コードの意図を理解した上でリスクを判定する」という点に強みがあります。たとえば、認証チェックが特定のエンドポイントだけ漏れているケースや、ビジネスロジック上の権限昇格リスクなど、ルールベースでは書きにくい脆弱性パターンを捉えられます。

基本的な使い方

コマンド実行

Claude Codeのセッション中に、以下のコマンドを入力します。

/security-review

これだけで、現在の作業ディレクトリにあるGit差分を対象にセキュリティレビューが始まります。変更量にもよりますが、数十秒〜数分で結果が返ってきます。

出力の読み方

/security-reviewの出力は、以下の構造で返されます。

• リスクの概要: 検出されたセキュリティ上の懸念点のサマリー
• リスクレベル: Critical / High / Medium / Low の4段階
• 該当コードの特定: ファイル名・行番号・該当コードスニペット
• リスクの説明: なぜそのコードが危険なのかの解説
• 修正案: 具体的なコード修正の提案

対象範囲の指定

デフォルトではGit差分全体が対象ですが、プロンプトで対象を絞ることも可能です。

/security-review -- 認証周りのコードに絞ってレビューしてください

/security-review -- src/api/ ディレクトリの変更だけを対象にしてください

このように自然言語で対象範囲や重点ポイントを指定できるのは、LLMベースのレビューならではの利点です。

検出できる脆弱性パターン

/security-reviewは、OWASP Top 10をはじめとする主要な脆弱性カテゴリを網羅的にカバーしています。

主要な検出カテゴリ

ビジネスロジックの脆弱性

静的解析ツールでは検出が難しい、ビジネスロジックレベルの脆弱性も/security-reviewの得意分野です。

• 価格操作: ECサイトのカート処理で、クライアント側から送信された価格をそのまま使用している
• レースコンディション: 在庫チェックと注文確定の間にタイムウィンドウが存在する
• IDOR（Insecure Direct Object Reference）: ユーザーIDをパスパラメータで受け取り、所有権チェックなしにデータを返している
• Mass Assignment: リクエストボディのフィールドをそのままORMに渡し、意図しないカラムが更新される

これらは「コードの文脈」を理解しなければ検出できないため、LLMによるレビューが特に有効です。

実務での活用パターン

パターン1: PR作成前の最終チェック

Before: プルリクエストを作成した後にセキュリティレビューを依頼し、指摘を受けて修正するサイクルが発生していました。レビュアーの工数も大きく、1件あたり30分〜1時間のレビュー時間がかかっていました。

After: git addした後、PR作成前に/security-reviewを実行します。Critical・Highレベルの指摘があればその場で修正し、修正済みの状態でPRを作成します。

`# コード変更をステージ

git add -A

/security-review

git commit -m "feat: add user authentication endpoint"

gh pr create`

この運用により、PRレビューでのセキュリティ指摘が大幅に減少します。レビュアーはビジネスロジックやアーキテクチャの議論に集中でき、レビューサイクル全体が短縮されます。

パターン2: CI/CDパイプラインへの組み込み

GitHub Actionsなどのパイプラインに/security-reviewを組み込むことで、全PRに対してセキュリティチェックを自動実行できます。Claude Codeのヘッドレスモード（-pフラグ）を活用します。

`# .github/workflows/security-review.yml

name: Security Review

on:

pull_request:

branches: [main]

jobs:

• security-review:
• runs-on: ubuntu-latest
• steps:

• uses: actions/checkout@v4

with:

fetch-depth: 0

• name: Run Claude Code Security Review

run: |

claude -p "このPRの変更内容をセキュリティ観点でレビューしてください。Critical/Highレベルの問題があればexitコード1で終了してください。"

env:

ANTHROPIC_API_KEY: $`

CriticalまたはHighレベルの問題が検出された場合にCIを失敗させることで、セキュリティリスクのあるコードがmainブランチにマージされることを防止します。詳しくは「Claude Code × CI/CD自動化」で解説しています。

パターン3: 定期的なコードベース監査

新規の変更だけでなく、既存コードベース全体を定期的に監査する運用も有効です。

`# 直近1ヶ月の変更を対象にセキュリティレビュー

git diff HEAD~100..HEAD | claude -p "以下のdiffをセキュリティ観点でレビューしてください。OWASP Top 10に基づいてリスクを分類し、優先度順にレポートしてください。"`

Before: 年に1〜2回、外部のセキュリティ監査会社に依頼して脆弱性診断を実施していました。費用は1回あたり数百万円、結果が出るまでに2〜3週間かかっていました。

After: 月次で/security-reviewによる内部監査を実施し、外部監査は年1回に削減します。日常的にセキュリティ品質を維持しつつ、コストを最適化できます。外部監査を完全に置き換えるものではありませんが、発見の頻度と速度が大幅に向上します。

関連コマンドとの組み合わせ

Hooks × /security-review: 自動セキュリティゲート

Claude Code Hooksと組み合わせることで、特定の操作の前後にセキュリティチェックを自動挿入できます。詳しくは「Claude Code Hooksで開発を自動化する方法」で解説しています。

`{

• "hooks": {
• "Stop": [
• {

"matcher": "",

"command": "echo 'セキュリティレビューを自動実行中...' && claude -p '直近の変更をセキュリティ観点でレビューしてください' --output-format json"

• }
• ]
• }

}`

この設定により、Claude Codeがタスクを完了するたびにセキュリティレビューが自動実行されます。

/diff × /security-review: 変更の可視化とリスク評価

/diffコマンドで変更内容を確認した後に/security-reviewを実行する流れが効果的です。

• /diff — 何が変わったかを把握する
• /security-review — その変更にリスクがないかを評価する
• 必要に応じて修正 — Claudeに修正を依頼する

CLAUDE.md × /security-review: プロジェクト固有のルール

CLAUDE.mdにプロジェクト固有のセキュリティルールを記述しておくと、/security-reviewの精度が向上します。

`# セキュリティポリシー

• すべてのAPIエンドポイントには認証ミドルウェアを必須とする
• ユーザー入力はzodスキーマでバリデーションする
• 環境変数以外の方法でシークレットを管理しない
• SQLクエリには必ずパラメータバインディングを使用する`

このようなルールがCLAUDE.mdに明記されていると、/security-reviewはプロジェクトのセキュリティ基準に照らしてレビューを行います。

/compact × /security-review: 大規模変更の効率的レビュー

変更量が多い場合、コンテキストウィンドウの消費が大きくなります。/compactでコンテキストを圧縮してから/security-reviewを実行することで、より多くの変更をレビュー対象に含められます。詳しくは「Claude Codeの/compactコマンド」で解説しています。

セキュリティレビューの精度を高めるコツ

1. CLAUDE.mdにセキュリティ基準を明文化する

プロジェクト固有の「やってはいけないこと」をCLAUDE.mdに記載しておくと、レビューの精度が格段に上がります。認証方式、暗号化ポリシー、使用禁止の関数やライブラリなどを列挙しておくのが効果的です。

2. レビュー対象を適切に絞る

変更量が膨大な場合、一度にすべてをレビューさせるよりも、ディレクトリやファイル単位で分割してレビューした方が精度が高くなります。特にセキュリティ上重要なコンポーネント（認証、決済、個人情報処理）を優先的にレビューする運用が推奨されます。

3. 検出結果をチームで蓄積する

/security-reviewが検出した脆弱性パターンを社内ナレッジとして蓄積し、CLAUDE.mdやコーディングガイドラインにフィードバックするサイクルを回すことで、チーム全体のセキュリティ意識が底上げされます。

あわせて読みたい

• Claude Code実践ガイド｜開発現場での活用パターン総まとめ
• Claude Codeのメモリ・コンテキスト管理｜CLAUDE.md設計からプロジェクト知識の永続化まで
• Claude Code × CI/CD自動化｜プルリクエストレビューからデプロイまでを自動化する

まとめ

本記事の要点をまとめます。

• 静的解析との使い分けが重要: /security-reviewはビジネスロジックの脆弱性やコンテキスト依存リスクの検出に強みがあり、静的解析ツールと補完的に使うことで最大の効果を発揮します
• CI/CDへの組み込みでセキュリティゲートを構築: PR前の自動実行やHooks連携で、人的レビューが手薄になりがちな箇所を継続的にカバーできます
• 検出結果のナレッジ化が長期的な効果を生む: 検出された脆弱性パターンをCLAUDE.mdやコーディングガイドラインにフィードバックすることでチーム全体のセキュリティ水準を高めます
• 多層防御の一部として位置づける: /security-reviewを唯一のセキュリティチェックとせず、SAST・コードレビュー・ペネトレーションテストと組み合わせた多層防御設計が重要です

まずはお気軽にStartLinkへご相談ください。

よくある質問（FAQ）

Q1. /security-reviewは静的解析ツール（SonarQube、Semgrep等）の代替になりますか？

完全な代替ではありません。静的解析ツールは既知のパターンを高速・網羅的に検出する点で優れており、CI/CDでの定常実行に適しています。/security-reviewはビジネスロジックの脆弱性やコンテキスト依存のリスク検出に強みがあります。両者を併用するのが最も効果的です。静的解析ツールで機械的なパターンを網羅し、/security-reviewでコンテキスト理解が必要な脆弱性を補完する運用を推奨します。

Q2. /security-reviewの結果をそのまま信頼してよいですか？

AIによるレビューのため、見落とし（偽陰性）や誤検出（偽陽性）の可能性はあります。Critical・Highレベルの指摘は必ず人間が確認し、修正判断を行ってください。一方で、Medium・Lowレベルの指摘はトリアージの参考として活用できます。重要なのは、/security-reviewを「唯一のセキュリティチェック」として位置づけるのではなく、多層防御の一つとして組み込むことです。

Q3. 大規模なコードベース全体をレビューさせることは可能ですか？

可能ですが、コンテキストウィンドウの制約があるため、一度にレビューできるコード量には限りがあります。大規模なコードベースの場合は、ディレクトリやモジュール単位で分割してレビューを実行するのが実用的です。特に認証・認可、決済処理、個人情報を扱うモジュールなど、セキュリティ上重要なコンポーネントを優先的にレビューする運用がおすすめです。