AIは本当に脆弱性を「発見」したのか — Mythosのcurl/FreeBSD報告で露わになった3つの問題

はじめに

2026年4月、AnthropicがClaude Mythos Previewを発表した時、セキュリティ業界はざわついた。「OpenBSDで27年生き残ったバグ」「FreeBSD NFSの未認証RCE（CVE-2026-4747）」「Firefoxへの181回成功する攻撃」——前世代Opus 4.6比で桁違いの数字が並んだプレスリリースは、AIによる脆弱性発見が新たなフェーズに入った印象を強く与えた。

ところが5月に入り、状況は一変する。curl作者Daniel Stenberg氏の検証報告、独立リサーチャーによる訓練データ汚染の指摘、競合のAISLEによる「小型モデルでも同じ脆弱性を発見できた」という反証。Hacker Newsで529pts、Reddit r/programmingで755ptsを集めたこれらの議論は、「AIが脆弱性を発見する」という言明そのものを技術的に再検証する契機になった。本記事では、Mythosをめぐる3つの問題を整理する。

問題1: curl作者による「5件中4件は誤検知」検証

Daniel Stenberg氏は、Mythosがcurlに対して報告した5件の「確認済み脆弱性」を1件ずつ精査した。結果は容赦ない。

3件が偽陽性（false positive）: コードを誤読した結果の架空の脆弱性
1件は脆弱性ではなく単なるバグ: 動作不良はあるがセキュリティ影響なし
1件のみ実在: しかも severity: low でCVE発行予定

Stenberg氏のブログは、Mythosのマーケティング上の華々しさと、実プロジェクトでの検証結果のギャップを淡々と指摘している。彼は「AI駆動の脆弱性発見が従来型ツールより明らかに優秀」という事実は認めつつも、「他のAIツール（AISLE、Zeropath）と比べて特別優れているわけではない」「まったく新しい種類の脆弱性は1件も報告していない」と結論づけた。

この「新規性の欠如」が、次の問題に直結している。

問題2: 訓練データ汚染 — 「発見」と「想起」をどう区別するか

Mythosの目玉とされたCVE-2026-4747（FreeBSD NFSサーバーの未認証RCE）について、rival.securityの研究者は決定的な検証を行った。彼らは2007年のKerberos実装と2026年のFreeBSD該当コードを並べ、両者が「virtually identical」であることを示した。同じバッファオーバーフロー欠陥、同じ関数構造、さらにFreeBSDが採用したパッチパターンまで2007年版とほぼ同一だった。

つまりMythosが「自律的に発見」したとされた17年眠っていたバグは、LLMの訓練データに含まれていた既知の脆弱性パターンの再現に近い。これは技術的にはcombinatorial creativity（既存知識の組み替えによる「創造性」）と呼ぶべきもので、純粋な未知の発見ではない。

ただしrival.securityはこれを「だから無価値」とは結論づけていない。むしろ強調されているのは別の論点だ：

レガシー脆弱性の再生産: LLMがコード生成に広く使われている現在、訓練データの不安全パターンが新しいコードに繰り返し焼き込まれている
発見コストの劇的低下: 攻撃側にとっても、訓練データ由来のパターンマッチで巨大コードベースを横断的にスキャンできる
評価方法の再定義: 「AIが脆弱性を発見した」という主張は、訓練データとのコンタミネーション検証を経て初めて成立する

ベンチマークでAIモデルを評価するとき、訓練データに答えが含まれていないかを検証するのは基本中の基本だ。脆弱性発見でも同じ原則が適用されるべきというのが、コミュニティの合意になりつつある。

問題3: フロンティアモデル独占という幻想 — AISLEの反証

AnthropicはMythos PreviewへのアクセスをProject Glasswingという限定パートナーシップ経由で提供しており、「フロンティアモデルにしかできない能力」という位置づけを取っている。これに対しAISLE（OpenSSLで15件のCVEを発見した実績を持つ競合）は、技術的に明確な反証を出した。

