Claude Codeの/security-reviewで脆弱性を自動検出

本記事は2026年8月時点の情報です。

Claude Codeの/security-reviewコマンドは、現在のブランチの変更（2026年10月時点の仕様）に対してSQLインジェクション・XSS・認証バイパスなどの脆弱性をAIが自動検出し、修正案まで提示します。セキュリティレビューを「できる人がやる属人作業」から「開発フローに組み込まれた仕組み」に変えられるのが本質的な価値です。

——「セキュリティ観点がレビューで後回しになる」「専任のセキュリティエンジニアがおらず、詳しい人の目視頼みになっている」「チェックリストをスプレッドシートで配っても誰が見たか追えない」——開発現場でよく聞く声です。

/security-reviewとは、Claude Codeのセッション中に実行するスラッシュコマンドで、現在のGit差分を対象にセキュリティ観点のレビューをAIが自動実行する機能です。 検出した問題は該当コードの特定とリスクの説明つきで報告され、修正案も受け取れます。本記事の機能・コマンドの説明は2026年10月時点の公式ドキュメントに基づきます。手動レビューだけでは見落としがちなリスクを、開発フローの中で継続的に洗い出せる点が特徴です。

本記事は、Claude Codeを開発現場でどう使いこなすかをまとめた「Claude Code実践ガイド」シリーズの一部です。

この記事でわかること

セキュリティレビューが特定の担当者の目視に依存している状態から、コマンドとして仕組み化された状態に移行するために必要な考え方を、実際の操作から運用設計まで順に解説します。エンジニア個人のスキルに頼らず、チームとして同じ水準のレビューを回せるようにするための設計を軸にまとめています。

• /security-reviewの仕組みと基本操作 — Git差分を対象にした実行方法と、出力されるリスクレベル・修正案の読み方を整理します。
• 静的解析ツールとの使い分け — ルールベースの検出とLLMによる文脈理解の違いを比較表にし、どちらをどこに置くかを設計します。
• 実務での活用パターン3つ — PR作成前チェック、CI/CDへの組み込み、直近の変更の定期監査の3層で解説します。
• 精度を高める設計 — CLAUDE.mdへのセキュリティ基準の明文化と、検出結果をチームのナレッジに還流させる仕組みづくりを扱います。
• 向かないケースと限界 — AIレビューが苦手な領域と、人間が判断すべき範囲を率直に書きます。

エンジニアチームでAI活用を進めたい開発リーダーの方、セキュリティレビューが特定の担当者に依存している状態を変えたい方に向けて書いています。最後まで読むと、/security-reviewを単発のコマンドとしてではなく、開発フロー全体に組み込んだセキュリティゲートとして設計できるようになります。

/security-reviewとは何か

まずコマンドの正体と、既存のセキュリティ施策の中でどこに位置づくのかを整理します。ここを曖昧にしたまま導入すると、「AIが見てくれるから大丈夫」という危うい運用になりがちです。何ができて何ができないかをセットで押さえておくと、導入後の期待値のずれを防げます。

Git差分を対象にAIがレビューする仕組み

/security-reviewは、Claude Codeに組み込まれたスラッシュコマンドの一つです。2026年10月時点の公式ドキュメントでは、現在のブランチとoriginの既定ブランチとの差分を対象に、インジェクション・認証の問題・データ露出などのリスクを分析するコマンドとされています。差分の取得にoriginリモートが必要です。レビュー対象が「差分」という点が重要です。コードベース全体ではなく、今まさに書いたコードに焦点を当てた設計になっており、レビュー結果が「今回の変更に起因するリスクなのか」を判断しやすくなるという利点もあります。

出典: Claude Code公式ドキュメント: コマンド一覧

手動レビューと静的解析ツールの「中間」に位置する

従来のセキュリティレビューは、専門知識を持ったエンジニアが手動でコードを精査するか、SonarQubeやSemgrepといった静的解析ツールを導入する必要がありました。前者は品質が人に依存し、後者はルール定義とCI設定の整備コストがかかります。

/security-reviewはその中間に位置づけられます。静的解析ツールのようにルールベースで機械的にパターンマッチするのではなく、コードの文脈を理解した上でリスクを評価します。コマンド1つで実行できるため、導入のハードルは比較的低い設計です。この「専門ツールほど設定は重くないが、手動レビューよりは観点が安定している」という中間の立ち位置が、既存の施策を置き換えるのではなく補完する理由になっています。

