セキュリティの検査
コードのセキュリティを調べる3つの手段、security-guidance プラグイン・Claude Security プラグイン・/security-review の使い方と使い分けをまとめます。
Claude Code には、コードのセキュリティを調べる方法が層になって用意されています。Claude がコードを書く最中に見る security-guidance プラグイン、リポジトリや差分を複数のエージェントで走査して修正パッチまで作る Claude Security プラグイン、現在のブランチの変更を1回調べる /security-review です。PR の自動レビューはコードレビューと ultrareviewにあります。
- security-guidance:インストールすると自動で動き、Claude が書いたコードの脆弱性を、同じセッションの中で直させます
- Claude Security:
/claude-securityで、リポジトリ全体か変更だけを走査し、独立に検証した指摘と、自分で適用するパッチを出します /security-review:現在のブランチと origin のデフォルトブランチの差分を、インジェクション・認証の問題・データの露出などの観点で調べます- どれも、静的解析や依存関係のスキャナー、人のレビューの代わりではなく、多層防御の1つの層です
- 3つとも、読むのは手元のソースコードで、動いているサイトやデプロイ済みのサービスではありません
3つの手段の使い分け#
| 段階 | 手段 | 調べるもの |
|---|---|---|
| セッション中 | security-guidance プラグイン | Claude が書くコードの一般的な脆弱性を、同じセッションの中で直す |
| 必要なとき・1回の確認 | /security-review |
現在のブランチの変更を、頼んだときに1回セキュリティの観点で調べる |
| 必要なとき・深い走査 | Claude Security プラグイン | リポジトリや差分の複数エージェントによる走査。独立に検証した指摘とパッチ |
| pull request | Code Review(Team・Enterprise プラン) | コードベース全体を踏まえた、複数エージェントによる正しさとセキュリティのレビュー |
| マネージド | Claude Security の製品(Enterprise プラン) | 接続したリポジトリを監視するホスト型の走査 |
| CI | 既存の静的解析と依存関係のスキャナー | 言語ごとの規則・サプライチェーンの確認・方針の強制。プラグインが狙わないもの |
すでにあるコードのセキュリティ問題を探すときは、セッションで Claude に特定のファイルやディレクトリの脆弱性を見るよう頼むか、Claude Security プラグインでリポジトリ全体を深く走査します。/security-review が見るのは、現在のブランチの変更だけです。
/security-review#
/security-review は、現在のブランチの変更を、セキュリティの脆弱性について分析するコマンドです。ブランチと origin のデフォルトブランチの差分を見て、インジェクション・認証の問題・データの露出などのリスクを洗い出します。
originリモートが要ります。ambiguous argumentのエラーで失敗したときは、エラー一覧を見てください- コマンドの一覧はスラッシュコマンド一覧にあります
security-guidance プラグイン#
security-guidance プラグインは、Claude が自分のコードの変更を、作業しながら一般的な脆弱性について見直し、見つけたものを同じセッションの中で直すようにします。インジェクション・安全でないデシリアライズ・安全でない DOM API などを、コードが pull request に届く前に捕まえ、下流の人のレビューに回るセキュリティの確認を減らします。インストールすれば自動で動き、呼び出すものも覚えるコマンドもありません。PR に対して動く Code Review の、セッション内の相棒で、このプラグインが PR に届くものを減らし、Code Review が届いたものを捕まえます。
必要なもの#
PATHに Python 3.7 以降。エージェント型のコミットレビューには Python 3.10 以降が要り、Claude Code が Amazon Bedrock や Google Cloud の Agent Platform のようなサードパーティのプロバイダーを使うときは、モデルを使うレビューのすべてにも要る。プラグインは、バージョン付きのpython3.13からpython3.10を優先し、次にpython3・python・py -3にフォールバックする- 作業するディレクトリの git リポジトリ。ターン終了時とコミットのレビューは git の状態に対して差分を取り、リポジトリの外では黙って飛ばす。編集ごとのパターンの確認は、どこでも動く
初回の実行で、プラグインは ~/.claude/security/ の下に仮想環境を作り、Claude Agent SDK をそこへ入れます。pip とネットワークが要ります。インストールに失敗する、または使える Python が3.10より古いと、ファーストパーティ認証でのコミットレビューは、エージェント型でなく1回だけのレビューにフォールバックします。Amazon Bedrock や Google Cloud の Agent Platform のようなサードパーティのプロバイダーでは、モデルを使うレビューが SDK 自体を必要とするので、飛ばされます。古い Python が原因のときは、プラグインが1回だけ通知を出します。
インストールする#
VS Code 拡張かデスクトップアプリでは、プラグインを使うにあるプラグインのインストールの手順で入れます。端末では、claude で Claude Code を起動し、そのプロンプトで次を入力して、公式の Anthropic マーケットプレイスからインストールします。
/plugin install security-guidance@claude-plugins-official
端末の CLI では、/plugin が対話のパネルを開きます。/plugin がこの環境では使えないと Claude が答えるときは、別の方法でインストールします。
- Claude のデスクトップアプリ(ローカルか SSH のセッション):プロンプトの横の「+」ボタンから「Plugins」、「Add plugin」でプラグインブラウザを開く
- VS Code 拡張:「Manage plugins」ダイアログからインストールする
- クラウドセッション:ユーザー設定やリポジトリの
.claude/settings.jsonのプラグインを読み込まない。組織が管理設定で配るプラグインは組織への導入と管理設定を参照
端末でのインストールはスコープを尋ねます。ユーザースコープを選ぶと、プラグインがユーザー設定に書かれ、このマシンで新しく始めるローカルのセッションのすべてで読み込まれます。インストールに失敗したら、Claude Code が出すメッセージに合わせて対処します。
Marketplace "claude-plugins-official" not found:/plugin marketplace add anthropics/claude-plugins-officialでマーケットプレイスを加えて、インストールをやり直す- マーケットプレイスにプラグインが見つからない:プラグイン名を確かめる
インストールの要約を確認し、Run /reload-plugins to activate. と出たら、再起動せずに現在のセッションで有効にする方法を、プラグインのリファレンスで見てください。プラグインの扱いはプラグインを使うにあります。
チームがリポジトリで始めるローカルのセッションでプラグインを有効にするには、プロジェクトのコミット済みの設定に宣言します。
{
"enabledPlugins": {
"security-guidance@claude-plugins-official": true
}
}
管理者は、管理設定で enabledPlugins を設定して、組織全体で有効にできます。
何を調べるか#
プラグインは、Claude の作業を、深さの違う3つの場面で見ます。
| 場面 | 内容 |
|---|---|
| ファイルの編集のたび | 危険な呼び出しの高速なパターン一致。モデルは呼ばない |
| 各ターンの終わり | そのターンが変えたすべてへの、バックグラウンドのモデルによるレビュー |
| Claude が行うコミットや push のたび | 周辺のコードを読む、より深いエージェント型のレビュー |
それぞれの層は、自分の規則を足して広げられます。組み込みのチェックを1つずつ外すことはできませんが、各層を独立に無効にできます。
ファイルの編集のたび#
Claude がファイルに書くと、プラグインは新しい内容を、既知の危険なパターンについて走査します。モデルを呼ばないパターン一致なので、使用コストはかかりません。パターンのカテゴリの例は次のとおりです。
- 動的なコードの実行:
eval(・new Function・os.system・child_process.exec - 安全でないデシリアライズ:
pickle - DOM への注入:
dangerouslySetInnerHTML・.innerHTML =・document.write - ワークフローのファイル:
.github/workflows/の下の編集(リポジトリ単位の権限を与えうる)
確認は編集が反映された後に走り、次の一歩のために警告を Claude のコンテキストへ追記します。各警告は、1セッションにつきパターンとファイルの組ごとに1回だけ出るので、同じファイルでの繰り返しの一致が会話を埋めません。この層には、security-patterns.yaml ファイルで自分のパターンを足せます。
各ターンの終わり#
ターンは、Claude が応答する1回の往復(メッセージを送り、Claude が作業して返信し、ターンが終わる)です。ターンの後、プラグインは、そのターンの間に作業ツリーで変わったすべて(Claude の編集ツール・Bash コマンド・サブエージェントによる変更を含む)の git diff を計算し、セキュリティに絞った別の Claude のレビューへ送ります。レビューはバックグラウンドで動くので、Claude の返信は遅れません。問題が見つかると、Claude が指摘とともに再び促され、フォローアップとして対処します。文字列の一致では捕まらない、次のような問題を拾えます。
- 認可のバイパス
- 安全でない直接オブジェクト参照
- インジェクション
- サーバーサイドリクエストフォージェリ
- 弱い暗号
指摘と Claude の対処の両方が、セッションにそのまま見えます。レビューは1ターンあたり最大30の変更ファイルを対象にし、あなたへ制御を戻すまでに、続けて最大3回までしか起動しません。
Claude が行うコミットや push のたび#
Claude が Bash ツールで git commit か git push を実行すると、プラグインは、変更のより深いエージェント型のレビューを、バックグラウンドで動かします。このレビューは、呼び出し元・サニタイザー・関連ファイルを含む周辺のコードを読んで、報告する前に指摘が本物かを判断します。追加の文脈により、単独では危険に見えるが、コードベースでは安全なパターンでの誤検出が少なくなります。この層が動くのは、Claude が Bash ツールで行うコミットと push だけです。自分のシェルで行うコミット(セッション内の ! のシェルエスケープを含む)はレビューされません。コミットと push のレビューは、1時間あたり20回までに制限されます。コミットレビューの指摘が、ターン終了時のレビューがすでに報告したものと重なるときは、Claude は再び促されないので、問題のないコミットは、この層からは何も見える出力を生みません。
レビューの独立性と限界#
プラグインは、コードを書いたのと同じ Claude に自分を採点させません。編集ごとのチェックは、モデルを使わない決定的な文字列一致です。ターン終了時とコミットのレビューは、新しい文脈とセキュリティに絞ったプロンプトで、別の Claude の呼び出しとして動きます。レビュアーは差分から始め、元のやり方に思い入れがなく、問題を探すことだけを指示されます。どの層も、書き込みやコミットを止めません。指摘は、書いている Claude へ指示として届き、Claude が会話の中で対処します。レビューのモデルが問題を見逃すこともあります。プラグインは、完全なセキュリティ対策ではなく、多層防御の1つの層と考えてください。
自分の規則を足す#
プラグインには2つの拡張点があります。モデルを使うレビュー向けの Markdown の案内ファイルと、編集ごとの文字列一致向けの YAML か JSON のパターンのファイルです。どちらも追加のみで、これらのファイルで組み込みのチェックを無効にすることはできません。
モデルを使うレビュー向けの案内#
プロジェクトに .claude/claude-security-guidance.md を作り、脅威モデルとレビューのチェックリストを普通の言葉で書きます。モデルを使うレビューは、組み込みの脆弱性のチェックリストに加えて、追加の文脈としてこれを読み込みます。次の例は、ロールで制限した管理者のルートと顧客データのログの方針を持つ Web サービス向けです。
# Security guidance for this repo
- Do not log `customer_id` or `account_number` at INFO level or above.
- All routes under `/admin` must call `require_role("admin")` before any database read.
- Use `crypto.timingSafeEqual` for token comparison instead of `===`.
これらの規則は、レビュアーへの案内で、決定的な防護柵ではありません。プラグインは違反を、Claude が直す指摘として示しますが、書き込みは止めず、すべての違反を捕まえる保証もありません。案内は追加のみで、ある種類の脆弱性を無視せよという規則は、それらの指摘を抑えません。強制が要るなら、プラグインを、編集を止めるフックや CI のチェックと組み合わせます(フックの使い方を参照)。
編集ごとのパターンを足す#
.claude/security-patterns.yaml を作ると、編集ごとのパターンの確認へ、正規表現や部分文字列の規則を足せます。組み込みのパターンと並んで、決定的な文字列一致として動きます。
patterns:
- rule_name: internal_api_key
substrings: ["sk_live_", "AKIA"]
reminder: "Hardcoded API key prefix. Load credentials from the secret manager."
- rule_name: tenant_unfiltered_query
regex: "\\.objects\\.all\\(\\)"
paths: ["**/src/tenants/**"]
reminder: "Multi-tenant code must filter by org_id."
| フィールド | 型 | 説明 |
|---|---|---|
rule_name |
string | 警告に出す識別子 |
reminder |
string | Claude のコンテキストへ追記する警告の文面。1 KB まで |
regex |
string | 編集した内容に照合する Python の正規表現 |
substrings |
list | 文字どおりの部分文字列。これか regex のどちらかを書く |
paths |
list | 省略可。glob のパターン。一致するファイルにだけ規則が適用される。glob は完全なファイルパスに照合されるので、プロジェクト相対のパターンには **/ を前置する |
exclude_paths |
list | 省略可。飛ばす glob のパターン。照合は paths と同じ |
プラグインは、同じスキーマで .claude/security-patterns.yml と .claude/security-patterns.json も読みます。JSON はどの Python でも動きます。YAML の形には、PyYAML を import できる必要があり、プラグインはそれを入れません。プラグインは最大50個のカスタム規則を読み込み、壊滅的なバックトラッキングを起こしやすそうな正規表現は飛ばします。
規則ファイルを探す場所#
プラグインは、claude-security-guidance.md と security-patterns.yaml を、プラグインをどう有効にしたかとは関係なく、同じ場所で探します。
| スコープ | パス | 補足 |
|---|---|---|
| ユーザー | ~/.claude/claude-security-guidance.md |
このマシンのすべてのプロジェクトに適用される |
| プロジェクト | .claude/claude-security-guidance.md |
リポジトリにコミットされる |
| プロジェクトのローカル | .claude/claude-security-guidance.local.md |
個人用の上書き向け。.gitignore に加える |
プラグインは、存在するすべての場所を読み込んで連結し、案内ファイルは合計8 KB までです。管理者は、デバイス管理でユーザースコープのファイルを ~/.claude/ へ配って、組織全体の規則を配布できます。security-patterns.yaml にも同じパスが適用されます。
使用コスト#
編集ごとのパターンの確認は、モデルを呼ばず、コストもかかりません。ターン終了時とコミットのレビューは、それぞれ追加のモデル使用量を使い、ほかの Claude のリクエストと同じく使用量に数えられます。コミットレビューはエージェント型で、コミットごとに複数のモデルのターンがかかることがあります。ファイルを変えるターンごとに1回のレビュー呼び出しと、コミットごとに1回のより深いレビューが目安で、どちらも上のように上限があります。モデルを使う2つのレビューは、既定で Claude Opus 4.7 を使います。ターン終了時のレビューのモデルは SECURITY_REVIEW_MODEL、コミットレビューのモデルは SG_AGENTIC_MODEL で選び直せます。プラグインはすべてのプランで使えます。コストの全体像はコストを抑えるにあります。
無効にする・アンインストールする#
個々の層だけを切って残りを保つには、対応する環境変数を設定します。
| 変数 | 効果 |
|---|---|
ENABLE_PATTERN_RULES=0 |
編集ごとのパターンの確認を無効にする |
ENABLE_STOP_REVIEW=0 |
ターン終了時の diff レビューを無効にする |
ENABLE_COMMIT_REVIEW=0 |
コミットと push のレビューを無効にする |
ENABLE_CODE_SECURITY_REVIEW=0 |
モデルを使うレビューをすべて一度に無効にする |
SECURITY_GUIDANCE_DISABLE=1 |
アンインストールせずに、プラグイン全体を無効にする |
ユーザースコープでプラグインを一時停止する、または取り除くには、次を実行します。
/plugin disable security-guidance@claude-plugins-official
/plugin uninstall security-guidance@claude-plugins-official
プラグインがプロジェクトの .claude/settings.json で有効になっていた場合、/plugin からアンインストールすると、コミット済みのファイルを編集せず、.claude/settings.local.json に上書きが書かれるので、あなたにはプラグインが無効のまま、チームメイトには影響しません。同じダイアログは、共有の .claude/settings.json から外して、全員のプラグインをアンインストールする選択肢も出します。管理設定で有効にされたプラグインは、管理者だけが無効にできます。
Claude Code とのつながり#
プラグインは、Claude のループの特定の時点で自分のコードを動かす仕組みである、フックだけで作られています。次を登録します。
| フックイベント | 目的 |
|---|---|
SessionStart |
プラグインの Python 環境を用意する |
UserPromptSubmit |
ターン終了時のレビューが差分を取る基準になる、作業ツリーの基準を取る |
Edit・Write・NotebookEdit への PostToolUse |
編集ごとのパターン一致 |
Stop |
ターン終了時の diff レビュー。バックグラウンドで動く |
git commit と git push に絞った Bash への PostToolUse |
コミットと push のレビュー。バックグラウンドで動く |
自分でフックを作るなら、プラグインのソースは、フックから別のモデル呼び出しを動かして結果をセッションへ返す、動く例になります。
うまく動かないとき(security-guidance)#
プラグインは、実行時の診断を ~/.claude/security/log.txt へ書きます。レビューが出ないときは、まずそこを見ます。レビューの層が、会話にメッセージなしで飛ばされる、よくある理由は次のとおりです。
- ディレクトリが git リポジトリでない:ターン終了時とコミットのレビューは git の状態が要り、リポジトリの外では飛ばされる
- セッションに Anthropic の認証もサードパーティのプロバイダーの設定もない:モデルを使うレビューは飛ばされ、編集ごとのパターンの確認だけが動く
security-patterns.yamlはあるが PyYAML を import できない:ファイルは無視される。代わりにsecurity-patterns.jsonを使う
Claude Security プラグイン#
Claude Security プラグインは、Claude Code のセッションの中で、コードベースの複数エージェントによる脆弱性の走査を行います。Claude のエージェントのチームが、アーキテクチャを調べ、脅威モデルを作り、脆弱性を探し、レポートを書く前にすべての指摘を独立に見直します。リポジトリ全体、または変更だけ(ブランチの diff・pull request の diff・1つのコミット)を走査し、選んだ指摘を、自分で確認して適用するパッチにできます。
プラグインは、セッションの中でローカルに動き、Claude Code で使えるどのモデルでも使え、走査のたびに使用量に数えられます。リポジトリを監視するマネージドのサービスがほしい、または Claude Mythos で走査したいときは、Enterprise プランで使える Claude Security の製品を見てください。プラグインは、GitLab や Bitbucket にあるリポジトリや、受信の接続を許さないネットワークなど、マネージドの製品が届かないコードに届きます。このプラグインは、Claude Code に最初からあるレビューの道具とも別物です。security-guidance プラグインは Claude がコードを書く最中に見直し、/security-review はブランチを1回調べ、Code Review は pull request をレビューします。
必要なもの#
- 有料のプラン、Anthropic API へのアクセス、またはサードパーティのプロバイダー:走査がエージェントをまとめるのに使うワークフローのため。Pro では、
/configの「Dynamic workflows」の行でオンにする PATHにpython3として Python 3.9 以降。python3 --versionで確かめる。プラグインの道具は Python の標準ライブラリだけを使うので、何もインストールしない- Linux・macOS・Windows
- 変更の走査とパッチ作成のための Git。これらの作業はほかのバージョン管理に対応しない。全体の走査は、バージョン管理の有無を問わず、どのディレクトリでも動く
モデルとプロバイダー#
走査は、Claude Code のセッションの中で動きます。プラグイン自身はモデルの呼び出しをしないので、別の API キーやプロバイダーの設定は要りません。
- モデル:脆弱性を探す、指摘を検証する、パッチを書いて見直すエージェントは、セッションのモデルで動く。変えるには、走査を始める前にセッションで
/modelを実行する。リポジトリの把握など一部の補助の段階は、代わりにsonnetのエイリアスを使う - プロバイダー:走査は、有料のプラン、Anthropic API へのアクセス、または Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry などのサードパーティのプロバイダーで動く
サードパーティのプロバイダーでは、sonnet のエイリアスが Anthropic API とは別のバージョンに解決されることがあります。アカウントがそのバージョンを使えないなら、ANTHROPIC_DEFAULT_SONNET_MODEL を含めて、モデルのバージョンを固定します。モデルのエイリアスや固定はモデル・effort・fast modeを参照してください。自動のモデルのフォールバックは、モデルの安全策が検出したリクエストを再実行します。Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry では、デプロイの設定によっては、リクエストが拒否のメッセージで終わることがあります。
インストールする#
Claude Code のセッションで、公式の Anthropic マーケットプレイスからインストールします。
/plugin install claude-security@claude-plugins-official
コマンドはプラグインの詳細を開くので、インストールのスコープを選んでインストールを始めます。インストールに失敗したら、Claude Code が出すメッセージに合わせます。
Marketplace "claude-plugins-official" not foundと出たら、/plugin marketplace add anthropics/claude-plugins-officialでマーケットプレイスを加え、インストールをやり直す- マーケットプレイスにプラグインが見つからないと出たら、プラグイン名の打ち間違いを確かめる
インストールの要約を確かめ、Run /reload-plugins to activate. と出たら、現在のセッションで有効にする方法をプラグインのリファレンスで見ます。プラグインを取り除くには、/plugin のメニューからアンインストールするか、端末で claude plugin uninstall claude-security を実行します。
走査してコードを直す#
プラグインは /claude-security コマンドを1つ加えます。コードベースの走査・変更の走査・パッチの提案の3つの作業のメニューが開きます。基本の流れは、全体の走査を行い、その指摘をパッチにします。
/claude-securityを実行し、「Scan codebase」を選ぶ- 何を走査するかを選ぶ:プラグインはまずリポジトリを読み、リポジトリ全体か絞った領域かを、選択肢ごとのファイル数と相対的なコストとともに示す。リポジトリ全体を選ぶか、「I don't know」と答えると、リポジトリの大きさに合う妥当な既定をプラグインが選ぶ
- 実行を確認する:走査には時間がかかることがあり、かなりの数のトークンを使うことがあり、完了するまで Claude Code を開いたままにする必要がある。確認するまで何も走らない
- レポートを読む:走査の間、各段階が始まるたびに報告され、詳細は
/workflowsで見られる。結果は、リポジトリのタイムスタンプ付きのディレクトリに書かれる - 指摘をパッチにする:もう一度
/claude-securityを実行して「Suggest patches」を選び、対処する指摘を選ぶ。見直されたパッチは、レポートのpatches/フォルダに書かれる - 受け入れるパッチを適用する:各パッチを、シェルから
git applyで、それぞれ別の pull request で適用する。パッチは自動では適用されない
メニューから始める必要はありません。作業は、コマンドの引数(/claude-security scan my branch)や、普通の言葉(「scan commit abc1234」)で直接頼めます。プラグインは、走査のエージェントが各段階で権限プロンプトなしに進める auto mode でいちばんよく動きます(権限モードを参照)。
変更だけを走査する#
ブランチに、ベースにないコミットがあると、/claude-security のメニューが、その diff だけの走査を提案するので、マージ前にブランチを確かめられます。自分の開いている pull request の1つや、「scan commit abc1234」のように頼んだ1つのコミットも走査できます。走査されるのはコミット済みの変更だけです。作業中の編集は、先にコミットかスタッシュするか、作業ツリーを読む全体の走査を行います。変更の走査には git リポジトリが要りますが、バージョン管理されていないディレクトリの全体の走査は動きます。自分の開いている pull request を探すのが、ネットワークへ出る唯一の段階で、セッションが GitHub CLI を動かす権限をすでに持ち、gh がサインインしているときだけ提案されます。
大きなリポジトリの範囲を絞る#
大きなリポジトリでは、ツリー全体でなく、1つの領域ずつ走査します。プラグインが示す絞った範囲(API の層や認証のコードなど)の1つを選ぶと、実行は選んだものに合わせた大きさになります。レポートのカバレッジの節が、調べたものと調べなかったものを述べます。別の領域の走査は、いつでも実行できます。
走査の結果を読む#
走査のたびに、結果は、リポジトリのタイムスタンプ付きの CLAUDE-SECURITY-<timestamp>/ ディレクトリに書かれます。
| ファイル | 内容 |
|---|---|
CLAUDE-SECURITY-RESULTS.md |
レポート。各指摘の ID(F1 など)と、影響・攻撃のシナリオ・重大度・確度・推奨 |
CLAUDE-SECURITY-RESULTS.jsonl |
同じ指摘を、1行に1つの JSON オブジェクトで、機械が読める形にしたもの |
CLAUDE-SECURITY-RESULTS.sarif |
同じ指摘を、GitHub のコードスキャンやこの標準を読むほかのツール向けの SARIF 2.1.0 のログにしたもの。走査は指摘を CWE の弱点のカテゴリで分類する |
CLAUDE-SECURITY-REVISION-<commit>.json |
リビジョンの印。どのコミットを、どの effort で走査したか、コミット前の変更が走査したツリーに含まれたか、実行がどれだけ入念に検証されたかを記録し、レポートが常に、述べているコードに結び付く。バージョン管理の外での走査は、コミットの代わりに UNVERSIONED と印を付ける |
走査がチェックアウトに加える変更は、このディレクトリだけで、ディレクトリは自前の .gitignore を持つので、うっかりの git add でレポートがコミットに入りません。監査の履歴としてレポートを履歴に残すには、その .gitignore ファイルを削除して、ほかと同じようにディレクトリをコミットします。指摘は、独立した検証のエージェントが分析した後にだけレポートに現れるので、レポートは短く、読む価値のあるものに保たれます。走査は非決定的で、同じコードの2回の走査が、別の指摘を出すことがあります。走査を定期的に実行し、リビジョンの印で、各レポートを、対象のコードと設定に結び付けます。
指摘を直す#
修正の流れは、/claude-security のメニューから「Suggest patches」を選ぶか、「fix finding F3」のように普通の言葉で頼んで始め、対処するレポートの指摘を選びます。パッチはコミット済みのコードに対して作られ、レポートは、いまのコードを今も述べている必要があります。コードがその後変わった指摘は、注記つきで飛ばされ、プラグインは、古いレポートからパッチを作らず、新しい走査を提案します。各パッチは、リポジトリの作業用のコピーで下書きされるので、自分でパッチを適用するまで、ソースのファイルは手つかずです。
届ける前に、各パッチは、書いたものとは独立したエージェントが見直します。コードにテストがあればプロジェクトのテストを変更に対して動かし、新しく入りうるものがないか、差分を自分の基準で読みます。パッチが書かれるのは、その見直しが、変更が1つの指摘に対処し、新しい脆弱性を入れず、そのほかの挙動を変えないことの3つを保証できるときだけです。3つすべてを保証できないときは、パッチの代わりに理由を述べた短い注記が届きます。
パッチは自動では適用されない#
パッチを適用するかは、常にあなたが決めます。パッチは、レポートの patches/ フォルダへ、指摘ごとに1つの F<n>.patch と、変更を説明する横の注記として書かれます。シェルから適用するか、Claude に適用して pull request を開くよう頼みます。
git apply CLAUDE-SECURITY-<timestamp>/patches/F1.patch
パッチを当てたコードにテストがないときは、パッチの注記がそう書いているので、見直しがテストの実行なしに行われたことが分かります。各パッチは、それぞれ単独でレビューとテストができるよう、別の pull request で適用します。
ほかのセキュリティツールとの関係#
Claude Security プラグインは、多層防御の中の、必要なときに動かす深い走査の層です。既存のスキャナーの代わりではなく、静的解析・依存関係のスキャン・コードレビューと並べて動かします。人間のセキュリティ研究者がするようにコードを推論するので、それらのツールが提供する決定的なチェックを補います。層ごとの比べは、このページの「3つの手段の使い分け」にあります。
うまく動かないとき(Claude Security)#
/claude-securityのメニューが Python の警告つきで開く:プラグインはPATHにpython33.9 以降が要る。python3が全く見つからないとき、メニューは、1つ入れるまで Claude Security が動かないと警告する。PATHの最初のpython3が古いときは、警告が見つけたバージョンを挙げる。Python 3 を入れるか、新しいpython3をPATHの先頭に置いて、新しいセッションを始める- Fable のモデルで走査すると「safeguards flagged this message」の通知が出ることがある:メッセージは動かしているモデルを挙げる。Fable のサイバーセキュリティの安全分類器が一部のリクエストを検出し、Claude Code が自動のモデルのフォールバックで、検出されたリクエストを Opus のモデルで再実行する。これは想定どおりで、リクエストが再実行されれば、走査は成功して完了するはず
関連するページは、コードレビューと ultrareview・フックの使い方・セキュリティとデータの扱いです。
公式ドキュメント(英語)
2026年10月5日時点の内容をもとに、日本語でまとめています。