サーバは5段継承でできている（cmdb_ci_server）

2026年6月28日 11:03

ServiceNow の CMDB を触っていると、サーバやデータベース、ネットワーク機器など「モノ」ごとに専用のテーブルが用意されていることに気づきます。その代表格が、サーバを表す cmdb_ci_server（画面ラベルは Server） です。OS や CPU、RAM といったサーバらしい項目がずらりと並ぶこのテーブルは、一見すると独立した大きなテーブルに見えます。

ですが実機で継承元をたどると、cmdb_ci_server はCMDB の中心テーブル cmdb_ciから生まれています。5段の継承チェーンを経て生まれた具象 CI クラスでした。PDI（Zurich / OOTB）で cmdb_ci_server を実際に開きます。どのフィールドがどのレベルで定義されているのか、cmdb_ci_server 自身が足すのはどれかを確認します。基底 cmdb_ci との役割分担も、件数やフィールド数の実測値とともに確認します。

この記事は、ServiceNow の画面操作には慣れたが、CMDB の CI クラスがどう積み上がっているのかをこれから整理したい管理者・開発者を想定しています。

この記事で分かること

cmdb_ci_server が cmdb → cmdb_ci → cmdb_ci_hardware → cmdb_ci_computer → cmdb_ci_server の

5段で継承された具象クラスであること

フォームに並ぶ 112フィールドのうち、cmdb_ci_server 自身が定義するのはわずか5つで、残りは祖先からの継承であること
os / cpu_count / ram / disk_space などは「サーバ固有」ではなく cmdb_ci_computer（Computer）由来であること
PDI 実機のサーバ40件のクラス別・OS別の内訳
cmdb_ci_server の下にある Windows / UNIX / Linux などのサブクラスの構造
基底 cmdb_ci と具象クラス cmdb_ci_server の役割分担

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、フィールド構成・件数・OS の分布が異なります。

サーバ CI クラス cmdb_ci_server とは

cmdb_ci_server は、サーバという構成アイテム（CI）を1台＝1レコードで記録する具象テーブルです。アプリナビゲーターから「Configuration > Servers」を開くと、PDI（Zurich / OOTB）にはすでに何台ものサーバが登録されています。下の画面は、その一覧を sys_class_name（クラス）でグループ化したものです。

PDI のサーバ CI はサブクラスを含めて 合計40件でした。同じ「サーバ一覧」の中に Server・Windows Server・UNIX Server・Linux Server といった複数のクラスが混在しています。これは cmdb_ci_server が単なる1テーブルではなく、その下にさらに細かいクラスを持つクラス階層の節（ノード）であることを示しています。

cmdb_ci_server は5段の継承でできている

cmdb_ci_server の継承元（super_class）を実機で上方向にたどると、次の5段のチェーンになっていました。

cmdb（Base Configuration Item） … super_class が空のルート基底テーブル
cmdb_ci（Configuration Item） … すべての CI の共通項を持つCMDB の中心テーブル
cmdb_ci_hardware（Hardware） … 物理ハードウェア共通の層
cmdb_ci_computer（Computer） … PC・仮想マシン・サーバなど「計算機」共通の層
cmdb_ci_server（Server） … サーバの具象クラス

実機でテーブル定義（sys_db_object）を開くと、cmdb_ci_server の Extends table（継承元）が Computer になっていることが確認できます。

つまり cmdb_ci_server は、祖先が積み上げてきた共通項の上に、サーバ固有の項目を足しただけのテーブルです。この積み上げの考え方は、incident が task を継承するのと同じです。継承元のフィールド定義を子テーブル側で上書きする仕組みについては辞書オーバーライド（sys_dictionary_override）の記事も参考になります。

フィールドの大半は「継承」されたもの

各レベルがそのレベルで足す固有フィールド数を実測すると、積み上げの構造がはっきりします。

cmdb_ci_server のフォームには 累計112個のフィールドが並びます。内訳は cmdb が47・cmdb_ci が34・hardware が5・computer が21、そして cmdb_ci_server 自身はわずか5個です。実機で sys_dictionary を name=cmdb_ci_server で絞ると112件が並びます。これは継承分を含む累計で、cmdb_ci_server 自身が定義するのはこのうち5件です。

「サーバの情報」に見えるフィールドの多くは、実は cmdb_ci_server のものではありません。下の図は、1枚のサーバフォームに並ぶ項目が、どのレベル由来かを色分けしたものです。

代表的なフィールドの出どころを整理すると、次のようになります。

os / os_version / cpu_count / cpu_core_count / ram / disk_space / virtual

… これらは cmdb_ci_computer（Computer）由来。PC や仮想マシンとも共有される「計算機」共通の項目で、サーバ固有ではありません。

ip_address / dns_domain / fqdn / mac_address / operational_status … cmdb_ci 由来のネットワーク・状態系。
name / install_status / location / company / serial_number / asset（→ alm_asset）

… cmdb（基底）由来の最も共通の項目。

cmdb_ci_server が自身で足すのは5つだけです。

内訳は classification / used_for / host_name / firewall_status / dr_backup です。classification の既定は Production で、選択肢は Production・Critical Infrastructure・Disaster Recovery など6種です。

