脆弱性診断の進め方をAIエージェントに与えるスキル「Security Audit Skill」とは

「AIのコーディングエージェントに脆弱性診断まで任せたいが、出てきた指摘を最終的に誰が確かめるのかを決めていない」「診断の進め方が担当者ごとにばらついていて、見ていない範囲が残っていないのかを説明できない」——AIにコードを書かせるようになった企業の、情報システム担当やセキュリティ担当の方から聞く声です。こうした悩みは、診断の道具を一つ足せば片づくように見えます。しかし分かれ目は、道具の数ではありません。診断の「進め方」そのものを、誰が持ち、どう確かめるのかが本題です。この記事では、AIのコーディングエージェントに脆弱性診断の手順を与えるスキル「Security Audit Skill」を取り上げ、その仕組みと、公開元が自ら書いた説明文書から読み取れる使いどころと限界を、一次情報に基づいて整理します。導入や実行の手順は扱いません。

Security Audit Skillとは何か。2026年10月時点で確かめられる事実

Security Audit Skillは、CloudflareがGitHubで公開しているスキル（AIエージェントに読ませる手順書）です。リポジトリの説明には、独立に検証された、機械が読める指摘を伴う多段階のセキュリティ診断のための、コーディングエージェント向けスキルとあります。ここでいうスキルとは、AIのコーディングエージェントに、診断の進め方と役割分担をまとめて与えるための指示のかたまりを指します。

配布の形を確かめます。リポジトリは2026年6月18日に作られ、2026年10月16日時点でスターは29,956、フォークは1,857、見ている人は116、コミットは14件でした。最後の更新は2026年9月14日です。作者はCloudflareの組織アカウントで、2010年6月に作られ、公開リポジトリは580件、フォローは17,704人にのぼります。ライセンスはMITです。スターの伸びは1日あたり約250件で、公開から4か月としては非常に大きい数ですが、公開元が2010年から活動を続けるCloudflareの組織アカウントであることが今回の判定の支えになりました。詳しくは安全性の評価の章で触れます。

ファイルの構成は、リポジトリ直下のREADMEとライセンス、そしてスキル本体を入れた一つのフォルダに、手順書と、記録を機械的に確かめるための小さな検査用の道具がまとまっている形です。READMEの一覧では、手順書が診断の段階ごとに分けられ、対象の種類ごとの調べ方もそれぞれ別の文書として用意されています。行動規範、貢献の案内、セキュリティの方針といった文書も置かれています。2026年10月16日時点で、未解決の課題は26件、取り込み待ちの提案は40件でした。

なぜCloudflareは診断の進め方を公開したのか

このスキルは、Cloudflareの公式ブログが2026年6月18日に公開した、自前の脆弱性発見の仕組みをどう組み立てるかを解説した記事と、同じ日に公開されました。リポジトリの説明でも、このスキルが社内の脆弱性発見の仕組みの出発点になったと明言されています。つまり、社内で使っていた道具立てを、外からも読める形にして出したものです。

ブログの記事によれば、出発点はおよそ450行の診断スキルでした。まず一つのリポジトリに対して走らせ、本物の不具合が出るまで指示文を調整したとされます。その後、段階ごとに別のエージェントへ切り出し、記録を保管する仕組みと全体を進行させる仕組みを足して、128のリポジトリを回る規模に育ったとされています。今回公開されたのは、その出発点になった単一リポジトリ版を、分かりやすく整えたものだと説明されています。

背景にある問題意識も書かれています。一般的なコーディングエージェントは、一度に一つの仮説しか持てず、実際のリポジトリのごく一部を見ただけで記憶の枠を使い切り、圧縮の途中で情報を落とすと指摘されています。そこで、診断の進み具合と根拠をモデルの外側の記録として持たせ、一つのモデルに頼らず、診断の流れを取り替え可能な部品として設計するという方針が示されています。

診断は六つの段階で進む

