IPAの解説によれば、CVEは1999年1月、アメリカのパーデュ大学で開かれたワークショップで、脆弱性に関する情報共有の方法としてMITREによって提案されたものです。目的ははっきりしています。「別々の組織が出した情報が、同じ脆弱性について語っているのかどうか」を判断できるようにすることです。

番号の形はとても単純です。

形式はIPA『共通脆弱性識別子CVE概説』の「CVE-西暦-連番」という説明にもとづきます。例に挙げたCVE-2007-5000は、同資料が挙げているApache HTTP Serverの脆弱性です。

ここで大事なのは2番目の「西暦」です。これは採番された年であって、危険度でも、発見された年でもありません。「古い番号だから安心」とは言えず、実際に2020年より前の番号が今も悪用され続けています。

日本語で読むときの番号

日本には、CVEとは別の識別番号があります。IPAとJPCERT/CCが共同運営するJVNとJVN iPediaの番号です。同じ1つの脆弱性に、3つの番号が付きます。

出典：IPA『共通脆弱性識別子CVE概説』の対応例。番号が3つあるのは重複ではなく、どのデータベースで見ているかの違いです。CVE番号があることで、この3つが同じものだと分かります。

つまりCVEの価値は「番号が付くこと」そのものではなく、世界中のバラバラな情報を1本の糸で結べることにあります。製品ベンダーの告知、セキュリティ企業のブログ、日本語のデータベース。表現も言語も違う情報が、同じ番号を持っていれば同じ話だと分かる。それが唯一で最大の役目です。

第1章 おわり — 次は第2章

まず規模から。CVEは、もう「たまに出る番号」ではありません。

NVDの件数は、NISTが公開しているAPIから2026年8月20日に取得した実測値です。JVN iPediaの件数はIPA『脆弱性対策情報データベースJVN iPediaの登録状況［2026年第2四半期］』（2026年7月15日公開）によります。

3か月で13,131件。1日あたり140件を超えるペースです。「出たCVEを全部見る」という運用は、もう成立しません。

日本語の情報は、どこから来ているか

ここからがこの記事の本題です。同じIPAの資料は、13,131件の内訳も公表しています。

出典：同上（表1-1）。割合は総数から筆者が計算しました。JVN iPediaは、国内開発者の情報、JVNで公表した情報、そしてNVDが公開した情報を集約・翻訳しています。

日本語で読める脆弱性情報の約99%は、アメリカのデータベースの翻訳です。これは日本の努力不足という話ではなく、世界中の製品を使っている以上そうなる、という構造の話です。ただし結果として、米国側の仕組みが止まると、日本語で読める情報も止まります。

2025年に起きたこと

その仕組みが、実際に一度揺れました。時系列で並べます。

出典：CISA『CISA Statement on CVE Program』（2025年4月16日）、『Statement from Matt Hartman on the CVE Program』（2025年4月23日）、『The Mandate, Mission, and Momentum to lead the CVE Program into the Future belongs to CISA』（2025年9月10日）。CVE Foundationについては、同団体が自ら掲げている「単一の資金源から、多様で安定した資金モデルへの移行を支援する」という説明によります。

CISAの9月のブログは、かなり踏み込んだ書き方をしています。「政府が主導する信頼できる脆弱性識別の仕組みなしに、国家のサイバー防衛は成り立たない」とし、民営化や別の管理者へ移す案について「魅力的に聞こえるかもしれないが、影響は深刻だ」と述べています。あわせて、実際に悪用されている脆弱性の一覧であるKEVカタログも、CVEプログラムなしには成立しないとしています。

第2章 おわり — 次は第3章

脆弱性が見つかってから、あなたが日本語でそれを読めるようになるまでの流れです。段階ごとに、利用者から見えているかどうかが変わります。

段階3の採番機関について、JPCERT/CCは国内初のCNAとして2010年に認定され、国内のパートナーシップや海外から報告された脆弱性関連情報に「自らの判断でCVE番号を付与」しています（JPCERT/CC）。段階6の集約・翻訳はIPAの資料による説明です。

この流れで押さえておきたいことが2つあります。

1つ目。番号は「危ない順」に付きません。採番は報告された順、対応が進んだ順です。だからCVE番号の若い・古いは、深刻さとまったく関係がありません。

2つ目。すべての脆弱性に番号が付くわけではありません。開発者が自社で見つけて自社で直したものには、番号が付かないことがあります。「CVEが出ていない＝脆弱性がない」ではない、ということです。

日本の窓口は、世界とつながっています

日本で脆弱性を見つけた人が届け出ると、情報セキュリティ早期警戒パートナーシップの枠組みで扱われ、JVNで公表されます。そのときJPCERT/CCがCNAとしてCVE番号を付けるため、日本発の脆弱性情報も、世界共通の番号を持って国際的に流通します。IPAの資料によれば、JVNとJVN iPediaは2008年10月からMITREが公表する「CVE情報源サイト」の1つとして掲載され、2010年1月にはCVE互換認定も受けています。

逆方向も同じです。海外で採番された番号が、JVN iPediaを通って日本語になる。第2章で見た13,011件は、この経路を通ってきた情報です。番号という共通の糸があるから、翻訳しても同じものだと分かる。それがこの仕組みの実務上の効き目です。

第3章 おわり — 次は第4章

CWEの件数はIPAの四半期報告にも出ており、2026年4〜6月に日本で登録された脆弱性の分類では、CWE-416（解放済みメモリの使用）が749件、CWE-79（クロスサイトスクリプティング）が697件で上位でした。

第4章 おわり — 次は第5章

個人にとってのCVEは、覚える対象ではありません。ニュースで番号を見たときに「自分の製品か」を確かめて、該当したら更新する。それだけです。番号そのものを追う必要はまったくありません。

4番目が、いちばん見落とされます。サポートが終わった製品は、脆弱性が見つかっても修正されません。「CVEが出ていないから安全」ではなく、「もう誰も見ていない」だけという状態になります。

第5章 おわり — 次は第6章

3か月で13,131件。1日140件を超える情報を人が読む運用は成立しません。組織の仕事は「全部見ること」ではなく、「見なくていいものを外すこと」です。上から順に絞ります。

順番は筆者による整理です。1と2ができていない状態で3以降だけを回すと、自社に関係のないCVEの点数を毎日眺めることになります。

情報の取り方については、日本語で完結する手段があります。IPAとJPCERT/CCが運営するJVN iPediaは、製品名でCVE番号を検索でき、日本語で読めます。IPAは脆弱性対策情報を収集するツールMyJVNも公開しています。英語の一次情報を毎日追えない組織でも、日本語側の入口があります。

第6章 おわり — 次は第7章

使う側として「御社が使っている製品にCVEが出ています」と言われたら

作った側として「御社の製品に脆弱性があります」と言われたら

作る側の体制については「PSIRTとは？連絡が取れない会社は、社名が公表されます」で詳しく扱っています。

第7章 おわり — 次は第8章

この用語とセットで覚えると理解が早くなる語です。

第8章 おわり — 最後にFAQ