AIを使った脆弱性調査は、もう「どのモデルが賢いか」を比べる段階を少し過ぎて、実際のコードで何を見つけられるかが問われ始めている。AISLEのブログは、その変化をかなり露骨な形で示した。curlという、世界中で使われ、しかも何度も目を通されてきたはずのコードベースで、OpenAIとAnthropicのシステムが空振りしたあとに、AISLEが6件のCVEを拾ったというのだ。単なる自慢話に見えて、実際には「汎用モデル」と「専用システム」の差がどこで出るのかを考えさせる材料になっている。
元記事が伝えているのは、AIを使ったセキュリティ調査の結果が、同じ対象でもシステムによって大きく変わった、という話だ。curlの開発者であるDaniel Stenbergは、2026年8月24日に、次のリリースに向けて保留中のCVEは3件しかないと書いていた。そのうえで、AnthropicのMythosとOpenAIのCodex Securityにcurlを見せたところ、Mythosは「これ以上見つからない」とし、Codex Securityは空の一覧を返したとされる。
その後、AISLEが自社の自律型AIシステムでcurlを調べた。すると翌日、Daniel Stenbergは「Mythos: 0 Aisle: 29」と投稿した。これは、Mythosが0件、AISLEが29件の報告を出した、という意味だ。もちろん29件すべてがそのままCVEになったわけではない。そこからcurlのセキュリティチームが確認し、数日以内に6件が深刻だと判断され、公開CVEとして扱われた。対象は curl 8.22.0 に入り、すでに修正済みだという。
6件の内容は、OpenSSL provider の use-after-free、OpenSSL pinning bypass、native CA store の connection reuse、タブ文字を使った secure attribute bypass、wolfSSL の CA-cache hit が callback を上書きする問題、domain-scoped public-suffix cookie などだ。付けられた番号は CVE-2026-80229、80230、80231、80255、82208、82209。いずれも Low severity とされている。この記事では、curlの保守担当者が実際にコードを見て、本当に問題があると認めたものだけがCVEになった点を強調している。
さらに、これは一般的なベンチマークではないとも説明している。CTFのように答えが用意された課題ではなく、学習データに載っているかもしれない既知問題でもない。実際の production code を相手にし、しかも「これは本物か」「CVEにする価値があるか」はcurl側が決めた。比較の基準になったOpenAIとAnthropicのゼロ件報告は、AISLEの結果より前に、日付付きで公開されていた。だから「後出しで都合よく見せた」のではなく、先に空振りが公表され、そのあとでAISLEが見つけた、という順序がはっきりしている。
記事は、この結果をcurlだけの偶然ではないかもしれない、とも示唆する。Linux stable releases の長年の保守担当者である Greg Kroah-Hartman は、Danielの投稿に対し、Linuxでも同じようなことが起きていると反応した。「Aisleが何をしているのか分からないが、すごい」といった趣旨のコメントだ。AISLEはこれを、自分たちが掲げる「System over Model」仮説の裏づけだと位置づけている。つまり、最先端の大規模モデルそのものより、特定用途に最適化したシステムのほうが、実戦的なゼロデイ発見では勝つことがある、という主張である。
この話でまず面白いのは、AISLEが「29件見つけた」と言っていることそのものより、そこから6件が実際のCVEになった点だと思う。セキュリティ分野では、ツールが大量の警告を出すこと自体は珍しくない。ただ、その多くはノイズで終わる。だから本当に重要なのは、どれだけ派手な件数を出したかではなく、専門家が見て「これは本物だ」と認めた数だ。curlの保守側が短期間で6件をCVEにしたなら、それは少なくともゼロではないし、しかも偶然のヒットでは片づけにくい。
一方で、Low severity というラベルも見落とせない。これは「大したことがない」という意味ではなく、curlのように長く使われ、何度も監査されてきたコードでは、残る欠陥が狭い条件や微妙な組み合わせに偏る、ということを示している。つまり、AIが見つけたのは大穴というより、条件付きで悪さをする細い綻びだ。ここには現実味がある。実運用で怖いのは、目立つ致命傷だけではない。設定の組み合わせが少し違うだけで発火する、見落とされやすいバグのほうが、保守現場では厄介だからだ。
元記事は、OpenAIやAnthropicの結果を「ゼロ」と対比しているが、ここを単純な勝ち負けにすると少し雑になると思う。汎用モデルは、幅広い質問に応じる代わりに、探索のやり方や検証の粘り方が一定ではない。対してAISLEは、記事の書きぶりからすると、脆弱性探索に特化した自律システムとして組まれている。もしそうなら、同じ「AIをコードにかける」という行為でも、実際には別競技に近い。
ここで重要なのは、モデルの知識量よりも、どんな手順でコードを掘るかだと思う。脆弱性発見は、単に怪しい箇所を文章として説明する力だけでは足りない。条件分岐、設定差、ライブラリとの相互作用、古いコードパスの再利用、そういう地味な場所を執拗に追えるかが効いてくる。AISLEが強かったのだとすれば、それは「賢い言語モデルだから」ではなく、「探し方がしつこいから」ではないか。元記事が強調する System over Model という言い方は、まさにそこを突いている。
Greg Kroah-Hartman が Linux でも同様の傾向を見ていると述べたのは、かなり重いサインだと思う。curlだけの珍事なら、「特定のコードにたまたま刺さった」で済む。しかし、Linux のような巨大プロジェクトでも似たことが起きるなら、特化型システムがコード監査の一部を担う余地はかなり大きい。保守者側からすると、期待したいのは華々しいデモではなく、毎回少しずつでも見落としを拾ってくれる道具だ。
ただし、ここで安心しすぎるのも危ない。AIがCVEを見つけたからといって、人間のレビューが不要になるわけではないし、逆にAIの報告件数だけで品質を測るのも危うい。今回の価値は、AISLEが自動で全部を確定したことではなく、最終判断をcurlの保守側が握っていたことにある。つまり、AIは発見の入口であり、責任の主体ではない。この役割分担が守られる限り、AIはかなり強い道具になる。ただし、そこを取り違えると、ノイズの山だけが増えるはずだ。
この記事は、AI競争の見方を少し変えている。派手に見えるのは「OpenAIとAnthropicがゼロ、AISLEが6」という数字だが、実際には、どの会社のモデルが何点かより、どういうシステム設計で、どのコードを、どんな確認手順で掘ったかが効いている。ここを見ないと、次の比較でも同じ勘違いをするだろう。
セキュリティの現場では、今後こうした差がもっとはっきり出るかもしれない。汎用モデルは便利だが、狙いを絞った探索では専用設計に負けることがある。逆に言えば、AI導入の価値は「最強モデルを使うこと」ではなく、「現場の課題に合わせて探索系を組めること」に移っていくのではないか。curlの件は、その先触れとして読むのが自然だと思う。
参考: AISLE Discovered Six curl CVEs After OpenAI and Anthropic Found Zero
