Tech BlogAWSツール & 技術ブログ
メニュー

カテゴリ

AWS & AI ツール

タグ

AI24Claude Code23AWS12セキュリティ11Claude9効率化8開発ツール6プラグイン5S35CloudFront5Next.js4Opus 4.83すべて見る →

Claude公式のsecurity-guidanceプラグインが出た——自前ルールとの併用を考える

AIClaude Codeセキュリティプラグイン開発ツール

はじめに

公式プラグインを入れたあと、既存の自前ルールとどう棲み分けるかで混乱しがちです。本記事は、3 層構造を理解したうえでプロジェクト固有のルールをどこに書くかを整理し、重複によるコンテキストの無駄をなくすことを目的にしています。

Anthropic 公式の Claude Code 向けプラグインとして、security-guidance というセキュリティレビュー用プラグインが公開されました。

ざっくり言うと、別インスタンスの Claude が、Claude 自身が書いたコードをセキュリティ観点でレビューし、PR に到達する前に問題を直すためのプラグインです。

このブログでも OWASP ZAP の記事 や おすすめプラグインの記事 でセキュリティ周りには触れてきましたが、これまでは「公式に決まったセキュリティレビューの仕組みはない」状態でした。OSS のベストプラクティス集を参考に、自分の CLAUDE.md や .claude/rules/ に手書きでルールを並べて運用してきた人も多いと思います。私もその 1 人です。

今回、公式からまとめて出してきた以上、これは 全員が一度は入れて触っておくべき プラグインだと考えています。本記事では、その理由と、既存の自前ルールとの折り合いをどうつけるかを整理します。

なお、このブログのセキュリティ系記事は役割を分けて書いています。本記事は セッション内でのリアルタイム防御 に特化した内容で、OWASP ZAP の記事は デプロイ済みサイトに対する静的・動的診断、おすすめプラグインの記事は プラグイン選定全般 を扱っています。3 本は競合ではなく、書いている最中・コミット時・公開後という別々のタイミングを補い合う相補関係にあります。

これまで自前で何をやっていたか

私の ~/.claude/rules/ 以下には、company-security.md や company-implementation.md といったセキュリティ関連のルールが並んでいます。中身はざっくり以下のようなものです。

  • .env や認証キーを含むファイルを読み取らない・出力しない
  • API キー・パスワードをコードに直書きさせない
  • 個人情報（メール、電話、氏名）をマスキングする
  • SQL インジェクション対策にプレースホルダーを必ず使う
  • 危険な評価関数にユーザー入力を渡さない
  • 動的なスクリプト読み込み（信頼できない CDN）を禁止する

これらは、GitHub で公開されている OSS のセキュリティ向け Claude Code 設定や、社内で議論したルールを参考に少しずつ追加してきたものです。

これでも一定の効果はありました。 実際、Claude が生成したコードでハードコードされたシークレットが警告されたり、危険な DOM API を使った実装を書き換えてもらえたりしています。ただ、課題もありました。

自前ルールの課題 内容
カバー範囲が偏る 自分が知っているパターンしか書けない。CSRF・SSRF・安全でないデシリアライゼーションなど抜け漏れが出る
メンテナンスコスト 新しい攻撃手法やライブラリの脆弱性が出るたびにルールを追加する必要がある
レビュアーの独立性が弱い コードを書いた Claude と同じセッションで「自分のコードを点検して」と頼んでも、肯定的に見てしまうバイアスがある
編集ごとの即時チェックがない ガイドラインとして読まれるだけで、編集の瞬間に止める仕組みは別途フックが必要

特に「同じ Claude が自分のコードを点検する」という構造上の弱点は、自前ルールではどうにもなりませんでした。

security-guidance プラグインの何が違うか

公式ドキュメントを読むと、3 つのレイヤーが前述の自前ルールの課題（カバー範囲の偏り・編集ごとの即時チェックの欠如・レビュアーの独立性の弱さ）をそれぞれ別の角度から潰しに来ていることが分かります。機能の羅列ではなく、「自分の運用で何が解決するか」という順で見ていきます。

