AIはセキュリティリスクを本当に増やしたのか？

セキュリティ界隈は詰んでいる？

今年に入ってから、脆弱性対応に追われている人は多いのではないだろうか。

GitHub Advisory は毎日増える。
Dependabot の通知は止まらない。
顧客からは対応状況を聞かれる。

私自身も、特に根拠無く、「AIでセキュリティリスクが急増しているのではないか」という感覚を持っていた。

Claude Mythos は限定公開中に、脆弱性を次から次へと発見したと話題になった。Mythos も、そのフィルター版 Fable も米国政府により輸出規制の枠に入れられた。超高性能モデルの悪用を懸念して、というようにも聞こえる。

AI によるマルウェア生成や RaaS の隆盛など、AI によるセキュリティリスクがセンセーショナルに世の中を賑わすと、不安は高まる。セキュリティへの意識向上自体は素晴らしいことだが、実際に被害がでなければ予算がつかないのが、セキュリティ界隈だ。

構造的に詰んでいる（気がする）。

のだが、本当か？
実際、Dialy のモニタリングで毎日新規の脆弱性を振り分けているが、実際に緊急対策が本当に必要なものはほとんどない。

なので、ちゃんと調べることにした。No Measure, No Control.

調査対象

• 対象: Node (npm) / Python (PyPI) / PHP (Composer) を中心とした OSS パッケージ脆弱性
• 期間: 2024年1月〜2026年6月（30ヶ月、2026年6月は15日まで）
• データソース: GitHub Advisory DB, NVD, OSV.dev, CISA KEV, PYSEC, RustSec, FriendsOfPHP, GitLab gemnasium-db, ransomware.live（いずれも公開データ）

脅威は1つの数字ではない

セキュリティの議論では、よく次のようなストーリーが語られる:

脆弱性が増える → 攻撃が増える → 被害が増える

このドミノは一見すると自然だが、実はこの3つは全く別の現象である。
今回、脅威を以下の3段階に分けて測定・分析を行った

段階	測定対象
Disclosure	OSS脆弱性公開件数
Exploitation	実際に悪用が確認された脆弱性（CISA KEV）
Victimization	ランサムウェア被害（リークサイト掲載数）

つまり、

• 脆弱性が公開されたか
• 実際に攻撃に使われたか
• 被害が発生したか

を個々に追跡した。

実際に増えたのは何だったのか？

結果は、感覚とは異なっていた。

指標	2026年 vs 2024-2025平均
OSS全体脆弱性公開	3.9倍
CISA KEV	1.37倍
ランサムウェア被害	1.34倍

OSS 全体では 3.9倍だが、npm に限定すると8.8倍に増加している。一方で、被害は 1.34倍程度と、増えてはいるが、同じペースでは増えていない。

少なくとも観測できる範囲では、

CVE爆増 = 被害爆増

は成り立たない。

更に、調査期間内での特異点を数学的（Pettitt, Binary seg., Bayesian MAP, CUSUM）に分析すると、

段階	スパイク時期
Disclosure	2026-03
Exploitation	2024-08
Victimization	2024-11

と、悪用・被害は、発見の下流にはないことが分かる。

これは実は昔から知られていた

ここで「じゃあ CVE は無視して良い？」という話しにはならないのだが、大多数の CVE は実際には悪用されないという事実は昔から知られている。

例えば、

Cyentia Institute & Kenna Security の Prioritization to Prediction シリーズでは、

実際に悪用される脆弱性は概ね 2〜6 ％

と報告しているし、FIRST.org の EPSS も、

大半の CVE は実際には悪用されない

という前提の上に構築されている。
つまり、

95％程度の CVE は実被害にはならない

というのは、10年以上前から繰り返し確認されている現象であり、今回の分析結果は、その既存研究と整合している。

ただし、これは

大半の脆弱性を無視してよい

という意味ではない。
Mandiant の分析によれば、実際に悪用される脆弱性は公開から悪用までの中央値がわずか5日である。つまり、

