この記事のポイント

Anthropic が 2026 年 5 月下旬に Claude Code 向けの公式プラグイン security-guidance を公開しました（各メディアで紹介されたのは 5 月 27 日です）。全プランで利用でき、2026 年 6 月時点でベータ表記はありません。ただしモデルによるレビューは通常の Claude 利用枠を消費します
「ファイル編集時 / ターン終了時 / コミットや push 時」の 3 層で脆弱性を検出し、検出した内容をそのまま AI に修正させる流れが特徴です
Anthropic の社内ベンチマーク（公式発表をメディアが引用したもので、公式ドキュメント本文には載っていません）によると、このプラグインを使って開いたプルリクエストに付くセキュリティ系コメントが 30〜40% 減ったとされていて、レビュー前の早い段階で問題を潰す用途に向きそうです
ただし「AI がコードを書く → AI が直す」というループ自体は監査対象として残るため、Snyk / CodeQL / SAST との併用や、Anthropic がまとめている「封じ込め設計」の考え方を踏まえた運用が現実的だと考えています

この記事は 2026 年 5 月末に公開し、2026 年 6 月 30 日に公式ドキュメント（code.claude.com）で各記述を再確認したうえで内容を更新しています。プラグイン名・インストールコマンド・前提バージョン・3 層構成は再確認時点でも変更ありませんでした。

はじめに

このプラグインの使い方を「/plugin install を叩けば終わり」とだけ紹介するのは、たぶん本質を外していると感じています。手順そのものは数行で済むので、本記事ではむしろ「なぜこの種のプラグインが今のタイミングで必要とされたのか」「AI が書いたコードの脆弱性検出は、従来のセキュリティ検査と何がどう違うのか」という背景の方に紙幅を割いてみます。

Claude Code をはじめとするエージェント的なコーディング支援が日常に入り込むと、開発の現場では「人間が 1 行ずつ書いて、人間がレビューする」という前提が崩れていきます。AI が数百行を一気に生成し、別の AI がそれを直し、また別のセッションで機能を足していく。このとき素朴に湧いてくる疑問が「では、その大量のコードを最終的に誰が（あるいは何が）レビューするのか」というものです。security-guidance は、この構造的な問いに対する Anthropic 側からの一つの回答として読めると考えています。

本記事ではこのプラグインの位置づけと使い方を押さえつつ、その手前にある脅威モデルの変化、3 層分析が攻撃面のどこに対応しているのか、AI に修正させること自体のリスク、そして既存ツールとの棲み分けを「思想の違い」から整理してみます。AI と DevSecOps が交わる領域に関心のある方に届くと嬉しいです。

1. なぜ今このプラグインが必要とされたのか

1-1. 「誰が大量の AI コードをレビューするのか」という構造問題

従来のソフトウェア開発では、コードを書く速度には人間の手が律速として効いていました。1 日に人間が書けるコード量には上限があり、レビューする側もおおよそそのペースに追従できていたわけです。レビューが追いつかないとしても、それは「人手が足りない」という量の問題で、構造そのものが破綻していたわけではありません。

エージェント的コーディングが普及すると、この前提が変わります。生成側の速度が人間のレビュー速度を大きく上回り始めると、「書く」と「確かめる」の間に恒常的なギャップが生まれます。しかもそのギャップは、人を増やしても簡単には埋まりません。生成側もスケールするからです。ここに「AI が大量に書いたコードを誰がレビューするのか」という、量ではなく構造に根ざした問いが立ち上がってきたと捉えています。

この問いへの応答の方向性はいくつか考えられます。たとえば「生成を遅くしてレビューに合わせる」「レビューも自動化して生成に追従させる」「そもそも危ない書き方が生成段階で出ないようにする」といった具合です。security-guidance は、このうち主に後ろ 2 つ、つまり「検査を生成の近くに置き、危ない書き方をその場で潰す」という方向に寄せた設計に見えます。生成と検査の距離を縮めることで、ギャップが拡大する前に閉じようという発想だと理解しています。

