CVSSv3とは？v3.1の計算式・スコアの目安と3つの評価基準を解説

CVSSv3は、脆弱性の深刻度を0.0〜10.0の数値で表す共通脆弱性評価システム（CVSS）のバージョン3系で、2015年公開のv3.0と2019年公開のv3.1を指します。この記事では、FIRSTの仕様書にある重みと計算式をそのまま使ってスコアの出し方を追い、IPAが公開している21件の評価事例で一致を確かめたPythonの検算コードも載せます。CVSS全体の位置づけと、2023年11月に公開された後継のv4.0はCVSSとは？脆弱性の深刻度スコアの見方・計算方法とv4.0の変更点を解説で扱っています。

まとめ：CVSSv3の要点

• CVSSv3は基本（Base）・現状（Temporal）・環境（Environmental）の3つの評価基準でスコアを出します。公開情報に載るのはほぼ基本値です。
• 基本値は8指標（AV・AC・PR・UI・S・C・I・A）の組み合わせで決まり、計算式と重みは仕様書で固定されています。同じベクトル文字列なら誰が計算しても同じ値になります。
• 深刻度の目安は、9.0〜10.0がCritical（緊急）、7.0〜8.9がHigh（重要）、4.0〜6.9がMedium（警告）、0.1〜3.9がLow（注意）です。
• v3.1は指標を増やしていません。変わったのは切り上げ関数の定義、環境値の一部の式、採点ガイダンスです。
• v4.0が公開された後も、NVDやベンダーはv3.1のスコアを併記し続けています。v3.1とv4.0の数値は同じ尺度ではないので、並べて比べないでください。
• 基本値は深刻度であってリスクではありません。対応順は、環境値・露出・悪用実績（KEV）と合わせて決めます。

CVSSv3の定義とv3.0・v3.1の公開時期

CVSSは、FIRST（Forum of Incident Response and Security Teams）のCVSS-SIGが管理する、ベンダーに依存しない脆弱性評価の手法です。IPAの「共通脆弱性評価システムCVSS v3概説」によると、2004年10月に原案が作られ、2005年6月にv1、2007年6月にv2が公開されました。v3は2012年6月に検討が始まり、2015年6月10日にv3.0が公開されています。

v3の設計で大きく変わったのは評価の単位です。v2は攻撃対象のホストやシステム全体で深刻度を見ていましたが、v3は仮想化やサンドボックス化の普及を受けて「脆弱性のあるコンポーネント」単位で評価します。この考え方から、影響がコンポーネントの外へ広がるかを表すスコープ（S）という指標が生まれました。

FIRSTのCVSSページでは、現在v4.0の文書が先頭に並び、v3.1とv3.0は「Archive」の見出しの下にあります。ただし、実際に公開されるスコアは今もv3.1が中心です（後述）。

v3.0からv3.1で変わった計算結果と変わらない計算結果

v3.1のUser Guideは、変更の範囲を「新しい指標や指標値を追加せず、既存の式にも大きな変更を加えない」と説明しています。ベクトル文字列の先頭が CVSS:3.0/ から CVSS:3.1/ に変わりますが、8つの基本指標と重みは同じです。計算結果に影響する変更は次の2つです。

• Roundup関数の再定義：v3.0の「Round up」は、浮動小数点の誤差で0.1ずれることがありました。v3.1は、入力を100,000倍して整数に直してから切り上げる方式を仕様書のAppendix Aで示しています。User Guideは、基本値が2.5・5.0・10.0でE:H/RL:U/RC:Uの組み合わせでは、現状値がv3.0より0.1低くなると明記しています。
• 環境値のModifiedImpactの式：修正スコープが「変更あり」で、要求度（CR・IR・AR）のどれかが「高」のとき、v3.0では値を上げる方向の設定をしても環境値が下がる逆転がありました。v3.1は末尾の指数を15から13に変え、MISSに0.9731を掛けて修正しています。User Guideによると、環境値が0.1上がる組み合わせは7%未満、0.1下がる組み合わせは1%未満で、0.1を超える差はありません。

User Guideが差分として挙げているのは現状値と環境値だけで、基本値の差は挙がっていません。計算以外では、隣接（A）の定義がMPLSやVPNのような論理的に隣接するネットワークまで広がり、ライブラリの採点指針や、追加指標を定義するExtensions Frameworkが入りました。

CVSSv3スコアの目安：深刻度5段階と0.0〜10.0の対応

「CVSSv3のスコアの目安は？」への答えが、仕様書のTable 14にある定性的な深刻度の区分です。日本語はIPAの訳語を併記しました。

