AIが生成したコードの脆弱性を、Anthropic公式の無料プラグイン security-guidance はどこまで防げるのか。わざと危険なコードを書かせて3層チェックが鳴るか実機検証し、限界も正直にまとめました。
関連記事として「
Blog執事AIに薦められたツールが危なかった——Star数に騙されないための3層防御GitHub Star 2,100のツールの依存にSSH鍵を抜くマルウェアが。Claude Codeの3エージェント並列リサーチで発覚し、deny list + PreToolUse hookで3層防御を構築した実体験。→」もあわせて読むと、“AIに任せる開発”の守り方を「入れるツール」と「書くコード」の両面から立体的に掴めます。
この記事は Anthropic 公式の発表・README(2026年5月版)と、自環境での実機検証をもとに執筆しています。検出ルールやモデルの挙動は今後のバージョンで変わる可能性があります。
TL;DR: Anthropic が2026年5月27日に公開した Claude Code 向け無料プラグイン security-guidance は、①書いた瞬間(機械照合)②返答を書き終えた時(AIレビュー)③commit時(データフロー追跡)の3層でコードの脆弱性を点検します。わざと eval や危険な書き方を仕込んだところ3層すべてが発火し、high/critical を8件検出しました。ハードコードシークレットの扱いやドキュメント誤検知など限界もありますが、0設定・トークン消費ほぼゼロで入る「最初の防波堤」として、AIに任せて書く人ほど価値が大きいツールです。
AIに「ログイン機能を作って」と頼めば、数十行のコードが一瞬で返ってきます。動く。テストも通る。そのままコミット――この一連の流れ、いわゆる「バイブコーディング」を、わたしも毎日のようにやっています。
でも、ここで一つ怖い事実があります。AIが書いたコードは「動く」かもしれませんが、「安全」かどうかは別の話です。ユーザー入力をそのまま eval() に渡していたり、パスワードを md5 でハッシュしていたり、外部URLを検証せず叩いていたり――こうした脆弱性は、コードが正常に動いている限り、表には出てきません。バグは動かなくなれば気づけますが、セキュリティの穴は静かに開いたままになります。
そして、雰囲気でコードを受け取っている書き手ほど、その穴を見抜けません。レビューしてくれる先輩もいない個人開発なら、なおさらです。
そんな「バイブコーダーの構造的な弱点」に、ちょうど公式が手を打ってきました。2026年5月27日、Anthropic が Claude Code 向けに security-guidance プラグインを無料公開したのです。とはいえ、公式が出したものでも「実際どこまで効くのか」は気になるところです。今回はこれを、機能紹介では終わらせず「本当にわたしたちの事故を減らせるのか?」という目線で、実際にわざと危険なコードを書かせて検証してみました。
このプラグインのコンセプトは一言でいうと「AIが書いたコードを、AI自身に見張らせる」です。導入は1行で終わります。
/plugin install security-guidance@claude-plugins-official
要件は Claude Code 2.1.144 以降と Python 3.8 以上だけ。全プラン無料です。
面白いのは、チェックを3つの違うタイミング・違うやり方で重ねている点です。空港のセキュリティに例えると、いちばん腑に落ちます。
| 層 | 例えると | いつ動くか | やり方 | コスト |
|---|---|---|---|---|
| Layer 1 | 入口の金属探知機 | 1行書いた瞬間 | 危険な単語を機械照合(AI不使用) | 無料 |
| Layer 2 | 手荷物を見る係員 | AIが返答を書き終えた時 | 変更差分をAIが読んで判断 | AI利用枠を少し消費 |
| Layer 3 | 出国前の捜査官 | git commit する時 | 周辺ファイルまで遡ってデータの流れを追う | AI利用枠を消費 |
なぜわざわざ3層に分けるのか。それは「速さ」と「賢さ」がトレードオフだからです。金属探知機(Layer 1)は一瞬で鳴りますが、決まった危険物しか見つけられません。捜査官(Layer 3)は賢く深掘りしますが、時間もお金もかかります。だから軽い網と賢い網を、書く瞬間・書き終わり・コミット時の3段に重ねて、すり抜けを減らしているわけです。
ちなみにこのプラグイン、常駐コストがほぼゼロです。仕組みが「フック」(Claudeの判断の外側で動く仕掛け)なので、毎回の会話のトークンを食いません。Layer 1 にいたってはAIすら呼ばないので完全無料。財布に優しい設計です。
ここからが本題です。セキュリティ製品は「実際に危ないものを通したとき、ちゃんと警報が鳴るか」を試さないと意味がありません。ここからは、どのように検証したかを具体的に共有します。そこで、まっさらなコードにわざと既知の脆弱パターンを書き足し、3層が鳴るかを観察しました。
仕込んだのは、eval()(任意コード実行)、os.system()(コマンドインジェクション)、pickle.loads() と yaml.load()(安全でないデシリアライズ)、requests.get(ユーザー入力のURL)(SSRF)、md5 でのパスワードハッシュ(弱い暗号)、認可チェックなしのレコード取得(IDOR)、そして innerHTML への代入(XSS)。盛り合わせです。
先に結論から言うと、3層すべてが鳴りました。順に見ていきます。
Layer 1(書いた瞬間・即時) ――投入した5つの危険な書き方を、編集直後にその場で指摘:
| 投入したコード | 検出 |
|---|---|
eval(user_input) | ✓ |
os.system(cmd) | ✓ |
pickle.loads(data) | ✓ |
yaml.load(f) | ✓ |
el.innerHTML = text | ✓ |
Layer 2(返答の書き終わり・約16秒) ――変更全体をAIがレビューし、high/critical を8件検出。それぞれに修正案(eval→ast.literal_eval、md5→bcrypt/argon2、innerHTML→textContent/DOMPurify など)まで付いてきました:
| ファイル | カテゴリ | 重大度 |
|---|---|---|
| app.py | 動的コード評価 (eval) | CRITICAL |
| app.py | コマンドインジェクション (os.system) | CRITICAL |
| app.py | 安全でないデシリアライズ (pickle) | CRITICAL |
| app.py | 安全でないデシリアライズ (yaml.load) | CRITICAL |
| app.py | SSRF | HIGH |
| app.py | 弱いパスワードハッシュ (md5) | HIGH |
| app.py | 認可不備 (IDOR) | HIGH |
| util.js | XSS (innerHTML) | HIGH |
Layer 3(commit時) ――Layer 2 とは独立してもう一度レビューが走り、同じ問題を「RCE(リモートコード実行)につながる」と、攻撃の影響度を強調する形で報告してきました。
結論として、3層すべてが期待どおり発火しました。バイブコーダーが気づかず通してしまいそうな穴を、書いた端からきちんと拾ってくれます。
ここはあえて正直に書きます。完璧ではありません。
まず、ハードコードされたAPIキーは、今回の検証では検出されませんでした。ただしこれには裏があって、わたしが使ったのが sk-FAKE-not-a-real-secret-000000 という、誰がどう見てもニセモノの文字列だったからです。プラグイン側が「これはダミーだ」と正しく判断して無視した、いわば過検知を抑える良い挙動とも言えます。逆に言うと、本物のシークレットを確実に検出できるかは今回は確認しきれていません(これは別途、現実的な形式のダミーで追試する予定です)。
もう一つ面白かったのが、ドキュメント(.md)を書いていると一部ルールが誤反応すること。この記事の下書き自体、本文中に書いた innerHTML や yaml.load( という文字列にLayer 1が反応しました。ルールごとに「ドキュメントは除外する」フィルタの整備度に差があるようです。実害はありませんが、セキュリティ記事を書く人は少しザワつくかもしれません。
公式も「これはベストエフォートの補助ツールであって、保証ではない」と明言しています。SASTやペネトレーションテストの代わりにはなりません。誤検知も取りこぼしもあり得ます。
導入のハードルは限りなく低いです。インストールして再起動すれば、あとは黙って動きます。設定は不要。初心者ほど恩恵が大きい設計です。
ただ、一点だけ意識しておくとよいのが「コードがどこに送られるか」です。Layer 2 / Layer 3 はAIにコードの差分を送ってレビューさせる仕組みなので、送信先 = ふだんの Claude Code の接続先になります。
ANTHROPIC_BASE_URL でそのゲートウェイに向きます。SECURITY_REVIEW_MODEL をプロバイダー固有のモデルID形式で指定する必要があります。また、.claude/claude-security-guidance.md を置くと「自社/自分のプロジェクト固有のセキュリティルール」を追加できますが、この中身は毎回レビューのプロンプトに添付されるので、シークレットは絶対に書かないこと。これは公式も注意している点です。
要らなくなったら SECURITY_GUIDANCE_DISABLE=1 で全停止、各層も個別にオフにできます。多エージェントで動かしている人向けの逃げ道もちゃんと用意されています。
正直、このプラグインだけでセキュリティが万全になるわけではありません。でも、AIに任せて雰囲気で書く人ほど、これを入れる価値があります。なぜなら、自分では気づけない eval や innerHTML を、書いた瞬間に「それ危ないよ」と教えてくれるから。0設定・無料・トークン消費ほぼゼロで手に入る「最初の防波堤」としては、十分すぎるくらいです。
公式が出した、というのも大きい。AIが書いたコードの安全性に、AIを作っている当事者が責任を持ち始めた――そういう流れの第一歩として見ても、入れて損のないプラグインでした。
もっと踏み込んで、検出した脆弱性の調査や修正提案まで自動化したい人は「
BlogWazuhとClaude Codeを繋いだら、CVE調査と修正提案が自動化できた【自宅ラボ セキュリティ実録 #3】Wazuh REST APIでCVEリストを取得し、Claude Codeに渡したら調査と修正コマンド生成が自動化できた。93件のCriticalを手動で追っていた状態からの脱出実録。→」も参考になります。今回のプラグインが「書いた瞬間の最初の網」だとすれば、そちらは「見つかった後の対応」を回す話で、ちょうど補完関係になります。
HW系エンジニアとして20年超・2000件超の単独SOL業務を経験。AI・ガジェット・自作PCを実際に触りながら「本当に使えるか」を試し続けています。META-MARK では GPU/CPU/AI ツールの実務評価と、プログラマティック SEO の実験を並行して走らせています。
(確認バージョン: security-guidance 2.0.0 / 確認日: 2026-05-28) この記事は Anthropic 公式発表(2026-05-27)および security-guidance 公式リポジトリ README(anthropics/claude-plugins-official)を一次ソースとして参照し、自環境での実機検証(Layer 1=機械照合で5件 / Layer 2=AIレビューで8件 / Layer 3=commit時に独立発火)をもとに執筆しています。
META-MARK × AI
ローカルAIを動かすGPU、ちゃんと選べていますか?
VRAM・性能・コスパをMetaScoreで数値化。AIアプリ別の推奨ハードウェア要件も確認できます。