「CVE-2026-0300が話題だが、うちに影響あるのか？」——脆弱性のニュースを追う情シス担当者なら、このCVE番号を毎日のように目にしているはずです。ベンダーの注意喚起、脆弱性スキャナの結果、JVNの公表、どれもこのCVE番号で脆弱性を指しています。本記事では、CVEとは何か、その仕組みと、情シスが実務でどう使えばよいかを一次情報をもとに整理します。
この記事でわかること
- CVE（共通脆弱性識別子）の意味とCVE-IDの読み方
- 誰が、どうやってCVE番号を割り当てているのか（MITRE・CNA・JVN）
- CVEとCVSS・NVD・JVN iPediaの違いと関係
- 情シスがCVEを日々の脆弱性対応でどう活用するか
CVEとは何か（1文の定義）
CVE（Common Vulnerabilities and Exposures／共通脆弱性識別子）とは、公表された個々の脆弱性に世界共通の一意な番号を付けて、誰もが同じ脆弱性を同じIDで参照できるようにする仕組みです。IPAは「個別製品中の脆弱性を対象として、米国政府の支援を受けた非営利団体のMITRE社が採番している識別子」と説明しています。
ポイントは「識別子（番号）」であって、脆弱性の危険度を表すスコアでも、詳細なデータベースそのものでもない、という点です。CVEはあくまで「脆弱性の背番号」だと捉えると理解しやすくなります。
なぜCVEが必要なのか
CVEがなかった時代は、同じ一つの脆弱性を、ベンダーAは「A社の緊急パッチ」、スキャナBは「B社の検知シグネチャ名」、報道Cは独自の呼び名で指していました。これでは「A社が言っている脆弱性と、うちのスキャナが検知したものは同じなのか？」を人手で突き合わせる必要があります。
CVE番号を全員が共通で使えば、脆弱性対策情報同士の相互参照や関連付けが一発でできます。ベンダーの公表、脆弱性スキャナ、資産管理ツール、報道、いずれもCVE番号をキーにして名寄せできる——これが脆弱性管理の土台になっています。
CVE-IDの読み方
CVE番号は次の形式です。
CVE-西暦-連番（例：CVE-2026-0300）
- 西暦：番号が予約（採番）された年。脆弱性が実際に公表された年とは限らない点に注意します。
- 連番：その年に割り当てられた通し番号。
かつて連番は4桁固定でしたが、2014年1月1日以降は4桁で足りなくなった場合に桁数を増やす方式に変わりました。年間の採番数が1万件を大きく超える現在では、5桁以上の番号が当たり前になっています。また候補段階で使われていた「CAN-」という旧プレフィックスは2005年に廃止され、現在はすべて「CVE-」に統一されています。
誰がCVE番号を割り当てているのか
CVEプログラムは、米国CISA（サイバーセキュリティ・インフラセキュリティ庁）が資金を提供し、非営利団体のMITRE社が運営しています。ただし、MITREが世界中の脆弱性を一手に採番しているわけではありません。実際の採番は、権限を与えられた組織であるCNA（CVE Numbering Authority）が分担しています。
CNAには、Microsoft・Red Hat・Ciscoといった大手ベンダーや、各国のCSIRTなどが含まれます。自社製品の脆弱性は自社（CNA）が番号を割り当てる、という分担により、世界規模の採番をさばいています。日本ではJPCERT/CCとIPAが共同運営するJVNがこの枠組みに参加しており、2008年10月からMITREが公示する「CVE情報源サイト」の一つとして、日本国内で発見・報告された脆弱性へのCVE割り当てを担っています。
CVEと混同しやすい用語の整理
実務で紛らわしいのが、CVEと似た略語や関連データベースです。役割を分けて覚えると混乱しません。
| 名称 | 役割 | ひとことで言うと |
|---|---|---|
| CVE | 脆弱性を一意に識別する番号 | 脆弱性の「背番号」 |
| CVSS | 脆弱性の深刻度を数値化する評価基準 | 危険度の「点数」 |
| CWE | 脆弱性の「種類・原因」を分類する体系 | 弱点の「タイプ」 |
| NVD | 米国のCVE詳細データベース（CVSS等を付与） | 米国の脆弱性DB |
| JVN iPedia | 日本語で脆弱性対策情報をまとめたDB | 日本の脆弱性DB |
関係を一続きにすると、「脆弱性が見つかる → CNAがCVE番号を採番 → NVDやJVN iPediaが、その番号にCVSSスコアやCWE分類、影響範囲などの詳細を肉付けして公開する」という流れになります。CVEは入口の識別子、詳細はデータベース側が担う、という分業です。
情シスはCVEをどう使うのか
CVEは知識として知っておくだけでなく、日々の運用で次のように使います。
- 影響有無の判定の起点にする：ニュースやベンダー公表でCVE番号を見たら、その番号で自社の資産管理台帳・スキャナ結果を検索し、該当製品・バージョンを使っているかを確認します。CVE番号は名寄せのキーそのものです。
- 優先度づけはCVSSと実際の悪用状況で：CVE番号は危険度を表しません。対応の優先順位は、CVSSスコアに加えて「実際に悪用されているか（CISAのKEVカタログ等）」「自社での露出度」を合わせて判断します。CVE番号が付いている＝すぐ直せ、ではありません。
- 経営層・他部署への説明の共通言語にする：「CVE-2026-0300への対応状況」と番号で管理すれば、部署をまたいでも認識がぶれません。パッチ適用の進捗管理でも、CVE番号を軸にすると抜け漏れを追いやすくなります。
現場の実感として悩ましいのは、CVE番号が付いて世に出た瞬間から、攻撃者もその情報を見ている、という点です。番号が公表されてからパッチ適用までの数日〜数週間が最も危険な空白期間になりがちで、限られた人員でこの窓をどれだけ短くできるかが、脆弱性管理の勝負どころだと感じます。「CVEの一覧を眺めているだけ」では守れず、自社資産の棚卸しと突き合わせが伴って初めて意味を持ちます。
知っておきたい最近の動き（2025〜2026年）
CVEは「あって当たり前」の世界共通インフラですが、2025年4月にはMITREへの運営資金の契約が一時失効しかけ、CVEプログラムの継続が危ぶまれる事態が起きました。最終的にCISAが契約を延長して事なきを得ています。CVE Boardは2026年1月の会合で「当面の資金面の崖はない」と説明していますが、単一国の予算に依存する構造への懸念は残っています。
この流れを受け、欧州ではENISA（欧州サイバーセキュリティ機関）が2025年にEUVD（欧州脆弱性データベース）を立ち上げました。EUVDはCVEを置き換えるものではなく、CVE番号と対応づけながら欧州独自の識別子（例：EUVD-2025-xxxxx）を付与し、CVEを補完する位置づけです。情シスの実務が急に変わるわけではありませんが、「脆弱性情報の供給源が米国一極から複線化しつつある」ことは、頭の片隅に置いておくとよいでしょう。
対策・脆弱性管理の指針はどこを見ればよいか
CVEを起点にした脆弱性管理の進め方は、自前でチェックリストを作り込むより、公的機関の指針を土台にするのが確実です。まずはIPAの共通脆弱性識別子CVE概説で仕組みを押さえ、実際の脆弱性対策情報はJVN iPediaで日本語で確認できます。中小規模の組織であれば、中小企業の情報セキュリティ対策ガイドラインが、資産把握やパッチ運用の全体像をつかむうえで参考になります。あわせて、脆弱性情報を「見て終わり」にしないための地道な運用（資産台帳の整備、担当者への周知）を定着させることが、番号を知る以上に効いてきます。
まとめ
- CVE（共通脆弱性識別子）とは、公表された脆弱性一つひとつに付ける世界共通の一意な番号で、脆弱性情報の名寄せの土台になる。
- CVEは「識別子」であり危険度スコアではない。優先度づけはCVSSや実際の悪用状況（KEV）と組み合わせて判断する。
- 番号を眺めるだけでは守れない。自社資産との突き合わせと、公表からパッチ適用までの空白期間を縮める運用が要になる。