仕様書はこの区分の使用を任意としています。区分の境目にも余裕が取られていて、式を作る際には、想定した深刻度から0.5の範囲に収まるずれを許容しています。仕様書は、Highを想定した組み合わせでも6.6〜9.3の値になりうると書いています。6.9と7.0の0.1差を根拠に対応期限を大きく分ける運用は、この精度を超えた使い方です。

基本評価基準（Base）の8指標と計算に使う重み

基本評価基準は、時間や利用環境で変わらない脆弱性そのものの性質を評価します。各指標の値と、計算式に入る重み（仕様書Table 16）は次のとおりです。

攻撃のしやすさを表す4指標（AV・AC・PR・UI）と影響を表す3指標（C・I・A）を別々に計算して足し、スコープで式を切り替える構造です。

攻撃容易性の4指標：AV・AC・PR・UI

攻撃元区分（AV、英語名Attack Vector）は、ネットワーク（N）・隣接（A）・ローカル（L）・物理（P）の4段階です。物理はv3で新設された値で、v2ではUSB経由のような攻撃もローカルに含まれていました。必要な特権レベル（PR）とユーザ関与レベル（UI）もv3で入った指標です。v2の「攻撃前の認証要否（Au）」は廃止され、PRの一部として評価するようになりました。

攻撃条件の複雑さ（AC）はv2にも同名の指標がありました。v3.1では、ACの説明から「特定のシステム設定の有無」という表現が削除されています。攻撃に特定の設定が必要でも、それが合理的な設定であれば、その設定で動いている前提で採点します。

スコープ（S）：影響が脆弱なコンポーネントの外へ及ぶか

スコープは、脆弱性のあるコンポーネントと、影響を受けるコンポーネントが同じ権限の範囲にあるかを表します。IPAは、Webアプリのクロスサイトスクリプティングが利用者のブラウザに影響する例と、ゲストOSの脆弱性がホストOSに影響する例を挙げています。

変更あり（C）では影響度の式が変わって合計に1.08が掛かり、PRの重みも上がります。IPAの集計では、全組み合わせの平均値がスコープ変更なしで4.99、変更ありで6.00です。満点の10.0は、スコープ変更ありでなければ出ません。NVDはLog4Shell（CVE-2021-44228）を S:C で10.0と評価しています。なお、評価が後から見直される例もあります。CVE-2026-40175（axios）は当初10.0とされましたが、のちに4.8へ下方修正されました。

影響の3指標：機密性・完全性・可用性

機密性（C）・完全性（I）・可用性（A）は、それぞれ高（H）・低（L）・なし（N）で評価します。v2は「部分的／全面的」という影響の広さで判定していましたが、v3は重要な情報への影響があるかで判定します。この違いで、同じ脆弱性でもv2からv3で点数が大きく変わることがあります（後述のHeartbleed）。v3.1のガイダンスは、攻撃前から持っていた権限ではなく、攻撃によって新たに得られる権限の増分で影響を採点するよう定めています。

CVSSv3の計算式とベクトル文字列の読み方

ベクトル文字列 CVSS:3.1/AV:N/… の構造

ベクトル文字列は、評価に使った指標の値を1行で記録する形式です。先頭のバージョン識別子の後に「指標:値」をスラッシュで並べます。

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

この例は「ネットワークから・条件なしで・認証不要・ユーザ操作不要で攻撃でき、スコープは変わらず、機密性・完全性・可用性すべてに高い影響がある」という意味で、基本値は9.8です。現状・環境の指標は /E:F/RL:X のように後ろへ足します。スコアの数値だけでは根拠が分からないので、社内で記録するときもベクトル文字列ごと残してください。

9.8の計算過程：ISS・影響度・攻撃容易性

基本値は仕様書7.1節の式で計算します。上のベクトルに重みを当てはめると次のようになります。

• ISS（影響の小計）＝1 −（1−0.56）×（1−0.56）×（1−0.56）＝0.914816
• 影響度（スコープ変更なし）＝6.42 × ISS ≒ 5.873
• 攻撃容易性 ＝8.22 × 0.85 × 0.77 × 0.85 × 0.85 ≒ 3.887
• 基本値 ＝Roundup（min（5.873＋3.887, 10））＝Roundup（9.760）＝9.8

スコープ変更ありにすると、影響度は 7.52×（ISS−0.029）−3.25×（ISS−0.02）の15乗 ≒ 6.048 になります。1.08×（6.048＋3.887）≒10.73 は上限の10で切られ、10.0です。C・I・Aがすべて「なし」なら影響度が0以下になり、基本値は他の指標に関係なく0.0です。

