---
sourceDocument: オーストラリア ServiceNow AI Platform の機能
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/servicenow-platform

 Release :

    - australia

ft:locale :

    - ja-JP

ft:publication_title :

    - オーストラリア ServiceNow AI Platform の機能

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# 識別ルール

# 識別ルール {#ariaid-title1}

* リリースバージョン: Australia
* 
* 更新日 2026年03月12日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：6分

CMDB 識別プロセスは、CI を一意に識別するために識別ルールに依存します。
識別ルールは CI クラスに適用され、単一の CI ID と 1 つまたは複数の識別子エントリおよび関連エントリで構成されます。エントリはそれぞれ異なる優先度を持ちます。各識別子エントリは特定の優先度を持つ一意の属性セットを定義し、各関連エントリは関連アイテムを識別するためのルールを定義します。最強の識別子エントリと関連エントリに最高の優先度が設定されている強力な識別ルールを作成します。  
識別プロセスと識別ルールでは、識別のために CI の属性を使用します。

一意の属性
:   CI を一意に識別するために使用できる、CI の基準属性値の指定セット。一意の属性は、同じテーブルまたは派生テーブルから取得できます。

必要な属性
:   空にすることができない CI の指定属性。

## CMDB 階層全体での派生 {#c_IdentificationRules__section_lpj_mcp_mvb}

子クラスに対して識別ルールが明示的に定義されていない場合、子クラスはその親クラスから、関連付けられた識別エントリおよび関連エントリを含む識別ルールを派生させます。その後、子クラスに対して独自の識別ルールを明示的に定義できます。その場合、最初に親クラスから派生した識別ルールは、関連付けられた識別エントリおよび関連エントリを含め、子クラスでは無効になります。また、子クラスで新しく作成された識別ルールに識別エントリと関連エントリを明示的に追加する必要があります。

例：Hardware クラス識別ルールには Software Instance テーブルの関連エントリがあります。Software Instance テーブルに関連付けられた関連エントリを含むこの識別ルールは、Computer クラスによって派生します。Computer クラスの新しい識別ルールを作成すると、Hardware クラスから派生した識別ルールはそれによって上書きされます。Software Instance テーブルに関連付けられた関連エントリを含む Hardware クラス識別ルールは、Computer クラスに対する効果はなくなります。同じ関連エントリが必要な場合は、Computer クラスの新しく作成された識別ルールで Software Instance テーブルの関連エントリを明示的に追加する必要があります。

## 識別ルール タイプ {#c_IdentificationRules__section_ukp_1h4_j1b}

CI の依存関係は、CI クラスマネージャーで CI のクラスの依存関係ルールによって指定されます。

独立型 CI
:   独自に存在し、他の CI に依存しないサーバー CI などの CI です。

