CMDBはなんとなく分かってきたのに、資料を読み進めると今度はCSDMという言葉が出てきて、CMDBと何が違うのか分からなくなる——ServiceNowのサービス設計では誰もが一度ここで止まります。しかも「Discoveryを回せばCMDBは自動で埋まる」と聞いていたのに、CSDMの資料には人が設計する話ばかり書いてある。自動で埋まるなら、なぜ設計が要るのでしょうか。
この記事は、その疑問をデータ構造（CSDMとCMDBはそれぞれ何か）→ 対応関係（4ドメインとCMDBクラスの早見表）→ 自動と手動の境界（Discoveryが書き込むのはどこまでか）→ 設計を進める順番 → 崩れる典型パターンの順に整理し、最後にCIS-DiscoveryとCIS-DF試験でこの領域がどう問われるかまで進む判断ガイドです。読み終えると「このレコードはどのクラスに載せるべきか」「これは自動で埋まるのか、人が作るのか」を即答できるようになります。
要点まとめ
- CMDBは「器」、CSDMは「器の使い方を決めた設計図」。CSDMという名前の製品や追加モジュールがあるわけではありません。
- Discoveryが自動で書き込むのはインフラCIとその関係（技術レイヤー）だけ。Business ApplicationやBusiness Service、Service Offeringといったビジネス層は人が設計して登録します。
- 迷ったら「計画の話ならDesign、動いている実体ならManage Technical Services、提供の約束ならSell/Consume」。この3択がCSDM判断の背骨です。
CSDM・CMDB領域の理解をCIS-Discovery無料模試で確認する
この記事で扱う「どのクラスに載るか」「Discoveryはどこまで書くか」は、模試のCMDB連携・実務パターン系ドリルの頻出判断です。
CSDMとCMDBの関係は「器と設計図」
まず言葉の整理から片づけます。CMDB（Configuration Management Database）は、サーバー・アプリケーション・サービスといった構成アイテム（CI）を保存するテーブル群の総称です。実体はcmdb_ciを頂点とするクラス階層で、サーバーならcmdb_ci_server、CI同士の関係ならcmdb_rel_ciと、種類ごとにテーブルが分かれています。インスタンスを立てた瞬間から存在する、データの「器」です。
一方のCSDM（Common Service Data Model）は、その器をどう使うかをServiceNowが標準化した設計図です。何百とあるCMDBクラスのうち、どのクラスを・どの目的で・どんな関係でつなぐべきかの規範を定めたフレームワークであり、CSDMという名前のプラグインや追加ライセンスを買うものではありません。だから「CSDMを導入する」の実態は、製品インストールではなく既存CMDBの使い方をCSDMの役割分担に沿って揃えていく設計作業になります。
この区別が付くと、冒頭の疑問にも答えが出ます。Discoveryが自動で埋めてくれるのは器の一部（後述する技術レイヤー）だけで、「どのデータをどの層に載せ、何と何をつなぐか」という判断そのものは自動化できない。だからCMDBが自動で埋まってもCSDMの設計は別に必要なのです。
CSDMの4ドメインとCMDBクラスの対応早見表
CSDM（4.0系）はデータの置き場所を4つのドメインに分けています。この記事の中心資産として、各ドメインが「何を決める場所」で、代表クラスがどのテーブルで、Discoveryとどう関わるかを1枚にまとめます。
横にスクロールできます
| ドメイン | 何を決める場所か | 代表クラス（テーブル） | Discoveryとの関係 |
|---|---|---|---|
| Foundation | 誰が・どこで・何を使うか。全ドメインが参照する共通マスタ | Company（core_company）、Department（cmn_department）、User（sys_user）、Group（sys_user_group）、Location（cmn_location） |
書き込まない。人事・組織データの連携や手動整備で揃える |
| Design | 計画とアーキテクチャの視点。会社にどんな業務アプリケーションが存在するか | Business Application（cmdb_ci_business_app） |
書き込まない。アプリケーションポートフォリオとして人が登録する |
| Manage Technical Services | 運用の実体。いま実際に動いているシステムそのもの | Application Service（cmdb_ci_service_auto系）、サーバーやデータベースなどのインフラCI（cmdb_ci_serverほか） |
ここだけ自動で埋まる。インフラCIと関係はDiscovery、Application Serviceのトポロジは Service Mapping やタグ付けで作る |
| Sell/Consume | 利用者と契約の視点。何を・どんな条件で提供するか | Business Service、Service Offering（service_offering） |
書き込まない。サービスカタログやSLAの設計と合わせて人が定義する |
4行しかない表ですが、CSDMの実務判断と試験判断はほぼこの表に還元できます。各ドメインをもう一段だけ具体化します。
Foundation：サービスを支える共通マスタ
会社・部門・人・場所・グループといった、CIそのものではない基礎データの層です。テーブルを見ると分かるとおり、core_companyやsys_userはcmdb_ci階層の外にあります。「CMDBクラスではないのにCSDMに含まれる」のがFoundationの特徴で、ここが未整備だと後段のサービスに「誰が使うか」「どの部門の持ち物か」を紐づけられません。派手さはありませんが、設計の順番では最初に着手する層です。
Design：ビジネスアプリケーションの計画視点
Business Application（cmdb_ci_business_app）は「うちの会社には経費精算システムがある」という計画・ポートフォリオ上の存在を表します。ポイントは、これが「動いているサーバー群」ではないこと。経費精算システムという概念は1つでも、実体は本番環境・検証環境と複数動いているはずです。その「概念としてのアプリ」を管理するのがDesignドメインで、IT投資の棚卸しやアプリケーション統廃合の議論はこの層で行います。
Manage Technical Services：運用の実体レイヤー
実際に稼働しているシステムの層です。中心になるのがApplication Service（cmdb_ci_service_autoとそのサブクラス）で、「本番の経費精算サービス」のように環境単位で動いている実体を表し、配下のサーバー・データベースなどインフラCIと関係でつながります。障害対応で「このサーバーが落ちたら何が止まるか」を辿るのはこの層です。Business Application（概念）とApplication Service（実体）の対応関係が、CSDM理解の最初の山場になります。
Sell/Consume：提供と契約の視点
Business Serviceは「利用者に約束するサービス」、Service Offering（service_offering）はそれを「対象範囲・サービスレベル・提供時間などの条件付きで切り出したメニュー」です。たとえば「社内ITサポート」がBusiness Serviceなら、「平日9-18時対応の標準サポート」「24時間対応のプレミアムサポート」がService Offeringにあたります。SLAや通知の宛先、サービスカタログとつながるのはこの層で、技術構成が同じでも提供条件が違えばOfferingは分かれます。
Discoveryが自動で書き込むのはどこまでか
早見表の「Discoveryとの関係」列を、今度はデータの流れとして縦に見ます。境界線がどこにあるかが、この記事でいちばん持ち帰ってほしい判断です。
自動で埋まる層：インフラCIと関係
Discoveryはネットワークをスキャンして見つけた機器やソフトウェアを、IRE（Identification and Reconciliation Engine）を通してcmdb_ci_serverなどのインフラ系クラスへ書き込み、CI同士のつながりをcmdb_rel_ciへ記録します。IREは識別ルールで「これは既存のあのCIと同一か」を判定して重複を防ぎ、複数のデータソースが同じCIを更新するときはデータソースの優先度で採用値を決める門番です。この仕組みの全体像はDiscovery実務ガイドで扱っているので、本記事では「書き込み先」に絞ります。
自動では埋まらない層：ビジネス側のサービス
一方、Business Application・Business Service・Service Offeringは、どれだけDiscoveryを回しても1件も作られません。理由は単純で、「うちの会社がこれを1つのサービスとして顧客に約束している」という情報はネットワーク上のどこにも存在しないからです。スキャンで見つかるのは機器と接続だけ。それを「経費精算サービスの本番系」と意味づけるのは人間の設計判断です。Discovery導入プロジェクトで「CMDBは自動化したのにサービスマップが空のまま」という状態になるのは、この境界を計画に入れていなかったときに起きます。
Application Serviceは「作り方を選ぶ」クラス
境界線上にいるのがApplication Serviceです。器はビジネス寄りですが、中身（どのインフラCIで構成されるか）は自動化の対象で、Service Mappingでエントリポイントから接続を辿ってトポロジを描く方法、CIに付けたタグでまとめる方法、手動でCIを選んでグルーピングする方法など複数の作り方から選びます。「Application Serviceを作ること」自体と「その配下を自動で維持すること」は別の判断だ、と覚えておくと設計の議論が噛み合います。
サービス設計を進める順番
4ドメインと自動化の境界が分かると、設計の順番は自然に決まります。実務では次の順で進めるのが安全です。
- Foundationを整える——会社・部門・ロケーション・グループ。ここが空だと後段のすべてが宙に浮きます
- Discoveryでインフラ層を埋める——IREの識別が効いた状態で、機器と関係のデータを自動維持に乗せます
- Business Applicationを棚卸しする——会社にどんな業務アプリがあるかを、環境と切り離した概念単位で登録します
- Application Serviceを作る——重要システムから順に、Service Mapping・タグ・手動のどれで構成を維持するかを決めて実体をつなぎます
- Sell/Consume層を定義する——利用者に見せるBusiness ServiceとService Offeringを設計し、SLA・カタログ・通知へ接続します
逆に「先にBusiness Serviceの一覧だけ作って中身は後で」と上から始めると、実体とつながらない名前だけのサービスが並び、影響分析に使えないリストになります。下（Foundation・インフラ）から上（提供条件）へが原則です。
設計が崩れる典型パターン
この領域で実際に起きるしくじりを1つ、流れで見ておきます。
【現場で起きる事故】監視ツールとの連携やレポートづくりを急ぐあまり、技術チームの運用単位も、顧客向けのサービス名も、アプリケーションの概念名も、区別せず全部「サービス」として同じクラスへ直接登録していく。
【放置するとどうなる】1年後、サービス一覧は数百件。どれが顧客に約束しているもので、どれが運用の内部単位か、登録した本人にしか分からなくなります。障害時の「このサーバーが落ちたらどのサービスが止まるか」に対する答えが人によって違い、CMDBの影響分析そのものが信用を失います。
【CSDMではこう分ける】概念としてのアプリはBusiness Application、動いている実体はApplication Service、提供の約束はBusiness ServiceとService Offering——登録先のクラスを役割で分け、層と層はcmdb_rel_ciの関係でつなぎます。
【改善後】障害連絡は「どのOfferingの利用者に知らせるか」、原因調査は「Application Serviceからインフラへ辿る」と、見る層が会話で揃います。サービス一覧も「この層のリストを見れば良い」と役割ごとに短くなります。
ほかにも、IREの識別ルールを整えないままデータソースを増やして同じサーバーのCIが二重三重にできるパターン、命名規範を決めずにサービス名が「経費精算」「経費精算(本番)」「keihi-prod」と乱立するパターンが定番です。どちらも器は正しくても運用ルールが未設計という点で、根っこは同じです。
PDIで自分の目で確かめる場所
ここまでの内容は、無料のPDI（Personal Developer Instance）で実物を見ながら確認できます。順路は3つです。
- CI Class Managerでクラス階層を見る——
cmdb_ciを頂点に、どんなクラスがどうぶら下がっているかを展開して眺めます。「CMDBは1枚の表ではなく継承ツリー」という感覚が一度で入ります - リストでサービス系クラスを見比べる——ナビゲーションフィルターに
cmdb_ci_service.listとcmdb_ci_service_auto.listを入力し、リスト右上の歯車からClassカラムを足すと、同じ「サービス」でもクラスが分かれていることを確認できます - CIのRelationshipsを見る——任意のCIフォームの関連リストで、Depends on / Runs onといった関係の実データ（
cmdb_rel_ci）がどう持たれているかを見ます
なお、Discovery本体（MID Serverを立てて実ネットワークをスキャンする部分）はPDIだけでは完結しません。どこまでPDIで確認でき、どこから公式ドキュメントで補うかはMID Serverの構成と設定ガイド側で整理しています。
試験ではこう出る：CIS-DiscoveryとCIS-DFの問われ方
CSDMとCMDBの関係は、CIS-Discovery（Discovery実装スペシャリスト）とCIS-DF（Data Foundations）の両方で問われますが、角度が違います。
- CIS-Discoveryでの問われ方——「Discoveryが書き込むテーブルはどれか」「重複CIを防ぐ仕組みは何か」のように、自動化の境界とIREの役割を軸に出ます。Service MappingとDiscoveryの分担もこの文脈です
- CIS-DFでの問われ方——「Business ApplicationとApplication Serviceの違いは」「この説明はどのドメインか」のように、CSDMの4ドメインと各クラスの役割対応そのものが出ます。CSDMのバージョンによるドメイン再編（5.0では構成が細分化されています）に触れる出題もあるため、教材がどのバージョン前提かの確認も大切です
問題文を読むときの判断軸はシンプルで、「計画・ポートフォリオの話ならDesign、いま動いている実体ならManage Technical Services、提供条件・契約の話ならSell/Consume、共通マスタならFoundation」。選択肢がクラス名で並んでいたら、この4択に翻訳してから選ぶと迷いが減ります。
当サイトの無料模試は、この領域を分類別ドリルで反復できます。CIS-Discovery模試（597問）はDiscoveryの書き込み先・IRE・実務パターンを、CIS-DF模試（355問）はCSDMドメインと用語対応を集中的に扱います。どちらも分類別の推定得点と間違えた問題の復習モードが付いているので、この記事を読んだ直後に解くと弱点の層がそのまま見えます。
まとめ
- CMDBはデータの器（
cmdb_ciのクラス階層）、CSDMはその使い方を標準化した設計図。CSDMという製品を買うわけではない - CSDM（4.0系）の4ドメインは Foundation / Design / Manage Technical Services / Sell/Consume。それぞれ共通マスタ・計画・運用実体・提供条件を受け持つ
- Discoveryが自動で書くのはインフラCIと関係（＋Application Serviceのトポロジ維持）まで。ビジネス層のサービスは人が設計する
- 設計は下から上へ：Foundation → インフラ → Business Application → Application Service → Sell/Consume
- 迷ったら「計画か・実体か・提供の約束か」の3択に翻訳する。実務でも試験でも同じ判断軸が使える
よくある質問
CSDMは製品やプラグインですか？導入に追加ライセンスは必要ですか？
いいえ。CSDMはServiceNowが公開している標準データモデル（設計規範）で、インストールする製品ではありません。すでにあるCMDBのクラス群を「どの役割で使うか」を揃える設計活動が、いわゆるCSDM導入の中身です。
Discoveryを動かせばBusiness Serviceも自動で作られますか？
作られません。Discoveryが書き込むのはインフラCIと関係までで、Application Serviceのトポロジ維持を含めても自動化されるのは技術レイヤーだけです。Business Application・Business Service・Service Offeringは、組織として何をサービスと呼ぶかの判断を伴うため、人が設計して登録します。
CSDMは4.0と5.0のどちらで覚えるべきですか？
土台としてはこの記事で扱った4.0系の4ドメインをまず固めるのが実用的です。5.0ではドメイン構成が再編・細分化されているため、教材や問題文がどちらの前提かを必ず確認してください。当サイトのCIS-DF模試では、バージョンを明示した形で両方の呼び方を扱っています。
関連記事・公式確認先
- ServiceNow Discovery実務ガイド｜MID Server・CMDB・CSDMまで一本で
- ServiceNowのCIとAssetの違い｜CMDBと資産管理で迷わない判断基準
- CIS-Discovery試験対策ハブ
- CIS-DF（Data Foundations）試験対策ハブ
- ServiceNow CIS-DFの難易度と勉強法｜CMDB・CSDM学習順と模試活用の判断ガイド
受験条件・試験範囲・製品仕様は変わる可能性があります。最終確認は必ず公式で行ってください。