1. 編集ごとのパターンマッチ——「即時チェックがない」を埋める

自前ルールの課題のうち 編集ごとの即時チェックがない に直接効くのがこのレイヤーです。CLAUDE.md にルールを書いても、それはガイドラインとして読まれるだけで、編集の瞬間に止める力はありませんでした。

security-guidance では、Edit / Write / NotebookEdit で変更が入った直後に決定論的な文字列マッチが走ります。動的コード実行系の関数呼び出しや、安全でないデシリアライゼーション、DOM インジェクションを引き起こす API などの危険パターンを即座に検出し、警告を次のターンのコンテキストに乗せます。

これはモデル呼び出しを伴わないため コストがゼロ。自前のフックでやっていた「編集の瞬間に止める」役割を、追加費用なしで肩代わりしてくれます。

2. ターン終了時の diff レビュー——「カバー範囲の偏り」と「独立性の弱さ」を同時に潰す

自前ルールの課題テーブルで挙げた カバー範囲が偏る と レビュアーの独立性が弱い の 2 つに、まとめて効いてくるのがこのレイヤーです。

ターン（＝ Claude が一回応答するサイクル）が終わるたびに、その間に変更された全ファイルの git diff を 別の Claude インスタンス に渡してレビューさせます。レビュアーは元のアプローチへの投資がなく、「問題を見つけるだけ」の指示で動くので、独立した目線で diff を読みます。これがまさに、自前ルールでは構造上どうにもならなかった「同じ Claude が自分のコードを点検するとバイアスがかかる」問題への回答になっています。

そしてここでキャッチされるのは、自分が知っているパターンしか書けない自前ルールでは抜けがちな、以下のような領域です。

  • 認可バイパス
  • 安全でない直接オブジェクト参照（IDOR）
  • インジェクション全般
  • SSRF
  • 弱い暗号化の選択

私の自前ルールが一番カバーしきれていなかった領域がここで、特に SSRF・IDOR は文章で書いても Claude が見落としやすい部類です。別インスタンスにレビューさせる という設計が、カバー偏りと独立性の両方を一度に埋めてくれます。

3. コミット・プッシュ時の agentic レビュー——「独立性」をさらに深掘りする

レイヤー 2 と同じく レビュアーの独立性が弱い への対策ですが、こちらはより踏み込んだ精度を担います。Claude が Bash ツール経由で git commit や git push を実行した瞬間に、より深い agentic レビューが走ります。diff だけでなく、呼び出し元・サニタイザー・関連ファイルまで読みに行く ため、「単独で見ると危険だが、実際にはサニタイズ済みで安全」というケースで偽陽性を抑えられる作りです。

ローリング 1 時間あたり 20 回までという制限はありますが、コミット粒度のレビューが入るのは大きいです。今までは pre-commit フックで自前のチェックを走らせていましたが、内容に踏み込んだレビューは別途人間が必要でした。それを Claude 側で肩代わりしてくれる形になります。

既存セキュリティツールとの位置づけ

公式ドキュメントには、他のセキュリティツールとの棲み分けも明記されています。

ステージ ツール カバー範囲
セッション内 security-guidance プラグイン Claude が書くコードの一般的な脆弱性、同じセッション内で修正
オンデマンド /security-review 現在のブランチ全体への 1 回限りのパス
PR Code Review（Team / Enterprise） コードベース全体のコンテキストを持つマルチエージェントレビュー
CI 既存の SAST / 依存関係スキャナ 言語固有ルール、サプライチェーンチェック、ポリシー実装

プラグインは「PR や CI に到達するボリュームを減らす」役割であり、既存のレビューや CI を置き換えるものではない という整理がされている点が誠実です。これは現実的に正しく、私も pre-commit フック・OWASP ZAP・CI 上の依存関係スキャンを引き続き使い続ける前提で導入しています。

インストールと有効化

導入は非常にシンプルです。Claude Code 2.1.144 以降と Python 3.8 以降が必要です。