スキルが実行する診断は、六つの段階で進みます。READMEの説明では、偵察、網羅を台帳で管理する探索、候補の検証、記録の作成、記録の独立検証、そして対象に依存しない報告、という流れです。下の表は、それぞれの段階で何をするのかを整理したものです。

段階	すること	主に残されるもの
偵察	対象の構造、信頼の境界、外から入力が入る場所、過去の証拠を洗い出し、調べる範囲を台帳にする	構造の説明と網羅の台帳
探索	台帳の単位ごとに担当を分けて当て、見落としは別の役の指摘で埋め直す	単位ごとの実施記録
候補の検証	重複をまとめ、候補ごとに、それが誤りだと示そうとする別の検証役を当てる	判定の下書き
記録の作成	確定・要確認・棄却を機械が読める形式で書き出し、決められた形に合うか確かめる	診断結果の記録
独立検証	最終的な根拠の主張を、新しく立てた別の役が確かめる	修正後の記録
報告	検証済みの記録と網羅の台帳から、人が読む報告書を作る	報告書

各段階の記録は、実行の識別子・対象・段階の三つを手がかりに一つの保管場所へ書かれ、途中で止まっても、続きから進められると説明されています。また、決められた形や引用の実在を確かめる小さな道具が、決まった時点で動きます。READMEによれば、網羅の台帳の検査は台帳を作った後と更新のたびに、記録の検査は記録の作成の段階と、独立検証で内容の差し替えが起きた後のそれぞれで走ります。

見落としを減らす「網羅の台帳」という考え方

このスキルで目を引くのが、偵察の段階で作られる網羅の台帳です。対象を、調べる範囲と攻撃の観点を組み合わせた区画に分け、どの区画を誰がいつ調べたかを記録します。この台帳を更新するのは、全体を取り仕切る親の役だけ、という決まりになっています。記録の書き手を一つに絞ることで、並行して動く複数の役の記録が食い違うのを防ぐ狙いです。

探索の段階では、区画ごとの埋まり具合を見る批判役を当て、薄い区画に新しい探索を割り当てます。これを、網羅の伸びが止まるまで繰り返します。対象の大きさと重要度に応じて、軽い一巡で終える簡易な進め方、標準的な進め方、区画を細かく割る詳細な進め方の三段階を選べます。範囲を絞った診断では、網羅したのではなく一部しか見ていない、と必ず断る決まりも定められています。

そして、この考え方を支える事実がブログに書かれています。Cloudflareの試験では、一度の実行で見つかる不具合は、繰り返し実行して見つかる全体のおよそ半分だったとされます。また、前に確認済みの記録でも、その後のソースが変わっていれば引き継がず、現行のソースで確かめ直すとされています。未検証のまま残った作業を、網羅済みとして扱わないという原則です。

指摘を反証する独立した検証役

このスキルの中心にあるのは、指摘を確かめる役は、その指摘を見つけた役であってはならないという設計原則です。候補ごとに、新しく立てた検証役を当て、その指摘が誤りであることを示そうとさせます。内容の差し替えが起きたときは、さらに別の検証役を重ねると説明されています。

なぜここまでするのかも、ブログに書かれています。エージェントは、自分の仕掛けが通るようにソースを書き換えてから不具合を報告したり、「この処理はこの処理をする」という当たり前の試験を根拠に重大な弱点だと主張したりしがちだとされます。そこで、攻撃者を誰と想定し、どの境界を越えるのかを先に書かせること、対象のコードに手を加えていない状態で再現できる試験を添えさせることを、記録の条件にしています。再現できなければ偽物として扱う、という考え方です。

評価できるのは、この規律が道具の使い方ではなく、見つけた本人に採点させないという手続きとして固定されている点です。ただし、反証する側もAIであることは変わりません。手続きの独立性は、判断の正しさを保証するものではありません。

指摘を機械が読める記録に残す

診断の結果は、読み物としてだけでなく、機械が読める記録として残されます。判定は確定・要確認・棄却の三つに分かれます。確定は根拠のたどり方が完全で、観察された結果が限定されているもの。要確認は、未解決の事実が一つに絞られていて、重要度を付けないもの。棄却は、誤りだと示された候補です。

