---
sourceDocument: Yokohama IT Operations Management
sourceDocumentLink: https://www.servicenow.com/docs/r/ja-JP/yokohama/it-operations-management

 Release :

    - yokohama

ft:locale :

    - ja-JP

ft:publication_title :

    - Yokohama IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# アラートを特定のホスト CI にバインドする (デフォルトバインディング)

# アラートを特定のホスト CI にバインドする (デフォルトバインディング) {#ariaid-title1}

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

\[ノード\] フィールドまたは \[CI ID\] フィールドを使用してアラートを構成アイテム (CI) にバインドすることで、イベントの正確な関連付けが保証されます。イベントレコードの \[ノード\] または \[CI ID\] の値を比較することで、アラートが適切なシステムにリンクされます。これにより、影響を受ける資産が明確に可視化されるため、応答、根本原因分析、影響度アセスメントが改善されます。

## デフォルトバインディングの仕組み {#binding-alert-CI-host-default__section_p3t_zfy_k2c}

イベントレコードの \[ノード\] フィールドまたは \[CI ID\] フィールドを使用して、デフォルトバインディングを実行できます。

イベントがシステムに入力されると、\[ノード\] などのキーフィールドがイベントレコードで使用できるようになります。ただし、CI に \[ノード\] フィールドはありません。代わりに、イベントのノード値は、名前、完全修飾ドメイン名 (FQDN)、IP、MAC アドレスなど、ホスト CI 内のさまざまな属性と比較されます。一致するものが見つかった場合、アラートは対応する CI にリンクされます。これは、アラートを CI にバインドするデフォルトの方法です。

プロパティ sa.active_operation_status は、特にイベントのノードフィールドを使用して IP/MAC 経由でバインドする場合に、デフォルトのバインディングメカニズムで使用されます。イベントが (IP/MAC を使用して) ノードフィールドを介してホストにバインドしようとすると、システムは運用ステータスがこのプロパティに含まれていないホストを無視し、ホストの運用ステータスも null であってはなりません。デフォルトでは、プロパティ値は「1」で、\[運用\] に対応します。リストを拡張して追加のステータスを含めることができます。リスト内のステータスはバインディング中に無視されません。  
例: sa.active_operational_status = "1,2" の場合、稼働中のホストと非稼働中のホストの両方がバインディングに有効であると見なされます。ステータス属性は、次の値で定義されます。

* 1:稼働
* 2:非稼働
* 3 -- 修理中
* 4 -- DRスタンバイ
* 6:廃止
{#binding-alert-CI-host-default__ul_vk3_yc1_lhc}  
注:  
このバインディングプロセスでは、CI がホストでなければなりません。ホスト CI には、コンピューター、オペレーティングシステム (OS)、スイッチ、ルーター、または \[cmdb_ci_hardware\] テーブルを拡張する任意の CI タイプ/クラスが含まれます (つまり、CI タイプまたはクラスは、ハードウェアコンポーネントである必要があります)。

ノードを使用して一致するものが見つからない場合、システムはイベントレコードの \[CI ID\] フィールドを確認します。CI ID は、比較用の列名と値 (名前、完全修飾ドメイン名 (FQDN)、IP、MAC アドレスなど) を含む JSON 構造です。JSON は {"column_name":"\<column_value\>"} です。たとえば、値が Dell Latitude 7420 Laptop である serial_number によって識別される CI にバインドする場合、JSON は <kbd class="ph userinput">{"serial_number":"Dell Latitude 7420 Laptop"}</kbd> になります。一致するものが見つかった場合、アラートは対応する CI にリンクされます。

## ノードによるバインディングとCI ID {#binding-alert-CI-host-default__section_ufn_3p1_l2c}

デフォルトバインディングでは、\[補足情報 (Additional Information)\] フィールドのすべてのフィールドが考慮され、その値と CI テーブルとの照合が試みられます。\[CI ID\] フィールドでは、\[補足情報 (Additional Information)\] に存在しない場合でも、特定のフィールドを照合対象として指定できます。このプロセスは、事前定義された JSON 構造を使用し、CI がホストである場合にのみ 適用されます。  
注:  
\[ノード\] または \[CI ID\] によってアラートと CI のバインディングが成功した場合でも、\[イベントルール\] 内で利用可能な \[デフォルトバインディングを上書き\] チェックボックスを使用して、バインディングの方法がさらに決定されます。これにより、アラートは直接一致するだけでなく、ビジネスロジックに基づいて正しくバインドされます。これにより、アラートは直接一致するだけでなく、ビジネスロジックに基づいて正しくバインドされます。

## 例：ノードルールとイベントルールを使用した CI の解決 {#binding-alert-CI-host-default__section_rn5_bgy_k2c}

ネットワーク内のサーバー (Server-123) がイベントを生成したとします。イベントレコードには、値が「Server-123.example.com」の \[ノード\] フィールドが含まれています。

1. CI 属性との照合：
   1. CMDB に対してノードの値がチェックされます。
   2. 「Server-123.example.com」と既存のホスト CI の FQDN、IP、MAC アドレス 、または名前が比較されます。
   3. 一致するものが見つかった場合 (例：CMDB の FQDN も「Server-123.example.com」)、アラートはその CI にリンクされます。
   {#binding-alert-CI-host-default__ol_lfj_1qp_k2c}
2. イベントルールの適用：ノードが Server-123 に関連付けられた場合でも、追加のイベントルールによって、アラートが異なるようにリンクされるべきかどうかが決定される場合があります。たとえば、イベントルールが指定され、Server-123 からのアラートが個々のサーバーではなく、親 CI (クラスターなど) にリンクされる場合があります。
{#binding-alert-CI-host-default__ol_kfj_1qp_k2c}