ServiceNowのCMDB構築で失敗しないための4つのポイント
目次
※CMDB（Configuration Management Database / 構成管理データベース）
ITシステムを構成するあらゆる要素（ハードウェア、ソフトウェア、ネットワーク、設定、文書、契約情報など）と、それらの関係性を一元管理するデータベース。
デジタルソリューション事業本部
デジタルビジネス事業部
ServiceNow 推進担当
シニアエキスパート
ServiceNow CTA（Certified
Technical Architect）資格を保有
島貫 航二
AI時代における構成管理ことはじめ
AI時代では、サイバー攻撃の高度化・自動化・高速化が進む一方、クラウドやSaaS、デバイス、AIの利用拡大により、企業が管理すべきIT資産も増加・複雑化しています。そのため「自社のサービスを管理し、サービスを構成するIT資産がどこにあり、どこで動き、何とつながり、誰が管理しているのか」を正しく把握することがビジネス上の決断やトラブル解決において意思決定の迅速化につながります。構成管理は企業のデジタル環境を正しく把握し、守るための土台です。効果的な構築・運用を考え、戦略的に進化させていくことが必要になります。
Excel管理をそのまま移行しない
構成情報と一覧表は本質的に異なる
多くの企業では、サーバ一覧、ネットワーク機器一覧、ライセンス一覧などをExcelで管理しています。しかし、これらは「一覧表」であり、CMDBが前提とする「関係性を持つ構成管理」とは構造が異なります。
例えば、Excelでは以下のような状態が一般的です。
・サーバ名
・IPアドレス
・OS
・保守期限
・管理部署
・システム名
これらは単一行に集約されており、アプリケーション、サービス、ネットワーク、保守契約との関連性が分離されていません。一方、ServiceNowのCMDBでは、サーバ、アプリケーション、データベース、契約、担当組織などを独立したCIまたは関連情報として管理し、それらをリレーションとして接続する思想が前提になります。そのため、Excel台帳をそのままインポートすると、以下の問題が発生しやすくなります。
・ServiceNow標準のCMDBクラス、テーブルを利用できない
・カスタマイズ属性が大量に発生する
・CI定義が曖昧になる
・重複CIが大量発生する
・リレーションが未整備となる
・影響分析が機能しない
CMDB構築では、まず「現在のExcelは何を管理しているのか」を棚卸しし、構成情報・資産情報・契約情報・運用メタ情報を分離した上で、目的に応じて再構築する必要があります。
保守契約情報をCIへ直接埋め込まない
保守契約は構成情報とは性質が異なる
多くの企業では、保守期限や保守ベンダー情報を構成情報の一部として管理しているケースが見られます。例えば以下のような列です。
・保守会社
・保守開始日
・保守終了日
・契約番号
・SLA
・保守連絡先
運用上は必要な情報ですが、これらは本来「契約情報」であり、CIそのものの属性ではありません。CIにこれらを直接持たせると、以下の問題が起こります。
・契約更新のたびに大量CI更新が発生する
・同じ内容を複数CIへ重複登録する
・契約単位での可視化、集計が困難になる
・契約変更履歴が追跡しにくい
ServiceNowでは、契約情報は別テーブルで管理し、CIと関連付ける構造、もしくは技術サービスオファリングと関連付ける構造が推奨されます。特に、ハードウェア資産管理（HAM）や契約管理との統合を見据える場合、CMDBに何の情報を持たせるべきかを明確にし、情報の性質を厳密に分離することが重要です。
「運用上便利だから入れる」が技術的負債になる
実務では、「画面を開いたときに全部見えた方が便利」という理由でCIへ情報を集約したくなる傾向があります。しかし、この設計は短期的には便利でも、中長期ではデータ重複と保守負荷を増加させます。特にServiceNowでは、DiscoveryやIntegration Hub（統合ハブ）、サービスグラフコネクタを用いた自動同期を行うケースが多く、責任境界が曖昧な属性は競合更新の原因になります。そのため、CMDB設計では「誰が」「どのタイミングで」「何を正とするか」を事前に定義する必要があります。
ベンダー依存の構成情報を標準化する
納品物ごとの粒度差がCMDB品質を壊す
多くの企業では、システムごとに異なるSIベンダーが導入・保守を担当しています。その結果、構成情報の粒度や記載ルールが企業全体として統一されていないケースが一般的です。例えば、あるベンダーは以下の区分をCIとして登録します。
・Webサーバ
・APサーバ
・DBサーバ
一方、別ベンダーでは以下のようにCIが細分化される場合があります。
・VM
・ミドルウェア
・JVM
・アプリケーション
・バッチ
この状態でCMDBへ統合すると、粒度が一致せず、システムを横断した分析が困難になります。
特に以下の機能で問題が顕在化します。
・変更影響評価
・サービスマッピング
・障害影響分析
・CSDM準拠
・KPI集計
CSDMを意識した論理モデル整理が重要
※CSDM（Common Service Data Model /共通サービスデータモデル）
ビジネスとITサービスや構成管理データベース（CMDB）内のデータを標準化・構造化するためのフレームワーク。
ServiceNowでは、CSDMをベースに基盤データや構成情報を整理する考え方が基本となります。CSDMは単なるデータモデルではなく、「ビジネスサービス」「アプリケーションサービス」「技術サービス」「CI」の責任境界を整理するフレームワークです。多くの企業では、インフラ中心の管理文化が強く、サービスの視点が不足しやすい傾向があります。そのため、CMDB構築では以下を明確化する必要があります。
・どこまでをCI化するか
・サービス単位をどう定義するか
・アプリケーション粒度をどう統一するか
・リレーションの必須ルールをどうするか
重要なのは、全システムで完全統一を目指すことではなく、「最低限比較可能な粒度」を定義することです。
CMDB運用体制を先に設計する
「誰が更新責任を持つか」が最重要
CMDBは運用開始後に時間が経過するにつれて品質が劣化していきます。
したがって、鮮度維持をするための運用の仕組みが不可欠です。特に日系企業では、以下の状態が発生しやすくなります。
・更新責任者が不明
・ベンダーごとに更新ルールが異なる
・障害時だけ参照される
・棚卸しイベント時しか更新されない
この結果、「最新情報ではないので誰も見なくなる」という悪循環に陥ります。
CMDBでは、データそのものよりもガバナンス設計が重要です。
更新プロセスをITSMへ組み込む
CMDB単体で運用すると、更新漏れが発生しやすくなります。そのため、以下との連携が重要です。
・変更管理
・リリース管理
・インシデント管理
・問題管理
・資産管理
・CIのライフサイクル
例えば、変更管理完了時にCI更新を必須化することで、構成変更との同期精度を高めやすくなります。また、CMDB品質KPIとして以下を定義する企業もあります。
・オーナー未設定率
・リレーション欠損率
・Discovery不一致率
・更新期限超過率
CMDBは「登録すること」が目的ではなく、「運用プロセスの信頼性を支えるデータを維持すること」が本来の目的です。
まとめ
ServiceNowのCMDB構築では、単なるデータ移行ではなく、「構成管理そのものを再定義する」視点が重要です。特に日系企業では、Excel中心の属人的管理、契約情報との混在、ベンダー依存による粒度不整合が典型的課題になります。そのため、実務では以下が重要になります。
・CIの責任範囲を明確化する
・契約情報と構成情報を分離する
・粒度標準を定義する
・運用ガバナンスを先行設計する
CMDBは、単に「情報を集める仕組み」ではありません。変更管理、障害対応、IT統制、サービス可視化を支える運用基盤です。そのため、ServiceNow導入時には製品機能だけでなく、自社の運用文化・委託構造・データ責任分界を含めて設計する必要があります。特に、既存台帳をそのまま移行するアプローチは、短期的には移行負荷を下げても、中長期ではCMDB形骸化を招く可能性があるため注意が必要です。
島貫 航二
2001年にＤＴＳへ入社し、大手通信事業者のBPO業務やデータセンター事業の支援を担当。
2008年からはプロジェクトマネージャーとして、海外データセンタービジネスの支援に携わる。
海外業務をきっかけに英語力向上の必要性を感じ、2か月間のＤＴＳインドグローバル研修に参加。
2019年にはServiceNowを活用したDXビジネス「ReSM Plus」に参画し、ServiceNow関連ビジネスの立ち上げを推進。
2022年からはServiceNow推進担当として、顧客の業務効率・生産性向上にチームで取り組んでいる。