AI が書いたコードの約 45% に OWASP Top 10 の脆弱性が含まれている。Veracode が公開した調査の数字で、人間が普通に書くコードと比べて 2.74 倍も脆弱性が多いという。Vibe Coding で量産されたサービスが API キー 150 万件を公開状態にしていた、みたいな事故も実際に起きている。Claude Code を業務で回している人なら、生成スピードの裏でこの不安はずっと付きまとっていたはず。
そこに Anthropic が、Claude Code 向けの security-guidance プラグインを出してきた。やることはシンプルで、Claude が書いたコードを、別の Claude がその場でレビューして、脆弱性を見つけたら同じセッションで直す。前回 Anthropic の「封じ込め」設計の記事を読んだときにも感じたけど、この会社はコード生成のアクセルとセキュリティのブレーキを、同じ熱量で踏みに来ている。公式ドキュメントを読み込んだので、中身を整理する。
- 何をするプラグインか、まず全体像
- 編集・ターン終了・コミットで深さを変える3段階レビュー
- 「自分のコードを自分で採点させない」設計の妙
- PRのセキュリティ指摘が30-40%減ったという社内データ
- タダではない、Opus 4.7を回す層のトークンコスト
- 組織のルールを足せる、defense in depthの最初の1枚として
何をするプラグインか、まず全体像
このプラグイン、インストールすると勝手に動く。呼び出すコマンドも、覚えておくスラッシュコマンドもない。Claude がコードを書くたびに、裏でレビューが走る仕組み。
検出対象は、インジェクション、安全でないデシリアライゼーション、安全でない DOM API といった、AI 生成コードで頻出する脆弱性。これらを PR（プルリクエスト）に到達する前に捕まえて、その場で修正させる。要は、人間のレビュアーまで降りてくる前に、機械的に潰せるものは潰しておく、という発想。
インストールは Claude Code のセッション内から。
/plugin install security-guidance@claude-plugins-official /reload-plugins
前提条件は、Claude Code CLI 2.1.144 以降、Python 3.8 以降、そして git リポジトリであること。全プランで使える。マーケットプレイスが見つからないと言われたら、先に /plugin marketplace add anthropics/claude-plugins-official を打ってから入れ直す。
編集・ターン終了・コミットで深さを変える3段階レビュー
このプラグインが賢いのは、3 つのタイミングで、それぞれ深さの違うレビューをかける設計になっているところ。全部を一律にやると重いし遅い。だから段階を分けている。
ひとつ目は、ファイル編集のたびの高速パターンマッチ。Claude がファイルに書き込んだ瞬間、危険なパターンを文字列照合でチェックする。eval(、new Function、os.system、child_process.exec みたいな動的コード実行、pickle のような安全でないデシリアライゼーション、dangerouslySetInnerHTML や .innerHTML = といった DOM インジェクション、それと .github/workflows/ 配下の編集。ここはモデルを呼ばないのでトークンコストがゼロ。これが効いてくる、というのは後述する。
ふたつ目は、ターン終了時の差分レビュー。1 ターン（あなたがメッセージを送って、Claude が作業して返すまで）が終わると、その間に変わった全ファイルの git 差分を計算して、セキュリティ特化の別 Claude に送る。これはパターンマッチでは拾えない、認可バイパス、安全でない直接オブジェクト参照、SSRF、弱い暗号みたいな文脈を読まないと分からない問題を捕まえる。バックグラウンドで走るので、Claude の返答自体は遅れない。最大 30 ファイル、連続 3 回まで。
みっつ目は、コミット・プッシュ時の深いエージェント型レビュー。Claude が git commit や git push を実行すると、周辺のコード（呼び出し元、サニタイザ、関連ファイル）まで読み込んで、その脆弱性が本物かどうかを判断してから報告する。単体で見ると危険だけど、このコードベースでは安全、というケースの偽陽性を減らす工夫。1 時間あたり 20 回まで。
段階を分けることで、軽いチェックは毎回、重いチェックは節目だけ、というメリハリが効いている。現場感覚で言うと、この設計思想は CI/CD のパイプライン設計とよく似ていて、納得感がある。
「自分のコードを自分で採点させない」設計の妙
個人的にいちばん感心したのが、ここ。コードを書いた Claude 自身に、自分のコードを採点させていない。
考えてみれば当たり前なんだけど、これは大事なポイント。自分が書いたコードを自分でレビューすると、「この approach で正しいはず」という思い込みが入る。人間のコードレビューを別の人がやるのと同じ理屈で、レビューは独立していないと意味が薄い。
このプラグインの、モデルを使うレビュー（ターン終了時とコミット時）は、新しいコンテキストの別 Claude 呼び出しとして走る。レビュー担当の Claude は、差分だけを渡されて、元のアプローチに何の思い入れもない状態から、「問題を見つけろ」とだけ指示される。書いた本人じゃないから、忖度なく叩ける。マネージャー目線で言うと、これは「実装者とレビュアーを分ける」という組織のセキュリティ原則を、AI のワークフローの中で再現している形。
ただし、どの層も書き込みやコミットをブロックしない。見つかった問題は「指摘」として書いた側の Claude に戻されて、Claude が会話の中で対応する。レビューモデルが見逃す可能性もある。だから Anthropic 自身も「これは defense in depth の 1 層であって、完全なセキュリティ解決策ではない」と明記している。過信は禁物、という線引きは正直で好感が持てる。
PRのセキュリティ指摘が30-40%減ったという社内データ
「で、実際効くの?」という疑問に対して、Anthropic は具体的な数字を出している。社内で広範に使った結果、このプラグインを使って開いた PR のセキュリティ関連コメントが 30-40% 減少した、と。
これ、地味だけど現場にとっては大きい。PR のセキュリティ指摘が 3〜4 割減るというのは、レビュアーの負荷がそれだけ下がるということ。コードレビューで「ここ SQL インジェクションの余地ありますよ」みたいな基本的な指摘を毎回するのは、レビューする側もされる側も消耗する。その単純な往復が減れば、人間のレビュアーは設計やロジックみたいな、本当に人間が見るべき部分に集中できる。
部下に紹介するなら、「コードレビューの一次フィルタを AI に任せて、人間は二次以降を見る」という分業の入口として説明すると思う。プラグインが軽い一次パスを担って、その後に /security-review（オンデマンドの一括チェック）や、PR 時の Code Review（Team/Enterprise プラン）、CI の静的解析が続く。各段階が前段の漏れを拾う多層構造。
タダではない、Opus 4.7を回す層のトークンコスト
ここは正直に書いておきたい。前回 Obsidian 連携の記事でもトークン消費の話をしたけど、このプラグインも使い方次第でトークンを食う。
3 層のうち、ファイル編集時のパターンマッチはコストゼロ（モデルを呼ばないので）。問題は残り 2 層。ターン終了時のレビューとコミット時のレビューは、どちらもモデル呼び出しで、しかもデフォルトで Claude Opus 4.7 を使う。Opus は Claude のフラッグシップで、当然トークン単価が高い。ファイルを変更するターンごとに 1 回、コミットごとに 1 回（こちらはエージェント型で複数ターン回る可能性あり）レビューが走る計算。
ヘビーに開発を回している人だと、これは確実に Claude Code の使用量に乗ってくる。週次上限が気になっている人なら、なおさら無視できない。
ただ、対策は用意されている。レビューに使うモデルは環境変数で変えられる。SECURITY_REVIEW_MODEL でターン終了時レビューのモデルを、SG_AGENTIC_MODEL でコミット時レビューのモデルを、それぞれ指定できる。Opus じゃなく Sonnet や Haiku に落とせば、コストはかなり抑えられる。レビュー精度とのトレードオフになるけど、「まず軽いモデルで試して、必要なら上げる」という入り方が現実的だと思う。各層は環境変数で個別にオフにもできる。
つまり、何も設定せず全部 Opus で回すと、生成のたびにフラッグシップが裏で動いてトークンが膨らむ。ここを理解してモデルを選べば、コストはコントロールできる。設定の問題で、避けられない出費ではない。
組織のルールを足せる、defense in depthの最初の1枚として
このプラグイン、組み込みのチェックだけじゃなく、自社のセキュリティポリシーを足せるのも実用的。
.claude/claude-security-guidance.md というファイルをリポジトリに置いて、自社の脅威モデルやレビュー観点を普通の日本語（や英語）で書いておくと、モデルベースのレビューがそれを追加のコンテキストとして読む。たとえば「/admin 配下のルートは必ず require_role("admin") を呼ぶこと」「customer_id を INFO レベル以上でログ出力しないこと」みたいな、自社固有のルール。これをリポジトリにチェックインすれば、クローンした全員に効くし、MDM で配布すれば組織全体に展開できる。
文字列パターンの方も .claude/security-patterns.yaml で自社ルールを足せる。社内 API キーの prefix（sk_live_ や AKIA）をハードコードしてないか、マルチテナントのコードで org_id フィルタを忘れてないか、みたいなそのコードベース固有の地雷を登録できる。
注意したいのは、これらはガードレールではなくガイダンスだということ。違反を「指摘」として出すけど、書き込みをブロックするわけじゃない。本当に止めたいルールは、編集をブロックする hook や CI チェックと組み合わせる必要がある。プラグインはあくまで「最も早い段階で、最も安く拾う 1 枚目のフィルタ」。これ単体でセキュリティが完成するわけじゃない、という位置づけを間違えないことが大事。
AI 生成コードの 45% に脆弱性が混ざる時代に、いちばん上流で機械的に拾える仕組みが標準で手に入るのは、素直にありがたい。まず試すなら、本番リスクの低い個人プロジェクトか社内ツールのリポジトリに入れて、レビューモデルを Sonnet あたりに設定して、1 週間どんな指摘が出るか眺めてみる。出てくる指摘の質を見てから、本番リポジトリや組織展開に広げるか判断する。導入のハードルは /plugin install の一行なので、まずどんなものか自分の目で確かめるのがいちばん早い。
