CMDB運用設計書

この記事は、PDI（Zurich、2026-07-08 確認）の OOTB（初期設定）構成をもとに、CMDB（構成管理データベース）運用の設計判断を「なぜそう決めるか」まで整理した運用設計書です。登録経路の統制やデータ品質のしきい値などの具体値は一例で、自社導入時のたたき台に使うことを想定しています。

1. 運用設計の目的と範囲

構成情報（CI）を、誰が登録しても重複せず、関係と状態が実態を表す台帳として保てるため、本設計書ではServiceNowのCMDB運用の設計判断を一つずつ決める。どの経路からのCI登録を正規のものとするか、クラスと関係タイプをどこまで使うか、状態をどの軸で表すか、データ品質のずれをどう検知するか。あとから運用を変えるときに判断の背景までさかのぼれるよう、決定とその理由をあわせて記録する。

CMDBの構造は、次の3本の記事で確認済みだ。

• CMDBの中心テーブル cmdb_ci の構造 …「ServiceNow CMDB の中心テーブル cmdb_ci を実機で読み解く」

• CI 間の関係の持ち方 …「ServiceNow の CI 関連（cmdb_rel_ci）を実機で読み解く」

• 同定・調整の仕組みそのもの …「ServiceNow CMDB の同定・調整（IRE）を実機で読み解く」

本設計書は構造の説明ではなく、その構造の上で運用をどう決めるかに重心を置く。

CMDB運用の設計が達成すべきことを、次のように置く。

• 同一機器が別々のCIとして登録される事態を防ぐことを目的として、CI登録経路と同定ルールの設計を決める。

• クラスと関係が管理コストに見合う粒度になるため、クラス階層と関係タイプの標準セットを設計する。

• CIの現在地を一つの基準で説明できることを目的として、状態の3軸（設置状況・運用状況・ライフサイクル）の使い分けを設計する。

• 退役したCIが稼働中の扱いのまま残らないため、退役時の後始末を設計に含める。

• 台帳と実態のずれを検知し続けることを目的として、データ品質のルールとKPI、棚卸しの回し方を設計する。

操作の「やり方」は、対になる運用手順書「ServiceNowのPDIをもとにしたOOTB CMDB運用手順書」が担当する。手順書では、サーバCIを1件選び、IRE経由の新規登録から関係付け・状態変更・退役までを実機で回している。手順書は「どの画面で何が起き、どの値がどう変わるか」を順番に見せる。本設計書は「どの経路を正規とし、何を標準にし、誰が責任を持つか」を決める。やり方を先に知りたい人は、手順書が入口になる。

対象範囲は、cmdb_ci とそのサブクラス全般を中心としたCMDB運用とする。設計の対象に含めるのは次の5点だ。

• CI登録経路（IRE・table API・手動）

• 同定ルール（cmdb_identifier）

• クラス階層と関係タイプ（cmdb_rel_type）

• 状態の3軸（install_status・operational_status・life_cycle_stage系）

• データ品質の定義（CMDB Health・staleness rule）と棚卸し

Discovery のパターン開発、Service Graph Connector 個別製品の設定、CSDM のサービスマッピング（アプリケーションサービス・ビジネスサービス側の設計）は対象に含めない。これらは今回の実機検証範囲外とし、末尾に明記する。

設計の起点はOOTBとする。ServiceNowのCMDBには、何も作らない初期状態でも次の仕組みが最初から組まれている。

• ハードウェア系クラスに継承的に効く同定ルール（Hardware Rule）

• 40種類の関係タイプ

• install_status・operational_status の選択肢構成

• CSDM系のライフサイクル対応表（life_cycle_control）

• CMDB Healthの指標定義

OOTBの構成のうち、どこをそのまま使い、どこを自社の運用ルールへ落とし込むかを決めることを本設計書の方針とする。 想定読者は、CMDB導入・改善を任された運用設計者、登録経路の統制に責任を持つ構成管理者、CIとの連携を設計したい資産管理・監視運用の担当者です。

設計領域の全体像

CMDB運用設計で決めることを4つの領域に分け、この順で設計を進める。

• 登録経路・同定設計（3章）… 何を正規の入口にするか。IRE と cmdb_identifier の使い方。

