Cloudflareが公開したこの記事は、AIを使った脆弱性調査の「現場感」がかなり濃いです。
しかも単なる未来予想ではなく、実際に自社の50以上のリポジトリに Mythos Preview を当ててみた結果がベースになっています。
率直に言うと、この記事の面白さは「AIがバグを見つけました」では終わらないところです。
むしろ本題は、AIが“攻撃の筋道”を組み立てられるようになってきたこと。そして、その力を本当に使うには、モデル単体では足りず、周辺の仕組みづくりが必要だ、という点にあります。ここはかなり重要だと思います。
Cloudflareの見立てでは、Mythos Previewは「ちょっと良くなった」ではなく、前の世代の一般的な frontier model とは別物に近いそうです。
frontier model は、要するに最先端クラスの大規模モデルのことです。
特に目立ったのは次の2つです。
これは、複数の小さな弱点をつないで、実際に使える攻撃の流れにする能力です。
たとえば、1個のバグだけでは大したことがなくても、
みたいに、細かいピースを組み合わせると本物の攻撃になります。
ROP chain は、ざっくり言うと既にあるコード片をつなぎ合わせて攻撃を成立させるテクニックです。
ここがすごいのは、Mythos Previewが単に「怪しい箇所」を列挙するのではなく、どうつなげば攻撃になるかを考えられる点です。Cloudflareは、これはまるでシニア研究者の仕事みたいだと評価しています。いや、これはかなり強い表現です。実際、そのくらいインパクトがあるのでしょう。
もうひとつは、見つけたバグを実際に証明するコードまで作ることです。
流れとしては、
というループになっています。
ここ、個人的にかなり面白いです。
脆弱性研究って、結局は「本当に再現できるのか？」が命なんですよね。怪しい指摘は山ほど出る。でも、再現できなければ修正優先度も判断しづらい。Mythos Previewはそのギャップをかなり埋めている、という話です。
記事では、Mythos Preview には一般公開モデルにあるような追加の安全機構がなかった一方で、モデル自身が勝手にブレーキをかけるような拒否をする場面もあったと説明しています。
ただし問題は、その拒否が一貫していないことです。
同じコードを見ていても、
ということが起きたそうです。
これはAIらしいといえばAIらしいのですが、セキュリティ用途ではかなり厄介です。
なぜなら、「モデルがたまに断るから安全」とは言えないからです。
Cloudflareの主張は明快で、将来一般公開するレベルの cyber frontier model には、こうした自然発生的な拒否に頼るのではなく、追加の安全策が必要だということです。これはもっともだと思います。気分屋の門番は、門番としては頼りないですから。
脆弱性調査で本当に大変なのは、バグを見つけることよりも、それが本物か、悪用可能か、今すぐ直すべきかを見分けることです。
この「見極め」の難しさを、記事はかなり率直に語っています。
C や C++ は、メモリを直接いじれるぶん、
のようなバグが起きやすいです。
一方、Rust のような memory-safe language は、コンパイル時にこうした事故をかなり防げる。
つまり、AIが同じように見ていても、C/C++ の方が false positive（誤検出）が多くなりやすいわけです。
ここも実にAIっぽい話です。
人間の研究者なら、「見つけたもの」と「どれくらい確信があるか」をセットで話します。
でもモデルは、聞かれたら何かしらのバグを見つけようとする。
その結果、
みたいな、かなり慎重そうで実は曖昧な指摘が大量に出ます。
探索ツールとしてはいい。でも、triage queue（優先度付けの列）では最悪です。人間が一個ずつ読んで捨てるコストが積み上がるからです。
ここは「AIが賢いか」より、AIの出力をどう扱うかの問題なんですよね。かなり現場的な論点だと思います。
それでも Mythos Preview は、ただの検出器より良い結果を出したそうです。特に、
という点が強い。
要するに、**“怪しい”レポートの山ではなく、行動できる報告に近づいた**ということです。これは大きいです。
最初に思いつくやり方は、「コーディング用AIにリポジトリを読ませて脆弱性を探させる」だと思います。
でもCloudflareは、これはそれっぽく動くけど、実用的なカバレッジが出ないと言っています。
理由は2つです。
coding agent は基本的に、
みたいな、一本の筋で進む作業が得意です。
でも脆弱性調査は、
狭く、並列に、何千回も別の仮説を試す仕事です。
人間の研究者も、リポジトリ全体を漫然と眺めるわけではなく、
を、狭く切って調べます。
単一の agent セッションで100,000行規模の repo を回すと、実用的なカバレッジはごくわずか。しかも context window が埋まると、過去の重要情報が圧縮されて消えることすらある。
これ、地味だけどかなり致命的です。
脆弱性調査では、1個ずつ順番にやるより、同時並行でたくさんの仮説を回す方が強いです。
でも単一の agent は、基本的に1つのことを1回にやる。
つまり、形そのものが違う。
だから、Mythos Preview をそのまま会話相手として使うのではなく、周辺にharnessを作る方向に切り替えた、というのがCloudflareの結論です。
harness は、ざっくり言うと モデルをうまく回すための実行基盤 です。
チャット画面ではなく、仕事の流れ全体を管理する仕組み、と考えるとわかりやすいです。
記事では、スケールさせる中で次の4つが重要だと分かったとしています。
「このrepoの脆弱性を全部探して」よりも、
のように絞った方が、モデルは人間に近い動きをするそうです。
これはかなり納得感があります。
広く浅くはAIが得意そうに見えて、脆弱性調査ではむしろ逆で、狭く深く切る方が強いんですよね。
最初のモデルが出した結果を、別の agent が
という立場でチェックする。
この「わざと食い違う役」を作ると、ノイズがかなり減るそうです。
これは面白い発想です。
1人に「慎重にやって」と言うより、2人を喧嘩させる方が精度が上がる、ということですから。人間のレビュー文化にも通じます。
「このコードはバグっているか」と
「外部の攻撃者が本当にそこへ到達できるか」は、別問題です。
これを1つで聞くより、別々の問いに分ける方が、モデルはうまく考えられる。
人間でも同じで、問いが長くなるほど判断が雑になりがちです。
「全部やってくれるAI」より、
狭い仕事をたくさん並列で回して、最後に重複排除する方が、カバレッジは上がる。
ここは、かなり実務的で、たぶん今後のAI運用全般に効く考え方だと思います。
この記事を読んで一番強く感じたのは、モデル単体の性能競争ではもう話が終わらないということです。
Mythos Preview は確かに強い。
でも本当に効いているのは、
という、周辺の設計です。
言い換えると、これからのセキュリティAIは「頭のいい1体」を持つだけでは足りず、組織としての調査フローを再設計する必要がある、ということだと思います。これは面倒ですが、かなり本質的です。
Cloudflareのこの記事は、AIによる脆弱性研究が「夢物語」ではなく、すでにかなり実戦的な段階に入っていることを示しています。
特に Mythos Preview は、単発のバグ検出ではなく、複数の弱点をつないで実際に使える攻撃形にする点が強い。
ただし、同時に見えてきたのは、AIの出力はそのままだとノイズが多く、拒否も一貫せず、単体のチャットではスケールしないという現実です。
だからこそ必要なのは、モデルをありがたがることではなく、harnessを作って使いこなすこと。ここに、これからの実務の勝負所があるのだと思います。