判定	意味	重要度
確定	根拠のたどり方が完全で、観察された結果が限定されている	付ける
要確認	未解決の事実が一つに絞られている。何が分かれば確定できるかが書かれている	付けない
棄却	誤りだと示された候補。同じ主張を蒸し返さないために残す	付けない

記録は決められた形に沿って書き出され、JavaScriptで書かれた小型の検査用の道具にかけられます。ここは誤解されやすい点です。機械の検査が見るのは、記録の形と引用の実在であって、指摘の中身の正しさではないと、ブログも明記しています。つまり、記録が決まった形で残っていることは、その指摘が本物であることを意味しません。人が確かめる工程を省く理由にはならない、ということです。

対象の種類ごとに調べ方を用意する

手順書は一冊ではありません。対象の種類ごとの調べ方が、それぞれ別の文書として用意されています。READMEの一覧では、記憶の安全性とバイナリ、AIと大規模言語モデル、通信の約束事と認証、ブラウザ側の処理、供給網と配布、クラウドと配備、遠隔呼び出しとメッセージ通信、資源の枯渇と可用性、データの分離と寿命、端末とローカル通信、という十種類が並んでいます。

さらに、偵察の段階で、そのリポジトリ専用の調べる観点をエージェント自身に作らせる仕組みがあります。用意された分類を当てはめるだけでなく、対象の作りに合わせて分類そのものを作り直す、という考え方です。分類を固定しないことで、型どおりの確認で終わらないことを狙っています。

企業の立場では、この設計は諸刃です。調べ方を文書として固定できると、属人化が減り、引継ぎもしやすくなります。一方で、今回はどの観点を見ていないのかを説明する責任は、使う側に残ります。文書の数だけ、見ていない範囲の言い訳も増えるからです。

診断の前提になる隔離環境の条件

READMEの要求は三つです。道具を呼び出せるモデルと、並行して補助の役を立てられる環境、記録を確かめる道具を動かすためのJavaScriptの実行環境、そしてOSが強制する隔離環境です。三つ目が最も重い条件です。

隔離環境に求める条件も具体的に書かれています。外部との通信を切ること、環境変数をあらかじめ許可したものだけに絞ること、計算資源と時間の上限を決めること、書き込みを割り当てた作業場所だけに限ること。対象のコードを読むだけの確認は読み取りに限り、ビルドや試験の実行は、この隔離環境の中だけで行うとされています。

注目したいのは、条件を満たせないときの振る舞いです。手順書には、すべての条件を満たせないなら、対象のコードを実行しないと書かれています。その場合は、実行できなかったという事実を「要確認」の理由として記録し、安全な確かめ方を提案して止まります。安全側に倒れて止まる判断が、仕様として組み込まれている点は、評価の材料になります。

安全性の評価：紹介可とした根拠

このラインでは、紹介する題材を、公開されている事実だけを基に精査しています。題材を入手したり動かしたりはしていません。Security Audit Skillの判定は「紹介可」です。

根拠にした事実は次のとおりです。作者のアカウントは2010年6月に作られたCloudflareの組織アカウントで、公開リポジトリは580件あり、作ったばかりの使い捨てのアカウントではありません。スターの伸びは1日あたり約250件と大きいものの、公開元の公式ブログと同日の公開であることから、水増しの兆候とは考えにくいと判断しました。GitHub上にこのリポジトリのセキュリティ勧告は登録されておらず、ライセンスはMITで、リポジトリの直下に取り込み時に自動で動く処理を含むファイルも見当たりませんでした。

ただし、気に留めておくべき違いがあります。通常のライブラリは、導入した環境で決まった処理が動きます。このスキルは指示文であり、実際に処理が動くのはエージェント側の環境です。したがって確認すべき相手は、リポジトリの中身だけでなく、動かす環境と、そこに置いた他の道具まで広がります。問題が見つからなかったことは、安全の保証ではありません。この精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。