1-2. 公式が出すことの意味

サードパーティ製のセキュリティツールは以前から数多くあります。それでも Anthropic 自身がプラグインを出したことには、いくつかの意味があると感じています。一つは、Claude が生成する瞬間のコンテキスト（直前の編集差分、セッション内の意図、ツール出力など）にもっとも近い位置で動けるのは、Claude Code 本体に統合された仕組みだという点です。外部ツールは生成が終わって出力されたコードを後から見ますが、統合された仕組みは「書いている最中」の文脈をそのまま使えます。

もう一つは、AI が書いたコードに特有の失敗パターンを、生成側のベンダーがもっともよく把握できる立場にあるという点です。どんな入力でどんな誤りが出やすいかは、モデルを訓練・運用している側に知見が溜まります。その知見を検査側にも反映できるのは、同じ提供元ならではの強みだろうと考えています。とはいえ、これは「公式だから安心」という話ではなく、「公式だからこそ把握できる失敗パターンがある一方で、見落とす範囲も当然ある」という両面で捉えるのが妥当だと感じています。

2. AI 生成コードの脅威モデルは、なぜ従来と違うのか

ここが本記事でいちばん厚く書きたいところです。AI が書いたコードの危うさは、量が多いという以上に、危うさの質が従来と異なる点にあると考えています。

2-1. 人間が書かないパターンが混入する

人間のレビューは、長年積み上げた「人間がやりがちなミス」のパターン認識に支えられています。off-by-one、null チェック漏れ、ロック忘れ、典型的な SQL の組み立てミスなどです。ところが AI は、人間とは違う統計的な傾向でコードを生成します。学習データの分布に引っ張られて、文脈的にはもっともらしいけれど局所的には不整合な書き方を混ぜてくることがあります。

問題は、こうした「人間が書かないパターン」のミスに対して、人間のレビュアーの直感的なアラートが鳴りにくいことです。見た目が自然で、変数名も妥当で、コメントまで丁寧に付いていると、レビュアーは「ちゃんと考えて書かれたコード」として読み流しやすくなります。流暢さが、かえって警戒心を下げる方向に働くわけです。

2-2. もっともらしいが誤った依存追加

機能を実現するために、AI がライブラリの追加を提案してくることがあります。多くは妥当ですが、ときに「やりたいことに対して過剰な権限を要求するライブラリ」や「メンテナンスが止まっている古いパッケージ」「名前は似ているが目的の違うパッケージ」を、自然な口調で勧めてくることがあります。

依存追加は、コード本体以上に攻撃面を広げやすい操作です。一つ依存を足すと、その依存がさらに引き連れてくる依存（推移的依存）まで含めてプロジェクトに取り込まれます。AI の提案は文章として説得力があるため、レビュアーが「もっともらしいから」と受け入れてしまうと、攻撃面が静かに拡大していくことがあります。

2-3. ハルシネーションによる存在しないパッケージ（slopsquatting）

さらに固有のリスクとして、AI が存在しないパッケージ名を自信ありげに生成してしまう現象があります。これ自体は単なる誤りなのですが、悪用の経路につながり得る点が厄介です。攻撃者が、AI がよく幻覚する名前を先回りして実在のパッケージとして登録しておけば、その名前を信じてインストールした開発者が悪意あるコードを取り込んでしまう、という筋書きが成立し得ます。

この手口は「slopsquatting」と呼ばれることがあります。従来のタイポスクワッティング（打ち間違いを狙う）が人間のタイプミスを前提にしていたのに対し、slopsquatting は AI の幻覚を前提にしている点で、まさに AI 時代に固有のリスクだと言えそうです。

slopsquatting を含むサプライチェーン攻撃の具体的な手口や対策は、状況によって大きく変わります。ここでの記述は概念の整理を目的にしたものなので、実際の対策を検討する際は、利用しているパッケージレジストリやセキュリティベンダーの最新の公式情報を確認していただく方が安全だと考えています。

2-4. まとめると、何が変わったのか

