サービスもCIになる（cmdb_ci_service）

ServiceNow の CMDB を調べていくと、サーバや PC のような「モノ」の CI だけが登録されているわけではないと気づきます。「Email」「SAP Payroll」といったサービスも CI として登録されています。これらは cmdb_ci_service というテーブルに入り、その下を支えるサーバやデータベースとひも付いています。

サービスは、cmdb_ci（全 CI の基底）を継承する cmdb_ci_service を起点にします。そこから Business Service / Technology Management Service / Application Service という種別へ分かれます。CSDM（Common Service Data Model）は、このサービスの種別と関連をそろえるための共通の枠組みです。

この記事は、ServiceNow の Incident や cmdb_ci は触ったことがある管理者・開発者を想定しています。サービス系テーブル（cmdb_ci_service と svc_ci_assoc、それに CSDM のアプリケーションサービス）をこれから理解したい人です。実際の cmdb_ci_service を起点に、上位の cmdb_ci、下位の種別テーブル、サービスと CI の紐づけ方を順に確認します。

この記事で分かること

• cmdb_ci_service が cmdb_ci を継承し、その下に5つの種別テーブルを持つこと

• service_classification（Business / Technology Management / Application）の3種別

• 「サービス＝CIの集合」を、この PDI では cmdb_rel_ci の Depends on で表していたこと

• svc_ci_assoc（Service CI Association）の構造と、今回 0 件だった事実

• cmdb_ci_service が持つ主な参照フィールドと周辺設定の件数

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

サービスをCIとして持つということ

CMDB は、サーバやネットワーク機器のような物理的な「モノ」だけを CI にするわけではありません。「Email」「SAP Payroll」のような業務サービスも、cmdb_ci_service というテーブルに 1 レコードずつ登録され、CMDB の一員になります。

サービスを CI にすると、そのサービスが「どのサーバやデータベースに支えられているか」を CMDB の関連としてたどれます。インシデントや変更が起きたとき、影響を受けるサービスを構成から判断できるのは、サービスもまた CI として関連を持っているからです。

ServiceNow では、この「サービスをどう定義し、どんな種別に分け、何と関連づけるか」を組織間でそろえるための枠組みを CSDM（Common Service Data Model）と呼びます。CSDM は新しいテーブルというより、cmdb_ci_service を中心とした既存テーブルの使い方を標準化する考え方です。

cmdb_ci_service はサービスの基底テーブル

cmdb_ci_service は、全 CI の基底である cmdb_ci を継承し、その下に種別ごとのテーブルを持ちます。

今回確認した PDI（Zurich / OOTB）では、cmdb_ci_service（label: Service）は cmdb_ci を継承していました。そして cmdb_ci_service の直接の子クラスは5件で、内訳は次のとおりです。

• cmdb_ci_service_business（Business Service）

• cmdb_ci_service_technical（Technology Management Service）

• service_offering（Offering）

• cmdb_ci_service_group（Application Service Group）

• cmdb_ci_service_auto（Service Instance）

さらに cmdb_ci_service_auto（Service Instance）の下に続きがあります。cmdb_ci_service_discovered（Mapped Application Service）と cmdb_ci_query_based_service（Dynamic CI Group）です。CSDM でいう「アプリケーションサービス」は、この cmdb_ci_service_discovered にあたります。Service Mapping や Discovery が自動生成するアプリケーションサービスはここへ入りますが、手動で登録することもできます。自動生成の挙動は今回の検証範囲外です。

固有フィールドの数は cmdb_ci_service が113でした。cmdb_ci の共通項目（name / sys_class_name / install_status / operational_status など）があります。そこにサービス固有の項目を加えた構成になっています。

階層は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_db_object_list.do?sysparm_query=super_class.name=cmdb_ci_service

サービスの種別（service_classification）

cmdb_ci_service のレコードは、service_classification というフィールドで種別を表します。テーブルとしては cmdb_ci_service_business のように分かれていますが、種別の値そのものは service_classification の選択肢で持ちます。

今回の PDI（Zurich / OOTB）の選択肢は3つでした。

• Business Service … 利用者・顧客から見た業務サービス。「Email」「Finance」のように、IT 視点ではなく使う側の言葉で表します。

• Technology Management Service（値は Technical Service）… IT 運用チームが支える基盤サービス。Active Directory や Exchange のような、業務サービスを下支えする IT サービスです。

• Application Service … アプリケーション1スタックの論理的な表現。Web・アプリ・DB といった構成要素のまとまりを1つのサービスとして表し、テーブルとしては cmdb_ci_service_discovered に対応します。

公式の Application services（Zurich） に、アプリケーションサービスの位置づけが説明されています。Technology Management Service の扱いは Manage Technical Services domain of the CSDM framework（Zurich） にまとまっています。

選択肢は、次のURLで一覧できます。

https://<YourInstance>/sys_choice_list.do?sysparm_query=name=cmdb_ci_service^element=service_classification^inactive=false^ORDERBYsequence

