Claude Code security-reviewでブランチの脆弱性を検知する

security-reviewは、現在のブランチにある変更を、インジェクション・認証不備・データ漏出といったセキュリティ観点で調べるClaude Codeのコマンドです。ブランチとorigin側のデフォルトブランチとの差分を対象にするため、originリモートが無いプロジェクトでは失敗します。本稿では、何を検知するコマンドか、/code-reviewと何が違うか、そしてambiguous argumentエラーが出たときの具体的な直し方を扱います。正確性・簡潔性のレビューを扱う/code-reviewの実行経路はClaude Codeコードレビュー — 4つの実行経路の使い分けで解説しています。

security-reviewとは何を検知するコマンドか

/security-reviewは、現在のブランチにある変更をセキュリティの観点で分析するコマンドです。公式ドキュメントは「ブランチとoriginのデフォルトブランチとの差分をレビューし、インジェクション・認証の問題・データ漏出といったリスクを特定する」と定義しています。対象は差分そのものであり、リポジトリ全体を毎回スキャンするわけではありません。

差分に絞る設計には理由があります。リポジトリ全体を毎回スキャンする方式は、変更していない既存コードのリスクまで拾ってしまい、レビューの焦点がぼやけます。/security-reviewはいま自分が書いた変更だけを対象にするため、指摘のすべてが「このPRで持ち込んだリスク」に絞られます。インジェクションはSQLやコマンド文字列の組み立てに外部入力が紛れ込む形、認証の問題は権限チェックの抜けや認可の順序ミス、データ漏出はログやエラーメッセージに機密情報が混ざる形が典型です。

/security-reviewは/code-reviewや/verifyと違い、公式コマンド一覧でバンドルスキルとして明記されていません。バンドルスキルはClaudeに渡されるプロンプトとして動き、ユーザーが自分のSKILL.mdを書く場合と同じ仕組みで実行されます。/security-reviewはこの枠組みに含まれず、CLIに直接組み込まれた固定ロジックとして動きます。挙動をカスタマイズする余地が無い代わりに、実行のたびに同じ手順でレビューされます。

公式ドキュメントは、出荷前の作業の流れを挙げています。/diffで変更内容を確認し、/code-reviewで正確性のバグと整理の余地を洗い出し、/security-reviewで脆弱性を確認する順です。/security-reviewは単独で使うコマンドというより、この流れの最後に置いて仕上げに使うコマンドです。権限設計やサンドボックス化など、Claude Code自体のセキュリティ設定はClaude Codeセキュリティ・権限ガイドで扱っています。

/code-reviewとの違いを早見表で見る

どちらも差分を対象にしますが、見ている観点とコマンドの性格が異なります。

/security-reviewは脆弱性の検知に絞ったコマンドで、/code-reviewのような効果レベルの指定や--fixによる自動適用はありません。正確性のバグ探しや整理・簡潔性のレビューが必要な場面は/code-reviewの役割です。

originリモートが無いと失敗する — ambiguous argumentエラーの原因

/security-reviewはorigin/HEAD(originリモート上でどのブランチがデフォルトかを記録するローカルの参照)との差分でレビュー対象を組み立てます。この参照が存在しないと、差分を集めるgitコマンドが失敗し、レビューは始まる前に止まります。

Error: Shell command failed for pattern "!`git diff --name-only origin/HEAD...`": [stderr]
fatal: ambiguous argument 'origin/HEAD...': unknown revision or path not in the working tree.

エラーメッセージ中のgitコマンドは実行のたびに変わります。/security-reviewはorigin/HEADに対して複数のgitコマンドを同時に走らせ、最初に失敗したものを報告するため、git logや別のgit diffが表示されることもあります。

origin/HEADの参照は、リモートのデフォルトブランチがリモート側で公開され、かつ自分のfetch設定がそのブランチを含んでいる場合にのみ作成されます。コミットのあるリモートをフルクローンしていれば両方の条件を満たします。一方で次のような状況では参照が作られません。

• シングルブランチクローンやCI環境のチェックアウトで、fetchの範囲がデフォルトブランチを含んでいない
• リモート側のHEADが、誰もpushしていないブランチを指したままになっている
• originリモート自体が存在しない、またはfetchしたことが無い

/security-reviewは、レビュー対象の差分を集めるために事前にいくつかのgitコマンドを実行する「動的コンテキスト注入」という仕組みを使っています。この仕組み自体が失敗すると、ambiguous argumentとは別の2種類のエラーが出ることもあります。1つは、注入するコマンドの権限チェックが許可以外の結果を返したときに出るShell command permission check failed for pattern "..."です。注入されたコマンドは確認ダイアログを出さずに中断するため、allowed-toolsで該当コマンドを事前に許可しておく必要があります。もう1つは、Windows環境でGit Bashが見つからないときに出るSkill <name> requires bash (shell: bash in frontmatter) but Git Bash was not foundです。この場合はGit for Windowsを導入するか、該当スキルの設定を確認します。

エラーを解消する3つの手順

状況に応じて、次の3つのいずれかで解消します。

