ServiceNowのDiscoveryは何を調べに行く機能なのか？ discovery_probes 143件を実機で分類する

2026年8月9日 20:38

「Discoveryを入れると、結局CMDBに何が自動で登録されるのか」を、実際に動かしたことがなくても知りたいという担当者は多いはずです。DiscoveryはOSやミドルウェア、仮想化基盤ごとに用意された「Probe（調査手順）」を組み合わせて情報を集め、その結果をCMDBのCIに変換する機能です。Zurich PDIには最初からProbeの定義が143件入っていました。今回はその中身を実機で分類しました。

検証環境：Zurich PDI / OOTB / 2026-08-09 確認

この記事で分かること

discovery_probes 143件が、対象別に5クラスへ分類されること
ITOM Discoveryのプラグインが無効なのに、Probe定義だけは最初から存在する理由
MID Serverが0台のPDIでは、Discoveryの実行結果画面は再現できないという事実
discovery_credentialsという名前のテーブルが、実はDiscovery専用ではないこと

結論：Discoveryは「143種類の調べ方」を使い分ける機能

先に全体像を示します。実機で確認できたのは次の3点です。

discovery_probesには143件のProbe定義が入っており、対象ごとに5つのクラスへ分かれています。
これらのProbe定義はITOM Discoveryのライセンスプラグインとは別枠（Core Automationというパッケージ）で提供されています。Discoveryをライセンス有効化していなくても最初から存在します。
一方でこのPDIにはMID Serverが1台も登録されていません。実際にスキャンを動かした記録（discovery_status / discovery_queue / discovery_result）は、すべて0件でした。

Discoveryは「調べ方の設計図（Probe）」と「実行するエンジン（MID Server）」が分かれた作りになっています。前者だけならプラグインの状態に関係なく、いつでも中身を見られます。まずはその143件がどう内訳されているかを見てみましょう。

画面右上に「143 total Probes」と出ています。ここでの分類軸はsys_class_name（Probeの実装クラス）です。この分類が、そのままDiscoveryが対応しているプロトコルや実行方式の種類を表しています。

公式のGet Started with Discoveryにも説明があります。Discoveryの実体は、MID Serverを介した複数プロトコル（SSH・WMI・SNMPなど）での調査です。実機の分類は、この「複数プロトコルを使い分ける」という設計をそのまま裏付けていました。

discovery_probes 143件はどう分類されるか

143件をsys_class_name別に集計し、それぞれの役割と主な対象を整理したのが次の表です。

汎用のProbe（111件）はコマンド実行が中心

もっとも多いのが汎用のProbe（discovery_probes）で111件です。UNIX系OS（Linux・Solaris・AIX・HP-UX）のOS情報の取得が中心です。Oracle・Apache・Tomcat・VMware vCenter・MySQL・PostgreSQLといったミドルウェアや仮想化基盤の調査も担当します。これらの多くはSSH経由でコマンドを実行し、結果をテキストで持ち帰る作りだと読み取れます。

WMI Probe（12件）とSNMP Probe（11件）は対象が違う

WMI Probeが12件あります。こちらはWindows専用です。WMI（Windows Management Instrumentation）というWindows標準のAPIを使って、OS情報・ハードウェア・サービス一覧・インストール済みソフトウェアを取得します。UNIX系がコマンド実行なのに対し、WindowsはOS標準の管理APIを叩く住み分けです。

SNMP Probeが11件です。こちらの対象はサーバではありません。ネットワーク機器（スイッチ、ルータ）やUPS、プリンタ、DRAC（サーバの管理コントローラ）が対象になります。OSにログインせず、SNMPで応答する機器の情報を取りに行く方式です。

MultiProbe（8件）とCommand Pipeline（1件）の役割

MultiProbeが8件あります。単体で情報を取るProbeとは役割が違い、複数のProbeをまとめて実行する「束ね役」です。中身はWindows・Linux・Solaris・AIX・HP-UX・Mac OS Xそれぞれの「Identity」でした。最初に接続した機器が何のOSかを判定する処理です。Discoveryが最初に行うのは「これは何の機器か」の判定であり、そのための専用クラスがあらかじめ用意されています。

残る1件がCommand Pipeline（Subnet Probe）です。サブネット単位でのスキャンを連鎖的に実行する特殊な役割で、他の142件とは仕組みが異なります。111+12+11+8+1で合計143件、画面の表示と一致します。

