脆弱性の山を、AIが仕分けて塞ぎに行く。Cloudflareの新機能で人間は何を判断するのか

まず初めに

IT Postでは、この分野の最大の問題は「見つけられないこと」ではなく、「見つけすぎること」だと考えている。

脆弱性の検査ツールを走らせたことがある人なら分かるはずだ。ボタンを押すと、数千行の指摘が出てくる。全部が危険だと言う。全部が緊急だと言う。読み終わる頃には次の検査の時間が来る。まるで、健康診断で全項目に赤い印を付けて「全部気をつけてください」と言い放つ医者だ。ありがたい。ありがたいが、それで何をすればいいのか。

だから今回の発表で目を引いたのは、AIで見つけるという部分ではない。どれから手を付けるかを決めようとしている、その一点だ。

※個人の感想です

何を自動化するのか。手順を分解する

Cloudflareの公式ブログによると、この機能は次のような流れで動きます。

1. 対象サイトに届いている通信と、Webアプリケーションファイアウォールが記録した防御の状況を取得する
2. ソースコードを分析し、脆弱性の候補を洗い出す
3. 偵察ていさつ役のエージェントが、実際に外から到達できる経路と、その先にあるコードを対応づける
4. 探索役のエージェントが、許可された範囲のコードを詳しく調べる
5. ソースコード上の根拠に基づいて、見つかったものを検証し、危険度を評価する
6. その箇所へ実際に通信や探りが来ている場合は、危険度の評価を引き上げる
7. コードの修正案と、ファイアウォールの独自ルールの案を提示する
8. 承認された場合のみ、範囲を絞った形でルールを適用する

ここで重要なのは6番です。同じ深刻度の脆弱性でも、誰も辿り着けない場所にあるものと、いま実際に叩かれている場所にあるものでは、対処の緊急度がまったく違います。従来の検査ツールは、コードだけを見るためこの区別ができませんでした。Cloudflareは自社のネットワークを通る通信を見られる立場にあるため、この2つを突き合わせられる、という理屈です。

人間が判断する部分は残る

自動化の範囲について、公式の説明は控えめです。

修正案とファイアウォールのルールは「提示」までであり、実際に適用するのは承認された場合に限られます。しかも適用の範囲は保守的に絞るとしています。つまり、AIが勝手に本番環境のコードを書き換えるという仕組みではありません。

AIに全部任せます、と言い切らないところに、むしろ運用を知っている会社の匂いがする。

危険度の評価も、ソースコード上の根拠に基づくと明示されています。根拠のない推測で「危険です」と言わせない設計です。ただし、AIの判断が常に正しいという保証はどこにもありません。見落としも、逆の誤検知ごけんちも起こり得ます。最終的にどれを直すかを決めるのは、依然として運用する側の人間です。

「脆弱性が多すぎる」という前提

Cloudflareのプレスリリースは、この機能の背景として、2026年9月までに米国の脆弱性データベースが60,475件を記録し、2025年通年の48,185件を上回ったと説明しています。

一方、公式ブログの冒頭にある「4,000件の新規脆弱性のうち78件が最も深刻」といった数字は、優先順位づけの難しさを説明するための想定例であり、この製品が実際に処理した実績値ではありません。IT Postでは、この2種類の数字を混同しないよう区別して扱います。

日本の読者にとって何が変わるのか

まず、この機能そのものは招待制で、対象は選ばれた企業顧客です。個人が申し込んで使えるものではありません。

そのうえで、間接的な意味は2つあります。

1つは、私たちが日常的に使うWebサービスの安全性です。多くの日本企業のサイトもCloudflareを経由しています。修正の優先順位づけが実データに基づいて行われるようになれば、放置される穴が減る可能性があります。可能性であって、確定した効果ではありません。

もう1つは、攻撃側との速度競争です。近年は、脆弱性が公表されてから悪用が始まるまでの時間が短くなっています。IT Postでも、修正版が出た数日後に悪用が確認された事例を扱いました。人手で優先順位を決めていては間に合わない、という現実が、この種の自動化を後押ししています。

なお、AIを使ったサイバー分野の能力向上は、防御側だけの話ではありません。攻撃側も同じ道具を手にします。今回の発表は、その競争の防御側の一手として読むのが妥当です。

用語の整理

言葉	意味
脆弱性	ソフトウェアの弱点。悪用されると不正な操作を許してしまう
CVE	公表された脆弱性に付けられる共通の管理番号
ファイアウォール	通信を検査し、危険なものを遮さえぎる仕組み
早期アクセス	正式提供の前に、限られた顧客だけに提供する段階
エージェント	指示を受けて、道具を使いながら自分で手順を進めるAI

よくある疑問

個人のサイトでも使えるのか。 使えません。招待制の早期アクセスで、対象は選ばれたCloudflare Enterprise顧客です。一般提供の時期は示されていません。

AIが勝手にコードを直すのか。 直しません。修正案とルールの案を提示するところまでで、適用は承認された場合に限られ、範囲も絞るとしています。

どのAIモデルが使われているのか。 OpenAIのDaybreakモデル群で、なかでもGPT-5.6 Cyberが名指しされています。

これで脆弱性はなくなるのか。 なくなりません。優先順位づけと初動を速くする仕組みであり、脆弱性そのものを生まなくする技術ではありません。

IT Postの見方——「全部危険です」を卒業できるか

IT Postでは、この発表の値打ちは、AIを使ったことではなく、AIに何をさせないと決めたかにあると考える。

セキュリティ製品の歴史は、警告の量を増やしてきた歴史でもある。検知できる項目が増えるたびに、担当者の画面は赤くなる。売る側にとって、検知件数は分かりやすい売り文句だ。買う側にとって、それは処理しきれない宿題の山でしかない。誰も読まない警告は、無いのと変わらない。むしろ、読まない習慣を育てるぶん有害だ。

今回、実際に通信が来ている箇所を引き上げる、という発想はまっとうだ。理論上の危険と、いま叩かれている危険を同じ列に並べない。当たり前のことだが、コードしか見えない道具にはできなかった。通信を見ている会社だからできる、という点も、正直で分かりやすい。

適用を承認制にしたのも良い。ここでもし「検知から修正の適用まで全自動」と言い切っていたら、IT Postの評価は逆になっていた。本番環境を勝手に書き換える道具は、脆弱性より怖い。動くものを壊す権限は、そう簡単に渡してはいけない。

ただし、手放しでは褒めない。招待制の早期アクセスであり、対象は大企業だ。脆弱性の放置で本当に困っているのは、専任の担当者すら置けない中小の現場である。そこへ届かない限り、社会全体の穴は塞がらない。高機能な消火設備が、火の少ない建物から順に入っていくようなものだ。

そしてもう1つ。攻撃側も同じ性能のAIを買える。防御の自動化が進んだ分だけ、攻撃の自動化も進む。今回の一手は前進だが、ゴールではない。競争のスタート地点が、また一段上がっただけだ。