従来の脅威モデルが「人間が起こすミスや、外部の攻撃者が仕掛ける攻撃」を主に想定していたのに対し、AI 時代には「もっともらしさで警戒を解いてくる生成物」という新しい軸が加わったと整理しています。流暢で説得力があるからこそ素通りしやすい、という点が共通項です。だとすると、検査側も「いかにもおかしいコード」だけでなく、「自然に見えるが危ういコード」を捕まえる方向に寄せる必要が出てきます。

3. 3 層分析と攻撃面マッピング

security-guidance の特徴は、レビューを 1 回で済ませず、開発フローの異なるタイミングに 3 段階で挟み込んでいる点です。記事や Anthropic の説明を整理すると、おおよそ以下のような構成になります。

レイヤ	発火タイミング	主な処理	コスト感
1. パターンマッチ	ファイル編集時（`Edit` / `Write` / `NotebookEdit` の直後）	危険なライブラリ呼び出しや既知の悪パターンを決定論的に高速検知（モデル呼び出しなし）	軽量、トークン消費なし
2. ターン終了レビュー	1 ターン分の変更がまとまった時点	バックグラウンドでモデルが git の差分をレビューし、見落としを再確認して Claude にフィードバック	中程度
3. コミット時レビュー	`git commit` / `git push` の直前	周辺コードや呼び出し元まで読み込んで本格的なエージェントレビュー	重め

公式ドキュメントを読むと、それぞれのレイヤには実運用上の上限や前提が設けられています。レイヤ 2 は 1 回あたり最大 30 ファイル・連続 3 回まで、レイヤ 3 はおおむね 1 時間あたり 20 回までといった具合で、コストが膨らみすぎないように調整されています。レイヤ 2・3 は git リポジトリ内でのみ動き、リポジトリ外ではスキップされます。

ここで一点気をつけたいのが、コミット時レビュー（レイヤ 3）が動くのはあくまで Claude が Bash ツール経由で git commit / git push を実行したときに限られる、という挙動です。! のシェルエスケープから直接コミットした場合や、利用者が自分のターミナルから手でコミットした場合はレビュー対象になりません。「コミットすれば必ず最終チェックが走る」と思い込むと取りこぼしが起きやすいので、運用に組み込むときは押さえておきたい点だと感じています。

ここで意識したいのは、3 つのレイヤがそれぞれ別の攻撃面に効いている、という点です。冒頭で触れた「依存・コード・設定」という観点で、どのレイヤがどの攻撃面に対応しやすいかを整理してみます。

3-1. コード自体への攻撃面 — 主にレイヤ 1・2 が効く

コードインジェクション、安全でないデシリアライズ、危険な DOM 操作、認証バイパスといった、ソースコードの中に直接現れる脆弱性です。これらは比較的「危ない書き方の形」が決まっているため、ファイル編集時のパターンマッチ（レイヤ 1）で初手を拾い、ターン終了レビュー（レイヤ 2）で文脈を踏まえた見落としの再確認をかける、という二段構えが効きやすい領域だと考えています。

書いた直後にその場でフィードバックが返るので、2-1 で触れた「流暢さゆえの素通り」を、人間が読み流す前に機械側が一度引っかける形になります。

3-2. 依存への攻撃面 — レイヤ 2・3 で文脈を見たい

2-2 や 2-3 で触れた、過剰な依存追加や存在しないパッケージの混入は、1 行のパターンだけでは判断しきれません。「この機能にこの依存は妥当か」「このパッケージは実在するか、メンテされているか」といった判断には、変更全体やプロジェクトの文脈が要ります。だとすると、変更履歴全体を見るターン終了レビュー（レイヤ 2）や、周辺コードまで読み込むコミット時レビュー（レイヤ 3）の方が向いていそうです。

ただし、依存の脆弱性管理そのものは後述するように専用ツール（Snyk など）の領域が広く、このプラグイン単体で完結する話ではないと捉えています。

3-3. 設定への攻撃面 — レイヤ 3 で周辺ごと見る