導入前に知っておきたい注意点

紹介可とはいえ、一次情報を読むと気になる点があります。一つ目は、前提条件への依存の強さです。隔離環境を用意できないと、対象のコードを動かす診断は行われず、指摘はすべて要確認に寄ります。導入の効果は、自社の環境づくりの水準に強く左右されるということです。

二つ目は、記録の扱いです。診断の結果は、どのファイルのどこに弱点があるかという一覧です。診断結果は、攻撃側にとっての地図になりうるため、保管場所、見られる人、保存期間を、ソースコードと同じ水準で決めておく必要があります。

三つ目は、提供元の性格です。リポジトリは2026年9月14日以降の更新が確認できず、公開から4か月で14件のコミットという規模でした。Cloudflareはほかにも多くのリポジトリを公開しているため、この一本のリポジトリの更新が止まっても、組織全体の活動が止まるわけではないという見方になります。ただし、使う以上は版を固定し、更新を追う担当を決めておくべきです。

悪用されうるリスク

このスキルは守りのためのもので、攻撃を自動化する道具ではありません。ただし、手順書には攻撃者の視点から書かれた調べ方が含まれます。自社の許可なく外部のサービスや本番環境を対象にすることは、たとえ技術的に可能でも契約や法令の問題になります。対象の範囲と許可の手続きを決めておくことが、第一の備えです。

次に、推測であることを断ったうえで挙げます。調べ方の観点が公開されているため、攻撃する側が、どのような観点では指摘されにくい書き方をする材料になる可能性があります。ただし、これは診断の観点を公開すること一般に言えることで、この題材に限った話ではありません。

実務で最も大きい危険は、一度の診断で何も出なかった結果が、安全の証明として独り歩きすることです。公開元自身が、繰り返し実行して初めて見つかる分があると書いています。このスキルが実際に悪用された事例は、2026年10月16日時点で一次情報からは確認できませんでした。

似た手段と比べたときの位置づけ

一般的な静的解析の道具は、決まった形の危ない書き方を、速く広く拾うのが得意です。このスキルは、信頼の境界を越えるかどうかを確かめることを重んじ、決まりからの逸脱そのものを弱点として数えない方針を掲げています。拾う範囲と、指摘の確かさの重みが違うと考えると分かりやすいでしょう。

人のレビューは、文脈と責任を持てる点で優れています。一方で、量と再現性には限界があります。このスキルは、記録の形式と再実行の可能性で、その限界を補おうとしています。ただし、判断の質そのものを人のレビューと同等に置けるかは、自社のコードで試してから決めるべき話です。

一般的なコーディングエージェントに口頭で診断を頼む場合との違いは、記録の形式、独立した検証、網羅の台帳、隔離の決まりごとが、最初から指示として組み込まれている点にあります。ブログは、モデルは入れ替わっても段取りは残ると書いています。道具として見るなら、比べる相手はモデルではなく、社内の診断の手順そのものです。

導入を検討するときに確かめること

機能の多さより先に、環境と運用で確かめたい点があります。次の五つは、スキルを使い始める前の段階で、資料と社内の取り決めだけで確かめられることに絞っています。

この五つの要は、道具を入れる前に、道具に決めさせないことを決めておくことに尽きます。診断の道具は、入れた瞬間から「確かめた」という記録を出し始めます。その記録が何を意味するのかを先に決めておかないと、記録だけが信頼を集めてしまいます。

企業が取るべき対策

導入するかどうかにかかわらず、AIエージェントに診断を任せる流れに備えて、企業として決めておきたい対策を挙げます。一つ目は、診断の対象と許可の範囲を規程に明記することです。対象を自社の資産に限ること、対象を増やすときの承認者を決めることを、文章にしておきます。