1. デフォルトブランチが分かっている場合: git remote set-head origin <デフォルトブランチ名>を実行します。ローカルの追跡参照origin/<ブランチ名>が既にあれば、これだけで解決します。無ければgit remote set-branches --add origin <ブランチ名>→git fetch originの順で先にブランチを取得してから、同じコマンドを実行します
2. ブランチ名を指定したくない場合: git fetch originのあとにgit remote set-head origin --autoを実行します。リモートに問い合わせてデフォルトブランチを自動判定します。リモートがデフォルトブランチを広告していない場合(空のリポジトリ、または誰もpushしていないブランチをHEADが指している場合)はCannot determine remote HEADで失敗するため、手順1のように名前を明示します。クローンがそのブランチをfetchしていない場合はNot a valid refで失敗するため、fetch範囲を広げてから再試行します
3. originリモート自体が無い場合: git remote add origin <URL>でリモートを追加してからfetchします。リモートが空(コミットが無い)場合は、先にgit push -u origin HEADで自分のブランチをpushし、そのブランチ名を使って手順1のコマンドを実行します。この場合、origin/HEADはpushしたばかりのブランチを指すため、そのブランチが分岐するまで/security-reviewには差分が無い状態として映ります

いずれの手順でも、参照を作り直したあとに/security-reviewを再実行すれば解消します。エラーの原因はいずれも「origin/HEADという参照が手元に無い」という1点に集約されるため、状況に合わせて上記のいずれかを選べば十分です。

v2.1.70前後の変遷

/security-reviewはここ数回のメジャーな挙動変更が無い、比較的安定したコマンドです。公式changelogで確認できる関連する変更は次の2件です。

v2.1.108の変更は、/security-review自体がバンドルスキル化したという意味ではありません。Claudeがツール呼び出しの一種として/security-reviewのような組み込みコマンドを認識できるようになった、という改善です。バージョン要件は公式コマンド一覧に明記されていませんが、v2.1.70より前から存在していたことは、この不具合修正の内容から確認できます。修正対象がすでに使われていた既存コマンドであることを前提にした記述だからです。

よくあるつまずき

• CI環境やシングルブランチクローンで急に失敗する: fetchの範囲がデフォルトブランチを含んでいないことが原因です。git fetch originでデフォルトブランチを取得してからgit remote set-headを実行します
• origin/HEADはあるはずなのにエラーが出る: リモート側のHEADが、誰もpushしていない古いブランチを指したままになっている可能性があります。git remote set-head origin --autoがCannot determine remote HEADで失敗する場合は、デフォルトブランチを明示的に指定します
• --fixで自動修正できると思い込む: /security-reviewに--fixのような自動適用フラグはありません。検知した内容の修正は自分で行うか、/code-review --fixなど別コマンドに切り出します
• フォークしたばかりのリポジトリで空の差分になる: originが空でpushしたばかりの場合、origin/HEADはそのpush直後のブランチを指すため、分岐が無い間は差分が検知されません

よくある質問

security-reviewはどんな脆弱性を見つけますか

公式ドキュメントは「インジェクション・認証の問題・データ漏出といったリスク」を例示しています。ブランチとoriginのデフォルトブランチとの差分を対象にした分析です。

security-reviewはバンドルスキルですか

いいえ。公式コマンド一覧で/code-reviewや/verifyのような[Skill]表記が付いておらず、CLIに直接組み込まれた固定ロジックとして動きます。disableBundledSkillsのようなバンドルスキル向けの無効化設定は対象外です。

originリモートが無いプロジェクトでは使えませんか

originという名前のリモートが必須です。無い場合はgit remote add origin <URL>でリモートを追加し、fetchまたはpushしてからorigin/HEADの参照を作る必要があります。手順は本稿の「エラーを解消する3つの手順」で解説しています。

security-reviewの指摘をPRに自動でコメントできますか

公式コマンド一覧には、/code-reviewが持つ--commentのようなフラグは/security-reviewの項目に記載がありません。PRへのコメント投稿を自動化したい場合は、/code-review側の機能を使う運用になります。

originのデフォルトブランチ以外と比較できますか

公式コマンド一覧に/security-reviewの引数は記載されていません。常にorigin/HEADが指すデフォルトブランチとの差分が対象になり、/code-reviewのようにブランチ名やPR番号を渡して比較対象を変える機能はありません。別のブランチと比較したい場合は、一時的にそのブランチをoriginのデフォルトに設定し直すか、/code-review側で対象を指定します。

まとめ

security-reviewは、現在のブランチとoriginのデフォルトブランチとの差分を、インジェクション・認証不備・データ漏出などの観点で分析するコマンドです。/code-reviewとは異なりバンドルスキルではなく、効果レベルの指定や--fixもありません。originリモートやorigin/HEAD参照が無いとambiguous argumentエラーで止まるため、git remote set-headやリモートの追加・fetchで参照を整えてから再実行します。出荷前のチェックとして/diff・/code-reviewと組み合わせ、最後の一手として使う運用が実務的です。