AI 脆弱性診断を自社コードに｜Cloudflare公開スキルの仕組みと注意点
この記事の要点
- Cloudflareが紹介した「security-audit」は、コーディングエージェントに6段階の脆弱性監査をさせる公開スキルです。公開は2026年6月で、11月4日の投稿は改めての紹介です。ライセンスはMITです。
- 探す役と確かめる役を分け、確かめる役が指摘の反証を試みます。結果は「確認済み」「要検証」「否認」に分け、形式はプログラムで検査します。
- Cloudflareはこのスキルから社内の仕組みを発展させ、2万799件の候補を絞り込みました。ただし、この数字は公開されていない社内システムのもので、スキル単体の成績ではありません。
- Cloudflareのテストでは、1回の実行で見つかったのは、繰り返し実行で見つかった脆弱性全体の約半分でした。稼働中のシステムも試さないため、1回で問題なしと判断することはできません。
- 使う前に、コードの送信先、対象コードを実行するサンドボックス、バージョンの固定、報告書の管理を確認してください。第三者のコードでは、編集部は読み込む文章に指示が仕込まれる危険にも注意すべきだと考えます。
「コーディングエージェントを、セキュリティ監査のチームに変える」。Cloudflare の開発者向けアカウントは2026年11月4日（UTC。日本時間では5日）、同社の脆弱性発見システムの出発点になった公開スキル「security-audit」をこう紹介しました[1]。GitHub のリポジトリは11月6日時点で6万件を超えるスターを集めています[2]。
スキルとは、AIエージェントに特定の仕事の進め方を教える指示書のセットです。AI が脆弱性を探すこと自体は珍しくありませんが、未確認の指摘が大量に出ると、確かめる人の負担が増えます[10]。Cloudflare のスキルは、その問題を手順と検査で抑えようとしています[2]。
この記事では、公開されたファイルと Cloudflare の公式ブログを読み、何をどう調べるのか、社内システムと何が違うのか、何が分からないのか、試す前に何を確認すべきかを整理します。情報は2026年11月6日時点のものです。編集部はファイルを読んで解説しており、このスキルで実際の監査は実行していません。
Cloudflare は何を公開したのか？
公開されたのは、コーディングエージェントに複数段階の脆弱性監査をさせるスキルです。プログラム本体というより、エージェントへの詳しい指示書と、結果の形式を検査する2つのプログラムでできています[2]。ライセンスは MIT です[2]。リポジトリの作成は2026年6月18日で、同じ日の公式ブログと合わせて公開されました[3][9]。
1,778行
指示書の分量
skills/security-audit 配下の Markdown 15本の合計。編集部が2026年11月6日に計測
経緯は次のとおりです。日付はいずれも UTC です。
5月18日
Cloudflare が Project Glasswing の所見を公開
汎用のコーディングエージェントだけでは、実際のコードを広く調べきれないと説明[10]。
6月18日
社内の仕組みの解説とスキルを公開
約450行のスキルから始めた経緯を公開ブログで説明し、スキルを公開[3]。
9月10日
監査の流れと検査を全面的に改修
コミット「Rework the audit workflow, findings contract, and validators end to end」[9]。
9月14日
相談対応と完全監査の区別を明確化
11月6日時点の最新コミット（c1c8a8c）[9]。
11月4日
Cloudflare の開発者向けアカウントが改めて紹介
相次ぐ脆弱性の公表を理由に、自社コードの点検を呼びかけた[1]。
スキルには2つの動作があります。セキュリティの質問や部分的なレビューには、必要な部分だけを使う「ガイダンスモード」で答えます。コードの監査や侵入テストを明示的に頼むと「完全監査モード」になり、6段階すべてを実行してファイルを書き出します[4]。どちらか判断できないときは、作業を始める前に質問するよう定められています[4]。
6段階の監査はどう進むのか？
コードの構造を調べ、調べる範囲を表にしてから、担当を分けて攻撃の視点で探します。候補は別のエージェントが反証を試み、残った記録をさらに別のエージェントが確かめ、最後に報告書にまとめます[2]。全体を統括する親エージェントだけが共有ファイルに書き込みます[4]。
| 段階 | 何をするか | 主な成果物 |
|---|---|---|
| 1. 偵察 | 構成、信頼の境界、入力の入口、過去の結果を調べ、調べる単位の一覧を作る[2] | architecture.md、coverage-ledger.json[2] |
| 2. 探索 | 一覧の単位ごとに独立した探索役を割り当てる。別の役が調べ漏れを探す[2][5] | 構造化された候補（JSON）[5] |
| 3. 候補の検証 | 探索に関わっていない検証役が、候補ごとに反証を試みる[2][6] | 確認済み・要検証・否認の判定[6] |
| 4. 記録の出力 | 判定を記録し、スキーマと検査プログラムで形式を確かめる[2] | findings.json[2] |
| 5. 記録の再検証 | 別のエージェントが、最終的な記録の根拠をソースコードで確かめる[2] | 検証済みの記録（必要なら差し替え）[2] |
| 6. 報告 | 検証済みの記録と調べた範囲の一覧から報告書を作る[2] | REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md[2] |
探索の基本は9種類の視点で、対象に合わせて選び、必要なら追加します。インジェクション、アクセス制御、ファイルなどの扱い、暗号と秘密情報、業務ロジック、機能の悪用と情報漏えい、複数の弱点の連鎖に加え、自由に探す「ワイルドカード」と、基本的な見落としを探す「Obvious things」があります[14]。さらに、対象に応じて選ぶ10種類の専門別の指示書があります[2]。
範囲は「quick」「standard」「deep」の3段階で指定します。規定は standard です。quick は小さな対象や最初の確認に向き、部分的な結果として示さなければなりません[4]。quick では候補の検証と記録の再検証が1回にまとまり、確かめる役は候補ごとに1人になります。独立した確認そのものは省略できません[6]。段階を変えても、証拠の基準は変わりません[4]。
AI の指摘の誤りをどう抑えるのか？
AI の判断に任せきりにせず、指摘を通す条件を手順にしています。スキル単体の精度を示すデータはありません。Cloudflare は、モデルに脆弱性を探させると、実際にあるかどうかに関係なく何かを報告する傾向があると述べています[10]。スキルでは、見つけた役が自分の指摘を判定せず、確証のない指摘には重大度を付けません[2]。
- 脆弱性の条件を先に定める：攻撃者の立場、受け入れる値、止めるはずの処理、到達する結果を順に示す[5]
- 影響を盛らない：クラッシュをコード実行に、自分の権限内の操作を権限昇格に格上げしてはならない[5]
- 対策不足と脆弱性を分ける：別の層で攻撃が防がれているなら、それは改善の助言で、脆弱性ではない[2]
- 検証役は反証から入る：「あなたはこの候補を書いていない」という前提で、ソースと局所的な証拠から反証を試みる[6]
- 記録を機械で検査する：スキーマに合わない記録や、順序の誤った追跡を検査プログラムで見つける[2][9]
デプロイ、ブラウザー、提供元、ブローカー、OS、プロキシ、パッケージ、秘密情報、ID に関する事実で、ソースの外にあるものは、どちらの証拠にもならない。そのような事実が決め手になるなら、不足している観測と、所有者が確かめられる安全な確認方法を正確に記して needs_validation を返す。
A deployment, browser, provider, broker, OS, proxy, package, secret, or identity fact outside source is not proof either way. If one such fact is decisive, return a needs_validation record with the exact missing observation and safe owner-observed check.
公開スキルと社内システムは何が違うのか？
公開スキルは1リポジトリを調べる出発点で、Cloudflare が128リポジトリに使う社内システム（ハーネス）そのものではありません[2][3]。Cloudflare は、1回の実行では足りないことや、文脈の上限、途中で落ちたときのやり直し、リポジトリをまたぐ判断の難しさから、社内システムを作りました[3]。
| 項目 | 公開スキル | 社内システム（2026年6月の説明） |
|---|---|---|
| 対象 | 1つのリポジトリ[2] | 128リポジトリとリポジトリ間の依存関係[3] |
| 状態の管理 | coverage-ledger.json と findings.json[2] | SQLite に工程ごとに保存し、途中から再開する[3] |
| AI モデル | 並列のサブエージェントとツール利用に対応したもの[2] | 発見と判定で別のモデルを使う[3] |
| 確認済みの条件 | 完全なソースの追跡と、範囲を限った観測結果[2] | 元のコードに対して動く試験（PoC）と修正案[3] |
| 修正 | 説明のみで、対象のソースは変更しない[4] | 修正案と試験を生成する。統合は必ず人がレビュー[3] |
| 公開状況 | MIT で公開[2] | 将来の公開に言及。編集部が11月6日に GitHub を検索した範囲では見つからなかった[3] |
Cloudflare が公表した社内システムの数字は、絞り込みの重要さを示しています。発見側が累計で出した候補は2万799件で、検証を通ったのは約1万2,057件でした。別の仕組みの指摘と合わせた1万3,841件のうち、5,442件が重複、1,154件が別のリポジトリ宛てや低リスクなどに分類され、担当チームが対応すべき指摘は7,245件でした[3]。
この数字は6月のブログ執筆時点のものです。Cloudflare は、隔離した環境での研究の結果で、本番環境に未修正の脆弱性が残っていることを示すものではないと説明しています[3]。また、同社は見逃し率を示していません。すべての脆弱性を網羅した正解データがないためです[3]。
このスキルで分からないことは何か？
1回の監査では、すべての脆弱性は分かりません。稼働中のシステムの状態も分かりません。Cloudflare のテストでは、1回の実行で見つかったのは、繰り返し実行で見つかった脆弱性全体の約半分でした[2]。この記述は最初の公開時からあり、9月の改修後に測り直したかは示されていません[9]。公式ブログも、1回で見つかるものは単純で分かりやすいものに偏る傾向があったと述べています[3]。
- 稼働中のシステムは試さない：公開中のサーバー、外部サービス、本番の ID には接続しない設計[4]
- ソースにない設定は判断しない：クラウドの権限、プロキシ、ブラウザーの動作が決め手なら「要検証」にする[4][5]
- 安全に動かせなければ実行しない：サンドボックスの条件が1つでも欠けると、対象のコードは動かさず「要検証」のまま残す[4]
- リポジトリをまたぐ問題は見えにくい：Cloudflare は、単一リポジトリのセッションでは、それを使う側との関係が見えないと説明している[3]
繰り返すときは、過去の結果を読み込み、調べ漏れや変更された箇所を優先します[2][4]。報告では、1回の実行で対象を調べ尽くしたように示してはならないと定められています[4]。報告書に「問題なし」に見える部分があっても、まず調べた範囲の一覧を確かめてください。
編集部は、このスキルが従来の脆弱性診断や依存関係の点検の代わりになるとは考えていません。Cloudflare の社内では、探索役が Semgrep（静的解析ツール）を1か月間一度も呼ばなかったそうですが[3]、これはエージェントの使い方についての観察で、ほかの点検を不要とする根拠ではありません。公開中の環境の確認も別に必要です。
使う前に確認すべきリスクは何か？
確認すべきなのは、コードの送り先、実行環境、スキルの入手元、報告書の扱いです。スキルは自社のコードを AI に読ませる手順なので、普段のコーディングエージェントの設定とデータの扱いがそのまま関係します。スキルが守ってくれるのは手順であって、契約や社内ルールではありません。
| 確認事項 | 分かっていること | 編集部の推奨 |
|---|---|---|
| コードの送信先 | スキルはモデルを指定しない[2]。読んだコードの扱いは、使うエージェントとモデルの契約による | 秘密情報や顧客データを含むリポジトリは、学習利用や保持の条件を確かめてから使う |
| 対象コードの実行 | 外部ネットワークの遮断、空の環境変数、対象の読み取り専用、書き込み先の限定、資源の上限が必須[4] | 条件を満たせないならソースを読むだけにする。確認済みには観測結果が必要なので、原則としてすべて要検証になり、重大度も付かない |
| 報告書の管理 | 既定の出力先は対象の外の ~/security-audit-skill/<repo-name>/run-<N>[2] | 未修正の脆弱性の一覧として扱い、共有範囲を決める |
| スキルの固定 | リポジトリにリリースもタグもない[9]。Skills CLI は完全なコミットを指定できると説明している[11] | 40桁のコミット ID で npx skills add cloudflare/security-audit-skill@<40桁のコミットID> --skill security-audit と固定し、更新時に差分を読む |
| CLI の通信 | Skills CLI は匿名の利用データを送信する[12] | 社内ルールに合わせ、DISABLE_TELEMETRY=1 で止めるかを決める |
| 費用の上限 | 全工程のエージェント起動回数を予算として指定できる。金額の上限ではなく、候補が多いと上限を超えるか、検証が未完了のまま終わることがある[4] | 最初から quick と範囲の限定で試し、起動回数の上限を決める |
入手元にも注意してください。公式のリポジトリは cloudflare/security-audit-skill です[2]。Cloudflare 以外が自動生成して公開した、似た名前のスキルも存在します。たとえば reason-machines/security-skills は、人気のリポジトリから自動生成したスキル集と自称しており、そこに含まれる説明には、探索役を既定で7つとし、公式版にない環境変数で変更できるとするなど、現在の公式版と異なる記述があります[13][2]。これらが不正だという意味ではありませんが、公式版の説明がそのまま当てはまるとは限りません。
自社のコードで試すにはどうすればよいか？
最初は、自社に権利があり、機密性の低い小さなリポジトリを選び、範囲を絞って試すのが安全です。公式の導入は Skills CLI で行います。導入後は、コーディングエージェントに「このコードベースをセキュリティ監査して」と頼むと、スキルが自動で有効になります[2]。
最初の1回で確認すること
- 対象が自社に権利のあるコードか、委託先が作ったものなら点検してよい契約かを確認する
- コードの送信先となる AI の契約と設定（学習利用・保持・管理者設定）を確認する
- 対象に本物の API キーや顧客データが含まれていないかを確認する
- スキルをコミット指定で導入し、指示書と検査プログラムの中身を読む（Skills CLI の説明）
- 対象のコードを実行するなら、前の節の条件をすべて満たす、OS で強制するサンドボックスを用意する。用意できなければソースを読むだけにし、結果は原則として要検証になると理解しておく
- 「quick」と対象のパスを指定し、エージェントの起動回数の上限も伝える
- 報告書の出力先と共有範囲を決め、対象のリポジトリにコミットしない
- 確認済みの指摘があれば人が内容を確かめ、修正と回帰テストの担当を決める
- 要検証の指摘は、不足している事実を持っている人（クラウドや運用の担当）に回す
指摘が出たら、重大度だけで順番を決めないでください。Cloudflare の社内システムも、CVSS の値だけで期限を決めるのではなく、本番で到達できるかを別の工程で判断しています[3]。スキルが示す重大度の目安も、確認された結果に基づきます[4]。修正後は同じ範囲をもう一度調べ、変わった箇所が再検証されるようにします[4]。
Cloudflare は、自前の仕組みを作る場合の最小の構成として、偵察・探索・検証の3工程をデータベースに記録し、指摘を自分では登録できない検証役を置けばよいと助言しています。複数のリポジトリが重要になるまでは、リポジトリをまたぐ追跡を作らなくてよいとも述べています[3]。大きな仕組みを最初から作る必要はありません。
AIを組み込んだアプリでは何を調べるのか？
チャットボットや RAG、AIエージェントを含むアプリには、専用の指示書 AI-AND-LLM.md があります。見るのは、信頼できない内容が AI や記憶を通って、権限や処理に届く流れです[8]。外部からの内容がほかの利用者の文脈に入る、AI の出力がそのままコマンドに渡る、といった流れを追います[8]。
- RAG や記憶の汚染：攻撃者が書ける文書やメールが、別の利用者の文脈に入らないか[8]
- 権限の代理：共有の認証情報で動くツールが、依頼者の権限を確かめているか[8]
- 承認の結び付き：利用者が承認した操作と、実際に実行される内容が一致するか[8]
- MCP の信頼：ツールの説明やメタデータを、権限の根拠にしていないか[8]
- 出力の扱い：AI の出力が HTML やコマンドなどに、必要な処理なしで渡っていないか[8]
- 費用の暴走：1回の依頼で、上限なく支出や外部 API の処理が繰り返されないか[8]
興味深いのは、「プロンプトインジェクションだけでは指摘にならない」と定めている点です。別の利用者の文脈に届く、依頼者にない権限を使うなど、コード上の境界の失敗が必要としています。「ガードレール用のプロンプトは安全上の境界ではない」とも明記しています[8]。AI の振る舞いへの指示ではなく、権限の確認や分離などの仕組みで守るという考え方です。
AI で作った社内ツールが増えている会社でも、この観点はそのまま使えます。ツールが誰の権限で動き、どのデータに触れ、何を外部に出せるのかを書き出すだけでも、確認すべき場所が見えます。社内の AI 利用の全体像はAIセキュリティとは、鍵の管理はAPIキー漏洩の解説でも扱っています。
まとめ
Cloudflare の security-audit は、コーディングエージェントに6段階の脆弱性監査をさせる公開スキルです。探す役と確かめる役を分け、不足している事実を明記させ、調べた範囲を記録します[2][4]。社内システムが出した大きな数字は、公開スキル単体の成績ではありません[3]。
1回で見つかるのは一部で、稼働中のシステムは試しません[2][4]。試すなら、自社のコードで範囲を絞り、コードの送信先、サンドボックス、バージョンの固定、報告書の管理を先に決めてください。AI の指摘は人が確かめ、従来の診断や依存関係の点検と組み合わせて使うことが大切です。よくある質問はFAQにもまとめています。
よくある質問
Cloudflare の security-audit スキルとは何ですか？
コーディングエージェントに6段階のセキュリティ監査をさせる公開スキルです。コードの構造を調べ、担当を分けて脆弱性を探し、別のエージェントが反証を試み、結果を記録して報告書にします。ライセンスは MIT です。Cloudflare の社内の脆弱性発見システムの出発点になりました。
どのコーディングエージェントで使えますか？
公式の説明では、ツールを使え、並列のサブエージェントに対応したモデルのコーディングエージェントが必要です。スキル自体は特定のエージェントに依存しない書き方で、導入に使う Skills CLI の説明には Claude Code を指定する例があります。検査プログラムを動かすために Node.js も必要です。対象のコードを実行する場合は、OS で制御するサンドボックスも必要です。
プログラミングができなくても使えますか？
自然な言葉で依頼して動かすことはできます。ただし、サンドボックスの準備や、指摘が本当に問題かの判断には、技術の知識が必要です。AI で作った社内ツールを調べるときは、結果を開発の分かる人に確かめてもらい、対象のコードを実行しない範囲から始めるのが安全です。この場合、結果は原則として要検証になり、重大度は付きません。
このスキルで問題が見つからなければ安全と言えますか？
言えません。Cloudflare のテストでは、1回の実行で見つかったのは、繰り返し実行で見つかった脆弱性全体の約半分でした。また、稼働中のシステムや、ソースコードにない設定は確認しません。報告書の調べた範囲を確かめ、従来の脆弱性診断や依存関係の点検と組み合わせてください。
社内で使うときに最も注意すべき点は何ですか？
編集部が重視するのは、コードの送信先です。監査ではソースコードを AI に読ませるため、使う AI の契約と設定を先に確かめてください。報告書は未修正の脆弱性の一覧なので、共有範囲も決めてください。第三者のコードを調べるときは、中の文章に指示が仕込まれる可能性も考え、秘密情報のない環境で動かすことを勧めます。
出典・参考資料
- 投稿With the recent wave of vulnerability disclosures, it’s a good time to take a closer look at your own code.
- 公式発表GitHub - cloudflare/security-audit-skill
- 公式発表Build your own vulnerability harness
- 公式発表security-audit-skill/skills/security-audit/SKILL.md
- 公式発表security-audit-skill/skills/security-audit/HUNTING.md
- 公式発表security-audit-skill/skills/security-audit/VALIDATION-AND-REPORTING.md
- 公式発表security-audit-skill/skills/security-audit/RECONNAISSANCE.md
- 公式発表security-audit-skill/skills/security-audit/AI-AND-LLM.md
- 公式発表Commits · cloudflare/security-audit-skill
- 公式発表Project Glasswing: what Mythos showed us
- 公式発表skills/docs/commands.md
- 公式発表skills/docs/troubleshooting.md
- 記事reason-machines/security-skills
- 公式発表security-audit-skill/skills/security-audit/ATTACK-CLASSES.md
- 調査レポートLLM01:2025 Prompt Injection
本記事の事実関係は、2026.11.06 時点で上記の出典をすべて再確認しています。 独立のファクトチェックで全出典を照合し、対象リポジトリの指示書を読み直して確認。指摘を反映済み。スキルとそのプログラムは編集部では実行していない。
AIセキュリティの基本は「AIセキュリティとは」で解説しています。
