CVSSとは?スコアの見方と深刻度の評価基準を解説【最新v4.0対応】

・脆弱性の深刻度を測る世界共通の指標「CVSS」の仕組み
・CVSSスコアを算出する3つの評価基準と最新版v4.0の変更点
・実際のCVE事例と計算ツールを使った、スコア算出と優先順位判断の実践手順
・CVSSの限界を補い、より現実に即したリスク評価をおこなうアプローチ
CVSSとは、情報システムの脆弱性に対する深刻度を評価するための世界共通の指標です。
本記事では、CVSSスコアの意味・見方・評価基準・計算式・算出方法の説明を整理し、2023年に公開された最新バージョンv4.0の変更点や、脆弱性対応の優先度判断への具体的な活用方法までを分かりやすく解説します。サイバーセキュリティ担当者がおさえておきたい実務ポイントも網羅しました。
・CVSSスコアが示す深刻度レベルの具体的な見方
・CVSSスコアを算出する3種類の評価基準(v3系)
・最新バージョンCVSS v4.0の主な変更点を解説
・【実践】CVSSスコアの具体的な計算方法
・CVSSスコアをセキュリティ対策の優先順位付けに活用する方法 ・CVSSスコアの限界とそれを補う新しい評価アプローチ ・CVSSに関するよくある質問 ・まとめ
CVSS(共通脆弱性評価システム)とは何か?

CVSSは「Common Vulnerability Scoring System」の略で、日本語では「共通脆弱性評価システム」と訳されます。ソフトウェアや情報システムに存在する脆弱性の深刻度を、客観的な基準で数値化するための枠組み(スコアリングの仕組み)です。
仕様は米国の非営利団体 FIRST(Forum of Incident Response and Security Teams) が策定・管理しており、世界中のベンダー・公的機関・セキュリティチームで採用されています。
CVE番号を管理するMITRE、脆弱性情報をNVDによる公式スコアとして公開するNIST、Red Hatなど主要ベンダーも、このCVSSに準拠して脆弱性のrisk score(リスクスコア)を公表しています。金融・製造・医療など、あらゆる業種の情報システム部門で使われている、まさに世界標準の指標です。
なぜCVSSによる共通の評価基準が必要とされているのか
CVSS登場以前は、各ベンダーが独自基準で深刻度を公表しており、同じ脆弱性でも解釈がバラバラでした。CVSSという共通のものさしができたことで、国内外の組織が同じ土俵で脆弱性情報を共有し、迅速かつ的確なリスク判断を下せるようになっています。
CVSSの中核をなす情報セキュリティの3要素
脆弱性の深刻度をスコア化するプロセスにおいて、機密性(Confidentiality)、完全性(Integrity)、可用性(Availability)の3要素は情報セキュリティマネジメントの中核となる概念です。これらは英語の頭文字から「CIA」と呼ばれ、情報セキュリティの維持に欠かせない基本原則として位置づけられています。
・完全性:情報が改ざんされず正確な状態を保つこと
・可用性:必要なときにいつでもサービスを利用できること
これらは国際規格JIS Q 27000でも定義される情報セキュリティの基本原則であり、CVSSは脆弱性がこの3要素に与える影響度から評価値を算出します。
CVSSスコアが示す深刻度レベルの具体的な見方

CVSSスコアは0.0~10.0の数値で表され、値が大きいほど「攻撃の実行しやすさ」と「悪用時の技術的影響(機密性・完全性・可用性への影響)」が大きいことを示します。数値は複数の評価項目から計算式にもとづいて機械的に算出されるため、主観を排した比較が可能です。
「緊急」から「情報」まで5段階の深刻度レベル一覧
CVSSv3系・v4.0共通で、算出された基本値(基本スコア)にもとづいて深刻度を5段階のランクに分類します。
以下が一覧と対応目安です。多くの脆弱性管理ツールやセキュリティ勧告で採用されている区分で、実務でも検索・目安の確認に使われます。
| 深刻度 | スコア範囲 |
|---|---|
| 緊急(Critical) | 9.0~10.0 |
| 重要(High) | 7.0~8.9 |
| 警告(Medium) | 4.0~6.9 |
| 注意(Low) | 0.1~3.9 |
| 情報(None) | 0.0 |
特に7.0以上のハイスコアは、優先度の高い対応が必要な領域です。パッチ適用SLA(対応時間の目安)を社内ルールとして明文化しておくと、運用がぶれません。
CVSSスコアを算出する3種類の評価基準(v3系)

