CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化

CVE（Common Vulnerabilities and Exposures、共通脆弱性識別子）は、世界中で見つかった脆弱性に「CVE-2025-55182」のような一意の番号を割り当て、誰が見ても同じ脆弱性を指せるようにする識別のしくみです。読み方はそのまま「シーブイイー」で、正式名称の日本語訳が「共通脆弱性識別子」にあたります。脆弱性アラートやスキャナーの結果に必ず登場する一方で、CVSSやCWE、NVD、JVNといった似た用語と混同されやすいのも特徴です。この記事では、CVE IDの読み方と構造、採番のしくみ、CVSS・CWE・NVD・JVNとの役割分担、そして2025〜2026年に起きた運営体制の大きな変化までを、公式情報をもとに整理します。

まとめ：CVEの要点と2026年時点で押さえるべき変化

先に結論を示します。CVEは「脆弱性に共通の名前を付ける辞書」であり、深刻度を測るCVSS、種類を分類するCWE、詳細情報を足すNVD/JVNとは役割が分かれています。実務でまず押さえたい点は次のとおりです。

• CVE IDは「CVE-西暦-連番」形式。西暦は採番を予約した年で、脆弱性の公表年とは必ずしも一致しない。
• 採番はMITRE単独ではなく、認定機関CNA（日本ではJPCERT/CC等）が分担している。
• CVE自体は「識別」が役割。深刻度はCVSS、種類はCWE、影響製品はCPEで補い、それらをまとめて引けるのがNVDやJVN。
• 2025年4月にMITREの運営契約が一時失効しかけ、CISAが11か月延長。並行してCVE Foundationが設立され、公式サイトはcve.orgへ移行した。
• 2026年にはNVDが全件のenrichment（CVSS/CWE/CPE付与）を断念し、優先度の高い脆弱性に絞るトリアージへ移行した。CVE番号だけでは付帯情報が揃わない前提で運用する必要がある。

以下、それぞれを具体例とともに掘り下げます。脆弱性の深刻度評価そのものを詳しく知りたい場合はCVSSとは何か？その基本的な定義と重要性についてもあわせて参照してください。

CVEとは何か：共通脆弱性識別子という名称の由来と基本的な役割

CVEは1999年に米国の非営利組織MITREが開始した、脆弱性を一意に識別するための公開リストです。開始の動機ははっきりしています。当時は同じ脆弱性をベンダーごとに別の名前で呼んでいたため、A社の警告とB社のパッチが同じ問題を指しているのか突き合わせられず、対応が遅れていました。CVEは「世界共通の通し番号」を与えることで、この突き合わせコストを下げる目的で生まれたわけです。

「共通脆弱性識別子」は Common Vulnerabilities and Exposures の定訳で、IPA（情報処理推進機構）もこの訳語を用いています。Vulnerabilities（脆弱性）だけでなく Exposures（設定ミスなどの暴露）まで含むのが原語の含意ですが、日本語では「共通脆弱性識別子」で定着しました。検索では「CVEとは」「共通脆弱性識別子」「CVE 意味」「common vulnerabilities and exposures 読み方」がほぼ同じ意図で使われており、いずれもこの定義に行き着きます。

注意したいのは、CVEは脆弱性の「名前」を決めるだけで、危険度や直し方そのものは持たない点です。だから後述するCVSSやNVDと組み合わせて、はじめて実務で使えます。CVEを「脆弱性データベース」と紹介する記事もありますが、正確には「識別子のリスト」であり、詳細データベースはNVDやJVNが担うと理解しておくと混乱しません。

CVE IDの読み方と構造：CVE-2025-55182の意味

CVE IDは「CVE-西暦4桁-連番」という形式です。たとえば「CVE-2025-55182」なら、CVEプログラムが2025年に採番予約した55182番目の識別子という意味になります。読み方は「シーブイイー・にせんにじゅうご・ごーまんごせんひゃくはちじゅうに」で、ハイフン区切りの3ブロックで構成されます。

CVE-IDの西暦部分は公表年ではなく採番を予約した年を指す

よくある誤解が「西暦＝脆弱性が見つかった年」というものです。正しくは、CNAがその番号を予約した年を表します。脆弱性が年をまたいで公表されると、たとえば2024年に予約した「CVE-2024-xxxxx」が2025年に公開される、という時間差が普通に起こります。古いCVE番号が新しいニュースに出ても矛盾ではありません。

CVEの連番部分は2014年に4桁固定から可変長の方式へ拡張

