重複CIを防ぐ仕組み IRE（cmdb_identifier）

2026年6月21日 22:26

前回の記事では、CMDB の中心テーブル cmdb_ci のクラス階層・状態・CI関連を見ました。今回はその続編です。「同じサーバが二重に登録されないのはなぜか」「複数のデータソースが同じ CI を更新したとき、何が起きるのか」。CMDB を運用するうえで避けて通れない仕組みを扱います。

その答えが IRE（Identification and Reconciliation Engine＝同定・調整エンジン） です。Discovery や外部連携で次々に流れ込むデータを、IRE が「既存の CI か／新規か」を判定し（同定）、「どのデータソースがどの属性を上書きできるか」を制御します（調整）。

この記事では、IRE をプロセス論だけで説明しません。実際の cmdb_identifier（CI Identifier）／ cmdb_identifier_entry（Identifier Entry）／ cmdb_reconciliation_definition（Reconciliation Definition）／ sys_object_source（Source）を PDI（Zurich）で開きます。同定ルールが優先順位つきの属性照合でできていること、その正準例である「Hardware Rule」が 9 件の entry を持つことを実機で確認します。

この記事は、ServiceNow の Incident は触ったことがあり、前回の cmdb_ci の記事で CMDB のテーブル構造をつかんだ人を想定しています。管理者・開発者が「重複 CI が増える／意図しない上書きが起きる」を調べるとき、まずどのテーブルを見るべきかを示します。

この記事で分かること

IRE（同定・調整エンジン）が「重複CI防止」と「上書き制御」を担うこと
同定ルールは cmdb_identifier（本体）＋ cmdb_identifier_entry（優先順位つき明細）でできていること
正準例 Hardware Rule が serial_number → name → mac_address … と 9 段の優先順位で照合すること
independent（独立 identifier）が何を意味するか
調整（reconciliation）とデータソース（sys_object_source / discovery_source）の役割
実機で確認するときに見るべき一覧URL

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、ルールの件数・内容・データソースの分布が異なる場合があります。

IRE（同定・調整エンジン）とは

IRE（Identification and Reconciliation Engine）は、CMDB にデータが流れ込むときの共通の入口です。「同じ CI か」を判定し（同定）、「どのソースが上書きできるか」を制御します（調整）。Discovery、Service Graph Connector（3rdパーティ連携）、IntegrationHub ETL（取り込み）など、IRE を経由する経路はすべてこの仕組みを通ります。

IRE がなければ、Discovery が走るたびに同じサーバが別の CI として登録され、CMDB はすぐに重複だらけになります。IRE は、入ってくるデータを既存 CI と突き合わせます。一致すれば更新、一致しなければ新規作成。この判定が重複 CI を防いでいます。

大きな流れはこうです。①同定（Identification）で既存 CI を探す。②見つかれば更新、なければ新規作成する。③調整（Reconciliation）で「その属性をこのソースが上書きしてよいか」を確認してから cmdb_ci に書き込む。今回はこの①と③に関わるテーブルを実機で確認します。

公式の CMDB Identification and Reconciliation（IRE）（Zurich）に、IRE が複数のデータソースからのデータを一元的に同定・調整する仕組みとして説明されています。

IRE を構成する主なテーブル

IRE は単一のテーブルではなく、役割の違う複数のテーブルの組み合わせで動きます。今回確認した PDI（Zurich / OOTB）での件数は次のとおりです。

ポイントは2つです。第一に、同定ルール（cmdb_identifier）は 409 件あります。これは「CIクラスごとに 1 ルール」という設計を反映しています。Hardware には Hardware Rule、AWS Account には AWS Account Rule、という具合に、対象クラスごとに同定ルールが用意されています。第二に、調整ルール（cmdb_reconciliation_definition）とデータソース記録（sys_object_source）は、今回の PDI では 0 件でした。重複防止（同定）は OOTB で広く定義済みです。一方、属性ごとの上書き制御（調整）や実際のソース履歴は、Discovery 等を動かして初めて意味を持ちます（このPDIでは Discovery の蓄積がないため 0 件）。

