/security-review｜Claude Codeのセキュリティレビュー機能

「/security-reviewを使えば、自分のコードは安全になるのだろうか」「脆弱性チェックと聞いて実行してみたが、何も指摘が出なかった——これは『問題なし』という意味なのだろうか」——検索してこのコマンドにたどり着いた人の多くが、こうした期待と不安を同時に抱えています。

結論から言うと、/security-reviewは今のブランチにある差分（diff）だけを、1回だけ確認するコマンドです。公式ドキュメントの説明は「Check the current diff for security vulnerabilities（現在のdiffのセキュリティ脆弱性を確認する）」という一文に尽きます。指摘が0件でも、それは「このコードに脆弱性が存在しない」という証明にはなりません。見ている範囲そのものが限定的だからです。

株式会社Fyveは中小企業のAI業務活用を支援しており、Claude Codeを日常の実務で使っています。この記事では、/security-reviewが何を見て何を見ないのか、Claude Codeが用意しているセキュリティ関連機能全体の中でこのコマンドがどこに位置するのかを、公式ドキュメントに基づいて整理します。非エンジニアの方が「これで安全になった」と思い込まないための境界線を、はっきり書くことを目的にしています。

/security-reviewとは——追加インストール不要のバンドル済みスキル

/security-reviewは、Claude Codeに標準搭載されているバンドル済みスキルの1つです。/code-reviewや/debugと同じ扱いで、.claude/skills/に何かを置く必要はなく、Claude Codeが入っていればそのまま使えます。

公式のコマンド一覧には、次のように記載されています。

• コマンド：/security-review
• Purpose（公式の説明・原文）：Check the current diff for security vulnerabilities
• 分類：Skill（バンドル済みスキル）

ここで確認できるのは「現在のdiff（差分）のセキュリティ脆弱性を確認する」という1行だけです。/code-reviewの公式説明が「correctness bugs and cleanup opportunities（正しさのバグと整理の余地）」まで踏み込んで書かれているのに比べると、/security-reviewの公式説明はかなり簡潔です。具体的にどの脆弱性クラス（インジェクション、認可不備など）を検出対象としているかは、コマンド自体の説明としては明記されていません。また、--fixや対象範囲を指定する引数についても、/code-reviewのような記載は見当たりませんでした。

Claude Codeのセキュリティ機能は5層に分かれている——/security-reviewはその1つに過ぎない

「Claude Codeでセキュリティを見てもらう」と一口に言っても、公式ドキュメントを読むと、性質の異なる5つの層が並んで用意されていることが分かります。/security-reviewはその中の1つの層でしかなく、残り4つを知らずにいると、守備範囲を実際より広く錯覚しやすくなります。

この整理は、Anthropic公式ドキュメントの2つのページ（security-guidanceプラグインの解説ページとClaude Securityプラグインの解説ページ）に、それぞれほぼ同じ内容の対比表として掲載されているものです。両ページとも、/security-reviewを「on demand, single pass（任意のタイミングで、1回だけ）」と位置づけています。

つまり、/security-reviewは「常時見張ってくれる機能」でも「リポジトリ全体を精査する機能」でもなく、自分で呼び出したときだけ、今の差分だけを1回見る、5層の中でいちばん軽い層です。

他の4層は何をしているのか

比較のために、残り4層の中身も公式ドキュメントの記載に沿って簡単に整理しておきます。

