ServiceNowのCIはどのテーブルに入る？ cmdb_ciの102クラスを実機で確認
サーバのCIを一覧で探しているのに、cmdb_ciを検索しても目的のレコードにたどり着けないという経験はないでしょうか。ServiceNowのCIはcmdb_ciという1テーブルに集約されず、その下に102の子クラスが枝分かれしています。しかも102クラスのうち、実際にCIレコードを直接抱えているのはわずか12クラスだけでした。Zurich PDIでcmdb_ciの継承構造と、クラスごとの実データの偏りを確認します。
検証環境：Zurich PDI / OOTB / 2026-08-09 確認
結論：cmdb_ciの102クラスのうち、実データがあるのは12だけだった
先に全体像です。
cmdb_ciはcmdb（基底）を継承しながら、直下に102の直接の子クラスを持ちます。
102クラスのうち、CIレコードを直接持つクラスは12だけで、残り90クラスは0件でした。実際のCIデータの大半は、直接の子よりさらに深い階層のクラスに入っています。
全2,786件のうち、cmdb_ci_spkg（Software、直接の子）が1,767件で63%、cmdb_ci_computer（Computer、直接の子ではない、さらに深い階層）が815件で29%を占め、この2クラスだけで全体の92%を超えます。
12対90という差は、想像以上でした。
図の色は6種類の意味に固定しています。
水色 … 継承元（cmdb）
濃紺 … 起点（cmdb_ci）
緑 … 直接の子のうち実データがあるクラス
赤 … 直接の子のうち実データ0件のクラス
紫 … 直接の子ではない、さらに深い階層のクラス
橙 … 件数が突出しているクラス
cmdb_ciを検索窓でそのまま探しても目的のCIに当たらないことがあるのは、この階層のどこかに実データが偏っているためです。sys_class_nameを見れば、いま自分がどのクラスを見ているかが分かります。
Discoveryやインポートで自動登録されたCIを確認するときも、まず開くのはsys_class_nameです。クラスをまたいで件数を集計したり重複をチェックしたりすると、実態とずれた数字を見てしまうことがあります。
なぜCIは1つのテーブルに入らないのか
CMDB（Configuration Management Database）とは、組織が持つIT資産や構成要素を登録するデータベースです。登録単位を構成アイテム（CI＝Configuration Item）と呼び、サーバ・PC・アプリ・サービスなどが対象になります。組織によっては、ネットワーク機器やクラウド上の仮想リソースまで対象を広げ、IT基盤全体を横断的に管理する目的で使うこともあります。ServiceNowでは、このCIを格納する中心テーブルがcmdb_ciです。
ただし、サーバもアプリもデータベースも同じ種類のレコードに入るわけではありません。cmdb_ci_server / cmdb_ci_computer / cmdb_ci_databaseのように、CIはクラスごとに分かれたテーブルに保存されます。今どのクラスに入っているCIかは、sys_class_nameフィールドで確認します。
cmdb_ciのフォームを直接開くと、共通項目の並んだ1レコードが見えます。
サーバのフォームに並ぶ項目は、cmdb_ci側の共通項目とcmdb_ci_server側の固有項目を組み合わせたものです。ServiceNowのテーブル拡張は、親テーブルの共通項目と子テーブルの固有項目を1つのレコードとして扱う仕組みです。cmdb_ciを一覧すると全クラスのCIがまとめて見え、各クラスのテーブルを開くとそのクラスだけが見える、という関係になります。
画面からクラス構成をたどりたいときは、Configuration ＞ CI Class Managerが入口になります。クラス一覧・継承関係・各クラスの件数を1つの画面でまとめて確認できるため、sys_db_objectを直接クエリで探すより見通しが立ちやすい場面もあります。
クラス階層は、次のURLで確認できます（先頭の<YourInstance>は自分のインスタンスに置き換えてください）。
https://<YourInstance>/sys_db_object_list.do?sysparm_query=super_class.name=cmdb_ci直接の子と、さらに深い階層は別物
cmdb_ciで始まる名前のテーブルを前方一致で数えると707件ありました。ただしこれは名前ベースのラフな値で、直接の子クラス102件とは別の数字です。cmdb_ci_hardware / cmdb_ci_computer / cmdb_ci_serverのような、よく見る具体的なクラスは、cmdb_ciの直接の子ではありません。中間クラスのさらに下に位置しています。直接継承しているクラスなのか、名前がcmdb_ciで始まるだけのクラスなのかを混同すると、クラス階層の深さを見誤ります。
公式のConfiguration Management Database (CMDB)にCMDBの全体像がまとまっています。
cmdb_ciにはどんなフィールドがあるのか
cmdb_ciは、どのクラスのCIにも共通する項目を持ちます。
識別・状態・所有担当・関連・ネットワークの5グループ
識別グループはname / sys_class_nameのようにCIを特定する項目、状態グループはinstall_status / operational_statusです。所有担当グループはassigned_to / support_groupのように誰が管理するかを表し、関連グループはasset / model_idのように他テーブルへの参照を持ちます。ネットワークグループはip_address / fqdnのように通信面の情報です。5つに分けて覚えておくと、フィールド一覧を初めて見たときも迷わず読めます。
主なフィールドの代表は次のとおりです。ラベルは画面上の表示名で、実機どおり記載します。
CIは「モノの台帳」として、識別情報（name / serial_number）と状態（install_status / operational_status）を持ちます。あわせて、担当（assigned_to / support_group）や関連（asset / model_id / location）も記録します。assetは資産レコード（alm_asset）、model_idは型番（cmdb_model）への参照です。
cmdb_ciの共通フィールドは、多くのCMDB機能の前提です。公式ドキュメントでも、cmdb_ciの属性をdictionaryで不用意に変更しないよう注意喚起されています。フィールド型や参照先を変えると、CMDBを利用する機能に影響が及びます。
全フィールドは、次のURLで一覧できます。
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=cmdb_ci^elementISNOTEMPTY
公式のCMDB tables descriptionsに、cmdb_ciをはじめとするCMDB関連テーブルとフィールドの詳細が一覧されています。
install_statusとoperational_statusは何が違うのか
CIの状態は、task系のような1本のStateとは違う扱いです。軸は2つあります。cmdb_ciには、代表的な状態フィールドとしてinstall_statusとoperational_statusの2つがあります。
install_statusは、CIが設置・在庫・修理・廃棄など、ライフサイクル上どの状態にあるかを示す項目です。operational_statusは、CIの現在の運用状態を表す項目です。単に動いている・止まっているだけでなく、Repair in Progress・DR Standby・Ready・Retiredのように、運用上の扱いを表す値も含みます。「Installed（設置済み）だがNon-Operational（停止中）」のように、2つの状態を組み合わせると実態がつかめます。
実環境では、Life Cycle Stage / Life Cycle Stage Statusなど、より新しいライフサイクル管理用の項目や組織独自の運用ルールが関係する場合があります。cmdb_ciの2項目だけで運用の全体像が決まるわけではない点は、覚えておくとよいでしょう。
install_statusの選択肢は、次のURLで一覧できます。
https://<YourInstance>/sys_choice_list.do?sysparm_query=name=cmdb_ci^element=install_status^inactive=false^ORDERBYsequence
CI同士のつながりはcmdb_rel_ciに入っている
CMDBの価値は、CIを単体の台帳として持つだけでなく、属性・クラス・状態・関連を組み合わせて管理できる点にあります。CI同士の関連は、このサーバはどのアプリを載せ、どのサービスを支えているかという影響範囲や依存関係を読み解く手がかりです。
関連はcmdb_ciテーブルには保存されません。cmdb_rel_ci（CI Relationship）という専用テーブルに、1関連＝1レコードとして保存される仕組みです。基本になるのはparent（親CI）・child（子CI）・type（関連種別）の3つで、typeはcmdb_rel_typeを参照します。関連種別（cmdb_rel_type）は40種、関連レコード（cmdb_rel_ci）は238件ありました。
parentとchildはtypeとセットで読む
parent / childは単なる上下関係ではありません。relationship typeとセットで意味を持ちます。向きが命です。「Runs on」「Depends on」「Hosted on」など、関係種別によってどちらをparent / childに置くかが変わるため、関連を見るときはtypeの向きも確認します。
CIはasset（→alm_asset）で資産レコードと関連付けられる場合があります。ハードウェアなど資産管理の対象にもなるCIでは、構成の視点（cmdb_ci）と資産の視点（alm_asset）を分けて管理する設計です。すべてのCIがAssetと1対1に対応するとは限らず、アプリケーション・サービス・論理構成のように、資産管理とは別の観点で管理されるCIもあります。
CI関連は、次のURLで確認できます。
https://<YourInstance>/cmdb_rel_ci_list.do
公式のCI relationships in the CMDBにparent / child / typeの意味や関連種別の考え方が説明されています。
cmdb_ciを動かす周辺設定はどれくらいあるのか
cmdb_ciの動きは、フィールド定義だけでは決まりません。保存時の処理や権限など、複数の設定が組み合わさって動きます。大まかには、保存時や正規化の処理はBusiness Rule、操作はUI Action、権限はACLが関係します。
ここで数えているのはcmdb_ci（基底）に直接紐づく設定だけです。各サブクラス（cmdb_ci_serverなど）にも固有の設定があり、CIの挙動はそれらが合わさって決まります。基底だけを見て全体を判断しないようにします。
個々のBusiness RuleやUI Actionの中身までは今回は開いていません。それでも24件・26件という件数感を先に持っておくだけで、障害調査で読む範囲の見当がつきやすくなります。
ACLは名前の前方一致で数えると危険
理由は単純です。sys_security_aclのnameを前方一致（cmdb_ciSTARTSWITH）で絞ると、cmdb_ci_serverのようなサブクラス分まで拾ってしまい284件ヒットします。cmdb_ci自身に絞ったテーブルACLは22件、フィールドACLは1件です。テーブル名がそのままACLのnameになる設計のため、サブクラスごとにACLが個別定義されており、絞り込みはtype（record / field）とnameの完全一致で行う必要があります。
自分のインスタンスでは、次のURLで各一覧を開けます。
Business Rules : https://<YourInstance>/sys_script_list.do?sysparm_query=collection=cmdb_ci^active=true
UI Actions : https://<YourInstance>/sys_ui_action_list.do?sysparm_query=table=cmdb_ci^active=true
Access Controls: https://<YourInstance>/sys_security_acl_list.do?sysparm_query=name=cmdb_ci実機で気づいたこと
直接の子クラス102件のうち、CIレコードを実際に持つのは12件だけでした。残り90件は、cmdb_ci_group（グループ）やcmdb_ci_batch_job（バッチジョブ）のように名前は用意されているものの、この環境では1件も使われていません。空クラスの方が多数派です。最初は102という数字を見て、多様なCIが登録された環境を想像していました。実際のデータを見ると、102クラスの大半は「使われる可能性がある選択肢」にすぎず、実際に使われているクラスは一部でした。
差は歴然でした。もう1つ意外だったのが、cmdb_ci_spkg（Software、直接の子）1件のクラスだけで全体の63%を占めていた点です。2位のcmdb_ci_computer（Computer、直接の子ではない深い階層）を合わせると92%を超えます。つまりこの環境のCMDBは、「多様な102クラスに満遍なく分散している」のではなく、実質は2クラスに集中し、残りは細かく分岐した少数派という構図でした。障害調査でCMDBを見るなら、まずこの2クラスの中身から見た方が話が早いと考えられます。
cmdb_ci自体にも1件だけレコードがありました。どのサブクラスにも属さず、基底のままCIとして登録されていた例です。クラスの割り当てが漏れたか、暫定的に基底のまま作成したレコードだと考えられます。102クラスに加えて基底そのものも件数を持ち得る点は、グループ化して集計するときに見落としやすいところです。
ACLの数え方にも落とし穴がありました。sys_security_aclのnameを前方一致で絞ると、cmdb_ci以外のサブクラス分まで拾ってしまいます。テーブル名がそのままACLのnameになる設計だと分かっていないと、実際の10倍以上の件数を数えてしまう危険があります。
実務では何に使えるか
CMDBを引き継いだとき、あるいは既存のCMDBを見直すときは、cmdb_ciをsys_class_nameでグループ化した一覧を最初に開きます。件数を見れば一目瞭然です。件数の多いクラスと、レコードが1件も無いクラスがどちらも一目で分かるため、どのクラスから調査すればよいかの見当がすぐつきます。
ここからは別の話です。Discoveryや手動登録で新しいCIクラスを増やす計画があるなら、cmdb_ciの直接の子102クラスのうち、まだ0件のクラスに登録先が用意されているかを先に確認します。新規にクラスを作る前に、既存のクラス階層のどこかに近い場所が無いかを見ておくと、階層をむやみに増やさずに済みます。
CIの重複や棚卸しを検討するときは、特定クラスへの件数集中や、想定したクラスの0件放置がないかを、sys_class_name別の件数とcmdb_rel_ciの関連件数から確認します。今回のように関連が238件しかない環境では、CIどうしのつながりを辿る調査が難しくなるという結果でした。関連を増やす作業とCIを追加する作業のどちらを優先すべきかは、この2つの数字を見比べれば判断できます。
棚卸しや監査でACLの範囲を洗い出すときは、名前の前方一致に頼らず、type（record / field）とnameの完全一致で絞り込みます。cmdb_ciだけを見ているつもりが、実は数百件のサブクラス分まで含めていたという取り違えは、ACLの棚卸しでは特に起きやすいところです。集計条件を1つ間違えるだけで結果が10倍以上ぶれることを踏まえ、件数を報告する前に絞り込み条件を見直す習慣をつけておくと安全です。
意識することは、結局この3点に集約されます。sys_class_nameでいまどのクラスを見ているかを確認すること、直接の子と深い階層を混同しないこと、集計条件を絞りすぎたり緩めすぎたりしないことです。
さらに詳しく知りたい人へ
ServiceNowのフィールド設定はどこに保存される？ sys_dictionaryを実機で読む — cmdb_ciもsys_db_objectとsys_dictionaryの上に成り立っています。テーブル構造の読み方から見る記事です。
ServiceNowのCMDBは何がどこに入っている？ CI・関係・サービスを実機で数える — cmdb_ciだけでなく、CMDB全体をCI・関係・サービス・資産の4本の軸で見る記事です。
PCもサーバも束ねるComputer（cmdb_ci_computer） — 今回815件で2位だったcmdb_ci_computerを、さらに深い階層まで掘り下げます。
まとめ
結論は単純です。cmdb_ciはcmdb（基底）を継承しながら、直下に102の直接の子クラスを持つテーブルです。ただし102クラスのうち実データがあるのは12だけで、cmdb_ci_spkgとcmdb_ci_computerの2クラスだけで全体の92%を占めていました。CIを探すときは、cmdb_ci単体だけでなく、いま見ているsys_class_name・上位のcmdb・周辺のcmdb_rel_ci / alm_assetもセットで確認します。
用語
PDI … Personal Developer Instance（無料の検証用インスタンス）
OOTB … Out of the Box（初期設定のまま）
CI … Configuration Item（構成アイテム）
CMDB … Configuration Management Database（構成管理データベース）
クラス（sys_class_name） … そのCIが実際に属するサブテーブル名
Asset（alm_asset） … 資産管理の視点で管理するレコード（CIと1対1とは限らない）
実機で調べるときに開いたURL
sys_db_object_list.do?sysparm_query=name=cmdb_ci … テーブル定義
sys_db_object_list.do?sysparm_query=super_class.name=cmdb_ci … 直接の子クラス
sys_dictionary_list.do?sysparm_query=name=cmdb_ci^elementISNOTEMPTY … フィールド一覧
sys_choice_list.do?sysparm_query=name=cmdb_ci^element=install_status^inactive=false^ORDERBYsequence … install_status
cmdb_rel_ci_list.do … CI関連
cmdb_ci_list.do?sysparm_query=GROUPBYsys_class_name … クラス別の件数集計
参考リンク
検証環境と未検証範囲
確認した範囲（PDI／Zurich／2026-08-09確認）は次のとおりです。cmdb_ciの上下クラス階層（直接の子102・実データがあるクラス12）とフィールド数（cmdb_ci 81／cmdb 47）を確認しました。あわせて、install_status / operational_statusの選択肢と主要フィールドも確認済みです。cmdb_rel_ci / cmdb_rel_type・周辺設定件数・クラスごとのCI件数分布も確認しました。
確認していない範囲は、ライフサイクル関連の項目（Life Cycle Stage / Life Cycle Stage Status）です。各サブクラス固有の設定と内部スクリプトの挙動、Discovery / Service Mappingの動作も確認していません。CMDB Health / Identification & Reconciliation、CSDMの運用方針も確認の対象外です。本番環境やカスタマイズ済み環境では、クラス構成・フィールド・関連設定・件数の内容が異なります。