Pythonでの検算コードとIPA掲載21事例での照合

次のコードは、仕様書の重み・式・Appendix Aの切り上げ方式をそのまま実装した基本値の計算です。

import math

AV = {"N": 0.85, "A": 0.62, "L": 0.55, "P": 0.2}
AC = {"L": 0.77, "H": 0.44}
UI = {"N": 0.85, "R": 0.62}
CIA = {"H": 0.56, "L": 0.22, "N": 0.0}

def roundup(x):
    # 仕様書 Appendix A の方式：整数に直してから小数第1位へ切り上げる
    i = round(x * 100000)
    if i % 10000 == 0:
        return i / 100000.0
    return (math.floor(i / 10000) + 1) / 10.0

def base_score(vector):
    m = dict(p.split(":") for p in vector.split("/")[1:])
    changed = m["S"] == "C"
    pr = {"N": 0.85, "L": 0.68 if changed else 0.62,
          "H": 0.5 if changed else 0.27}[m["PR"]]
    iss = 1 - (1 - CIA[m["C"]]) * (1 - CIA[m["I"]]) * (1 - CIA[m["A"]])
    if changed:
        impact = 7.52 * (iss - 0.029) - 3.25 * (iss - 0.02) ** 15
    else:
        impact = 6.42 * iss
    expl = 8.22 * AV[m["AV"]] * AC[m["AC"]] * pr * UI[m["UI"]]
    if impact <= 0:
        return 0.0
    total = 1.08 * (impact + expl) if changed else impact + expl
    return roundup(min(total, 10))

print(base_score("CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"))  # 9.8
print(base_score("CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"))  # 10.0
print(base_score("CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N"))  # 3.1

IPAのCVSS v3概説には、実在する21件の脆弱性についてv3.0のベクトルと基本値が載っています。この関数に21件のベクトルを入れると、21件すべてがIPA掲載の基本値と一致します。最後のprint文のベクトルは、そのうちの1件であるPOODLE（CVE-2014-3566）です。

切り上げを math.ceil(x * 10) / 10 で済ませると、User Guideが挙げる CVSS:3.1/AV:P/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:H/E:H/RL:U/RC:U で誤差が出ます。基本値5.0に0.92を掛けた値は、浮動小数点では4.6000000000000005になり、現状値が正しい4.6でなく4.7になります。v3.0時代の計算機と現状値が0.1ずれるのは、この切り上げが原因です（環境値は前述のModifiedImpactの変更も関わります）。

計算ツール：FIRST・NVD・JVNの計算機

公開されている計算機でも、指標を選べばスコアとベクトルが出ます。FIRSTの「CVSS v3.1 Calculator」（first.org/cvss/calculator/3.1）が基準となる実装です。NVDにもv3の計算機があります。日本語で使えるのはJVN iPediaの計算機（jvndb.jvn.jp/cvss/ja/v3.html）で、画面上の表記はv3.0です。基本値の全2,592通りの組み合わせで、素朴な切り上げとv3.1の切り上げ関数の結果は一致します。基本値だけならどちらの計算機でも同じ値が出ます。

現状評価基準（Temporal）：3係数で基本値を割り引く仕組み

現状評価基準は、攻撃コードの出回り具合や対策の有無など、時間とともに変わる要素を反映します。現状値は「基本値 × E × RL × RC」を切り上げたものです。

係数はすべて1以下なので、現状値が基本値を超えることはありません。「攻撃コードが公開されると現状値が上がる」というのは、E:U（未実証）からE:P（実証可能）やE:F（攻撃可能）へ変わって、割引が小さくなるという意味です。E:H（容易に攻撃可能）は、自動化された攻撃コードが出回っているか、攻撃コードなしで攻撃できる状態を指します。基本値9.8の脆弱性でRL:O・RC:Cなら、E:Uで8.5、E:Pで8.8、E:Fで9.1、E:Hで9.4です。どれも9.8を上回りません。

環境評価基準（Environmental）：自社環境でスコアを付け直す手順

環境評価基準は、利用者が自社のシステムに当てはめて付け直す部分です。1つは、機密性・完全性・可用性の要求度（CR・IR・AR）で、低 0.5／中 1／高 1.5 の係数を掛けます。もう1つは、基本指標を自社の実態で上書きする修正版の指標（MAV・MAC・MPR・MUI・MS・MC・MI・MA）です。修正後の影響の小計（MISS）は0.915で頭打ちになります。