「人」ではなく「仕組み」でレビュー品質を担保する

セキュリティレビューが回らない原因は、多くの場合メンバーの意識の低さではありません。レビューの観点が個人の頭の中にしかなく、忙しいときに真っ先に省略される工程になっているという構造の問題です。スプレッドシートでチェックリストを配るだけの運用が定着しにくいのも、同じ構造に原因があります。

/security-reviewの価値は、この観点をコマンドという形に固定できる点にあります。誰が実行しても同じ視点でレビューが走るため、新しく入ったメンバーでも同じ観点でチェックに参加しやすくなるという利点があります。個人の力量差をフローの設計で吸収するという考え方は、私たちがHubSpotのパイプライン設計で「ステージ移行時の必須入力プロパティ」を推奨しているのと同じ発想です。属人的なチェックリストではなく、実行すれば毎回同じ観点が適用される仕組みに置き換えることが、ここでの狙いです。

静的解析ツールとの違いと使い分け

「静的解析ツールを入れているから不要では」という質問をよくいただきます。結論としては役割が違うため、併用が前提になります。ここでは両者の特性を比較した上で、どちらをどのタイミングに置くかを設計します。

比較表で見る特性の違い

2026年10月時点の一般的な傾向を整理した比較です。

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

実行速度の差をフロー設計に反映する

実行速度は無視できない差です。静的解析ツールは短時間で終わるため、コミットのたびに走らせても開発のリズムを崩しません。一方で/security-reviewはLLMの応答を待つ分だけ時間がかかります。

この差をそのままフローに反映すると、静的解析は「コミット単位で常時」、/security-reviewは「PR作成前やマージ前などの節目」に置くのが自然な設計になります。すべての工程で最も重い手段を使うのではなく、頻度とコストのバランスで配置を決めるという考え方です。速度が違う2つの手段を同じ場所に重ねて置いても効果は薄く、役割ごとに配置を分けることが設計の出発点になります。

向かないケースを先に把握しておく

率直に書くと、/security-reviewが万能というわけではありません。以下のようなケースでは、他の手段を主役に据えたほうがよいかと思います（2026年10月時点の整理です）。

/security-reviewは多層防御の一層にすぎず、唯一のチェックにはなりません。なお、正確性のバグを含む一般的なコードレビューには、2026年10月時点で同梱スキルの/code-reviewがあり、セキュリティに絞る/security-reviewとは目的が異なります。この前提を社内で共有しておくことが、導入時の最初の合意事項になります。

基本的な使い方と出力の読み方

ここからは実際の操作です。コマンド自体は非常にシンプルですが、出力の読み方と対象範囲の絞り方を知っているかどうかで、実務での使い勝手が大きく変わります。

コマンドの実行

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

/security-review

これだけで、現在のブランチとoriginの既定ブランチとの差分を対象にセキュリティレビューが始まります。コミット前の変更が対象に含まれるかは状態によって変わり得るため、レビューしたい変更はコミットしておくと対象が明確です。差分の取得に失敗する場合は、originリモートが設定されているかを確認してください。変更量にもよりますが、結果が返るまで一定の待ち時間がかかります。待ち時間やトークンの消費量はステータスラインで確認できます。表示項目の設定方法はClaude Codeの見た目カスタマイズで解説しています。

以下の画面は、本記事で扱う/security-reviewや/diffといったスラッシュコマンドと、後述するgit commit・gh pr createといったターミナルコマンドを並べたものです。

出力の読み方

2026年10月時点の/security-reviewの出力は、概ね以下の要素で返されます。表示形式はバージョンによって変わることがあるため、実際の画面で確認してください。この構造を理解しておくと、チーム内で「Criticalは修正必須、Mediumはトリアージ」といった運用ルールを決めやすくなります。

特に「リスクの説明」が返ってくる点は、教育的な副次効果があります。指摘の理由が言語化されるため、レビューを受けた本人が次から同じ書き方を避けられるようになります。必須入力プロパティが新人に「何を確認すべきか」を教えるツールになるのと同じ構造です。指摘を一度きりの修正で終わらせず、理由まで読み込む習慣がチームに根づくと、同じ種類の指摘が繰り返し出る頻度も下がっていきます。