CVSSv3系(version 3.1)ではスコアを「基本評価基準」「現状評価基準」「環境評価基準」の3種類を組み合わせて算出します。脆弱性の内在的な危険性から、時間経過による脅威の変化、個別環境におけるリスクまでを多角的に評価する仕組みです。
基本評価基準(Base Metrics):脆弱性そのものの特性
基本評価基準は、脆弱性そのものが持つ不変の特性を評価する最も重要な評価基準です。以下の8つの評価項目で構成されます。
・攻撃の複雑さ(AC:Attack Complexity)
・必要な特権レベル(PR:Privileges Required)
・利用者の関与レベル(UI:User Interaction)
・影響の想定範囲(S:Scope)
・機密性への影響(C:Confidentiality)
・完全性への影響(I:Integrity)
・可用性への影響(A:Availability)
これらの要素から算出される「基本スコア」は、脆弱性の潜在的な深刻度を示し、対策を検討するうえでの最初の判断基準となります。
現状評価基準(Temporal Metrics):時間の経過による脅威の変化
現状評価基準は、時間の経過によって変化する脆弱性の脅威度を評価する基準です。以下の3つの評価項目で構成されます。
・対策情報の入手性(RL:Remediation Level)
・脆弱性情報の信頼性(RC:Report Confidence)
例えば、脆弱性が発見された当初は攻撃コードが存在しなくても、後に出回ることで現状評価スコアは上昇します。これにより、脆弱性が実際に攻撃される可能性を考慮した、より現実的な評価が可能です。
環境評価基準(Environmental Metrics):ユーザー環境に合わせた調整
環境評価基準は、脆弱性が存在するシステムを利用する組織側の個別要因を評価に反映するための基準です。CVSSv3.1では以下の項目を評価することで、汎用的な基本スコアを自組織向けに補正した環境値として算出します。
・完全性の重要度(IR:Integrity Requirement)
・可用性の重要度(AR:Availability Requirement)
・修正基本評価項目(Modified Base Metrics:基本評価項目を自社環境向けに再選択)
つまり、基本スコアが「その脆弱性の一般的な深刻度」を示すのに対し、環境評価基準は「その脆弱性が自社にとってどれほど危険か」を数値化する仕組みだといえます。
最新バージョンCVSS v4.0の主な変更点を解説