権限設定、シークレットの取り扱い、CORS や認証フローの構成といった「設定面」の問題は、単一ファイルを見ても気づきにくく、複数ファイルにまたがる文脈を読んで初めて危うさが見える種類のものです。周辺コードを読みに行くコミット時レビュー（レイヤ 3）が、相対的にこの面に踏み込みやすいと考えています。

このように、3 層は単なる「念のための多重チェック」ではなく、軽いパターンマッチで拾える攻撃面から、文脈を要する攻撃面まで、段階的にカバー範囲を広げていく構造として読むと腑に落ちます。検出対象として記事内で挙げられているのはコードインジェクション、危険なデシリアライズ、DOM 操作の問題、認証バイパスといった代表例ですが、網羅性については公式ドキュメント側の記載が一次情報になるため、自分のスタックでどこまで効くかは導入後に確認したいところです。

4. なぜ SAST / DAST だけでは AI 時代に不十分なのか

ここで一度、従来型の検査手法に立ち返ってみます。SAST（静的解析）や DAST（動的解析）は長年セキュリティ検査の主軸でした。これらが AI 時代に「不要になる」わけではないと考えていますが、それだけでは追いつきにくい構造があるのも確かだと感じています。

一つは速度のミスマッチです。SAST/DAST は CI や定期スキャンで動くことが多く、フィードバックが返るのは多くの場合、コードを書き終えてしばらく経った後です。生成速度が上がった状況では、検査結果が返る頃にはもう次の生成が積み上がっていて、フィードバックループが恒常的に遅れがちになります。書いた本人（あるいは AI）の文脈が冷めてから指摘が来ても、直すコストは上がりやすいわけです。

もう一つはコンテキスト不足です。CI 段階のツールは、最終的に出力されたコードは見られますが、「なぜそう書いたのか」「どんな意図でこの依存を足したのか」といった生成時の文脈までは持っていません。AI 生成コードの危うさが「もっともらしさ」に宿るとすると、その文脈を欠いたまま形だけ見ても、自然に見える危うさは捕まえにくいことがあります。

さらに、誤検知と見逃しの構造もあります。ルールベースの SAST は誤検知が多いと運用側が疲弊し、警告を無視する習慣が育ちます。逆に厳しすぎる調整は見逃しを生みます。この調整の難しさ自体は従来からありますが、生成量が増えると警告の絶対数も増えるため、「アラート疲れ」がより起きやすくなる方向に働くと考えています。

こうした点を踏まえると、security-guidance のように「生成の近くで、文脈を持ったまま、その場で返す」という設計は、SAST/DAST の弱点を別の角度から補おうとしているものだと読めます。ただしこれは置き換えではなく補完であって、後段の SAST/DAST が持つ「コードベース全体を再現性高く、決定論的にスキャンできる」強みは引き続き必要だと感じています。

5. 導入手順と検出例（疑似ケース）

ここまで背景を厚めに見てきたので、手順自体は簡潔に押さえます。導入は Claude Code の plugin マネージャ経由で完結します。公式ドキュメントによれば、前提は Claude Code CLI v2.1.144 以降と Python 3.8 以降です（2026 年 6 月時点の CLI 最新版は v2.1.195 ですが、要求される最低バージョンは v2.1.144 のままです）。

# Claude Code 内のコマンドラインから
/plugin install security-guidance@claude-plugins-official

もし上記でマーケットプレイスが見つからないと言われた場合は、先にマーケットプレイスを登録してから入れ直します。

# マーケットプレイスを登録してからインストールし直す
/plugin marketplace add anthropics/claude-plugins-official
/plugin install security-guidance@claude-plugins-official
/reload-plugins

インストール後はフックが自動で有効になり、ファイル編集・ターン終了・コミットや push の時に裏側で動きます。検出された問題は通常のセッション画面に通知される形なので、特別な画面に切り替える必要はありません。レビューに使われるモデルは既定で Claude Opus 4.7 で、環境変数で別のモデルに変更できます（モデルによるレビューは通常の Claude 利用枠を消費します）。

