ServiceNow Discoveryを学び始めると、Discovery・MID Server・CMDB・CSDMという言葉が次々に出てきて、どれがどの役割なのか曖昧なまま用語を覚えてしまいがちです。CIS-Discovery（Certified Implementation Specialist - Discovery）試験も、機能名を一つずつ暗記しているかではなく、「ネットワーク上の実機を、どうやって見つけ、どう識別し、CMDBとサービスモデルにどう載せるか」という一連の処理を、つながりとして理解しているかを問います。
この記事では、Discoveryを「実機からサービスモデルまでの一本のデータ動線」として最初から最後まで通して扱います。Discovery本体の処理フローを背骨に据え、その途中で必ず登場する MID Server を一段深く掘り下げ、最後に発見結果を CSDM へどう接続するかまでを一続きで整理します。仕上げに、その流れを自分の PDI（Personal Developer Instance）で確認するための手順を添えます。
Discovery・MID Server・CMDB・CSDMの役割を入口で分ける
最初に、混同しやすい4つの言葉を、データが流れていく順番で並べて役割を分けておきます。ここを曖昧にしたまま先へ進むと、後で出てくる Probe/Sensor や IRE の説明が、ただの暗記になってしまいます。
データは、ざっくり次の向きで流れます。「ネットワーク上の実機」から始まり、「実機を発見する仕組み（Discovery と MID Server）」を経て、「発見した構成情報をためる土台（CMDB）」に入り、「それをサービス視点で意味づけるモデル（CSDM）」へとつながります。
横にスクロールできます
| 層 | 何をする層か | 主な成果物 | 典型的な誤解 |
|---|---|---|---|
| Discovery | 対象環境を探索し、機器やアプリの構成情報を収集・更新する | 検出されたCIと属性、関係性 | CMDBとは別物だと考え、CI品質への影響を見落とす |
| MID Server | インスタンスから直接届かない社内ネットワークへ処理を中継・実行する | 探索結果（ECC Queue経由でインスタンスへ） | 入れれば全ネットワークを見られると思い込む |
| CMDB | CIと関係性を管理するデータ基盤 | CIレコードと関係(Relationship) | 単なる資産台帳として見て、サービス影響分析と切り離す |
| CSDM | 発見したCIをサービス・アプリケーションの文脈に整理する共通モデル | Application Service、Business Application等への整理 | Discoveryのスキャン機能の名前だと誤解する |
この表で大事なのは、4つが置き換え可能ではなく、役割分担で連なっているという点です。Discovery は情報を集める仕組み、CMDB はそれをためる土台、CSDM はその意味づけの設計、MID Server はその全体を社内ネットワークで成立させるための実行役です。CIS-Discovery では、この役割分担を前提に、各処理がどこでつまずき、どの画面やログを見て切り分けるかまで踏み込んで問われます。
学ぶ順番としては、まず Discovery 本体の処理フローを通しで押さえ、次にその途中で必須になる MID Server を掘り下げ、最後に発見結果を CMDB から CSDM へつなぐ、という順序が理解しやすいはずです。以降、この順で見ていきます。
ServiceNowの製品やUIは世代によって細部の見え方が変わります。お手元の PDI の画面と照らし合わせながら読み進めてください。
Discovery本体：実機の発見が成立する仕組み
まず背骨である Discovery 本体です。Discovery は、対象ネットワーク上の物理・仮想の機器やアプリケーションを探索し、構成情報を CI として CMDB に反映する仕組みです。ここでは「探索が始まってから CMDB に CI が載るまで」を、処理の順番で追っていきます。
Discovery Schedule：どこを、いつ探索するか
Discovery の出発点は Discovery Schedule です。これは「どの範囲を、いつ、どのMID Serverで探索するか」を決める設定で、主に次の要素を持ちます。
- 探索対象を表す IP アドレスの範囲（IP Range / ネットワークの指定）
- 実行のタイミング（手動実行、定期実行など）
- どの MID Server を使うか、あるいは自動選択させるか
ここで指定した範囲が、その後の探索の入口になります。範囲を取り違えると、そもそも目的の機器が探索対象に入らず、いくらMID Serverや資格情報が正しくても結果が出ません。範囲指定は探索の前提条件だと押さえてください。
探索フェーズ：Shazzam → Classify → Identify → Explore
Discovery の中心は、4つのフェーズが順番に進む処理です。それぞれが前のフェーズの結果を受けて動くため、どこで止まったかを切り分けられるよう、順番で理解しておきます。
- Shazzam（ポートスキャン）：指定範囲のIPアドレスに対して、どのIPが応答するか、どのポートが開いているかを調べます。これは MID Server 上で実行され、生きているデバイスとおおまかな種類の当たりをつける段階です。
- Classify（分類）：開いているポートや応答から、対象が何であるか（Windows、Linux/UNIX、ネットワーク機器、ストレージなど）の種類を判定します。ここで「どの種類として扱うか」が決まり、次のフェーズで使う処理が分岐します。
- Identify（識別）：対象にログインして情報を取得し、その機器が CMDB 上の既存 CI と同一か、新規かを判断します。ここで後述する IRE（Identification and Reconciliation Engine）が働き、重複 CI を作らずに正しく更新できるかが決まります。
- Explore（探索）：識別が済んだ対象から、さらに詳しい属性や関係性（インストールされたソフトウェア、稼働プロセス、依存関係など）を収集します。集めた結果が CMDB の CI と Relationship に反映されます。
この4段は「生きているIPを見つける → 種類を見分ける → 同一性を判断する → 詳細を集める」という流れだと捉えると、暗記ではなく筋として残ります。たとえば「ポートは開いているのに種類が判定されない」なら Classify 付近、「情報は取れているのに重複CIができる」なら Identify と IRE 付近、というように、症状からフェーズを当てられるようになるのが目標です。
Probe/Sensor と Pattern：情報を取りに行く部品
各フェーズで実際に情報を取りに行く部品が Probe/Sensor と Pattern です。
- Probe（プローブ）：対象に対して「この情報を取ってきて」と指示を出す部品。MID Server を通じて対象へ送られます。
- Sensor（センサー）：Probe が取得した結果を受け取り、CMDB に反映できる形へ処理する部品。
- Pattern（パターン）：近年の Discovery で中心的に使われる、宣言的に探索手順を定義する仕組み。どの属性をどう取得・整形するかを定義し、Probe/Sensor 方式に比べて保守しやすいのが特徴です。
実務でも試験でも、Probe/Sensor の役割の違い（取りに行く側と受け取って処理する側）と、Pattern が探索ロジックを担う中心であることを押さえておくと、探索が想定どおり動かないときに「取得の段階か、整形・反映の段階か」を切り分けやすくなります。
IRE：重複CIを作らないための識別と突き合わせ
Discovery の品質を左右するのが IRE（Identification and Reconciliation Engine）です。IRE は、検出された情報を CMDB の既存 CI と突き合わせ、同一なら更新、新規なら作成、という判断を担う共通の仕組みです。役割は大きく2つに分かれます。
- Identification（識別）：Identification Rule に基づき、検出されたデータが既存のどの CI に当たるか、あるいは新規かを判断する。
- Reconciliation（突き合わせ・調整）：複数の情報源（Discovery、Service Mapping、インポートなど）が同じ CI を更新するとき、どの情報源の値を正とするかを調整し、データの上書き競合を防ぐ。
Identification Rule の決め手は段階的に評価される
識別でまず理解しておきたいのは、CI の同一性を「名前」ではなく、識別ルールで定めた決め手で判断するという考え方です。Identification Rule は CI Class（あるいはその上位の共通クラス）ごとに定義され、その中に複数の Identifier Entry（識別の手がかり）が優先順位を持って並びます。検出データが来ると、上位の手がかりから順に「この属性で既存 CI に一致するものはあるか」を評価し、決まった時点でその CI を同一とみなします。
手がかりには、強いものと弱いものがあります。シリアル番号のように機器に固有でぶれにくい属性は決め手として強く、IPアドレスやホスト名のように、付け替えや重複・表記ゆれが起こりうる属性は相対的に弱い手がかりです。だからこそ、強い決め手を上位に、弱い決め手を補助として下位に置く設計が効いてきます。名前だけで突き合わせると、表記ゆれ（全角半角・余分なスペースなど）や同名の機器で別 CI を取り違え、結果として重複 CI が生まれます。
識別の手がかりには、対象そのものを直接特定する独立した手がかりと、「親となる CI が分かって初めて意味を持つ」従属的な手がかりがあります。たとえばディスクやネットワークカードのような部品は、それ単体では一意に決まりにくく、「どのサーバに載っているか」という親との関係を前提に識別されます。Discovery が想定どおりに動いていても、親 CI の識別が先に失敗すると、ぶら下がる部品側の識別も連鎖して崩れることがある、という点は押さえておくと切り分けに役立ちます。
Reconciliation とデータソース優先度：誰の値を正とするか
CMDB は Discovery だけが書き込むとは限りません。Service Mapping、各種インポート、手入力など、複数の情報源が同じ CI の同じ属性を更新しに来ることがあります。このとき、後から来た値で無条件に上書きすると、信頼できる情報源の値が、精度の低い情報源の値で塗り替えられてしまいます。これを防ぐのが Reconciliation（突き合わせ・調整）で、属性ごとに「どの情報源を正とするか」という優先度の考え方に基づいて、上書きの可否を判断します。
実務では、ある属性について「この値は Discovery を正とする」「この値は資産管理側のインポートを正とする」といった整理を、情報源の信頼度に応じて設計します。優先度の考え方が整っていないと、Discovery が正しく検出した値が別の経路の古い値で上書きされ、CMDB の鮮度がかえって落ちる、という事態が起こりえます。「検出は成功しているのに、CMDB 上の値が想定と違う」という症状のとき、探索側だけでなく、どの情報源の値が採用されているか（上書き競合が起きていないか）まで見る必要があるのは、このためです。
重複が出てしまったときの運用
それでも、識別の設計が対象の実態に合っていなかったり、過去に名前ベースで作られた CI が残っていたりすると、重複 CI は発生します。重複は、後段の Incident や Change の影響分析を不正確にする直接の原因になります。同じ実機が2つの CI として見えていると、どちらに障害や変更を紐づけるべきかが定まらず、影響範囲の判断がぶれるためです。
運用としては、重複を「その都度手で消す」のではなく、まず識別ルールの決め手が対象の実態に合っているかを見直し、再発の元を断つのが筋です。そのうえで、すでに生まれた重複は、ServiceNow が備える CMDB の重複対応の仕組み（重複の検出と、正とする CI へ寄せる集約）を使って整理します。CMDB の値の正しさは、こうした識別・突き合わせの設計と、重複が出たときの運用の両輪に支えられている、と理解してください。
ここまでが Discovery 本体です。次は、この処理を社内ネットワークで成立させるために欠かせない MID Server を、一段深く掘り下げます。
深掘り：MID Serverはなぜ要るのか、どこでつまずくか
Discovery のフェーズは、対象機器に「到達できて」「ログインできて」初めて成立します。その到達を担うのが MID Server です。ここは独立した深掘りとして、役割・構成・つまずきどころを整理します。
MID Serverの役割：ファイアウォール内へ届く実行エージェント
MID Server（Management, Instrumentation, and Discovery Server）は、ServiceNow インスタンスと社内ネットワーク上の対象機器の間に立つ中継コンポーネントです。社内に設置した小さな実行エージェントだと考えると分かりやすいでしょう。
なぜこれが必要かというと、ServiceNow インスタンスはクラウド側にあり、企業のファイアウォールの内側にある機器へ直接ログインして探索することができないためです。MID Server は社内ネットワーク内に置かれ、インスタンスとはアウトバウンド通信（社内から外向きの接続）で連携します。インスタンス側から社内へ穴を開けるのではなく、MID Server 側から取りに行き、結果を返す——この向きが、ファイアウォール内の機器を安全に探索できる理由です。
つまり、Shazzam のポートスキャンも、Identify のログインも、Explore の属性収集も、実際の処理は MID Server 上で動きます。MID Server は Discovery の手足にあたる存在です。
設置・資格情報・負荷と可用性
MID Server を実用に乗せるには、設置と設定でいくつかの観点が必要です。
- 配置（どこに置くか）：探索したい対象ネットワークに到達できる場所に置きます。複数のネットワークセグメントがファイアウォールで分かれている場合、片方からもう片方へ届かないことがあるため、対象に届く位置取りが前提になります。
- 登録と有効化（Validation / Status）：インストール後、インスタンスに登録され、有効に使える状態（Validated / Up）になって初めて Discovery で使えます。インストールしただけで使えるわけではない点に注意します。
- 資格情報（Credential）：対象にログインするための認証情報を設定します。Windows、Linux/UNIX、ネットワーク機器、クラウドなどで必要な種類やプロトコルが異なり、対象ごとに合った資格情報と十分な権限が要ります。
- Capability と選択条件：どの MID Server がどの探索に使われるかは、Capability、対象IPの範囲、アプリケーション、クラスタ構成などの条件で決まります。
- 負荷分散と可用性（Cluster）：探索量が多い、あるいは止められない環境では、複数の MID Server をクラスタとしてまとめ、負荷を分散したり片方が落ちても継続できるようにしたりします。
これらは「入れて終わり」ではなく、対象に届く位置・有効な状態・正しい資格情報・適切な選択と冗長性、という連なりで考える必要があります。
よくある失敗：到達不能と権限不足を切り分ける
MID Server がからむ失敗で多いのが、「到達できない」のか「ログインできない」のかを切り分けずに、Discovery 全体が壊れていると判断してしまうケースです。次のように観点を分けて切り分けます。
横にスクロールできます
| つまずき | 主に確認する観点 | よくある原因 |
|---|---|---|
| MID Serverが使えない | Status / Validated の状態 | 登録後に有効化（Validation）が済んでいない |
| 対象に到達できない | ネットワーク到達性、ポート、名前解決 | ファイアウォール、プロキシ、ルーティング、範囲指定の誤り |
| 対象にログインできない | 資格情報と権限 | 資格情報の誤り、権限不足、対象OS/プロトコルの不一致 |
| 処理が進んでいるか不明 | ECC Queue の入出力 | 処理がどこで滞留しているかを見ていない |
ここで切り分けの要になるのが ECC Queue（External Communication Channel Queue）です。ECC Queue は、インスタンスと MID Server の間でやり取りされる指示（Output）と結果（Input）が並ぶ場所で、処理がどの段階で詰まっているかを確認する入口になります。「到達不能」と「権限不足」は症状が似て見えますが、前者はネットワークの問題、後者は資格情報の問題で、対処がまったく異なります。まず ECC Queue と MID Server のログで、どこまで進んでどこで止まったかを見るのが切り分けの起点です。
MID Server が安定して対象に届き、ログインでき、結果を返せるようになって、ようやく前章の Discovery フェーズが成立します。次は、こうして集めた CI を CMDB から CSDM へどうつなぐかに進みます。
深掘り：Discovery結果をCSDMにどう接続するか
Discovery と MID Server で集めた CI は、CMDB に載っただけでは「機器の一覧」にとどまります。それを Incident や Change の影響分析に使える「サービスの地図」にするのが CSDM の役割です。ここでは CSDM 全般の解説ではなく、あくまで「Discovery の結果を CSDM にどう接続するか」に絞って掘り下げます。CSDM そのものの全体像は、関連記事のCSAのCMDB/CSDM基礎に譲ります。
CSDMは「発見結果の意味づけ」を担うモデル
CSDM（Common Service Data Model）は、CMDB 上の CI を、サービスやアプリケーションの文脈で一貫して整理するための共通モデル（設計の枠組み）です。ここで押さえるべきは、CSDM は Discovery のように対象をスキャンする機能ではない、という点です。Discovery が「実機から CI を作る仕組み」だとすれば、CSDM は「その CI をサービス視点で意味づける設計」です。両者は対立せず、Discovery が集めた素材を CSDM の枠に整理して初めて、サービス単位での可視化や影響分析ができるようになります。
発見したCIをサービスモデルへ載せる
Discovery が作るのは、多くの場合サーバ、ネットワーク機器、インストール済みソフトウェアといった技術的な CI です。これらを、人が業務で認識する単位へ結びつけていきます。CSDM で特に混同しやすいのが、粒度の違う次の2つです。
- Application Service：実際に稼働しているサービスの単位。どのサーバ上で、どのコンポーネントが、どう依存し合って動いているか、という技術的な構成や関係性を持ちやすい層です。Discovery や Service Mapping の結果は、まずこの Application Service として構成・関係づけされることが多くなります。
- Business Application：業務側から見たアプリケーションの単位。「経費精算システム」のように、業務上ひとまとまりとして扱う、より上位の概念です。
この2つは粒度が違うのに同じものとして扱われがちで、試験でも実務でも取り違えの起きやすいところです。おおまかには、Discovery が集めた技術的な CI を Application Service として組み立て、それを業務単位の Business Application に結びつけていく、という方向で整理するとつながりが見えます。
Application Service の境界をどこで引くか
Discovery 結果を CSDM に載せるとき、実務で最初に悩むのが「Application Service の境界をどこで引くか」です。Discovery は、ネットワーク上に存在するサーバやプロセスを技術的な事実として淡々と集めます。しかしどこからどこまでを「一つの稼働サービス」とまとめるかは、技術的な事実だけでは決まらず、業務上の意味づけが要ります。境界の引き方には、大きく次の2つの考え方があります。
- 手がかりから自動で組み立てる：Service Mapping のように、ある入口（たとえば対外的に見えるエンドポイント）を起点に、通信や依存をたどって関係する CI を機械的にまとめていくやり方。実態に追従しやすい反面、たどった範囲が業務上のまとまりと一致するとは限らず、不要な依存まで取り込んだり、逆に取りこぼしたりすることがあります。
- 業務の単位から定義する：「この業務サービスは、これらのサーバとコンポーネントで構成される」と、人が定義してから CI を割り当てるやり方。業務上のまとまりとは一致しやすい反面、構成変更への追従を運用で支える必要があります。
どちらを採るにせよ、境界が広すぎると、無関係な変更まで「このサービスに影響あり」と出て影響分析がノイズだらけになり、狭すぎると、本来巻き込まれるはずの依存が抜けて影響を見落とします。Discovery が集めた素材を CSDM に載せる作業は、この境界を業務の実態に合わせて引き直し続ける運用とセットだ、と捉えておくと、「とりあえず全部つなぐ」式の失敗を避けられます。
接続が成立するための前提：CI品質とRelationship
Discovery の結果を CSDM に載せる作業は、土台となる CI の品質が低いと成立しません。具体的には、次の2つが前提になります。
- 重複のない正しい CI：前章の IRE が効いていて、同じ実機が複数の CI として登録されていないこと。重複があると、どの CI をサービスに紐づけるべきかが定まらず、サービスモデルが信用できなくなります。
- 関係性（Relationship）が作られていること：CI の属性だけでなく、CI 同士の依存関係（Depends on / Used by のような関係）が作られていること。サービスの影響分析は、この関係性をたどって行われるためです。
Relationship の「品質」とは何か
関係性は、ただ存在すればよいわけではありません。影響分析に使える Relationship かどうかは、向きと意味が実態に合っているかで決まります。Depends on / Used by のような関係には向きがあり、たとえばアプリケーションがデータベースに依存しているとき、依存の向きを取り違えると、データベースの停止がアプリ側へ波及する、という影響の伝わり方が逆に表現されてしまいます。向きが誤った関係性は、影響分析を「正しそうに見えて実は逆」にしてしまうため、欠けているよりたちが悪いことがあります。
Discovery が作る関係性は、対象から取得できた事実に基づくため、探索が届いていない範囲や、Pattern で取得していない依存は、そもそも関係として表れません。「画面上はサービスが見えているのに、ある依存だけ影響分析に出てこない」というとき、関係性が誤っているのか、そもそも作られていないのかを切り分ける必要があります。前者は識別・突き合わせや関係の生成ロジック、後者は探索範囲や Pattern の取得対象、と見るべき場所が変わります。
再分類の運用：CI Class はずれることがある
もう一つ運用で効いてくるのが再分類です。Classify フェーズで判定される CI Class は、常に最終的に正しいとは限りません。対象のバージョン差や応答の違いで、本来より上位の汎用クラスにとどまったり、別のクラスとして分類されたりすることがあります。CI Class がずれると、その CI に適用される識別ルールや、サービスへの組み込まれ方も変わるため、CSDM 上での扱いまで影響します。
実務では、分類の精度を継続的に見直し、誤って分類された CI を正しいクラスへ寄せていく再分類を運用に組み込みます。これは一度きりの設定ではなく、対象環境の変化や Pattern の更新に合わせて続く作業です。「Discovery を一度回したら CMDB と CSDM は完成する」と捉えると、分類のずれや関係性の欠けが放置され、時間とともに影響分析の精度が落ちていきます。
逆に言えば、CSDM に正しく載っているかどうかは、Discovery と IRE がどれだけ正確に CI・分類・関係性を作れているかに直結します。CSDM 側だけを整えても、土台の CI が重複していたり、分類がずれていたり、関係性が欠け・誤っていたりすれば、Incident の影響範囲や Change の影響評価は不正確になります。Discovery → CMDB → CSDM は、別々の作業ではなく一続きの品質の連鎖だと捉えてください。
Discovery・MID Server・CMDB・CSDMの早見表
ここまでの4つの役割を、一望できる形でまとめ直します。設問や障害切り分けで迷ったとき、「いま自分はどの層の話をしているのか」を確認する起点にしてください。
横にスクロールできます
| 観点 | Discovery | MID Server | CMDB | CSDM |
|---|---|---|---|---|
| 何をする層か | 実機を探索しCIを収集・更新する | 社内ネットワークで探索を中継・実行する | CIと関係性を管理する土台 | CIをサービス視点で整理する設計 |
| 主な成果物 | 検出CI・属性・関係性 | 探索結果（ECC Queue経由） | CIレコードとRelationship | Application Service / Business Application等 |
| 主な構成要素 | Schedule、4フェーズ、Probe/Sensor、Pattern、IRE | 配置、Validation、Credential、Capability、ECC Queue | CI Class、Relationship、IRE | 粒度の異なるサービス/アプリケーションの層 |
| 典型的な誤解 | CMDBと別物でCI品質に無関係だと考える | 入れれば全ネットワークを見られると思う | 資産台帳としてだけ見る | Discoveryのスキャン機能の名前だと誤解する |
表で並べると、4つが「探索する／中継する／ためる／意味づける」と役割で分かれているのが見えます。CIS-Discovery の設問は、この役割分担の上で「どの層のどの部品の話か」を見分けさせるものが中心です。
PDIで処理の流れを確認する手順
ここまでの動線は、読むだけでなく、自分の PDI（Personal Developer Instance）で一度なぞると定着が早くなります。PDI は無料で取得できる学習・検証用のインスタンスです。以下の順で、設定から CMDB 反映までを通して確認してください。なお、PDI の標準構成では実際のネットワーク探索を行えない場合があるため、ここでは「どの画面で何を確認するか」を中心に進めます。
手順1：Discovery Schedule の設定項目を確認する Discovery Schedule のレコードを開き、IP Range（探索範囲）、実行タイミング、使用する MID Server の指定がどこにあるかを確認します。範囲と MID Server がどう結びつくかを把握します。
手順2：MID Server の状態と資格情報を確認する MID Server のレコードで、Status / Validated、Capabilities、関連付けられた Application を確認します。続いて Credential（資格情報）の一覧を開き、Windows・Linux・ネットワーク機器などで種類やプロトコルがどう分かれているかを見ておきます。
手順3：ECC Queue で処理の入口と出口を見る ECC Queue を開き、Input と Output のレコードがどう並ぶかを確認します。処理が滞留したときに、どこを見れば「どこで止まったか」が分かるのかを、画面の位置として覚えます。
手順4：CI の Class・属性・Relationship をたどる CMDB から任意の CI を開き、CI Class、Name、シリアル番号などの識別に使われる属性、そして Relationship（依存関係）を確認します。CI が単独の属性だけでなく、関係性を持って他の CI とつながっていることを意識します。
手順5：CMDB から CSDM の粒度を見比べる サーバなどの技術的な CI と、Application Service、Business Application の粒度を見比べます。同じシステムでも、技術側の単位と業務側の単位で見え方が変わることを確認し、Discovery の結果がどの層に載るのかを整理します。
この一周をなぞっておくと、CIS-Discovery の設問が「設定の話なのか、到達性の話なのか、識別の話なのか、サービスモデルの話なのか」を、画面の位置と結びつけて判断できるようになります。
まとめ
Discovery は、それ単体の機能名というより、「実機を発見し、CMDB に正しく載せ、サービスモデルにつなぐ」までの一連の動線として理解するのが近道です。要点を動線の順に並べると、次のようになります。
- 出発点は Discovery Schedule で、どの範囲をいつ、どの MID Server で探索するかを決める。
- 探索は Shazzam → Classify → Identify → Explore の順で進み、Probe/Sensor と Pattern が実際の取得・整形を担う。
- 同一性の判断と重複防止は IRE が担い、名前ではなく識別ルールの決め手で CI を突き合わせる。
- MID Server は、ファイアウォール内の対象へ届くアウトバウンドの実行エージェントで、到達不能と権限不足の切り分けが障害対応の起点になる。
- CMDB に載った CI は、IRE による品質と Relationship を前提に CSDM へ接続され、Application Service と Business Application の粒度で整理されて影響分析に使える形になる。
この一本の流れが頭に入っていれば、個々の用語は「動線のどこにある部品か」で位置づけられます。次の一歩として、全体像はCIS資格対策ハブとCIS-Discoveryハブで確認し、CMDB と CI/Asset の区別が曖昧ならCMDBとCI・Assetの違いもあわせて確認すると、Discovery の前提が固まります。
よくある質問
Q1. Discovery、MID Server、CMDB、CSDM の関係をひと言で整理するとどうなりますか。 Discovery が実機を探索して情報を集め、その探索を MID Server が社内ネットワークで中継・実行します。集まった情報は CMDB に CI として管理され、CSDM はその CI をサービス視点で意味づける設計の枠組みです。「探索する・中継する・ためる・意味づける」という役割分担で覚えると、置き換え可能なものではないと整理できます。
Q2. MID Server はなぜ必要なのですか。インスタンスから直接探索できないのですか。 ServiceNow インスタンスはクラウド側にあり、企業のファイアウォールの内側にある機器へ直接ログインして探索することができません。MID Server を社内ネットワーク内に置き、社内から外向きのアウトバウンド通信でインスタンスと連携することで、ファイアウォール内の対象を探索し、結果を返せるようになります。Shazzam・Identify・Explore の実処理は MID Server 上で動きます。
Q3. Discovery がうまく動かないとき、どこから切り分ければよいですか。 まず「到達できないのか」「ログインできないのか」「処理が詰まっているのか」を分けます。MID Server の Status（有効か）、対象へのネットワーク到達性、資格情報と権限、そして ECC Queue の入出力を順に確認します。到達不能はネットワークの問題、権限不足は資格情報の問題で対処が異なるため、症状が似ていても混同しないことが切り分けの起点です。
Q4. 重複 CI はなぜ問題になり、どう防ぐのですか。 重複 CI があると、Incident や Change の影響分析で「どの CI が本当の対象か」が定まらず、影響範囲の判断が不正確になります。防ぐ鍵は IRE による識別と突き合わせで、CI の同一性を名前ではなく識別ルールの決め手（シリアル番号やIPなど一意になりやすい属性）で判断することです。名前で突き合わせると表記ゆれや同名機器で取り違えが起き、重複の原因になります。
Q5. CSDM は Discovery の機能の一つなのですか。 いいえ。CSDM は対象をスキャンする機能ではなく、CMDB 上の CI をサービスやアプリケーションの文脈で整理するための共通モデル（設計の枠組み）です。Discovery が集めた CI を素材として、Application Service や Business Application といった粒度で意味づけていくものだと捉えてください。Discovery の結果が正しく載るかどうかは、IRE による CI 品質と Relationship に支えられています。
Q6. この記事は CIS-Discovery 試験対策に役立ちますか。 役立ちます。用語を一つずつ暗記するのではなく、「実機の発見 → CMDB 反映 → CSDM への接続」という動線と、その各段での判断（範囲指定、フェーズの切り分け、識別と突き合わせ、到達性と権限の切り分け、サービスモデルの粒度）を整理しているためです。CIS-Discovery はこの役割分担と切り分けを問う設問が中心です。読了後は、ハブ記事で全体像を確認し、模擬問題と往復して弱点を見つけると定着が早まります。