• 悪用される脆弱性は少ない
• しかし悪用されるものはすぐ使われる

というのが現実だ。

危険な脆弱性が増えた？

もし本当にセキュリティリスクそのものが悪化しているなら、

• Serverity: Critical/High の割合
• RCE (Remote Code Execution) の割合

などが増えていてもおかしくはないが、その傾向を裏付けるようなデータは観測されなかった。

Ecosystem	Crit+High 2024	2025	2026	RCE share 2024	2025	2026
npm	44%	49%	50%	8%	11%	8%
PyPI	51%	49%	51%	10%	14%	10%
Composer	38%	32%	44%	8%	6%	8%

つまり、危険な脆弱性だけが大量発生するようになったわけではなく、 「より多くの脆弱性が満遍なく見つかり、公開されるようになった」 というのが事実だ。

AI はどこに効いているのか？

ここで AI の話しに戻る。今回の調査で、AI が原因で何かが変わった・その因果関係を証明するデータは存在しない。しかしながら、強めの仮説として、

AI が脆弱性派遣能力を向上させていること自体はほぼ間違いない

くらいは言えるかもしれない。
例えば、

• Google Project Naptime
• Google Big Sleep
• DARPA AI Cyber Challenge
• XBOW

など、2024〜2025年には AI による脆弱性発見能力を示す事例が急増している。特に Big Sleep は実際の未知脆弱性発見を報告した。つまり、

AI → 脆弱性発見

は既に現実になっている。一方で、

AI → 被害急増

を示す同レベルの証拠はまだ見当たらない。

興味深いことに、2026年Q1の OSS 脆弱性公開数のスパイクは、2025年後半の LLM能力向上と時間的には整合している。ただし、これは因果関係を示すものではなく、有力な仮説であり、証明された結論ではない。

なお、Claude Mythos（4月）、Fable（6月） などの利用に規制がかかるほどの超高性能モデルは、CVE 公開数が跳ねた後に登場しており、かつ4月から5月では CVE 公開数は減少していることなどからも、Opus クラスのモデルが、脆弱性発見に既に十分な能力を持っており、今後更に CVE 公開数がジャンプすることはないかもしれない。今後は、高止まりするのではないかと予想されるが、現時点ではまだ何とも言えない。

「AIランサムウェアが席巻している」もデータでは確認できない

AI による攻撃増加の象徴のように、AIランサムウェアがしばしば取り上げられる。しかしながら、現実は、現時点ではそれほど悲観的になるような状況ではない。

• FuncSec
• GLOBAL GROUP
• AiLock
• PromptLock

といった AI を全面に押し出したランサムウェアグループを追跡した。

AI を全面に押し出したランサムウェアキャンペーンは、実際には1〜2ヶ月程度で収束しており、被害面でも、全体のわずか1〜5％程度であった。AI がマルウェアを生成する PromptLock に至っては、トピックとしてはセンセーショナルであるものの、被害件数は 0 と、PoC 段階のようである。

話題性は大きいものの、データからは、AI犯罪組織がランサムウェア市場を席巻しているという状況は、現時点では確認できない。

本記事では詳しく触れないが RaaS が隆盛しているというデータも、ない。

ただし安心はできない

ここで重要なのは、AI ランサムウェアが猛威を奮っているという事実がないということは、AI脅威は嘘だということではない。むしろ逆で、「まだ」脅威になっていないというだけだ。

PromptLock は、被害件数は 0 だが、歴史的には興味深い存在だ。PromptLock は、

AIが攻撃コードそのものを生成した最初の事例

だからである。
現在 Disclosure と Victimization の間には巨大なギャップがある。そのギャップを支えているのが、

• Exploit開発
• Weaponization
• 攻撃運用

という人間の作業だ。将来 AI が高精度にこのパイプラインを自動化するようになれば、

CVE 増加 ≠ 被害増加

という構造が変化する可能性はある。
（個人的には、これが自動化できない技術的な課題が何なのか気になる）

