AIコード監査にsecurity-audit-skillが選ばれる理由

コーディングエージェントにセキュリティ監査をやらせる選択肢は、この1年で一気に増えました。ただ、導入を検討する側が本当に知りたいのは「見つけてくれるかどうか」ではありません。返ってきた指摘を人間が仕分ける工数が、どのくらいかかるのかです。

「脆弱性らしきもの」を100件出されても、そのうち本当に信頼境界を越えているものがどれかを人が判断し直すのであれば、監査を自動化した意味は薄れます。むしろ、レビュー待ちのキューが増えただけ、という結果にもなりかねません。LLM による検出は再現性が低く、同じコードベースでも実行のたびに結果が変わります。この性質が、SAST ツールの延長線上で評価しようとしたときに噛み合わない原因になります。

Cloudflare が公開した security-audit-skill は、この点に正面から設計で答えようとしたリポジトリです。監査ワークフローは6つのフェーズで構成されていますが、脆弱性を「探す」ことに使われるのは最初の2つだけで、残りの4つは候補を潰し、根拠を検証し、確証が持てないものを別枠に退避させるために費やされます。そして、そのワークフローは Cloudflare が社内で運用する脆弱性発見ハーネスの原型でもあります。

本記事では、公式リポジトリの README と SKILL.md、および Cloudflare の公式ブログをもとに、6フェーズの監査フローの構造、誤検知を抑えるための設計原則、導入前に満たす必要がある前提条件、そして類似 OSS との使い分けを整理します。なお本記事は公開ドキュメントとリポジトリのメタデータに基づく解説であり、インストールや実行による動作確認は行っていません。記載内容はすべて一次資料の記述に基づきます。

security-audit-skillとは｜Cloudflareの脆弱性ハーネスの原型

リポジトリの基本情報

security-audit-skill は、Cloudflare が公開しているコーディングエージェント向けのスキルです。リポジトリの説明文では「独立して検証された機械可読な findings を伴う、多段セキュリティ監査のためのコーディングエージェントスキル」と定義されています（cloudflare/security-audit-skill）。

※ 上記は 2026年10月4日時点に GitHub API で取得した値です。

ここで名称を整理しておきます。リポジトリ名は security-audit-skill ですが、その中に収められているスキル自体の名前は security-audit です。後述するインストールコマンドで指定する --skill の値も security-audit であり、リポジトリ名とは一致しません。リポジトリのトップレベルには LICENSE と README.md、そして skills/ ディレクトリしかなく、スキルの実体は skills/security-audit/ の配下にまとまっています。

ライセンスは MIT です。商用プロジェクトへの組み込みや、自社の監査基準に合わせた改変が許容されます。監査ワークフローを自前で調整したい場合に、ライセンス面の制約が少ない点は実務上の判断材料になります。

Cloudflareの脆弱性発見ハーネスとの関係

このリポジトリを評価するうえで外せないのが、Cloudflare 社内システムとの関係です。公式ブログ「Build your own vulnerability harness」では、同社がエンタープライズ規模のコードベースを横断して脆弱性を発見・検証する自動システムを構築したことが報告されています（Cloudflare Blog）。

このシステムは2段構成で、脆弱性発見ハーネス（VDH）が Recon / Hunt / Validate / Gapfill / Dedup / Trace / Feedback / Report の8フェーズを、脆弱性検証システム（VVS）が Dedup / Judgment / Fixing の3フェーズを担当します。VVS は VDH とは別のモデルで独立したトリアージを行い、本番環境への到達性の判定やパッチ生成までを担います。

同ブログには、このハーネスを開発する際に使った初期のスキルを整理したうえで公開した、という記述があります。つまり GitHub で公開されている security-audit-skill は、全社展開されたハーネス本体ではなく、その出発点となった単一リポジトリ版の原型です。README でも、ハーネスが多段・全社規模のシステムへ成長したのに対し、本スキルは単一リポジトリを対象とする版である旨が示されています。

この区別は重要です。「Cloudflare が実運用しているシステムがそのまま手に入る」と受け取ると期待値がずれます。一方で、実運用まで育ったシステムのアーキテクチャにほぼ直接対応する設計が、整理されたリファレンス実装として読める点には価値があります。フェーズ数こそハーネスの8に対してスキルは6ですが、探索と検証を分離するという骨格は共通しています。