対象範囲の指定

既定ではブランチ全体の差分が対象です。変更が大きいときは、ブランチを機能単位に分けるか、通常のプロンプトで重点を伝えて確認します。

認証まわりの変更に絞って、セキュリティ観点でレビューしてください。

このように自然言語で重点ポイントを指定できるのは、LLMベースのレビューならではの利点です。ルール定義を書き換えることなく、その場の文脈に応じて観点を切り替えられます。

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

どこまで見てくれるのかが分からないと、人間側がどこを補えばよいか判断できません。ここでは検出カテゴリを整理し、特にLLMならではの強みが出る領域を掘り下げます。

OWASP Top 10に対応する主要カテゴリ

/security-reviewが扱う脆弱性は、OWASP Top 10をはじめとする主要なカテゴリです（2026年10月時点の公式説明では、インジェクション・認証の問題・データ露出などが例示されています）。以下は、これらを一般的な分類に当てはめた目安です。検出の網羅は保証されません。なお、既知の脆弱性を含む古い依存ライブラリは、公式公開のレビュー定義で対象外とされており、依存関係スキャナーの担当です（OWASPのA06:2021に当たる領域です）。

ビジネスロジックの脆弱性こそ本領

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

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

これらは「コードの文脈」を理解しなければ検出できないため、LLMによるレビューが特に有効です。逆に言えば、この領域こそが/security-reviewを導入する主な動機になります。既知のパターン検出だけが目的なら、静的解析ツールで足りるためです。

AIに任せる範囲と人間が判断する範囲

私たちはAIを「超一流の専門家」ではなく「優秀なアシスタント」として位置づけて活用することをおすすめしています。セキュリティレビューでも同じで、指摘を出すところまでをAIに任せ、最終判断は人間が持つのが現実的な設計です。

特にCritical・Highの指摘は、そのまま鵜呑みにせず人間が確認してください。自動で修正コミットまで走らせるような自律運用は、リスクが大きいため避けたほうが安全です。

実務での活用パターン3つ

コマンドを知っていても、どこに置くかを決めないと定着しません。ここでは開発フローの中での配置を、頻度の異なる3つのレイヤーに分けて設計します。

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

変更をコミットした後、PR作成前に/security-reviewを実行する運用です。Before/Afterで整理すると次のようになります。

# 変更をコミット（対象ファイルを指定して追加）
git add src/api/auth.ts
git commit -m "feat: add user authentication endpoint"

# Claude Codeのセッション内でセキュリティレビュー実行
/security-review

# 指摘があれば修正して追加コミットしてから
gh pr create

この運用により、PRレビューでのセキュリティ指摘を減らせます。レビューサイクル全体が短縮されるケースもあります。複数の機能を並行して進めている場合は、Git Worktreeによるブランチ分離で作業ディレクトリを分けておくと、差分に他の変更が混ざらずレビュー精度を保てます。

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

GitHub Actionsなどのパイプラインに同じ観点のレビューを組み込むことで、全PRに対してセキュリティチェックを自動実行できます。2026年10月時点では、claude -pによる非対話実行を使う方法と、/install-github-appで導入する公式のGitHub連携があります。ここではclaude -pの例を示します。GitHubの標準ランナーにはClaude Codeが入っていないため、実行前に導入ステップが必要です（公式のインストーラーを使う例です）。公式のanthropics/claude-code-actionや、セキュリティレビュー専用のanthropics/claude-code-security-reviewを使えば、この導入ステップは不要です。後者のREADMEには、信頼できるPRだけを対象にする前提で使うよう注意書きがあります。検出結果をチームへ即座に共有したい場合は、Claude Code × Slack連携で通知フローを組み合わせる方法があります。

# .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: Install Claude Code
        run: |
          curl -fsSL https://claude.ai/install.sh | bash
          echo "$HOME/.local/bin" >> "$GITHUB_PATH"
      - 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自動化」で解説しています。

ただし、いきなり全PRでCIを落とす設定にすると、偽陽性で開発が止まるリスクがあります。最初は結果をコメント出力するだけの「警告モード」で運用し、指摘の精度を確認してからブロッキングに切り替える段階的な導入をおすすめします。

