CSDMとは？ServiceNow共通サービスデータモデルの7ドメイン・CMDBとの違い・導入手順【CSDM 5】

CSDM（Common Service Data Model／共通サービスデータモデル）は、ServiceNowが「CMDBのどのテーブルに何を入れ、どの関係でつなぐか」を定めたデータモデルの規範です。最新版はCSDM 5で、2025年5月のホワイトペーパー公開でドメインが7つになりました。本記事では、CMDBとの違い、7ドメインと主なテーブル、経費精算システムを例にしたモデルの組み方、Foundation・Crawl・Walk・Run・Flyの導入段階、ライフサイクル値の移行とダッシュボードでの点検までを、ServiceNowの公式ドキュメントとCSDM 5ホワイトペーパーに沿って説明します。

まとめ：CSDMの要点（CSDM 5）

• CSDMとは：ServiceNow製品がCMDBのデータを同じ意味で読むための規範。製品名ではなく、テーブルと関係の使い方を決めたガイドライン。
• CMDBとの違い：CMDBは構成アイテム（CI）を入れるデータベース、CSDMはそのCIをどのクラスに置き、どう関連づけるかのルール。CSDMはCMDBを置き換えない。
• 最新バージョン：CSDM 5（ホワイトペーパーは2025年5月6日にServiceNow Communityで公開）。CSDM 4から約4年ぶりの改訂で、2026年9月更新の公式ドキュメントもCSDM 5の構成。
• ドメインは7つ：Foundation、Ideation & Strategy（CSDM 5で新設）、Design & Planning、Build & Integration、Service Delivery、Service Consumption、Manage Portfolio。
• 最初に作るのは4種類：Business Application、Service Instance、Application、サーバー。これでインシデント管理と変更管理に必要な最低限がそろう（Crawl段階）。
• 最大の分かれ目：アプリの台帳（Business Application）と、障害時に選ぶ稼働中の実体（Service Instance）を分けること。
• 進み具合はダッシュボードで測る：CSDM Data Foundations Dashboardが「関係の欠落」などを段階別に数える。

CSDMの定義：CMDBの使い方を決めるServiceNowの規範

ServiceNowの公式ドキュメントは、CSDMを「管理者がServiceNow製品とアプリケーションを設定するときに従うべきデータモデル」と定義しています。読みは「シー・エス・ディー・エム」。CMDBを使うすべてのServiceNow製品がこのモデルを前提に作られており、ドキュメントはそれらを「CSDM準拠（CSDM-conforming）」と呼びます。

CSDMは有償製品ではなく、ホワイトペーパーとドキュメントで示される設計指針です。基本テーブルはベースシステムに含まれますが、Ideation & Strategyのように追加のプラグインやストアアプリが必要なデータモデルもあります。CSDMに従うとは、標準のテーブルと関係を基本に、定義された意味に沿ってデータを配置することです。拡張を一律に禁じるものではありません。ServiceNowそのものの製品構成はServiceNowの機能と強みの解説にまとめています。

CSDMとCMDBの違い

CMDBは「何があり、何と何がつながっているか」を記録する器です。CSDMは、その器の中で「業務アプリの台帳はcmdb_ci_business_appに置く」「実際に動くアプリはService Instanceとして表す」といった配置と関係を決めます。CSDMの概念とCMDBテーブルの対応（公式）も、Business Applicationのデータはcmdb_ci_business_appテーブルに置くと明記しています。CMDBそのものの仕組みと導入判断はCMDBの仕組みとITILとの関係の解説を参照してください。

CSDMとITILの関係

CSDMはITILの代わりになるプロセス体系ではありません。ServiceNowの日本語ドキュメントは、CSDMにおける「サービス」の定義がITIL v3とIT4ITのサービスの基本定義と一致していると明記しています。ITILが「インシデントや変更をどう扱うか」を決め、CSDMは「そのとき選ぶサービスやCIがCMDBのどこにあるか」を決める、という分担です。ITILとITSMの関係はITSMとITILの違いの解説で扱っています。

CSDMに沿うと製品ごとに変わること