AISLEのテストでは、Mythosが看板にしたFreeBSD RCE脆弱性を、8つのモデル中8つすべてが検出した。その中にはオープンウェイトの小型モデル（3.6B〜5.1Bパラメータ）も含まれる。さらに興味深いのは、「最強のモデル」が存在しないという観察だ。

3.6BパラメータのモデルがFreeBSD検出で5.1Bモデルを上回り、OpenBSD SACK分析ではその関係が逆転する。

AISLEはこれを “Jagged Frontier”（ギザギザのフロンティア） と呼ぶ。AIセキュリティ能力はモデルサイズに対し滑らかにスケールせず、タスクごとに勝者が入れ替わる。

ここから導かれる重要な実務的示唆がある。競争優位はモデルそのものではなく、それを取り囲むシステムにある。脆弱性発見パイプラインは少なくとも5つのモジュールに分解できる：

モジュール	役割	フロンティアモデル依存度
広域スキャン	大規模コードベースの探索	低
脆弱性検出	怪しい箇所の特定	低
トリアージ／検証	真陽性と偽陽性の判別	中
パッチ生成	修正提案	中
エクスプロイト構築	実証コード生成	高

検出層は誰でも作れる。差がつくのは、False positiveをふるい落とすシステム設計と、メンテナへ届ける時の出力品質だ。AISLEがOpenSSLの「high quality reports」と評価された理由はここにある。AnthropicのMythosが特殊だったのは能力そのものではなく、評価チームを抱えて世界へ広報できるリソースだった、という見方が広がりつつある。

エンジニアへの影響 — 何を学び、何を実務に持ち帰るか

Mythos騒動から実務エンジニアが取り出すべき教訓は3つある。

1. AIのセキュリティ報告は必ず人間が検証する。 Mythosの誤検知率（5件中4件）は氷山の一角ではない。AIによる脆弱性報告は確率的な仮説生成にすぎず、CVE化する前にコードを読んで再現確認する工程は省略できない。GitHubでAI生成のセキュリティPRが急増している今、メンテナ側の検証コストが新たなボトルネックになっている。

2. 訓練データ汚染を前提に評価する。 AIツールを社内導入する際は「このツールはどの時点までの公開CVEを訓練データに含むか」を必ず確認する。未知ゼロデイの発見能力と、既知パターンのコード横断検索能力は別物だ。前者を期待してコストを払うと裏切られる。

3. パッチサイクル短縮への投資。 攻撃者がAIを使えば、N-day脆弱性（既知だがパッチ未適用）のエクスプロイト化が劇的に速くなる。これは確定的な変化だ。検出側の精度議論とは独立に、組織のパッチ適用パイプラインを自動化する投資は今すぐ正当化できる。Anthropic自身も「インシデント対応の自動化推進」「脆弱性開示ポリシーの見直し」を防御側への提言として明記している。

まとめ

Mythosの「自律的な脆弱性発見」は、技術的検証を通じて以下のように姿を変えた。

curl報告は誤検知8割。新規性ある脆弱性はゼロ
FreeBSD CVE-2026-4747は訓練データに事実上含まれていた
検出能力は小型オープンモデルでも再現可能。フロンティア独占という幻想は崩れた

ただしこれはAIセキュリティの否定ではない。AIによるコード分析が実用段階に入ったからこそ、評価基準が「マーケティング主張」から「再現可能な検証」へ移行している——その健全な転換点が今回の議論だ。次に飛び込む「自律発見」の宣伝を見たら、まず訓練データ範囲とfalse positive率を確認したい。

今日のその他のニュース

Chrome DevTools MCP がブレイクスルー段階に（はてブ450 users）。LLMから直接ブラウザのDOM解析・操作が高精度に行える環境が一般化し、AIエージェントによるブラウザ操作自動化の事例が爆発的に増えている。

Bun、ClaudeでZig→Rustへ大規模移行（Publickey）。JSランタイムBunの中核実装言語を、AIペアプログラミングを前提にRustへ移行中。AI時代の言語選定とリファクタ戦略の最新事例。

Hardware Attestation as Monopoly Enabler（HN 2012pts）。GrapheneOSによる論考が大反響。Web認証やOS配布まわりで、HW証明書ベースの認証が市場独占を強化する構造を批判している。