なお cmdb_identifier / cmdb_reconciliation_definition はいずれも Application File（メタデータ系）を継承するルール定義テーブルです。CI の実データ（cmdb_ci）とは別の場所に、ルールとして保存されている点を押さえておくと混乱しません。

同定ルールの構造（cmdb_identifier ＋ identifier entry）

同定ルールは、1つの本体（cmdb_identifier）に、複数の明細（cmdb_identifier_entry）がぶら下がる構造です。

本体（cmdb_identifier）は、対象にする CI クラス（applies_to）と、単独で同定できる独立ルールか（independent）を持ちます。明細（cmdb_identifier_entry）は、照合に使う属性の組み合わせ（attributes）、照合先のテーブル（table）、評価の優先順位（order）を持ちます。

各テーブルの主なフィールドは次のとおりです。ラベルは画面上の表示名で、実機どおり記載します。

今回確認した PDI（Zurich / OOTB）では、cmdb_identifier は 409 件、cmdb_identifier_entry は 471 件でした。うち active は 460 件です。1つの identifier が複数の entry を持つため、entry の総数が identifier より多くなります。

主な固有フィールド

cmdb_identifier の固有フィールドは、name（ルール名）・applies_to（対象CIクラス）・independent（単独で同定できるか）です。ほかに description・active も持っています。cmdb_identifier_entry は、identifier（→cmdb_identifier）・order（優先順位）を持ちます。加えて table（照合先テーブル）・attributes（照合する属性の組み合わせ）も基本項目です。さらに main_table・main_attributes・condition（絞り込み条件）も持ちます。allow_null_attribute・allow_fallback・exact_count_match・active という細かい制御項目もあります。

CI Identifier の一覧は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/cmdb_identifier_list.do

公式の Identification rules（Zurich）に、1つの同定ルールが「1つの CI identifier ＋ 1つ以上の identifier entry」で構成されることが説明されています。

正準例：Hardware Rule の優先順位（entry 9件）

抽象的な説明だけでは分かりにくいので、最も代表的な Hardware Rule を実機で開きます。これは Hardware（cmdb_ci_hardware）を対象にした同定ルールで、サーバ・コンピュータなど多くの CI の同定に関わります。

このフォームでは、Name=Hardware Rule、Applies to=Hardware、Independent にチェックが入っています。そして下部の関連リストに「Identifier Entries (9)」、その隣に「Related Entries (3)」のタブがあります。同定が、本体だけでなく複数の entry の集合で成り立っていることが一目で分かります。

その 9 件の entry を優先順位（order）順に並べたのが次の画面です。

evidence と一致する形で表にすると、次のようになります。

ここから読み取れるのは、「強い識別子から順に試す」という設計です。order 100 の serial_number（シリアル番号）は最も信頼できる識別子なので、最優先で照合します。見つからなければ name、さらに mac_address、最後に ip_address と、順に弱い識別子へ降りていきます。

entry 9件の内訳（order順）

order は 90=product_instance_id、100=serial_number・serial_number_type（cmdb_serial_number 参照）と続きます。200=serial_number、300=name も order の一部です。後半の order は 400=mac_address・name（cmdb_ci_network_adapter 参照）、500=ip_address・mac_address と続きます。600=mac_address、700=ip_address、800=mac_address（cmdb_ci_network_adapter 参照）が最後です。番号が小さいほど優先度が高く、途中から cmdb_serial_number や cmdb_ci_network_adapter という関連テーブルも参照している点が特徴です。

この設計では、一致した時点で照合を打ち切ります。order 100 の serial_number で既存 CI が見つかれば、その CI を更新し、残りの entry（name 以下）は評価しません。すべての entry を試しても一致しなかったときだけ、新規 CI を作成します。この「上から順に試して、最初に当たったところで確定する」動きが、重複 CI を防いでいます。

公式の Create a CI identification rule（Zurich）に、entry を priority 順に評価し、一致したら以降を評価しない、という挙動が説明されています。