連番部分は当初4桁固定（最大9999件/年）でしたが、報告件数の急増に追いつかなくなり、2014年に最低4桁・必要に応じて桁を増やせる可変形式へ変更されました。これにより1年あたり1万件を超える採番が可能になり、実際に2025年には4万件超のCVEが公開されています（最新の件数はcve.orgの公式統計で確認してください）。桁数が4桁か5桁以上かで脆弱性の重大さが変わるわけではなく、単に予約順を示すだけです。

CVEの採番のしくみ：MITREとCNAによる役割分担の全体像

「CVE番号は誰が決めるのか」は検索でもよく問われます。答えは、MITRE単独ではなく分散型です。MITREがプログラム全体を運営し、実際の採番は世界各地のCNA（CVE Numbering Authorities、CVE採番機関）が分担します。

認定機関であるCNAが脆弱性の公表からID付与までを担当する

CNAは、自社製品やオープンソースなど特定の範囲について、MITREに都度問い合わせずにCVE IDを割り当てられる認定機関です。Microsoft、Red Hat、Googleなど大手ベンダーのほか、日本ではJPCERT/CCがCNAとして国内の調整役を担っています。CNAが各地で並行して採番することで、脆弱性の公表からID付与までの時間が短くなり、件数増にも対応できる設計です。CNAが扱えない範囲は、最上位の調整役であるルートCNAやMITREが受け持ちます。

製品開発者が自分でCVEを取得したい場合の申請窓口と採番基準

製品やOSSの開発者が、自ら見つけた脆弱性にCVEを付けたい場面もあるはずです。その場合、まず対象製品を所管するCNAがあるかを確認し、なければMITREのCVE採番依頼フォーム（cveform.mitre.org）から申請します。申請には影響製品・バージョン・脆弱性の種類・再現条件などの情報が必要で、要件を満たすとCVE IDが割り当てられる流れです。報告すれば必ず付与されるわけではなく、CVEの採番基準（独立した製品で、修正可能な欠陥であること等）を満たす必要があります。

CVEとCVSS・CWE・CPEの違い：役割の分担で覚える整理

CVE周辺で最も混乱しやすいのが、CVSS・CWE・CPEとの違いです。これらは競い合う関係ではなく分業の関係にあり、「何を答えるか」で切り分けると一度で整理できます。GSCでも「cveとcvssの違い」「cve nvd 違い」「cveid」が同時に検索されており、読者は役割の区別を求めています。

つまり一つの脆弱性に対して、CVEが名前を、CVSSが点数を、CWEが種類を、CPEが影響対象を与えます。たとえば「CVE-2025-55182」では、CVSSが10.0（Critical）、CWEが「CWE-502 信頼できないデータのデシリアライゼーション」、CPEが（付与されれば）影響を受けるReactのバージョン範囲、という形で一式が紐づきます。CVSSの基本値だけ見て対応を決めると過不足が出やすいため、後述のSSVCやKEVと併用するのが実務の流れです。

CWEとの違いは、とりわけ問い合わせが多い論点です。CVEが「個別の事件番号」なら、CWEは「罪状の分類」にあたります。両者の関係と使い分けはCWEとCVEの違いと相互関係を比較した解説で詳しく扱っています。

CVEとNVD・JVNの違い：識別子と詳細データベースの関係

CVEは識別子のリストであり、そこに技術的な肉付けをするのがデータベースです。代表が米国NVDと日本のJVNで、「cve nvd 違い」「nvd cve」もよく検索されます。

NVDはCVEに深刻度と影響範囲を足した米国の拡張データベース

NVD（National Vulnerability Database）はNISTが運営し、CVEを取り込んだうえでCVSSスコア、CWE分類、CPE（影響製品）などのメタデータを付与します。CVEが「何が問題か」を示し、NVDが「どれだけ深刻で、どの製品に効くか」を補う関係です。実務では、CVE番号を起点にNVDのページを開き、スコアと影響範囲を確認する流れが基本になります。

JVNは日本語で脆弱性情報を確認できる国内向けの公式ポータル

JVN（Japan Vulnerability Notes）はJPCERT/CCとIPAが共同運営する国内向けのポータルで、CVE番号で検索して日本語の脆弱性情報を確認できます。緊急性の高いものは「JVNVU」、網羅的な蓄積は「JVN iPedia」で扱われ、国内製品独自の情報も載るのが特徴です。海外DBより多少の時間差はありますが、日本語で初動判断をしたい場面で役立ちます。CVE→NVD→JVNと辿れば、同じ脆弱性を英語の一次情報と日本語の補足の両面から把握できます。