1件のProbeを開くと何が分かるか（Heartbeatの例）

分類だけでなく、実際に1件のProbeフォームを開いてみます。選んだのは「Heartbeat」です。MID Serverの死活監視に使われる、もっともシンプルなProbeです。

このフォームから読み取れる主なフィールドは次のとおりです。

Class：Probe（前章のsys_class_nameと同じ）
ECC queue topic：HeartbeatProbe。MID Serverとやり取りする際の宛先識別子です
Used by Discovery / Used by Orchestration：どちらもチェックが入っていません
Description：「MID Serverの基本機能をテストし、いくつかの基本統計情報を返す」

興味深いのは、HeartbeatはUsed by Discoveryがオフになっている点です。このProbeはDiscoveryのスキャンフローには直接使われません。MID Server自体が生きているかどうかを確認する、別の用途に割り当てられています。「Discovery配下のテーブルにある＝Discoveryが使う」とは限らないことが、1件を開いただけで分かりました。

なお全143件についてtypeフィールドを集計すると、例外なく全件がJavaでした。Probeの実処理はMID Server本体側のJavaクラスにあると考えられます。discovery_probes側のレコードは「どのJavaクラスを、どんな設定で呼び出すか」というメタデータに徹している設計です（この解釈は実機の集計結果からの推測です）。

used_by_discoveryとused_by_runbookは何を分けているのか

Heartbeatで見たUsed by DiscoveryとUsed by Orchestration（データ上のフィールド名はused_by_runbook）を、143件全体で集計しました。

used_by_discovery=trueが129件、falseが14件です。Heartbeatを含む14件は、Discoveryのスキャン本流では使われないことになります。

もう一方のused_by_runbook=trueは24件です。Runbook Automation（Orchestration機能の一部で、サーバ上で任意のコマンドを実行する仕組み）でも、同じProbe定義が呼び出されることを示しています。discovery_probesは「Discovery専用の置き場」ではありません。MID Serverを使う複数の機能が共有する部品置き場になっている、というのが実機から読める構造です。この2つのフラグは独立して立っているため、両方trueのProbe(DiscoveryからもRunbookからも呼ばれるもの)も存在すると考えられます。ただし、その重複件数までは今回のクエリでは分離できていません(検証範囲外)。

なぜプラグインが無効なのに、Probe定義だけ143件あるのか

ここが今回いちばん気になった点です。このPDIでITOM Discoveryのプラグイン状態を確認すると、次のようになっていました。

ITOM Discovery LicenseはInactiveです。Data Discovery APIsも同様にInactiveでした。名前に「Discovery」を含むプラグインを幅広く検索しましたが、有効化されているものは見当たりません。それにもかかわらず、discovery_probesには143件のレコードが最初から入っています。プラグインの有効化そのものについては、公式のActivate a pluginにも手順があり、この操作をまだ行っていない状態だと分かります。

Core AutomationとITOM Discovery Licenseは別物

MID Serverプラグイン（com.glideapp.agent）はActiveでした。143件のProbeが属しているsys_package（アプリケーションの分類）を確認すると、全件が同一のパッケージです。その名前は「Core Automation」でした。ITOM Discovery Licenseというライセンス系プラグインとは、明らかに別物です。

ここから読み取れるのは、Probe定義がMID Serverを使う自動化基盤(Core Automation)に同梱されるデータだという構造です。ITOM Discoveryという製品ライセンスの有効・無効とは切り離されています。MID Serverの仕組み自体はDiscovery専用ではありません。Orchestration（Runbook Automation）やService Mappingなど、複数の製品が共有する土台の一部です。その土台にProbe定義も基本セットとして含まれています。だからライセンスの有無にかかわらず、最初から存在すると考えられます。これはここまでの実機確認から立てた仮説です。sys_packageテーブル本体へのアクセスはACLで拒否され、パッケージの詳細プロパティまでは確認できていません。この説明には推測を含みます。

テーブルにレコードがあることと使える状態は別問題

読者にとっての実務上の教訓は単純です。「テーブルにレコードがあるかどうか」だけでは、その機能が使える状態かどうかは判断できません。ライセンスプラグインの状態は別途、v_pluginで確認する必要があります。

discovery_credentialsの4件は本当にDiscovery専用なのか

認証情報を管理するdiscovery_credentialsテーブルも見ておきます。