チーム全体やクラウドセッションでも常に効かせたい場合は、プロジェクトの .claude/settings.json に有効化を書いておく方法もあります。

.claude/settings.json

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

本記事の記述は 2026 年 6 月時点の公開情報（code.claude.com の公式ドキュメント）で再確認したものです。プラグインの仕様や検出精度は今後のリリースで変わる可能性があるため、実運用に組み込む前に必ず公式ドキュメントの最新版をご確認ください。

ここから先は、AI に書かせたサンプルコードを題材にした疑似的なケースで動作イメージを共有します。実プロジェクト名や本番構成は伏せた上で、よくある書き方を再現したものとお考えください。

5-1. コマンドインジェクションを含む Python コード

たとえば、ユーザー入力をそのままシェルに渡してしまう以下のようなコードを書かせたとします。

import subprocess

def run_backup(filename: str) -> str:
    # ユーザー入力をそのまま結合してしまっている例
    cmd = f"tar czf /tmp/backup.tgz {filename}"
    return subprocess.check_output(cmd, shell=True, text=True)

security-guidance を入れた状態だと、ファイル編集時のパターンマッチ層（レイヤ 1）で shell=True と外部入力の結合を含む組み合わせが引っかかります。続いてターン終了時（レイヤ 2）に「これは引数を分割して呼び出した方が安全そうです、修正案を出しますか」と Claude が自発的に提案してくる、という流れになります。これは 3-1 で触れた「コード自体への攻撃面」を二段構えで拾う典型例だと整理できます。

修正後のコードは概ね以下のような形に落ち着くはずです。

import subprocess
from pathlib import Path

def run_backup(filename: str) -> str:
    target = Path(filename).resolve()
    # シェル経由ではなく引数配列で渡す
    return subprocess.check_output(
        ["tar", "czf", "/tmp/backup.tgz", str(target)],
        text=True,
    )

5-2. 危険なデシリアライズ

もう 1 つよく出てくるのが、外部から受け取ったバイト列をそのまま pickle.loads で復元する書き方です。

import pickle

def load_state(payload: bytes):
    return pickle.loads(payload)  # 任意コード実行に直結しやすい

コミット時の本格レビュー層（レイヤ 3）は、こうした「任意コード実行に直結しやすい関数の組み合わせ」を、周辺コードまで読み込んだうえで見つけてくる想定です。修正の方向としては、JSON など別の表現への置き換えや、検証付きのデシリアライザ利用が提案されることが多いと考えています。

import json

def load_state(payload: bytes) -> dict:
    # 任意コード実行を伴わない表現に寄せる
    return json.loads(payload.decode("utf-8"))

JSON で表現しきれない構造を扱う場合は、そもそも信頼できない入力をデシリアライズする設計自体を見直すか、スキーマ検証を挟む方向を検討するのが無難だと感じています。

ここで示しているコード例はあくまで動作イメージを掴むためのもので、実際の検出メッセージや修正提案の文面はバージョンや状況によって変わります。本番投入する前には、自分のリポジトリで小さな PoC を走らせて挙動を確認した方が安全だと考えています。

6. AI に修正させること自体のリスクと「封じ込め設計」

便利なプラグインではあるのですが、「AI が書いたコードを AI が直す」というループには、構造的に注意したい点があります。ここは 1 章で触れた「誰がレビューするのか」という問いと裏表の関係にあると感じています。検査も修正も AI 側に寄せると、ループが閉じて人間の目が入りにくくなる方向に働くからです。

具体的には、次のような点が気になっています。

検出ロジック自体が確率的に動く部分を含むため、見落としがゼロになるとは限りません
修正提案が表面的なパッチに留まり、本質的な設計上の問題は別途見直しが必要なことがあります
一つの修正が別の箇所を壊し、それをまた AI が直す、という修正の連鎖が起きると、変更全体の見通しが悪くなりやすいです
修正のために権限を広げたり依存を足したりすると、直したはずが攻撃面を広げてしまうことがあります
「AI が自分で検出して自分で直した」という構図は、自己検証の限界（自分の誤りは自分で気づきにくい）と重なる部分があります
「修正したから安全」という心理的な安心感が、人間レビューを軽視する方向に働く可能性があります

