ServiceNowのCMDBは何がどこに入っている？ CI・関係・サービスを実機で数える
CMDBを開くと、cmdb_ci・cmdb_rel_ci・cmdb_ci_service・alm_assetなど似た名前のテーブルが並び、どれが何なのか分からなくなります。ServiceNowのCMDBはCI・関係・サービス・資産という4本の軸でできていて、軸ごとに整備の進み方がまるで違います。Zurich PDIでCI2,786件・関係239件・資産2,819件を数えました。
検証環境：Zurich PDI / OOTB / 2026-08-08 確認
結論：4本の軸のうち、太いのはCIだけだった
先に全体像です。
CMDBは「CI」「関係」「サービス」「資産」という4本の軸で構成されます。このうち件数として太いのはCI（2,786件）と資産（2,819件）で、関係（239件）とサービス提供（0件）は細いままです。
CIとCIをつなぐcmdb_rel_ciは239件しかありません。CI1件あたりに割ると0.09本で、大半のCIはどこにもつながっていません。
資産（alm_asset）はCIより件数が多いのに、分類のしかたはまったく別物です。CIはクラス階層、資産は「Asset・Consumable・Hardware・Software License」という4区分です。
図の中心にあるcmdb_ciは、クラス定義（cmdb_class_info）と識別ルール（cmdb_identifier）から形作られます。そこから関係（cmdb_rel_ci）・サービス（cmdb_ci_service）・停止記録（cmdb_ci_outage）へと矢印が伸びていきます。資産（alm_asset）だけは矢印が点線です。同じモノを指していても、別系統の集計であることを表しています。サービスの下にあるservice_offeringは、四角の色を変えて「空のまま」だと分かるようにしました。
上の画面はConfiguration Itemsの一覧をクラスでグループ化したものです。全体2,786件のうち、Computerクラスだけで800件台に達する一方、1件しか登録されていないクラスも並びます。Databaseクラスは13件、Cluster Nodeは3件、AIX Serverは2件です。規模の差は数百倍に及びます。件数の偏りの大きさが、開いた瞬間に伝わってきます。
この9テーブルを、次の見出しから1つずつ確認します。
クラスは460定義されているが、実際にデータがあるのは35だけ
cmdb_ciを継承するクラスの定義は、CMDB Class Informationというテーブルに登録されています。件数は460でした。
一覧にはcmdb_ci_appl_ora_conc（Oracle Concurrent Server）やcmdb_ci_lb_bigip（F5 BIG-IP）のような専門的なクラスも並びます。特定の製品名がそのままクラス名になっている例です。cmdb_ci_vcenter_clusterやcmdb_ci_virtual_pvt_gatewayのように、仮想化基盤やネットワーク専用の枠も用意されていました。業務システムの構成であれば、ほぼ何でも表現できるだけのクラスが最初から入っている計算です。
一方で、先ほどのクラスごとグループ化の一覧では、実際に1件以上のCIが登録されているクラスは35にとどまっていました。460の定義のうち、実データがあるのは1割にも届きません。数字だけ見ると寂しく感じますが、これは異常ではありません。環境で使っている製品や機器の種類が、そのまま反映されただけです。使っていない技術のクラスにレコードが無いのは自然なことで、逆に「定義されているのに0件」を問題視する必要はありません。
CIより少ないのは cmdb_rel_ci：関係はCI 1件あたり0.09本
CIどうしのつながりを記録するのがcmdb_rel_ciです。件数は239でした。CIが2,786件であることを踏まえると、CI1件あたりの関係は0.09本という計算になります。
種類でグループ化すると、Depends on::Used byだけで137件と過半数を占めています。次点はExchanges data with::Exchanges data withの18件です。Members::Member ofが17件、Contains::Contained byが16件、In Rack::Rack containsが12件と続きます。いずれも10件台にとどまりました。1件しか登録されていない種類（Connected by::ConnectsやDR provided by::Provides DR forなど）も複数あります。よく使う種類とめったに使わない種類の差が、はっきり出ていました。
関係の種類そのものを定義するcmdb_rel_typeは40件登録されていますが、実際に1件以上の関係で使われている種類は15でした。定義はDR provided by::Provides DR forのような専門的な種類まで用意されているものの、実際の環境で使われているのはごく一部という点は、クラス定義とよく似た構図です。
フォームを開くと、Parent descriptorとChild descriptorが対になっていることが分かります。Depends onの逆から見るとUsed byというように、1つの関係を親側・子側それぞれの言葉で表現する設計です。どちらから見ても同じ1件のレコードを指しています。
サービスの下がまだない：service_offering は0件
CIを業務サービス単位で束ねるcmdb_ci_serviceは42件でした。
Blackberry・Bond Trading・E-Commerceのように、業務名がそのままサービス名になっています。Business criticalityやManaged byが入っているサービスもあれば、Approval groupが空のままのサービスも混在していました。
サービスのさらに下位にあたるservice_offeringを開くと、様子が変わります。
0件でした。ServiceNowのサービス階層は、上からBusiness Application・Application Service・Service Offeringという3段で設計されています。この環境では、いちばん下の段がまるごと空でした。サービス名までは登録されているのに、そのサービスをどんな条件で誰に提供しているかという具体まで踏み込んだレコードは1件もありません。42件のサービスは存在するのに、その先が続いていない状態です。
資産(alm_asset)はCIより多い、しかも別の分け方をしている
台帳としての資産を扱うalm_assetは2,819件で、CIの2,786件よりわずかに多い件数でした。
内訳を見ると、Consumable（消耗品）だけで1,791件と全体の6割以上を占めていました。次に多いのがHardwareで904件、Software Licenseが77件、分類前のAssetが47件です。CIのクラス階層はComputerやServerのような「機器の種類」で分かれます。資産の4区分は「モノの性質」による分類です。同じ機器でも、CI側では機種ごとのクラスに、資産側ではHardwareという1区分にまとまる形です。見ている軸そのものが違います。件数がほぼ同じでも、中身を単純に対応づけることはできません。
CIの停止記録は438件、関係よりずっと多い
CIの停止を1件ずつ記録するcmdb_ci_outageは438件でした。
Type列にはOutage・Degradation・Planned Outageの3種類が混在しています。Configuration Item列を見ると、PeopleSoft CRMやSAP Financial Accountingのように、サービス寄りのCIに停止記録が集中していました。CIそのもの（2,786件）や関係（239件）と比べると、停止記録438件という数字は決して少なくありません。障害の記録は積み上がっているのに、その障害がどのCIのつながりを通じて広がったのかを関係からたどれる状態には、まだなっていないことになります。
重複を防ぐ識別ルールは409件登録されている
同じCIが二重に登録されるのを防ぐ仕組みがIRE（Identification and Reconciliation Engine）で、そのルールを保持するのがcmdb_identifierです。件数は409でした。
1件ずつのルールには、Active Directory Domain ControllerやAdvanced Queueのように、対象のCIクラスと結びついた名前が付いています。Applies to列を見ると、cmdb_ci_ad_controllerのような物理クラス名が入っており、Independent列にはtrue・falseが混在していました。Independentがtrueのルールは、そのCI単独の情報だけで同定できることを示します。falseのルールは、他のCIとの関係を手がかりに同定する設計です。ACL Endpoint Ruleのように、単独では同定しきれず親となるCIとの関係を必要とするルールが、falseの側に並んでいました。クラスの数だけルールが必要になるわけでもありません。1つのルールが複数のクラスに対応する例も見られました。409件という数は、CIクラスの多様さに応じて同定の手がかりも細かく作り込まれていることの表れだと考えられます。
実機で気づいたこと：登録は進み、つながりは追いついていない
CI2,786件に対して関係239件という数字を見たとき、最初は「関係は主要な機器の間だけに絞って登録するものだろう」と考えていました。予想は外れました。関係の内訳を見ると、Depends on::Used byが137件で過半数を占め、残りは10件台の種類がほとんどです。主要な依存関係だけを選んで登録しているというより、単純に登録作業がCIの登録ほど進んでいないという状態に近く見えます。
もう1つ意外だったのが、資産2,819件がCI2,786件を上回っていた点です。逆でした。理由は資産の内訳にあります。Consumableだけで1,791件あり、消耗品はCIとして登録する対象にならないことがほとんどです。CIにならないモノが資産側だけに大量に存在するため、母数が逆転していました。件数の大小だけでシステムの整備状況を判断すると、見誤ることがあると分かります。
自分がCMDBの状態を短時間で確認するなら、まずCI一覧をクラスでグループ化し、次に関係一覧を種類でグループ化します。この2つの画面を開くだけで、「登録されているクラスの広がり」と「つながりの薄さ」がどちらも一目で分かります。停止記録やサービス階層は、その後で確認しても遅くありません。
実務では何に使えるか：CMDBを立て直すならこの順で見る
CMDBを引き継いだとき、あるいは既存のCMDBを見直すとき、どこから手を付けるかは上の表の順で決めています。
障害対応の場面で影響範囲が追えないという相談を受けたら、まず疑うのはcmdb_rel_ciです。CIそのものは登録されていても、関係が無ければ影響範囲は追えません。今回の環境のようにCI1件あたり0.09本という薄さであれば、関係を増やす作業のほうがCIの追加登録より優先度が高くなります。
CIの重複が疑われる場合は、cmdb_identifierを確認します。対象のクラスに識別ルールが用意されているか、Independentの設定が実態に合っているかを見ると、重複の原因が仕組み側にあるのか運用側にあるのかを切り分けられます。
サービス影響の追跡ができないという相談には、cmdb_ci_serviceとservice_offeringの両方を開きます。サービス名までは登録されていても、その下のservice_offeringが空であれば、サービス階層としてはまだ半分しかできていません。
台帳の数字が合わないという相談には、alm_assetとcmdb_ciの両方を突き合わせます。今回の環境で見たように、資産とCIは分類の軸そのものが違うため、件数の差だけを見て「どちらかが間違っている」と判断するのは早計です。
過去の障害履歴が追えないという相談には、cmdb_ci_outageを開きます。停止記録が438件あっても、記録先のCIに関係が無ければ、その障害が他のサービスにどう波及したのかまでは追えません。停止記録の量と、関係の薄さは別の問題として扱う必要があります。
使っていないクラス定義を整理したいという相談には、cmdb_class_infoとCI一覧のクラス別グループ化を見比べます。460の定義のうち実データがあるのは35クラスでしたが、残り425をすぐ削除してよいとは限りません。将来使う予定があるか、他の設定から参照されていないかを、削除の前に確認する手順が要ります。
さらに詳しく知りたい人へ
CIは1テーブルではなく102クラスに分かれる（cmdb_ci） — cmdb_ciのクラス階層を1テーブルずつ読む前提知識
CIのつながりは親→種類→子（cmdb_rel_ci） — cmdb_rel_ciの構造を詳しく見る実例
資産(alm_asset)とCMDB(cmdb_ci)を分ける理由 — 資産とCIを分けて管理する理由を掘り下げた記事
よくある質問
Q1. CI2,786件に対して関係239件は少ないのでしょうか
比較できる基準値が公式に決まっているわけではないので、断定はできません。ただしCI1件あたり0.09本という数字は、大半のCIがどの関係にも登場しないことを意味します。障害の影響範囲をCMDBから追いたいのであれば、この状態では関係をたどる調査が機能しにくいと考えられます。
Q2. 資産(alm_asset)とCI(cmdb_ci)はどちらを正として扱えばよいですか
用途によって変わります。所有者や購入価格、契約といった台帳の情報は資産側が正で、機器同士のつながりや稼働状況を追いたいならCI側が正になります。今回の環境では資産のほうが件数が多く、Consumableのように最初からCIに対応しない資産も含まれているため、両方を同じ台帳として扱うことはできません。
Q3. service_offeringが0件なのは設定ミスですか
設定ミスとは限りません。service_offeringはサービス階層の中でも詳細な提供条件を記録する下位テーブルで、上位のcmdb_ci_serviceだけでも一覧としては機能します。ただし影響分析やSLAをサービス提供単位で細かく見たい場合は、この階層まで整備しないと粒度が粗いままになります。
Q4. クラス定義460のうち、データが無い425クラスは削除してよいですか
今回のクラスごとグループ化では、実データがあるクラスが35であることまでは確認できましたが、残りのクラスをすべて削除してよいかどうかは別の話です。将来その技術を導入する予定がある場合や、他のプラグインが参照している定義が含まれる可能性があるため、削除の前に依存関係の洗い出しが必要です。
Q5. どのテーブルから手を付けるとCMDBの状態が早く分かりますか
cmdb_ciをクラスでグループ化した一覧と、cmdb_rel_ciを種類でグループ化した一覧の2つを開くのが最短です。前者で登録の広がりが、後者でつながりの薄さが同時に見えます。サービス階層や資産の突き合わせは、この2つを確認した後に進める順番で問題ありません。
まとめ
ServiceNowのCMDBは、CI・関係・サービス・資産という4本の軸で構成されています。今回の環境ではCIが2,786件、資産が2,819件と太い一方、関係は239件、service_offeringは0件と細いままでした。クラス定義460のうち実データがあるのは35クラス、関係の種類40のうち実際に使われているのは15種類と、定義と実データの差も大きく開いています。
CIの登録だけを見ていると、CMDBは十分に整備されているように見えます。しかし関係やサービス階層まで含めて確認すると、登録されたCIが互いにつながっていない状態が見えてきます。CMDBを立て直す作業は、CIを追加することよりも、既にあるCIどうしをつなぐ作業から始めたほうが効果が出やすいはずです。
用語
cmdb_ci … 構成アイテム（CI）の基底テーブル。サーバやサービスなど多様なクラスがここから枝分かれする
cmdb_rel_ci … CIどうしの関係を記録するテーブル。parent・child・typeの3項目で1件が決まる
cmdb_rel_type … 関係の種類の定義。Depends on::Used byのように親側・子側の呼び方が対になる
cmdb_class_info … CIクラスの定義を保持するテーブル
cmdb_identifier … IRE（同定・重複判定の仕組み）が使う識別ルール
cmdb_ci_service … 業務サービスを表すCI
service_offering … サービスをさらに詳細な提供条件で分けた下位レコード
cmdb_ci_outage … CIの停止を1件ずつ記録するテーブル
alm_asset … 資産管理の基底テーブル。CIとは別の軸で台帳を持つ
実機で調べるときに開いたURL
/cmdb_ci_list.do?sysparm_query=GROUPBYsys_class_name … CIをクラス別に集計
/cmdb_rel_ci_list.do?sysparm_query=GROUPBYtype … 関係を種類別に集計
/cmdb_rel_type_list.do … 関係の種類の定義一覧
/cmdb_ci_service_list.do … サービス一覧
/service_offering_list.do … サービス提供一覧
/alm_asset_list.do?sysparm_query=GROUPBYsys_class_name … 資産をクラス別に集計
/cmdb_ci_outage_list.do … CIの停止記録一覧
/cmdb_identifier_list.do … 識別ルール一覧
/cmdb_class_info_list.do … クラス定義一覧
参考リンク
検証環境と未検証範囲
件数・画面はZurich PDI（OOTB）で確認したものです。一覧画面の総件数表示とグループ化の内訳を突き合わせて数えており、推定やサンプリングではありません。本番環境やカスタマイズ済みの環境では数値が異なります。
各クラスごとのレコード分布の全量、IREが実際に重複をどう防いでいるかという動作、Discoveryを動かした場合の変化は確認していません。資産とCIがレコード単位でどこまで対応づいているかという突き合わせも、今回は扱っていません。関係の種類ごとの妥当性やクラス定義の要不要についても、判断材料の提示にとどめています。