サービスがCIを束ねる仕組み（cmdb_rel_ci）

サービスは「CIの集合」として、配下のサーバやデータベースとつながります。実際の Service フォームを開くと、その関連が Related Items に並びます。

上の SAP Payroll の例では、Depends on で Windows Server やデータベースにひも付いています。Contained by では親サービス（SAP Enterprise Services）にひも付いています。この関連は cmdb_ci_service の中ではなく、cmdb_rel_ci（CI Relationship）に parent / child / type の組で保存されます。サービスとサーバの間に1関連＝1レコードが入る形です。

サービスの実クラス（sys_class_name=Service）が parent になっている関連を数えると、今回の PDI では116件ありました。種別の内訳は次のとおりです。

Depends on::Used by が93件と多い結果でした。サービスが Windows Server / Web Server / Network Gear / Database へ依存する形が中心です。Contains::Contained by の16件は、SAP Enterprise Services が SAP Payroll などの子サービスを束ねる、サービス同士の入れ子です。

子CI（child）のクラス内訳（116件）

• Service … 32（サービス同士の入れ子）

• Windows Server … 26

• Web Server … 25

• Network Gear … 12

• UNIX Server … 4

• Database … 3

• そのほか（Email Server / Server / Linux Server / Computer など）… 10

• 空（クラス不明）… 4

関連を読むときは type の向きに注意します。Depends on::Used by は「parent が child に依存する」という意味です。Contains::Contained by は「parent が child を含む」という意味で、どちらを parent に置くかが種別ごとに決まっているためです。サービスを起点に依存先をたどるには、parent がサービスの関連を見ます。

サービスが親の関連は、次のURLで確認できます。

https://<YourInstance>/cmdb_rel_ci_list.do?sysparm_query=parent.sys_class_name=cmdb_ci_service

公式の CI relationships in the CMDB（Zurich） に、parent / child / type の意味と関連種別の考え方が説明されています。

svc_ci_assoc（Service CI Association）とは

サービスと CI の紐づけには、cmdb_rel_ci とは別に svc_ci_assoc（Service Configuration Item Association）という専用テーブルもあります。こちらは「どのサービスがどの CI を含むか」を service_id と ci_id の組で1行ずつ持つ、関連専用の表です。

svc_ci_assoc の主なフィールドは service_id（→cmdb_ci_service）・ci_id（→cmdb_ci）・ignore_errors の3つです。残りは sys_ 系のメタ項目です。cmdb_ci_service を継承するのではなく、独立したテーブルとして定義されています。

注意したいのは、今回の PDI（Zurich / OOTB）では svc_ci_assoc のレコードが 0 件だった点です。デモデータのサービスは、配下の CI を svc_ci_assoc ではなく cmdb_rel_ci の Depends on / Contains で表していました。svc_ci_assoc は、サービス定義のインポートなど別の取り込み経路で書き込まれるテーブルで、初期データでは空のままだと考えられます。実際にどの機能が svc_ci_assoc を書き込むかは今回の検証範囲外です。

サービスと CI の紐づけを調べるときは、まず Service フォームの Related Items（中身は cmdb_rel_ci）を見ます。svc_ci_assoc は別経路として分けて確認します。

svc_ci_assoc は、次のURLで開けます。

https://<YourInstance>/svc_ci_assoc_list.do

サービス系テーブルとレコード件数

サービス系のテーブルは種別ごとに分かれていますが、今回の PDI では実データの多くが基底の cmdb_ci_service に入っていました。

cmdb_ci_service の42件を実クラス（sys_class_name）で見ると、Service が41件、Application Service Group が1件でした。Business Service や Technology Management Service の専用テーブル（cmdb_ci_service_business / cmdb_ci_service_technical）はいずれも0件でした。種別を分けるよりも基底のテーブルにまとめて入っている状態です。service_classification が設定済みのレコードも2件のみです。

cmdb_ci_service の主な参照フィールド

サービスらしい項目が並びます。

• 階層・分類：parent（→cmdb_ci_service・親サービス）, spm_service_portfolio（→Service Portfolio）, life_cycle_stage / life_cycle_stage_status, business_unit

• 担当：user_group（Users supported）, owned_by, managed_by, supported_by

• 契約：sla（→Agreement）

• ガバナンス：change_control（Approval group）, attested_by

サービスを「誰が持ち、どのポートフォリオに属し、どんな SLA を結ぶか」まで CI のフィールドで表せる作りになっています。

cmdb_ci_service に関わる周辺機能

cmdb_ci_service の動きも、フィールド定義だけでは決まりません。保存時の処理や権限など、複数の設定が組み合わさって動きます。

今回確認した PDI（Zurich / OOTB・active 中心・2026-06-22 確認）では、cmdb_ci_service に次のような設定が直接紐づいていました。

ほかに Client Script が3件、UI Policy が1件、Choice が48件ありました。Notification（sysevent_email_action）は0件です。