6-1. なぜ「封じ込め」という発想が出てくるのか

このあたりの考え方は、Anthropic が公開している How we contain Claude（封じ込め設計に関する解説）が参考になります。「封じ込め（containment）」という言葉が示しているのは、モデルの賢さや検出精度を上げて安全に近づけるという発想だけに頼らず、「仮にモデルが間違えても被害が一定の範囲を超えない」境界をあらかじめ作っておく、という発想だと理解しています。

確率的に振る舞うものを、確率の精度だけで制御しようとすると、どこかで限界が来ます。だからこそ、決定論的に効く境界（環境側の制約）を先に置いておこう、という順序の話だと捉えています。同記事では、エージェントの安全性をおおむね 3 層で支えるアプローチが紹介されています。

環境層 — サンドボックス、VM、出力制御で決定論的な境界を作る
モデル層 — システムプロンプト、分類器、訓練の修正で挙動を整える
外部コンテンツ層 — MCP サーバーやツール出力など、信頼境界の外を扱う層

ポイントは、確率的に振る舞うモデル層だけに頼らず、まず環境層で「ここから先には踏み込めない」境界を作っておくという順序です。security-guidance はこの分類で言えばモデル層側に近い仕組みなので、サンドボックスや権限制御を別途整えておかないと、検出が漏れた瞬間に被害が大きくなり得ます。逆に言えば、このプラグインを入れたからといって環境層をおろそかにしてよいわけではない、という関係だと考えています。

Claude Code 自体は OS レベルのサンドボックス（macOS の Seatbelt、Linux の bubblewrap など）で動かす設計が紹介されているので、ローカルで動かす場合もこの境界を切らさないことが現実的な落としどころに見えます。

7. 既存ツールとの棲み分けを「思想の違い」から考える

「セキュリティ監査」と聞くと、Snyk や CodeQL、Dependabot、各種 SAST/DAST ツールを思い浮かべる方も多いと思います。security-guidance はこれらを置き換えるものというより、補完する位置づけで捉えるのが妥当そうです。ここでは表で並べるだけでなく、それぞれが何を前提にした「思想」のツールなのかという角度から整理してみます。

Dependabot の思想 — 「依存は古くなる。新しい脆弱性は後から見つかる」という前提に立ち、既知の脆弱性データベースと付き合わせて依存を継続的に更新し続ける、時間軸方向の防御だと捉えています。コードの中身よりも「いつの時点の依存か」を問題にします。
Snyk の思想 — 依存ライブラリとその推移的依存を含めた攻撃面を、既知の脆弱性として体系的に管理する発想です。2-2 で触れた「依存が攻撃面を広げる」問題に、データベースの広さと再現性で応えるツールだと理解しています。
CodeQL の思想 — コードを問い合わせ可能なデータとして扱い、データフローを追跡して「危険な入力が危険な箇所まで到達するか」を意味的に解析します。3-1 で触れたコード自体の攻撃面に対して、再現性の高い決定論的な解析で深く踏み込む発想です。
security-guidance の思想 — 上記がいずれも「書き終わったコード」を対象にするのに対し、こちらは「書いている最中の、文脈を持ったコード」を対象にします。決定論的な広さ・再現性よりも、生成の近くで素早くフィードバックを返すことに重きを置いた設計だと読んでいます。

つまり、決定論的で再現性高くスキャンするツール群（Snyk / CodeQL / Dependabot）と、生成の近さで早さと文脈を取りにいくプラグイン（security-guidance）は、そもそも狙っている軸が違うと整理できます。なお、SAST や CodeQL は再現性こそ高いものの、それ自体が脆弱性の網羅を保証するわけではない点には留意が必要です。だとすると、どちらか一方で済ませるよりも、軸の違うものを重ねる方が理にかなっていそうです。