6フェーズの監査フローと3つの判定

探す2フェーズと、潰す4フェーズ

README に記載されている監査ワークフローは、以下の6フェーズで構成されます。隔離された複数のエージェントを、親エージェントがオーケストレーションする形です。

6つのうち、脆弱性の候補を新しく見つけに行くのは最初の2つだけです。残りの4フェーズは、挙がった候補を絞り込み、根拠を突き合わせ、確証が取れないものを別の扱いに回すことに使われています。「AI が見つけた」と言わせないための工程に、ワークフローの3分の2が割かれている構造だと読み取れます。

この配分が、冒頭で挙げた「誤検知の仕分け工数」という懸念に対する答えになっています。排除の工程をワークフロー側に押し込むことで、人間の手元に届く段階での仕分け量を減らす設計です。

confirmed / needs_validation / rejected の3判定

構造化出力のフェーズでは、各候補に3種類のいずれかの判定（verdict）が付きます。定義は README に明記されています。

注目すべきは needs_validation の扱いです。この判定が付いた項目には重大度が付与されません。確証が取れていない候補に「Critical」「High」といったラベルが付くと、受け取る側はその表示に引きずられて優先順位を決めてしまいます。重大度を付けないという一行のルールが、グレーな候補を赤い警告として扱わせないための歯止めになっています。

また rejected を捨てずに記録として残す点も特徴です。反証された候補の履歴が残るため、同一リポジトリに繰り返し監査をかける際、過去に潰した候補を再び追いかける無駄を避けられます。

成果物とスキーマ検証

監査の出力は、人が読むレポートと機械が読むデータの両方に分かれています。

• architecture.md — アーキテクチャと信頼境界のマッピング
• coverage-ledger.json — どの範囲を見たかを記録する台帳
• findings.json — 3判定すべてを含む構造化レコード
• REPORT.md / FINDINGS-DETAIL.md / NEEDS-VALIDATION.md — レポート群

findings.json は report-schema.json で定義された JSON スキーマに照らして検証されます。検証を担うのは validate-findings.cjs と validate-coverage-ledger.cjs という2つのバリデータで、いずれもゼロ依存で実装されています。親エージェントは台帳の作成後と更新のたびに台帳バリデータを、構造化出力フェーズと独立検証フェーズでの差し替えのたびに findings バリデータを実行します。フェーズ3以降の詳細な手順は VALIDATION-AND-REPORTING.md に記述されています。

機械可読な出力がスキーマ検証付きで得られることは、監査結果を既存のチケット管理やダッシュボードへ流し込みたい場合に効いてきます。レポートが Markdown だけであれば、解析の手間がそのまま運用コストになります。

AIコード監査の誤検知を抑える設計原則

先ほど見たフローが「構造」だとすれば、ここで扱うのは「判断基準」です。README の Design principles と SKILL.md の中核原則には、AI の自己申告を信用しないための具体的なルールが並んでいます。

発見したエージェントは検証しない

もっとも明快なのが、敵対的検証（adversarial validation）の原則です。README には「発見を検証するエージェントは、発見したエージェントと決して同一にしない」と記載されています。

同一のエージェントに「自分の見つけた脆弱性が本物か確認せよ」と指示すると、直前の文脈に引きずられて肯定的な結論に傾きます。そこで候補検証フェーズでは、候補を反証しようとする新規のエージェントへ渡します。さらに独立レコード検証フェーズでは、また別の新しいエージェントが最終的なソース主張を確認し、実質的な差し替えが生じた場合にはさらに別の独立検証者が付きます。検証を二段構えにし、かつ毎回文脈を切り離した状態から始めるという構成です。

「境界を越えた」と言えなければconfirmedにしない

confirmed に上げるためのバーも明示されています。SKILL.md の中核原則では、候補ごとに以下を明示することが求められます。

• より低い信頼レベルの主体
• 受け入れられる入力・操作
• 意図された制御
• 越えられた境界
• 影響を受ける主体・リソース
• 具体的に観測された（またはオーナーが観測しうる）結果

