セキュリティ対策における「トリアージ」とは、発生したインシデントや発見された脆弱性に対して、深刻度・緊急度・影響範囲などを評価し、対応の優先順位を決めるプロセスのことです。脅威の数が増える一方で、対応できる人員は限られており「何を、いつ、どう対処するか」を素早く正確に判断する仕組みが、組織のセキュリティ水準を左右します。そもそも、すべてのアラートに同等のリソースを割こうとすること自体が、かえって重大な被害を招く原因になりかねないのです。
この記事では、セキュリティトリアージの概念と役割から、CVSS・KEV・SSVCといった評価指標の使い方、手動・自動それぞれの対応方法を解説します。
トリアージという言葉は、もともと救急現場で多数の傷病者の治療優先度を判断する医療用語で、セキュリティ分野ではこの概念を転用し、インシデントや脆弱性への対応順序を決める行為を指します。
セキュリティのトリアージが対象とするのは、大きく2つの場面です。1つは、インシデント（不正アクセス、マルウェア感染、情報漏洩の疑いなど）が発生した際の初期対応。もう1つは、自組織のシステムで発見された脆弱性への対処を決める場面です。どちらの場合も、「今すぐ対応すべきか」「後回しにできるか」「そもそも自組織に関係するか」を判断することがトリアージの核心になります。
トリアージは単なる優先順位づけではありません。「そもそも対応すべきインシデントか（誤検知や無関係な報告ではないか）」を見極める工程でもあり、重大なものを見逃すのはもちろん、対応不要なものに動いてしまうことも、リソースの浪費や情報の誤開示という別のリスクを生みます。
JPCERT/CCが公開する「インシデントハンドリングマニュアル（※）」では、インシデント対応の基本フローを「検知・連絡受付 → トリアージ → インシデントレスポンス → 報告・情報公開」の4段階と定義しています。この中でトリアージはフローの第2段階に位置づけられており、後続の対応の質と速度を決定づける重要なステップとして明示されています。
同マニュアルはまた、トリアージを適切に機能させるためには「あらかじめ判断基準を明確に定めておくべき」と指摘しています。つまりトリアージは、インシデントが起きてから即席で考えるものではなく、事前設計が前提の仕組みなのです。
※参考：JPCERT/CC「インシデントハンドリングマニュアル（2021年11月30日版）」
脅威の件数とセキュリティ人材の不足は、今や反対方向に動いています。すべてのインシデントや脆弱性に均等にリソースを配分しようとすれば、担当者は疲弊し、本当に重要な脅威への対応が遅れてしまうのです。トリアージが形式ではなく実務上の必要手段である背景を、データと現場の実態からお伝えしていきます。
IPAの「情報セキュリティ10大脅威 2026」では、組織向けの1位にランサムウェア攻撃が11年連続で選出され、うち6年連続1位にランクインしました。サプライチェーンや委託先を狙った攻撃が2位、AIの利用をめぐるサイバーリスクが3位と、脅威の多様化と高度化が続いています（※1）。
こうした脅威の増加に対し、人材側は深刻な状況にあります。国内では約11万人のセキュリティ人材が不足しているとの民間調査結果があり（※2）、ISC2（国際情報システムセキュリティ認証コンソーシアム）の2025年版調査では、国内回答者の94%が「スキル不足を感じている」と回答しています（※3）。また、CISO（最高情報セキュリティ責任者）等を任命している従業員301名以上の国内企業に限定しても、CSIRTに専任メンバーを1名以上配置しているのは約30%にとどまります（※4）。
脅威の数と対応できる人員の数は、反対方向に動いています。この非対称性こそが、トリアージを形式ではなく実務上の必要手段にしている最大の理由です。しかも近年は、この不足が「人数」だけの問題ではなくなってきています。同じISC2の調査は、人材の絶対数はやや増える一方で、進化する脅威に既存チームのスキルが追いつかない「スキルのミスマッチ」こそが最大のリスクだと指摘しています。
すべてのアラートに同等の優先度を与えて対応しようとすると、深刻ではないインシデントに担当者の時間とエネルギーが費やされ、本当に対処すべき脅威への対応が遅れます。これを「アラート疲れ（Alert Fatigue）」と呼びます。
また、誤った判断に基づいた対応はそれ自体がインシデントを引き起こしたり、被害を拡大する原因になったりするという指摘もあります（※5）。インシデントでないものをインシデントと誤判断して対応すれば、秘匿すべき情報を誤って開示するリスクがある。反対に、最優先で対応すべきインシデントを見落とせば、被害が広がります。全件対応は一見「抜け漏れのない対応」に見えますが、実態としては判断品質を落とし、組織全体の対応能力を低下させます。
トリアージが目指すのは、全件に対応することではありません。「何に対応し、何を対応しないか」を意識的に選択することです。この選択を事前設計された基準で行うことが、限られたリソースを最も効果的に活かす方法です。ここで押さえておきたいのは、対応しない判断も、放置ではなく積極的な選択である点です。軽微なものを意図的に後回し・対象外とし、重大な脅威にリソースを集中させるなど、線引きを堂々と行えることこそ、成熟したトリアージの条件だといえます。
※1 参考：IPA│情報セキュリティ10大脅威 2026
※2 参考：経済産業省│サイバーセキュリティ人材の育成促進に向けた検討会 最終取りまとめ（2025年5月）
※3 参考：ISC2│2025年版サイバーセキュリティ人材調査（Cybersecurity Workforce Study）
※4 参考：IPA│2024年度 中小企業における情報セキュリティ対策に関する実態調査 報告書（2025年5月）
※5 参考：JPCERT/CC│インシデントハンドリングマニュアル（2021年11月30日版）
トリアージの判断精度は、どの評価指標を、どのように組み合わせて使うかで大きく変わります。現在、実務でよく活用されている代表的な指標がCVSS・KEV・SSVCの3つです。それぞれの役割と特性を理解したうえで、組み合わせて使うことが重要です。
CVSS（Common Vulnerability Scoring System：共通脆弱性評価システム）は、発見された脆弱性のリスクを0〜10の数値で示す国際標準の評価指標で、FIRST（Forum of Incident Response and Security Teams）が管理しています。2023年11月にリリースされたCVSS v4.0においても、スコア区分はv3.x系から引き継がれており、以下のように整理されます（※1）。
| スコア | 深刻度ラベル |
|---|---|
| 0.0 | なし（None） |
| 0.1〜3.9 | 低（Low） |
| 4.0〜6.9 | 中（Medium） |
| 7.0〜8.9 | 高（High） |
| 9.0〜10.0 | 緊急（Critical） |
CVSSスコアはセキュリティ担当者が優先対応を判断する際の出発点となりますが、このスコアだけを見て対応順位を決めることには注意が必要です。CVSSはあくまで「脆弱性そのものの深刻度」を示す指標であり、自組織の環境や実際の悪用状況は考慮されていません。スコアが高くても、自組織に関係のない製品の脆弱性であればリスクは低く、逆にスコアが中程度でも、自組織の基幹システムに関わるものなら即対応が必要になります。
CVSSスコアはトリアージの第一フィルターとして使い、後述するKEVやSSVCと組み合わせて評価することが現実的な運用です。
KEV（Known Exploited Vulnerabilities：既知の悪用された脆弱性）は、米国CISA（Cybersecurity and Infrastructure Security Agency：サイバーセキュリティ・社会基盤安全保障庁）が管理・公開している脆弱性リストです。このリストに掲載されている脆弱性は、実際に攻撃者によって悪用されたことが確認されたものに限られています（※2）。
CVSSスコアが「理論上の危険度」であるのに対し、KEVは「現実に攻撃されている脆弱性」のリストです。この違いは実務において大きな意味を持ちます。たとえばCVSSスコアが7.5の脆弱性が100件あったとして、そのうちKEVに掲載されているものは数件だったとしましょう。掲載された数件は現在進行形で攻撃者に使われている脆弱性であり、対応の優先度は他の96件よりも明確に高くなります。
KEVカタログは定期的に更新されており、CISAのWebサイトから無償で参照できます。自組織のシステムや利用している製品と照合することで、緊急対応すべき脆弱性の絞り込みに役立てられます。KEVはもともと、米国の連邦政府機関に対して期限内の是正を義務づけるために作られたリストです。掲載されること自体が「猶予なく対処すべき」という判断を意味しており、民間企業にとっても、対応の緊急度を測る強い根拠になります。
SSVC（Stakeholder-Specific Vulnerability Categorization：ステークホルダー固有の脆弱性分類）は、カーネギーメロン大学ソフトウェア工学研究所（SEI）が2019年に開発し、CISAと共同でカスタマイズした脆弱性対応の優先順位付けフレームワークです（※3）。CVSSとKEVが「脆弱性の客観的な性質」を評価するのに対し、SSVCは「この脆弱性が自組織にとってどのくらい問題か」という文脈依存の評価を行います。
SSVCは複数の意思決定ツリーを用いて評価を進め、最終的に取るべき行動（「今すぐ対応（Act）」「優先対応（Attend）」「監視継続（Track）」など）を導き出します。たとえば同じ脆弱性であっても、その脆弱性を持つ製品を本番環境で稼働させているかどうか、悪用した場合の業務影響はどの程度かによって、判断結果が変わります。開発者（Supplier）・利用者（Deployer）・調整者（Coordinator）という異なるステークホルダーに対して、それぞれ独立した評価ツリーが設計されている点も特徴です。ここで挙げたAct・Attend・Trackは、ソフトウェアを利用する側（Deployer）のツリーが導く結果です。開発者（Supplier）のツリーでは「Immediate（即時修正）」「Scheduled（計画的に修正）」のように結果の選択肢そのものが変わります。自組織がどの立場で判断するのかを最初に決めることが、SSVCを使ううえで重要です。
CVSSスコアに基づく一律のルールだけでは、自組織の実態にそぐわない優先順位が生まれることがあります。SSVCはその問題を補う役割を担い、より精度の高いトリアージを実現するための手段として活用されています。
実務においてよく見られる誤りが、「CVSSスコアの数値だけで対応順位を決めてしまう」ことです。
CVSSスコアはその設計上、特定の環境や組織の状況を考慮しません。スコアが9.0以上の「緊急」であっても、自組織でその製品を使っていなければ実質的なリスクはほぼゼロです。一方、スコアが5.0程度の「中」でも、それが自組織の顧客情報を格納するサーバーに影響する脆弱性であれば、即座な対応が必要になります。
さらに、脆弱性の数が増加する現代では、「緊急（Critical）」に分類される脆弱性だけでも相当数が毎月公開されます。それらすべてに最優先で対応しようとすると、担当者は疲弊し、かえって対応品質が下がります。KEVで悪用実績を確認し、SSVCで自組織の文脈を加味した評価を行う。この組み合わせがあってはじめて、CVSSスコアは実務で使える指標になります。
※1 参考：FIRST│CVSS v4.0 Specification Document
※2 参考：CISA│Known Exploited Vulnerabilities Catalog
※3 参考：CISA│Stakeholder-Specific Vulnerability Categorization（SSVC）
トリアージは、情報を集め、評価し、判断し、共有するという4つのステップで進みます。このフローをあらかじめ定めておくことで、インシデント発生時でも一貫した対応が可能になります。以下では、JPCERT/CCが定義するインシデントハンドリング（※1）の枠組みをベースに、脆弱性管理の文脈も加味して解説します。
最初に行うのは事実確認です。JPCERT/CCのマニュアルが例示する確認項目は、いつ・どこで・何が・どのようにの4点です（※1）。断定的な結論を出すことよりも、「対応すべき事象かどうかを判断するための情報を集める」ことがこの段階の目的です。
インシデントの場合は、報告者からのヒアリング、ログの確認、影響範囲の初期特定を行います。脆弱性の場合は、どのシステムが対象製品を使用しているかを確認します。この情報収集の精度が、後続のトリアージ判断の質を直接左右します。なお、インシデントは必ずしも自組織で検知できるとは限りません。内容によっては、取引先や外部機関からの通報がなければ気づけないものもあります。自組織の監視だけに頼らず、外部からの連絡を受け付ける窓口を用意しておくことも、情報収集の一部です。
収集した情報をもとに、深刻度と緊急度の2軸で評価を行います。深刻度は「この事象が組織にどれだけ大きな被害をもたらしうるか」、緊急度は「今すぐ対応しなければならないか」を意味します。深刻度と緊急度は別の軸です。深刻度が高くても緊急度が低いケースもあれば、その逆もあります。
脆弱性のトリアージでは、CVSS・KEV・SSVCを組み合わせてこの評価を行います。インシデントのトリアージでは、「自組織のシステムが実際に侵害されているか」「顧客データや基幹業務への影響はあるか」「外部への漏洩の可能性があるか」といった観点から判断します。あわせて欠かせないのが、自組織がどこまでリスクを許容できるかの視点です。同じ深刻度の事象でも、許容できるリスクの水準は組織によって異なります。この基準がないまま評価を進めると、判断が担当者ごとにぶれてしまいます。
評価をもとに、インシデントや脆弱性を以下の3区分に振り分けます。
| 区分 | 意味 |
|---|---|
| 即時対応 | 緊急かつ深刻なため、今すぐリソースを投入する |
| 計画対応 | 深刻だが緊急ではないため、定期メンテナンス等で対処する |
| 対応不要 | 自組織への影響がなく、対応の必要がない |
「対応不要」と判断した場合も、その根拠を記録に残すことが重要です。JPCERT/CCのマニュアルは、対応しない判断をした場合も、その根拠を自組織のポリシーに照らして報告者や関係者に伝えるべきと指摘しています（※1）。記録を残さなければ、後日なぜその判断をしたのかが検証できず、組織としての改善につながりません。
さらにトリアージでは、「自社で対応するか、外部に委託するか」の切り分けも行います。特に高度なサイバー攻撃が疑われる場合は、内部だけで判断せず、セキュリティ専門家による手動での詳細調査を早期に検討することが、被害の極小化に有効です。
対応区分が決まったら、複数の対応事項がある場合は優先順位を確定し、担当者・部門・外部委託先など関係者に伝えます。深刻度が高いインシデントであれば、経営層への報告も必要になります。
JPCERT/CCのCSIRTガイドでは、優先順位付けの判断基準を「あらかじめ可能な限り詳細に定めておくべき」と明示しています（※2）。インシデント発生後にゼロから考えていては判断が遅れます。関係者への連絡フロー・報告先・エスカレーション基準を事前に文書化しておくことが、このステップの品質を左右します。ただし、文書化がゴールではありません。CSIRTガイドでは、定めた手順が実際に機能するかを演習によって定期的に確かめ、問題が見つかれば手順を修正するよう推奨しています。
※1 参考：JPCERT/CC│インシデントハンドリングマニュアル（2021年11月30日版）
※2参考：JPCERT/CC│CSIRTガイド（2021年11月30日版）
手動と自動はそれぞれ適した領域が異なり、実務では役割を分けて組み合わせます。自動化ツールが一次処理の速度と量をカバーし、人による判断が文脈と精度を担う。この構造を理解したうえで、体制が整っていない組織の現実的な始め方も合わせて示します。
手動によるトリアージとは、セキュリティ担当者がCVSS・KEV・SSVCなどの情報を参照しながら、発見された脆弱性やインシデントを1件ずつ評価していくやり方です。
判断の文脈をきめ細かく反映できる点が強みです。自組織固有の事業リスクや、過去に類似インシデントを経験した際の知見を加味した評価ができます。一方、脆弱性の件数が増えるにつれて限界が明確になります。1件の評価に要する時間は数分から数十分かかることもあり、月に数百件の脆弱性情報が発生するような組織では、手動対応だけでは追いつきません。限界は件数だけではなく、判断が担当者の経験や、そのときの状況に左右されやすい点も課題です。同じ脆弱性でも人によって結論が変わるようでは、対応の一貫性は保てません。そのため、SSVCのように判断の道筋をあらかじめ決めておく仕組みが役に立ちます。
脆弱性管理の自動化ツールを導入することで、手動では対応しきれない件数に対して一定水準の評価を素早く処理できます。まず恩恵を受けるのはレビュー時間です。人が介入することなく、CVSS・KEV・SSVCに基づく初期評価が自動で行われます。加えて、自動ツールが一次評価を担うことで、開発エンジニアは本来の開発業務に集中できます。件数が多い場合も、緊急対応が必要なものと後回しにできるものを自動で振り分けられるため、担当者は優先度の高い案件から手をつけられます。
ただし、自動化は「判断の自動化」ではなく「一次処理の自動化」と捉えることが重要です。自動化ツールが出す優先度は、設定したルールや指標に基づく機械的な判断であり、自組織のビジネスリスクや攻撃の文脈を完全には反映できません。特に高度なサイバー攻撃や、複合的な要因が絡むインシデントでは、専門家による手動での詳細調査が不可欠です。自動化で処理できる範囲と、人による判断が必要な範囲を明確に分けて運用することが、実務における適切な使い分けです。自動化ツールの精度は、入力となる資産情報の正確さに大きく左右されるにも注意が必要です。どの製品をどのバージョンで、どこに使っているかが把握できていなければ、脆弱性情報と照合しても正しい結果は出てきません。ツールの導入前に、資産の棚卸しを整えておくことが重要です。
専任のセキュリティ担当者がいない、あるいはCSIRTを設置していない組織では、本格的なトリアージ体制を構築する前に何から手をつけるべきかが見えにくいものです。
まず取り組みやすい出発点は、自組織のシステム資産を一覧化し、各システムの業務上の重要度を定義することです。「基幹業務に影響するか」「顧客データを扱うか」「外部公開されているか」の3軸で資産を分類するだけでも、インシデント発生時の判断が格段に速くなります。
ただし「外部公開されているか」の軸は、自組織で把握しきれていない資産が残りやすく、棚卸しの抜け漏れがそのままリスクになりがちです。まずは現状を正確に把握するという意味で、外部からの視点で公開資産を洗い出すAttack Surface調査サービスのような手段で初期の棚卸しを固めておくと、以降の判断の土台がぶれません。そのうえで、CISAが公開しているKEVカタログを定期的に確認し、自組織が利用している製品と照合する習慣を作ることが、次の一歩になります。なお、KEVカタログは英語で提供されています。日本語で情報を追いたい場合は、JPCERT/CCとIPAが共同運営する脆弱性対策情報ポータル「JVN」や、JPCERT/CCの注意喚起も併せて確認するとよいでしょう。
こうして現状把握の土台ができれば、継続的な脆弱性管理の運用体制づくりへと無理なく進められます。
セキュリティにおけるトリアージとは、対応優先度を定め、限られたリソースを最も重要な問題に集中させるプロセスです。評価はCVSS（深刻度）・KEV（悪用実績）・SSVC（自組織の文脈）の3指標を組み合わせ、CVSSスコアだけで判断しないことが要点です。進め方は「情報収集 → 評価 → 対応区分の決定 → 共有」の4ステップ。自動化ツールは一次処理に有効ですが、高度・複合的なインシデントの最終判断には専門家の手動調査が欠かせません。
ユービーセキュアではこうしたセキュリティに関する相談を無料で承っていますので、何から手をつけるべきか定まっていない段階でもお気軽にご活用ください。