Cloudflare が本番トラフィックを根拠に脆弱性を優先付け — OpenAI の GPT-5.6 Cyber を AI Gateway 経由で使う

要約

2026-09-03、Cloudflare が Cloudflare Managed Defense に 文脈認識型（context-aware）の脆弱性発見・修正機能を追加したと発表しました。

中心的な発想は1つです。コードの静的解析だけで危険度を決めない。

汎用のリスクスコアではなく、本番トラフィックとセキュリティイベントのデータを組み合わせて優先順位を付けます。 「そのコードは理論上危険か」ではなく、**「そのエンドポイントは実際に叩かれているか、攻撃を受けているか」**を判断材料に入れる、ということです。

使用する Cloudflare 製品と、それぞれの役割は明確に分かれています。

• WAF — セキュリティイベントのデータ供給と、カスタムルールの適用先
• Web Assets — 有効なルートのインベントリとトラフィック情報
• Workers — スキャン対象としてサポートされるアプリケーション実行環境
• Workers Observability — リクエストのメタデータとエンドポイント利用状況

そして、AI 側の役割も明示されています。

OpenAI の GPT-5.6 Cyber が、コードベースに対する偵察（reconnaissance）・探索（hunting）・検証（validation）を担当します。 実行は OpenAI 側のインフラ上で、AI Gateway を経由します。

重要なのは、モデルの出力がそのまま顧客に届くわけではない点です。 モデルが脆弱性候補とパッチ案を出したあと、Cloudflare 側のハーネスが、顧客へ提示する前にすべての検出結果を検証します。

処理は5段階です。

1. コンテキスト収集 — 有効なルート、トラフィック量、セキュリティイベントのスナップショットを取得 2. コード解析 — 偵察エージェントがコードとエンドポイントを対応付け、ハンターが特定箇所の弱点を探索 3. 優先順位付け — ソースコード解析に加え、**ネットワーク側の証拠（トラフィック量・攻撃の活発さ）**でリスク評価 4. 緩和策の提示 — コードパッチ案と、脆弱なエンドポイントに絞った保守的な WAF ルールの両方を提案 5. レビュー — 顧客が見る前に検証を通す。適用の最終判断は顧客が持つ

提供形態は、Cloudflare Managed Defense 経由の招待制 early access です。 価格の記載はなく、公式は「Cloudflare のアカウントチームに相談してほしい」としています。

なお、同日 OpenAI が発表した Daybreak Defense Network（35を超えるエンタープライズ製品・パートナー運営サービス）の、具体的な実装例の1つにあたります。**「Daybreak のサイバーモデルを、防御者が既に使っているツールの中へ持ち込む」**という OpenAI 側の説明が、Cloudflare 側では実装として現れています。

何が変わったか

• Cloudflare Managed Defense に文脈認識型の脆弱性発見・修正を追加
• 静的解析だけで危険度を決めず、本番トラフィックとセキュリティイベントで優先順位を付ける
• 使用製品: WAF（イベント供給・ルール適用先）、Web Assets（ルートとトラフィック）、Workers（スキャン対象）、Workers Observability（リクエストメタデータ）
• OpenAI の GPT-5.6 Cyber が偵察・探索・検証を担当。 実行は OpenAI 側インフラ上、AI Gateway 経由
• Cloudflare 側のハーネスが、顧客提示前にすべての検出結果を検証
• 出力は コードパッチ案 と 脆弱なエンドポイントに絞った保守的な WAF ルール の2本立て
• 適用の最終判断は顧客が持つ
• 提供: Managed Defense 経由の招待制 early access。価格の記載なし
• 同日発表の OpenAI Daybreak Defense Network（35超）の実装例の1つ

業務インパクト（一般企業向け）

この発表は、招待制の early access なので「今すぐ導入」の話ではありません。しかし考え方は、自社の脆弱性管理へそのまま持ち込めます。論点は3つです。

1つ目は、脆弱性の優先順位を何で決めるか、という問題です。

多くの組織で、脆弱性対応の優先順位は CVSS スコアで決まっています。 そしてこれがうまく機能していないことも、現場では広く知られています。

理由は単純で、CVSS は「そのコードが理論上どれだけ危険か」しか見ていないからです。 実際には、外部から到達できないエンドポイントの Critical より、毎日攻撃を受けている入口の Medium の方が危険です。同じスコアでも、置かれている状況で危険度は変わります。

今回の設計は、そこに証拠を持ち込んでいます。 有効なルートか、どれだけトラフィックが来ているか、実際に攻撃イベントが出ているか——ネットワーク側の事実で優先順位を補正する。