そのうえで、ベストプラクティスの欠如、推測されたデプロイ挙動、一般的なパーサクラッシュ、自己影響の4つを、セキュリティ上の発見へ格上げしてはならないと定めています。

関連して、重大度の判定基準も「チェックリストからの逸脱ではなく、発生可能性 × 影響」と規定されています。さらに多層防御のギャップについては、「レイヤ A が攻撃を防いでいるなら、レイヤ B の欠如はハードニングノートであって脆弱性ではない」という線引きが示されています。

この3つのルールは、AI によるコード監査でノイズが膨らむ典型的なパターンをそれぞれ塞いでいます。チェックリスト照合で機械的に警告を積む、防御層が別にあるのに個別の欠如を脆弱性として報告する、攻撃者の存在を仮定せずに「理論上は危険」と述べる、といった出力が confirmed に混ざらないようにする設計だと読み取れます。ハンティング手法と検証ルールの詳細は HUNTING.md にまとめられています。

カバレッジ台帳が「見ていない範囲」を残す

誤検知と並ぶもう一方の問題が、見落としです。このワークフローは coverage-ledger.json という台帳で、どの範囲を見てどの範囲を見ていないかを記録し続けます。

README には、複数回の実行が加算的（additive）であることが明記されています。過去の台帳と findings を参照してギャップを狙い、変更されたソースを再検証し、現行ソースに基づく証拠を引き継ぐ一方で、古い作業や未解決の作業を「カバー済み」として扱いません。

この前提を裏付ける数字として、README には次の記述があります。テスト実行において、1回の実行で見つかった脆弱性は、繰り返し実行して合計で見つかった脆弱性のおよそ半分だった、というものです。1回走らせて終わりにする運用では、半分を取りこぼす想定で考える必要があります。

ここは導入判断に直結します。1回の実行で網羅性を期待するツールではなく、台帳を育てながら複数回かけて範囲を広げていく運用を前提とした設計です。そのぶんエージェント呼び出しのコストも積み上がるため、次の章で触れる予算の考え方とセットで検討することになります。

security-audit-skill導入前に確認すべき前提条件

ここまでの内容に魅力を感じたとしても、すぐに入れられるとは限りません。README の Requirements と SKILL.md の実行安全性の節には、導入可否の分かれ目になる条件が並んでいます。

2つの動作モード

まず押さえておきたいのは、スキルを読み込んだだけでは監査が始まらない点です。SKILL.md では動作モードが2つ定義されています。

• guidance mode（既定） — スキルを読み込んだ状態の初期モード。完全な監査ワークフローの開始やファイル作成は認可されません。セキュリティに関する質問や、限定的な脆弱性調査への回答に使われます。
• full audit mode — ユーザーが明示的に「監査してほしい」「ペンテストしてほしい」「フル／包括的／エンドツーエンドのレビューがほしい」「レポート成果物がほしい」と依頼したときにのみ入るモードです。

どちらとも取れる依頼の場合は、ファイル作成やワークフロー開始の前に確認質問を1つだけ行う、と規定されています。「スキルを入れた瞬間に勝手に全走査が始まるのではないか」という懸念に対しては、既定が guidance mode である点が答えになります。

なお full audit mode で出力先を指定しなかった場合、既定の出力先は ~/security-audit-skill/<repo-name>/run-<N> です。対象リポジトリの内部に書き込むのは、バージョン管理が無視するディレクトリを明示的に選んだ場合に限られます。

OS強制サンドボックスという最大のハードル

導入上、もっとも高い壁になりやすいのがここです。ソースコードの検査自体は読み取り専用で行われますが、ターゲット由来のビルド・テスト・プロセス・ブラウザ・エミュレータ・ファザー・フィクスチャを実行する場合には、以下をすべて備えた OS 強制サンドボックスが要求されます。

• 外部ネットワークなし（ローカルの client/server 通信が必要なときのみ、隔離されたループバック名前空間を使用）
• 許可リストから明示的に組み立てた空の環境。HOME・一時ディレクトリ・キャッシュは scratch ローカル
• 読み取り専用のターゲットとツールチェーン。ターゲット由来のプロセスが書き込めるのは割り当てられた scratch/ のみ
• CPU・メモリ・プロセス数・ファイルサイズ・ディスク・実時間に対する明示的で低い上限