4件登録されていますが、内訳を見ると意外でした。画面の種別(Type)列で、Windows MID Server Service Accountの1件だけが「Windows」です。残る3件は、すべて「OAuth 2.0」でした。名前はSidebar - Slack User Token Credentials／Sidebar - Teams Credentials／Sidebar Slack Credentialsです。

Discovery(MID Server)用と呼べるのはWindows MID Server Service Accountの1件だけです。残り3件はSlackやTeamsとの連携用OAuth認証情報でした。テーブル名はdiscovery_credentialsですが、sys_db_objectでラベルを確認すると単に「Credentials」となっています。Discovery専用の置き場ではありません。全社共通の認証情報の置き場を、Discoveryも間借りしている構造だと分かります。公式のDiscovery Credentialsにも説明があります。CredentialsはDiscoveryだけでなく、Orchestrationなど複数の機能で共有される仕組みです。

実務では、認証情報の命名規則やOrder(優先順位)の設計時に、この「共有テーブルである」という前提を踏まえておく必要があります。Discovery用のSSH鍵やWindowsサービスアカウントを増やしていくと、通知連携やAPI認証の情報と同じ画面に混在していくからです。

MID Serverが無いと何が起きるのか

Discoveryが実際にスキャンを行うには、対象ネットワークに到達できるMID Serverが最低1台必要です。このPDIでMID Serverの登録状況を見ると次のとおりでした。

「No records to display」。ecc_agentテーブルの件数を数えても0件です。MID Serverは、PDIのようなクラウド上の検証環境から社内ネットワーク機器へSSHやWMIで到達することを前提にしたエージェントソフトウェアです。別途Windowsサーバなどにインストールして登録する必要があります。PDIには最初から用意されておらず、自分でセットアップしない限り0台のままです。公式のMID Serverにも、社内ネットワークとインスタンスをつなぐ常駐エージェントだと説明されています。

MID Serverが無い状態は、Probe定義(設計図)とECC Queue(MID Serverとの命令の受け渡し口)はあっても、その先で命令を受け取って実行する主体が存在しないことを意味します。ProbeもCredentialsも用意されているのに、実行できない状態がここで生まれています。

実行結果はどうなっているか(すべて0件)

最後に、実際のスキャン結果を格納するテーブル群を確認しました。

discovery_status(スキャンの実行単位)、discovery_queue(実行待ちのキュー)、discovery_result(Probeが持ち帰った生データ)のいずれも0件でした。ITOM Discovery Licenseが無効で、かつMID Serverも0台という状態なので、当然といえば当然の結果です。スキャン結果が蓄積されていれば、最終的にはcmdb_ci配下の各テーブルにCIとして反映されます(CMDBのテーブル構成)。今回はその手前で止まっています。

ここまでの確認結果を、Discoveryが本来動くときの流れに沿って1枚の図にまとめました。色は「このPDIで確認できたもの」と「確認できなかったもの」を分けています。

紺色のProbe定義(143件)が今回の主役です。緑色のDiscovery Range(1件)とCredentials(4件)も、存在は確認できました。赤色のMID Server(0件)とITOM Discovery License(Inactive)が欠けています。そのためECC Queueから先、実行結果とCMDBへのCI登録までは、灰色つまり今回は到達できなかった範囲としています。実行結果の画面は見せられませんでした。ですが「どこまでは定義され、どこから先が動かせなかったか」を正直に示すことには意味があると考え、この図にまとめました。

導入前に確認しておきたいこと(設計提案)

ここからは、実機で確認した事実そのものではありません。そこから導ける設計上の提案です。事実と分けて書きます。

MID Serverのネットワーク到達性を先に決める。Probe定義は最初から揃っていても、対象ネットワークにSSH/WMI/SNMPで到達できるMID Serverが無ければ何も始まりません。どのセグメントに何台配置するかは、Discoveryを有効化する前に決めておく設計項目です。
Credentialsは「Discovery専用テーブル」ではないと意識して設計する。前述のとおり全社共通の認証情報テーブルです。命名規則(対象環境・用途が分かる名前)とOrder(優先順位)を、他機能の認証情報と衝突しないように整理しておくと、後から見返したときに迷いません。
used_by_discoveryとused_by_runbookの重なりを踏まえる。Discoveryだけでなく、Runbook Automationでも同じProbeが呼ばれる設計です。片方の機能を無効化・カスタマイズするときは、もう片方への影響がないかを確認したほうが安全です。
プラグインの有効・無効は別途v_pluginで確認する。テーブルにレコードがあることと、機能がライセンス的に使える状態にあることは別問題です。導入検討時は、ITOM Discovery Licenseなど関連プラグインの状態を必ず個別に確認します。