OS や CPU を「サーバの属性」と思い込みがちですが、実機で見るとそれらは1つ上の Computer 層の共通項です。cmdb_ci_server はあくまで「サーバならではの分類（classification）や DR バックアップ（dr_backup）」を追加しているだけ、というのが正確な姿です。

サーバ1台のフォームを実機で見る

実際にサーバ CI を1件開くと、ここまで見た継承の積み上げが1枚のフォームに収まっているのが分かります。下は「Service-now Production Sacramento」（クラス＝Server、OS＝Linux Red Hat、classification＝Production）のレコードです。

なお PDI の OOTB サンプルでは、host_name や ip_address が空のサーバが多いです。これらは通常 Discovery（自動検出）が投入する項目で、OOTB のデモデータには入っていないためと考えられます（Discovery の具体的な動作は検証範囲外）。RAM は整数（MB）で、未取得を表す -1 が入っているレコードもありました。

cmdb_ci_server の下にあるサブクラス

cmdb_ci_server 自身も、さらに細かいサブクラスを持つ親クラスです。実機で super_class.name=cmdb_ci_server を数えると、16個の直接サブクラスがありました。

代表的なものは cmdb_ci_win_server（Windows Server）・cmdb_ci_unix_server（UNIX Server）です。ほかに cmdb_ci_linux_server（Linux Server）もあります。ほかに cmdb_ci_virtualization_server（Virtualization Server）・cmdb_ci_lb（Load Balancer）などもあります。さらに UNIX Server の下には AIX Server のような、もう一段深いクラスも存在します。

PDI 実機のサーバ40件を、クラス別・OS別に数えると次のとおりでした。

40件のうち 19件がクラスそのもの（Server）で、残り21件は Windows / UNIX / Linux などのサブクラスに属していました。OS 別では Linux Red Hat（9件）・Windows 2003 Standard（8件）・Windows XP（7件）が上位で、OOTB のデモデータは少し古めの OS が中心です。実機でサーバ一覧を os でグループ化すると、この内訳がそのまま確認できます。

同じ「サーバ」でも、より具体的な種別はサブクラスで表現される、という CMDB のクラス設計がよく分かります。

基底 cmdb_ci との役割分担

基底 cmdb_ci と具象クラス cmdb_ci_server の関係を見ます。

cmdb_ci（基底） … すべての CI に共通する「構成の視点」を定義する中心テーブル。クラス階層・状態（install_status / operational_status）を担当します。CI 関連（cmdb_rel_ci）といった、CI 全般に効く枠組みも担当します。
cmdb_ci_server（具象クラス） … その枠組みを継承したうえで、サーバという「モノ」を表す具体的な器。OS・CPU・RAM（実体は Computer 層）に、サーバ固有の分類や DR 設定を足して、1台のサーバを記録します。

ざっくり言えば、cmdb_ci は「CI とは何かを決める設計図」、cmdb_ci_server は「その設計図に沿って作られたサーバ用の実物」です。サーバだけでなく、データベース・ネットワーク機器もあります。業務サービス（cmdb_ci_service）も同様です。cmdb_ci を継承した具象クラスとして並んでいます。CMDB を読むときは、まず「どのクラスか（具象）」を見て、足りない共通項は「継承元（基底）まで遡る」と、フィールドの意味が一気に腑に落ちます。

実機で確認するときに見るべきURL

今回見た画面を自分のインスタンスで開くためのURLをまとめます（<YourInstance> は置き換えてください）。

# サーバ一覧をクラスでグループ化
https://<YourInstance>/cmdb_ci_server_list.do?sysparm_query=GROUPBYsys_class_name

# サーバ一覧をOSでグループ化
https://<YourInstance>/cmdb_ci_server_list.do?sysparm_query=GROUPBYos

# cmdb_ci_server のフィールド定義（継承を含む累計112件・自身の定義は5件）
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=cmdb_ci_server^elementISNOTEMPTY

# cmdb_ci_server のテーブル定義（Extends=Computer を確認）
https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=cmdb_ci_server

まとめ

cmdb_ci_server は cmdb → cmdb_ci → cmdb_ci_hardware → cmdb_ci_computer → cmdb_ci_server の

5段継承でできた具象 CI クラス。

フォームの 112フィールドのうち、cmdb_ci_server 自身が足すのは5つだけ。

内訳は classification / used_for / host_name / firewall_status / dr_backup。

os / cpu / ram / disk は cmdb_ci_computer 由来。

ip_address / operational_status は cmdb_ci 由来、name / install_status は cmdb 由来。

PDI 実機のサーバは40件で、19件が Server クラスそのもの、残りは Windows / UNIX / Linux などサブクラス。
基底 cmdb_ci は「CI の設計図」、cmdb_ci_server は「サーバ用の実物」。役割が違う。

サーバ CI の構造が分かると、CMDB の中心テーブル cmdb_ci・CI 関連（cmdb_rel_ci）・サービス系テーブル（cmdb_ci_service）・資産管理（alm_asset）が、「基底で枠を決める → 具象クラスでモノを表す → 関連でつなぐ → 資産と対にする」という流れでつながって見えてきます。

ServiceNowのCMDBは何がどこに入っている？ CI・関係・サービスを実機で数える — cmdb_ci_server を含む CMDB 全体の CI・関係・サービスの件数感を実機で確認できます。