セキュリティ界隈は詰んでいる

2026-Q1 に CVE 公開数がスパイクした。しかしながら、公開される CVE で実際に悪用されるものは極めて少ない事実はこれまでと変わらず、AI がリスクを加速させているという事実も存在しない。発見能力が武器化を大きく上回っており、どちらかと言えば、ポジティブな状況であると言えなくもない。

しかしながら、実務者として私は疲弊している。

これは何故かと言えば、シンプルに調査が必要な脆弱性が増えたからであり、従来通りのルール（Serverity ベースの SLA など）では、放置が契約違反にあたるからである。

善意の AI 利用があぶり出したのは、脆弱なルールだったのかもしれない。

この Critical に脆弱なルールの変更に時間がかかるという点を考えれば、やはりセキュリティ界隈は詰んでいる。

なぜ Serverity ベースの SLA は危険なのか

Serverity ベースの SLA は問題ないように見えるかもしれないが、いまはとても危険だ。新たな契約では結んではいけないし、既存契約にあるなら見直す必要がある。

OSS 脆弱性が約 4 倍（Node 系システムなら約 9 倍）になった世界で、

• Critical: 24時間以内
• High: 72時間以内

のような、一見合理的に見える運用を行った場合、何が起こるかと言えば、

• 現場は大量の通知に埋もれる
• 顧客は大量の報告を受ける

そして、

• 本当に危険な脆弱性が埋もれる
• 開発チームがパッチ作業に追われる

と、誰も得をしない。

CVE対応は「件数」ではなく「到達可能性」と「悪用可能性」で見るべきであり、Severity だけでなく、少なくとも次の観点で優先度を決めるべきである:

• その脆弱性が実際に使っているコードパスに到達可能か
• 外部公開面にあるか
• 認証なしで悪用できるか
• 実際に悪用が確認されているか
• KEVやEPSSなどの指標で優先度が高いか
• 対象システムの重要度が高いか
• 暫定回避策があるか
• パッチ適用による業務影響がどの程度か

「CVSS が高いから危険」ではなく、「自分の環境で本当に危険か」が重要である。
もちろん、Critical/High を無視して良いわけではないが、Serverity は出発点であって、対応の優先順位を決定する最終判断ではない。

運用保守契約にセキュリティ条項を入れるなら、単純なCVE対応SLAよりも、トリアージプロセスを明記する方が良い。

例えば、

• 新規CVEを定期的に確認する
• 対象システムへの影響有無を評価する
• 悪用実績、到達可能性、外部公開面、業務影響で優先度を決める
• 緊急対応が必要なものは個別に合意する
• 通常対応は提起リリースサイクルに組み込む
• 対応不能または即時対応が不合理な場合は、回避策・監視・リスク受容を選択肢に含める

などといった形だ。

つまり、契約で保証すべきなのは、「全てのCVEに一定時間内でパッチを当てること」ではなく、「CVEを評価し、実リスクに応じて対応判断するプロセス」である。

まとめ

AI によってセキュリティの世界が変わっている可能性はある。特に、脆弱性を見つける速度は上がっているかもしれない。

しかし、現時点で観測できるデータからは、CVE の増加が、そのまま攻撃や被害の増加に連動しているとは言えず、公開される CVE の多くは実際の被害には繋がらないという事実に変化は起きていない。

なので、企業も、開発・運用チームも、

CVEが増えた → 全部すぐ対応しなければならない

という発想から離れる必要がある。CVE対応は必要だが、Serverity だけで SLA 化すると、現場も顧客も大量のノイズに飲み込まれることになる。

AI 時代のセキュリティ運用で本当に必要なのは、危機感を煽ることではなく、リスクを分解し、優先順位を付けて、持続可能な対応プロセスを作ることである。

調査レポート

本記事の元となる調査レポートは、再現するためのデータ・スクリプトなどを同梱し、GitHub で公開している。Preprint かつ、英語のみとなっているが、興味があれば。