2026年2月11日、FIRSTは2026年のCVE公開件数を59,427件と予測した。これは同組織が2024年11月に公表した2025年予測45,505件をさらに上回る水準であり、CVEエコシステムが「年間5万件超」を前提に再設計される段階に入ったことを示すシグナルである。本稿は、件数増加それ自体ではなく、脆弱性管理プロセスのどこが先に破綻し、どの機能を自動化しなければ運用不能になるのかを整理する。

2026年予測59,427件が意味するもの

FIRSTの2026年予測59,427件は、単なる増加トレンドの延長ではない。従来の「重大度ベースで月次棚卸しする」運用は、件数が臨界点を超えると処理待ちを恒常化させ、修正優先順位の意思決定を遅延させる構造を持つ。特にグローバル企業では、プロダクト単位・環境単位・資産単位で同一CVEの影響評価が分岐するため、件数増加はそのまま評価ジョブの多重化を引き起こす。

2026年の論点は「何件見つかるか」ではなく、「どの時点で手動評価がボトルネック化するか」である。59,427件という予測値は、脆弱性管理をSOC的な常時運用へ移行させる転換点として読むべきである。

CVE件数の推移と加速の構造

CVE件数の推移を振り返ると、増加は直線的ではなく指数関数的に加速している。2020年に約18,000件だったCVE公開件数は、2023年に29,065件、2024年に約40,000件、そして2025年予測が45,505件、2026年予測が59,427件と推移している。注目すべきは2024年から2026年にかけての増加率で、わずか2年で約50%の増加が見込まれている点である。

この加速には複数の構造的要因がある。第一に、CVE Numbering Authority（CNA）の拡大がある。2024年時点で400を超えるCNAが登録されており、各CNAが独立してCVEを採番・公開するため、従来のMITRE一極集中時代と比べて採番速度が大幅に上がった。第二に、自動脆弱性検出ツールの高度化がある。ファジング、静的解析、AIによる自律的脆弱性ハンティングの進化により、従来は発見されなかった脆弱性が大量に掘り起こされている。第三に、ソフトウェアサプライチェーンの複雑化がある。一つのアプリケーションが数百の依存パッケージを持つ現代では、各依存先の脆弱性がすべてCVEとして登録される。

5万件突破が持つ心理的・実務的インパクト

年間5万件超という数字は、セキュリティチームの心理にも影響を与える。1営業日あたり約240件の新規CVEが公開される計算であり、これは「すべてに目を通す」ことが物理的に不可能であることを意味する。筆者はこれまでSOC構築やSIEM導入の実務に携わってきたが、SOCの価値はツールではなく、アラートから判断までの人間のプロセスにあるという原則は脆弱性管理にも当てはまる。ツールが何千件のアラートを出しても、人間の判断キャパシティを超えればノイズと同じである。5万件時代の脆弱性管理は、「全件確認」から「構造的に重要なものだけを人間が判断する」設計への移行を迫られている。

なぜ従来プロセスは破綻するのか

2025年3月19日にNVDが公表した運用更新では、2024年のCVE入力増加率が32%に達したこと、そして蓄積分の処理のために機械学習活用を含む自動化拡張が必要であることが示されている。すなわち、中央データ基盤側ですでに処理能力問題が顕在化している。

この状況下で、企業内の従来プロセスは次の順で劣化しやすい。

  • 受付: 監視対象の増加で、重複チケットとノイズ通知が急増する。
  • 評価: CVSSだけでは修正優先度を決められず、資産重要度・公開エクスプロイト有無・露出面を突合する手作業が膨張する。
  • 実装: パッチ適用判定からメンテナンス調整までが人手依存のため、SLAを恒常的に超過する。

件数が5万件規模に達すると、問題の本質は「検知精度」ではなく「意思決定スループット」に移るのである。

NVDバックログ問題と企業への波及

