資産管理の自動化の成功を左右するCI定義と関係性管理

CIとは何か：CMDBの基本単位を正しく理解する

CI（Configuration Item）とは、ITサービスのデリバリーまたはサポートに関連し、管理が必要なあらゆる構成要素のことです。ITILの定義ではハードウェア・ソフトウェア・ドキュメント・人員まで含みますが、実務においては「管理することで価値が生まれるもの」をCIとして選定することが重要です。

CMDBはこれらCIとその属性・関係性を一元的に管理するデータベースです。ServiceNowでは、CMDBはITSM（インシデント・変更・問題管理）、ITSM（サービスカタログ）、SAM（ソフトウェア資産管理）など複数のプロセスの基盤データとして機能します。CIの定義精度がこれらすべてのプロセスの品質に影響します。

よくある誤解は、「発見できるものはすべてCIとして登録する」という方針です。自動探索ツール（ServiceNow Discovery等）は多くのデバイス・ソフトウェアを検出しますが、すべてを管理対象CIとすることは管理コストの爆発を招きます。管理の目的（何のためにこのCIを管理するか）を先に定義し、そこから逆算してCI範囲を決定することが正しいアプローチです。

CI定義が不適切だと何が起きるか

CI定義が不明確なままCMDB構築を進めた場合、最初に現れる問題は重複CIの大量発生です。複数の探索ツール（SCCM、Jamf、ServiceNow Discoveryなど）が同一の物理・仮想マシンを異なるキー属性で登録することで、CMDBに同一資産が複数のCIとして存在する状態が生まれます。重複CIはライセンスカウントの誤算やインシデント管理の混乱を引き起こします。

次に現れるのが不整合データの蓄積です。CI属性（ホスト名・IPアドレス・担当者・ビジネスサービスへの紐付けなど）が複数のシステムから異なる値で更新されるため、どの値が正しいかが不明な状態になります。これが慢性化すると、CMDBへの信頼が組織全体で失われ「CMDBは参考程度」という扱いになってしまいます。

SAMの文脈では特に深刻な問題が生じます。ソフトウェアCIが正確に定義されていなければ、インストール済みソフトウェアとライセンスの紐付けが機能せず、コンプライアンス計算の精度が著しく低下します。Oracle等の複雑なライセンス計算においては、CI定義の誤りが数千万円単位のライセンス過払いまたは違反リスクに直結します。

効果的なCI定義のための4つの原則

原則1：管理目的の明確化から始める。「なぜこのCIを管理するか」を先に定義します。インシデント対応に必要か、ライセンス計算に必要か、変更管理に必要かによってCI粒度と必須属性が変わります。管理目的が複数ある場合は優先順位をつけ、段階的に管理範囲を広げる計画を立てます。

原則2：一意識別キー（Identification Rule）の設計。各CI類型ごとに「何をもって同一のCIとみなすか」のルールを定義します。物理サーバーはシリアル番号、仮想マシンはUUID、ソフトウェアはPublisher＋Product Name＋Versionの組み合わせなど、CI類型ごとに識別キーの設計を行います。これが重複排除の基盤になります。

原則3：データソースの権威付け（System of Record）の確立。各属性値は「どのシステムが正しい値を持つか」を定義し、そのシステムをSystem of Record（SoR）として権威付けします。例えばホスト名はActive Directory、ハードウェア仕様はSCCM、担当者情報はHRシステムというように分担を明確化し、他ソースからの上書きをコントロールします。

原則4：CI分類階層（Class Hierarchy）の適切な設計。ServiceNowのCMDB Class Modelに準拠しつつ、自社環境に合わせたカスタムクラスを最小限で追加します。クラスを細分化しすぎると管理コストが増大するため、既存クラスへの属性追加で対応できる場合は新規クラス作成を避けることが原則です。

CI関係性（Relationship）の設計と管理

CIとCIの関係性（Relationship）の管理は、CMDBが単なる台帳ではなくサービスマップとして機能するための核心部分です。関係性には「Runs on（ソフトウェアがサーバー上で稼働する）」「Hosted on（仮想マシンがハイパーバイザー上に存在する）」「Depends on（アプリがDBに依存する）」などの類型があります。

SAMにおいて特に重要な関係性はソフトウェアインストールとソフトウェアモデルの紐付けです。探索ツールが検出した「インストール済みソフトウェア（Software Install CI）」を正規のソフトウェアカタログ（Software Model）に正規化・紐付けすることで、はじめてライセンスコンプライアンス計算が可能になります。この正規化プロセスの設計精度が、SAM全体の精度を決定します。

また、ビジネスサービスとIT構成要素の関係性（Business Service Map）を維持することで、インシデント発生時の影響範囲分析や変更管理における影響評価が自動化できます。ただし、関係性の自動生成に頼りすぎると不正確な関係性が大量に生成されるため、自動生成後の人的レビューとクレンジングのプロセスを必ず設計に組み込みます。

CMDBデータ品質の継続的維持方法

CMDBは一度構築したら終わりではなく、IT環境の変化に追従して継続的に維持管理が必要な生きたデータベースです。データ品質の劣化を防ぐには、まずデータ品質の測定指標（KPI）を定義することから始めます。代表的な指標としては、CI属性の完全性（必須項目の充足率）、重複CI数、CI更新の鮮度（最終探索日からの経過日数）、関係性の整合率などがあります。

次に、ServiceNowのHealth Log Analytics（HLA）やCMDB Health Dashboardを活用し、データ品質を定期的に可視化・モニタリングする体制を構築します。品質指標が閾値を下回った場合にアラートが発報されるよう設定し、担当者が能動的に問題CIを検出・修正できる仕組みを作ります。

さらに、CMDB更新プロセスをITSMの変更管理と連携させることが重要です。変更要求（RFC）の承認・実施に合わせてCMDBを更新するフローを確立することで、IT環境とCMDBデータのズレを最小化できます。人手による更新だけに依存せず、変更管理完了トリガーで探索を自動実行するオートメーションと組み合わせることが、持続可能なデータ品質維持の鍵です。

このトピックについて専門家に相談する

ServiceNow CMDBのCI定義設計から自動化構築・データ品質改善まで、IT資産管理の自動化プロジェクトを成功に導くための専門的サポートを提供します。現状のCMDB課題のヒアリングからお気軽にご相談ください。