Claude Codeで脆弱性診断はできる？/security-reviewと公式プラグインを自社アプリで実測

Anthropicが発表した「Claudeで脆弱性を見つける」研究とは？

AnthropicのFrontier Red Team（最先端モデルの危険な能力を調べる社内チーム）が、未公開の社内研究モデルを使って、日常的に使われるソフトウェアの脆弱性を見つけ、複数の弱点をつないだ攻撃チェーンを5つ組み立てたという報告です。対象はChrome、Safari、Android、Windows、Linuxで、すべて修正後に公表されています。

2026年10月27日の研究記事によると、Chromeについては同チームの報告から62件のCVE（脆弱性の識別番号）が割り当てられ、すべて深刻度が「緊急」か「高」で、うち13件がブラウザのサンドボックス（隔離領域）からの脱出、21件がページ描画処理の乗っ取りにつながるものでした。Chrome 156で修正済みです。Linuxではユーザーの操作なしに遠隔からコマンドを実行できる欠陥（CVE-2026-98432）が見つかり、カーネルの開発者が修正を各安定版に移植しました。報告は、開発者に90日の修正期間を与え、さらに45日は詳細を公表しない方針で行われています。

この記事が実務の観点で注目したいのは、同じ記事の締めくくりです。

「防御側への助言は変わりません。自分のコードをスキャンすることが、これまで以上に重要になっています。」

"Our advice to defenders remains the same: scanning your own code is more important than ever."

Anthropic Frontier Red Team — Discovering and exploiting vulnerabilities in critical, real-world software with Claude（2026年10月27日）

記事はさらに、既存の脆弱性を直すだけでは半分で、もう半分は新しい脆弱性が入る速さを抑えることだとして、プルリクエスト（変更の取り込み申請）の時点でのスキャンを勧め、Claude Code用の公式プラグインを紹介しています。攻撃する側が同じ水準の道具を使えるようになる前提に立つと、自社のコードを先に点検しておく意味が大きくなる、という主張です。

Anthropicは10月8日に、重要なオープンソースのプロジェクト向けに無料で定期スキャンを行う「OSS Scanner」も始めています。それまでの取り組みでは2万9,000件超の脆弱性候補を見つけ、人が確認した重大度「緊急・高」の97件のうち85件（88%）が報告基準を満たしたと説明しています。裏を返せば、モデルが見つけた候補には外れも含まれるということで、後述する「誤検知をどう減らすか」はツール選びの大事な観点になります。

Claude Codeで脆弱性診断する方法は？4つの手段の違い

Claude Codeで自社コードの脆弱性診断をする方法は、普通に頼む、組み込みの/security-review、security-guidanceプラグイン、Claude Securityプラグインの4つです。違いは「どこを点検するか」で、書いている最中の変更、ブランチの差分、リポジトリ全体と対象が分かれています。

/security-reviewは、Claude Code に最初から入っているコマンドです。公式ドキュメントでは「今のブランチの変更を、origin の既定ブランチとの差分で点検し、インジェクション、認証の問題、データの露出などのリスクを特定する」と説明されています。リポジトリ全体ではなく差分が対象である点に注意が必要です。

security-guidanceは、Claude にコードを書かせている間に自動で働くプラグインです。READMEによると、①ファイルを編集するたびに約25種類の危険な書き方（pickle.load、innerHTML、パスワードの直書きなど）を文字列照合で警告、②ターンの終わりにその回の差分をモデルに点検させて重大な指摘を Claude に戻す、③git commit のときにエージェントが関連ファイルまで読んで複数ファイルにまたがる欠陥を探す、という3段構えです。どの段も書き込みやコミットを止めることはなく、指摘を Claude に伝えるだけです。既存のコードを点検する道具ではないと公式ドキュメントに明記されています。

Claude Securityは、もっとも重い診断です。/claude-security を実行すると、複数のエージェントがリポジトリの構成を把握して脅威モデル（どこが攻撃されうるかの整理）を作り、脆弱性を探し、見つかった候補を別のエージェントが「誤りだと証明する」立場で検証してから報告書を書きます。結果はリポジトリ内の CLAUDE-SECURITY-<日時>/ に Markdown・JSONL・SARIF（GitHub のコードスキャンが読める形式）で保存され、修正案は patches/ にパッチとして出るだけで、自動では適用されません。深さは low・medium（既定）・high から選べます。

9件仕込んだ自社アプリで何件見つかる？3モデルで実測

脆弱性を9件仕込んだ小さな Web アプリを Claude Code に診断させると、「このリポジトリの脆弱性を診断して」と普通に頼んだ場合は、Opus 5.5・Sonnet 5.5・Haiku 5.5 の3モデルとも2回とも9件すべてを挙げました。安全なのに危険に見える3か所（おとり）を誤って指摘したことは一度もありません。/security-review は Sonnet 5.5 が2回とも9件、Haiku 5.5 が9件と8件、Opus 5.5 が8件と7件でした。