NVD（National Vulnerability Database）自体が処理の遅延に直面していることは、企業の脆弱性管理にも直接影響する。NVDは2024年中盤からCVEのエンリッチメント（CVSS採点、CPE紐付け等）の遅延が常態化し、未処理のバックログが数万件に達した。企業側のスキャナやSIEMはNVDデータに依存しているため、NVDの遅延はそのまま企業内トリアージの遅延を意味する。

この問題に対し、CISAはVulnrichmentプログラムを開始し、NVDとは独立にCVEのエンリッチメントを進めている。しかし、データソースの二重化は企業側のデータ統合をさらに複雑にする。2026年の脆弱性管理は、単一データソースへの依存から複数ソースの自動統合へ移行する必要がある。

CVSS偏重の限界とEPSS・KEVの台頭

従来のCVSSスコアだけで修正優先度を決める運用は、5万件時代には機能しない。CVSSが「脆弱性の技術的深刻度」を測定するのに対し、実際のリスクは「その脆弱性が実環境で悪用される確率」と「悪用された場合のビジネス影響」の掛け算で決まる。

ここで注目されるのがEPSS（Exploit Prediction Scoring System）とKEV（Known Exploited Vulnerabilities）カタログである。EPSSはCVEが今後30日以内に悪用される確率を機械学習で予測し、KEVはCISAが「実際に野生で悪用が確認された」脆弱性をリスト化する。2026年2月のMicrosoft 6件ゼロデイ連鎖が示すように、野生利用が確認された脆弱性への即時対応は必須であり、KEV掲載CVEへの対応SLAを別途定義する運用が標準化しつつある。

実務的には、以下の三層フィルタリングが推奨される。

  • 第1層: KEV掲載 — 悪用確認済み。24〜48時間以内に修正または緩和策適用。
  • 第2層: EPSS上位5%かつ資産露出あり — 悪用確率が高く、インターネット露出がある。72時間以内に評価完了。
  • 第3層: CVSS High/Critical — 技術的深刻度は高いが、悪用確率・露出が低い。通常パッチサイクルで対応。

構造的転換: AIトリアージと自動パッチ適用

ここで必要なのは、検知ツールの追加ではなく運用レイヤの再設計である。実務上は少なくとも次の二層自動化が前提となる。

  • AIトリアージ層: CVE、資産台帳、SBOM、外部脅威情報を横断し、修正優先順位を機械的に再計算する。人間は「例外承認」と「ビジネス影響判断」に集中する。
  • 自動適用層: 低リスク更新はリング配信で自動展開し、失敗時は即時ロールバックする。高リスク更新は事前検証結果を添えて承認待ちに回す。

この二層化により、担当者は全件レビューから外れ、ポリシー設計者へ役割を移せる。逆に言えば、この転換がない組織は件数増加に比例して未修正残高を積み上げる。

AIトリアージの実装アーキテクチャ

AIトリアージの実装は、以下の4つのデータソースを統合するパイプラインとして設計する。

  • CVEフィード: NVD、CNA直接フィード、CISA Vulnrichmentの統合。JSON形式で日次または時次取り込み。
  • 資産台帳（CMDB）: IPアドレス、ホスト名、OS、インストール済みソフトウェア、ビジネスクリティカリティの紐付け。SBOMとの連携が鍵。
  • 脅威インテリジェンス: EPSS、KEV、MITRE ATT&CK、PoC公開状況、ダークウェブ言及の統合。
  • 過去の対応履歴: 自社のパッチ適用成功率、ロールバック率、修正に要した平均時間。これらをフィードバックループとしてモデルに学習させる。

これらを統合し、各CVE×資産ペアに対して「修正優先スコア」を自動算出する。スコアの根拠は人間が検証可能な形で提示し、ブラックボックス化を防ぐ設計が重要である。

自動パッチ適用のリング配信モデル