IPAは、ネットワークから攻撃できる脆弱性でも、実システムでファイアウォールによってアクセスが限られていれば攻撃元区分を「隣接」と評価し直す例を挙げています。FIRSTのv3.1 User Guide（3.6節）も、インターネットから届かない安全なネットワークに置かれていれば、MAVを「隣接」にしてよいとしています。基本値9.8のベクトルに当てはめると、環境値は次のように下がります。

• MAV:A（社内ネットワークからしか届かない）→ 8.8
• MAV:L（その端末にログインしないと届かない）→ 8.4
• CR・IR・ARをすべてL（重要データを持たない検証環境）→ 8.0
• MAV:AとCR・IR・AR:Lの組み合わせ → 6.9

これらの値は、上の関数に環境値の式を足して計算し、FIRSTが配布する計算機のJavaScript（cvsscalc31.js）でも同じ値になることを確かめています。公開された基本値が9.8でも、社内限定の検証サーバーなら6.9のMediumまで下がります。逆方向の例もあります。基本値7.5のHeartbleed（C:H/I:N/A:N）に機密性の要求度CR:Hを付けると、環境値は9.3のCriticalです。環境値を付けずに基本値だけで対応期限を決めると、この差がすべて抜け落ちます。

CVSSv2とCVSSv3の違い：同じ脆弱性で点数が上下した6事例

IPAの21事例には、同じ脆弱性のv2とv3の基本値が並んでいます。差が大きい6件を抜き出しました。

上がった3件は、影響の判定基準とスコープの導入が効いています。Heartbleedは、v2では機密性が「部分的」でしたが、v3では重要な情報が漏れるので「高」になりました。JunosとESXiは影響が他のコンポーネントへ及ぶため、スコープ変更ありで評価されています。下がった3件のうち2件は、評価の前提が変わっています。Adobe Readerは不正なファイルを開かせる攻撃なので、v2のネットワークからv3ではローカル（AV:L）になり、新設のUI:Rも付きました。POODLEは中間者攻撃が前提なのでAC:Hで、新設のUI:Rも付いています。Shellshockは、v2ではネットワーク・認証不要で3つの影響が全面的なら10.0でしたが、v3ではスコープが変わらない限り上限は9.8です。

「v2とv3はどっちを使うか」の答えはv3（またはv4.0）です。2026年8月に公開されたCVEにもv2の値が683件付いていますが、683件すべてVulDBが付けたもので、同じVulDBがv3.1とv4.0の値も併せて付けています。NVDは、Heartbleedのような古いCVEにもv3.1の値（7.5）を付けて、v2の値（5.0）と併記しています。

2026年のCVSSv3の位置づけ：v4.0公開後もv3.1が併記される実態

v4.0の仕様書は2023年11月1日に初版が出ていますが、現場の数値は今もv3.1が中心です。NVD APIで2026年8月に公開されたCVE（取り下げを除く）12,259件を、2026年9月29日時点で集計しました。

• v3.1のスコアが付いたCVE：10,436件（85.1%）
• v4.0のスコアが付いたCVE：3,519件（28.7%）
• v3.xとv4.0の両方が付いたCVE：2,479件
• v3.xもv4.0もv2も付いていないCVE：692件

v3.1は8割を超えるCVEに付いていて、v4.0は3割に届きません。v4.0だけが付いたCVEは1,040件です。v3.1の値が付いた10,436件のうち、NVD自身の値があるのは770件です。それ以外は、CVEを採番したCNA（ベンダーや調査機関）の値や、CISAがADP（追加データの提供者）として付けた値（1,850件）です。同じCVEに付け手の違う複数のスコアが並ぶこともあるので、NVDで確認するときは誰が付けた値かも見てください。

同じ脆弱性にv3.1とv4.0の両方が付くと、数値が食い違います。F5はNGINXの脆弱性CVE-2026-42945に、v4.0で9.2（Critical）、v3.1で8.1（High）を付けています。v4.0は攻撃条件の扱いや影響の分け方が違う別の尺度なので、「v4.0では9.2に上がった」と読むのは誤りです。比べるときは同じバージョン同士で比べてください。この脆弱性の影響条件はNGINX Rift（CVE-2026-42945）の影響条件とPoC公開後の対応で解説しています。

基本値だけで対応順を決めてはいけない場面

v3.1のUser Guideは「CVSSは脆弱性の深刻度を測るもので、それだけでリスクを評価するものではない」と明記しています。基本値は、露出（インターネットから届くか）と悪用の実績を見ていません。

