ITOM のサブモジュールと契約区分の全体像：Discovery・Event Management・Cloud を PDI でどこまで試せるか

2026年10月15日 08:24

ITOM の提案書に、Discovery、Service Mapping、Event Management、Health Log Analytics と見慣れない製品名が並んでいます。どれが何の契約に入り、どれから手を付ければよいのでしょうか。

ITOM は、公式の概要ページで3つの観点に整理されています。CMDB を正しく保つ「ITOM Visibility」、障害を見つけて選り分ける「ITOM AIOps」、クラウドを統制する「ITOM Optimization」です。Brazil の PDI で各サブモジュールを確かめました。外部の機器やクラウドなしで試せたのは Event Management だけです。模擬イベントの投入から、アラートの生成、相関、インシデントの自動起票まで確認できました。

検証環境：Brazil PDI / OOTB＋Event Management プラグイン＋AIOps Experience / 2026-10-14〜15 確認

画面で確かめた要点

ITOM は機能を Visibility・AIOps・Optimization の3つに整理している。契約パッケージには、ログ解析やクラウド向けの別区分もある
Discovery・Service Mapping・Service Graph Connectors は、CMDB に情報を集める側にいる
Event Management は、サービス影響の判断に CI とサービスの関連を使う
今回の PDI で自動起票を確認するには、プラグインに加えて Store アプリ AIOps Experience の追加が必要だった
Discovery・Service Mapping・Health Log Analytics・Cloud 系は、対象機器・MID Server・クラウドの資格情報・ML のどれかが要るため、PDI では動かしていない

PDI でどこまで試せるか

ITOM の主なサブモジュールを、PDI の状態と今回の試行範囲で並べます。判断の基準は、外部の機器・クラウド・ML・ライセンス付き機能に頼らず、PDI の中で動作と記録を確かめられるかどうかです。

表の内容を文字でも書き出します。

Discovery（機器を検出して CMDB を更新）：PDI で本体を確認できず、試せない。対象機器と MID Server が要る
Service Mapping（サービスの構成を作る）：プラグインは Inactive で、試せない。検出済みの CI が要る
Event Management（イベントをアラートにして起票）：プラグインは Active。模擬イベントで自動起票まで確認した。今回は AIOps Experience を追加している
Metric Intelligence（メトリクスの異常を検出）：PDI で確認できず、試せない。メトリクスの履歴と ML が要る
Health Log Analytics（ログの異常を検出）：PDI で確認できず、試せない。ログの取り込み経路が要る
Cloud 系（クラウド資源の検出と統制）：Cloud API は Inactive で、試せない。クラウドの資格情報が要る

Event Management でも、監視ツールとの実接続は確認していません。確認したのは、筆者が投入した模擬イベントの処理までです。

プラグインの状態は、System Plugins の一覧で確かめました。

①の Event Management 系プラグインは Active です。②の Cloud API と③の Service Mapping は Inactive で、ITOM Discovery License も Inactive でした。MID Server は Active です。

ITOM が扱うのは機械と構成の状態

ITSM は、インシデント・変更・サービス要求などの業務を管理します。多くは人の申告が起点です。

ITOM (IT Operations Management) が扱うのは、サーバーやネットワーク機器、クラウド資源といった機械と、その構成の状態です。公式ドキュメントでは、次のように説明されています。

IT インフラとサービスの状態を把握する
CMDB を正確に保つ
障害を予兆・検知して運用を自動化する

ITSM に比べると、ITOM は入力の起点が機械に移ります。機械が出す大量の信号を整理して、必要なものだけを人の仕事（インシデント）に変える役割も担います。

監視の警報が人の作業になるまでを、次の図にまとめます。

図の内容を文字でも書き出します。

① 見える化（CMDB・サービス）：どの業務に響くかを教える台帳。トリアージを下から支える
② ITOM トリアージ：警報を選り分け（ノイズを捨てる）、まとめ（同じ原因を1つに）、順番を付け（業務への影響）、担当に渡して復旧で閉じる。結果は ITSM のインシデントになる
③ 予兆検知：数値やログの異常を見つけ、トリアージへ渡す
④ 自動化・AI：自動対処と要約。トリアージの先で使う

図の ③ と ④ は、今回 PDI で動かしていません。

3つの観点と契約パッケージ

公式ドキュメントは、ITOM の機能を次の3つで説明しています。

ITOM Visibility：機器やサービスを検出し、CMDB を充実させる。Discovery、Certificate Inventory and Management、Service Graph Connectors などが含まれる
ITOM AIOps：イベントとメトリクスから障害を検知・予兆する。Event Management と Metric Intelligence が含まれる
ITOM Optimization：クラウドのライフサイクル管理とガバナンス。クラウドワークフローの自動化などを扱う

この3つは、公式の概要ページでの整理にあたります。課金のパッケージには、ほかにも区分があります。

入門向けの ITOM Discovery
ログを扱う Health Log Analytics（AIOps の契約も別途必要）
クラウド向けの ITOM Cloud Accelerate

公式の契約ページは、課金の仕組みを次のように説明しています。