自動パッチ適用は、Microsoftが自社のWindows Updateで採用しているリング配信モデルを参考にできる。

  • Ring 0（カナリア）: 開発・テスト環境に即時適用。自動テストで回帰確認。
  • Ring 1（アーリーアダプター）: 本番環境の5〜10%に適用。24時間モニタリング後、異常がなければ次段階へ。
  • Ring 2（全面展開）: 残り全体に適用。ただし、ロールバック手順を事前に自動準備。
  • 例外リング: ビジネスクリティカルシステム、レガシー環境など自動適用不可の資産。人間による評価・承認を経て手動適用。

筆者が過去に全国規模WAFサービスの技術主任として無停止リプレースを実現した経験から言えることは、「止められないという制約が技術的判断の全てを支配する」という点である。パッチ適用も同様で、可用性を維持しながら修正を適用する設計こそが5万件時代の実装課題の核心である。

SBOMと脆弱性管理の統合

5万件時代の脆弱性管理において、SBOM（Software Bill of Materials）は基盤インフラとなる。SBOMがなければ、公開されたCVEが自社のどのシステムに影響するかを特定する作業自体が手動になり、トリアージ以前のボトルネックが発生する。

2024年以降、米国では連邦政府向けソフトウェアにSBOMの提出が義務化され、EUサイバーレジリエンス法（CRA）でも2027年までにSBOM対応が求められる見通しである。日本国内でも経済産業省のSBOM導入ガイドラインが公開され、サプライチェーンリスク管理の文脈でSBOMの実装が加速している。

SBOMと脆弱性管理を統合する際のポイントは以下の3点である。

  • SBOMの自動生成と更新: CI/CDパイプラインにSBOM生成を組み込み、ビルドごとに最新のSBOMを出力する。手動管理では陳腐化が避けられない。
  • CVE-SBOM自動マッチング: 公開されたCVEのCPE（Common Platform Enumeration）とSBOMのコンポーネント情報を自動突合し、影響を受ける資産を即時特定する。
  • 推移的依存関係の可視化: 直接依存だけでなく、依存先の依存先（推移的依存）に含まれる脆弱性も追跡する。npm、Maven、pip等のエコシステムでは推移的依存が全体の80%以上を占めることも珍しくない。

2026年に再定義すべきKPI

件数増加局面では、従来の「検知件数」「月次クローズ率」は経営判断に寄与しにくい。2026年は、次の運用品質KPIへ置き換えるべきである。

  • 初動判定時間（Triage Lead Time）: 新規CVE取り込みから優先度確定までの時間。目標: KEV掲載CVEは4時間以内、その他は24時間以内。
  • 自動修正率（Automated Remediation Rate）: 承認不要で閉じた修正の割合。目標: 全修正の60%以上を自動化。
  • 例外滞留日数（Exception Aging）: 未修正を許容した例外の平均滞留日数。目標: 30日以内。90日超の例外は経営報告事項とする。
  • 再発率（Reopen / Regression Rate）: パッチ適用後に再度脆弱状態へ戻る割合。目標: 5%以下。
  • MTTR（Mean Time to Remediate）: CVE公開から修正完了までの平均時間。Critical/High/Medium/Lowの重大度別に測定。
  • カバレッジ率: SBOM管理下の資産が全資産に占める割合。目標: 90%以上。カバレッジ外の資産は「見えないリスク」として別途管理。

59,427件という予測値は恐怖を煽る数字ではない。脆弱性管理を「人が回す業務」から「機械が回し人が統治するシステム」へ移すべき期限を示す、具体的な運用要件である。

組織体制の再設計: 脆弱性管理専任チームの必要性

5万件時代には、脆弱性管理をSOCやCSIRTの「兼務業務」として運用することの限界が明確になる。専任の脆弱性管理チーム（VMT: Vulnerability Management Team）を設置し、以下の役割分担を明確化すべきである。

  • VMTリード: 脆弱性管理ポリシーの策定、KPI設計、経営報告。
  • トリアージアナリスト: AIトリアージの例外対応、ビジネス影響評価。AIが判断しきれないグレーゾーンの意思決定。
  • パッチエンジニア: リング配信の運用、ロールバック対応、レガシー環境のパッチ戦略設計。
  • データエンジニア: CVEフィード、SBOM、CMDB、脅威インテリジェンスの統合パイプライン維持。

