ServiceNowのCIとAssetの違い｜CMDBと資産管理で迷わない判断基準

ServiceNowのCMDBや資産管理を学ぶと、CI と Asset の違いで迷いやすくなります。サーバー、PC、ソフトウェア、ネットワーク機器など、同じものを指しているように見える場面があるためです。

結論から言うと、CIはサービス運用や影響分析のために管理する構成要素で、Assetは購入、契約、所有、廃棄など資産ライフサイクルを管理する対象です。同じ物理機器がCIでもAssetでもあることはありますが、管理したい目的が違います。

CMDB・CI・CSDMの理解をCSA模試で確認する
CI、関係性、CMDB Health、CSDMの判断問題を確認できます。

CIとAssetの違いは「運用上の構成要素」か「資産」か

CIとAssetは、どちらもIT部門が管理する対象です。ただし、見ている観点が違います。

CIはサービス運用のための構成情報

CIはConfiguration Itemの略で、サービスを構成する要素を表します。サーバー、アプリケーション、データベース、ネットワーク機器、サービスそのものなど、運用上の影響分析に必要な対象をCMDBで管理します。

CIで重要なのは、単体の名前やスペックだけではありません。どのアプリがどのサーバーに依存しているか、どのサービスに影響するか、どの関係性を持っているかが大切です。インシデントや変更管理で「この障害はどのサービスへ影響するか」を見るためにCIが使われます。

そのため、CIは単なる台帳ではなく、運用判断の材料です。CMDB Healthや関係性の品質が悪いと、障害対応や変更影響分析の精度も落ちます。

CSDMを外すとCMDBが再利用しづらくなる

ServiceNowのCMDBを実務で使う場合、CSDMを避けて考えると、あとから困りやすくなります。CSDMは、Business Application、Application Service、Technical Service、CIなどの関係を整理するための考え方で、ServiceNow内の複数製品でCMDBを再利用しやすくする土台になります。

たとえば、サーバーCIを大量に登録しても、それがどのApplication Serviceに紐づき、どのBusiness Applicationや業務に影響するのかが分からなければ、障害時の影響分析に使いづらくなります。CIを登録するだけでなく、関係性とサービスの粒度をどう設計するかが重要です。

Assetは資産ライフサイクルを管理する対象

Assetは、購入、所有、契約、割当、保守、廃棄など、資産としてのライフサイクルを管理する対象です。PCやサーバーのようなハードウェア、ソフトウェアライセンス、契約情報などが関係します。

Assetで重要なのは、誰に割り当てられているか、いつ購入したか、費用はいくらか、契約や保証はどうなっているか、廃棄済みかといった情報です。運用影響よりも、所有やコスト、コンプライアンスの管理に近い領域です。

たとえば、ノートPCはAssetとして購入・貸与・返却・廃棄を管理します。一方で、そのPCをサービス影響分析の対象として扱う必要があるならCIとしても管理される可能性があります。

同じものがCIにもAssetにもなることがある

CIとAssetは排他的な分類ではありません。同じ物理サーバーが、Assetとして購入・保守契約を管理され、CIとしてサービス構成や依存関係を管理されることがあります。

ここで大切なのは、「同じ実物を見ているが、管理目的が違う」と理解することです。資産担当者は費用や契約を見たい。運用担当者はサービスへの影響を見たい。どちらも必要ですが、同じ項目を同じ粒度で管理すればよいわけではありません。

実務では、CIとAssetを自動連携させる設計もあります。ただし、連携すればすべて解決するわけではなく、どのタイミングで作成するか、どの状態を同期するか、廃棄や退役をどう扱うかを決めておく必要があります。

データソースと更新責任を決めないとCMDBは崩れる

CMDBの品質は、最初に登録したときではなく、運用で更新され続けるかどうかで決まります。Discovery、Service Mapping、Import Set、手動登録、外部資産管理ツールなど、どの入口からCIやAssetが入るのかを整理しておく必要があります。

特に重要なのは、更新責任です。サーバーの所有者、アプリケーションサービスのオーナー、資産の管理部門、廃棄判断者が曖昧だと、CIとAssetの状態がずれていきます。CMDBを「台帳」として作るだけでなく、「誰が、どのタイミングで、何を更新するか」を決めておくことが実務では欠かせません。

実務での確認順

CIとAssetで迷ったときは、次の順で確認すると整理しやすくなります。

1. 管理したい目的は運用影響か、資産ライフサイクルか
2. インシデント、変更、問題管理で参照する必要があるか
3. 購入、契約、費用、廃棄を管理する必要があるか
4. CIとAssetを同じ粒度で持つべきか
5. 関係性や状態の更新責任者は誰か

障害時の影響分析や変更管理で使うならCIの観点が重要です。費用、所有、契約、在庫、廃棄を追うならAssetの観点が重要です。CMDBの全体像は、既存記事の ServiceNow CSAのCMDB Health解説 もあわせて確認するとつながりが見えやすくなります。

よくある失敗例

• CMDBをExcel台帳の置き換えとして作る: 関係性やサービス粒度がないと、影響分析に使えません。
• 重複CIを放置する: 同じサーバーやアプリが複数CIとして存在すると、インシデントや変更の紐づけが崩れます。
• CSDMを後回しにする: テーブルは埋まっていても、サービス単位で再利用しにくいCMDBになります。
• Assetの状態とCIの状態を同期しない: 廃棄済み資産が運用中CIのまま残るなど、現実とデータがずれます。

CSA/CISではどう問われるか

CSAでは、CIをCMDBで管理する構成要素として理解しているかが問われやすいです。問題文に「構成」「関係性」「影響分析」「サービスとの依存関係」が出てきたらCIを考えます。

CISでは、対象アプリケーションやITSMプロセスの中で、CIがインシデント、変更、問題管理にどう関係するかを見られることがあります。Assetは資産管理やライフサイクルの文脈で登場しやすいため、目的の違いで切り分けることが大切です。

FAQ

まとめ

CIとAssetは、同じ機器やソフトウェアを扱うことがあります。しかし、CIは運用や影響分析のための構成要素、Assetは購入や契約を含む資産ライフサイクルの管理対象です。

実務で迷ったら、「障害や変更の影響を見るために必要なのか、それとも所有・契約・費用を管理したいのか」を確認してください。この判断軸があると、CMDBと資産管理の役割分担が見えやすくなります。