/plugin install security-guidance@claude-plugins-official
/reload-plugins

マーケットプレイスが見つからないと言われた場合は、先に /plugin marketplace add anthropics/claude-plugins-official を実行します。

チーム全体で有効化するなら、リポジトリの .claude/settings.json にチェックインしておきます。

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

このブログのリポジトリでも上記設定を入れて、リポジトリを開いたら自動的に有効になるようにしています。

導入後の効果確認の目安

入れたあと「ちゃんと動いているか」が分かりにくいので、初期段階で確認できる具体例を挙げておきます。読者が手元で試すなら、以下のような小さな変更を入れてみると、各レイヤーが反応するかどうかの目安になります。

  • DOM API への文字列の直接代入（例: 取得した値をそのまま innerHTML に入れる）を書いてみて、編集ごとのパターンマッチ警告が出るか
  • SQL を組み立てるコードで、文字列連結ではなくプレースホルダーが使われているかを diff レビューが見ているか
  • 環境変数やシークレットらしき値を含む変更をコミットしようとしたとき、コミット時のレビューが反応するか

なお、/plugin install 実行時に「マーケットプレイスが見つからない」と言われた場合は、先に /plugin marketplace add anthropics/claude-plugins-official を実行してから再度インストールしてください（この順序はインストール節でも触れています）。

自前ルールとの併用——どこまで残すか

ここからが本題で、すでに CLAUDE.md や .claude/rules/ にセキュリティルールを書き込んでいる人が悩むポイントです。

完全に削るのは早計

公式プラグインが入ったから、自前のセキュリティルールを全部消してしまえばいいかというと、そうではありません。プラグインがカバーするのは「一般的に脆弱性とされるパターン」であって、以下のような プロジェクト固有のルール は依然として自分で書く必要があります。

  • このプロジェクトでは customer_id を INFO レベル以上でログ出力しない
  • /admin 配下のルートでは必ず require_role("admin") を呼ぶ
  • マルチテナントコードは必ず org_id でフィルタする
  • 社内 API キーのプレフィックス（sk_live_, AKIA 等）をハードコードしない

これらは公式プラグインの汎用チェックでは引っかからないため、.claude/claude-security-guidance.md や .claude/security-patterns.yaml に書いておく価値があります。プラグイン側に 公式の拡張ポイント が用意されている点もポイントです。

重複するルールはコンテキストの無駄になりうる

一方で、危険な評価関数を使わない・DOM への直接代入を避ける・SQL はプレースホルダー、といった 公式プラグインが既にカバーしている内容 を自前ルールにも残しておくと、セッション開始時に同じ趣旨の情報が二重に読み込まれ、コンテキストを無駄に消費します。

/usage コマンドの記事 でも触れた通り、コンテキストは有限です。プラグインで自動的に注入される警告と、CLAUDE.md の常時読込ルールが重複していると、その分だけ実装やレビューに使えるコンテキストが削られます。

取捨選択は Claude 自身にやらせるのも手

ではどこまで削るか。これを人力で判断するのは地味に大変です。自分で書いたルールへの思い入れもあり、「念のため残しておくか」となりがちです。

実は これは Claude にやらせるのが一番速い と感じています。以下のようなプロンプトでセッションを 1 回回すと、かなり機械的に整理できます。

@~/.claude/rules/company-security.md と
@~/.claude/rules/company-implementation.md を読んで、
公式の security-guidance プラグインが自動でカバーする内容と
重複しているルールを抽出してください。

重複しているものは「プラグインが自動でやるので削除候補」、
プロジェクト固有で残すべきものは「保持」と分類して、
表で出してください。

私が試したところ、自前ルールのうち以下のような項目は「プラグインで自動カバー、削除候補」と判定されました。

  • 危険な評価関数にユーザー入力を渡さない（→ 編集ごとパターン）
  • 動的スクリプト読み込みの禁止（→ ターン終了レビュー）
  • 安全でないデシリアライゼーション（→ 編集ごとパターン）