中小企業で専任チームの設置が難しい場合は、Managed Vulnerability Management Service（MVMS）の活用も選択肢となる。ただし、ビジネス影響の判断は外部委託できないため、最低限の意思決定プロセスは社内に残す必要がある。

AI脆弱性発見の加速が生むフィードバックループ

5万件突破の背景には、脆弱性を「発見する側」の能力向上もある。ÆSIR/Claude Opus 4.6によるOpenSSL 12件全件検出に代表されるように、AIが自律的に脆弱性を発見・報告する時代が到来している。これは脆弱性管理側にとってポジティブなフィードバックループとネガティブなフィードバックループの両面を持つ。

ポジティブな面は、これまで何年も潜伏していた脆弱性が早期に発見・修正されることで、攻撃者に先行できる点である。ネガティブな面は、AIが発見する脆弱性の件数がCVE処理能力を上回り、バックログがさらに拡大する点である。

このフィードバックループに対処するには、発見・登録・エンリッチメント・トリアージ・修正のパイプライン全体をエンドツーエンドで自動化する設計が求められる。部分的な自動化では、最も遅いステージがボトルネックとなり、パイプライン全体のスループットが制約される。

FAQ

Q1. 59,427件は確定値なのか。

確定値ではなく、FIRSTが2026年2月11日に公表した予測値である。ただし、同組織は2025年についても事前予測を公開しており、年次計画の入力値としては十分に実務的である。FIRSTの過去予測と実績の乖離は概ね10%以内に収まっており、50,000件を超えることはほぼ確実視される。

Q2. CVSSだけで優先順位を決める運用はもう難しいのか。

難しい。件数増加局面では、CVSSに加えて資産重要度、インターネット露出、既知の悪用情報（KEV、EPSS）、代替策有無を同時に評価しないと修正順序が現実のリスクと乖離するためである。CVSSスコアが9.0以上でも野生利用が確認されていないCVEと、CVSSが7.5でもKEVに掲載され活発に悪用されているCVEでは、後者の修正優先度が高い。

Q3. 自動パッチ適用は本番障害リスクが高くないか。

一律自動化は危険である。リング配信、カナリア、即時ロールバック、事前適用テストを組み合わせ、低リスク領域から段階導入する設計が前提となる。実績データによれば、適切なリング配信を導入した組織では、パッチ起因の障害率は全手動適用時と同等以下に抑えられている。

Q4. 2026年中に最優先で着手すべきことは何か。

脆弱性データと資産データの統合である。SBOMの自動生成をCI/CDに組み込み、CMDBとの紐付けを確立することが第一歩となる。データが分断されたままではAIトリアージの精度が上がらず、結果として人手運用を脱却できない。

Q5. 中小企業でも5万件時代への対応は必要か。

必要である。中小企業は直接59,427件すべてに対応する必要はないが、自社が利用するソフトウェアに関連するCVEは確実に増加する。SBOMベースの自動マッチングとマネージドサービスの活用により、少人数でも構造的な対応が可能になる。「うちは小さいから狙われない」は2026年には通用しない。

Q6. EPSSの精度はどの程度信頼できるのか。

EPSSは機械学習ベースの予測モデルであり、完璧ではない。しかし、FIRSTが公表するモデル評価によれば、EPSS上位5%に含まれるCVEが実際に悪用される割合はCVSSのみの優先順位付けと比較して大幅に高い。CVSSと組み合わせることで単独使用よりも精度が向上するため、補完的に活用することが推奨される。

Q7. SBOMの導入はどこから始めるべきか。

最もビジネスクリティカルなアプリケーションのCI/CDパイプラインから始めるのが効果的である。SyftやCycloneDX等のOSSツールを使えば、ビルド時に自動でSBOMを生成できる。まずは1プロジェクトで導入し、CVE自動マッチングの効果を実証した上で全社展開する段階的アプローチが現実的である。

参考文献