--- title: "CSDMとは？ServiceNow共通サービスデータモデルの7ドメイン・CMDBとの違い・導入手順【CSDM 5】" url: "https://www.issoh.co.jp/tech/details/4949/" published: 2025-01-22 updated: 2026-10-23 categories: ["業務システム"] publisher: "株式会社一創" --- # 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の機能と強みの解説](/tech/details/4955/)にまとめています。 ### CSDMとCMDBの違い | 観点 | CMDB | CSDM | | ----------- | ------------- | ---------------------- | | 正体 | 構成情報のデータベース | データの置き方の規範 | | 中身 | CIクラスのテーブルと関係 | どのクラスに何を置くかの指定 | | 範囲 | インフラ・アプリのCI | CI＋契約・組織・ロケーション等の参照データ | | ServiceNow外 | 一般概念として存在 | ServiceNow固有 | CMDBは「何があり、何と何がつながっているか」を記録する器です。CSDMは、その器の中で「業務アプリの台帳はcmdb\_ci\_business\_appに置く」「実際に動くアプリはService Instanceとして表す」といった配置と関係を決めます。[CSDMの概念とCMDBテーブルの対応（公式）](https://www.servicenow.com/docs/r/servicenow-platform/common-service-data-model-csdm/csdm-to-cmdb-mapping.html)も、Business Applicationのデータはcmdb\_ci\_business\_appテーブルに置くと明記しています。CMDBそのものの仕組みと導入判断は[CMDBの仕組みとITILとの関係の解説](/tech/details/4951/)を参照してください。 ### CSDMとITILの関係 CSDMはITILの代わりになるプロセス体系ではありません。ServiceNowの日本語ドキュメントは、CSDMにおける「サービス」の定義がITIL v3とIT4ITのサービスの基本定義と一致していると明記しています。ITILが「インシデントや変更をどう扱うか」を決め、CSDMは「そのとき選ぶサービスやCIがCMDBのどこにあるか」を決める、という分担です。ITILとITSMの関係は[ITSMとITILの違いの解説](/tech/details/13406/)で扱っています。 ### CSDMに沿うと製品ごとに変わること [CSDMの恩恵を受ける製品の一覧（公式）](https://www.servicenow.com/docs/r/servicenow-platform/common-service-data-model-csdm/csdm-used-by-products.html)は、CSDMに沿ったCMDBで製品ファミリーごとに次の指標が改善するとしています。 | 製品ファミリー | CSDMで可能になること | 公式が挙げる指標 | | -------- | -------------------- | ----------------- | | ITSM | サービス単位のレポート・変更管理 | チケット削減・MTTR短縮 | | ITOM | 障害を業務プロセスに対応づけて優先度付け | サービス停止の回避 | | ITAM | 正確なライセンスポジション | ライセンス違反金・監査不合格の減少 | | SPM | 投資・廃止の範囲と影響の計画 | 旧技術による業務リスクの低減 | | SecOps | 業務重要度による脆弱性の優先順位 | 優先度1脆弱性の修正時間短縮 | | IRM（GRC） | 監査対象の正確な特定 | 監査工数の削減 | どの行も、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の公開ページ）](https://www.servicenow.com/community/common-service-data-model/csdm-5-finally-get-the-csdm-5-white-paper-here/ta-p/3254967)の「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関係を定めた公式ドキュメント](https://www.servicenow.com/docs/r/servicenow-platform/common-service-data-model-csdm/ci-relationships.html)によると、CSDM v5はBusiness ApplicationとApplication Serviceを`Uses::Used By`で結び、以前の版は`Consumes::Consumed By`でした。ただしEnterprise Architecture Workspaceの利用者は、TLMとTRMのライフサイクルのタイムラインを正しく表示するために`Consumes::Consumed by`を使い続けるよう注記されています。 ### CSDM 4と5のドメイン対応 | CSDM 4 | CSDM 5 | 変化 | | ------------------------- | ------------------- | ---------------- | | Foundation | Foundation | Value Stream等を追加 | | なし | Ideation & Strategy | 新設 | | Design | Design & Planning | 改称 | | Build | Build & Integration | 改称 | | Manage Technical Services | Service Delivery | 改称 | | Sell/Consume | Service Consumption | 改称 | | Manage Portfolio | Manage Portfolio | 上位レイヤーとして継続 | ホワイトペーパーは、Manage Portfolioを「以前の5つのドメイン（foundation、design、build、manage technical services、sell/consume）の一部にまたがる概念」と説明しています。「CSDMのドメインは5つ」と書く資料はCSDM 4の数え方で、現行の数え方は7つです。 ## CSDM 5の7ドメインと主なテーブル ドメインは、CIと参照データを含むデータモデルの要素を、責任範囲と製品・サービスの種類に応じてまとめた区分です。日本語ドキュメントでは基盤ドメイン、サービスデリバリドメイン、サービス消費ドメインなどと訳されています。 | ドメイン | 主なテーブル | 運用CIか | | ------------------- | --------------------------------------------------------------- | ------ | | Foundation | cmdb\_ci\_business\_process, ast\_contract, cmn\_location | 参照データ | | Ideation & Strategy | sn\_align\_core\_planning\_item, sn\_align\_core\_product\_idea | いいえ | | Design & Planning | cmdb\_ci\_business\_capability, cmdb\_ci\_business\_app | いいえ | | Build & Integration | cmdb\_ci\_sdlc\_component | いいえ | | Service Delivery | cmdb\_ci\_service\_auto, cmdb\_ci\_service\_technical | はい | | Service Consumption | cmdb\_ci\_service\_business, service\_offering | はい | | Manage Portfolio | spm\_service\_portfolio | 上位レイヤー | 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準拠のインシデント管理プロセスの解説](/tech/details/13805/)とあわせて検討してください。 ### アプリケーションを表す4つのエンティティ ホワイトペーパーは、アプリケーション関連のデータを台帳・開発部品・展開した実体・実行プロセスの4つに分けて扱います。 | エンティティ | テーブル | 作り方 | ITSMで選ぶか | | -------------------- | ------------------------- | --------------------- | -------- | | Business Application | cmdb\_ci\_business\_app | 手入力・インポート | 選ばない | | SDLC Component | cmdb\_ci\_sdlc\_component | 任意・DevOps連携 | 選ばない | | Service Instance | cmdb\_ci\_service\_auto系 | Service Mapping・手動・タグ | 選ぶ | | Application | cmdb\_ci\_appl | Discoveryが自動作成 | 原因CIとして | Business Applicationはアプリの台帳（ポートフォリオ）で、版にも環境にも依存しません。Service Instanceは、そのアプリを環境や地域ごとに展開した実体で、利用者が「経費精算システムが動かない」と連絡してきたときに選ばれるのはこちらです。Applicationは1台のホスト上で動く実行プロセスで、ホワイトペーパーは「アプリケーションの台帳ではない」と注意しています。1つのApplication（たとえばデータベースのインスタンス）が複数のService Instanceを支えることもあるため、ApplicationとService Instanceは1対1になりません。 ## CSDMのモデル例：経費精算システムのドメイン別配置 CSDMでは、1つの業務システムを台帳・稼働環境・提供サービスなどの観点に分け、複数のドメインに記録します。説明用の例として、社内の経費精算システムを置くと次のようになります（レコード名は例です）。 | ドメイン | レコードの例 | テーブル | | ------------------- | --------------------------------- | ------------------------------------------------ | | Foundation | 経理部・東京DC・運用グループ | cmn\_department, cmn\_location, sys\_user\_group | | Design & Planning | 経費管理（業務ケイパビリティ） | cmdb\_ci\_business\_capability | | Design & Planning | 経費精算システム（台帳） | cmdb\_ci\_business\_app | | Design & Planning | 振込口座情報という情報種別（PII。口座番号そのものは格納しない） | cmdb\_ci\_information\_object | | Service Delivery | 経費精算 本番／経費精算 検証 | cmdb\_ci\_service\_auto系 | | Service Delivery | app01上のTomcat、db01上のDB | cmdb\_ci\_appl系, サーバー系クラス | | Service Delivery | Linuxサーバー運用 東京（Offering） | service\_offering＋Dynamic CI Group | | Service Consumption | 経費精算サービス 国内社員向け | cmdb\_ci\_service\_business, service\_offering | ポイントは3つの線です。1本目は、台帳の「経費精算システム」と環境ごとの「経費精算 本番」「経費精算 検証」を`Uses::Used By`で結ぶ線で、これでアプリ1つに本番と検証の2つの実体がぶら下がります。2本目は、Service Instanceの下に実際のTomcatやDBのサーバーをつなぐ線で、Service MappingかDynamic CI Groupで作ります。3本目は、業務側の「経費精算サービス 国内社員向け」とService Instanceをつなぐ線で、この関係は業務への影響をたどる基盤になります。インシデント画面への反映には、対象CIの登録、関連リストとプロパティの設定、[影響サービスの更新処理（Refresh impacted services）](https://www.servicenow.com/docs/r/it-service-management/incident-management/refresh-impacted-cis.html)が必要で、利用者の特定にはOfferingの購読情報なども必要です。 サーバーのサポートグループは、サーバー1台ずつではなく「Linuxサーバー運用 東京」のOfferingに設定し、Dynamic CI Groupで束ねたCIへ同期させます。[Dynamic CI Groupと種別の公式解説](https://www.servicenow.com/docs/r/servicenow-platform/common-service-data-model-csdm/csdm-dynamic-ci-groups-by-service.html)によると、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 | 会社・部署・ロケーション・グループ・製品モデル・契約 | レポートの共通軸 | | Crawl | Business Application, Service Instance, Application, サーバー | インシデント・変更の最低限 | | Walk | Technology Management Service/Offering, Dynamic CI Group | サポートグループの一括管理 | | Run | Business Service Portfolio, Business Service/Offering | 業務への影響分析 | | Fly | Business Capability, Information Object | アプリとサービスの合理化 | 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プラグインの有効化ページ](https://www.servicenow.com/docs/r/servicenow-platform/common-service-data-model-csdm/csdm-enable.html)に記載された必要ロールはitilとitil\_adminです。同ページは、有効化の前に既存のライフサイクルデータをCSDM標準の属性へマッピングするよう求めています。これを飛ばすと、CMDB Data Managerで資産のライフサイクル遷移を追跡できません。 CSDMのライフサイクルは、Life Cycle Stage（大きな段階）とLife Cycle Stage Status（段階内の状態）の2つの値の組で表します。[物理CIのライフサイクル定義（公式）](https://www.servicenow.com/docs/r/servicenow-platform/common-service-data-model-csdm/csdm-lifecycle-df-tangible-physical.html)の主な組み合わせは次のとおりです。 | Life Cycle Stage | 主なStage Status | | ---------------- | -------------------------------------- | | Ideation | Under Evaluation, Pilot | | Purchase | On Order, Preallocated | | Inventory | Available, Reserved, Pending Repair | | Deploy | In Stock, In Transit, Test | | Operational | In Use, In Maintenance, End of Support | | End of Life | Pending Disposal, Disposed, Sold | 従来のInstall StatusやOperational Statusなどの値は、プラグインの手順に沿うと自動でこの組へ対応づけられます。[自動更新されるレガシー値の一覧](https://www.servicenow.com/docs/r/servicenow-platform/common-service-data-model-csdm/csdm-lifecycle-status-auto-updated.html)に載っているのは、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ダッシュボードで測ります。[ダッシュボードの設定手順（公式）](https://www.servicenow.com/docs/r/servicenow-platform/common-service-data-model-csdm/csdm-foundations-dashboard.html)によると、初回利用前に「All > System Scheduler > Scheduled Jobs」でCSDM Get Well Metric Collectionジョブを実行します。データが出るのはこのジョブの初回実行後で、既定では毎日実行され、スコアはsn\_getwell\_csdm\_scoreテーブルに保存されます。各指標の結果が100%なら、その段階で必要な情報はそろっています。 [ダッシュボードの収集ジョブ一覧](https://www.servicenow.com/docs/r/servicenow-platform/configuration-management-database-cmdb/cmdb-csdm-scheduled-jobs.html)に並ぶCSDM側の指標を見ると、何を直せばよいかが具体的に分かります。 | 指標（公式名） | 見つかる不備 | | ------------------------------------------------------------- | ------------- | | Business Application Missing Application Service Relationship | 台帳に実体がない | | Application Services Missing Business Service Offerings | 業務への影響が出ない | | Technical Service Offering without Support or Change Group | 担当グループの同期元がない | | Dynamic CI Groups without CMDB Group | 束ねる条件が未設定 | | CIs with Mismatched Operational Status and Life Cycle Stage | ライフサイクル値の矛盾 | | Services Using Custom CMDB Tables | 独自テーブルへの依存 | ダッシュボードは「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の廃止に関する公式の注意](https://www.servicenow.com/docs/r/servicenow-platform/common-service-data-model-csdm/csdm-retire-srvc-inst-affects-hdw.html)は、共有DBのように他のService Instanceが同じホストに依存している例を挙げ、ホストは廃止できないとしています。 - **データのオーナーを決めずに入れる**：ホワイトペーパーは、ガバナンスとプロセスがなければモデル内のデータの価値は小さいとしています。 CSDMはServiceNowのテーブル名と製品連携を前提にした規範です。ServiceNowを使っていない組織が汎用の構成管理モデルとして持ち込んでも、テーブル名や段階の効果はそのまま当てはまりません。その場合は[NetBoxのようなOSSの構成管理ツール](/tech/details/3571/)を含め、自社のCMDB製品の標準モデルに合わせるべきです。反対にServiceNowでITSMを運用しているなら、独自のテーブル設計よりCSDMに寄せたほうがバージョンアップ時の手戻りが減ります。アップグレード時の回帰を自動テストで確かめる方法は[ATF Test GeneratorとCloud Runnerの解説](/tech/details/4948/)にまとめています。 ## 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との関係・導入判断を解説](/tech/details/4951/) - [ServiceNow（サービスナウ）とは？機能・強み・他ツールとの違いを解説](/tech/details/4955/) - [ITSMとは？ITILとの違い・管理プロセス・ツール実装と導入判断を解説](/tech/details/13406/) - [インシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装を運用目線で解説](/tech/details/13805/) - [ATF Test Generatorとは？ServiceNowのテスト自動生成とCloud Runnerの手順・制約](/tech/details/4948/) --- 出典: [CSDMとは？ServiceNow共通サービスデータモデルの7ドメイン・CMDBとの違い・導入手順【CSDM 5】]()（株式会社一創）