The ServiceNow AI Platform® uses a licensing method where your organization is billed for using the following IT Operations Management products: ServiceNow® ITOM Visibility, ServiceNow® ITOM Discovery, ServiceNow® ITOM AIOps, ServiceNow® Health Log Analytics, ServiceNow® ITOM Optimization, ServiceNow® ITOM Cloud Accelerate, ServiceNow® Service Reliability Management, ServiceNow® SLO Management, ServiceNow® Service Observability, and ServiceNow® synthetic monitoring.

（訳：ServiceNow AI Platform は、次の ITOM 製品の利用に対して課金する方式を採っています。ITOM Visibility、ITOM Discovery、ITOM AIOps、Health Log Analytics、ITOM Optimization、ITOM Cloud Accelerate、Service Reliability Management、SLO Management、Service Observability、synthetic monitoring）

引用元：Subscriptions for IT Operations Management

課金の単位は subscription units（SU）です。CI のカテゴリごとに、何 CI で 1 SU になるかが異なります。Visibility は検出した CI 数、AIOps はアラート・イベント・メトリクスを送る CI 数で数えます。比率は契約で決まるため、価格や比率は扱いません。

ITOM の構成要素の関係

各サブモジュールの関係を、次の図に示します。

起点は CMDB、緑は PDI で動かした機能、灰色は PDI で試せない機能、橙は人へ渡す先です。枠は機能上の分類で、契約範囲とは異なります。

図の接続関係を、文字でも書き出します。

Discovery、Service Mapping、Service Graph Connectors は、CMDB に情報を集める
MID Server は、Discovery の通信を中継する
Event Management は、CMDB の CI とサービスの関連を使って影響を判断する
Metric Intelligence と Health Log Analytics は、検出した異常を Event Management へ渡す
Event Management は、アラートをインシデントへつなぐ
ITOM Optimization と Cloud Accelerate は、クラウド統制を担う

サービス影響の判断は、CMDB の中身が最新であることを前提にします。

情報を集めるサブモジュール

ここからは、サブモジュールの役割を短く説明します。

Discovery

Discovery は、インフラのコンポーネントを自動で継続的に検出し、CMDB を最新に保つ機能です。検出の基本は horizontal discovery で、依存関係を持たない CI の検出を指します。AWS の検出では、エージェント型・エージェントレス・クラウド API・IP による OS レベルの検出を組み合わせます。実行は定期スケジュールか、ほぼリアルタイムです。公式の説明は Discovery のドキュメントを参照してください。

Service Mapping

Service Mapping は、アプリケーションサービスを検出し、機器・アプリ・構成の関係をマップにする機能です。上から下へたどる top-down mapping が基本で、タグ（key-value）からサービスを作る方法もあります。タグベースの説明は Tag-based mapping を参照してください。

Service Graph Connectors

Service Graph Connectors は、サードパーティの監視・管理ツールのデータを CMDB などのテーブルに取り込むコネクタです。ServiceNow Store から入手します。公式の一覧で提供中のコネクタを確認できます。

MID Server

MID Server は、ネットワーク内で動く Java アプリです。インスタンスと外部の機器・データソースの間で、通信とデータの移送を行います。Discovery やイベントの取り込みで通る経路です。MID Server の公式ページに概要があります。

Certificate Management

Certificate Inventory and Management は、TLS 証明書を検出して棚卸し・管理する機能です。期限切れによる停止を防ぎます。公式ページに詳細があります。

状態を見るサブモジュール

Event Management

Event Management は、監視ツールからのイベントを集約し、ルールで重複を排除してアラートにする機能です。アラートはどのサービスに影響するかまで結び付けられ、ITOM AIOps の中核を担います。案内ページは Exploring Event Management、AIOps 全体は Exploring ITOM AIOps にまとまっています。

Metric Intelligence

Metric Intelligence は、メトリクスを取り込み、履歴から異常を検出して anomaly alert を作る機能です。旧称は Operational Intelligence で、現在の公式ドキュメントでは Metric Intelligence として説明されます。公式ページが説明です。

Health Log Analytics

Health Log Analytics は、ログを取り込んで key-value に構造化し、パターンを検出する機能です。異常を見つけると、Event Management にイベントを送ります。契約上は ITOM AIOps とは別に必要です。公式ページが詳細です。

クラウドを統制するサブモジュール

ITOM Optimization は、クラウドのワークフロー自動化（コストの可視化などを含む）を扱います。ITOM Cloud Accelerate は、Tag Governance、Cloud Migration Assessment、Cloud Configuration Governance、Cloud Action Library を含む別の契約です。公式の案内は ITOM Optimization と ITOM Cloud Accelerate です。クラウド資源を API で検出する Discovery for AWS の説明もあります。

Cloud Provisioning and Governance（旧 Cloud Management）は、Brazil リリース以降、将来の廃止に向けて準備中で、新規インスタンスには入らないと公式に書かれています。新しく検討するなら、別のサブモジュールを前提にします。

試せた Event Management の実画面