CVEの実務での使い方：スキャナー検出から対応判断までの流れ

CVEがどこで使われるかは「cve脆弱性対応方法」「cve 脆弱性スキャナー」といったクエリに表れています。CVE番号は、検出から優先順位付け、対応報告までを貫く共通言語として働きます。

脆弱性スキャナーやSBOMとCVE番号を突き合わせる資産照合

脆弱性スキャナーや資産管理ツールは、検出した問題にCVE番号を添えて出力する形です。担当者はその番号をNVD/JVNで引き、影響製品・版が自社環境に該当するかを確認します。SBOM（ソフトウェア部品表）とCVEを突き合わせれば、利用中のライブラリに既知の脆弱性がないかを機械的に照合できます。OSSの依存関係に潜む脆弱性は気づきにくいため、CVEを軸にした自動照合が現実的です。こうした照合や優先順位付けを社内リソースだけで回すのが難しい場合は、外部の脆弱性診断・セキュリティ診断サービスで現状を棚卸しし、検出されたCVEへの対応方針を整理する進め方もあります。

対応の優先順位はCVSS単独ではなくKEVやSSVCで決める

対応の優先度をCVSSスコアの高さだけで決めるのは、現場では不十分です。CVSS 9.0でも自社で該当製品を使っていなければ急ぐ必要はなく、逆にスコアが中程度でも実際に攻撃が観測されていれば最優先になります。そこで最近は、運用文脈を加味するSSVC（ステークホルダー特定脆弱性分類）や、悪用が確認された脆弱性をまとめたCISAのKEV（Known Exploited Vulnerabilities）カタログの併用が実務的です。「KEVに載っている＝いままさに悪用されている」ため、KEV掲載のCVEはスコアに関わらず即時対応の判断材料になります。具体例として、2025年末に大きく報じられたReact関連の脆弱性は、影響範囲と悪用状況の両面から評価されました（背景はReact・Next.jsに発生した重大脆弱性とは何かを参照）。

2025〜2026年に起きたCVE運営体制の変化（独自解説）

CVEの解説記事の多くは定義と用語の違いで止まりますが、2025年以降のCVEは運営体制そのものが揺れ動きました。ここは他の入門記事が手薄な論点であり、脆弱性管理の前提が変わったため実務にも直結します。結論から言えば、「CVE番号さえあれば付帯情報も自動で揃う」という前提は、もはや無条件には成り立ちません。

MITRE契約の一時失効危機とCVE Foundationの設立

2025年4月、米国政府（DHS/CISA）とMITREのCVE運営契約が4月16日に失効するという通知が出て、プログラム停止の懸念が一気に広まりました。最終的にCISAが直前で契約を11か月延長し、即時停止は避けられました。この騒動を受けて、CVE Boardの一部メンバーが運営を一国の予算に依存させないために非営利の「CVE Foundation」を設立し、長期的な独立運営への移行を表明しています。CVEが事実上の国際標準でありながら、その資金基盤が脆かったことを露呈した出来事でした。

公式サイトのcve.orgへの移行とJSON 5.0系への刷新

運営の近代化として、旧来のcve.mitre.orgから公式ポータルがcve.orgへ移行し、データ形式もCVE JSON 5.0系（Record Format 5.x）へ刷新されました。新形式はPackage URL（PURL）による影響製品の表現に対応するなど、自動処理を前提とした構造になっています。脆弱性情報をAPIやSBOMツールで機械的に扱う流れが標準になりつつあり、CVEの取得元としてはcve.orgを一次情報とするのが現在の推奨です。

NVDのenrichment縮小がもたらす実務へのインパクト

もう一つ見逃せないのがNVD側の変化です。NVDは2024年2月から付帯情報（CVSS/CWE/CPE）の付与が大幅に滞り、2026年にNISTがリスクベースのトリアージへの移行を打ち出しました。CISAのKEVや連邦政府が指定する重要ソフトウェアなどを優先し、それ以外の多数のCVE（一部報道では約29,000件規模が「Not Scheduled」へ再分類）はCVSSやCPEが付かない可能性があります。これは「CVE番号を引けばNVDで深刻度と影響製品が必ず分かる」という従来の運用が崩れることを意味します。実務では、NVD一本に頼らず、cve.org、ベンダー公式、JVN、商用の脆弱性インテリジェンスを併用し、付帯情報の欠落を前提に複数ソースで補う運用が現実的です（各データベースの提供状況は変動するため、最新は各公式で確認してください）。