あわせて、依存関係のインストールも、ビルドによる取得も禁止されています。ローカルに既に存在するツールと依存のみを使う前提です。デプロイ済みエンドポイント・外部サービス・共有インフラ・本番 ID・他ユーザーのデータ・ライブのコントロールプレーンへの探索も禁じられています。

満たせない場合の挙動まで定められている点は押さえておく価値があります。これらの制御をすべて強制できない場合、ワークフローはターゲットコードを実行せず、欠けているサンドボックス機能を needs-validation のブロッカーとして報告し、安全な検証計画を提示します。README の Requirements にも、これらの制御がない場合にリードを confirmed へ上げず needs_validation のまま保持する旨が記載されています。

つまり、サンドボックスを用意できない環境でも動かないわけではありませんが、動的な確認を伴う候補は confirmed に到達しません。結果として needs_validation が積み上がり、人間が検証する項目が増えます。サンドボックス整備の工数を先に見積もっておかないと、期待した自動化効果が得られない構図です。

このほかの要件として、ゼロ依存バリデータの実行に Node.js が必要であること、そしてツール使用と並列サブエージェントをサポートするモデルを備えたコーディングエージェントが必要であることが挙げられています。並列サブエージェントは、隔離されたハンターと検証者を独立に動かすという設計の根幹に関わるため、ここを満たせないエージェントでは本来の構成を再現できません。

プロファイルとコスト予算の考え方

LLM エージェントの運用で読みにくいのがコストです。SKILL.md では、この点にも規定が置かれています。

まず実行プロファイルが3種類あり、既定は standard です。

重要なのは、プロファイルが変えるのは広さと冗長性だけで、証拠のバーは変わらないと明記されている点です。quick を選んでも confirmed の基準が緩むわけではありません。

特定のパスや単一サブシステムに絞ったスコープ付き実行では、スコープ外は covered ではなく out_of_scope として記録され、部分的なカバレッジであることがレポートに明示されます。限定実行の結果を全体監査の結果と取り違えないための仕組みです。

コストの見積り単位も示されています。台帳によって支出が数えられ、1ユニットがおよそ1ハンター割り当て、生き残った候補1件がプロファイルに応じて検証者1〜2割り当てに相当します。run-metadata.json の budget には、全フェーズ通算のエージェント呼び出し回数の上限を記録します。

そして偵察エージェントを起動する前に、厳格な予算ゲートが適用されます。ベースライン偵察4回分、批評1〜2回分、検証者1回分以上を予約したうえで、最小構成を賄えない場合はエージェントを1つも起動せず、予算の増額・スコープの縮小・プロファイルの変更を求めます。予算が尽きた場合は run_status: "incomplete" と incomplete_reason を設定し、「カバレッジ完全」を主張しません。未検証の候補を findings.json に入れること、needs_validation に貼り替えること、実行を完了として報告することはいずれも禁止されています。

上限を宣言でき、賄えないなら起動しないという設計は、コストが読めないという導入前の不安に対して明確な答えになっています。走らせてから請求額に驚く、という事態を構造的に避ける作りです。

インストール手順

導入自体はコマンド1本です。README には次のコマンドが記載されています。

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

出典: cloudflare/security-audit-skill の README

ユーザーレベルでインストールする場合は --global を付けます。

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit \
  --global

出典: cloudflare/security-audit-skill の README

ここで指定している --skill security-audit は、リポジトリ名ではなくスキル名です。前述のとおり両者は一致しないため、コマンドをそのまま使うのが確実です。

使用する npx skills は Skills CLI（skills.sh） が提供するコマンドで、エージェント向けスキルのインストールを標準化するエコシステムです。公式サイトには Claude Code / Cursor / Codex / GitHub Copilot / Windsurf / Gemini / Cline など多数のエージェントが対応として掲載されています。したがってこのスキルは特定製品の専用機能ではありません。ただし README の Requirements にあるとおり、並列サブエージェントをサポートするモデルとエージェントであることが前提になります。