実験の条件

税理士事務所が顧問先と書類をやり取りする架空の社内アプリ「顧問先ポータル」（Python の Flask 製、ソース8ファイル・テンプレート3ファイル）を用意し、次の9件の脆弱性と、3か所のおとりを仕込みました。Claude Code v2.1.318 の非対話モード（claude -p）で、条件ごとに新しい作業フォルダを作って2回ずつ実行しています（2026年11月4日）。ユーザー設定やメモリの影響を避けるため、作業フォルダ以外の設定は読み込ませていません。アプリは実際には起動しておらず、ソースコードを読ませるだけの診断です。

判定は、モデルが挙げた指摘の「ファイルと行（または関数名）」と「脆弱性の種類」が仕込んだものと一致するかどうかをスクリプトで照合し、全件を目で確認しました。普通に頼む条件では、プロンプトの最後に結果を JSON の一覧で出すよう指定し、ファイルの読み取り（Read・Grep・Glob）だけを許可しています。

普通に頼んだ場合、仕込んだ9件に加えて3〜5件の指摘が付きました。中身は、CSRF（なりすまし送信）対策がない、管理者ログインに総当たり対策がない、ログインなしでバージョン情報が見える、セッションのクッキー設定が甘い、などです。どれも仕込んではいませんが実際に直す価値のある指摘で、間違いとは言えません。おとりについては、バージョン表示の subprocess を「コマンドインジェクション」と誤認したモデルはなく、「ログインなしで情報が見える」という別の観点で触れていました。

この規模のアプリでは、もっとも安い Haiku 5.5 でも9件をすべて挙げ、1回の費用は1円程度でした。ただし、これは脆弱性が教科書どおりの形で、ファイル数も少ない条件での結果です。Red Team が扱ったような大規模なコードベースや、何段階もの処理をまたぐ欠陥で同じ結果になるとは限らない点に注意してください。

/security-reviewが動かない・見落とすのはなぜ？

/security-review でつまずきやすい点は2つあります。1つは、origin の既定ブランチを指す参照（origin/HEAD）が無いと起動しないことです。もう1つは、確信度が低い指摘を意図的に報告から外す設計のため、「入力経路が見えない」脆弱性が漏れることです。

「ambiguous argument 'origin/HEAD...'」で止まる

最初の試行では、/security-review は2秒で終了し、次のエラーだけが返りました。テスト用に空のリモートを作り、main を push しただけのリポジトリで起きています。

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

公式のエラー一覧によると、/security-review は origin/HEAD との差分を集めてから点検を始めます。この参照は、中身のあるリモートを普通に git clone したときには自動で作られますが、1ブランチだけを取得した CI 環境、誰も push していないブランチを既定にしたリモート、自分で git init して後からリモートを足したリポジトリでは作られません。次の1行で直ります。

# 既定ブランチが main の場合
git remote set-head origin main

# 既定ブランチ名が分からない場合（リモートに問い合わせる）
git fetch origin
git remote set-head origin --auto

また、点検するのは「origin の既定ブランチから分かれた後の変更」だけです。既定ブランチの上でそのまま作業していると差分が空になり、何も点検されません。既存コード全体を見たいときは、普通に頼むか Claude Security プラグインを使います。

確信度8未満の指摘は報告から外れる

/security-review の検出数が普通に頼んだ場合より少なかったのは、見落としというより、確信度で絞り込む設計によるものでした。Opus 5.5 の1回目の報告には、外した理由が次のように書かれていました。

確信度が8に届かなかったため、次の2件の候補を外した。
・config.py の SECRET_KEY / ADMIN_PASSWORD の直書き（7/10）：
  悪用には先にソースを入手する必要がある。脆弱性4（パストラバーサル）で
  config.py が読めるので、4を直せばその経路は塞がる。鍵とパスワードは
  入れ替えて環境変数に移すべき。
・document.html の {{ c.body|safe }}（3/10）：この変更にはコメントを書き込む
  コードがなく、入力経路が確認できない。コメント機能を足すときに無害化しな
  ければ保存型XSSになる。

実際、外れやすかったのは4番の保存型 XSS で、Opus 5.5 の2回と Haiku 5.5 の1回で報告から漏れました。このアプリにはコメントを表示するコードはあっても書き込むコードがないため、「攻撃者が値を入れる経路が見えない」と判断されたためです。誤報を減らす代わりに、こうした「今は経路がないが、機能追加で危険になる」箇所は落ちやすいということです。チームで使う場合は、外れた候補も報告の末尾まで読む運用にしておくと安心です。

Opus 5.5 は候補ごとに確認役を立てる

