ServiceNow ZurichでCI関係設定に迷うポイントを整理する CMDBの見落とし防止ガイド

CIは登録できているのに運用で活かしきれない理由

ServiceNowでCMDBを触り始めると、まずはCIを登録するところから入ります。
サーバ、アプリケーション、データベースなどを作成し、インシデントや変更と紐づける。ここまでは比較的スムーズです。

ところが、運用や学習を進めるにつれて、次のような違和感が出てきます。

・CIは存在しているのに影響範囲が見えない
・Dependency Viewsを開くと、想定と違うつながり方をしている
・Relationshipを設定したはずなのに、実務では使われていない
・CI関係が増えるほど、全体像が把握しづらくなる

これらは単なる設定ミスというより、CI関係をどう捉えているかが整理されていないことが原因であることが多いです。
Zurich以降のCMDBは、CI単体ではなく「関係を前提に活用する」設計になっており、関係の理解が浅いと一気に迷いやすくなります。

---

CI関係とReferenceの違いを曖昧にしたまま進むと起きること

CI同士をつなぐ方法として、ServiceNowには大きく2つの考え方があります。

ひとつはReferenceフィールドによる紐づけです。
これは「このレコードがどのCIを参照しているか」を示すための仕組みで、インシデントや変更とCIを結びつける用途に向いています。

もうひとつがCI関係です。
CI関係は、CIとCIの間に「どのような依存関係や構造があるか」を意味として持たせるためのものです。

ここでよくある誤解が、「Referenceでつないでいるから、関係としても十分ではないか」という考え方です。
しかし実際には、Referenceはあくまで業務データとしての参照であり、依存関係の可視化や影響分析には使われません。

考え方の目安は次の通りです。

・業務上どのCIを選択したかを示したい → Reference
・構成や稼働影響、依存関係を表現したい → CI関係

この切り分けができていないと、Dependency ViewsやCMDB Healthを使ったときに「なぜ見えないのか」「なぜ評価されないのか」で迷うことになります。

---

Relationship Typeと方向性で混乱しやすいポイント

CI関係を設定するとき、多くの人が悩むのがRelationship Typeの選択と、親子の方向です。
特に英語表記のRelationship Typeは、日本語の感覚で読むと逆に解釈してしまうことがあります。

ここで重要なのは、名前の雰囲気で判断しないことです。
代わりに、次の問いを基準に考えます。

・このCIは、何がなければ動かないのか
・このCIが止まった場合、どれが影響を受けるのか

この問いに答えることで、「どちらが依存している側か」がはっきりします。
上下や親子という言葉に引きずられるよりも、依存しているかどうかで統一して考えるほうが、設計がぶれにくくなります。

また、CIクラスごとに一般的とされる関係の考え方があります。
関係タイプを増やす前に、「そのクラス間で自然な関係か」を一度立ち止まって考えることが、後々の混乱防止につながります。

---

Dependency Viewsで確認するときに意識したい順序

CI関係を設定したあと、「正しくつながっているか」を確認する場面で使われるのがDependency Viewsです。
ただし、最初から複雑な構成を表示しようとすると、かえって分かりにくくなります。

おすすめの確認手順は次の通りです。

・ルートにするCIをひとつだけ決める
・上流と下流のどちらを見たいのかを先に決める
・関係が1本だけのシンプルな状態で表示する
・想定した方向に伸びているかを確認する

期待と違う表示になった場合、多くは次の原因に行き着きます。

・親子の向きが逆になっている
・想定と違うRelationship Typeを使っている
・Referenceでつないでおり、CI関係として定義されていない

Dependency Viewsは「とりあえず開いて眺める」ものではなく、関係設計が正しいかを検証するための道具として使う意識が大切です。

---

CMDB Healthで関係の質が問われる理由

CI関係は、一度設定して終わりではありません。
DiscoveryやImport、構成変更などを繰り返すうちに、知らない間に崩れていきます。

そこで重要になるのがCMDB Healthです。
CMDB Healthでは、次のような観点でCI関係の状態が評価されます。

・本来つながるべきCIが孤立していないか
・同じ関係が重複して作られていないか
・クラスとして推奨される関係から大きく外れていないか

ここで意識したいのは、完璧を目指すことではありません。
「関係が壊れ始めている兆候に早く気づける状態」を作ることが目的です。

CI関係を何となく増やしていると、CMDB Healthの数値は下がりやすくなります。
逆に、関係の意味を整理したうえで設計していれば、運用の中での修正も判断しやすくなります。

---

IREや取り込み処理がCI関係に与える影響

CI関係が意図せず増えたり欠けたりする大きな要因が、外部からのデータ取り込みです。
ここで関わってくるのがIREです。

IREは、取り込まれたデータをCMDBに反映する前に、
「これは既存CIなのか」「新規CIとして作るべきか」を判断します。

この判断が揺らぐと、

・同じCIが重複して作成される
・結果として関係が分散・断絶する

といった問題が起きます。

CI関係の品質を保つためには、関係そのものだけでなく、
「CIが正しく同一視されているか」という前提も重要になります。

---

まとめ：CI関係で迷わないために持っておきたい判断軸

ZurichでCI関係設定に迷うのは、知識不足というより、判断の軸が整理されていないことが原因である場合がほとんどです。

次のポイントを意識するだけで、迷いは大きく減ります。

・ReferenceとCI関係は役割が違う
・方向性は名前ではなく「依存しているか」で判断する
・Dependency Viewsは検証のために段階的に使う
・CMDB Healthは関係の壊れ始めを知るための指標
・取り込みやDiscoveryが関係に影響することを前提に考える

CI関係を「設定項目」としてではなく、
サービス運用を成立させるための設計要素として捉えられるようになると、
実務でもCSA学習でも理解が一段深まります。