powered by TechFeed
表示モード
Deep Dive

Cloudflareが「1エージェントでは失敗した」と認め、複数AIの並列分析でセキュリティアラート対応を自動化 — 証拠なき推論を排除する設計思想とは

10月8日、Cloudflareが「Building an evidence-grounded agentic security operations harness on Cloudflare」と題した記事を公開した。この記事では、Cloudflare Workers上に構築したマルチAIエージェント型セキュリティ運用ハーネスのアーキテクチャと設計思想について詳しく紹介されている。

10月8日、Cloudflareが「Building an evidence-grounded agentic security operations harness on Cloudflare」と題した記事を公開した。この記事では、Cloudflare Workers上に構築したマルチAIエージェント型セキュリティ運用ハーネスのアーキテクチャと設計思想について詳しく紹介されている。


「1エージェントでは失敗した」という出発点

セキュリティアラートは単独では来ない。1件のアラートが連鎖的に環境全体に波及し、アナリストは「どれを無視するか」「どれが誤検知か」「どれがインシデント対応チームへの連絡を要するか」を同時に判断しなければならない。アラートの量が増えるほど、個々の精査に充てられる時間は逆に減っていくという構造的な問題がある。

Cloudflareがまず試みたのは、汎用の単一AIエージェントに調査全体を委ねる方式だった。結果は「使えるが危うい」というものだった。テレメトリ、検知ルールの説明、ポリシー、脅威インテリジェンスをすべて1つのプロンプトに詰め込んだことで、3つの問題が繰り返し発生した:

  • コンテキストが権威になる:検知結果はあくまで仮説だが、汎用エージェントはそれを「事実」と混同する
  • スコープが漂流する:誤ったアカウント、時間範囲、データソースへのクエリをプロンプトで防ぐことはできない
  • 失敗が消える:タイムアウトした場合、「未確認」と「確認済みで見つからなかった」が区別されなくなる

この反省から、証拠収集とスコープ制御をモデル推論の前段にあるアプリケーションコードで行うという設計にシフトした。


アーキテクチャ:「偵察先行、推論後退」

ハーネスの前半には、AIエージェントが1つも登場しない。

まず決定論的なコードが固定の偵察ワークフローを実行する。顧客のID、検知履歴、トラフィックベースライン、適用された制御の結果、ネットワーク観測結果を収集し、それぞれにソース・バージョン・タイムスタンプを付与して保存する。この「偵察スナップショット」は再現性の確保にも寄与する。エージェントが自分でデータを取得する構成では、2回の実行間で入力が変わって結果が食い違う可能性があるが、同一スナップショットをリプレイできれば、差異は「解釈の違い」に限定できる。

次に登場するのがClefによる早期ノイズフィルタリングだ。元記事ではClefはCloudflareが開発した判定モデルとして紹介されているが、その実装の詳細(オープンソース・クローズドソースの別、Workers AI上で動作するか等)については元記事を直接確認されたい。Clefは「このアラートは過去にこの顧客で何度も誤検知だったか?」「トラフィックは通常の人間的な振る舞いと一致しているか?」を判定し、誤検知率が高いと判断されたアラートはスペシャリストエージェントの分析をスキップさせる。


4つのスペシャリストエージェントが並列稼働

フィルタを通過したアラートに対しては、コーディネーターエージェントが以下の4つのスペシャリストエージェントを並列で起動する:

  • トラフィック分析:リクエスト挙動・履歴変化・適用済み制御を精査
  • 顧客コンテキスト:過去のアラート・対応履歴・アナリストの判断を精査
  • グローバルテレメトリ:プライバシーを保ちつつ、インターネット全体のシグナルと比較(個別顧客データは使用しない)
  • 脅威インテリジェンス:アラートや案件に紐づいた既知のインジケーターを確認

最後に合成エージェントが4者の型付き調査結果を1つのアドバイザリにまとめる。この合成エージェントは、新たな証拠を取得することも、あらかじめ決まった語彙の外から分類を選ぶこともできない設計になっている。


証拠の引用を機械的に検証する

分析前に、システムはバージョン管理された「証拠パッケージ」を生成する。対象・スコープ・時間アンカー・採用済み証拠・ポリシーバージョン・ソース・カバレッジギャップが含まれる。スペシャリストエージェントはこのパッケージ内の項目しか引用できず、アプリケーションコードが「引用が存在するか」「その調査案件に属しているか」「主張を裏付けているか」を機械的にチェックする。不正な引用は修正されるか、限界として記録される。

「証拠なし」「確認したが該当なし」「不在を裏付ける証拠あり」の3状態を明確に区別する点が、この設計の重要なポイントだ。証拠が不十分な場合は分類も対処の推奨も行わない。


Cloudflare Workers基盤上での実装

このパイプライン全体はCloudflareの開発者プラットフォーム上で動作している:

  • **Workflows**:各ステージの調整と完了済み作業の保存。失敗したステージは検証済みの証拠から再開できる
  • **D1**:調査・アドバイザリの状態管理
  • **R2**:証拠アーティファクトの保持
  • **Durable Objects**:ケースチャット状態の永続化
  • **AI Search**:コンテキストの強化

採用しているLLMモデルについては、元記事に具体的な記載があるが、モデル名・サービス名の正確な表記は元記事を直接確認していただきたい。本稿執筆時点で名称の確認が取れなかったため、ここでは記載を省いている。


現状と今後

最終的な判断と緩和策の適用はManaged Defenseアナリストの責任に留まる。アナリストはAIの推奨を確認・修正・棄却できる立場にあり、モデルがテナント境界を越えたり、アナリストの代わりに行動したりする権限は与えられていない。

ベータはCloudflare Managed DefenseでWAF、DDoS保護、Magic Transitなど対応製品の利用者向けに提供中だ。今後の数四半期で「Custom Managed」レベルの追加と、固定ルールでは検出が難しいパターンを継続監視する常時起動型エージェントの導入を検討している。

詳細はBuilding an evidence-grounded agentic security operations harness on Cloudflareを参照していただきたい。