SKILL.md 自体も特定製品に依存しない書き方で統一されており、Parent（調整役・共有状態の所有者）、Task tool（委任／サブエージェント機構）、research エージェント、general エージェントといった抽象語で記述されています。役割・書き込み分離・プロンプト・独立性の境界を保ったまま、同等のプラットフォーム機能で置き換えてよい旨も明記されています。

コーディングエージェントのスキルという仕組み自体に馴染みがない場合は、Claude Code スキルの記事もあわせて参照してください。

類似OSSとの違いとAIコード監査ツールの使い分け

採用を検討する際に避けて通れないのが、既に運用している仕組みとの重複です。ここでは類似する3つのリポジトリと比較します。いずれも 2026年10月4日時点に GitHub API で取得した値です。

PR差分レビュー型との違い

anthropics/claude-code-security-review は GitHub Action として提供され、PR がオープンされたタイミングで自動実行されます。走査の中心は変更差分で、結果は PR へのインラインコメントとして返ります。CI に組み込んで常時回すガードレールとしての性格が強い構成です。

これに対し security-audit-skill は、開発者がエージェントに依頼したときに起動する対話型です。走査範囲はリポジトリ全体で、カバレッジ台帳によって管理され、複数回の実行で加算的にカバレッジが上がります。出力はスキーマ検証付きの findings.json と3種類の Markdown レポートです。

誤検知への対処方法も異なります。前者はカスタマイズ可能なルールによるフィルタ、後者は発見者とは別のエージェントが反証を試みる敵対的検証と独立レコード検証の二段構えです。

ルールベースSASTとの違い

semgrep/semgrep はパターンマッチによる決定論的な静的解析です。同じ入力に対して同じ出力が返る再現性が最大の強みで、CI での回帰検出やルールの資産化に向いています。コストは CPU 時間です。

security-audit-skill は LLM エージェントによる探索であり、再現性ではルールベースに劣ります。README が複数回実行を推奨していること自体が、1回の実行結果が変動することの裏返しです。コストはエージェント呼び出し回数、つまりモデル利用料に連動し、budget で上限を宣言できます。

両者は役割が重なりません。既知パターンの恒常的な検出はルールで、信頼境界の設計に由来する欠陥の探索はエージェントで、という切り分けになります。

スキルカタログ型との違い

mukul975/Anthropic-Cybersecurity-Skills は、817 件のセキュリティスキルを複数のフレームワークにマッピングしたカタログ型のリポジトリです。性格が根本的に異なり、カタログ型が提供するのは対応領域の広さ、security-audit-skill が提供するのは1本の監査ワークフローの深さです。後者は6フェーズの手順、JSON スキーマ、バリデータ、サンドボックス要件まで規定することで、出てくる結果の確からしさを担保しようとしています。

カタログ型の採用判断軸については、Anthropic-Cybersecurity-Skillsの記事で扱っています。

使い分けの結論

比較の結果は「どれか1つを選ぶ」ではなく、役割の分担に落ち着きます。

security-audit-skill が埋めるのは3段目です。日々の差分チェックでは見えない、リポジトリ全体の信頼境界を洗い直す工程にあたります。既に1段目・2段目を運用している環境でも重複投資になりにくいのは、起動契機と走査範囲が明確に異なるためです。

周辺の動向にも触れておきます。OpenAI は2026年3月に、脆弱性の発見・検証・修正を自動化する AI エージェント「Codex Security」を発表しました（出典: GIGAZINE, 2026-03-09）。Anthropic も Claude Code にセキュリティレビュー機能を提供しています（出典: Anthropic, Automate security reviews with Claude Code）。ベンダー提供のマネージド機能が増えるなかで、監査手順そのものをドキュメントとして手元に持ち、自社の基準に合わせて改変できる点が、MIT ライセンスの OSS である security-audit-skill の立ち位置になります。

採用判断のチェックポイント

メンテナンス状況の読み取り

採用判断では、プロジェクトの継続性も見る必要があります。GitHub API で確認できる事実は以下のとおりです。

注意したい点が2つあります。

1つはリリースタグが発行されていないことです。バージョンを固定して導入したい場合、タグではなくコミット SHA を指定する必要があります。CI に組み込んで再現性を担保したいケースでは、この点が運用設計に影響します。

