Claude Code security-guidanceの正体｜AIが書くそばから脆弱性を潰す3層レビュー

「Minutes later, it was flagging things in my workflow that I had completely missed.」。MediumでClaude Codeのsecurity-guidanceプラグインを試した開発者Joe Njenga氏は、こう書き残した（Medium）。導入から数分で、自分が見逃していたものをプラグインが拾い始めた、という意味だ。

Anthropicが2026年5月27日に公開したClaude Code公式プラグイン「security-guidance」は、AIが書いたコードを別のClaudeがその場でレビューする仕組みを持つ（Help Net Security、公式ドキュメント）。インストールはコマンド一行。プラグイン自体は無料（モデル呼び出しを伴うレイヤーのトークン消費は別途発生）。前提条件はClaude Code CLI 2.1.144以降とPython 3.8以降、それと作業ディレクトリがgitリポジトリであることだけだ。

Anthropic自社調べでは、プラグイン導入後のプルリクエストに対するセキュリティ関連コメントが30〜40%減少したと報告されている（Help Net Security）。第三者検証ではなくAnthropic社内データである点は留意したい。それでもレビュー担当者の負荷が3割減るというのは、フリーランスや小規模チームにとって決して小さくない数字だ。

ただしこのプラグインは万能ではない。後で詳しく書くが、SAST（静的解析）の置き換えではないし、「導入したら何もしなくていい」というツールでもない。本記事では3層レビューの構造、25種類の検出パターン、導入手順、現実的な限界までを掘り下げる。

なぜ今このプラグインが要るのか：AI生成コードの脆弱性問題

少し前提を共有しておきたい。

Georgia Tech のSystems Software and Security Lab（SSLab）が公開しているVibe Security Radarによれば、AI生成コードに直接起因するCVE（共通脆弱性識別子）登録件数は2026年1月の6件から3月には35件まで増えた（CSA Research）。同レポートで研究チームは実際の混入数を検知数の5〜10倍、つまりオープンソース全体で400〜700件規模と見積もっている。

Tenzaiが2025年12月に実施したという検証では、主要なAIコーディングエージェント5種類すべてが同じ機能でSSRF（外部URLを踏ませることで内部サービスにアクセスする攻撃）を生成したと報告された（CSA Research経由）。Georgetown CSETの調査では、5つの大手LLMをテストした際、XSS（クロスサイトスクリプティング）関連のテストサンプルの86%にXSSが検出された（出典）。GitGuardian系の集計では、AIアシストでコミットされたコードがシークレットを漏らす割合は、人間の書いたコードの約2倍（3.2%対1.5%）とされる。

数字を並べると重い話に聞こえるが、要は「AIにコードを書かせる時代に、AIが書いたコードを別のAIに即座にチェックさせる仕組みが必要になった」ということだ。security-guidanceはそこに対する公式の回答である。

security-guidanceの3層レビュー構造

このプラグインの中核は、3つの異なる深さのレビューが直列で走る点にある（Claude Code Docs）。

レイヤー	タイミング	モデル呼び出し	何を見るか
1. ファイル編集時	EditやWriteの直後	なし（パターンマッチ）	eval、pickle、innerHTMLなど25種類の危険パターン
2. ターン終了時	Claudeの応答が完了した直後	あり（バックグラウンド）	gitディフ全体を読み、認可バイパスやSSRFなど
3. コミット・プッシュ時	Claudeがgit commitやgit pushを実行したとき	あり（エージェント型）	周辺ファイルを読みデータフロー追跡

レイヤー1：ファイル編集時のパターンマッチ

Claudeが新しい内容をファイルに書き込むと、その内容に対して既知の危険パターンの文字列マッチが走る。モデル呼び出しがないので追加コストはゼロだ。

検出対象の例を公式ドキュメントから引く。