independent（独立 identifier）とは

cmdb_identifier には independent（独立） というフラグがあります。今回の PDI では、independent=true が 157 件、independent=false が 252 件でした。

independent=true は「そのルール単独で CI を一意に同定できる」ことを表します。Hardware Rule も independent=true で、シリアル番号などの自前の属性だけで CI を特定できます。

一方 independent=false は「単独では同定できず、親や上位の構成に依存して初めて同定できる」ことを表します。たとえばディスクパーティションやリスナーのように、「どのホストに属しているか」が決まらないと一意にならない CI がこれにあたります。independent=false が 252 件と多数を占めます。CMDB の多くの CI が「単独のモノ」ではなく「何かに従属する構成要素」だからだと読めます（このPDIで確認した範囲での内訳です）。

independent の絞り込みは、次のURLで確認できます。

https://<YourInstance>/cmdb_identifier_list.do?sysparm_query=independent=true

調整（Reconciliation）とデータソース

同定が「同じ CI か」を決める仕組みなら、調整（Reconciliation）は「どのデータソースがどの属性を上書きしてよいか」を決める仕組みです。

調整ルール（cmdb_reconciliation_definition）は、applies_to（対象クラス）と attributes（対象属性）を持ちます。加えて discovery_source（Data source）と priority（優先度）です。たとえば「OS のバージョンは Discovery のデータを正とし、Import では上書きさせない」といった制御ができます。

ただし注意したいのは、今回の PDI（OOTB）では cmdb_reconciliation_definition が 0 件だったことです。調整ルールが1件もない状態では、特定ソース優先の制御は効かず、基本的に「後から書いたソースの値が反映される」デフォルト動作になります。調整ルールは、複数のデータソースが同じ属性を奪い合う場面で初めて必要になります。だから OOTB では定義されていないと読めます。

データソースそのものの記録は sys_object_source（Source） が担います。target_table / target_sys_id（どの CI か）・name（ソース名）・last_scan（最終スキャン）などを持ちます。ただしこのPDIでは sys_object_source も 0 件で、Discovery 等の同期履歴が蓄積されていませんでした（＝ここは検証範囲外の挙動です）。

代わりに、CI 自身の由来は cmdb_ci.discovery_source フィールドで確認できます。今回の PDI で discovery_source が入っている CI は 50 件でした。確認できた範囲では、値はすべて "Other Automated" です。discovery_source の選択肢自体は、ServiceNow / ImportSet / Manual via IRE など 20 種が定義されています。

discovery_source の選択肢一覧（20種）

前半5種は、ServiceNow／PatternDesigner／AgentClientCollector／MS SMS／ServiceWatch です。続く5種には、ManualStagingTable／Manual Entry／ACC-Visibility／LANDesk／Manual via IRE が並びます。次の5種は、ImportSet／CredentiallessDiscovery／OpenView／SNAssetManagement／Other Automated です。最後の5種には、EventManagement／Cloud Insights Billing／Tivoli／Health Log Analytics／Altiris が入ります。今回の PDI で実際に値が入っていたのは Other Automated のみでした。

https://<YourInstance>/cmdb_ci_list.do?sysparm_query=discovery_sourceISNOTEMPTY

ServiceNow における IRE のポイント

IRE は「同定（重複防止）」と「調整（上書き制御）」の2段構えです。Discovery / Service Graph / Import など IRE を通る経路はすべてこの判定を受けます。
同定ルールは cmdb_identifier（本体・409件）＋ cmdb_identifier_entry（明細・471件）で構成され、CIクラスごとに 1 ルールが基本です。
entry は order（優先順位）順に評価され、一致した時点で打ち切ります。全 entry が不一致のときだけ新規 CI を作成します。これが重複防止の仕組みです。
正準例 Hardware Rule は entry 9件です。serial_number（order 100）→ name → mac_address → ip_address と、強い識別子から弱い識別子へ降りていきます。
independent=true（157件）は単独で同定できるルール、false（252件）は親に依存するルールです。
調整ルール（cmdb_reconciliation_definition）と sys_object_source は、今回の PDI では 0 件でした。調整・ソース履歴は Discovery 等を動かして初めて意味を持つため、OOTB では未定義・未蓄積のままです。

