Claude Mythos発表後、CVEが異常増加 7月は発表前の5倍に：調査で見えた変化

「AIが脆弱性を見つける」ことが現実になった2026年。AnthropicのClaude Mythos Preview発表後、重大なCVEの公開件数が異例のペースで増えていることが調査結果で示された。これを踏まえて脆弱性対策を考える。

[＠IT]

　Anthropicが2026年4月7日（現地時間、以下同）に発表したフロンティアAIモデル「Claude Mythos Preview」（以下、Mythos）は、ソフトウェアの脆弱（ぜいじゃく）性を取り巻く環境に大きな変化をもたらした。

　Anthropicは同日、Amazon Web Services（AWS）やApple、Microsoft、Googleなどと共に、Mythosを使ってソフトウェアの脆弱性を発見・修正する取り組み「Project Glasswing」を発表した。Anthropicによれば、Mythosは同プロジェクト発表時点で主要なOSやWebブラウザを含むソフトウェアから、数千件の重大な脆弱性を発見していた。

　そして同発表から数カ月後、CVE（共通脆弱性識別子）の公開件数に、これまでにない規模の変化が表れ始めている。

　Epoch AIは2026年8月22日、CVEの動向を調べられる対話型探索ツール「Cyber Vulnerabilities」を公開した。同ツールでは、2022年以降のCVE公開件数や深刻度、CVE Numbering Authority（CNA）ごとの傾向などを可視化できる。

　これを使った調査データによると、Mythosの発表後に重大なCVEの公開件数が急増したという事実が見えてきたという。

Mythos発表後にCVE急増　7月は「発表前の5倍」に

　Epoch AIが追跡している主要21組織では、2026年6月にHighおよびCriticalに分類されたCVEが約1550件公開された。これはMythos発表前の月間記録の3倍を超える水準だ。さらに7月には約2500件まで増加。Mythos発表前の月間記録と比べると約5倍に達した。6月の記録的な増加から、わずか1カ月でさらに約60％増えたことになる。

　ただし、CVE件数の急増をそのまま「世の中の脆弱性が5倍になった」と解釈することはできない。CVEは、脆弱性が発見された日ではなく、CVEとして公開された日を基準に集計される。加えて、CVEの公開件数は、脆弱性を発見する能力だけで決まるものではない。どの組織がCNAとしてCVEを割り当てるのか、どのような不具合にCVEを付与するのかといった運用の違いも、数字に影響するためだ。

　分かりやすい例が「Linux」だ。

　Linuxは2024年2月にCNAとなり、その後、過去のバージョンに修正を移植した不具合などに対しても多数のCVEを割り当てるようになった。その結果、Linux関連のCVE公開件数が増え、2024年と2025年の集計値を押し上げる要因になった。

　つまり、CVEの数字には「脆弱性がどれだけ見つかったか」だけでなく、「どのようにCVEとして公開されたか」も含まれている。

　Epoch AIもこうした違いを考慮し、全CNAのCVEを対象にしながら、組織別の比較では主要なCNAに絞っている。対象にはMicrosoftやGoogle、Apple、Adobe、Oracle、Cisco Systems、IBM、Red Hat、Intel、Advanced Micro Devices（AMD）、NVIDIA、Qualcomm、Samsung Electronics、SAP、AWS、VMware（Broadcom）、GitHubなどが含まれる。

　Epoch AIは、CVEの急増とMythos Previewの発表が重なっていることを示しつつ、AIが増加の原因だったと断定しているわけではない。それでも、Mythos発表後に重大なCVEの公開件数がこれほど急増したことは、AIによる脆弱性発見能力の向上を考える上で無視できない変化だ。

AIで脆弱性発見が爆速化されても“やるべきこと”は変わらない

　ただ、CVEの発見数が増えれば、それだけで安全になるわけでもない。大量に発見された脆弱性を検証し、影響を判断し、CVEとして公開し、ベンダーやオープンソースプロジェクトに通知し、パッチを作成して配布する必要がある。AIによる「発見」の高速化に対し、その後のトリアージや修正、公開のプロセスが追い付かなければ、新たなボトルネックが生まれる。

　特にAIによる発見能力が向上するほど、「本当に自社環境に影響するものを特定する」というトリアージの負荷はむしろ大きくなる。AIによる脆弱性発見の高速化によって、企業側のボトルネックが「見つけること」から「何を直すべきか判断すること」に移っているのだ。

　こうした現状を踏まえて、脆弱性管理のヒントをおさらいしよう。

　1つ目に、優先順位付けの精度と速度を高めることだ。CVSSのスコアだけを見て対応順を決めるのではなく、自社が実際に利用している製品かどうか、インターネットから到達可能かどうか、認証なしで悪用できるかどうか、重要な業務システムに接続しているかどうか、実際に悪用が確認されているかどうか、といった自社環境の情報を重ねる必要がある。

　2つ目に、資産管理と脆弱性管理を切り離さないことだ。CVEが増えれば増えるほど、「その脆弱性が存在するかどうか」だけではなく「どの資産に存在し、誰が管理し、事業にどの程度影響するのか」を即座に把握できることが重要になる。資産台帳やSBOM（ソフトウェア部品表）、クラウド環境、エンドポイントなどの情報を脆弱性管理と結び付け、影響範囲を自動的に絞り込める状態を作っておきたい。

　3つ目に、パッチ適用だけをゴールにしないことだ。緊急パッチが間に合わない場合には、外部公開を止める、アクセス制御を強化する、脆弱な機能を無効化する、仮想パッチを適用するなど、リスクを下げる代替策も必要になる。AIによって「発見から悪用まで」の時間も短縮されれば、従来の「パッチが出てから検討する」という時間感覚では間に合わない可能性がある。

　CVEが増える時代に求められるのは、「全ての脆弱性を一律に素早く直す」ことではない。自社にとって本当に危険な脆弱性を、誰より早く見つけて判断し、限られたリソースを集中させる能力だ。この差がAI時代のセキュリティ対応力を左右することになりそうだ。