CSDMの恩恵を受ける製品の一覧（公式）は、CSDMに沿ったCMDBで製品ファミリーごとに次の指標が改善するとしています。

どの行も、CIとサービスの関係がそろっていることが前提です。セキュリティ部門が脆弱性の優先順位を業務重要度で付けたいなら、その脆弱なサーバーがどのService Instanceを経てどの業務サービスにつながるかが、CMDB上でたどれなければなりません。

CSDMのバージョン：CSDM 4からCSDM 5への変更点

CSDM 5のホワイトペーパーは、2025年5月6日にServiceNowのScott Lemm氏がCommunityに投稿した記事「CSDM 5 Finally!!!」で公開されました。本体は63ページで、同ページの最終更新は2025年6月16日（リンクを修正した版の差し替え）です。2026年9月10日更新のBrazil版ドキュメントもCSDM 5の7ドメイン構成で書かれており、2026年10月時点で公式が示す最新版はCSDM 5です。

CSDM 5で追加・変更された要素

CSDM 5ホワイトペーパー（ServiceNow Communityの公開ページ）の「What is new in CSDM 5?」が挙げる変更点です。

• Ideation & Strategyドメインの新設
• SBOM（ソフトウェア部品表）、System Component Model、Software Component Model、Service Offering Model、Product Featureの追加。SBOMのデータモデルはストアアプリ「SBOM Core（sn_sbom_core）」で提供
• 業務プロセスモデルを拡張したValue Stream
• 1つのCIに複数の担当グループを持たせるTeams
• 定義つきのライフサイクルStageとStage Status
• DevOps Change data model（アプリストアで提供）、Service InstanceとAIのCIクラス（モデルのみ）
• テーブルラベルの変更（Technology Management Service、Technology Management Service Offering、Service Instance）

実装で影響が大きいのはラベル変更です。旧Technical Serviceは「Technology Management Service」（テーブルはcmdb_ci_service_technicalのまま）、旧Application Serviceは「Service Instance」と表示されます。CSDM 4時代の資料を読むときは、名前が違うだけで同じテーブルを指している点に注意してください。

関係の種類も変わりました。CSDMのCI関係を定めた公式ドキュメントによると、CSDM v5はBusiness ApplicationとApplication ServiceをUses::Used Byで結び、以前の版はConsumes::Consumed Byでした。ただしEnterprise Architecture Workspaceの利用者は、TLMとTRMのライフサイクルのタイムラインを正しく表示するためにConsumes::Consumed byを使い続けるよう注記されています。

CSDM 4と5のドメイン対応

ホワイトペーパーは、Manage Portfolioを「以前の5つのドメイン（foundation、design、build、manage technical services、sell/consume）の一部にまたがる概念」と説明しています。「CSDMのドメインは5つ」と書く資料はCSDM 4の数え方で、現行の数え方は7つです。

CSDM 5の7ドメインと主なテーブル

ドメインは、CIと参照データを含むデータモデルの要素を、責任範囲と製品・サービスの種類に応じてまとめた区分です。日本語ドキュメントでは基盤ドメイン、サービスデリバリドメイン、サービス消費ドメインなどと訳されています。

Foundationは他のドメインが参照する基盤データで、会社（core_company）、部署、ユーザーとグループ、ロケーション、契約、製品モデルなどを含みます。Ideation & StrategyはStrategic Portfolio Management（SPM）の計画項目と製品アイデアを扱います。Design & Planningはエンタープライズアーキテクトが扱う業務ケイパビリティ、ビジネスアプリケーション、情報オブジェクト（cmdb_ci_information_object）の置き場所です。

Service Deliveryは実際にサービスを提供する仕組みで、Service Instance、Technology Management ServiceとそのOffering、Dynamic CI Group（cmdb_ci_query_based_service）、サーバーなどのインフラCIが入ります。Service Consumptionは利用者から見たビジネスサービスと、その提供条件を定めるBusiness Service Offering、要求カタログです。Manage Portfolioのサービスポートフォリオには、Business ServiceとTechnology Management Serviceがspm_taxonomy_node経由でつながります。