2023年11月に、CVSSの最新バージョンであるv4.0が正式にリリースされました。このアップデートは、よりきめ細かく、現実に即した脆弱性評価を実現することを目的としています。
「基本評価基準」の変更点
基本評価基準では、以下の3点が主な変更点です。攻撃の難易度や影響範囲を測る項目の見直し、利用者関与の細分化により、これまでよりも精密な深刻度の算出が可能となっています。
「攻撃の実行条件(AT:Attack Requirements)」が新設
v4.0では、攻撃を成功させるために必要な追加の前提条件を評価する項目として「攻撃の実行条件(AT)」が新設されました。v3.1にも「攻撃の複雑さ(AC)」はありましたが、ACには「攻撃者側の複雑さ」と「システム側の条件」が混在しており、両者を切り分けて評価するには不十分でした。
例えば「特定のオプションを有効化した場合のみ攻撃可能」「タイミング依存の競合状態(レースコンディション)を突く必要がある」といった脆弱性は、AT:Presentとして評価されます。
ACとATを分けたことで、「攻撃者側の難しさ」と「システム側の条件の厳しさ」を切り分けて評価できるようになり、より正確なリスク判断が可能になりました。
Scopeが廃止され「後続システムへの影響」を新設
v4.0では影響の想定範囲(S:Scope)が廃止され、代わりに影響評価が2系統に分けて評価される構造に変わりました。
具体的には、脆弱性が直接存在する「攻撃対象システム(Vulnerable System)」と、悪用によって間接的に影響を受ける「後続システム(Subsequent System)」のそれぞれについて、機密性・完全性・可用性の3項目を評価します。
利用者の関与レベル(UI)が2択から3段階(None/Passive/Active)に細分化
v3.1では利用者の関与レベル(UI)は「None(不要)」か「Required(必要)」の2択でしたが、v4.0では関与の度合いを3段階に細分化することで、より実態に近い評価ができるようになりました。
・Passive(受動的):利用者に意識的な操作は不要だが、特定の状態にあることが必要(例:メールをプレビュー表示する、罠のあるWebページを閲覧する)
・Active(能動的):利用者による明確な操作が必要(例:リンクをクリックする、添付ファイルを開く、認証情報を入力する)
Passiveの新設によって、「メールを開いただけで発火する脆弱性(ゼロクリック攻撃に近いもの)」と「利用者がクリックして初めて発火する脆弱性」を区別できるようになりました。前者のほうがリスクが高いのは明らかで、v4.0ではこの違いがスコアに正しく反映されます。
「現状評価基準」の変更点
現状評価基準では、名称・項目数ともに大きく変わり、より実際の脅威状況に即した評価ができる仕組みに刷新されました。
「現状評価基準」の名称を「脅威評価基準(Threat Metrics)」に変更
CVSSv4.0で現状評価基準を刷新して導入された「脅威評価基準(Threat Metrics)」は、脆弱性が悪用される可能性を評価するための評価項目です。
具体的には、「攻撃実証コードの有無(Exploit Maturity)」というメトリクスで評価します。これは旧バージョンの現状評価基準の考え方を引き継ぎつつ、よりシンプルに攻撃される可能性を評価に組み込むことを目的としています。
v3.1の現状評価基準では「攻撃コードの有無(E)」「対策情報の入手性(RL)」「脆弱性情報の信頼性(RC)」の3項目で評価していましたが、v4.0では実務上もっとも重要な「攻撃実証コードの有無」に一本化され、判断のしやすさが向上しました。
この指標により、対策の優先順位付けがより現実の脅威に基づいておこなえるようになります。
「環境評価基準」の変更点
環境評価基準では、医療機器や産業制御システムなど、物理的な被害や人命に関わる分野への対応が強化されています。
「安全性(Safety)」を追加し4段階評価に拡張
CVSSv4.0では、環境評価基準の「緩和策実施後の基本評価の再評価」において、後続システムの完全性への影響と後続システムの可用性への影響の評価値が拡張されました。従来の「高/低/なし」の3段階に加え、新たに 「安全性(Safety)」 が追加され、4段階評価となりました。
・低(Low):影響が限定的
・なし(None):影響なし
・安全性(Safety):人命や身体、環境に危害が及ぶ可能性がある
「安全性」評価値の追加は、医療機器・自動車・産業制御システム(OT/ICS)・IoT機器など、サイバー攻撃が物理的被害や人命に直結する分野でCVSSがより実態に即した評価を可能にするためのものです。
これは、サイバーとフィジカルの融合が進む現代において、CVSSの適用範囲が情報システムを超えて広がりつつあることを象徴する重要なアップデートです。
そのほかの変更点
上記の3つの評価基準ごとの変更に加えて、CVSSv4.0では以下の共通的な変更がおこなわれました。
v4.0で新設された命名規則:CVSS-B/BT/BE/BTE
CVSSv4.0では、スコアがどの評価基準を用いて算出されたかを明示するための命名規則が新たに導入されました。これにより、同じCVSSスコアでも「基本評価基準のみで算出された値」と「環境まで加味して算出された値」を混同することがなくなります。
表記を統一することで、組織間・ベンダー間のコミュニケーションが正確になる点が最大のメリットです。
| 表記 | 利用する評価基準 | 用途の目安 |
|---|---|---|
| CVSS-B | 基本評価基準のみ | ベンダーが脆弱性公表時に付与する標準スコア |
| CVSS-BT | 基本+脅威評価基準 | 攻撃コードの流通など、現実の脅威状況を加味したスコア |
| CVSS-BE | 基本+環境評価基準 | 自社環境の重要度を反映したスコア |
| CVSS-BTE | 基本+脅威+環境評価基準 | 脅威と環境を両方加味した最も現実に即したスコア |
実務では、NVDやベンダーが公表するのはCVSS-B(基本スコア)が中心ですが、真のリスク判断にはCVSS-BTEへの補正が推奨されます。特に優先度判断の場面では、自社にとっての本当のリスクスコアを得るために、脅威情報(EPSS/KEVなど)と環境要因(IT資産の重要度)の両方を加味することが重要です。
この命名規則を理解しておくと、脆弱性情報を受け取ったときに「このスコアは何を反映しているのか」を即座に判断できるようになります。
「補足評価基準(Supplemental Metrics)」が新設
補足評価基準は、CVSSスコアの算出には影響しないものの、脆弱性の性質を補足的に伝えるための情報項目として新設されました。スコアだけでは表現しきれない実務上の判断材料を、ベンダーやセキュリティチームが必要に応じて付与できます。
・Automatable(自動化可能性):攻撃の自動化が可能かどうか
・Recovery(復旧性):攻撃後にシステムを復旧できるか
・Value Density(価値の集中度):攻撃対象に含まれる資産価値の集中具合
・Vulnerability Response Effort(対応工数):対策に必要な工数の目安
・Provider Urgency(提供者による緊急度):ベンダーが示す緊急度(Red/Amber/Green/Clear)
これらはスコアには反映されないため、CVSS-B/BT/BE/BTEといった数値には影響しません。しかし、同じスコアでも「自動化可能な攻撃なのか」「復旧が困難なのか」といった実態を伝えられるため、受け手の判断精度を高める役割を担います。
【実践】CVSSスコアの具体的な計算方法