以下の画面は、ヘッドレス実行に使うclaude -pと、変更履歴の確認に使うgit diffやgit logなど、CI/CD組み込みに関連するコマンドを並べたものです。

パターン3: 直近の変更の定期監査

新しく入った変更を、PR単位ではなく一定期間ごとにまとめて見直す運用も有効です。

# 直近100コミット分の変更差分をまとめてセキュリティレビュー（変更されていない既存コードは対象外）
git diff HEAD~100..HEAD | claude -p "以下のdiffをセキュリティ観点でレビューしてください。OWASP Top 10に基づいてリスクを分類し、優先度順にレポートしてください。"

この方法で見られるのは、指定した範囲の差分に現れた変更だけで、変更されていない既存コードは審査対象になりません。既存コード全体の棚卸しが必要な場合は、対象ディレクトリを分けて通常のプロンプトでレビューを依頼するか、静的解析ツールと外部監査を使ってください。外部監査を置き換えるものではありませんが、発見の頻度と速度を高められます。この月次実行は、セッション内の定期実行である/loopコマンドなどで仕組み化しておくと、実施漏れを防げます。/loopはセッションが生きている間だけ動くため、無人で安定して回したい月次の監査はCIのスケジュール実行などと組み合わせます。

3層をどう組み合わせるか

2026年10月時点で、次の3層に整理できます。

3つのパターンは択一ではなく、頻度の異なる層として重ねて使います。私たちはこの重ね方を「セキュリティゲートの3層モデル」として整理しています。それぞれの層で判断する主体が異なる点も、設計するうえで押さえておきたいポイントです。

実行を仕組みに組み込み、結果をリスクレベルで見える化し、同じ基準をチームで共有するという3層の考え方は、私たちがHubSpotの運用設計で重視している「自動化・可視化・一元管理」と同じ発想です。最初からこの3層すべてを構築しようとすると、設定と合意形成に時間がかかります。まずは開発者レイヤーの手動実行だけを1〜2週間ほど試し、指摘の質が実務に耐えると判断できてからパイプラインレイヤーに広げるのが現実的です。

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

/security-reviewは単独でも機能しますが、他のコマンドと組み合わせることで開発フロー全体に溶け込みます。実装からリリースまでの一連の流れの中に置くことで初めて、単発のチェックではなく継続的なセキュリティゲートとして機能します。ここでは実務で効果の高い組み合わせを紹介します。

Hooksによる自動セキュリティゲート

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

設定ファイル（.claude/settings.json）では、Stopフックからスクリプトを呼び出します。

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/security-review-on-stop.sh"
          }
        ]
      }
    ]
  }
}

スクリプト（.claude/hooks/security-review-on-stop.sh、実行権限が必要です）は次のとおりです。標準出力にはJSONだけを出す点が要所です。

#!/usr/bin/env bash
# Stopフックの入力（JSON）は標準入力で渡される
input=$(cat)

# 既にStopフックの結果で続行中なら、何もせず終了（再帰・無限ループ防止）
if [ "$(echo "$input" | jq -r '.stop_hook_active')" = "true" ]; then
  exit 0
fi

# 子のclaude -pではフックを無効にする（子のStopフックが再び起動するのを防ぐ）
review=$(claude -p "git diff HEAD の変更をセキュリティ観点でレビューしてください。問題がなければ OK とだけ答えてください。" \
  --output-format json --settings '{"disableAllHooks": true}' | jq -r '.result')

# 問題なしならそのまま停止を許可する
if [ "$review" = "OK" ]; then
  exit 0
fi

# 指摘があれば、停止を止めて内容を親のClaudeに返す（標準出力はこのJSONだけにする）
jq -n --arg reason "$review" '{decision: "block", reason: $reason}'