運用CIと非運用CIの境界

ドキュメントはIdeation & Strategy、Design & Planning、Build & IntegrationのCIについて、運用CIではないためインシデント管理・問題管理・変更管理で選択できないと明記しています。インシデントや変更の対象になるのは、Service Delivery側のService InstanceやTechnology Management Service、Service Consumption側のBusiness Serviceです。

この境界が崩れると影響分析が効きません。障害の起票時にビジネスアプリケーションを選ぶ運用にすると、そのアプリがどの環境（開発・検証・本番）のどのサーバーで動いているかをたどれないためです。インシデント起票側の設計はITIL準拠のインシデント管理プロセスの解説とあわせて検討してください。

アプリケーションを表す4つのエンティティ

ホワイトペーパーは、アプリケーション関連のデータを台帳・開発部品・展開した実体・実行プロセスの4つに分けて扱います。

Business Applicationはアプリの台帳（ポートフォリオ）で、版にも環境にも依存しません。Service Instanceは、そのアプリを環境や地域ごとに展開した実体で、利用者が「経費精算システムが動かない」と連絡してきたときに選ばれるのはこちらです。Applicationは1台のホスト上で動く実行プロセスで、ホワイトペーパーは「アプリケーションの台帳ではない」と注意しています。1つのApplication（たとえばデータベースのインスタンス）が複数のService Instanceを支えることもあるため、ApplicationとService Instanceは1対1になりません。

CSDMのモデル例：経費精算システムのドメイン別配置

CSDMでは、1つの業務システムを台帳・稼働環境・提供サービスなどの観点に分け、複数のドメインに記録します。説明用の例として、社内の経費精算システムを置くと次のようになります（レコード名は例です）。

ポイントは3つの線です。1本目は、台帳の「経費精算システム」と環境ごとの「経費精算 本番」「経費精算 検証」をUses::Used Byで結ぶ線で、これでアプリ1つに本番と検証の2つの実体がぶら下がります。2本目は、Service Instanceの下に実際のTomcatやDBのサーバーをつなぐ線で、Service MappingかDynamic CI Groupで作ります。3本目は、業務側の「経費精算サービス 国内社員向け」とService Instanceをつなぐ線で、この関係は業務への影響をたどる基盤になります。インシデント画面への反映には、対象CIの登録、関連リストとプロパティの設定、影響サービスの更新処理（Refresh impacted services）が必要で、利用者の特定にはOfferingの購読情報なども必要です。

サーバーのサポートグループは、サーバー1台ずつではなく「Linuxサーバー運用 東京」のOfferingに設定し、Dynamic CI Groupで束ねたCIへ同期させます。Dynamic CI Groupと種別の公式解説によると、Technology Management Service用のDynamic CI Groupは10,000件の類似CIを束ねる構成が公式に説明されています。基になるCMDB Groupの件数上限は既定で10,000件で、glide.cmdb.group.max_ci_limitプロパティにより変更できます。手動でCIを関連づける場合、ホワイトペーパーは「Discoveryならどう作るか（WWDD：what would discovery do?）」を基準にするよう求めています。

この例でIdeation & StrategyやBuild & Integrationが空欄なのは誤りではありません。SPMで投資計画を管理していない、DevOpsでコンポーネントを管理していない組織は、そのドメインを後回しにできます。

Foundation・Crawl・Walk・Run・Flyの導入段階

ServiceNowはCSDMの全要素を一度に実装することを推奨していません。ホワイトペーパーとドキュメントは、Foundation、Crawl、Walk、Run、Flyの5段階で範囲を広げる方法を示しています。

Foundationについて、ホワイトペーパーは「レポートやワークフローの要件の多くはCIそのものより参照データに依存する」と述べています。組織構造は変わりやすいので、どこから取り込み、誰が保守するかを先に決めます。

Crawlはアプリケーションに絞った段階で、前章の例でいえば台帳、環境ごとの実体、TomcatやDB、サーバーをそろえる範囲です。SDLC Componentはこの段階では任意です。Walkでは技術チームが支えるサービスをTechnology Management ServiceとOfferingで表し、数千台のCIにサポートグループを手で入れる作業をOffering側からの同期に置き換えます。