依存型 CI
:   別の CI との関係に依存し、依存関係がないと単独では存在できない CI です。たとえば、

    * Network Adapter CI は、それらを含む Hardware CI なしでは意味のある存在にはなりません。
    * Application CI は、ホストされている Server CI がなければ単独では存在できません。
{#c_IdentificationRules__ul_oyv_5kq_wqb}  
依存 CI を識別する手順は、独立 CI を識別する手順とは異なる場合があります。この違いは、依存識別ルールと独立識別ルールの違いに反映されます。

独立識別ルール
:   他の CI または関係とは無関係に、CI の独自の属性に基づいて CI を識別するルール。

依存識別ルール
:   CI を識別するルールは、依存 CI を最初に識別する必要があります。CI は 1 つ以上の CI に依存することができ、依存 CI は 1 つの親 CI のみと依存関係を持つことができます。CI とその依存 CI 間の関係タイプも識別プロセスに含まれます。依存 CI の識別プロセスを支援するため、CI タイプ内の依存関係チェーンを定義する[従属関係を作成](https://servicenow-prod.fluidtopics.net/LqDiZuSv2o_QfLRnU_TURQ#create-dependent-relationship "CI クラスのホスティングおよび格納規則 (依存関係性ルール) を作成して、ビジネスディスカバリープロセスおよびサービスマッピング中に依存 CI を正しく識別できるようにします。ディスカバリー は依存関係性ルールを適用する識別 API を呼び出します。")します。

    依存 CI の識別に使用されるペイロードには、修飾子チェーンとの関係を含めることができます。このような関係では、一致する親子ペアが存在する場合、ペイロード内の修飾子チェーンはデータベース内の CI の修飾子チェーンと比較されます。相違がある場合、データベース内の修飾子チェーンは、その関係のペイロード内の修飾子チェーンと一致するように更新されます。

## 識別子エントリ {#c_IdentificationRules__section_m3w_pg4_j1b}

CI の独自の属性 (フィールドベースの識別) に基づいているだけでなく、シリアル番号やネットワークアダプターなどの CI の関連リスト (ルックアップベースの識別) にも基づいて CI に一致するように識別子エントリを構成することができます。識別に使用されるルックアップテーブルには、cmdb_ci をポイントする参照フィールドがある必要があります。{#c_IdentificationRules__p_IDRuleIntro2}  
識別子エントリには 3 種類あります。

通常の識別子エントリ
:   識別は CI を一意に識別する CI 自身の属性に基づきます。

ルックアップ識別子エントリ

:   識別では、識別されている CI への参照を持つ任意のテーブルをルックアップテーブル (関連テーブル) として使用します。関連ルックアップテーブルを選択したら、cmdb_ci テーブル自体、またはその子孫の 1 つを参照する関連テーブルから識別子属性を選択します。

    ルックアップレコードがまだ存在しない場合は、識別子エントリで参照されるルックアップテーブルに挿入されます。

ハイブリッド識別子エントリ

:   通常の識別子エントリとルックアップ識別子エントリの両方の組み合わせです。 例：同一セットのシリアル番号がある 2 つの仮想マシンが含まれる可能性のあるクラウド環境で仮想マシンを検出した場合。<kbd class="ph userinput">[Table: Serial Number, Criterion Attributes: Serial Number, Serial Number Type]</kbd> のように、ハードウェアテーブルのルックアップ識別子エントリでは、このような 2 つの仮想マシンを一意に識別できません。しかし、<kbd class="ph userinput">[Table: Serial Number, Criterion Attributes: Serial Number, Serial Number Type + (Name field from main Hardware table)]</kbd> のようなハイブリッド識別子エントリでは、2 つの仮想マシンを一意に識別できます。

## ルックアップ テーブルのガイドライン {#c_IdentificationRules__section_e3m_rg4_j1b}

ルックアップ テーブルを識別子エントリに指定する場合は、次のガイドラインに従ってください。

1. ルックアップ テーブルが cmdb_ci テーブルを参照していることを確認します。
2. より強力な識別ルールのためにはカウントの完全一致を強制することが推奨されます (チェック ボックス \[カウントの完全一致を強制 (ルックアップ)\])。ルックアップ識別の間、このオプションは、ルックアップ レコード数の完全一致にのみ一致するように強制します。詳細は、[CI 識別ルールの作成](https://servicenow-prod.fluidtopics.net/Wvg7ed4bbbRvR0hBCmnnWQ "識別ルールは、識別および調整 (IRE) プロセスの一環として CMDB 内の CI を一意に識別するために使用されます。各 CMDB クラスは単一の識別ルールに関連付けることができます。")を参照してください。
3. 特にルックアップベースルールでは、競合する識別ルールを作成しないでください。  
   例：ハードウェアクラスの CI ID では、ネットワークアダプタークラスのルックアップベースルールを指定し、ネットワークアダプタークラスの CI ID も定義します。そのテーブルで一意の CI を識別する矛盾するルールが存在するため、ネットワーク アダプター テーブルに重複が作成される可能性があります。
   * 基準属性のみを参照する 1 つのルール (CI ID ルール)
   * 基準属性と参照した sys_id を参照する別のルール (ルックアップ ルール)。
   {#c_IdentificationRules__ul_c5y_vh4_j1b}
{#c_IdentificationRules__ol_efq_kgf_g1b}  
例：挿入が必要な関連アイテムがある CI - sysId が利用可能です。

    var payload = {
        items: [{
            className:'cmdb_ci_linux_server',
           related: [{
                  className:'cmdb_ci_spkg',
                  values: {
                    name:'package1',
                    version:'version1'
                    }
            }],
            values: {
                sys_id:'194876usytrr65378098'
            }
    }]
    };

## 関連エントリ {#c_IdentificationRules__section_ftc_tg4_j1b}

関連 CI に基づくルールである関連エントリを定義することができます。関連エントリは、識別されている CI への参照を持つ任意のテーブル (CMDB または非 CMDB) にすることができる関連テーブルに基づきます。関連エントリを使用すると、識別子エントリによって識別される CI にデータが関連付けられている他のテーブルのレコードを作成または更新できます。関連エントリは、CI を直接識別するためには使用されません。{#c_IdentificationRules__p_IDRuleIntro4}

ルールの関連テーブルを選択すると、参照済みフィールドのリストには、cmdb_ci テーブル自体、またはその子孫の 1 つを参照する関連テーブルからのフィールドが入力されます。

クラスの関連エントリは、関連エントリが指定されていない子クラスによって派生します。
* **[CI 識別ルールの作成](https://servicenow-prod.fluidtopics.net/Wvg7ed4bbbRvR0hBCmnnWQ)**   
  識別ルールは、識別および調整 (IRE) プロセスの一環として CMDB 内の CI を一意に識別するために使用されます。各 CMDB クラスは単一の識別ルールに関連付けることができます。
* **[ID 包含ルールの作成](https://servicenow-prod.fluidtopics.net/l1qRcwI1GlDJgxjQAQYtIQ)**   
  ID 包含ルールを作成して、識別プロセスに含まれる CI の範囲を絞り込みます。
* **[CMDB 識別を使用するための一般的なガイドライン](https://servicenow-prod.fluidtopics.net/z9oYgCaqRRbkJuI~6L0vcg)**   
  CMDB 識別を効果的に使用するための次の一般的なガイドラインを確認してください。

**関連概念**   

* [関係修飾子](https://servicenow-prod.fluidtopics.net/_6xw7Kr8SOESEsSTxMUMIg "修飾子 [cmdb_ci_qualifier] タイプの CI である関係修飾子は、CI 関係に関する重要な情報を格納しています。")

