2026/1/13

ServiceNow脆弱性管理の次なる進化「USEM」への移行戦略

はじめに

2024年12月のリリースにより、ServiceNowの脆弱性管理（Vulnerability Response）は、　「Unified Security Exposure Management（USEM：統合セキュリティ公開管理）」　を中心とした新たな構成フレームワークへと移行しました。

リリース当初は「名称変更」程度の認識もありましたが、詳細を調査してみると、今回は裏側のアーキテクチャ、特に設定周りのフレームワークが大きく刷新されていることが分かりました。
本記事では、このUSEMがこれまでのVRとどう違うのか、そして我々パートナーはいつ、どうやってお客様を新環境へ移行させるべきなのか、調査結果をもとにパートナー視点でまとめます。

本記事に関する重要な注意事項（セーフハーバー）

本記事の内容は、ServiceNowの将来の製品拡張や変更に関する将来見通しに関する記述（セーフハーバー声明）を含んでいます。記載されている機能やリリース計画は現時点のロードマップに基づくものであり、開発状況によって予告なく変更・延期される可能性がある点にご留意ください。

1. そもそもUSEMとは何なのか

USEMの核心は、これまで製品ごとに分断されていた 「VRフレーバー」の設定一元化 にあります。

設定の集約（統一構成フレームワーク）

VRからUSEMへの設定の一元化（Nano Bananaで生成）

以下の各製品（フレーバー）の設定が、一つの共通フレームワークに統合されます。

対象:

ホスト脆弱性（Host VR）
アプリケーション脆弱性（AVR）
構成コンプライアンス（CC）
コンテナ脆弱性（CVR）

一元化される設定

アサインルール
修復ターゲットルール
SLA
リスクスコア計算ルール
タスク作成（グループ化）ルール
例外管理など

「機能パリティ」問題の解決

これまでのアーキテクチャでは、あるフレーバー（例：ホストVR）に新機能が追加されても、他のフレーバー（例：アプリケーションVR）に対応するまでに時間がかかる「機能の格差（機能パリティ）」が発生していました。USEMでは管理層が共通化されたため、一つの機能強化がすべてのフレーバーへ同時に適用されるようになります。

データ層（エクスポージャーレイヤー）は引き続き独立

注意点として、設定は一元化されますが、テーブル（データ層）が統合されるわけではありません。脆弱性アイテム（VI）、アプリケーション脆弱性アイテム（AVI）、コンテナ脆弱性アイテム、CCテスト結果などの各テーブルはそのまま維持されます。USEMは、これら既存のデータの上に新しい「管理・構成レイヤー」を被せる構造をとっています。

2. 従来のVRと何が違うのか？

技術的な観点で調査したところ、決定的な違いは以下の2点に集約されると感じました。

① 設定フレームワークの統合

従来は「ホストVR」「App VR」「コンテナVR」「CC」それぞれで個別に「割り当てルール」や「リスク計算機」を設定する必要があり、管理が煩雑でした。 USEMではこれらが一つの共通フレームワークに統合され、 「資産の種類を問わず、同じロジックで担当者を割り当て、同じ基準でリスクを評価する」 ことが可能になっています。なお、Vulnerable Item (VI) や AVI といったデータを格納するテーブル構造自体は維持されるため、既存のデータレイヤーを活かしたまま、その上の「管理・構成レイヤー」だけがに刷新される形です。

USEMの構成イメージ（Nano Bananaで生成）

② 統一されたユーザーエクスペリエンス

USEMの導入により、新しい「Security Exposure Management Workspace」が提供されます。アナリストや管理者など、すべての役割に対して単一のインターフェースを提供します。これまでは製品ごとに画面を行き来してレポートを作成していましたが、USEMでは全資産の公開情報を横断的に可視化できます。また、ここには 生成AIAI（Now Assist for VR） も統合されています。例えば、例外申請の承認画面で「過去の類似ケースに基づき、承認すべきか否か」の推奨理由を提示したり、複雑なダッシュボードの状況をインサイトとして自動要約したりと、実用的なAIアシストが備わっています。

なお、実運用への影響を考慮し、従来の 「IT Remediation Workspace」は移行後もインスタンス内で引き続き利用可能 となっています。これは、現場の修復担当者が新しい「Security Exposure Management Workspace」に習熟するための猶予期間して提供されています

Security Exposure Management Workspace

3. 「いつ上げるべき？」バージョン選びとロードマップ

実案件で悩ましいのが「いつアップグレードするか」ですが、現状は以下の2つの選択肢があります。

v26 (Business as Usual): 従来のVRのまま使えるマイナーアップデート版。
v30 (USEM): 新フレームワークに切り替わるメジャーアップデート版。

推奨される戦略

新規導入の場合

これから新しくVRを導入する場合、後からの移行コストを考えると、最初から v30 (USEM) で利用開始するのが良さそうです。

既存顧客の場合

現在すでにVRを利用中の場合は、「Brazil」リリースというタイムリミットを意識する必要があります。調査によると、将来のプラットフォームリリース（Brazil）のタイミングで、全てのVRインスタンスが強制的にUSEM仕様へ統合（True up）される計画になっているとのこと。今は「猶予期間」ですが、ずっとv26に留まることはできません。お客様のアップグレード計画に、今のうちから「USEM移行」を組み込んでおくのが得策だと感じています。

USEMの移行ロードマップ（Nano Bananaで生成）

4. 成功のための「USEM移行ツールキット」

従来のプラグインアップデート（ストアマネージャー経由）でもUSEMへの移行自体は可能ですが、一部のUSEM固有の機能が利用できなくなる制限があります。ServiceNowは公式ガイダンスとして、専用の 「USEM Migration Toolkit」 の使用を強く推奨しています。
機能を確認したところ、以下の点がカバーされています。

事前診断: アップグレード前に「今のカスタマイズがどう影響するか」を可視化。
ルールの自動変換: 既存の割り当てルール等を、新フレームワーク用に自動で書き換え。

USEMの移行ツールキットの主な機能（Nano Bananaで生成）

ベンチマーク情報

資料によると、600個のルールと5,000万件の脆弱性アイテムがある環境でも、自動移行プロセスは約4時間で完了したとのこと。大規模環境のお客様にも提案しやすい実績値です。

まとめ：我々が今すべきこと

USEMへの移行は一度きりの作業ではなく、進化し続けるプラットフォームへの適応プロセスです。2026年現在、パートナーが注視すべきリソースと活動を整理します。

検証環境での「移行ツールキット」による事前診断

検証環境で公式のUSEM移行ツールキットを実行し、既存のカスタマイズ（Script IncludeやBusiness Rule）への影響を診断してください。本ツールはルールの自動変換に加え、USEMへのアップグレードの障壁となる技術的負債の可視化にも有効です。

「Brazil」リリースを見据えたロードマップの提案

2026年末頃に予定されているBrazilリリースでは、全インスタンスがUSEMへ強制統合（True up）される計画です。このタイムリミットを顧客に明示し、早期のロードマップ提案と予算確保を支援する必要があります。

VRからUSEMへ

本記事のインフォグラフィック（NotebookLMで生成）

USEMはビジネスサービスオーナーや技術担当者といった、より広範なペルソナへの対応を順次拡大しています。2026年は、このアーキテクチャの刷新をいち早く顧客のビジネス価値へと繋げることがパートナーとしての重要な差別化要因となるため、この進化を先取りし、組織全体のサイバーレジリエンスを向上させる戦略的パートナーとして支援を継続していきたいです。

本記事は2026年1月時点のServiceNow Communityおよび公式ドキュメントの情報に基づいています。