security-audit-skill は、Cloudflareが公開した コーディングエージェントを「セキュリティ監査人」に変える オープンソースのスキルです。 Claude Codeのような（ツール使用・並列サブエージェントに対応した）エージェントに読み込ませると、コードベースから 「実際に悪用できる脆弱性」だけ を発見します。 リポジトリの説明は「A coding-agent skill that turns your agent into a security auditor（エージェントをセキュリティ監査人に変えるスキル）」。ライセンスは MIT で、Cloudflareが社内で使う脆弱性発見ハーネス（ブログ「Build your own vulnerability harness」由来）を、誰でも自分のコードベースに適用できる形に整えて公開したものです。
従来の自動スキャンは「理論上は危ないかも」という警告を大量に出し、その多くが誤検知でした。 このスキルは 「悪用できるものだけ報告する（Only report what you can exploit）」 を原則に掲げ、誤検知を敵対的に削り込みます。 本稿は 2026年6月25日（JST）時点 で、公式GitHubリポジトリ（cloudflare/security-audit-skill）をもとに、仕組み・導入・使い方・注意点を整理します。
そもそも「Claude Skills（スキル）」の仕組みは Claude Skillsを徹底解説｜スキルはフォルダ——Anthropicエンジニアが明かした仕組みと使い方 をご覧ください。
- ・Cloudflare製のOSSスキル（MIT）。コーディングエージェントを“セキュリティ監査人”に変える。
- ・6フェーズ（偵察→攻撃→検証→報告→構造化→独立検証）で監査を進める。
- ・原則は「実際に悪用できるものだけ報告」。各発見に具体的な攻撃シナリオを要求。
- ・多段の敵対的検証（反証＋独立再確認）で誤検知を機械的に排除。
- ・
npx skills addで導入し、「security audit this codebase」で起動。
1. security-audit-skillとは — 監査の「型」をスキルにする
AIエージェントにセキュリティ作業をさせる試みは増えていますが、素朴に「脆弱性を探して」と頼むと、それっぽいが当てにならない指摘 が大量に返ってくるのが常でした。 本物と誤検知が混ざり、結局人間が選り分ける羽目になります。 しかも、セキュリティの専門知識がなければ、返ってきた指摘が本当に危険なのかどうかの判断すら難しい——ここがAIにセキュリティを任せる難しさでした。
security-audit-skillは、この問題を 「監査のプロセスを型（スキル）として与える」 ことで解きます。 場当たり的に探させるのではなく、偵察→攻撃→検証→報告→構造化→独立検証 という、人間のセキュリティ監査に近い手順を踏ませるのです。
中心にあるのは、たった一つの厳しい原則です。
「悪用できるものだけ報告する。すべての発見には、具体的な攻撃シナリオが必要」
理論上のリスクではなく、実際に攻撃が成立すること を発見の条件にする。 この一線を引くことで、出力が「対応すべき本物」に絞り込まれ、しかも各発見が“なぜ危険か”を攻撃シナリオ付きで説明してくれるため、専門知識が浅い開発者でも危険度を理解しやすくなります。 セキュリティ担当者の時間は有限です。 100件の「かもしれない」より、5件の「確かに突ける」のほうが、現場にとってはるかに価値がある——この実務感覚が、設計の根っこにあります。 Cloudflareが自社の脆弱性発見に使ってきたハーネスの考え方を、MITライセンスのOSSスキルとして公開した——それがこのプロジェクトです。
ここで「スキル（skill）」という形態の意味を補足します。 近年のコーディングエージェントは、特定領域の手順や知識を「スキル」としてフォルダ単位で読み込み、その領域の専門家のように振る舞えるようになりました。 security-audit-skillは、この仕組みを使って 「セキュリティ監査の段取りと判断基準」をエージェントに注入 します。 ポイントは、これが特定のSaaSや独自ツールではなく、手元のエージェント（Claude Code等）の中でそのまま動く ことです。 新しいツールの使い方を覚える必要はなく、普段のワークフローに「監査人の脳」を足す感覚で導入できます。 そして中身はOSS（MIT）なので、何をどう監査しているのかを自分で読んで検証・改変できる ——ブラックボックスのスキャナとは対照的な透明性も、セキュリティツールとしては重要な美点です。
2. 6フェーズのパイプライン
監査は6つの段階で進みます。 全体像を図にすると次のようになります。
並列エージェントがアーキテクチャと入力面を把握"] --> B["② Hunt（攻撃）
注入/アクセス制御/ロジック/暗号/機能悪用/連鎖を多角的に攻める"] B --> C["③ Validate（検証）
別エージェントが発見を“反証”し誤検知を排除"] C --> D["④ Report（報告）
人間が読めるドキュメントを生成"] D --> E["⑤ Structured Output
スキーマ検証済みJSONで出力"] E --> F["⑥ Independent Verification（独立検証）
新しいエージェントがソースコードで主張を再確認"] F --> G["対応すべき“本物の発見”だけが残る"]
各フェーズを補足します。
・① Recon（偵察）：まず攻撃対象を理解する。並列エージェントがアーキテクチャと「入力が入ってくる面（attack surface）」を洗い出す
・② Hunt（攻撃）：注入（injection）、アクセス制御、ビジネスロジック、暗号、機能の悪用、複数を組み合わせた連鎖攻撃など、多角的に攻める
・③ Validate（検証）：発見をそのまま信じない。別のエージェントが“反証”を試み、崩せたものは誤検知として捨てる
・④ Report（報告）：残った発見を、人間が読めるドキュメントにまとめる
・⑤ Structured Output：機械処理用に、スキーマ検証済みのJSON で構造化して出力する
・⑥ Independent Verification（独立検証）：最後に、まっさらな別エージェント がソースコードに照らして主張を再確認する。前段の文脈に引きずられない“新鮮な目”が、思い込みの混入を最後に防ぐ
この流れの肝は、「攻める役」と「疑う役」を分けている ことです。 見つける段階（Hunt）と、それを潰しにかかる段階（Validate / Independent Verification）を別エージェントに担わせることで、自分の発見に都合よく甘くなる“身内びいき”を防ぎます。
特に注目したいのが ②Hunt の網羅性 です。 脆弱性は一種類ではありません。 SQLインジェクションのような「注入」系、権限のない操作ができてしまう「アクセス制御」系、値引きや在庫を不正に操作できる「ビジネスロジック」系、鍵やハッシュの誤用といった「暗号」系、想定外の使い方でシステムを壊す「機能悪用」系——そして、それぞれ単体では軽微でも 組み合わせると重大になる「連鎖攻撃」 まで。 security-audit-skillは、これらを別々の観点として明示的に攻めさせます。 人間が一人で監査すると、自分の得意分野に偏りがちですが、観点を分けて並列に攻めさせることで 死角を減らす わけです。
そして⑤の スキーマ検証済みJSON は、地味ですが実務で効きます。 発見が決まった形式（重大度・攻撃シナリオ・該当ファイル/行・検証済みフラグ等）で出力されるため、人間が読むだけでなく、チケット起票やCIのゲート、他ツールへの連携を自動化 できます。 「AIが文章で報告して終わり」ではなく、機械処理可能な成果物にしているのが、実運用ハーネス由来らしい設計です。
3. なぜ「敵対的検証」で誤検知が減るのか
自動セキュリティツールの最大の弱点は、誤検知（false positive） です。 「ここにSQLインジェクションの“可能性”があります」といった警告が何百件も出るが、実際に悪用できるのはごく一部——そんな経験をした人は多いはずです。 ノイズが多いと、担当者は警告を信用しなくなり、本物まで見逃します（いわゆる“アラート疲れ”）。
security-audit-skillは、この問題を 敵対的検証（adversarial validation） で攻めます。 発見を「正しい」と仮定して進めるのではなく、わざわざ別のエージェントに「これは間違っている」と証明させにいく のです。
複数のエージェントが「攻める」「疑う」「再確認する」と役割を分担することで、一人のレビュアーが陥りがちな思い込みや見落としを、仕組みとして相殺 します。 これは、人間のセキュリティチームが「発見者」と「レビュアー」を分けるのと同じ発想を、エージェントの編成として実装したものだといえます。
なぜ「悪用できる」を条件にすると誤検知が減るのか、もう少し掘り下げます。 誤検知の多くは「コードの形だけ見て危険そうだと判断する」ことから生まれます。 たとえば文字列連結でSQLを組み立てている箇所を見ると、自動ツールは反射的に「SQLインジェクションの可能性」と警告します。 しかし、その値が実は内部で固定されていたり、上流で厳格にバリデーションされていたりすれば、実際には攻撃が成立しません。 「悪用できることを実証せよ」という条件は、エージェントに 「形」ではなく「経路」を追わせます。 入力がどこから入り、どう流れ、本当に危険な地点まで到達するのか——その具体的な攻撃経路を構築できて初めて“発見”とみなす。 だから、形だけ怪しいが実際には無害なコードは、検証段階で振り落とされます。 これは人間の優れたセキュリティエンジニアが頭の中でやっていることを、明示的なプロセスとして外在化したものだといえます。
4. 導入と使い方
導入はSkills CLIで行います。
# Skills CLI でスキルを追加
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
導入後は、普段使っているコーディングエージェントの中で、自然言語で起動します。
このコードベースをセキュリティ監査して
（または: "security audit this codebase"）
要件は次のとおりです。
・ツール使用と並列サブエージェントに対応したコーディングエージェント（Claude Code等）
・Node.js（スキーマ検証に使用）
専用のGUIやSaaSではなく、エージェントのワークフローに溶け込む のがこのスキルの形です。 出力は、人間向けのレポートに加えて スキーマ検証済みのJSON も得られるため、CIや他のツールに繋ぎ込んで自動化することもできます。プルリクエストごとに自動で監査を回し、重大な発見があればマージをブロックする、といった運用も設計できます。
要件にある「並列サブエージェントへの対応」は、このスキルが力を発揮するための前提です。 6フェーズの監査は、偵察で複数の入力面を同時に調べたり、攻撃で複数の観点を並行して試したり、検証で発見ごとに反証役を立てたりと、多数のエージェントを同時に走らせる ことで成立します。 逆に言えば、単一スレッドでしか動けない簡易なエージェントでは、本来の網羅性や検証の厳密さが出にくい、ということです。 Claude Codeのように、ツール使用とサブエージェントの並列実行に対応した環境で使うのが前提になります。 また、Node.jsが要件に含まれるのは、出力JSONを スキーマに照らして機械的に検証する ためで、これによって「形式が壊れたAIの出力」を弾き、後段の自動処理を安定させています。
// 構造化出力（JSON findings）のイメージ
{
"title": "Authenticated SQL injection in /api/orders filter",
"severity": "high",
"exploit_scenario": "manager ロールのトークンで status= に '; ... を注入し…",
"evidence": { "file": "src/api/orders.ts", "line": 142 },
"verified": true
}
※ コマンド・スキル名・出力スキーマはバージョンで変わるため、最新は公式リポジトリのREADMEを確認してください。
5. 位置づけ — AI×セキュリティの潮流の中で
security-audit-skillは、2026年に加速している 「AIエージェントにセキュリティ作業をさせる」 潮流の一例です。 本サイトでも、Claude Code向けの攻撃セキュリティ専門サブエージェント群を扱った pentest-ai-agents｜Claude Code向け35の攻撃セキュリティ専門サブエージェント解剖 を紹介してきました。 攻撃側（赤チーム）と防御・監査側（青チーム）の両方で、AIエージェントの活用が一気に進んでいるのが2026年の景色です。
両者は近いですが、力点が違います。
| 観点 | security-audit-skill（Cloudflare） | pentest系サブエージェント群 |
|---|---|---|
| 形態 | 1つのスキル（6フェーズのパイプライン） | 多数の専門サブエージェント |
| 力点 | 悪用可能性の実証＋誤検知の排除 | 攻撃の専門性・網羅性 |
| 出力 | レポート＋スキーマ検証済みJSON | 各エージェントの所見 |
| 由来 | Cloudflareの実運用ハーネス | コミュニティのエージェント集 |
| ライセンス | MIT（OSS） | OSS |
security-audit-skillの個性は、「監査プロセス全体を構造化し、特に“本物だけを残す”ことに振り切った」 点にあります。 攻撃の網羅性を競うより、ノイズを削って対応の優先度を明確にする ——実運用で効くのはこの“絞り込み”だ、というCloudflareの実戦知見が反映されています。
この「Cloudflareの実運用ハーネス由来」という出自は、信頼性の面で大きな意味を持ちます。 Cloudflareはインターネットの広範なトラフィックを支える企業であり、自社製品のセキュリティに強い動機と高い基準を持っています。 そこで実際に脆弱性を見つけるために使われてきた仕組みが土台になっている、という事実は、机上で設計されたツールとは重みが違います。 それをMITライセンスで公開し、誰もが自分のコードベースに適用できるようにしたこと自体が、AIセキュリティの民主化という観点で意義深い動きだといえます。
供給網（サプライチェーン）まで含めた防御の全体像は サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト も合わせて参照すると、こうした監査ツールの位置づけが立体的に見えてきます。
6. 注意点と限界
強力ですが、万能ではありません。
・防御目的に限る：自分（自社）の、許可されたコードベースの監査に使う。他者のシステムへの無断使用は不可
・コスト：多数の並列サブエージェントを動かすため、トークン消費が大きい。対象範囲を絞って使う
・最終判断は人間：「悪用できる」と主張されても、修正の優先度や妥当性は人間がレビューする
・機密性：機密コードを扱う場合、使用するLLM／エージェントのデータ取り扱いを確認する
・保証ではない：監査の“補助”であり、これだけでセキュリティを保証するものではない。既存のレビュー・テスト・WAF等と多層で組み合わせる
・カバレッジの限界：見つかったものは本物に近いが、「見つからなかった＝安全」ではない
・プロンプトインジェクション耐性：監査対象のコードやデータに悪意ある指示が埋まっている可能性も念頭に置く
security-audit-skillの理想的な使い所は、人間のセキュリティレビューの前段だ。エージェントに広く深く当てさせ、誤検知を削った“本物候補”を作らせる。人間はその精度の高いリストを起点にレビューする。ゼロから探すより圧倒的に速く、かつアラート疲れを避けられる。あくまで人間を置き換えるのではなく、人間の集中を最も価値ある所へ向けるための道具だ。とりわけ、専任のセキュリティ担当を置けない小規模チームにとっては、レビューの質を底上げする現実的な手段になる。リリース前のチェックに組み込んでおけば、見落としを減らしつつ、開発の速度を大きく落とさずに済む。
まとめ
security-audit-skillは、コーディングエージェントを「セキュリティ監査人」に変え、“実際に悪用できる脆弱性”だけを発見させる CloudflareのOSSスキル（MIT）です。
要点を整理すると次のようになります。
・偵察→攻撃→検証→報告→構造化→独立検証の6フェーズで監査を進める
・原則は「悪用できるものだけ報告」。各発見に具体的な攻撃シナリオを要求
・「攻める役」と「疑う役」を分け、敵対的検証で誤検知を機械的に排除
・npx skills add で導入し、「security audit this codebase」のような自然言語で起動
・出力はレポート＋スキーマ検証済みJSON。CIや自動化にも繋げられる
このスキルの本質は「ノイズを消す監査」だ。AIに脆弱性を“探させる”のは簡単だが、価値があるのは“本物だけを残す”こと。Cloudflareは、攻める役と疑う役を分けた多段の敵対的検証で、それを仕組みにした。人間のセキュリティレビューを置き換えるのではなく、その前さばきとして使い、精度の高い候補リストから人間が判断する——これが最も効く使い方だ。MITで公開されているので、まずは自分のリポジトリの一部に範囲を絞って小さく試し、出力JSONの精度とコスト感をつかんでから本格運用に広げるのが堅実だ。
参照ソース
・cloudflare/security-audit-skill（公式GitHubリポジトリ）
・Build your own vulnerability harness（Cloudflareブログ・由来）
・Agent Skills（Anthropic・スキルの仕組み）
・Claude Skillsを徹底解説｜スキルはフォルダ（本サイト・ピラー）
