---
sourceDocument: Xanadu の Now Platform 機能
sourceDocumentLink: https://www.servicenow.com/docs/r/ja-JP/xanadu/servicenow-platform

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu の Now Platform 機能

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# 調整ルール

# 調整ルール {#ariaid-title1}

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

調整ルールは、CI 属性を更新できるディスカバリーソースを決定します。{#r_ReconciliationRulesPrinciples__ph_ReconciliationShortDesc}
EventManagement、ImportSet、ManualEntry、および Tivoli などのディスカバリーソースは、CI の手動更新をシミュレートする [createOrUpdateCI()](https://www.servicenow.com/docs/access?context=c_IdentEngineScriptAPI&version=xanadu&pubname=xanadu-api-reference&ft:locale=en-US) API で使用されます。調整ルールがない場合、ディスカバリーソースは互いの属性値の更新を上書きできます。  
調整ルールには、次の 2 種類があります。

静的調整ルール

:   静的調整ルールは、CI 属性を更新するためのさまざまなディスカバリーソースの優先度を設定する従来の調整ルールです。静的調整ルールは、クラス属性を更新できるディスカバリーソース、およびこれらのディスカバリーソース間の優先順位を指定します。

    静的調整ルールを作成する場合、属性の更新が許可されている各ディスカバリーソースに調整ルールがあることを確認します。調整ルールは、親クラスおよび子クラスレベルで定義できます。

    静的調整ルールは、調整定義 \[cmdb_reconciliation_definition\] テーブルに保存されます。

動的調整ルール

:   動的調整ルールは、ディスカバリーソースの優先度ではなく、[CMDB 360/マルチソース CMDB](https://www.servicenow.com/docs/vrK2tgkoCF2uV4SGvQvY8w "CMDB 360 は、CI 属性の更新に関係するディスカバリーソースと提案された値の完全な履歴を保持します。CMDB 360 データを使用して、さまざまなディスカバリーソースによる CMDB への入力を CI 属性レベルで追跡します。また、特定のディスカバリーソースからの CI の更新を元に戻したり、更新された調整ルールを使用して属性値を再計算したりすることもできます。") によって処理される属性値に基づいています。まず、CMDB 360 は、現在のペイロードデータを CMDB 360 データストアに処理します。次に、IRE は動的調整ルールを適用して、たとえばディスカバリーソース全体で、報告された最大値または最も報告件数が多い値をを選択します。動的調整ルールは CMDB 360 を利用するため、動的調整ルールを使用するにはその機能を有効にする必要があります。

    動的調整ルールを作成すると、たとえば、複数のディスカバリーソースに優先順位を設定することが困難になった場合などに役立ちます。クラス属性ごとに存在できる動的調整ルールは 1 つだけです。

    動的調整ルールは、動的調整定義 \[cmdb_dynamic_reconciliation_definition\] テーブルに保存されます。

## 静的調整ルールの例 {#r_ReconciliationRulesPrinciples__section_mzm_tlg_q5b}

cmdb_ci_computer クラスとその cmdb_ci_linux_server 子クラスに対して、次の静的調整ルールのサンプルが作成されます。

1. ディスカバリーは、cmdb_ci_computer クラスの name 属性の更新を独占的に許可されます。

   調整ルールは親クラスから子クラスによって派生するため、このルールはディスカバリーが cmdb_ci_computer クラスの任意の子クラスの name 属性を更新することも許可します。
2. ServiceWatch は、cmdb_ci_linux_server クラスの name 属性の更新を独占的に許可されます。
3. ServiceWatch は、ルールの \[属性\] フィールドを空にして設定すると、cmdb_ci_linux_server クラス内のすべての属性を更新することが独占的に許可されます。
{#r_ReconciliationRulesPrinciples__ol_gk5_gg4_ft}

静的調整ルールの作成 (たとえば name などの特定の属性の更新をディスカバリーソースに許可するなど) の詳細については、「[CI 調整ルールの作成](https://www.servicenow.com/docs/Qz8KxLYvfs2UTaQOSz9wVQ#create-reconciliation-rule "静的または動的 CI 調整ルールの作成")」を参照してください。

## 調整ルールの使用 {#r_ReconciliationRulesPrinciples__section_dtq_nty_p5b}

調整ルールを作成するときは、属性レベルでのルールの柔軟性と改良のために設計された、次の原則を念頭に置いてください。  

動的調整ルールの優先順位

:   同じ CI 属性に静的調整ルールと動的調整ルールの両方が存在する場合、静的調整ルールよりも動的調整ルールが優先されます。

クラス内のすべての属性に対する許可

:   静的調整ルールを使用すると、ディスカバリーソースによるクラス内の全属性の更新を許可することができます。ただし、この許可は、特定の属性がリストされている子クラスのルールによって、一部の属性について上書きできます。

    たとえば、上の例のルール #1 と #3 のみが作成された場合、ディスカバリーは cmdb_ci_linux_server クラスの name 属性の更新が許可されます。ServiceWatch は name 属性を除くクラス内の他のすべての属性の更新が許可されます。

    ディスカバリーの権限を上書きして name 属性を更新するには、上の例のルール ＃2 を追加して、属性の更新を ServiceWatch に特別に許可します。

クラス内の特定の属性のみに対する許可

:   ディスカバリーソースにクラス内の特定の属性を更新する権限を付与する場合は、そのディスカバリーソースに対して静的調整ルールを作成し、そのルールでこれらの属性をリストします。クラス内の特定の属性へのアクセスを許可するルールは、クラス全体へのアクセスを許可する空の属性リストを持つ他の静的調整ルールを上書きします。

    上の例のルール #1 は、ディスカバリーに、cmdb_ci_computer クラスの name 属性の更新を独占的に許可します。他のすべてのディスカバリーソースは、cmdb_ci_computer クラス内の任意の CI の name 属性を更新できなくなります。

子クラスのルールによる親クラスのルールの上書き

:   子クラスに対して定義された調整ルールは、その親クラスに対して定義されたルールを上書きします。このルールは、子の調整ルールが静的で、親のルールが動的である場合にも適用されます (同じレベルのクラスの場合、動的調整ルールは静的調整ルールよりも優先されます)。

    たとえば、上のルール #1 では、ディスカバリーは cmdb_ci_computer クラスおよびそのすべての子クラスの name 属性を更新できます。ただし、親クラスのルール #1 を上書きする cmdb_ci_linux_server 子クラスルのルール #2 は、ServiceWatch が子クラスのこの属性を更新することを明示的に許可します。  
    結果：

    * ディスカバリーは子 cmdb_ci_linux_server クラスの name 属性を更新できません。ServiceWatch のみがこの属性の更新を許可されます。
    * ディスカバリーは、cmdb_ci_computer クラスのその他すべての子クラスで CI レコードの name 属性を更新することが許可されます。
    {#r_ReconciliationRulesPrinciples__ul_y1x_yzy_3t}

静的調整ルールの重複

:   同じクラスの同じ属性に対して異なるディスカバリーソースを許可する静的調整ルールは、共存することができ、互いに除外しません。

    たとえば、次のルールが追加されたとします。これは上のルール #1 の例と似ていますが、別のディスカバリーソースを許可します。

    ServiceWatch は、cmdb_ci_computer クラスの name 属性の更新を許可されます。

    上のルール #1 の例と同様に、この新しいルールは cmdb_ci_computer クラスの name 属性に適用されるため、ディスカバリーおよび ServiceWatch のどちらも属性を更新できます。ディスカバリーソースが互いの更新を上書きしないように、調整ルールが適用されます。

調整ルールの詳細については、「[\[CMDB - データ優先順位ルール\] CMDB データ優先順位ルールの理解とトラブルシューティング \[KB0756709\]](https://support.servicenow.com/kb_view_customer.do?sysparm_article=KB0756709)」のナレッジベース記事を参照してください (Paris リリース以降、調整ルールとデータ優先順位ルールは結合されています)。

## ドメインセパレーション

ドメインセパレーションを有効にすると、特定のドメインに調整ルールを適用できます。親ドメインのルールは、上書きされない場合、子ドメインの CI に適用されます。ドメインに表示されるすべてのルールが適用され、親ドメインを上書きするルールによって子ドメインのバージョンが表示されます。
[CMDB 調整ルールとトラブルシューティング \[KB0756709\] の理解](https://support.servicenow.com/kb_view.do?sysparm_article=KB0756709)
* **[CI 調整ルールの作成](https://www.servicenow.com/docs/Qz8KxLYvfs2UTaQOSz9wVQ#create-reconciliation-rule)**   
  静的または動的 CI 調整ルールの作成
* **[データ更新ルールの作成](https://www.servicenow.com/docs/77VIl7Fy8W5suUzjQ9MCew)**   
  特定のディスカバリーソースに対して CI が古くなっているかどうかを判断するには、データ更新ルールを指定します。これにより、このような CI を優先度がより低い、許可されたディスカバリーソースによって更新することができます。