実機を見て気づいたこと

一番驚いたのは、discovery_probesにactiveフィールドが存在しないことでした。事前情報では「143件はすべてactive=trueの状態で入っている」と聞いていました。しかし実際にsys_dictionaryでフィールド一覧を確認しても、activeという項目自体が見当たりません。active=trueで絞ってもactive=falseで絞っても同じ143件がヒットする挙動からも、それが裏付けられました。有効・無効という概念を持たず、143件は最初から「全部そこにある」状態で管理されています。有効/無効を切り替えて運用するテーブルだと思い込んでいたので、これは実機を開かないと分からなかった点です。

もう一つは、discovery_credentialsの中身です。テーブル名から「Discovery用の認証情報が並んでいる」とばかり思っていました。開いてみると、4件のうち3件がSlackやTeamsのOAuth連携用でした。ServiceNowのテーブル名は、必ずしも「そのテーブルが何に使われるか」を正確には表していません。当たり前のようで見落としがちな事実に、あらためて気づかされました。

そしてused_by_runbookの24件です。Discoveryという名前の機能の中に、Orchestration(Runbook Automation)用のProbeが混ざっている構造でした。機能単位でテーブルがきれいに分かれているわけではないと分かります。discovery_probesを触るときは注意が必要です。「これはDiscoveryだけの話か、Orchestrationにも影響するか」を、毎回used_by系のフラグで確認したほうがよさそうです。

自分の環境で確認するときのURL

先頭の<YourInstance>は自分のインスタンスに置き換えてください。

Probe一覧（クラス別グループ表示）: discovery_probes_list.do?sysparm_query=GROUPBYsys_class_name
Probeフォーム（例：Heartbeat）   : discovery_probes.do?sysparm_query=name=Heartbeat
Credentials一覧                  : discovery_credentials_list.do
MID Server一覧                   : ecc_agent_list.do
System Plugins（Discovery関連）  : v_plugin_list.do?sysparm_query=nameLIKEDiscovery
Discovery Status一覧              : discovery_status_list.do

用語

PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
Probe：調べに行く手段の定義。何をどの方法で取得するかを1件ずつ持つ
MID Server：社内ネットワークに置く中継サーバ。実際の調査はここが実行する

ServiceNowのCIはどのテーブルに入る？ cmdb_ciの102クラスを実機で確認 — Discoveryが最終的に書き込む先であるcmdb_ciのクラス構造を実機で確認できます。
ServiceNowのCMDBは何がどこに入っている？ CI・関係・サービスを実機で数える — CMDB全体の件数感をつかむ入口の記事です。
重複CIを防ぐ仕組み IRE（cmdb_identifier） — Discoveryが持ち帰ったデータが、実際にCIとして登録される際の同定ロジックを扱っています。

検証範囲とおことわり

確認した範囲：discovery_probesの件数（143件）とsys_class_name別内訳、used_by_discovery/used_by_runbookの集計、type/sys_package/sys_scopeの集計、Heartbeat Probeの全フィールド、discovery_credentialsの4件の内訳、ecc_agentの件数（0件）、discovery_status/discovery_queue/discovery_resultの件数（いずれも0件）、v_pluginでのITOM Discovery License / Data Discovery APIs / MID Serverの状態。すべてPDI（Zurich / 2026-08-09確認）のOOTBで、REST APIによる読み取り専用アクセスで取得しています。
確認していない範囲（断定しません）：実際にMID Serverを構築してDiscoveryスキャンを実行した際の挙動、discovery_status/discovery_queue/discovery_resultに実データが入った状態の画面、sys_packageテーブル本体のプロパティ（ACLにより403で参照不可）、discovery_range（1件）とdiscovery_classy（17件）の詳細設計、本番環境でのProbeカスタマイズ事例。これらは別記事で扱う可能性があります。

今回はPDIのOOTB（初期設定）を前提に、Discoveryの「調べ方の定義」であるProbeを中心に確認しました。実際にDiscoveryを運用する環境では、追加のProbeやCredentials、調整ルールなどが積み上がり、件数や構成は変わります。