• クラス・関係設計（4章）… どこまで細かく分けるか。クラス粒度と関係タイプの標準セット。

• 状態・ライフサイクル設計（5章）… 現在地をどの軸で表すか。3軸の使い分けと退役の後始末。

• 品質・棚卸し設計（6章）… ずれをどう検知するか。CMDB Health とKPI、棚卸しの回し方。

矢印の終点を品質・棚卸しから登録経路・同定設計へ戻しているのは、棚卸しで見つかった重複や品質低下の原因が、たいてい登録経路の統制不足や同定ルールの穴に行き着くためだ。4つの領域が一巡して閉じる構造を、設計の枠組みとする。

2. 現状把握（OOTBのCMDB構成）

設計の土台を確かめるため、OOTBのCMDBの構成をここで整理する。今回確認したPDIでは、cmdb_ci は全体で2,785件が入っており、値が入っているクラスは35種類でした。

2-1. CI総数とクラス分布

sys_class_name 別に見ると、Software Package が1,767件と最も多く、コンピュータ815件、サービス41件と続く。クラス数の数え方には注意が要る。テーブル単位のcountはサブクラスを含む累計になる。たとえば cmdb_ci_computer テーブルのcountは856件だが、そのうち sys_class_name=cmdb_ci_computer そのものは815件で、残り41件はサーバ系サブクラスでした。クラス数を語るときは、テーブルのcountではなく sys_class_name の実測値か super_class の階層で確認する必要がある。

2-2. 登録経路と同定ルールの実態

cmdb_identifier は409件、そのentryは471件定義されていた。ただし cmdb_ci_computer / cmdb_ci_server / cmdb_ci_linux_server 専用の identifier は存在しない。ハードウェア系のクラスは、親クラス（cmdb_ci_hardware）の「Hardware Rule」1本を継承的に使っている。

Hardware Rule の identifier entry を order 順に見ると、product_instance_id（90）→ serial_number 型別検索（100）→ serial_number（200）→ name（300）→ mac+name（400）の順に評価される。IP・MACアドレス単独の entry（500〜800）は inactive になっていた。

登録元を示す discovery_source は20個の選択肢を持つが、このPDIのCIでは大半（2,734件）が空でした。「Manual via IRE」のように登録経路を名乗る値も選択肢に含まれている。

2-3. 関係タイプの実態

cmdb_rel_type は40件定義されているが、cmdb_rel_ci（238件）の内訳を見ると実際に使われているのは15タイプ程度だ。中でもDepends on::Used by が57%を占めていた。

2-4. 状態体系の実態

cmdb_ci の状態は3つのフィールドで表現されうる。install_status（9値）は設置状況を表し、operational_status（6値）は運用状況を表す。operational_status は Repair in Progress・DR Standby・Ready を含む「運用状態」であり、稼働可否の二値ではない。この2軸は独立しており、install_status を Retired に変えても operational_status は自動では変わらない。

第3の軸である life_cycle_stage は選択肢ではなく参照フィールドで、有効な組み合わせは life_cycle_control テーブル（147件）が対象テーブル別に定義している。Configuration Item向けは21件の有効組み合わせを持つ。ただし、このPDIでは life_cycle_stage が入っているCIは0件で、OOTBデモデータは install_status / operational_status ベースで運用されていた。

2-5. データ品質の定義状況

CMDB Health の指標定義（cmdb_health_metric）は17件あり、Audit・Completeness・Duplicate・Orphan・Staleness などが含まれる。staleness rule（更新停滞の判定）は1件定義され、既定は60日でした。

一方で、cmdb_health_orphan_rule・cmdb_reconciliation_definition・cmdb_datasource_precedence はいずれも0件で未定義でした。指標の枠組みはOOTBに用意されている。ただし、孤立CIの判定基準や複数ソース間の属性優先順位は、導入時に自社で定義しないと機能しない領域として残されている。

この構成を土台に、ここから先は登録経路の統制・クラスと関係の標準セット・状態の使い分けと退役の後始末・データ品質のKPIと棚卸しの回し方を一つずつ確定していく。自社で決めるパラメータ一覧・RACI・代替案の採否まで、あわせて示す。