• security-guidanceプラグイン：Claudeがファイルを編集するたびに危険なパターン（eval(・os.system・dangerouslySetInnerHTMLなど）を文字列マッチで検知する層、ターンの終わりにその回の差分をセキュリティ専用のレビューにかける層、Claudeがcommit・pushするたびに周辺コードまで読んで検証する層——の3段階を持つ、コーディング中に自動で動く別プラグインです。/plugin install security-guidance@claude-plugins-officialで個別にインストールする必要があり、既定では入っていません
• Claude Securityプラグイン：リポジトリ全体、または特定のブランチ・PR・コミットの差分を対象に、複数のエージェントが分業してアーキテクチャの把握・脅威モデルの構築・脆弱性の探索・独立したレビューまで行います。結果はMarkdown・JSONL・SARIFの3形式で出力され、パッチは自動適用されず、必ず人間がgit applyで選んで当てる設計です。動作にはPython 3.9以上と、有料プランでのDynamic workflowsの有効化が必要です
• Code Review：GitHubのプルリクエストを対象に、複数のエージェントがコードベース全体の文脈込みでレビューし、該当行にインラインコメントを投稿します。Team・Enterpriseプラン限定の機能で、個人利用や小規模チームの多くは対象外です

この並びを見ると、「独立したエージェントによる検証」「リポジトリ全体の把握」「人間が確認してから適用するパッチ」といった、誤検知を減らすための仕組みは、Claude Securityプラグインの説明では明記されている一方、/security-review自体の公式説明にはそうした記載がありません。これが、誇張せずに使うために押さえておきたい、いちばん実務的な違いです。

もう1点、Code Reviewについて公式ドキュメントが明記している注意点も紹介しておきます。「Findings are tagged by severity and don't approve or block your PR（指摘には重要度のタグが付くが、PRを承認したりブロックしたりはしない）」——Team・Enterpriseプランの本格的な多層レビューでさえ、最終判断は人間に委ねる設計になっています。5層の中でいちばん軽い/security-reviewが、それ単体で「安全の判定」を下す機能ではないことは、この設計思想からも読み取れます。

読者特典・無料ダウンロードClaudeのこの5つの設定、今すぐ見直した方がいい無料でダウンロード →↓

/security-reviewが見ていないもの

「見ているもの」より「見ていないもの」を先に押さえておくほうが、実務での事故を防げます。公式ドキュメントの記載から確認できる範囲は次のとおりです。

• リポジトリ全体ではなく、現在のブランチの差分だけ——過去からすでに存在しているコードの脆弱性は、今回変更していない限り対象になりません
• 動いているアプリやデプロイ済みのサービスではなく、手元のソースコードだけ——公式ドキュメントは「the review reads the source code in your checkout, not a running site or deployed service（レビューは手元のチェックアウト内のソースコードを読むのであって、稼働中のサイトやデプロイ済みのサービスを見るのではない）」と明記しています。外部から実際に叩いて挙動を確認する診断（ペネトレーションテストなど）の代わりにはなりません
• 依存パッケージの脆弱性やサプライチェーンのチェックではない——これは前段の表の最下段、CIの静的解析・依存関係スキャナが担当する領域です
• 指摘を自動修正する機能ではない——公式ドキュメントには、/code-reviewにあるような--fixフラグの記載が/security-reviewにはありません。見つかった指摘をコードに反映するかどうかは、その後で自分がClaudeに依頼する別の作業になります
• 結果はどこにも投稿されない——/code-reviewの--commentやCode ReviewのようにPRへコメントを投稿する仕組みは、/security-reviewの説明には出てきません。結果はセッション内のチャットに返ってくるだけです

付け加えると、Claude Securityプラグインの公式ドキュメントは「Scans are nondeterministic: two scans of the same code can surface different findings（スキャンは非決定的で、同じコードを2回スキャンしても異なる指摘が出ることがある）」とはっきり書いています。これはClaude Securityプラグインについての記載であり/security-reviewについて明言されたものではありませんが、AIによるレビュー全般が「1回実行して指摘が0件だった＝その後もずっと安全」を意味しないことを裏付ける材料として押さえておく価値があります。

手元での確認について

今回、手元のClaude Code（v2.1.260・macOS、2026年9月4日確認）でも/security-reviewの実際の挙動を試みましたが、ヘッドレスモード（claude -p）からの呼び出しでは、今回の検証環境の要因により、結果が返らず空の応答になりました。同じ環境・同じ差分に対して/code-reviewや/simplifyなど他のバンドル済みスキルは問題なく動作したため、/security-reviewに固有の何らかの事情がある可能性はありますが、原因は特定できておらず、断定はできません。そのため本記事の内容は、公式ドキュメントの記載を一次情報として構成しています。対話セッションでの実際の挙動を知りたい方は、ご自身の環境で一度実行して確かめることをおすすめします。

なぜ「指摘が出なかった」で安心してはいけないのか

非エンジニアの方がAIによるセキュリティチェックを使うとき、いちばん起きやすい誤解は「ツールを実行した」という行為そのものを、「安全性を確認した」という結果と同一視してしまうことです。/security-reviewに限らず、AIレビュー全般に共通する構造上の限界として、次の3点は覚えておく価値があります。

• 見ていない範囲では、指摘のしようがない——今回変更していない既存コードや、依存パッケージの脆弱性は、そもそもレビューの対象に入っていません。「対象外だから指摘が出ない」のを「安全だから指摘が出ない」と読み違えるのが、いちばん起きやすい事故です
• 1回のレビューには揺らぎがある——Claude Securityプラグインの公式ドキュメントが明言しているとおり、AIによるレビューは同じコードでも実行のたびに異なる指摘が出ることがあります。1回通っただけでは「今後も通り続ける」保証にはなりません
• 報告と修正は別工程——/security-reviewは指摘をチャットで返す機能で、見つけたものを自動でコードに反映するわけではありません。指摘を読んで、実際に直すかどうかを判断するのは自分自身です

これらを踏まえると、/security-reviewは「セキュリティの認定機関」ではなく、「もう一人のレビュアーに、その場で一度だけ目を通してもらう」くらいの位置づけで使うのが実態に近いと言えます。認証情報の扱い方、決済処理、個人情報を含むフォームなど、事故が起きたときの影響が大きい変更については、この記事で整理した他の層（Claude Securityプラグインでの精査や、人間によるレビュー）を必ず別途はさんでください。

実務でどう使うか——「1つの入力」として扱う

ここまでの整理を踏まえると、/security-reviewの実務上の位置づけは次のように考えるのが妥当です。

• 小さな変更をマージする前の、手軽な1回チェックとして使う——コストも手間もかからず、標準搭載なので今すぐ使えます
• 指摘が0件でも「問題なし」と読まない——見ている範囲が今の差分だけであることを踏まえ、「少なくとも今回の変更分では、この1回のチェックで指摘は出なかった」という限定的な事実として受け取ります
• 認証・決済・個人情報を扱う変更では、これ単体で判断を終えない——独立した検証エージェントを持つClaude Securityプラグインでの精査や、人間によるレビューを別途はさむ判断をおすすめします
• Team・Enterpriseプランでない場合、Code Reviewは使えない——個人・小規模チームが手にできるのは、security-guidanceプラグイン・/security-review・Claude Securityプラグインの3つです。予算と手間に応じて組み合わせを考えます

Claude Codeには、この他にも追加インストールなしで使えるバンドル済みスキルが複数あります。全体像は以下にまとめています。

Claude CodeClaude Codeのバンドル済みスキル一覧｜追加インストール不要で使えるもの

まとめ

• /security-reviewは追加インストール不要のバンドル済みスキルで、現在のブランチの差分を1回だけ確認する
• 公式の説明は「Check the current diff for security vulnerabilities」の1行で、検出対象の脆弱性クラスは明記されていない
• Claude Codeのセキュリティ機能は5層あり、/security-reviewはその中で最も軽い「任意のタイミング・1回だけ」の層にあたる
• リポジトリ全体・稼働中のサービス・依存パッケージの脆弱性・自動修正・PRへの投稿は、いずれも対象外
• 指摘が0件でも「安全になった」ことの証明にはならない。認証・決済・個人情報が絡む変更では、他の層や人間のレビューと組み合わせる