Runでは、技術サービスと、それを消費・販売する業務側のBusiness Serviceを関係づけます。Offeringの「Subscribe by」で利用者、会社、ロケーション、部署、グループ単位の影響範囲も特定できるようになります。Flyでは業務ケイパビリティと情報オブジェクトを加え、アプリやサービスへの投資の過不足を評価します。情報オブジェクトはPII・PCI・HIPAAなどのデータ分類に使うため、要件次第で早い段階に実装してよいと公式も注記しています。

ServiceNowでCSDMを始める手順

ライフサイクル値のマッピングとプラグインの有効化

CSDMの機能はcom.snc.cmdb.csdm.activationプラグインで有効化します。CSDMプラグインの有効化ページに記載された必要ロールはitilとitil_adminです。同ページは、有効化の前に既存のライフサイクルデータをCSDM標準の属性へマッピングするよう求めています。これを飛ばすと、CMDB Data Managerで資産のライフサイクル遷移を追跡できません。

CSDMのライフサイクルは、Life Cycle Stage（大きな段階）とLife Cycle Stage Status（段階内の状態）の2つの値の組で表します。物理CIのライフサイクル定義（公式）の主な組み合わせは次のとおりです。

従来のInstall StatusやOperational Statusなどの値は、プラグインの手順に沿うと自動でこの組へ対応づけられます。自動更新されるレガシー値の一覧に載っているのは、Product Model Status、Asset State／Substate、Contract Status、CI Install Status、CI Operational Status、CI Hardware Status／Substatusで、対応づけた後も元の値は削除されません。独自の状態値を作っている場合は、対応ルールを持つlife_cycle_mappingテーブルに自分でルールを足します。Life cycle mappingの一覧画面で「Enable life cycle sync」を選ぶと、まずマッピングの不整合チェックが始まります。欠落・無効なマッピングを修正してチェックを通過した後、一括整合と継続同期の段階へ進みます。継続同期では、資産・CI・Install Base Item（IBI）の間でライフサイクル値がビジネスルールで定期的にそろえられます。

CSDM Data Foundationsダッシュボードによる不足データの点検

段階ごとの充足度は、CSDM Data Foundationsダッシュボードで測ります。ダッシュボードの設定手順（公式）によると、初回利用前に「All > System Scheduler > Scheduled Jobs」でCSDM Get Well Metric Collectionジョブを実行します。データが出るのはこのジョブの初回実行後で、既定では毎日実行され、スコアはsn_getwell_csdm_scoreテーブルに保存されます。各指標の結果が100%なら、その段階で必要な情報はそろっています。

ダッシュボードの収集ジョブ一覧に並ぶCSDM側の指標を見ると、何を直せばよいかが具体的に分かります。

ダッシュボードは「All > Configuration」から開くか、CMDB WorkspaceまたはService Graph WorkspaceのManagementメニューにあるOptimizeから開きます。ホワイトペーパーによると、CMDB用とCSDM用の2モジュールを持つこのダッシュボードは2020年8月から無償のストアアプリとして提供されています。

既存の独自テーブルからCSDMへ移行する5ステップ

独自のテーブルや本来と違うクラスにデータを入れてきたインスタンスでは、移行作業が発生します。公式ドキュメント（必要ロールはadmin）とホワイトペーパーが示す手順は次のとおりです。

1. データをすべての属性ごとExcelへエクスポートしてバックアップする
2. 移行先テーブルに必要な属性があるかを確認し、独自属性をPreferred・Keep・Refactor・Do Not Needに分類する
3. 公式Communityで配布されているfix scriptで、旧テーブルに依存するレポート・ビジネスルール・スクリプト・参照を洗い出す
4. 残すと決めた属性を移行先テーブルに用意し、リファクタリングを済ませる
5. CIのクラスを変更して移行し、レポートやスクリプトの参照先を付け替えてからバックアップの値を再投入する