この考え方は、Cloudflare を使っていなくても実行できます。 アクセスログ、WAF のログ、ロードバランサのメトリクス——「実際に叩かれているエンドポイント」のリストは、たいていの組織が既に持っています。 脆弱性リストとこのリストを突き合わせるだけで、優先順位の精度は上がります。 特別なツールが要る話ではありません。

2つ目は、パッチと WAF ルールを同時に出す、という設計です。

これは実務的に非常に理にかなっています。

脆弱性が見つかってからコードを直すまでには時間がかかります。 修正、レビュー、テスト、リリース。その間、脆弱性は開いたままです。

WAF ルールは、この待ち時間を埋めるための手当です。 恒久対策ではありませんが、修正がリリースされるまでの露出を減らせます。 公式が 「脆弱なエンドポイントに絞った保守的な（conservative）ルール」 と書いている点も重要で、広く網を掛けて正常な通信まで止めるのを避ける設計になっています。

自社の運用に持ち込むなら、「脆弱性が見つかったとき、恒久対策と暫定緩和をセットで検討する」というルールにできます。 多くの組織では恒久対策だけを追いかけて、その間の露出を放置しています。

3つ目は、AI の出力を人が検証する構造です。

注目すべきは、AI が出した結果をそのまま顧客に見せていない点です。 Cloudflare 側のハーネスが、提示前にすべて検証します。 そして 適用の最終判断は顧客が持ちます。

これは、セキュリティ領域で AI を使う際の妥当な構成です。 脆弱性スキャンで最も嫌われるのは誤検知です。大量の誤検知は、ツール自体を信用されなくする——現場が「どうせまた誤検知だ」と全体を無視し始めれば、本物も見落とされます。

AI を使ったセキュリティツールを評価するときの質問は、ここから導けます。 「どのモデルを使っていますか」ではなく、「出力を誰が、どうやって検証していますか」。検証工程を持たず、モデルの出力を直接見せるツールは、誤検知のコストを利用者に押し付けています。

なお、データの流れは把握しておく必要があります。 コード解析は OpenAI 側のインフラ上で行われ、AI Gateway を経由します。 自社のソースコードとトラフィックのメタデータが、どの範囲まで、どこへ渡るのか——招待を受けて検討する段階になったら、契約とデータ取り扱いの確認は必須です。 便利さの評価とデータフローの確認は、別々に行ってください。

副業・個人活用視点

個人や小規模事業者が直接使う機能ではありません。招待制で、Managed Defense はエンタープライズ向けです。ただし、3つ持ち帰れます。

1つ目は、優先順位付けの考え方を、そのまま提案に使えることです。

中小企業のセキュリティ相談で最も多いのは、「脆弱性スキャンをかけたら大量に出てきて、手が付けられない」という状態です。

ここで「全部直しましょう」と言うのは、実質的に何も言っていないのと同じです。 予算も人手も足りないから止まっているわけで、優先順位を付けられないことが問題の本体です。

今回の考え方は、そこに使えます。 「外から到達できるか」「実際にトラフィックが来ているか」「攻撃イベントが出ているか」で並べ替える。 アクセスログと WAF のログがあれば、特別なツールなしで実行できます。

そして、これは説明しやすい。 「CVSS が高いから」より、**「このエンドポイントは毎日攻撃を受けています」**の方が、経営層に伝わり、予算が付きます。 技術的な正しさと、説得力の高さが一致する数少ない場面です。

2つ目は、暫定緩和という選択肢を提案に含めることです。

「直すまで時間がかかります」で止まる提案と、「恒久対策はこの日程です。それまでの露出はこの方法で抑えます」と言える提案では、相手の安心感が違います。

そして後者は、実は工数がそれほど増えません。 WAF ルール、アクセス制限、機能の一時停止——選択肢を知っているかどうかの差です。「時間がかかる」と「その間どうするか」をセットで出せるかが、提案の質を分けます。

3つ目は、AI ツールの評価軸です。

AI を組み込んだツールが増え続けるなかで、「どのモデルを使っているか」を判断材料にするのは、あまり意味がありません。 モデルは頻繁に入れ替わります。

見るべきは、出力をどう扱っているかです。 検証工程があるか、誤検知をどう抑えているか、最終判断が誰にあるか。

今回の Cloudflare の設計——モデルは OpenAI、検証はハーネス、適用判断は顧客——は、この3層が明確に分かれています。 この分離ができているかどうかを、AI ツールを選ぶときの質問にする。

そして、自分が AI を組み込んだものを作って納品するときも、同じ質問が返ってきます。 「AI が出した結果を、誰がどう確認しているのか」——ここに答えを用意していないものは、業務では使ってもらえません。モデルの賢さではなく、間違ったときの受け止め方を設計できているかが評価されます。