Cloudflare Security Audit Skill、AIコードレビューを敵対的ワークフローへ転換
Cloudflareは、6段階からなるAIコード監査ワークフローを公開した。しかしCloudflare security audit skillは、モデルにバグを探すよう指示するだけの別のプロンプトではない。コードをマッピングし、脆弱性を探索し、所見に異議を唱え、残った証拠を検証するために、個別のエージェントを割り当てる仕組みだ。
この違いは重要である。AI生成のセキュリティレポートには、有効な攻撃経路を伴わないもっともらしい主張が含まれることが多い。Cloudflareの設計では、提案された脆弱性をすべて、別のエージェントが反証を試みるべき申し立てとして扱う。また、監査対象の範囲も記録するため、分析漏れが見えやすくなる。
このオープンソース公開は、Cloudflareがはるかに大規模な社内脆弱性ハーネスを構築する過程で培った考え方をパッケージ化したものだ。公開されたskillは、1つのリポジトリと1回の監査を対象とする。これに対しCloudflareの社内システムは、リポジトリ横断で結果を保持し、依存関係を追跡し、数千件の所見を管理する。
ここに、この公開をめぐる中心的な緊張関係がある。再利用可能なskillは構造化されたAIコードレビューへの障壁を下げる一方で、それだけでCloudflareの社内インフラを再現することはできない。開発者が得るのは、セキュリティエンジニアを自律的に置き換えるものではなく、より強力な出発点だ。
Cloudflare Security Audit Skillが実際に変えるもの
CloudflareはAIセキュリティレビューを、会話から明示的なカバレッジと検証ゲートを備えた、証拠を生み出すプロセスへと変えようとしている。
公開されたaudit skill repositoryでは、ツールと分離されたサブエージェントをサポートするコーディングエージェント向けに設計されたワークフローを説明している。MIT Licenseの下で提供され、Skillsコマンドラインインターフェースを通じてインストールできる。
Cloudflare security audit skillは、監査を6つのフェーズに分ける。偵察では、ソフトウェアアーキテクチャ、信頼境界、入力面、利用可能な証拠をマッピングする。このマップはアーキテクチャ文書と機械可読なカバレッジ台帳に記録される。
次に、カバレッジ主導の探索が行われる。親エージェントは、定義済みの領域と攻撃クラスに対して分離された探索エージェントを割り当てる。各探索エージェントは、疑わしい問題の一覧だけを返すのではなく、何を確認したかを記録する。
この台帳は重要である。短いレポートは、そうでなければ誤った安心感を与えかねない。エージェントは認証コードを調べ、何も見つけず、アプリケーション全体が安全に見えると示唆するかもしれない。カバレッジ記録があれば、パース処理、デプロイ設定、依存関係の処理、テナント分離への注意が不足していたことを示せる。
候補の検証では、個々の手掛かりを新たな検証者に渡す。その検証者は、前提、ソースパス、影響を受ける主体、セキュリティ上の結果を確認し、提案された脆弱性を退けようとする。探索エージェントが自らの作業を承認することはない。
残った所見は、続いて構造化された出力へ移される。このskillは記録を、確認済みの所見、検証が必要な問題、却下された候補に分類する。スキーマで必須フィールドを定義し、同梱されたJavaScriptバリデーターがファイルを機械的にチェックする。
最終フェーズでは、ソースに関する主張を独立して検証し、対象に依存しないレポートを生成する。所見に重要な変更が加えられた場合は、再度検証を行う。この設計は、レポート作成者が要約の過程で弱い主張を密かに強化することを防ごうとするものだ。
この結果は、通常のAIコードセキュリティ監査とは決定的に異なる。成果物には、調査した対象領域、却下したアイデア、未解決の事実、独立して確認された所見に関する説明が含まれる。見栄えのよいレポートだけが唯一の成果物ではなくなる。
Cloudflareは厳格な実行境界も定めている。ビルド、テスト、ファザー、ブラウザー、対象が制御するフィクスチャには、外部ネットワークアクセスを持たないOSサンドボックスが必要だ。こうした制御がなければ、ワークフローは信頼できないコードを実行するのではなく、手掛かりを未検証として保持しなければならない。
この制約により、この公開はワンラインの監査プロンプトよりも手軽ではなくなる。一方で、現実のセキュリティ問題も反映している。レビュー対象のコードには、監査環境そのものを攻撃する命令やビルド動作が含まれている可能性がある。
Cloudflareがフリート全体向けハーネスより先にSkillを構築した理由
公開skillにはCloudflareの監査手法が凝縮されている一方で、単一のエージェントセッションが運用上の限界に達する理由も示している。
Cloudflareによると、このプロジェクトは単一リポジトリ向けのおよそ450行のセキュリティskillとして始まった。エンジニアは有用なバグが見つかるまでプロンプトを改良し、そのシナリオと検証ルールをより大きなシステムへと引き継いだ。
同社は、その進化をvulnerability harnessに関するエンジニアリング記事で詳述している。最初のバージョンでは、偵察用に3つのリサーチエージェント、攻撃クラス別の個別探索エージェント、敵対的なバリデーター、構造化された所見、独立したソース検証を用いた。
Cloudflareは、初期の実行で3つの限界を特定した。長時間のセッションではモデルのコンテキストが尽き、中断された実行では進捗が失われ、単一リポジトリのレビューでは利用側サービスとの関係を見落とした。
これらの失敗は、単なるモデル品質の問題ではなかった。状態管理の問題だった。
モデルは現在のコンテキスト内にあるコードについて推論できるが、大規模な監査では多数の仮説が並行して生まれる。各仮説には、ファイル、信頼境界、前提、実験、反論、ステータス変更が伴う。この履歴を会話要約へ圧縮すると、決定的な詳細が失われる可能性がある。
Cloudflareは、状態を外部化することで対応した。後のハーネスでは、言語モデルを交換可能なワーカーとして扱い、永続的な監査情報をそのコンテキストウィンドウの外部に保持する。データベースには、各タスクの実行、リポジトリ、ステージが保存される。
この違いは、Cloudflareが完成済みの社内システムとしてではなく、出発点を公開した理由を説明する。skillは、コーディング環境の中に厳格な手順をエンコードできる。しかし、フリートのインベントリ、永続的なキュー、依存関係グラフ、プロダクションテレメトリーを自動的に提供することはできない。
Cloudflareは、最初のskillから128のリポジトリにまたがるシステムへ移行するのに約6週間かかったと報告している。この社内システムは、言語ごとのオーケストレーションなしで、Rust、Go、C、Lua、TypeScript、Python、設定形式を横断して動作する。
より大規模なワークフローでは、発見と検証を分離している。Vulnerability Discovery Harnessは潜在的な弱点をマッピングし、探索する。別のVulnerability Validation Systemが結果を重複排除し、プロダクション上の関連性を確認し、修正対応を管理する。
Cloudflareは、この2段階で異なるモデルを使用していると述べている。この選択により、単一モデルに繰り返し現れる推論パターンへの依存を減らせる。また、特定のモデルを中心にセキュリティプロセスを再設計することなく、プロバイダーを変更できる。
このモデル中立の立場は、ベンチマーク性能をAIセキュリティ製品の主要指標として掲げるベンダーに圧力をかける。Cloudflareの主張は、モデルの出力が有用なエンジニアリング作業になるかどうかを決めるのは、オーケストレーション、証拠、独立した却下だというものだ。
同社は、このskillがプロダクションパイプラインを再現すると主張しているわけではない。同社自身のガイダンスでは、チームは偵察、探索、検証から始めるべきだとしている。リポジトリ横断のトレーシングや専用の重複排除が有用になるのは、監査量がそうした問題を生んだ後に限られる。
この順序付けは、小規模チームに実践的な入口を提供する。高価なインフラを構築する前に、プロンプトと証拠ルールが自分たちのコードで機能するかを試せる。
また、公開版が誤解を招く製品デモになることも防ぐ。リポジトリが提供するのはCloudflareのシステムの基礎となった手法であり、現在フリート全体で稼働する完全なシステムではない。
真の対抗相手はワンショットのAIコードレビュー
Cloudflare vulnerability harnessは、1つの有能なモデルがリポジトリを検査し、実在する欠陥を特定し、自らの結論を確実に評価できるという前提に異議を唱える。
ワンショットレビューは通常、よく知られた流れをたどる。開発者はコーディングエージェントにリポジトリへのアクセスを与え、セキュリティ脆弱性を探すよう依頼する。エージェントは選択したファイルを読み、疑わしいパターンを特定し、洗練されたレポートを書く。
このプロセスは有用な手掛かりを生み出すことがある。しかし、3つの異なる失敗を隠す可能性もある。
第一に、モデルは何を調査するかを選択するが、何をスキップしたかについて永続的な記録を残さない。第二に、同じ推論プロセスが各主張を生成し、評価する。第三に、説得力のある表現によって、不完全な証拠が最終的な結論のように見える場合がある。
Cloudflareのワークフローは、各失敗に個別に対処する。カバレッジ台帳は意図した監査対象範囲を記録する。独立した探索エージェントは範囲が限定された単位を調査する。新たなバリデーターは、候補の表現を改善するのではなく、反証を試みる。
この敵対的な分担は、単にエージェントを増やすことより重要である。同じ前提を共有する10個のエージェントは、同じ偽陽性の10通りの説明を生成し得る。Cloudflareは役割を分け、バリデーターに探索エージェントの仮説を却下する権限を与える。
このskillは、具体的な境界の失敗も要求する。確認済みの問題には、影響を受ける主体、リソース、またはセキュリティ上の結果が必要だ。ベストプラクティスの欠如が自動的に脆弱性になるわけではない。
この区別により、すでに信頼された管理者だけが利用できる無制限の挙動といった所見を除外できる。また、攻撃者が実際の境界をどのように越えるかを示さず、不在の防御策だけを説明するレポートも却下する。
Cloudflareの社内プロセスでは、より強い証明要件を用いる。確認済みの所見には、元のコードベースに対して再現可能なテストが含まれていなければならない。そのテストは、探索エージェントが導入したソース変更に依存してはならない。
このルールは、特に危険な失敗モードに対処する。エージェントは実験中にコードを変更し、その変更済みバージョンに対するエクスプロイトを実証できる。ソース状態の制御がなければ、結果として得られるレポートは、エージェントが作り出した欠陥をアプリケーションの欠陥として帰属させる可能性がある。
機械的な検証は、さらに別の層を加える。通常のコードが、引用されたファイル、パス、パッチ、テストが存在するか、あるいは正しくパースできるかを確認する。言語モデル自身が、自らの出力がこうした基本的な構造要件を満たしているかを判断するわけではない。
Cloudflareによると、1回のskill実行で見つかった脆弱性は、繰り返し実行して最終的に発見された脆弱性のおよそ半分だった。これは同社による報告であり、独立して測定された再現率ではない。
それでも、この結果は公開版の中心的な設計選択を支持している。報告された所見がすべて有効であっても、完了した1回の実行だけで完全なカバレッジが確立されるわけではない。
したがって、厳格なAIコードセキュリティ監査には、異なる2つの信頼性に関する表明が必要となる。1つは各所見の有効性に関するものだ。もう1つは、所見を探す監査がどれほど徹底的だったかに関するものだ。
Cloudflare security audit skillは、この両方の問いを可視化する。確認済み、未解決、却下という判定は証拠上の信頼性を説明する。カバレッジ台帳は探索プロセスを説明する。
従来の静的解析も、このモデルでは引き続き重要である。決定論的なスキャナーは、既知のパターン、データフロールール、反復可能なチェックに優れている。エージェントは、アプリケーション固有の信頼に関する前提を調査したり、不慣れなロジックをまたぐ弱点を組み合わせたりできる。
Cloudflareの社内での経験は、想定されたツール選好に関する警告も示している。同社によれば、探索エージェントは1か月間の実行で統合されたSemgrepパスを呼び出さなかった。エージェントはコードの読み取りと実行を好む一方、不足している環境やフィクスチャを頻繁に要求した。
その観察は、静的解析に価値がないことを示すものではない。ツールを導入しただけでは、エージェントがそれを効果的に利用できるとは限らないということを示している。チームは、ワークフロー内で実際にどのようにツールが使われているかを測定する必要がある。
したがって競争の構図は、AI対従来型スキャナーではない。構造化されていないモデル出力対、決定論的な検査、専門的な探索、敵対的な検証を組み合わせた監査プロセスである。
構造化された検出結果はノイズを減らすが、安全性を証明するものではない
今回のリリースで最も強い点は、もっともらしいモデル出力を確認済みの証拠として扱わない姿勢にある。ただし、その規律だけで未発見の脆弱性を測定することはできない。
Cloudflareによると、社内の発見ハーネスは20,799件の生の候補を生成した。そのうち約12,057件が初期検証を通過し、より大規模な検証プールに入った。
別のハーネスからの検出結果がこのシステムに加わった後、中央プールには13,841件のレコードが含まれていた。重複排除により5,442件が除外され、1,154件は対象リポジトリの誤りまたは低リスク案件として振り分けられた。Cloudflareは、エンジニアリングチームにとって対応可能な検出結果が7,245件残ったとしている。
これらの数値は、生成から修正対応までの間にどれほど多くのフィルタリングが行われるかを示す点で有用だ。ただし、検出精度の独立したベンチマークとして解釈すべきではない。
Cloudflareは、リポジトリ、モデル、プロンプト、攻撃クラス、定義を自ら選定している。公開された数値が示すのは同社の運用パイプラインであり、公開スキルが無関係なコードベースでどのように機能するかを立証するものではない。
同社は偽陰性率の主張を明確に避けている。実際のリポジトリには、すべての脆弱性を含む完全なラベルセットは存在しないため、再現率を直接計算することはできない。繰り返し実行しても新たなバグが見つかり続けることは、カバレッジが不完全であることを示すが、残されたギャップの大きさまでは示さない。
この不確実性は、あらゆる評価の中心に置くべきだ。検証済みの報告は、複数の検出結果が実在することを裏付けられる。しかし、監査対象のコードが安全であることまでは立証できない。
公開スキルは、3つの判定を通じてこの違いを伝えようとしている。
confirmedの検出結果には、完全なソーストレースと、範囲が限定された観測結果がある。needs-validationのレコードは、裏付けのない重大度を割り当てずに、未解決の問いを正確に保持する。rejectedのレコードは、候補が不成立となった理由を記録する。
却下された候補を保持することには実務上の価値がある。将来の実行では、本当に新しい経路と、すでに否定されたアイデアを区別できる。また、却下が後に変わった事実に依存していなかったかをレビュー担当者が確認できる。
ただし、構造化出力はそれ自体で確実性の錯覚を生み出し得る。有効なJSONレコードが、必ずしも有効なセキュリティ上の結論であるとは限らない。スキーマ検証では必須フィールドや許容値を確認できるが、エクスプロイトが実際の境界を越えることまでは証明できない。
Cloudflareは、新たなソース検証によってこの制約に対処している。検証者はコードに関する主張を独立してレビューし、重要な置き換えには追加の確認が行われる。それでも品質は、モデルの挙動、利用可能なコンテキスト、脅威モデルの正確さに依存する。
サンドボックス化も導入上の課題となる。このスキルでは、ターゲットが制御するビルドや実験に対し、オペレーティングシステムレベルの制御が必要となる。日常的なコーディングエージェント環境の多くは、明確なリソース制限やネットワーク制限を伴う隔離を提供していない。
この要件を無視するチームは、悪意ある依存関係、ビルドスクリプト、テストフィクスチャを実行するリスクを負う。一方で要件を守るチームは、安全な環境が利用可能になるまで、有望な手がかりの一部を未解決のまま保持しなければならない。
プロンプトインジェクションも関連する懸念を生む。ソースファイル、ドキュメント、Issue本文、生成物には、エージェントに向けた指示が含まれている可能性がある。Cloudflareの後発の商用ワークフローは、コード、ログ、メタデータを指示ではなく証拠として扱うとしている。
ローカル利用にも同じ境界が必要だ。セキュリティエージェントは、認証情報の公開、ネットワークアクセスの拡張、無関係なシステムの変更を認める権限として、リポジトリの内容を解釈してはならない。
NISTのsecure software frameworkは、有用な参照点となる。これは、安全な開発を、準備、保護、制作、脆弱性対応にまたがる組織的実践の集合として扱っている。
AI監査スキルがカバーできるのは、そのライフサイクルの一部にすぎない。ソースを調査し、候補となる弱点を文書化する助けにはなる。しかし、安全な設計、アクセスガバナンス、依存関係の来歴、デプロイ制御、インシデント対応の備えを確立するものではない。
同じ理由で、人間によるレビューも不可欠だ。エンジニアは、意図された挙動、本番アーキテクチャ、ビジネスへの影響、リポジトリには現れない可能性のある代替的な統制を理解している。
したがって、このリリースはレビュー担当者を排除するのではなく、レビューのあり方を変えるべきだ。セキュリティチームは、裏付けのない主張の仕分けに費やす時間を減らし、証拠のテスト、露出の優先順位付け、修正の承認により多くの時間を充てられる。
Cloudflareはコード検出結果を本番コンテキストに結び付けている
Cloudflareのより大きな戦略は、ソースコードの検出結果をトラフィックおよび防御テレメトリーと組み合わせることにある。これは単体のスキルだけでは実現できない。
ソーススキャナーは、安全でないハンドラーを特定できても、そのハンドラーが本番環境で動作しているかどうかは分からない場合がある。どのルートがそのコードに到達するのか、クライアントがどの程度頻繁に利用するのか、稼働中の制御が該当リクエストを遮断しているかも把握できない可能性がある。
Cloudflareの招待制Vulnerability Discovery and Remediationサービスは、そのギャップを埋めようとしている。同社はこのサービスを、Cloudflare Managed Defenseの一部として2026年9月3日に発表した。
context-aware remediationの発表によると、このサービスは、認可されたコード分析をWeb Assets、Web Application Firewallデータ、Workersの可観測性と接続する。
このサービスは、偵察、ハンティング、検証のためにGPT-5.6 Cyberを含むOpenAI Daybreakモデルを使用する。Cloudflareによると、プロンプトはAI Gatewayを経由してOpenAIのサーバーへ送られる。モデル推論はCloudflareのエッジでは実行されない。
この実装は、オープンソースのスキルと商用サービスが異なる役割を担う理由を示している。スキルはリポジトリレベルの調査を体系化する。サービスは、デプロイ済みルート、リクエスト量、セキュリティイベント、既存の制御に関する情報を追加する。
本番コンテキストは、技術的な妥当性を変えずに優先度を変えることができる。到達不能な開発経路上の実際の脆弱性は、広く利用される公開エンドポイントにある同じ欠陥とは異なる扱いを受けるべきだ。
Cloudflareによると、そのプロセスは、証拠が両方を裏付ける場合にコードパッチと限定的なWAFルールを提案できる。エッジルールは、エンジニアが恒久的なコード変更をレビューしている間の露出を減らせる。
このサービスでは、モデルが自らの提案をデプロイすることはできない。ツール呼び出しはログに記録され、アクセスポリシーに照らして評価される。外部チェックがパッチとルールをテストし、変更を実装するかどうかは顧客が決定する。
このアプローチにより、Cloudflareの脆弱性ハーネスは単なる発見エンジン以上のものとなる。ソースの証拠、実行時コンテキスト、緩和策、修正対応を結び付けるエクスポージャー管理システムの一部となる。
この戦略は、同社がターゲット中立のレポートを重視する理由も説明している。同じ監査手法で異なる言語やアプリケーションタイプを検査でき、本番環境に固有のシステムが優先順位付けに必要なコンテキストを提供する。
公開スキルを使う大半のチームには、同等のネットワーク可視性はない。それでも、デプロイメントマニフェスト、ルートマップ、所有者記録、サニタイズ済みログを統制された証拠として提供することで、意思決定を改善できる。
来歴を明確に保つべきだ。ソースの検出結果、デプロイメントに関する主張、トラフィック観測は別々の主張である。それらを一つの段落で組み合わせても、それぞれの事実の出所を曖昧にしてはならない。
ここで、規律あるナレッジ管理が重要になる。エンジニアリングチームには、アーキテクチャ上の意思決定、監査証拠、却下された仮説、その後の修正を結び付ける検索可能な記録が必要だ。維持されたtechnical knowledge baseがあれば、こうした記録を一度のエージェントセッションを超えて利用可能にしておける。
公開スキルは、永続的な成果物を通じてすでにその方向へ進んでいる。アーキテクチャノート、カバレッジ記録、機械可読な検出結果、人間向けレポートは、将来のレビュアーにチャット履歴よりも永続的なものを提供する。
それでも、リポジトリは不完全な全体像にとどまる。インフラストラクチャポリシー、シークレット管理、認可設定、サービス依存関係、ユーザーの行動によって、ソースレベルの弱点が悪用可能になるかどうかは左右され得る。
最も恩恵を受けるチームは、このスキルをより広範なセキュリティプログラム内の一つの証拠生成手段として扱うだろう。最も苦戦するチームは、リポジトリに含まれていない本番リスクの問いに、リポジトリスキャンが答えてくれると期待するだろう。
リリースの重要性を示す3つのシグナル
次の試金石は、開発者がCloudflareの非公開インフラ、データ、セキュリティスタッフなしに、Cloudflareの規律を再現できるかどうかだ。
第1のシグナルは、公開される監査成果物の品質である。有意義な導入は、正確な信頼境界、再現可能な証拠、意味のある却下候補、率直な未解決の問いを備えたレポートを生み出すだろう。
インストール数の増加は関心を示すが、有効性を示すものではない。より重要な指標は、独立したチームが、メンテナーのレビューを経ても確認済みの検出結果が維持される監査を公開するかどうかだ。
このリリースの現行設計は、その評価を支えている。カバレッジと検出結果のスキーマにより比較可能な成果物が作られ、バリデーターは人間によるレビューが始まる前に不正なレコードを検出できる。
第2のシグナルは、実運用後にリポジトリがどのように進化するかである。Cloudflareの社内ハーネスは、繰り返しの実行、不足する環境、浅いカバレッジ、却下された検出結果から学んだ。公開スキルは、より幅広い言語、ビルドシステム、エージェントプラットフォームに直面することになる。
攻撃クラスのガイダンス、サンドボックス要件、カバレッジモデリング、偽陽性の取り扱いに関する変更を注視すべきだ。そうした更新によって、Cloudflareのプロセスのどの部分が円滑に移植でき、どの部分が社内システムに依存するのかが明らかになる。
confirmedとneeds-validationの検出結果の区別は、特に注意を払うべきだ。外部ユーザーが未解決の手がかりを確信に満ちたレポートへと日常的に格上げするなら、ワークフローの安全策は紙の上にしか存在しないことになる。
第3のシグナルは、他のセキュリティプラットフォームが同様に独立した検証を採用するかどうかだ。AIコードツールはすでに、速度、Issue件数、修正支援をめぐって競争している。Cloudflareは、注目を証拠の系譜、却下率、カバレッジ会計へと移そうとしている。
この特定パッケージを開発者が一度もインストールしなかったとしても、その変化はCloudflare security audit skillの広範な影響を強めることになるだろう。誰が検出結果を検証したのかを問う市場は、最大のアラート件数を評価する市場より健全だ。
Cloudflareの社内結果は、これが重要である理由を示している。数千件の生の候補が、検証、重複排除、文脈に基づく判断の過程で消えた。より多くの候補を生成することは、希少な能力ではなかった。それらを信頼できる作業に変換することが希少だった。
個々の組織内にも実務的なシグナルがある。セキュリティ責任者は、独立レビューを通過する検出結果の数、反復実行を通じてカバレッジがどれほど拡大するか、回帰テストを通過するパッチの数を追跡すべきだ。
監査コストと経過時間も記録すべきである。Cloudflareによると、同社の社内フルスキャンには数時間かかる場合があり、最長の実行は14時間を超えた。公開スキルでも、ハンターと検証者が別々の領域を調査するため、かなりのモデル時間を消費する可能性がある。
そのコストは、機密性の高いリポジトリや定期的な詳細レビューであれば正当化できるかもしれません。とはいえ、すべてのプルリクエストに適しているとは限りません。迅速なフィードバックには、より小規模なチェック、決定論的なルール、焦点を絞った脅威レビューのほうが依然として適しています。
重要なのは、既存のスキャナーをエージェントスキルに置き換えるべきかどうかではありません。現在の統制で見落とされている情報を、証拠に基づくエージェント監査がどこで補完できるかです。
開発者は、対象を限定した1つのリポジトリと、明確に定義された信頼境界から始めることができます。最終レポートを読む前にカバレッジ台帳を確認し、そのうえで確認済みの各問題を未変更のソースと照合して検証すべきです。
結論を無理に出すのではなく、未解決の記録を残すべきです。テストは適切なサンドボックス内でのみ実行し、修正方針の決定は人間の管理下に置く必要があります。
このプロセスによって、保守担当者が受け入れる再現可能な発見が得られるなら、Cloudflareは意義あるセキュリティ手法を公開したことになります。ユーザーがこれを単なる包括的なプロンプトの一つに矮小化すれば、6つのフェーズは信頼を高めることなく複雑さだけを増すでしょう。
したがって、Cloudflareのセキュリティ監査スキルは、AIセキュリティベンダーとエンジニアリングチームに具体的な課題を突きつけています。モデルがどれだけ多くの脆弱性を説明できるかで成功を測るのをやめるべきです。敵対的なレビューを経ても成立する主張は何か、どの領域が実際に調査されたのか、そしてどの事実が依然として不明なのかを測定すべきです。