CVSSスコアは、脆弱性の情報をもとに各評価項目を選択していくことで、専門家でなくても算出できます。計算式そのものはFIRSTが公開している仕様書に定められていますが、実務では計算ツールの利用が一般的です。
JVN iPediaの計算ツールを使ったスコア算出の手順
日本国内で広く利用されているのが、IPA(情報処理推進機構)が運営する脆弱性対策情報データベース「JVN iPedia」のサイト上で提供されているCVSS計算ツール(Calculator)です。
このツールでは、Webページ上で各評価項目の選択肢をラジオボタンで選ぶだけで、対応するスコアが自動で計算・表示されます。脆弱性情報に含まれる評価ベクトル文字列を入力すれば、一括で設定も可能です。過去のCVEを検索して、過去のスコア10の事例(Log4Shellなど)と自組織の脆弱性を比較してみるのも学習に有効です。
なお、v4.0のスコア計算についてはJVN iPediaやNVDの各サイトで最新情報をご確認ください。海外の情報を確認する場合は、NVD scoreに加えてRed HatなどベンダーCNAが独自に付与するスコアも参考になります。
実際のCVEで見る採点例
CVSSスコアがどのように付けられるのか、実在する著名な脆弱性を例にみてみましょう。以下は過去のスコア10を含む代表的なクリティカル脆弱性の一覧です。
なお、RCE(Remote Code Execution:リモートコード実行)とは、攻撃者が遠隔から標的のシステム上で任意のコードを実行できる脆弱性のことで、CVSSでも最も深刻な部類に位置づけられます。
| 脆弱性(CVE) | 通称 | 公開時期 | CVSSスコア | 主な特徴 |
|---|---|---|---|---|
| CVE-2025-55182 | React2Shell | 2025年12月 | v3.1:10.0 / v4.0:9.3(Critical) | React Server Componentsの認証不要RCE |
| CVE-2024-53677 | - | 2024年12月 | 9.5(Critical) | Apache Struts 2のファイルアップロード機能を悪用したRCE |
| CVE-2024-6387 | regreSSHion | 2024年7月 | 8.1(High) | OpenSSHサーバーの認証不要RCE。ルート権限奪取が可能 |
| CVE-2021-44228 | Log4Shell | 2021年12月 | 10.0(Critical) | Javaログライブラリ経由の認証不要RCE。CVSS史上もっとも社会的影響が大きかった事例のひとつ |
Log4Shellのようにネットワーク経由・認証不要・影響甚大な脆弱性は、CVSSの評価軸において最高スコア帯(Critical)に位置づけられます。
各評価項目の選択に迷った際の判断基準
各評価項目の選択には、明確な基準があります。判断に迷った際は、JVNやNVDが公開している既存の脆弱性評価事例を参照するのが有効な手段です。
・攻撃条件の複雑さ(AC):ASLR回避などの特殊条件が必要か
・攻撃前提条件(AT、v4.0新設):特定の設定・モジュールが必要か、レースコンディションが必要か
・ユーザ関与レベル(UI):クリックなどの関与が必要か、必要ならPassiveかActiveか
CVSSスコアをセキュリティ対策の優先順位付けに活用する方法