米CISAは2026年6月10日に拘束的運用指令BOD 26-04を出し、BOD 19-02とBOD 22-01を失効させました。新しい指令は、修正の緊急度を4つの変数で決めます。資産の露出、KEVカタログへの掲載、悪用の自動化の可否、悪用後の技術的影響です。実装ガイダンスには「BOD 19-02の失効により、連邦民間行政機関は脆弱性の優先順位付けにCVSSの使用を求められなくなった」とあります。ただし直後に、FIRSTのCVSS SIG消費者向け実装ガイダンスに沿うと続き、同ガイダンスの技術・脅威・環境の情報を使った優先順位付けを勧めています。CISAが外したのはCVSSそのものではなく、基本値だけで決める運用です。

「基本値9.0以上は即日、7.0台は月次パッチ」という一律ルールは採らないでください。HeartbleedはHigh（7.5）ですが、CISAのKEVカタログに2022年5月4日に登録されています。このルールでは、悪用が確認された脆弱性が月次に回ってしまいます。実務では次の順で判断します。

1. 公開されている基本値とベクトル文字列を確認します。
2. KEVへの掲載（悪用の事実）とインターネットへの露出を確認し、どちらかに当てはまれば基本値に関係なく先に対応します。
3. 残りは環境値を付けて自社の数値にし、その順に対応します。

ライブラリの脆弱性は特に注意が必要です。User Guideは、利用のされ方が分からないライブラリは「合理的な最悪ケース」で採点するよう定めています。自社製品で外部入力が届かない使い方なら、環境値で下げる余地があります。脆弱性管理を継続的なプロセスとして組み立てる考え方はCTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説を参照してください。

よくある質問

CVSS v2とv3はどっちを使えばよいですか？

新しく評価するならv3.1かv4.0を使い、v2は使わないでください。v2はユーザ操作の要否やスコープを評価できず、ファイルを開かせる攻撃などの点数が実態とずれます。2026年8月公開のCVEでは85.1%にv3.1の値が付いていて、v2の値はVulDBがv3.1・v4.0と並べて付けているものです。v2の値しかない古いCVEは、NVDでv3.1の値が追加されていないか確認してください。v4.0との使い分けは、配布元が付けたバージョンに合わせるのが原則です。

CVSSv3はいつ公開されましたか？

v3.0は2015年6月10日にFIRSTから公開されました（IPAの概説による）。改訂版のv3.1は2019年に公開され、指標を増やさずに定義の明確化と切り上げ関数の再定義を行いました。後継のv4.0は2023年11月1日に初版が出ています。v1は2005年6月、v2は2007年6月の公開です。

CVSS 9.8と10.0は何が違うのですか？

違いはスコープです。ネットワークから認証なし・操作なしで攻撃でき、機密性・完全性・可用性すべてに高い影響がある脆弱性は、スコープ変更なしなら9.8、変更ありなら10.0です。変更ありは、脆弱性のあるコンポーネントとは別の権限の範囲に影響が及ぶことを表します。ゲストOSの脆弱性からホストOSへ、Webアプリの脆弱性から利用者のブラウザへ、といった場合です。10.0は、スコープ変更ありでなければ出ない値です。Log4Shell（CVE-2021-44228）はNVDで S:C の10.0と評価されています。

攻撃コードが公開されると現状評価のスコアは上がりますか？

現状値は上がりますが、基本値を超えることはありません。現状評価の係数E・RL・RCは最大でも1で、攻撃コードが公開されるとEはU（0.91）からP（0.94）やF（0.97）に、自動化された攻撃が出回ればH（1）に変わり、割引が小さくなるだけです。基本値9.8の脆弱性で正式な修正が出ている場合、E:Uなら現状値8.5、E:Hなら9.4です。基本値より高いスコアが出るのは、環境評価で要求度を「高」にしたり、修正版の指標を基本指標より厳しく付け直したりした場合です。

CVSSv3.1とv4.0のスコアはそのまま比べられますか？

比べられません。v4.0は攻撃要件（AT）の新設、スコープの廃止と後続システムへの影響（SC・SI・SA）の分離など、指標の構成が変わっています。計算方法も、v3.1のような重みの掛け算ではなく、ベクトルをMacroVectorという集合に分けて補間する方式です。F5はCVE-2026-42945にv4.0で9.2、v3.1で8.1を付けていますが、深刻度が上がったわけではなく、尺度が違うだけです。どちらを採用するか決めたら、社内の基準も同じバージョンでそろえてください。

関連記事

• CVSSとは？脆弱性の深刻度スコアの見方・計算方法とv4.0の変更点を解説
• CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化
• CVEとCWEの違いとは？脆弱性管理の基礎をCVSS・相互関係とあわせて解説
• CVE-2026-40175（axios）とは｜CVSS10.0から4.8になった経緯と確認・更新手順
• CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説