Event Management は、監視ツールの信号をアラートにまとめ、インシデントへつなぐ機能です。PDI では、決済 DB の障害と後続の障害を想定した模擬イベントを投入しました。筆者が作った相関ルールで、親1件・子4件のアラートにまとめています。詳しい手順は単発記事に分けています。

同じ警報を監視メール1通ごとに起票すると8件のインシデントになる想定が、Event Management ではインシデント INC0010061（担当 Database）の1件になりました。ビフォー・アフターの比較は単発記事で扱います。

①の5件が、筆者作成の相関ルールで親子にまとまったアラートです。②の Priority group では、5件がそろって Urgent と表示されています。③の無関係なファイルサーバーの警告は Low と表示され、今回の自作の起票ルールの条件にも該当しませんでした。

AIOps 側の標準ダッシュボードも開きました。

①の AIOps 360° overview は、AIOps の効果を集約する標準ダッシュボードです。②の Value overview には削減時間を示す4つの枠（②は4枠全体を囲んでいます）が、③の Workload saving にはイベントからアラートへの絞り込みを示すグラフが並びます。画面にはデモ用の標準データも含まれるため、表示された数値は筆者の検証結果として扱わず、画面の構成の紹介にとどめます。

どこから導入を検討するか

導入の順序は、次の設計例が分かりやすいと考えます。以下は推奨例で、実際の順序は組織の体制に合わせて決めてください。

アプリケーションサービスと、それを構成する CI の関連を用意する：Event Management は、サービス影響の判断にこの関連を使います。
Event Management で監視の受け口を1本作る：既存の監視ツールを1つ選び、イベントをアラートにしてインシデントへつなぎます。外部の機器なしで模擬イベントから試せるため、効果を確かめやすい区分です。
Discovery と Service Mapping で CMDB を自動化する：手作業で用意した情報を、検出で置き換えていきます。MID Server と対象機器の準備が必要になるため、体制が整ってから進めます。

この順序にする理由は、Event Management の影響判断が、CI とサービスの関連を前提にしているからです。今回のデモでも、アプリケーションサービスを作成して CI を関連付けています。

実機を見て気づいたこと

Event Management はプラグインだけでは自動起票を確認できなかった

Event Management のプラグインを有効にすると、em_event・em_alert のテーブルが現れ、アラートまでは作られます。標準のアラート管理ルールにも Create Incident という名前のものがありますが、最初は inactive でした。有効にしても、インシデントは作られませんでした。

今回の環境では、Store のアプリ AIOps Experience（sn_sow_aiops）が入っていなかったことが、一因と考えられます。導入後に入ったアプリのうち、自動起票に関係する4つを抜き出します（直接の依存アプリは16個あります）。

①が AIOps Experience（27.2.51）です。②の3つのアプリは、アラートのルール管理、Event Management の中核、タグによるアラートのまとめ込みを担います。このアプリと依存アプリを入れたあとも、自作ルールの条件が一致しない問題が残りました。条件の type を表示名から参照先の sys_id に直して、はじめて自動起票を確認できました。

なお、画面から Quick Incident で手動起票する操作は、アプリを入れる前でも動きました。自動起票を試すなら、アプリ導入とルール条件の両方を見ておきます。

MID Server があっても Discovery は動かせない

MID Server は、インスタンスと対象機器の通信を仲介するアプリです。PDI には MID Server の ECC エージェントのレコードが1件ありましたが、Discovery のスケジュールは0件でした。Discovery 本体のプラグインも、PDI では確認できませんでした。Discovery を始めるには、検出対象の機器とライセンスの両方が要ります。PoC で試すなら、検出対象の検証用機器を先に用意します。

Service Mapping が Inactive でも共通部品のプラグインは Active だった

Service Mapping は、サービスの構成を作る機能です。PDI のプラグインは Inactive でした。一方、Event Management 側の com.snc.service-watch は Active で、その説明は「Event Management と Service Mapping の共通部品」となっています。確認できたのは、この共通部品のプラグインが Active だったことまでです。Service Mapping を後から追加できるかは、PDI では確かめていません。

このシリーズの記事

この記事は、ITOM のサブモジュールと契約区分の全体像です。詳細は次の記事で扱います。

検証範囲とおことわり

検証環境は Brazil Patch 0 の PDI です。契約区分の名称は、公式ドキュメントの記載を引用しています
価格と SU の比率は契約で決まるため、扱っていません
プラグインの「確認できず」は、v_plugin の検索で該当が無かったことを示します。未導入なのか、この API で見えないだけなのかは切り分けていません
Discovery・Service Mapping・Health Log Analytics・Metric Intelligence・Cloud 系は、PDI で動かしていません。説明は公式ドキュメントに基づきます
Cloud Insights と、ITOM 向けの Workflow・IntegrationHub spoke は、公式の専用ページを確認できていません
Event Management は、監視ツールとの実接続を確認していません。筆者が投入した模擬イベントと、筆者作成のルールで確認しています
テーブル全体の件数は掲載していません。画面の説明に出てくる5件・親1件・子4件・警告1件は、筆者が作ったデモ記録です
検証のため一部の設定を一時的に変更し、終了後に元へ戻しています