日々発見される多くの脆弱性に対し、すべてを即座に対処するのは現実的ではありません。
そこで重要になるのが、CVSSスコアを活用したセキュリティ対策の優先順位付け(トリアージ)です。算出されたスコアを基準に、対応の緊急度を判断することで、限られたリソースを最もリスクの高い脆弱性へ効率的に配分し、組織全体のセキュリティレベルを効果的に向上させることが可能です。
基本スコアをもとにパッチ適用の緊急度を判断する
多くの組織では、脆弱性対応の第一歩として、CVSSの基本評価基準から算出される基本スコア(v3系のBase Score、v4.0のCVSS-B)を用いて緊急度を判定します。
特にスコアが「緊急(Critical)」や「重要(High)」に該当する脆弱性は、悪用された際の影響が大きいため、優先的にパッチ適用などの恒久的な対応を進めるのが一般的です。
環境評価基準を適用して自社環境における真のリスクを把握する
環境評価基準を活かすには、単に再計算するだけでなく、社内の情報を紐付けて運用に組み込むことが重要です。以下のステップで進めるのが実務的です。
2. 既存の緩和策を洗い出す:WAF、EDR、ネットワーク分離、権限制御など、すでに導入済みの対策を評価対象システムごとに整理する
3. 環境値を再計算する:JVN iPediaやNVDの計算ツールで、資産重要度と緩和策の効果を反映したModified Base Metricsを設定し直す
4. 対応判断に落とし込む:再計算後のスコアで改めてトリアージし、パッチ適用・回避策・受容の判断を下す
例えば、基本スコアが9.8(Critical)の脆弱性でも、該当システムが外部接続のない検証環境で機密データを扱っていなければ、環境値では6点台まで下がり優先度を下げられるケースがあります。
逆に、基本スコアが6.5(Medium)でも基幹システムで機密データを扱っていれば、環境値は8点台近くまで上がり最優先対応となることもあります。基本スコアを鵜呑みにせず、自社の資産情報と突き合わせて再評価することが、環境評価基準を実務で活かす鍵です。
IT資産管理とCVSSの併用がリスク低減の鍵
環境評価基準を活かすには、そもそも「自社にどんな資産があり、どのソフトウェアが動いているか」が可視化されていることが大前提です。
CVSSスコアやCVE番号は脆弱性の情報を教えてくれますが、それが「自社のどこに存在するか」を教えてくれるのはIT資産管理側の情報のみです。両者を突き合わせられる状態を作ることが、実効性のある脆弱性管理のスタート地点となります。
CVSSスコアの限界とそれを補う新しい評価アプローチ

CVSSは脆弱性管理において非常に有用な指標ですが、万能ではありません。スコアの数値だけを過信すると、実際のリスクを見誤る可能性があります。
そのため、CVSSの限界を理解し、EPSSやKEVといった補完指標を組み合わせることで、より精度の高いリスク評価を目指す動きが広がっています。
CVSSスコアだけでは実際の脅威を判断しきれない理由
CVSSスコアが高いことは「潜在的な」深刻度の高さを示すもので、「実際に攻撃される可能性」の高さと必ずしも一致しません。攻撃コード(Exploit)が存在しない、または攻撃再現が難しい脆弱性は、スコアが高くても現実のリスクは低いことがあります。
スコアだけで対応優先度を決めると、現実の脅威からズレた対策にリソースを割いてしまう可能性があるのです。
悪用可能性を予測するEPSSを組み合わせてリスク評価を高度化する
この限界を補う指標として注目されているのがEPSS(Exploit Prediction Scoring System)です。脆弱性が公開後30日以内に悪用される可能性を0~100%の確率で予測します。
CVSSが示す「深刻度」と、EPSSが示す「悪用される可能性」を掛け合わせることで、「深刻かつ攻撃される可能性が高い」本当に危険な脆弱性を特定できます。より効率的で効果的な脆弱性対応の実現につながる考え方です。
CISAのKEVカタログで「今まさに攻撃されている脆弱性」を優先する
KEV(Known Exploited Vulnerabilities) は、米国CISAが公開する「実際に攻撃が観測された脆弱性」のカタログです。KEVに掲載されている脆弱性は、CVSSスコアの高低に関わらず即時対応対象として扱うのが世界標準の運用になりつつあります。
SSVCという新しいアプローチ
FFIRSTとは別に、カーネギーメロン大学SEI(ソフトウェア工学研究所)のCERT/CCが2019年に開発し、CISAも採用しているSSVC(Stakeholder-Specific Vulnerability Categorization) も注目されています。SSVCは「スコアで表現する」のではなく「意思決定木で判断する」アプローチで、より実務的な優先順位付けを可能にします。
CVSSに関するよくある質問