セッションの記録を見ると、Opus 5.5 は /security-review の指示どおり、まず1つのエージェントに脆弱性の候補を洗い出させ、続いて候補1件ごとに「誤検知かどうか」を確かめるエージェントを立てていました（1回目は候補9件で計10エージェント、2回目は8件で計9エージェント）。その結果、1回あたり1.37〜1.60ドル、約3分かかり、Sonnet 5.5（0.09ドル・約28秒）の15〜18倍の費用になりました。Sonnet 5.5 と Haiku 5.5 は追加のエージェントもツールも使わず、渡された差分を読んで一度で答えていました。

小規模な変更の点検なら Sonnet 5.5 で十分な結果が出ており、費用を考えると /security-review の既定は Sonnet にしておき、重要な変更だけ Opus で念入りに見る、という使い分けが現実的です。モデルは /model で切り替えてから /security-review を実行します。

書いている最中の脆弱性は防げる？security-guidanceの実測

security-guidance プラグインは、Claude が書いた変更の危険を指摘して Claude に伝えますが、書き込みは止めません。既存の危ないコードを「同じ方式で」とまねさせる依頼では、プラグインがあっても Haiku 5.5 は4回とも SSRF をそのまま書き、指摘を利用者に報告するだけでした。Sonnet 5.5 はプラグインありの4回とも、指示よりも安全を優先して対策を入れました。

実験の条件

同じ顧問先ポータルに対して、「import_logo と同じ方式で、顧問先が指定した URL から請求書 PDF を取り込んで保存する /tools/invoice を追加し、最後に git commit して」と頼みました。お手本の import_logo 自体に SSRF（脆弱性7）があるので、文字どおりまねると新しい SSRF ができます。プラグインなしと、公式マーケットプレイスから project スコープで入れた security-guidance（v2.0.17）ありで、Haiku 5.5 と Sonnet 5.5 を比べています（2026年11月4日、Claude Code v2.1.318）。

まず分かったのは、プラグインがなくても、どのモデルも最後の報告で「お手本と同じ SSRF の弱点を引き継いでいる」と自分から申告していたことです。プラグインを入れて変わったのは、指摘の細かさでした。Sonnet 5.5 には、名前解決の確認と実際の接続の間に DNS を書き換えて検査をすり抜ける攻撃（DNS リバインディング）の余地や、ダウンロードサイズの上限がないことまで指摘され、1回は上限を足す2回目のコミットをしています。別の依頼（書類プレビュー機能の追加）では、commit 時の点検が「ログインしていればどの顧問先のファイルも読める」と指摘し、Haiku 5.5 が所有者チェックを足すコミットを追加した例もありました。

一方で、Haiku 5.5 は指摘を受けても「同じ方式でという指示に従ってそのままにした。対策を入れるなら指示してほしい」と返し、コードは直しませんでした。公式ドキュメントのとおり、このプラグインは止める仕組みではなく、利用者の指示と指摘が食い違ったときに最終判断を利用者に戻す仕組みです。危ないお手本を「まねて」と頼まないこと、指摘が出たら必ず読むことが前提になります。

動かない・費用が見えないときの確認点

実測では、プラグインのモデルによる点検が動かない場面が2回ありました。どちらも ~/.claude/security/log.txt（今回は環境変数 SECURITY_GUIDANCE_DEBUG_LOG で出力先を変更）を見ると原因が分かりました。

もう1つ、commit 時の点検は「まだ点検していないコミット」をまとめて見るため、導入して最初のコミットではリポジトリにある既存のコミットも対象になり、既存コードの脆弱性まで一覧で返ってきました。今回の実測ではどの回も、Claude は「既存コードは直さない」という指示を守って一覧を報告するだけでしたが、思わぬ量の指摘が出ることは知っておくとよいでしょう。なお、今回は最後に commit させる依頼だったため、指摘を出したのは commit 時の点検で、ターン終わりの点検は動いた6回とも「問題なし」でした。

業務で脆弱性診断を始める手順と注意点

まずは既存のコードを一度、普通に頼んで診断し、そのうえで変更のたびに /security-review、Claude に書かせる作業では security-guidance、と段階的に足していくのが始めやすい順番です。診断結果は「候補」として扱い、最終判断は人が行います。

ツールの限界も押さえておきます。security-guidance の README は「最善の努力による支援ツールで保証ではない。人によるコードレビュー、静的・動的解析、依存関係のスキャン、ペネトレーションテストの代わりにはならない」と明記しています。今回の実測も、教科書どおりの脆弱性を仕込んだ小さなアプリでの結果です。Claude Code の診断は「人が見る前の一次チェック」として位置づけ、重要なシステムは専門家の診断と組み合わせるのが安全です。

Claude Code を業務で使う前の基本的なセキュリティ設定はClaude Codeの必須セキュリティ設定、Opus 5.5 の分類器とモデルの切り替えについては既存ゲームの再現ルールとサイバー分類器の違いで詳しく解説しています。Claude Code そのものの基本はClaude Codeとは？にまとめています。

まとめ