• 動的コード実行：eval(、new Function、os.system、child_process.exec
• 安全でないデシリアライズ：pickle
• DOM インジェクション：dangerouslySetInnerHTML、.innerHTML =、document.write
• ワークフローファイルの編集：.github/workflows/配下への変更

合計で約25パターンが組み込まれている（Pasquale Pillitteri）。同じパターンが同じファイルで再度ヒットしても、1セッション中は1回しか警告が出ない設計だ。会話がノイズで埋まらないようにする工夫である。

レイヤー2：ターン終了時のディフレビュー

ターンというのは「ユーザーがメッセージを送り、Claudeが作業して応答する」までの一往復のことだ。このターンが終わったタイミングで、プラグインは作業ツリー全体のgitディフを計算し、別のClaude（デフォルトはOpus 4.7）にセキュリティレビューを依頼する。バックグラウンドで走るのでClaudeの返答が遅れることはない。

ここで拾われる問題は、単純な文字列マッチでは見つからない種類だ。

• 認可バイパス（authorization bypass、認証は通るが権限チェックが甘い欠陥）
• IDOR（Insecure Direct Object References、他人のリソースIDを直接叩けてしまう欠陥）
• インジェクション全般
• SSRF
• 弱い暗号化

レビューは1ターンあたり最大30ファイルまでをカバーし、連続3回まで再プロンプトを返したら一旦ユーザーに制御を戻す。

レイヤー3：コミット・プッシュ時のエージェント型レビュー

Claudeがgit commitやgit pushをBashツール経由で実行したとき、プラグインはより深いレビューを走らせる。このレビューはRead/Grep/Globでリポジトリ内の関連ファイルを能動的に読み、データフローを追跡する。

ここが他の2層と決定的に違う点だ。「この変更だけ見ると危険そうだが、呼び出し元のサニタイザを通っているから実際は安全」といった判定が可能になる。レイヤー1の文字列マッチでは原理的に出せない判断だ。

回数は1時間あたり最大20回までに制限される。ユーザーが自分のシェルからgit commitしたものや、Claudeセッション内の!シェルエスケープから出したコミットはこの層の対象外だ。あくまでClaude自身がコミットしたものだけがレビューされる。

導入手順：3コマンドで終わる

Claude Codeのセッション内で以下を順に実行する。

# 1. 公式マーケットプレイスからインストール
/plugin install security-guidance@claude-plugins-official

# 2. スコープを聞かれたら user を選ぶ
#    → 同じマシンの全プロジェクトで有効になる

# 3. 現在のセッションで即時有効化
/reload-plugins

マーケットプレイスが見つからないと言われたら、先に/plugin marketplace add anthropics/claude-plugins-officialを打ってから再試行する。

初回起動時、プラグインは~/.claude/security/配下に独自のPython仮想環境を作り、Claude Agent SDKをインストールする。pipとネットワークアクセスが必要だ。これに失敗するとレイヤー3が「シングルショットのレビュー」にフォールバックする（つまり周辺ファイルは読まれず、ディフだけを見るレビューになる）。Windows環境では仮想環境ステップ自体がスキップされ、claude-agent-sdkが既にimport可能でなければ同じくフォールバックする。

チームで使うときの設定

userスコープでインストールするとそのマシンの全プロジェクトに適用されるが、Claude Code on the webや他のメンバーには引き継がれない。リポジトリにチェックインして全員が使う形にしたい場合は、プロジェクトの.claude/settings.jsonに明示する。

{
  "enabledPlugins": {
    "security-guidance@claude-plugins-official": true
  }
}

既存の.claude/settings.jsonがある場合はenabledPluginsキーを既存設定にマージする形にする。組織全体に展開する場合は管理者がManaged Settings経由で配布できる。Anthropicは「Pluginの公式実装そのものがHookの活用サンプルになっている」とも書いており、自社カスタマイズの土台にも使える。

カスタマイズ：プロジェクト固有ルールの追加

ここからは自分が触ってみて「フリーランスの実務に効くな」と感じたカスタマイズの話だ。

ガイダンスファイル（Markdown）でドメイン固有ルール

.claude/claude-security-guidance.mdを作って、自分のリポジトリ特有の脅威モデルやレビュー方針を自然言語で書く。レイヤー2・3のモデルレビューがこれを追加コンテキストとして読み込む。

# このリポジトリのセキュリティガイダンス

- `customer_id` や `account_number` は INFO レベル以上でログに出さない
- `/admin` 配下の全ルートは DB 読み取り前に `require_role("admin")` を呼ぶ
- トークン比較は `===` ではなく `crypto.timingSafeEqual` を使う

これは決定論的なガード（書き込みをブロックする仕組み）ではない点に注意がいる。違反は「指摘」としてClaudeに返るだけで、Claudeが直さなければ通過してしまう。本気で書き込みを止めたい場合は、HookでEditをブロックするか、CIに別途チェックを噛ませる必要がある。

User scope（~/.claude/claude-security-guidance.md）、Project scope（.claude/claude-security-guidance.md）、Project local scope（.claude/claude-security-guidance.local.md、gitignore対象）の3階層が存在し、すべて連結された上で読み込まれる。合計サイズの上限は8KBだ。

パターンファイル（YAML/JSON）でレイヤー1の拡張

.claude/security-patterns.yamlを作るとレイヤー1の文字列マッチに独自ルールを追加できる。

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（識別子）、reminder（警告本文、1KBまで）、regex（Python正規表現）、substrings（部分文字列リスト）、paths（適用globパターン）、exclude_paths（除外globパターン）の6つだ。

最大50ルールまで読み込まれ、catastrophic backtracking（壊滅的バックトラッキング）が起きそうな正規表現は自動でスキップされる。YAMLが動かない環境（PyYAMLがimportできない）では、同じスキーマをJSONで書けば.claude/security-patterns.jsonとしても読まれる。

実際のユーザーが感じたこと

公式の数字だけでは伝わらないので、実際に試した3人の声を引く。

Joe Njenga氏（Medium）

「導入から数分で、自分のワークフローで完全に見落としていたものを次々と警告し始めた。ハードコードされたシークレット、安全でないコマンド、怪しいプロンプト、コミット時のチェックまでテストした」とMediumで報告している（Medium）。

詳細はペイウォールの向こう側だが、彼が「テストする価値がある」と判断するに足る発見があったことは伝わる。

しろちゃん氏（Zenn、渋谷在住エンジニア）

Zennで詳細な解説記事を出している（Zenn）。3層の動作を独立に検証し、レイヤー1で約25パターンを瞬時に検出、レイヤー2でOpus 4.7がディフを読む、レイヤー3でコミット時に複数ファイルにまたがるデータフローを追う、という流れを実機で確認している。

同時に「best-effort（最善努力ベース）の補助であり、SAST/DASTやペネトレーションテストを完全に代替するものではない」と冷静な評価を加えている。ここを誤解しないことが重要だ。

貴信佐野氏（@4q_sano、株式会社フォー・クオリア）

Qiitaで先輩・後輩エンジニアの対話形式で導入手順とスコープ設定を解説している（Qiita）。「セキュリティ担当のもう一人のClaudeを常駐させる」という表現は、このプラグインの本質を一言で表していると感じた。

3人ともに共通するのは、「導入は簡単」「実際に何かを拾う」「ただし万能ではない」というトーンだ。誇張も貶しもない。

光と影：このプラグインの限界

ここからが影の部分。導入する前に知っておくべき話だ。

1. SAST/DAST（動的解析）の代替にはならない

Pasquale Pillitteri氏の分析は明確だ。「これはパターンマッチであり、セマンティック解析ではない。明らかな脆弱性は捕まえるが、データフローの追跡や高度な難読化の検出はできない。Snykのような従来のSASTツールを補完するものであって、置き換えるものではない」（出典）。

レイヤー3はある程度のデータフロー追跡を行うが、それでも独立した静的解析エンジンとは深さが違う。

2. 書き込みやコミットをブロックしない

これは公式ドキュメントが繰り返し強調している点だ。発見事項はClaudeに「指摘」として伝わり、Claudeが対応する。Claudeが対応しなければ通過する。「本気で止めたければHookか CIで止めろ」というスタンスである。

つまりこのプラグインは「最初の防衛線」であって、「最後の砦」ではない。

3. 自分のシェルからのコミットは見ない

レイヤー3はClaudeがBashツールから実行したgit操作だけを対象とする。ユーザーが別ターミナルでgit commitしたり、!git commitのシェルエスケープを使ったコミットはスキップされる。

この設計意図はわかる（ユーザー操作にまで割り込むのは過剰）が、Claudeにコードを書かせた後、自分でレビューしてから自分の手でコミットする運用ではレイヤー3が一切働かないことになる。気をつけたい。

4. モデル呼び出し分のコストがかかる

レイヤー1は無料だが、レイヤー2・3はモデル呼び出しを伴う。1ターンに1回程度、1コミットに1回程度のオーバーヘッドだ。Opus 4.7をデフォルトで使うので、長時間セッションでは無視できない額になる。

軽くしたい場合は環境変数で別モデルに切り替えられる。SECURITY_REVIEW_MODELでレイヤー2を、SG_AGENTIC_MODELでレイヤー3をそれぞれ指定する。例えばexport SECURITY_REVIEW_MODEL=claude-haiku-4-5のように指定すればコストは大幅に下がる。

5. Linux/Macとの差がある

Windows環境では初回のPython仮想環境構築がスキップされる。claude-agent-sdkが既にPython側でimport可能でない限り、レイヤー3は常にフォールバック動作になる。実質的にWindowsユーザーはレイヤー3の能力をフル活用しにくい。

電脳狐影の判断：自分ならこう使う

PMとしての判断を書く。

自分なら、フリーランスのクライアントワークでは/plugin installを必須運用にする。理由は2つある。

1つ目は、AIにコードを書かせる頻度が増えるほど、人間が見落とすパターンも増えるからだ。30〜40%のセキュリティコメント削減という数字は、PRレビュー時間に直接効く。フリーランスのレビュー相手がいない環境では特に価値がある。

2つ目は、「自分が書いたコードではなくAIが書いたコードに対するチェック」という線引きが心理的に大切だからだ。AIに任せた以上、最終責任は自分にある。security-guidanceは「AIに任せた領域を別のAIが独立に見る」構造であり、責任分界が明確になる。

ただし無条件で全プロジェクトに入れることはしない。具体的には以下のルールで使い分けるつもりだ。

• 本番デプロイ予定のあるリポジトリ：必須でenabledPluginsに登録
• プロトタイプ・実験コード：レイヤー1だけ有効化（ENABLE_STOP_REVIEW=0とENABLE_COMMIT_REVIEW=0でコスト圧縮）
• 自分のブログ・自動化スクリプト：そもそも入れない（外部入力を扱わないため）

ガイダンスファイルは、Webサービス案件なら必ずrequire_role系のルールと「顧客IDをログに残さない」ルールを書く。書かないと「このリポジトリで何を守りたいか」がClaudeにも自分にも曖昧になる。

CIにはこれと別にSemgrepかSnykを噛ませる。security-guidanceは「最初の網」、CIのSASTは「2枚目の網」、PRレビューが「3枚目の網」だ。3枚あれば、AIが書いたコードが本番に届くまでに何かしらの目を通せる。

まとめ：今日やること

1. Claude Code CLIを2.1.144以降にアップデートする
2. /plugin install security-guidance@claude-plugins-officialでインストール、スコープはuser
3. /plugin listで有効化を確認し、テスト用ファイルにeval("1+1")を書いて警告が出ることを確認する
4. 本番候補のリポジトリには.claude/claude-security-guidance.mdを1ファイル置く
5. CIにSAST（SemgrepかSnyk）を併用する設定にする

導入自体は数分で終わる。あとは1週間使って、警告のノイズと有用性のバランスを見ながら、レイヤー単位でON/OFFを調整していく流れがいい。

---

免責事項: 本記事の情報は2026年6月5日時点のものだ。プラグインの仕様・検出パターン・コスト・対応モデルは変更される可能性がある。導入前に公式ドキュメント（code.claude.com/docs/en/security-guidance）で最新情報を確認してほしい。本記事はセキュリティの一般情報を提供するもので、特定の脆弱性対策を保証するものではない。重要な本番環境への適用は、別途専門家のレビューや独立した監査と組み合わせることを推奨する。