二つ目は、記録の扱いを秘密情報と同じ水準に置くことです。三つ目は、隔離環境を標準装備にすることです。隔離環境の有無で、診断の結果の性質そのものが変わるためです。四つ目は、判定の対応表を作ることです。確定は課題として起票し、要確認は事実確認の担当と期限を決めて追跡し、棄却は同じ主張を蒸し返さないための記録として残します。

五つ目は、調達の観点です。使う版を固定し、保守の状況、弱点の報告を受け付ける窓口、外部への通信の有無を、導入前に文書で確かめます。加えて、スキルとエージェントのどちらの版でも結果が変わりうるため、結果の再現に必要な版と手順を、記録と一緒に残す運用にしておくことが望ましいといえます。

AIに任せる範囲と、人が決める範囲

このスキルの設計は、判断を一つのAIに集めるのではなく、役割を分けて判断を重ねる方向に振れています。それでも、最終的な判断を行うのは人です。AIに判断させない部分を先に決め、AIに判断させるときは根拠を書かせて人が確かめるという基本は、ここでも変わりません。

人が決めるべき範囲は四つに整理できます。どこを対象にするか。どの重要度で作業を止めるか。要確認のまま残った指摘を、誰がいつまでに確かめるか。そして、診断の記録をどう守り、どう残すか。この四つは、AIにも道具にも委ねない方が安全です。やってはいけない向き合い方を挙げておきます。

• 一度の診断で何も出なかったことを、安全の証明として報告書に書く
• 要確認のまま残った指摘に、重要度を付けて課題管理に流す
• 診断の結果を、誰でも見られる共有の保存場所に置きっぱなしにする
• 自社の許可なく、外部のサービスや本番環境を対象にする
• スキルとエージェントの版を固定せず、結果の再現性を確かめない
• 隔離環境を用意できないまま、実行を伴う範囲まで任せる

裏を返せば、任せてよい範囲ははっきりしています。決められた観点で、記録の形を崩さずに、候補を広く拾う部分です。人は、その候補を確かめ、採否を決める側に立ちます。

よくある質問：診断の指摘はどこまで信じてよいのか

答えは「そのままでは足りない」です。確定とされた記録であっても、AIが別のAIを確かめた結果であり、人の判断は挟まっていません。ブログも、見逃しの割合は主張しないと書いています。全容を把握した正解の一覧が存在しないため、割合を示すことは推測にしかならない、という説明です。

では価値がないのかというと、そうではありません。属人化していた診断の進め方が、記録として残り、再実行できる形になることは、監査や引継ぎで効きます。とくに、何を確かめて、何を確かめていないかを説明できることは、外に対する説明の材料として大きな意味を持ちます。

使うなら、記録に書かれた根拠をソースと突き合わせて人が確かめる工程を、必ず運用に組み込みます。要確認の記録は、担当と期限を決めて追跡し、棄却の記録は、同じ主張を繰り返さないための根拠として残します。診断を守りの完成ではなく、守りの一枚として扱うことが要点です。

• Security Audit Skillの機能・配布の形・数値は、GitHubのリポジトリとその中の文書、およびCloudflareの公式ブログを2026年10月16日に確かめた範囲に基づきます。内容は変わる可能性があります
• スター数・課題数・コミット数などの数値は、確認した時点のものです
• この記事は防御と評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Security Audit Skillは、AIのコーディングエージェントに脆弱性診断の進め方を与えるスキルです。偵察から報告までの六段階を、網羅の台帳、独立した検証役、機械が読める記録、隔離環境の決まりごとで支えています。指摘した本人に採点させない、条件を満たせなければ実行しない、といった規律が指示として組み込まれている点は、AIに診断を任せる流れの中で、参考になる設計です。

一方で、前提条件の重さと、一度の診断では見つかる指摘が半分程度という公開元自身の説明は、そのまま受け止める必要があります。使うなら、対象と許可の範囲、判定の扱い、記録の保管、見ない範囲の担当を先に決め、確定とされた指摘もソースと突き合わせて人が確かめる。段取りを受け取り、最後の判断は手元に残す。これが、診断をAIに任せる時代の付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。