もう1つは、設計が落ち着いたのが直近である点です。コミット履歴を見ると、2026年9月10日に監査ワークフロー・findings の契約・バリデータを全面的に作り直すコミットが入っており、その後2026年9月14日に guidance モードと full audit モードの説明を明確化する更新が行われています。作成から3か月ほどで大規模な作り直しが入っているため、ドキュメントの記述が今後も変わる可能性を織り込んでおくほうが安全です。

向いているケース・向いていないケース

ここまでの内容を、判断材料として整理します。

向いているケース

• OS 強制サンドボックスを用意できる、または用意する工数を確保できる
• 並列サブエージェントをサポートするコーディングエージェントを既に運用している
• 1回で完結させるのではなく、複数回の実行でカバレッジを積み上げる運用を許容できる
• 監査結果を機械可読な形で受け取り、既存のワークフローへ流し込みたい
• 監査手順そのものを自社基準に合わせて改変したい（MIT ライセンスのため可能です）
• リリース前や引き継ぎ時など、棚卸し的な全体監査のタイミングが明確にある

向いていないケース

• 同じ入力に対して同じ結果が返る再現性を最優先したい（ルールベース SAST が適します）
• PR ごとの自動実行を主目的としている（GitHub Action 型が適します）
• サンドボックス環境を整備できず、動的確認を伴う候補が needs_validation に滞留することを許容できない
• エージェント呼び出し回数に連動するコストの予算を確保できない
• バージョンをタグで固定して管理する運用が必須である

公式が公表している数値の読み方

最後に、評価を誤りやすい点を1つ補足します。Cloudflare 公式ブログで報告されている実績値は、ハーネス本体の数字であって security-audit-skill 単体の数字ではありません。

同ブログで報告されているのは、VDH が生成した生の候補 20,799 件、145 リポジトリを横断した findings 合計 13,841 件、エンジニアリングチームに渡った実行可能な findings 7,245 件といった規模です。初期検証の棄却率が改善した経緯や、高品質な findings の比率が上がった推移も示されています。

これらは8フェーズの VDH と3フェーズの VVS を組み合わせた全社規模システムの運用実績です。GitHub で公開されている単一リポジトリ版の原型をそのまま動かして同じ数字が出るわけではありません。この区別を押さえたうえで、「実運用まで育ったシステムの設計思想が読める」という観点で評価するのが妥当な読み方です。

まとめ｜AIコード監査にsecurity-audit-skillが選ばれる理由

security-audit-skill が AI コード監査の選択肢として挙がる理由は、公開ドキュメントから読み取る限り次の3点に集約されます。

1. 探索より排除に多くのフェーズを割く構造 — 6フェーズのうち探索は2つだけで、残り4つが候補の反証・検証・棄却に費やされます。発見者と検証者を分ける敵対的検証、confirmed に上げるための境界と結果の明示要求、多層防御のギャップを脆弱性と扱わない線引きが、人間側の仕分け工数を抑える方向に働きます。
2. 機械可読な出力とスキーマ検証 — findings.json が JSON スキーマで検証され、ゼロ依存のバリデータが同梱されています。監査結果を既存の運用に接続しやすい形で受け取れます。
3. 安全側に倒した既定の挙動 — 既定は guidance mode でスキルを読み込んだだけでは走り出さず、サンドボックス要件を満たせなければターゲットコードを実行せず、予算を賄えなければエージェントを1つも起動しません。

一方で、導入ハードルも明確です。OS 強制サンドボックスの整備、並列サブエージェント対応のエージェント、エージェント呼び出し回数に連動するコスト、そしてリリースタグがないためのバージョン固定手段。これらを自チームで用意できるかどうかが、採用判断の実質的な分かれ目になります。

まずは guidance mode の範囲で使いながら、SKILL.md と HUNTING.md に書かれた監査基準を自社のレビュー観点と突き合わせてみる、という入り方もあり得ます。ワークフロー全体を回さなくても、判断基準のドキュメントとして読む価値があるリポジトリです。

関連情報

セキュリティ監査の自動化や、開発プロセスへの AI エージェント組み込みをご検討中の場合は、お問い合わせフォームからご相談いただけます。要件が固まる前の段階でも、現状の体制に合わせた進め方の整理からご相談を承っています。