最も手間がかかるのは3番目です。fix scriptは依存関係を洗い出すだけで、データも依存先も動かしません。クラスの変更自体は簡単でも、旧テーブルを参照するレポートやスクリプトは自動では移らず、同じテーブル階層にない属性の値は失われます。少数のCIで試してから件数を増やしてください。

CSDMの導入で効果が出ないパターン

導入時は、各テーブルへの配置に加えて、関係とデータの管理責任を決めます。影響分析にはCI間の関係の整備が欠かせません。ダッシュボードの指標も、関係の欠落を数えるものと、製品モデルの名称やオーナーなど属性データを評価するものに分かれます。公式資料の警告から、避けるべきパターンを挙げます。

• 全ドメインを最初から設計する：Ideation & StrategyやFlyのテーブルまで一度に作ると、参照データが未整備のまま関係だけが増えます。最初の目標はCrawlの4種類に絞るべきです。
• cmdb_ci_applを台帳として手入力する：アプリ台帳と検出された実行プロセスが同じクラスに混在し、データの意味が崩れます。
• 1つのCIを複数のOfferingに入れる：Service Deliveryの規則では、Dynamic CI Group経由のCIが関連づけられるTechnology Management ServiceまたはOfferingは1つだけです。SLAや担当グループが衝突するためです。
• Service Instanceの廃止でサーバーも廃止する：Service Instanceの廃止に関する公式の注意は、共有DBのように他のService Instanceが同じホストに依存している例を挙げ、ホストは廃止できないとしています。
• データのオーナーを決めずに入れる：ホワイトペーパーは、ガバナンスとプロセスがなければモデル内のデータの価値は小さいとしています。

CSDMはServiceNowのテーブル名と製品連携を前提にした規範です。ServiceNowを使っていない組織が汎用の構成管理モデルとして持ち込んでも、テーブル名や段階の効果はそのまま当てはまりません。その場合はNetBoxのようなOSSの構成管理ツールを含め、自社のCMDB製品の標準モデルに合わせるべきです。反対にServiceNowでITSMを運用しているなら、独自のテーブル設計よりCSDMに寄せたほうがバージョンアップ時の手戻りが減ります。アップグレード時の回帰を自動テストで確かめる方法はATF Test GeneratorとCloud Runnerの解説にまとめています。

CSDMに関するよくある質問

CSDMの読み方と正式名称は？

「シー・エス・ディー・エム」と読みます。正式名称はCommon Service Data Modelで、ServiceNowの日本語ドキュメントでは「共通サービスデータモデル」と訳されています。

CSDMのドメインはいくつありますか？

現行のCSDM 5では7つです（Foundation、Ideation & Strategy、Design & Planning、Build & Integration、Service Delivery、Service Consumption、Manage Portfolio）。CSDM 4の資料では5つで数えています。

CSDMの最新バージョンは？

CSDM 5です。ホワイトペーパーは2025年5月6日にServiceNow Communityで公開され、2026年9月更新のBrazil版ドキュメントもCSDM 5の構成で書かれています。

CSDMのCrawl・Walk・Run・Flyとは何ですか？

CSDMを段階的に導入するための区分です。参照データを整えるFoundationの後、Crawlでアプリケーション、Walkで技術サービス、Runで業務サービス、Flyで業務ケイパビリティと情報オブジェクトを整えます。

CSDMを使うのに追加の費用はかかりますか？

CSDMはデータモデルの規範で、基本テーブルはベースシステムに含まれますが、追加のプラグインやストアアプリが必要なデータモデルもあります。進捗を測るCMDB and CSDM Data Foundations Dashboardは無償のストアアプリです。ただし、Service MappingやSPMなど、CSDMのデータを使う個々の製品はそれぞれのライセンスが必要です。

関連記事

• CMDBとは？構成管理データベースの仕組み・ITILとの関係・導入判断を解説
• ServiceNow（サービスナウ）とは？機能・強み・他ツールとの違いを解説
• ITSMとは？ITILとの違い・管理プロセス・ツール実装と導入判断を解説
• インシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装を運用目線で解説
• ATF Test Generatorとは？ServiceNowのテスト自動生成とCloud Runnerの手順・制約