フックには2026年10月時点でcommand・http・promptなどの種別があり、上の例はcommandです。公式ドキュメントでは、Stopフックは終了コード0のときに標準出力のJSONが解釈され、decision: "block"とreasonを返すとClaudeの停止を止めてreasonを伝えられるとされています。decisionを省略すれば通常どおり停止します。そのためスクリプトは、子のレビュー結果を取り出してreasonに入れ、標準出力にはJSON以外（echoによる進捗表示など）を混ぜないようにしています。blockで続行させるとStopフックが再度呼ばれますが、その入力のstop_hook_activeはtrueになります。公式ドキュメントはこの値を確認して、解決しない条件で止め続けるのを避けるよう案内しており、例でもtrueなら即終了しています（連続で続行できる回数には上限もあります）。さらに、コマンド内のclaude -pも同じプロジェクトの設定を読み込むため、そのままでは子プロセスのStopフックがさらにclaude -pを起動し、連鎖する恐れがあります。例では--settings '{"disableAllHooks": true}'を渡して、子の実行ではフックを無効にしています（公式ドキュメントに記載のある指定方法です）。--bareを付ける方法もありますが、CLAUDE.mdなども読み込まれなくなります。この設定により、Claude Codeが応答を終えるたびにセキュリティレビューが自動実行され、指摘があればClaudeがその内容を受けて対応を続けます。ただし応答のたびに別のClaudeを起動するため、時間とコストが増えます。実際の運用では、対象を絞るか、PR作成前のタイミングに限定することをおすすめします。「思い出したら実行する」という個人の運用から、「フローに組み込まれているので実行される」という状態に移行できるのがポイントです。

/diffとの連携で変更把握とリスク評価を分ける

/diffコマンドで変更内容を確認した後に/security-reviewを実行する流れが効果的です。何が変わったかの把握と、それが危険かどうかの評価を分けて行うことで、レビューの解像度が上がります。

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

CLAUDE.mdでプロジェクト固有のルールを効かせる

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

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

CLAUDE.mdはセッションの文脈として読み込まれるため、このようなルールが明記されていると、プロジェクトのセキュリティ基準に沿った指摘になりやすくなります。汎用的な脆弱性検出から、自社のポリシーに沿ったレビューへと性格が変わる部分です。CLAUDE.mdの設計思想は「Claude Codeのメモリ・コンテキスト管理」で詳しく扱っています。

/compactで大規模変更をレビュー対象に収める

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

検出精度を高める設計のコツ

同じコマンドでも、事前の設計次第で返ってくる指摘の質は変わります。ここでは精度を上げるための3つの打ち手を、自社に合わせて調整する前提で整理します。

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

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

ここで書くべき内容は、企業様によって最適な形が異なります。金融系のように規制要件が明確な領域と、社内向けツールを開発しているチームとでは、優先すべき観点が違うためです。汎用的なOWASPの項目をコピーするだけでなく、自社が過去にヒヤリとしたパターンを書き足していくと、実務に効くドキュメントになります。

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

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

重要な範囲のレビューには推論力の高いモデルを割り当てるのも有効です。2026年10月時点のClaude Codeでは既定のモデルがOpus 5.5で、/modelで切り替えられます。すべてを最上位モデルで回すのではなく、リスクの高い箇所に厚く配分するという考え方です。モデルの使い分けは/model opusplanによるハイブリッド運用で解説しています。

検出結果をチームのナレッジに還流させる

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

これはHubSpotで失注理由を分類・蓄積し、製品開発やマーケティング施策に還流させる考え方と同じ構造です。個別の指摘を「その場で直して終わり」にせず、カテゴリごとに分類して傾向を見ると、チームが繰り返し踏んでいるパターンが浮かび上がります。頻出カテゴリが分かれば、CLAUDE.mdへの追記なのか、ライブラリの選定見直しなのか、教育なのか、打つべき手が決まります。

セキュリティレビューを仕組みとして定着させる

コマンドの導入そのものはすぐに終わります。難しいのは、それをチームの標準運用として定着させることです。ここでは導入の進め方と、避けたい失敗パターンを整理します。

スモールスタートで進める3ステップ

目安期間は2026年10月時点の一般的な進め方であり、チームの状況で調整してください。

最初から全PRでのブロッキング運用を目指すと、偽陽性への対応や例外申請のフローまで設計する必要が出てきて、導入が止まりがちです。段階を分けて進めることをおすすめします。

第2段階を飛ばさないことが重要です。ここで蓄積したCLAUDE.mdの記述が、第3段階での誤検出によるブロックを減らします。

属人化を防ぐための決めごと

仕組みとして回すには、コマンドを入れるだけでなく運用ルールを言語化しておく必要があります。最低限、次の3点はチームで合意しておくとよいかと思います。