逆に以下は「プロジェクト固有・保持」と判定されました。

  • .env / config/secrets.* を読み取らない（プラグインはコードの脆弱性レビュー対象であり、Claude のファイルアクセス制御は別レイヤー）
  • 個人情報のマスキング方針（プロジェクトポリシー）
  • セキュリティ変更時の人間レビュー必須化（運用ルール）
  • AWS IAM 最小権限の原則（クラウド設定のポリシー）

これは厳密な正解というより、Claude による一次仕分けの結果を人間が最終判断する という運用です。重複削減を完全に手作業でやると後回しになりがちなので、AI に下書きさせるのが現実的だと思います。

入れない選択はないと思う理由

最後に、なぜ「全員入れた方が良い」と書いたかを補足しておきます。

  1. MCP 周辺の脆弱性公表があった：少し前にも、MCP プロトコルレベルでのゼロクリック プロンプトインジェクション経由の RCE 可能性が話題になりました。AI コーディング環境そのものが攻撃面になりつつある現在、公式が出してくる防御策に対しては とりあえず入れるが正解 になりやすいです。
  2. 編集ごとのチェックはコストゼロ：3 レイヤーのうち、最低でもパターンマッチレイヤーは追加コストなしで動きます。ENABLE_STOP_REVIEW=0 などで一部を切れば、コストを抑えながら導入可能です。
  3. 既存ルールを残したままでも併用できる：プラグインの拡張ポイント（claude-security-guidance.md / security-patterns.yaml）はプロジェクト固有ルールを足し算する設計で、既存ルールが「全部消えてしまう」ような壊し方をしない作りになっています。
  4. 依存はパスを通すだけ：Python 3.8 以上と git さえあれば動き、内部で ~/.claude/security/ に venv を作るので、グローバル環境を汚しません。

要するに、入れて損する要素がほぼなく、入れないと自前ルールでは届かないレイヤーで取りこぼしが出続ける という構造です。

このブログでの導入結果

このブログのリポジトリでもセッション内で有効化して何往復か触ってみました。記事生成中心のリポジトリなので脆弱性が大量に検出されるわけではありませんが、以下のような気づきがありました。

  • Cloudflare Pages 用の _headers ファイル更新時に、CSP の unsafe-inline 指定について警告が出た（既知の妥協だが、明示的に「意図的に許可している」とコメントを入れることになった）
  • ツール群（tools/ 配下の TSX）で、ユーザー入力をそのまま危険な DOM API へ流し込もうとした初稿で警告が出て、書き換えになった
  • コミット時のレビューで、ビルドスクリプトの環境変数読み込みについて「シークレット扱いになる値ではないか」という指摘が入った（実際にはビルド情報だけだったので注釈追加で対応）

「いきなり致命的な脆弱性が見つかる」ことはなくても、コード上の小さな曖昧さに対して指摘が入り、明示化が進む という効き方をしてくれます。

技術的な補足として、security-guidance はローカル（~/.claude/security/ の venv）で動作し、ホスティング先には非依存です。レビュー対象は手元の git diff やファイル編集なので、このブログのような Cloudflare Pages 構成でもセッション内の検査は同様に機能します。

まとめ

  • Anthropic 公式から Claude Code 向けの security-guidance プラグイン が出た
  • 編集ごとのパターンマッチ・ターン終了時の diff レビュー・コミット時の agentic レビューの 3 層構成で、別インスタンスがコードをレビューする という設計が肝
  • 自前のセキュリティルールを全消しする必要はなく、プロジェクト固有のルールは .claude/claude-security-guidance.md などに残して併用するのが現実的
  • 重複ルールは Claude 自身に仕分けさせると効率的
  • MCP まわりの脆弱性公表もあり、公式が出してきた防御策を入れない選択肢はほぼない

普段から CLAUDE.md でセキュリティに気を配っている人ほど、「自前ルールが時代遅れになっていないか」を見直す良いタイミングです。一度ドキュメントに目を通して、まずはインストールから試してみてください。

関連記事

← 記事一覧に戻る