観点	`security-guidance`	Snyk / CodeQL / Dependabot / 一般的な SAST	DAST
動くタイミング	コードを書いている最中（Claude Code セッション内）	PR / CI、定期スキャン	ステージング以降の動的環境
主な対象	AI が書いたばかりのコード片	コードベース全体、依存ライブラリ	実行中のアプリケーション
強み	即時フィードバック、文脈つき、その場で修正	ルールが豊富、決定論的で再現性が高い	実挙動ベースで検出できる
弱み	検出範囲が AI 編集セッションに依存	フィードバックループが長い	環境構築コストが高い

組み合わせ方の一案としては、こんな並びになるでしょうか。

ローカル / Claude Code セッション内：security-guidance で書きながら文脈つきで直す
PR / CI：CodeQL や Snyk、Dependabot で依存・データフローを含めた決定論的な静的解析
ステージング：DAST や fuzzing で実挙動を検証
本番：監査ログ、WAF、ランタイム保護

この並びはあくまで一例なので、扱う言語やコンプライアンス要件によって優先順位は変わると思います。自分のチームに合わせて並べ替えてみるのが良さそうです。

名前が似ていて紛らわしいのですが、Anthropic には claude-code-security-review という別のリポジトリ（GitHub Action）もあります。こちらは PR が開かれたタイミングで CI 上でセキュリティレビューを走らせるもので、本記事で扱っているセッション内プラグイン security-guidance とは別物です。プラグイン本体のソースは claude-plugins-official リポジトリの plugins/security-guidance 配下にあります。上の「2. PR / CI」の層には、この GitHub Action を組み合わせる選択肢も入ってきます。

まとめ

security-guidance は、エージェント的コーディングの普及で生まれた「大量の AI コードを誰がレビューするのか」という構造問題への、生成側からの一つの応答として読めると考えています
AI 生成コードの脅威は「もっともらしさで警戒を解いてくる」点が従来と異なり、依存追加や slopsquatting のように AI 時代固有のリスクも含みます
3 層分析は単なる多重チェックではなく、コード・依存・設定という異なる攻撃面に段階的に対応する構造として捉えると腑に落ちます
AI が検出して AI が直すループには修正の連鎖や自己検証の限界といったリスクがあり、確率的な検出に頼り切らず環境層で境界を固める「封じ込め設計」の発想が引き続き大切だと感じています
Snyk / CodeQL / Dependabot / DAST とは狙う軸（決定論的な再現性 vs 生成の近さと文脈）が違うので、置き換えではなく重ねる構成が現時点では取り回しやすそうです

「AI とセキュリティをどう接続するか」はまだ各社が試行錯誤している段階で、ベストプラクティスが固まり切っていない領域でもあります。本記事の内容も導入を検討するための入り口として読んでいただき、本番への適用は公式ドキュメントと自社のセキュリティポリシーを照らし合わせて判断していただけると安心です。

参考リンク

security-guidance プラグイン公式ドキュメント - Claude Code Docs（仕様の一次情報。3 層の発火条件・上限・前提バージョンはここが正です）
プラグインの探し方・導入手順 - Claude Code Docs
Claude Code 公式ドキュメント（トップ）（旧 docs.anthropic.com の Claude Code 情報はこちらに移行しています）
claude-plugins-official - GitHub（security-guidance を含む公式プラグインマーケットプレイスのリポジトリ）
claude-code-security-review - GitHub（PR 時にレビューする GitHub Action。セッション内プラグインとは別物）
How we contain Claude - Anthropic Engineering（封じ込め設計の解説）
Anthropic releases Claude Code security guidance plugin - Help Net Security（30〜40% 減という社内検証の数値の出典。公式ドキュメント本文には掲載されていません）
Slopsquatting: AI サプライチェーン攻撃に関する調査ノート - Cloud Security Alliance
OWASP Top 10
Anthropic News