CMDBは何のために作るのか CSAで混乱しやすい前提をそろえる
CMDB（構成管理データベース）は、IT資産の台帳を作るための箱…と思われがちです。でも、ServiceNowでCMDBを設計する目的はもう少し実務寄りで、「運用や変更管理の判断材料になる“共通の事実”を置く場所」を作ることにあります。インシデント、問題、変更、リクエスト、さらにはIT運用（ITOM）やセキュリティの文脈でも、同じ“構成アイテム（CI）”を参照できる状態が整うと、判断が速くなります。
逆に、最初から何でも入れようとするとCMDBは破綻しやすいです。たとえば「サーバ台数は全部入れたのに、アプリとサービスの関係がつながっていない」「同じ機器が重複して登録されていて、どれが正しいかわからない」「データソースごとに上書き合戦が起きる」など。こうなると、現場はCMDBを信用しなくなります。
Zurich世代では、CMDBを“一覧表”として扱うより、CMDB Workspaceを中心に「探索・整備・品質改善まで回す」発想がより自然になりました。Zurichのリリースノートでも、CMDB Workspaceが同梱され、必要ならより新しいバージョンをStoreから入れて最新機能を使える、という位置づけが示されています。また、アップグレードや新規連携後にCMDBが期待通り動くかを確認するクイックスタートテストも用意されています。こういう機能があるのは、「CMDBは継続的に変化するもの」という前提が公式側にもある、ということです。
ここでCSA視点として大事なのは、用語の整理です。
- CI：管理したい対象。物理・論理・サービスなど幅広い
- クラス：CIの種類（サーバ、アプリ、ビジネスサービス等）
- 関係（Relationship）：CI同士のつながり。ここが“価値の源”になりやすい
- データソース：Discoveryや連携ツールなど、CIデータの供給元
- 識別と調停：重複を防ぎ、どのソースの値を優先するか決める仕組み（後述のIRE）
CMDBは「入れること」よりも、「同じものを同じものとして扱えること」「運用が使える形でつながっていること」が重要です。この前提を押さえたうえで、次は最小構成の設計に落とし込みます。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
最小で始めるCI設計 クラス選び・命名・必須項目の決め方
CMDB基本設計の最初の決めごとは、意外とシンプルです。まずは「どこまでをCIとして管理するか」の境界線を引きます。おすすめは、いきなり“全社の全部”を狙わず、次の3つを優先して小さく始めることです。
- まず困っている領域（障害対応で影響範囲が追えない、変更のリスク判断ができない等）
- 情報が取りやすい領域（Discoveryや既存台帳でデータソースがある）
- サービスにつなげやすい領域（業務影響が語れる）
クラス設計は「増やさない」から始める
ServiceNowのCMDBには標準クラスが豊富にあります。初学者ほど「自社に合わせてクラスを作りたい」と思いますが、基本設計の段階では増やしすぎないほうが運用が安定します。まずは標準クラスで表現できる範囲を使い、どうしても表現が難しいところだけ拡張する、くらいが現実的です。
命名と一意性は“人間の都合”より“機械の都合”を優先する
CI名（Name）や表示名は、人が見てわかることも大事ですが、CMDBが壊れやすいポイントは「同じものが別名で登録されること」です。
そのため、命名ルールは次のどちらかに寄せると安定します。
- 一意になりやすい識別子を含める（例：ホスト名、シリアル、クラウドのリソースIDなど）
- 表示名と識別を分離する（見た目の名前とは別に識別用属性を持たせる）
この考え方は、後で説明するIRE（識別と調停）にもつながります。
必須項目は「入力させたい」ではなく「運用で必要」から決める
必須項目を増やしすぎると登録が止まります。逆に少なすぎると使えません。ここは“理想”より“運用”に寄せます。たとえば最初の必須項目は、よくあるところで次のようなものに落ち着きやすいです。
- 所有や責任が追える項目（管理者、担当グループなど）
- 影響判断に使う項目（環境、重要度、稼働状況など）
- データ品質を守る項目（データソース、最終更新、識別に使うキー属性など）
Zurichリリースノートでは、CI作成の体験として「Operational statusを自動でセットしない」方向の変更も示されています。つまり、状態の値を“最初から強制する”より、必要に応じて入力・運用に組み込む考え方に寄っている、と捉えると自然です。
この段階までできたら、次は「どうやってデータを入れて壊さないか」です。CMDBが崩れる最大要因は、実は“登録作業”ではなく“統合”です。
データを壊さず集める設計 IREで重複と上書きを防ぐ考え方
CMDBにデータを入れる方法は複数あります。たとえばDiscovery、外部台帳からの連携、インポート、Service Graph Connectorなど。ここで問題になるのが、「同じCIが別々に作られる」「別ソースが同じ項目を上書きする」です。
この課題に対してServiceNowが用意している中核が、**CMDB Identification and Reconciliation（IRE）**です。公式ドキュメントでも、IREは「複数のデータソースからのデータを識別し、調停するための集中フレームワーク」と説明されています。また、Import SetでCIを取り込む場合にもIREプロセスを適用でき、識別によって重複CIを防げることが示されています。さらに、重複が検知された場合は重複排除タスクとしてまとめられ、識別ルールが弱いと重複が増えやすい、といった注意点も明記されています。
IREの理解で押さえるポイント
CSAの学習でも、ここを理解していると「なぜその設計が必要か」が腑に落ちやすいです。
- Identification rule（識別ルール）
CIを“唯一”にするための条件。属性の組み合わせで「これが同一CI」と判定する - Reconciliation rule（調停ルール）
どのデータソースの更新を優先するか。上書きの優先順位や権限を管理する
たとえば、同じサーバについて
- Discoveryはホスト名やIP、CPU/メモリなどを更新したい
- 資産管理台帳は所有部門や購入日、減価償却情報を更新したい
といった場合、調停ルールがないと“取り合い”になります。IREで更新の優先順位を決めておくと、運用が揉めにくいです。
Zurichで意識したいポイント
ZurichのCMDBリリースノートには、「CIを一意に識別する際に、source_name/source_native_keyよりIREの識別ルールの利用を優先させる」ための設定（システムプロパティ）に触れた記載があります。これは、「連携側が付けてくるキーに頼り切りだと、設計が歪むことがある」という示唆として読めます。実務でも、連携キーが変わったり、ツール更改でキー体系が崩れたりするのはよくある話です。だからこそ、自分たちのCMDBの中で“同一性”を保証する設計が重要になります。
データ投入の選択肢を整理する
公式の位置づけとして、CMDB関連機能には次のような要素があります。
- Service Graph Connector：サードパーティからのデータ取り込みを支援
- IntegrationHub ETL：カスタムETL変換マップを作り、整合性を損なわず統合する
- CMDB Workspace：探索・健康状態の把握・改善作業のハブ
- Now Assist for CMDB：検索や重複対応、作成支援などの体験を支える（利用可否は契約範囲による）
基本設計としては、「どのソースがどの属性を責任持つか」を最初に決め、IREで矛盾が起きないようにしておく。これが“壊れないCMDB”の第一歩です。
関係性の設計が価値を決める CSDMでサービスにつなげる
CMDBが「台帳」で終わるか、「運用の武器」になるかは、関係性で決まりやすいです。たとえばインシデントが起きたときに、
- この障害はどのサービスに影響するのか
- 影響範囲にいるCIはどれか
- オーナーは誰か、どの変更が直近入ったか
こういう問いに答えるには、CIが単体で正しいだけでは足りません。サービスという単位につながっていることが必要です。
そこで役立つのが**CSDM（Common Service Data Model）**です。ServiceNowはCSDMを「ServiceNow製品がCMDBを使うための標準的なフレームワーク・ガイドライン」と位置づけ、サービスに関連する用語や関係を標準化し、IT資産をサービスやユーザー、コストなどと結びつけることを説明しています。
CSDMは“全部やる”ものではなく“迷わないための地図”
CSDMを聞くと、急に難しく感じる人が多いです。でも実務での使い方は「どこに何を置くべきか迷ったときの地図」に近いです。
基本設計でまず効くのは、この2点です。
- サービスを表すCIを決める（ビジネスサービス、アプリケーションサービス等の使い分け）
- サービスと下位CIの関係をどう作るか（依存関係、ホスティング、コンテインメントなど）
ここでよくある失敗は、サービスを“名前だけ”作って終わることです。サービスがサーバやアプリとつながっていないと、運用上は使えません。逆に、関係を丁寧につなぐと、インシデントの影響分析や変更のリスク判断に効いてきます。
関係の種類を増やすより、使う関係を固定する
関係タイプは増やせますが、増やすほど運用が揺れます。最初は「この関係はこの意味」と定義し、使う関係タイプを絞るほうがうまくいきます。
特に、後でCMDB HealthのRelationship指標でも見られるように、関係の重複・孤立・陳腐化が起きると、サービスモデルが崩れます。
学習のコツ
CSAの勉強では、CSDMの細かい段階を丸暗記するよりも、「サービス中心で見る」「CIは関係で価値が出る」「関係が壊れると運用が壊れる」という3点をストーリーとして理解しておくのが強いです。問題文が抽象的でも、設計の意図から選択肢を絞りやすくなります。
運用までが基本設計 CMDB HealthとWorkspaceで育てる仕組み
CMDBの設計は、テーブル構造を決めた時点では終わりません。むしろスタートです。データは日々変化しますし、連携も増えます。だから基本設計には「データ品質をどう測り、どう直すか」を必ず含めます。
CMDB Healthで“壊れ始め”を早期に見つける
ServiceNow公式の説明では、CMDB HealthはCIの健康状態を複数のKPIで監視・レポートします。KPIには Completeness（完全性）/ Correctness（正確性）/ Compliance（準拠性）/ Relationships（関係性） があり、必須項目未入力、重複や孤立、古いデータ、関係の不整合などを評価します。
また、ダッシュボードはCMDB Workspaceからアクセスでき、健康データを集計するためのジョブは初期状態では無効で、必要に応じて有効化・設定する、という運用前提も示されています。
ここが重要です。つまり、公式も「健康状態は放っておいて勝手に見えるものではない。ジョブを回し、基準を定義し、直す仕組みを作るもの」と言っています。
Zurich時代はCMDB Workspace中心で回す
Zurichのリリースノートにもある通り、CMDB Workspaceは探索や洞察の中心です。健康状態の確認、タスクの確認、手動作成、ポリシー管理など、「CMDBを育てる日常作業」が集約されていきます。
また、ロールの見直しも入っており、itilロールに含まれる権限が変わるなど、運用設計に影響する変更もあります。基本設計で「誰が何をするか」を決めるときは、Workspace中心の作業フローと合わせて考えるのが安全です。
“育てる”ための最小運用ループ
最初から完璧なCMDBは作れません。なので、回せるループを設計します。
- 追加・変更の入口を決める（どのデータソースが何を更新するか）
- IREで重複と上書きを抑える（識別ルール・調停ルール）
- CMDB Healthで測る（基準を決め、ジョブを回す）
- 直す（タスク化、担当割り当て、再発防止としてルール改善）
このループが回り始めると、CMDBは「信頼できる共通の事実」に近づきます。
体系的に学ぶ教材の一例
CMDBは、断片的に機能を覚えるより「設計思想→運用ループ→機能の位置づけ」の順で学ぶほうが伸びます。Udemyでも、ServiceNow CSA対策に加えて、CMDB/CSDM/IREあたりをテーマにした講座を選ぶと、用語の定義だけでなく“なぜそうするか”をストーリーで掴みやすいです。公式ドキュメントを読みながら、講座で全体像を補う、という組み合わせが現実的だと思います。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ
ZurichでのCMDB基本設計をCSA視点で整理すると、ポイントは「登録」ではなく「一貫性」と「運用」です。最初にCMDBの目的を“運用で使える共通の事実”と定義し、CIの範囲を小さく切って、標準クラス中心で始める。次に、複数データソースの統合で壊れないよう、IREで識別ルールと調停ルールを用意して重複と上書きを抑える。そして、関係性をCSDMの考え方でサービスにつなげ、最後にCMDB HealthとCMDB Workspaceで“測って直す”運用ループを回す。
この流れが理解できると、CSAの学習でも単語暗記になりにくく、問題文が抽象的でも「設計として自然なのはどれか」を考えて選べるようになります。CMDBは一度作って終わりではなく、育て続ける前提の基盤です。Zurich世代の公式機能（Workspace、Health、IRE、連携）を“点”ではなく“線”でつないで理解していくと、実務にも試験勉強にも効いてきます。