CVEが対象とする脆弱性の範囲とCVEが付与されない領域の限界

CVEは広範な脆弱性を扱いますが、すべてを網羅するわけではありません。対象や限界を理解しておくと、CVE番号が付かない脅威を見落とさずに済みます。

ソフトウェアもハードウェアも対象だが採番の可否には基準がある

CVEはバッファオーバーフロー、SQLインジェクション、クロスサイトスクリプティング（XSS）、認証不備などのソフトウェア脆弱性を中心に扱い、CPUの「Spectre」「Meltdown」のようなハードウェア脆弱性も対象です。一方で、採番には「独立して修正可能な、明確に影響を特定できる欠陥であること」といった基準があり、設定次第で生じる問題や対象範囲が曖昧なものは付与されないことがあります。すべての脆弱性にCVEが付くわけではない、という前提を持っておくと安全です。

ゼロデイやCVEが未採番の脆弱性はベンダー公式情報で補完する

ゼロデイ脆弱性（修正前に攻撃が始まる脆弱性）は、悪用リスクの高さからCVE採番と情報共有が急がれます。ただし、攻撃が観測されてもCVEが付くまでには時間差があり、その間はベンダー公式の緊急情報やKEVが頼りになります。CVE番号の有無だけで「既知/未知」を判断せず、ベンダーの臨時アドバイザリも監視するのが安全です。実例として、特定製品で次々と公表される脆弱性の流れは「7-Zip」脆弱性の全体像と2025年以降に公表された主要CVE一覧のように、CVE番号を時系列で追うと把握しやすくなります。

よくある質問

CVEの読み方と意味を一言でいうと何ですか？

CVEは「シーブイイー」と読み、Common Vulnerabilities and Exposures の略です。日本語の正式名称は「共通脆弱性識別子」で、世界中の脆弱性に共通の通し番号を付けるしくみを指します。1999年に米国のMITREが開始し、現在は脆弱性管理の事実上の国際標準です。番号自体は脆弱性の名前であり、危険度や対処法は別のCVSSやNVDが補います。

CVEとCVSSの違いは何ですか？

CVEは「どの脆弱性か」を識別する番号、CVSSは「どれだけ深刻か」を0.0〜10.0で評価するスコアです。役割が違うため両方を併用します。たとえば一つのCVEに対しCVSSスコアが付き、9.0以上ならCriticalと判断します。ただしスコアの高さだけで優先度を決めず、実際の悪用状況（KEV）や自社の利用状況も合わせて判断するのが実務的です。

CVE番号は誰がどうやって付けるのですか？

プログラム全体はMITREが運営し、実際の採番はCNA（CVE採番機関）が分担します。Microsoftなど大手ベンダーや、日本ではJPCERT/CCがCNAとして認定された機関です。製品開発者が自ら脆弱性にCVEを付けたい場合は、所管のCNAに連絡するか、MITREの採番依頼フォームから申請します。採番基準を満たす必要があり、報告すれば必ず付与されるわけではありません。

CVEとNVD・JVNはどう使い分けますか？

CVEは識別子のリスト、NVDはそこにCVSSやCWE、影響製品（CPE）を足した米国の拡張データベース、JVNはJPCERT/CCとIPAが運営する日本語のポータルです。CVE番号を起点に、英語の詳細はNVD、日本語の確認はJVNで引くのが基本の流れになります。ただし2026年以降はNVDの付帯情報が縮小しているため、ベンダー公式情報も併用してください。

2025年にCVEが終了するという話は本当でしたか？

2025年4月にMITREの運営契約が失効しかけ、一時的にプログラム停止が懸念されたのは事実です。ただしCISAが直前で契約を11か月延長し、停止は避けられました。さらに運営を安定させるためCVE Foundationが設立され、公式サイトもcve.orgへ移行しています。現在もCVEは続いて運用されており、終了したわけではありません。最新の運営状況は公式サイトで確認してください。より詳しくは、My WP Customize Admin/の記事で整理しています。

関連記事

• CVSSとは何か？その基本的な定義と重要性について
• CWEとCVEの違いと相互関係を比較した解説
• 「7-Zip」脆弱性の全体像と2025年以降に公表された主要CVE一覧
• React・Next.jsに発生した重大脆弱性とは何か