ここでは、CVSSについて多くの人が抱く疑問や、関連用語との違いについて解説します。CVEとの関係性や、スコアの決定方法など、基本的ながらも重要なポイントをQ&A形式でまとめました。
CVSSとCVE・CWE・EPSS・KEVはそれぞれ何が違いますか?
CVSSは、CVE・CWE・EPSS・KEVといった他の脆弱性関連用語とよく混同されますが、それぞれ役割が異なります。全体像を整理すると以下のとおりです。
| 略称 | 名称 | 役割 | 例 |
|---|---|---|---|
| CVE | Common Vulnerabilities and Exposures | 脆弱性を一意に識別する「番号」 | CVE-2021-44228 |
| CVSS | Common Vulnerability Scoring System | 脆弱性の「深刻度」をスコア化 | 10.0(Critical) |
| CWE | Common Weakness Enumeration | 脆弱性の「種類」を分類 | CWE-79(XSS)など |
| EPSS | Exploit Prediction Scoring System | 「悪用される可能性」を確率で予測 | 0~100% |
| KEV | Known Exploited Vulnerabilities(CISA) | 実際に悪用が観測された脆弱性のリスト | ー |
なかでも、もっとも混同されやすいのがCVEとCVSSの違いです。CVEは個々の脆弱性を一意に識別するための番号(例:CVE-2021-44228)であり、脆弱性の「名前」に相当します。
一方、CVSSはその脆弱性の深刻度を評価するための指標、つまり危険度を示す「スコア」です。両者はセットで用いられることが多く、CVE番号で脆弱性を特定し、CVSSスコアでそのリスクを判断します。
実務では、CVE番号で脆弱性を特定し、CVSSで深刻度を判断、CWEで根本原因を把握、EPSSやKEVで実際の攻撃可能性を見極める、というのが現代の脆弱性管理の基本フローです。
CVSSスコアは誰がどのように決めていますか?
CVSSスコアは、脆弱性を発見した製品ベンダーや、NVD(National Vulnerability Database:米国国家脆弱性データベース)、日本のIPAといった公的機関が判定します。これらの組織が、CVSSの仕様を管理するFIRSTが定めた評価基準にもとづき、脆弱性の特性を分析して各項目を評価し、スコアを算出・公開しています。
CVSSスコアと「リスク」は同じ意味ですか?
いいえ、厳密には異なります。
NVDは公式に「CVSS is not a measure of risk(CVSSはリスクを測る指標ではない)」と明示しています。CVSSは脆弱性の深刻度(Severity)、つまり「悪用された場合にどれだけ悪い結果になり得るか」を評価する指標です。
実際のリスクは、深刻度に加えて「悪用される可能性(EPSS)」「実際に攻撃されているか(KEV)」「自社にとっての資産重要度(環境評価基準)」を掛け合わせて初めて評価できます。CVSSスコアだけを見て「危険度」を判断せず、複数の指標を組み合わせることが実務のポイントです。
まとめ

CVSSは、脆弱性の深刻度を客観的に数値化する世界共通の評価システムです。
基本・現状・環境(v4.0では基本・脅威・環境)の評価基準からスコアを算出し、v4.0ではさらに補足評価基準が情報項目として追加されています。最新のv4.0では、Scopeの廃止・Attack Requirementsの新設・影響評価の2系統化・補足評価基準の導入など、より現実に即した評価が可能になりました。
一方でCVSSスコア単体では実際の攻撃可能性を測れないため、EPSSやCISAのKEVカタログと組み合わせ、さらに自社のIT資産管理情報と突き合わせて活用することが、効果的なセキュリティ対策への近道です。
IT資産管理ツールSS1/SS1クラウドを開発・販売している、株式会社ディー・オー・エスの営業企画部メンバーで構成されています。IT資産管理・ログ管理・情報セキュリティ対策など、情シス業務の効率化に役立つ最新トレンド情報を随時発信中!

セミナー情報