Cloudflare が「エビデンス接地」型のエージェント harness を公開。モデルを呼ぶ前に証拠を固定し、引用をコードで検証する
Cloudflare が、自社の Managed Defense アナリストがセキュリティアラートをトリアージ・調査するために内製したマルチエージェント harness の構成を公開した。中核にあるのは evidence grounding で、モデルを1回も呼ぶ前に決定論的コードがバージョン管理された API 呼び出しで証拠を集め、調査ごとにバージョン付きの証拠パッケージを固定する。専門エージェントはそこから引用しなければならず、アプリケーションコード側がすべての引用が実在し、その調査に属し、主張を裏づけているかを検証する。synthesis エージェントは新しい証拠を取りに行けず、承認された語彙の外から分類を選ぶこともできない。アドバイザリは未確認・確認したが一致なし・不在の証拠を確認を区別する。使用製品は Workers、Workers AI、Workflows、D1、R2、Durable Objects、AI Search。事例解説が主体だが、対象製品の顧客向けに Managed Defense の早期ベータも告知している。
ニュース原文を読む ↗要約
Cloudflare が2026年10月7日、自社の Managed Defense アナリストがセキュリティアラートをトリアージ・調査するために内製したマルチエージェント harness の構成を公開しました。 製品発表ではなく事例解説が主体ですが、対象製品の顧客向けに Managed Defense の早期ベータも同時に告知しています。
構成は次の順で動きます。
- 決定論的な recon — モデルを1回も呼ぶ前に、バージョン管理された API 呼び出しで顧客 ID、検知履歴、トラフィックのベースライン、適用結果、ネットワーク観測を収集する
- Clef トリアージ — 各アラートを誤検知らしさでスコアリングし、ノイズと判定されたものは専門エージェントの分析を飛ばす
- 4つの専門エージェントを並列実行 — トラフィック分析、顧客コンテキスト、グローバルテレメトリ（集計値のみ）、脅威インテリジェンス
- synthesis エージェント — 型付きの所見を1つのアドバイザリへ統合する。新しい証拠を取りに行くことはできず、承認された語彙の外から分類を選ぶこともできない
- ケース集約 — 関連アラートをまとめ、実際の影響範囲はアナリストが確認する
中核にある「エビデンス接地（evidence grounding）」が、この構成の設計思想です。 モデル推論の前に決定論的コードが証拠を集めてスコープを固定します。各調査にはバージョン付きの証拠パッケージが与えられ、専門エージェントはそこから引用しなければなりません。 そして、アプリケーションコード側が、すべての引用が実在し、その調査に属し、主張を裏づけているかを検証します。
これは「プロンプトでお願いする」のではなく「コードで検証する」という移動です。 「根拠を示してください」「推測で答えないでください」とプロンプトに書く方法は広く使われていますが、守られたかどうかを確認する手段がありません。 Cloudflare の構成では、引用が証拠パッケージに実在するかをアプリ側が機械的にチェックします。存在しない引用は、プロンプトの出来に関係なく弾かれます。
もう1つ実務的に効くのが、アドバイザリの3値区別です。 「未確認」「確認したが一致なし」「不在の証拠を確認」を区別します。データ欠損がクリーンな結果と誤読されないようにするための設計です。「調べていない」と「調べたが何もなかった」を同じ「問題なし」として出力するシステムは、インシデント対応で致命的な誤判断を生みます。
権限の境界も明示されています。 モデルはテナント境界を越えられず、アナリストの代わりに行動もできません。最終判断の責任はアナリストに残ります。
使用製品は、Workers（アプリコードが証拠を受け入れ結果を検証）、Workers AI（Clef を実行）、Workflows（段階の調整と、完了分の保存による失敗段階からの再開）、D1（調査・アドバイザリの状態）、R2（境界付きコンテキストと証拠アーティファクト）、Durable Objects（ケースチャットの状態）、Flue と AI Search（ケースチャットと enrichment）。外部モデルとして OpenAI の GPT-5.6 Cyber と Anthropic の Mythos を併用しています。Agents SDK、AI Gateway、Containers は言及されていません。
顧客向けには、WAF / DDoS protection / Magic Transit などを使っている場合にアカウントチームへ Managed Defense の追加を相談できるとしています。Custom Managed レベルと継続稼働型エージェントは今後の予定です。Clef はオープンソースの決定モデルですが、harness 本体のコードは公開されていません。
何が変わったか
- evidence grounding を中核にしたマルチエージェント harness の構成が公開（事例解説）
- モデルを呼ぶ前に、決定論的コードがバージョン管理された API 呼び出しで証拠を収集する
- 各調査にバージョン付きの証拠パッケージを与え、専門エージェントはそこから引用する
- アプリケーションコードが、引用の実在・調査への帰属・主張の裏づけを検証する
- Clef（Workers AI 上で実行）が誤検知らしさをスコアリングし、ノイズは専門分析を飛ばす
- 4つの専門エージェントを並列実行（トラフィック分析 / 顧客コンテキスト / グローバルテレメトリ〈集計値のみ〉/ 脅威インテリジェンス）
- synthesis エージェントは新しい証拠を取得できず、承認された語彙の外から分類を選べない
- アドバイザリは**「未確認」「確認したが一致なし」「不在の証拠を確認」を区別**する
- モデルはテナント境界を越えられず、アナリストの代わりに行動もできない。 最終判断はアナリストの責任
- 使用製品: Workers / Workers AI / Workflows / D1 / R2 / Durable Objects / Flue / AI Search
- 外部モデル: OpenAI GPT-5.6 Cyber、Anthropic Mythos
- Agents SDK / AI Gateway / Containers は言及なし
- Managed Defense の早期ベータを告知。WAF / DDoS protection / Magic Transit などの利用が前提で、アカウントチーム経由
- Custom Managed レベルと継続稼働型エージェントは今後の予定
- Clef はオープンソースだが、harness 本体のコードは非公開
業務インパクト（一般企業向け）
この記事の価値は、Cloudflare の製品を使うかどうかとは独立しています。 エージェントを業務判断の手前まで使う構成を設計するとき、参照できる実装パターンが1つ公開されたということです。しかも設計原則の部分は製品を問いません。
持ち帰れる原則は3つです。
1つ目、証拠収集を決定論的コードへ寄せる。 「モデルに必要な情報を取ってこさせる」のではなく、モデルを呼ぶ前にコードで集めてスコープを固定する。 これは一見エージェントの自律性を削る設計ですが、何を見て判断したかが再現可能になります。 監査が必要な業務では、この再現性が導入可否を分けます。「なぜこの判断になったのか」を後から説明できない構成は、審査を通りません。
2つ目、引用を機械的に検証する。 プロンプトで「根拠を示して」と頼むのと、出力された引用が実在するかをコードで確認するのは、信頼性の水準が違います。前者は守られたか確認できず、後者は確認できます。社内文書を参照して回答するシステムを作っている組織は、「参照元が実在するか」をアプリ側でチェックするという一手間を入れるだけで、品質の性質が変わります。
3つ目、「調べていない」と「調べて何もなかった」を分ける。 これが実務では最も見落とされます。データが取れなかったことを「問題なし」として出力するシステムは、安全側ではなく危険側に倒れます。 自社の AI システムの出力を見直して、この2つが区別されているかを確認する価値があります。区別されていなければ、出力フォーマットに状態を追加するという具体的な改修になります。
Managed Defense 自体は対象が限られます。 WAF / DDoS protection / Magic Transit などを使っている Cloudflare 顧客で、アカウントチーム経由の相談です。早期ベータなので、本番の運用体制に組み込む段階ではありません。中小企業で WAF を使っている場合は、アカウントチームに該当するかを確認してみる価値はあります。
harness 本体が非公開である点は、現実的な制約として押さえてください。 構成は読めますが、コードはありません。自分で作る前提の参考資料です。Clef だけはオープンソースの決定モデルとして公開されています。
副業・個人活用視点
「エージェント構成の設計ができる」ことが単価に直結する領域で、良い教材が1つ増えました。 現場で「AI エージェントを入れたい」という相談は増えていますが、デモを作れる人と、業務判断の手前まで信頼できる構成を設計できる人の差は大きいです。 この記事は後者の具体例で、しかも大手が実運用している構成です。提案資料で「こういう構成が実運用されています」と示せる材料になります。
小規模でも真似できる部分から入るのが現実的です。 4つの専門エージェントを並列実行する部分は規模が必要ですが、「モデルを呼ぶ前にコードで情報を集める」「引用の実在をコードで確認する」「未確認とデータなしを分ける」の3つは、1人で作るシステムにもそのまま入ります。 工数はそれぞれ数時間です。これだけで「それっぽく動くデモ」と「人に渡せるもの」の差が埋まります。
受託案件での差別化の軸になります。 クライアントに AI を提案すると、必ず「嘘をつかないか」と聞かれます。「プロンプトで指示しています」と答えるか、「参照元が実在するかをコードで検証しています」と答えるかで、提案の重みが変わります。 後者は実装工数が乗りますが、その工数を説明できる根拠として、大手の実運用事例を引けるのは強い材料です。
ハルシネーション対策の提案を「プロンプト改善」で止めないことです。 プロンプトエンジニアリングは安く速いので提案しやすいのですが、検証手段がないという弱点があります。 検証をコードへ寄せる構成を提案できると、単価の高い仕事に届きます。この記事はその設計を言語化する助けになります。
Workers / Workflows / D1 / R2 / Durable Objects の組み合わせは、個人開発でも手が届く構成です。 Cloudflare の無料枠・低額枠で同じ部品が使えるので、小さく組んで実装感覚を掴むことができます。 「状態は D1、証拠アーティファクトは R2、段階の調整は Workflows」という役割分担は、そのまま小規模構成の設計指針として使えます。