• リスクレベルごとの対応方針 — Critical・Highは修正必須、Mediumはissue化、Lowは記録のみ、といった線引きを決めます
• 例外を認める手順 — 修正しないと判断した場合に、誰が承認し、どこに記録を残すかを決めます
• CLAUDE.md更新の担当と頻度 — 検出傾向を踏まえた更新を、誰がいつ行うかを決めます

これらが決まっていると、レビュー担当者が不在でも他のメンバーが同じ判断基準で進められます。人が変わっても同じ品質で回ることが、仕組み化のゴールです。

開発フロー全体の中での位置づけ

/security-reviewは、開発フローの中の一点で完結する機能ではありません。実装からリリースまでの流れの中に置くと、次のような位置関係になります。

実装（Claude Codeによるコード生成）→ /diffで変更把握 → /security-reviewでリスク評価 → 修正 → コミット・PR作成 → CIでの自動レビューと静的解析 → 人によるコードレビュー → マージ → 定期監査で累積分を横断確認、という一気通貫の流れです。

この全体像の中で、/security-reviewは「実装直後」と「PR時」の2箇所に配置されます。前後の工程とセットで設計することで、どこが手薄なのかも見えてきます。チーム全体での運用設計は「Claude Codeでチーム開発を効率化する方法」も参考になります。

よくある質問

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

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

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

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

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

/security-review自体はブランチの差分（変更された部分）を対象にするコマンドで、変更のない既存コード全体を審査する用途ではありません。コードベース全体を見たい場合は、/security-reviewではなく通常のプロンプトで、ディレクトリやモジュール単位に分割してレビューを依頼する形になります。ただしコンテキストウィンドウの制約があるため、一度にレビューできるコード量には限りがあります。特に認証・認可、決済処理、個人情報を扱うモジュールなど、セキュリティ上重要なコンポーネントを優先的にレビューする運用がおすすめです。

Q4. セキュリティに詳しいメンバーがいないチームでも導入できますか？

導入自体はコマンド1つで可能です。指摘には理由の解説が付くため、レビューを受けながら観点を学べる側面もあります。ただし、検出結果のトリアージや例外判断には最終的に人間の理解が必要になるため、Critical・Highの指摘が出た際に誰が判断するかは事前に決めておいてください。まずは手動実行から始めて、指摘内容をチームで読み合わせるところから進めるとよいかと思います。

Q5. 検出された問題をClaude Codeにそのまま修正させてもよいですか？

修正案の生成までは任せられますが、そのまま自動でコミットまで走らせる運用は避けたほうが安全です。セキュリティ修正は仕様や認証設計に踏み込むことが多く、周辺への影響を人間が確認する必要があります。修正案を受け取り、内容を理解した上で適用するという順序をおすすめします。

まとめ

本記事の要点を整理します。

• 静的解析との使い分けが出発点: /security-reviewはビジネスロジックの脆弱性やコンテキスト依存リスクの検出に強みがあり、既知パターンの高速検出は静的解析ツールに任せる補完関係で設計します
• 3層のレイヤーで配置する: 開発者による手動実行、CIでの自動実行、定期監査という頻度の異なる層に分けて重ねることで、実行漏れを構造的に防げます
• CLAUDE.mdが精度を決める: 自社のセキュリティ基準を明文化しておくことで、汎用的な脆弱性検出から自社ポリシーに沿ったレビューへと質が変わります
• AIと人間の役割を分ける: 指摘の生成と理由の言語化はAI、トリアージと最終的な修正判断は人間という線引きを、チームのルールとして明記します
• 多層防御の一層として位置づける: /security-reviewを唯一のチェックとせず、静的解析・人によるコードレビュー・動的な検証と組み合わせた設計が前提になります

最初の一歩としては、まずご自身の直近のPRに対して/security-reviewを1回実行するところから始めてみてください。次の3ステップで進められます。

1. 手元で1回実行する — 直近の変更をステージした状態で/security-reviewを実行し、どんな指摘が返るかを確認します
2. CLAUDE.mdにセキュリティ基準を3〜5行書く — 自社で最低限守りたいルールを書き足し、もう一度実行して指摘の変化を見ます
3. チームのルールを決める — リスクレベルごとの対応方針を合意し、CIでの警告出力から段階的に広げます

なお、ここで紹介した設計はあくまで一般的な型です。開発体制やプロダクトの性質によって最適な運用は異なりますので、自社の状況に合わせて調整いただければと思います。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

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