防御までの時間を短縮するCatoの自己進化型脆弱性保護エージェント
要約（TL;DR）：最先端のAIモデルが急速に進化する時代において、脆弱性の発見やエクスプロイトの開発は、セキュリティ担当者が手作業で対応できる速度を上回る勢いで進んでいます。セキュリティチームは、増え続けるCVEへの対応に追われています。さらに、脆弱性が実際に悪用されるまでの時間は短くなり続けている一方で、脆弱性の調査、防御ルールの作成、検証、そして本番環境への展開といった作業の多くは、依然として手作業に依存しています。攻撃者が組織のパッチ適用よりも速いペースで脆弱性を悪用するようになる中、Time-to-Protect（保護までの時間） は、重要なセキュリティ指標になりつつあります。
Catoでは、CVEの公開から顧客保護までの時間を短縮するために、Multi-Modal Vulnerability Protection Self-Evolving Agent（マルチモーダル脆弱性防御自己進化型エージェント） を開発しました。2段階にわたるパイロット検証において、このエージェントは複数の脆弱性カテゴリに対して実用的な防御ルールを生成し、安定した結果を示しました。第1フェーズでは、生成された複数の防御ルールが、すでに本番環境で運用されているルールと同等、あるいはそれを上回る性能を示しました。その後、ワークフローの改善を経た第2フェーズでは、評価した6件すべてのCVEに対して実用的なシグネチャの生成に成功しました。最も短いケースでは、わずか45分で完了しています。本ブログでは、検証手法、評価結果、そして検証フィードバック、監査ログ、セキュリティ担当者によるレビューを通じて継続的に改善される、特定のモデルに依存しないエージェント型ワークフロー の評価から得られた主要な知見をご紹介します。
CVE防御エージェントのワークフロー
このワークフローの目的は、新たに公開された脆弱性に対する有効な防御を、できるだけ短時間で作り出すことです。同時に、防御ルールに関する最終的な判断は、常にセキュリティ担当者が行う仕組みとなっています。
ワークフローは大きく5つの段階で構成されており、さらに継続的な改善を可能にするフィードバックループを備えています。
- 脆弱性情報の収集
- エクスプロイト（脆弱性悪用）分析
- 防御ルールの生成
- 検証
- セキュリティ担当者によるレビュー
このワークフローでは、複数のAIモデルを組み合わせるとともに、さまざまな種類のセキュリティ関連情報を分析できるよう設計されています。分析対象には、ベンダーのセキュリティアドバイザリ、CVE情報、信頼できる公開・非公開リポジトリ、スクリーンショット、技術図表などが含まれます。これにより、エージェントは防御ルールを生成・検証する前に、対象となる脆弱性をより深く理解することができます。図1は、脆弱性の分析から検証、そしてセキュリティ担当者によるレビューに至るまでの、エージェント型CVE防御ワークフローの全体像を示しています。
図1. マルチモーダルCVE防御エージェントの全体ワークフロー
マルチモデル・マルチモーダル設計
このワークフローは、マルチモデルかつマルチモーダルな構成を採用しています。マルチモデルとは、タスクの内容や複雑さに応じて最適なAIモデルを使い分ける設計を指します。一方、マルチモーダルとは、アドバイザリ、ソースコード、スクリーンショット、技術図表、PoC（概念実証）コードなど、異なる形式の情報を横断的に分析できることを意味します。
この設計における重要な目標の一つは、柔軟性の確保でした。脆弱性調査の各工程では求められる推論能力が異なるため、すべてのタスクに同じモデルを利用するのは効率的ではありません。評価期間中は主に Claude Sonnet 4.6 と Claude Opus 4.7 を利用しました。また、それらの公開後には Claude Opus 4.8 および OpenAI GPT-5.5-Cyber の評価も開始しています。
メタデータの抽出、アドバイザリの解析、ワークフロー全体の管理といった処理は、比較的低コストなモデルでも効率よく実行できます。一方で、脆弱性悪用分析、防御シグネチャの生成、検証結果を踏まえた改善といった高度な処理では、より高い推論能力を持つモデルが効果を発揮します。このアーキテクチャは、特定のモデルに依存しないことを前提に設計されています。そのため、基盤モデルの性能向上を、基盤アーキテクチャを再設計することなくワークフロー全体に取り込むことができます。
バックグラウンドでは、エージェントはオーケストレーション層によって管理されており、エンドツーエンドのワークフロー全体にわたって16の処理ステップとサブエージェントを統括しています。さらに、各サブエージェントは処理効率を高めるために、追加のサブエージェントを並列に起動することもできます。各工程には検証ゲートが設けられており、期待された処理が正しく完了したかどうかが確認されます。要件を満たしていない場合、その工程は検証を通過するまで自動的に再実行されます。
シグネチャ生成は、汎用的なAIモデルだけに任せられているわけではありません。このワークフローでは、Catoが蓄積してきた脅威調査の知見、検知ロジック、IPSシグネチャに関する知識、回避手法に関する知見、そして検証ノウハウを活用する専用エージェントを利用しています。各エージェントは、それぞれ特定の脆弱性カテゴリに特化するよう設計されています。対象となる脆弱性カテゴリには、リモートコード実行、認証回避、パストラバーサル、サービス妨害（DoS）、情報漏えい、そして汎用的な攻撃手法が含まれます。こうしたカテゴリ別の専門化により、すべての脆弱性を同じ方法で扱う画一的なアプローチではなく、それぞれの脆弱性に適した、より効果的な防御を生成できるようになります。
また、このワークフローは複数の情報源とデータ形式を横断的に分析できるよう設計されています。分析対象には、CVEアドバイザリ、ベンダーによる公開情報、セキュリティ調査ブログ、信頼できる公開・非公開リポジトリ、技術図表、画像、スクリーンショットなどが含まれます。これらの情報を組み合わせることで、防御ルールを生成する前に、脆弱性の挙動についてより深い理解を得ることができます。
検証は、このワークフローにおける中核的な要素であり、後付けの工程ではありません。生成された防御ルールは、Catoのデータウェアハウスに保存された最新の実トラフィックデータを用いて、誤検知（False Positive）と検知漏れ（False Negative）の両面から評価されます。これにより、正規の通信を遮断することなく、関連する攻撃パターンを確実に検知できることを確認します。
最後に、このワークフローは、検証結果、セキュリティ研究者によるレビュー、実行履歴、監査ログから得られるフィードバックを通じて継続的に改善されます。こうした知見は、プロンプト、スキル、ワークフローのロジック、専門エージェント、そしてモデル選択ロジックの改善に活用され、時間の経過とともにワークフロー全体の性能向上につながります。
運用フィードバックを通じた継続的な改善
Multi-Modal CVE Protection Agentの重要な設計原則の一つが、継続的な改善です。エージェントがエンドツーエンドのワークフローを完了し、プルリクエストを生成するたびに、セキュリティ担当者が提案された防御ルールをレビューします。そして、必要に応じて改善点をフィードバックします。こうした修正は、担当者が手動で行うこともあれば、支援エージェントによって自動的に適用されることもあります。
フィードバックのプロセスは、1回のプルリクエストで終わるわけではありません。定期的に実行される学習ワークフローでは、完了済みのプルリクエスト、レビュアーのコメント、そして解決済みの課題が分析されます。システムは、エージェントが最初に生成した防御ルールと、最終的に承認された防御ルールを比較することで、繰り返し発生する問題、欠落しているロジック、そして改善の余地を特定します。こうして得られた知見は、エージェントが利用するスキル、ワークフロー、検証ロジック、知識の改善に活用され、将来の実行時に同様の問題が発生する可能性を低減します。
その結果、エージェントは一度構築して終わりの仕組みとはなっていません。レビューのたびに、防御品質の向上、今後の調査の迅速化、そして脆弱性調査プロセス全体の継続的な改善が図られます。
評価手法
Multi-Modal CVE Protection Agentの有効性を評価するため、私たちは複数の脆弱性カテゴリを対象としたパイロット評価を実施しました。評価対象には、6つの主要な攻撃カテゴリにまたがる20件の実際に報告された脆弱性を選定しました。第1フェーズでは、6つの主要な攻撃カテゴリに属する14件の実際の脆弱性を評価しました。対象には、すでに防御ルールが実装されているCVEを使用しています。これにより、エージェントが生成した防御ルールを、本番環境で運用されている既存の防御ルールと比較することができました。続く第2フェーズでは、第1フェーズの結果を踏まえてワークフローを改善した後、当社環境でまだ防御ルールが実装されていない6件のCVEを対象に評価を実施しました。第2フェーズで評価したCVEには、リモートコード実行（RCE）、認証回避、パストラバーサルなど、第1フェーズと同じカテゴリに属するものも含まれていました。ただし、すべてのカテゴリを1対1で対応させることを目的としたものではありません。
表1は、今回のパイロット評価で対象とした脆弱性カテゴリと、それぞれのカテゴリで評価したCVEの件数を示しています。
表1. パイロット評価に含まれる脆弱性カテゴリ
評価プロセス
各脆弱性について、エージェントは公開されている脆弱性情報を分析し、候補となる防御ルールを生成したうえで、収集済みのテレメトリデータおよび検証ワークフローを用いてその有効性を評価しました。
評価方法は、2つのパイロットフェーズで若干異なります。第1フェーズでは、テスト環境から既存の防御ルールを取り除いたうえで評価を実施しました。これにより、エージェントが生成した防御ルールを、本番環境で運用中の防御ルールと直接比較できるようにしました。第2フェーズでは、あらかじめ防御ルールが存在しない脆弱性を対象としてワークフローを評価しました。これにより、改善後のワークフローを、実環境に近い条件で評価することができました。
両フェーズを通じて、評価では以下の観点を測定しました。 * Time-to-Protect（保護までの時間） * 防御ルールの品質 * セキュリティ担当者による介入の度合い
評価結果
図2は、第1フェーズのパイロット評価結果をまとめたものです。複数の攻撃カテゴリにまたがる14件の脆弱性を対象に評価を実施しました。図中では、処理時間、CVEごとの最短処理時間、防御ルールの品質、そしてワークフローの成功率を示しています。
図2. 第1フェーズにおけるエージェント型CVEパイプラインのパイロット評価結果
パイロット評価の結果、エージェント型ワークフローは、多様なCVEデータセットに対しても、処理時間と品質の両面で安定した結果を示しながら防御ルールを生成できることが確認されました。
表2は、第1フェーズのパイロット評価における主要な評価指標をまとめたものです。
表2. 第1フェーズ パイロット評価結果の概要
第2フェーズの評価結果
第1フェーズで得られた知見をもとにワークフローを改善した後、既存の防御ルールが用意されていない6件の脆弱性を対象に評価を実施しました。
図3は、その結果を示しています。第2フェーズでは、6件のCVEすべてに対して実用的な脆弱性対策シグネチャの生成に成功しました。また、CVEごとの最短処理時間は45分でした。
図3. 第2フェーズにおけるエージェント型CVEパイプラインの評価結果
主な評価結果
短時間で効率的に生成
両フェーズを通じて、このワークフローは数日単位ではなく、数時間単位で防御ルールを生成しました。これは重要な成果です。通常、防御ルールの作成には、脆弱性分析、検知ロジックの設計、検証、レビュー、改善といった作業を含め、セキュリティ担当者による数時間に及ぶ専門的な作業が必要となるためです。第1フェーズでは、最短のTime-to-Protectは45分でした。その後、ワークフローを改善した第2フェーズでは、評価対象となった6件すべてのCVEに対して実用的なシグネチャの生成に成功しました。複数のケースで1時間以内に生成されており、最短時間は第1フェーズと同じ45分でした。
高い成功率
このワークフローは、評価対象となったほぼすべての脆弱性に対して実用的な防御ルールを生成することに成功しました。第1フェーズでは、生成された複数の防御ルールが、すでに本番環境で運用されているルールと同等、あるいはそれを上回る性能を示しました。第2フェーズでは、新たに公開された6件すべてのCVEに対して実用的な防御シグネチャを生成しました。
安定性と再現性
両フェーズの結果から、複数の脆弱性カテゴリにわたって一貫した結果が確認されました。また、処理時間についても、一部の成功事例だけに依存するのではなく、実運用に適した範囲内で安定して推移しました。
安全対策は想定どおりに機能
あるケースでは、公開されているエクスプロイト情報が十分ではなかったため、ワークフローは適切に処理を停止しました。これは、自律型セキュリティワークフローにおいて、ポリシーによる制御やガードレールが重要であることを示しています。
表3は、第1フェーズのパイロット評価における全データセットと結果を示したものです。
表3. 第1フェーズ パイロット評価データセットおよび結果
表4は、第2フェーズの評価結果をまとめたものです。
表4. 改善後ワークフローによる第2フェーズ評価結果
防御ルールの品質評価
今回の評価では、生成速度だけでなく、生成された防御ルールが十分な精度を備え、効率的であり、セキュリティ担当者によるレビューに適した品質であるかどうかについても検証しました。パイロット評価全体を通じて、複数の防御ルールが本番環境レベルの品質に到達しており、中には承認までにわずかな調整しか必要としないものもありました。
エージェントは、攻撃手法のバリエーション、エンコード方式の違い、シグネチャの適切な粒度、誤検知の抑制といった、防御ルールの設計において重要な要素も考慮することができました。その結果、生成された防御ルールは短時間で作成できるだけでなく、実環境での運用にも十分耐えうる実用的なものとなりました。
これらの結果は、エージェント型の脆弱性調査が、防御ルール開発の迅速化と効率化に貢献できる可能性を示しています。その一方で、防御ルールの最終的な検証と承認については、引き続きセキュリティ担当者が担います。
Claude Opus 4.8の初期評価
特定のモデルに依存しないアーキテクチャの利点の一つは、新たな基盤モデルが利用可能になった際に、迅速に取り込めることです。
Claude Opus 4.8が2026年5月28日に利用可能となった直後、私たちは以前取り上げたcPanelの脆弱性 CVE-2026-41940 を用いて評価を実施しました。表5は、この初期評価の結果を示しています。
表5. Claude Opus 4.8の初期評価結果
このワークフローは、1時間未満で、しかも初回実行の段階で高品質な防御ルールを生成しました。
なぜプラットフォームが重要なのか
エージェント型の脆弱性防御の有効性は、基盤となるAIモデルだけで決まるものではありません。AIモデルは脆弱性の分析や防御ルールの候補生成を支援できますが、本当の価値は、その周囲に構築されたアーキテクチャにあります。オーケストレーション、検証プロセス、フィードバックループ、そして防御ルールを迅速かつ安全に大規模展開できる仕組みこそが重要です。
Catoのクラウドネイティブアーキテクチャにより、Multi-Modal CVE Protection Agentは、脆弱性分析から顧客保護までを、顧客側での対応を必要とすることなく実現できます。新たな防御ルールは実際のトラフィックデータを用いて検証され、その後、CatoのグローバルPoPネットワーク全体へ展開されます。さらに、メンテナンス作業のための停止時間やアプライアンスの更新、手作業による対応を必要とすることなく、統合セキュリティプラットフォームを通じて提供されます。これは、私たちが以前の記事「The Mythos Moment」で述べた考え方とも一致しています。長期的なAIの価値は、基盤モデルそのものだけでなく、その周囲に構築されたアーキテクチャ、オーケストレーション、そしてフィードバックループによって生み出されるのです。
The Mythos Moment | Read the blog考察と結論
今回のパイロット評価とその後の調査を通じて、エージェント型の脆弱性調査が、複数の脆弱性カテゴリにおいてTime-to-Protectを大幅に短縮できることが確認されました。Multi-Modal CVE Protection Agentは、一貫して予測可能な処理時間、妥当なコスト、そして高品質な結果を伴う防御ルールを生成しました。さらに重要なのは、ボトルネックそのものが変化しつつあることです。防御ルールを生成することは、もはや最も難しい課題ではありません。真に重要なのは、それらを安全に検証し、大規模な環境で実運用に乗せることです。その段階では、プラットフォームアーキテクチャ、実際のトラフィックデータ、そしてセキュリティ研究者による監督が不可欠になります。
これは、もはや単なるパイロットプロジェクトではありません。Catoの研究チームはすでにこのワークフローを活用し、顧客へより迅速かつ強力な防御を提供しています。もちろん、人間の専門知識は引き続きプロセスの中心にあります。研究者は結果をレビューし、複雑なケースを検証し、必要に応じて最終的な検知判断を下します。一方で、エージェントは調査や防御ルール開発における反復的な作業を自動化し、大規模に処理します。今後、基盤モデルの進化が続く中で、このような特定のモデルに依存しないアーキテクチャは、AIの進歩をより迅速な顧客保護へと結び付ける現実的なアプローチになると考えられます。
AIが「行動」できる時代へ：OpenClawのガバナンス