IRE を調べるときは、まず対象クラスの cmdb_identifier を開き、その identifier entry を order 順に読みます。そのうえで、重複が疑わしいときは同定ルール、上書きが疑わしいときは調整ルールとデータソースを見ます。

実機を見て気づいたこと

Hardware Rule の9件の entry を order まで見ると、order 400 や 800 は cmdb_ci_network_adapter という別テーブルを照合先にしていました。同定は cmdb_ci_hardware 自身の属性だけで完結すると思っていましたが、実際にはネットワークアダプタなど関連テーブルの属性まで動員して照合していました。1つの CI を特定するために、CI自身の項目だけでなく周辺のレコードまで見に行く作りだと分かります。
cmdb_identifier_entry には allow_fallback という項目があります。名前から、ある entry の前提が崩れたときに次の entry へフォールバックする制御だと読めます。「上から順に試して最初に当たったところで確定する」という優先順位の仕組みが、単純な順次評価だけでなく、例外時の逃げ道まで用意された設計だと気づきました。

次に読むなら

次に確認したいのは、Related Entries（ルックアップ entry）の使い方です。加えて、IRE を実際に呼び出す identifyCI / createOrUpdateCI（IRE API）の挙動、Discovery / Service Graph Connector を流したときに sys_object_source へ何が記録されるか。特に「複数ソースが同じ CI を更新したときに調整ルールでどう優先順位をつけるか」は、本番 CMDB のデータ品質を左右します。これらは本記事の「調整とデータソース」で触れた仕組みの先にあたり、別記事で扱う予定です。

用語

IRE：Identification and Reconciliation Engine（同定・調整エンジン）
同定（Identification）：入ってくるデータが既存 CI かどうかを判定すること
調整（Reconciliation）：どのデータソースがどの属性を上書きできるかを制御すること
identifier entry：同定に使う属性の組み合わせ（優先順位つきの明細）
independent：そのルール単独で CI を同定できるか（true=独立 / false=親依存）
discovery_source：その CI がどのデータソース由来かを表す cmdb_ci のフィールド

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

先頭に自分のインスタンスを付けると、同じ画面が開けます。

CI Identifier 一覧   : cmdb_identifier_list.do
独立 identifier      : cmdb_identifier_list.do?sysparm_query=independent=true
Identifier Entry 一覧: cmdb_identifier_entry_list.do
Reconciliation 定義  : cmdb_reconciliation_definition_list.do
データソース由来CI   : cmdb_ci_list.do?sysparm_query=discovery_sourceISNOTEMPTY

ServiceNowのCMDBは何がどこに入っている？ CI・関係・サービスを実機で数える — IRE が同定する CMDB 全体の CI・関係・サービスの件数感を実機で確認できます。

検証範囲とおことわり

確認した範囲：cmdb_identifier / cmdb_identifier_entry / cmdb_reconciliation_definition / sys_object_source の定義・固有フィールド・件数、independent の内訳（157 / 252）、Hardware Rule の entry 構成（9件）と優先順位、discovery_source の分布（50件・Other Automated中心）。すべて PDI（Zurich / 2026-06-21 確認）の OOTB で取得しています。
確認していない範囲（断定しません）：実際に Discovery / Service Graph Connector / IntegrationHub ETL を流したときの同定挙動、sys_object_source への書き込み内容、調整ルールが効く場面、Related Entries（ルックアップ entry）の詳細動作、IRE API（identifyCI / createOrUpdateCI）の内部挙動、CMDB Health との連動。これらは別記事で扱います。

今回は PDI の OOTB（初期設定）を前提に、IRE の同定ルール構造を確認しました。実環境では、既存のカスタマイズや実際のデータソース連携によって、ルールの件数・調整定義・ソース履歴が変わります。