---
sourceDocument: Yokohama IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/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
* 
* 更新日 2025年01月30日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：4分

CI のバインディングまたはリンクは、イベントルールで定義されたロジックを使用して、構成管理データベース (CMDB) から構成アイテム (CI) を検索してアラートに接続するプロセスです。これにより、アラートが適切な IT コンポーネントに関連付けられ、可視化が向上し、問題解決が迅速化されます。

## CI バインディングの理解 {#ci-binding-alert__section_mdq_wxs_qdc}

アラートを CI にバインディングすると、受信アラートは、IT インフラストラクチャ内のコンピューター、サーバー、ルーター、仮想マシンなどの特定のホストを表す適切な構成アイテム (CI) にリンクされます。これにより、アラート追跡が正確になり、問題の原因を特定することでトラブルシューティングが簡素化され、特定のシステムに関連付けられたアラートの履歴レコードが保持されます。

IT Operations Management (ITOM)では、アラートと CI の関係は、サービスとインフラストラクチャを効果的に管理するうえで重要な役割を果たします。CI は、サーバー、アプリケーション、データベースなど、IT 環境内のコンポーネントを表します。アラートを CI にリンクすると、アラートとインシデントが、影響を受けるコンポーネントに直接関連付けられるため、正確な影響分析と迅速な解決が可能になります。  
動的で大規模な環境では、多くの場合、どの CI がアラートをトリガーする原因であるかを特定することが困難です。アラートは、複数のソースでキャプチャされた生のイベントデータから生成されますが、このデータは明示的に CI を参照していない場合があります。信頼性の高い方法でアラートを CI にバインドしないと、IT チームは次のようなリスクに直面します。

* サービスへの影響の可視化が不十分である。
* 平均解決時間 (MTTR) が長くなる。
* アラート管理プロセスが非効率である。
{#ci-binding-alert__ul_avr_yxs_qdc}  
イベントルールによって、構造化された方法で受信イベントデータを分析し、追加のコンテキストで拡張し、適切な CI にマップできます。こうしたルールはブリッジとして機能し、生のイベントデータを、CI にリンクしたアクション可能なアラートに変換します。たとえば、イベントルールでは次のことができます。

* 受信イベントデータの解析：このプロセスでは、生のイベントデータを分解して、ホスト名、IP アドレス、サービスタグなどの重要な詳細を抽出します。次に、これらの詳細をイベントの分析に使用して、そのソース、タイプ、影響を特定し、アラートを強化するために、影響を受けるサービス、優先度、解決手順などの関連コンテキストを追加して、IT チームにとってアクション可能なものにします。
* パターンの照合：ここでは、ホスト名、IP アドレス、サービスタグなどの抽出されたイベントの詳細が CMDB 内のエントリと比較され、事前定義されたルールまたはロジックに基づいて対応する構成アイテム (CI) が特定されます。一致すると、アラートは CI にリンクされ、影響を受ける IT コンポーネントに関するコンテキストが提供されるため、可視化が向上し、解決が迅速化されます。
* CI をアラートにバインド：この時点で、アラートは特定された CI に自動的に関連付けられます。これにより、アラートがシステム内の適切な IT コンポーネントに接続され、追跡と管理が容易になり、チームが問題に迅速に対処できるようになります。
{#ci-binding-alert__ul_hts_bys_qdc}

## CI バインディングのタイプ {#ci-binding-alert__section_mrf_fk1_l2c}

{#ci-binding-alert__table_m1c_gk1_l2c__entry__2}

| バインディングタイプ | 説明 |
|-|-|
| 暗黙的なノードバインディング (デフォルトバインディング) | イベントの \[ノード\] フィールドを、名前、FQDN、IP、MAC アドレスなどの属性と照合して、アラートをホスト CI にバインドします。 |
| CI フィールド一致バインディング | 列名と値 (名前、FQDN、IP、MAC アドレスなど) を含む JSON 構造である \[CI ID\] フィールドを使用して、アラートをバインドします。 |
| CI 識別バインディング | イベントルールを使用して、ホスト上の特定のアプリケーションにアラートをバインドします。 |
| プロセスレベルバインディング | プロセス関連の属性を照合して、アラートをアプリケーション CI にバインドします。 |
| デバイスレベルバインディング | イベントデータをホスト名、IP アドレス、MAC アドレスなどの属性と照合して、アラートをデバイス CI にバインドします。 |
[ ]

{#ci-binding-alert__table_m1c_gk1_l2c}

## 主な利点 {#ci-binding-alert__section_qfs_dys_qdc}

* サービス可視化の向上：CI にリンクされたアラートにより、影響を受ける IT コンポーネントを明確に把握できます。
* 自動化の強化：CI バインディングの自動化により、手作業が減り、一貫性が確保されます。
* 迅速な解決：チームは影響を受ける CI に焦点を当てることで、問題を迅速に診断して解決できます。
{#ci-binding-alert__ul_xp5_2ys_qdc}

## ユースケースの例 {#ci-binding-alert__section_p4x_gys_qdc}

シナリオ：ある会社の MailServer-01 という名前のメールサーバーがダウンします。  
プロセス :

1. アラートの生成：MailServer-01 が応答しなくなると、アラートがトリガーされます。
2. CI バインディング：イベント管理は、CMDB (構成管理データベース) 内の MailServer-01 を自動的に検索します。
   * 見つかった場合、アラートはこの特定のサーバー (CI) にリンクされます。
   * 見つからない場合、追加情報が提供されるまでアラートはリンク解除されたままになります。
   {#ci-binding-alert__ul_l2s_y1t_qdc}
{#ci-binding-alert__ol_ktp_x1t_qdc}  
結果：アラートは現在、MailServer-01 が影響を受けたシステムであることを示しています。

* 影響：IT チームは、調査するべきサーバーがすぐにわかります。
* 効率性：他のインフラストラクチャコンポーネントやシステムを確認する必要がないため、時間と労力を削減できます。
{#ci-binding-alert__ul_a4f_fbt_qdc}この直接リンクは、問題の正確な原因を示すことで、トラブルシューティングの簡素化に役立ちます。
**関連タスク**   

* [イベント処理をシミュレーション](https://servicenow-prod.fluidtopics.net/KJIHzJPN~roGgKa6zISFYw "イベントに対するイベント処理ロジックをシミュレートし、結果のアラートを表示することで、特定のイベントで実行されるルールと、そのルールが実行された後にイベントフィールドがどのように変化するかをよりよく理解できます。")