ここで数えているのは cmdb_ci_service（基底）に直接紐づく設定だけです。各サービス種別の挙動や、cmdb_ci 側の共通設定も合わさって最終的な動作が決まるため、基底だけを見て全体を判断しないようにします。

自分のインスタンスでは、次のURLで各一覧を開けます。

Business Rules : https://<YourInstance>/sys_script_list.do?sysparm_query=collection=cmdb_ci_service^active=true
UI Actions     : https://<YourInstance>/sys_ui_action_list.do?sysparm_query=table=cmdb_ci_service^active=true
Access Controls: https://<YourInstance>/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHcmdb_ci_service

ServiceNow のサービス系テーブルのポイント

• cmdb_ci_service は cmdb_ci を継承するサービスの基底テーブルです。直接の子クラスは5件（Business Service / Technology Management Service / Offering / Application Service Group / Service Instance）でした。

• 種別は service_classification の3値（Business Service / Technology Management Service / Application Service）で表します。Application Service はテーブルとしては cmdb_ci_service_discovered に対応します。

• サービスと配下 CI の紐づけは、この PDI では cmdb_rel_ci の Depends on / Contains で表されていました。Service クラスが親の関連は116件で、Depends on::Used by が93件と中心でした。

• svc_ci_assoc（service_id / ci_id）はサービスと CI を紐づける専用テーブルですが、今回の PDI では0件でした。書き込む機能は検証範囲外です。

• 今回の PDI のサービスは42件で、実クラスは Service が41件。種別専用テーブルは0件で、基底にまとめて入っていました。

サービスを調べるときは、まず Service フォームの Related Items（中身は cmdb_rel_ci）で依存先をたどります。種別は service_classification で確認し、svc_ci_assoc は別経路として分けて見ます。

実機を見て気づいたこと

• 重要度を表すフィールドは business_criticality と書きたくなりますが、実機のフィールド名は busines_criticality と s が1つ欠けたスペルでした。選択肢は most critical / somewhat critical / less critical / not critical の4段階です。

• 子クラスは5つ用意されているのに、実データが入っていたのは基底の cmdb_ci_service（Service）と Application Service Group だけでした。型は用意されていても、Discovery や Service Mapping のような自動生成の仕組みが動いていない環境では、種別テーブルは空のままになるようです。

次に読むなら

次に確認するなら3つあります。cmdb_ci_service_discovered（アプリケーションサービス）の固有フィールド。Service Mapping / Discovery がアプリケーションサービスをどう自動生成するか。そして CSDM の各ドメイン（Foundation / Design / Manage Technical / Sell-Consume）でサービスをどう配置するかです。これらは本記事で確認した「サービスの種別」「サービスがCIを束ねる仕組み」の先にあたり、別記事で確認していきます。基底の cmdb_ci 側の構造は、前回の記事（cmdb_ci のクラス階層・状態・CI関連）で確認しています。

用語

• PDI：Personal Developer Instance（無料の検証用インスタンス）

• OOTB：Out of the Box（初期設定のまま）

• CI：Configuration Item（構成アイテム）

• CSDM：Common Service Data Model（サービスの種別と関連をそろえる共通枠組み）

• サービス（cmdb_ci_service）：業務・技術・アプリのサービスを表す CI

• アプリケーションサービス：アプリ1スタックの論理表現（cmdb_ci_service_discovered）

自分の環境で確認するときのURL

先頭に自分のインスタンスを付けると、同じ画面が開けます。

テーブル定義          : sys_db_object_list.do?sysparm_query=name=cmdb_ci_service
直接の子クラス         : sys_db_object_list.do?sysparm_query=super_class.name=cmdb_ci_service
種別の選択肢           : sys_choice_list.do?sysparm_query=name=cmdb_ci_service^element=service_classification^inactive=false^ORDERBYsequence
サービス一覧           : cmdb_ci_service_list.do?sysparm_query=ORDERBYname
サービスが親の関連      : cmdb_rel_ci_list.do?sysparm_query=parent.sys_class_name=cmdb_ci_service
サービスCI紐づけ        : svc_ci_assoc_list.do

関連記事

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

検証範囲とおことわり

確認した範囲（すべて PDI／Zurich／2026-06-22 確認の OOTB で取得）:

• cmdb_ci_service の上下クラス階層と直接の子クラス5件

• 固有フィールド数（113）

• service_classification / busines_criticality の選択肢

• svc_ci_assoc の構造とレコード件数（0）

• 主要参照フィールド

• レコード件数（cmdb_ci_service 42・実クラス内訳）

• サービスが cmdb_rel_ci で CI を束ねる実態（Service クラスが親の関連116件）

• 周辺設定件数

確認していない範囲（断定しません。これらは別記事で確認します）:

• Service Mapping / Discovery によるアプリケーションサービスの自動生成挙動

• svc_ci_assoc を実際に書き込む機能

• CSDM の各ドメイン（Foundation / Design / Manage Technical / Sell-Consume）の運用方針

• サービスマップ（Dependency Views）のUI動作

• life_cycle_stage の運用ルール

• 各サービス種別テーブルの固有フィールド