ServiceNowにおけるAsset-CI連携の高度化：Product Instance 2.0導入による統一ライフサイクル管理の実践ガイド

序章：資産と構成、2つの世界の統合

ITAMとITSMにおけるデータ連携の戦略的重要性

現代の企業IT環境において、IT資産管理（ITAM）とITサービス管理（ITSM）は、それぞれが独立した重要な役割を担っています。ITAMは、IT資産のライフサイクル全体を通じてコストを最適化し、契約コンプライアンスを維持し、リスクを管理することに焦点を当てます 。一方、ITSMは、インシデント、問題、変更といったプロセスを通じて、ITサービスの安定的な提供と迅速な障害復旧を目的とします 。  

これら二つの領域は異なる目的を持ちながらも、その管理対象となるデータは密接に関連しています。例えば、あるサーバーに障害が発生した場合（ITSM）、そのサーバーの保証期間や保守契約情報（ITAM）を即座に参照できなければ、迅速かつコスト効率の高い対応は困難です。同様に、サーバーの構成変更を計画する際（ITSM）には、その変更がライセンス契約（ITAM）に与える影響を正確に評価する必要があります。

このように、ITAMとITSMのデータ連携は、サイロ化した情報を統合し、以下のような戦略的価値を創出するための不可欠な要素です。

• 意思決定の迅速化と精度向上: 変更管理プロセスにおいて、影響を受けるCIに関連する資産情報を参照することで、財務的影響や契約上の制約を考慮した、より精度の高い影響分析が可能になります 。  
• 運用効率の向上: インシデント対応時に、担当者はCIレコードから関連するAssetレコードにシームレスにアクセスし、保証情報やベンダー連絡先を迅速に把握できます 。  
• TCO（総所有コスト）の可視化: CIに関連するインシデントや変更のコストを追跡し、それを資産の購入・維持コストと組み合わせることで、ITサービス全体の総所有コストを正確に把握できます。

ServiceNowプラットフォームは、このITAMとITSMの連携をネイティブにサポートする強力な基盤を提供します。しかし、その実装はプラットフォームの進化と共に、より洗練され、より堅牢なアーキテクチャへと変遷しています。

本レポートが解説する標準実装からPI2.0への進化の道筋

本レポートは、ServiceNowプラットフォームにおける構成アイテム（CI）と資産（Asset）の連携に関する技術的な実装方法を、二つの段階に分けて詳細に解説することを目的とします。

第1部では、従来から提供されている標準的なAsset-CI連携のアーキテクチャを解き明かします。製品カタログ、モデル、そして連携の鍵となるモデルカテゴリの役割を定義し、ビジネスルールやスクリプトインクルードといった技術的要素が、どのようにしてAssetとCIの自動生成と属性同期を実現しているのかを深掘りします。また、この従来型アーキテクチャが内包していたステータス管理の課題についても明らかにします。

第2部では、ServiceNowのXanaduリリース以降に導入された革新的なデータモデル、Product Instance 2.0（PI2.0）によるパラダイムシフトに焦点を当てます。PI2.0が、なぜ従来の課題を解決するために導入されたのか、その背景にあるCommon Service Data Model（CSDM）の思想と共に解説します。そして、Asset、CI、さらには顧客資産を管理するInstall Base Item（IBI）までも統合する新しいアーキテクチャと、その中核をなす統一ライフサイクルフィールドの技術的な仕組みを詳説します。

第3部では、理論から実践へと移り、PI2.0導入実践プレイブックとして、ServiceNow公式のベストプラクティスに基づいた具体的な導入手順を提示します。導入前の「分析」、システムを有効化する「有効化」、そして導入後のデータ整合性を維持するための「データガバナンス」という3つのフェーズに沿って、実務的なステップを解説します。

最後に第4部では、PCセットアップのような高度なユースケースを通じてPI2.0の真価を探るとともに、導入におけるベストプラクティスと将来的な展望について論じます。

本レポートを通じて、読者はServiceNowにおけるAssetとCIの連携に関する深い技術的知見を得るとともに、CSDMに準拠した最新のデータアーキテクチャへ移行するための実践的なロードマップを描くことが可能となります。

第1部：標準的なAsset-CI連携のアーキテクチャ

ServiceNowにおけるAssetとCIの連携は、プラットフォーム上でIT資産の財務的側面と運用的側面を一元的に管理するための根幹をなす機能です。この連携の仕組みを理解するためには、まずそれぞれの役割を明確にし、それらをつなぐデータモデルと自動化ロジックを把握する必要があります。

1.1. AssetとCIの役割分担：財務的価値と運用上の実体

AssetとCIは、しばしば同じ物理的・論理的実体を指しますが、ServiceNowプラットフォーム上では明確に異なる目的とデータ構造を持っています。

Assetの定義と責務

資産（Asset）は、主にIT資産管理（ITAM）の文脈で用いられ、組織が所有するIT資産の財務的・契約的側面を管理します。データはalm_assetテーブルおよびその拡張テーブルに格納されます 。Assetレコードが追跡する主要な属性は以下の通りです。  

• 財務情報: 購入日、発注番号（PO Number）、取得価額、減価償却情報、残存価額など 。  
• 契約情報: 保証期間、保守契約、リース契約、ライセンス契約など 。  
• ライフサイクル情報: 資産の全ライフサイクル（要求、調達、在庫、展開、保守、廃棄）を追跡します。このライフサイクルは、CIがCMDBに存在する期間よりも長く、調達前の要求段階から、廃棄後の記録保管期間までをカバーします 。  

端的に言えば、Assetは「そのモノにいくら支払い、どのような権利を持ち、いつまで使えるのか」というビジネス上の問いに答えるためのレコードです。

CIの定義と責務

構成アイテム（CI）は、ITサービス管理（ITSM）の中核をなす構成管理データベース（CMDB）の基本単位であり、ITサービスを構成する運用上の実体を管理します。データはcmdb_ciテーブルおよびその拡張テーブル（cmdb_ci_server、cmdb_ci_computerなど）に格納されます 。CIレコードが追跡する主要な属性は以下の通りです。  

• 技術仕様: OSのバージョン、メモリ容量、CPUの種類、インストールされているソフトウェア、IPアドレスなど 。  
• 状態情報: 稼働状況（Operational Status）、インストール状態（Install Status）など。
• 関係性（リレーションシップ）: 他のCIとの依存関係や接続関係。例えば、あるアプリケーションサーバーがどのデータベースサーバーに依存しているか、といった情報です。
• 運用履歴: 関連するインシデント、問題、変更の履歴。

CIは、「そのモノがどのように機能し、他の何と関連しており、サービスにどのような影響を与えるか」という技術的・運用上の問いに答えるためのレコードです。この情報があることで、インシデント発生時の影響範囲の特定や、変更計画時のリスク評価が可能になります 。  

両者の関係性

すべてのIT資産がAssetとCIの両方を持つわけではありません。例えば、物理的な実体のないソフトウェアライセンスの権利自体はAssetとして管理されますが、通常はCIを持ちません。逆に、クラウド上で動的に生成された仮想サーバーは、運用上管理すべきCIですが、直接的な購入費用が発生しないため、対応するAssetレコードを持たない場合があります 。  

しかし、企業のITインフラを構成する多くの物理サーバー、ネットワーク機器、PCなどは、財務的な側面（Asset）と運用上の側面（CI）の両方を持ち合わせており、これら2つのレコードを原則として1対1の関係で正確に紐付けて同期させることが、ITAMとITSMを連携させる上での鍵となります。

1.2. 連携の要：製品カタログ、モデル、モデルカテゴリの役割

AssetとCIの自動的な連携とデータの一貫性を支えているのが、製品カタログを構成する「製品モデル」と「モデルカテゴリ」という2つの重要なデータオブジェクトです。

製品モデル (Product Model) [cmdb_model]

製品モデルは、特定のバージョンや構成を持つ資産のテンプレートとして機能します 。これは、個々の資産レコード（AssetやCI）を作成する際の標準的な仕様を定義するものです。例えば、「Apple MacBook Pro 14-inch, M3 Pro, 18GB RAM, 512GB SSD」といった具体的な製品仕様が製品モデルとして登録されます。  

製品モデルはcmdb_modelテーブルに格納され、AssetレコードとCIレコードの両方から参照されます 。これにより、以下のような利点が生まれます。  

• データの標準化: 個々の資産レコードにメーカー名やモデル名を自由に入力させるのではなく、標準化された製品モデルを選択させることで、データの揺らぎを防ぎ、正確なインベントリ管理とレポート作成を可能にします。
• 情報の一元管理: 製品のライフサイクル情報（サポート終了日など）やベンダー情報といった共通情報を製品モデルに集約することで、管理が効率化されます。
• 多様な資産タイプの管理: 製品モデルには、ハードウェアモデル、ソフトウェアモデル、消耗品モデル、そして複数のモデルを組み合わせたバンドルモデルなど、様々な種類があり、多岐にわたるIT資産を体系的に管理できます 。  

モデルカテゴリ (Model Category) [cmdb_model_category]

モデルカテゴリは、AssetとCIの連携において最も重要な役割を果たすオブジェクトです。その主な機能は、AssetクラスとCIクラスを関連付けることにあります 。  

例えば、「Computers」というモデルカテゴリを作成し、そこにAssetクラスとしてalm_hardwareを、CIクラスとしてcmdb_ci_computerを指定します。この設定が、プラットフォームに対して「このカテゴリに属するモデルから作成されるモノは、財務資産（Hardware Asset）であり、かつ運用上の構成アイテム（Computer CI）でもある」というポリシーを宣言する役割を果たします。

このモデルカテゴリの設定が、後述するビジネスルールによるAssetとCIの自動生成プロセスのトリガーとなります。モデルカテゴリにAssetクラスとCIクラスの両方が定義されている場合、どちらか一方のレコードが作成されると、もう一方のレコードが自動的に生成される仕組みが発動します 。したがって、モデルカテゴリは単なる分類項目ではなく、ServiceNowプラットフォーム上でのオブジェクトの振る舞いを定義する、一種のポリシージェネレーターとして機能していると理解することが重要です。この視点を持つことで、新しい種類の資産を導入する際に、場当たり的な設定を防ぎ、一貫性のあるデータガバナンスを設計することが可能になります。  

1.3. 同期の舞台裏：ビジネスルールとスクリプトインクルードによる技術的実装

AssetとCIの自動生成と属性同期は、ServiceNowプラットフォームのバックエンドで動作するビジネスルールとスクリプトインクルードによって実現されています。この技術的な実装は、大きく「自動生成」と「属性同期」の2つのメカニズムに分けられます。

1.3.1. 紐付けの技術的実装：参照フィールドによる直接リンク

AssetとCIの1対1の紐付けは、特別な共有IDを必要とせず、ServiceNowのデータモデルに組み込まれた参照フィールドによって直接的に実現されます。

• alm_asset（資産）テーブルには、Configuration item という名前の参照フィールドが存在します。このフィールドには、対応するCIレコードのユニークなシステムID（sys_id）が格納されます。
• cmdb_ci（構成アイテム）テーブルには、Asset という名前の参照フィールドが存在します。このフィールドには、対応するAssetレコードのsys_idが格納されます。

AssetレコードからCIが自動生成される際、システムはこれら2つのフィールドにお互いのsys_idを自動的に設定します。これにより、2つのレコード間に直接的かつ永続的な双方向のリンクが確立され、これが1対1関係の技術的な基盤となります 。  

1.3.2. 自動生成と属性同期のメカニズム

この直接リンクを確立し、維持するための自動化ロジックは、ビジネスルールとスクリプトインクルードによって実装されています。

• 自動生成:
  • alm_assetテーブルに新しいレコードが挿入されると、Create CI on insertビジネスルールが実行されます。このルールは、モデルカテゴリの定義に基づき、対応するCIレコードを生成し、前述の参照フィールドを相互に設定します 。  
  • 逆に、cmdb_ciテーブルではCreate Asset on insertビジネスルールが同様の役割を果たします 。  
  • これらのロジックはAssetandCIスクリプトインクルードに集約されています 。  
• 属性同期:
  • 一度紐付けられると、Update CI fields on change（alm_assetテーブル上）とUpdate Asset fields on change（cmdb_ciテーブル上）というビジネスルールが、両レコード間のデータの一貫性を保ちます 。  
  • これらのルールはAssetAndCISynchronizerスクリプトインクルードを呼び出し、Asset CI Field Mapping [alm_asset_ci_field_mapping] テーブルで定義されたフィールド（シリアル番号、場所など）の値を同期させます 。  

1.3.3. シリアル番号の役割：一意な識別子としてのキー

シリアル番号（Serial Number）は、参照フィールドのような直接的なリンク機構ではありませんが、正しいレコード同士を結びつけ、データの重複を防ぐための一意な識別キーとして極めて重要です。

• 初期紐付け: Asset作成時にシリアル番号が入力されると、自動生成されるCIにもその値がコピーされ、両者が同じ物理的実体であることを保証します 。  
• Discoveryと突合: Discoveryツールがシリアル番号を持つデバイスを発見すると、ServiceNowの**IRE（Identification and Reconciliation Engine）**がそのシリアル番号をキーにCMDBを検索します。一致するCIが見つかれば、新規作成の代わりに既存レコードを更新するため、データの重複が防止されます 。  

このように、標準アーキテクチャは、参照フィールドによる直接リンクと、シリアル番号のような識別キーによる突合、そしてビジネスルールによる自動化を組み合わせることで、AssetとCIの連携を実現しています。

1.4. 従来のステータス管理とその課題

標準的な連携アーキテクチャにおける最も複雑な側面の一つが、ライフサイクル状態の管理です。AssetとCIはそれぞれ独自のステータスフィールドを持っており、それらの同期は単純な1対1のマッピングではありません。

Assetのライフサイクルは、主にState（状態）とSubstate（サブステート）の2つのフィールドで管理されます。例えば、「In Stock」（在庫あり）というStateの中に、「Available」（利用可能）や「Pending Disposal」（廃棄待ち）といったSubstateが存在します。

一方、CIのライフサイクルは、歴史的な経緯から複数のフィールドにまたがって管理されています。

• Install Status (インストールステータス)
• Hardware Status (ハードウェアステータス)
• Operational Status (運用ステータス)

これらのフィールドは、前述の同期メカニズムによってAssetのState/Substateと論理的にマッピングされています。しかし、その関係は複雑です。例えば、あるハードウェア資産のStateが「In Stock – Pending disposal」に設定された場合、対応するCIのInstall Statusは「In Disposition」に設定される、といった具合です 。  

この複雑なマッピングは、以下のような課題を生み出していました。

• データの一貫性の欠如: 同期ロジックが複雑であるため、カスタマイズや外部システムからのデータ投入によって、AssetとCIのステータスが乖離（データドリフト）しやすくなります。例えば、Assetレコード上では「廃棄済み」となっているにもかかわらず、CMDB上ではCIが「稼働中」として表示され続けるといった事態が発生し、レポートの信頼性を著しく損ないます 。  
• 管理の複雑化: ライフサイクル状態を管理するための信頼できる唯一の情報源（Source of Truth）が存在せず、管理者は複数のステータスフィールドの関係性を常に意識する必要がありました。これは、自動化ワークフローの設計やセキュリティルール（ACL）の設定を複雑にし、ヒューマンエラーを誘発する原因となっていました。
• 拡張性の限界: 組織独自のライフサイクルステータスを追加しようとすると、複数の選択リストを更新し、複雑な同期ロジックを修正する必要があり、多大な工数とテストを要しました。

これらの課題は、IT資産のライフサイクル全体を正確かつ一貫して管理する上で大きな障害となっており、よりシンプルで堅牢なデータモデルへの移行、すなわちProduct Instance 2.0の導入を促す直接的な要因となったのです。

第2部：Product Instance 2.0によるパラダイムシフト

従来のAsset-CI連携が抱えるステータス管理の課題を根本的に解決するため、ServiceNowはXanaduリリース以降、Product Instance 2.0（PI2.0）という新しいデータモデルを導入しました。これは単なる機能追加ではなく、資産と構成アイテムの管理方法に関する考え方を大きく変えるパラダイムシフトです。

2.1. PI2.0の概念：Asset、CI、IBIを統合する新たな視点

PI2.0導入の直接的な背景には、従来のデータモデルではAsset（財務資産）、CI（運用構成アイテム）、そして顧客に販売・提供された資産を管理するInstall Base Item (IBI) の間で、ライフサイクル状態の同期が取れず、データに不整合が生じるという深刻な問題がありました 。例えば、ITAMチームが資産を「廃棄済み」としても、ITSMチームのCMDBではCIが「稼働中」のまま残り、CSMチームが管理する顧客資産情報（IBI）とも乖離するといった事態です。  

この問題を解決するため、PI2.0はこれら3つの独立したオブジェクトを、単一の「製品インスタンス（Product Instance）」という概念の異なる側面として再定義しました。

• Asset: 製品インスタンスの「財務的側面」を表現します。
• CI: 製品インスタンスの「技術的・運用的側面」を表現します。
• IBI: 製品インスタンスの「顧客との関係性における側面」を表現します。

この統合的な視点により、物理的・論理的に同一である「一つのモノ」のライフサイクルを、異なる業務ドメイン（ITAM, ITSM, CSM）から見ても、常に一貫した状態で捉え、管理することが可能になります。これは、データのサイロ化を解消し、組織全体で信頼できる唯一の情報源（Single Source of Truth）を確立するための根幹となるアプローチです。

2.2. CSDMフレームワークにおけるPI2.0の位置づけと目的

Product Instance 2.0は、ServiceNowプラットフォーム全体の標準データモデルである**Common Service Data Model (CSDM)**の思想を具現化する、極めて重要なコンポーネントです。

CSDMは、ServiceNowが提供する多様な製品群（ITSM, ITAM, ITOM, CSM, SPMなど）が円滑に連携するための共通言語であり、データモデルの設計図（ブループリント）です 。CSDMに準拠することで、企業はITサービスとビジネスの関連性を明確にし、プラットフォーム全体の価値を最大化できます 。  

このCSDMのフレームワークにおいて、PI2.0は「Sell/Consume」ドメインや「Manage Technical Services」ドメイン（CSDMのバージョンにより呼称は変化）の基盤を支える役割を担います。CSDMが定義するビジネスサービスやテクニカルサービスが、最終的にどのような物理的・論理的リソース（＝製品インスタンス）によって提供されているのかを明確に紐付けることで、トップダウンのサービス視点とボトムアップの資産・構成視点を繋ぎ合わせます 。  

PI2.0を導入し、CSDMに準拠したデータモデルを構築する目的は、単なるデータ整理に留まりません。これにより、例えば以下のような高度な分析と運用が実現可能になります。

• あるサーバー（CI）で障害が発生した際に、そのサーバーがどのビジネスサービスに影響を与え（CSDM Service Mapping）、そのサーバーの資産価値や保守契約がどうなっているか（Asset）、そしてどの顧客に影響が及ぶか（IBI）を、一気通貫で瞬時に把握する。
• 特定のビジネスアプリケーション（CSDM Business Application）を構成する全製品インスタンスの総コスト（Asset）と運用リスク（CI）を評価し、投資対効果を判断する。

このように、PI2.0はCSDMの理念を技術的に実現し、データドリブンな意思決定を可能にするための不可欠なデータ基盤なのです。

2.3. アーキテクチャ解説：統一ライフサイクルフィールドがもたらすデータ一元化

PI2.0がもたらす最も大きなアーキテクチャ上の変革は、ライフサイクル状態管理の一元化です。

統一フィールドの導入

PI2.0の技術的な中核をなすのが、cmdb_pi_product_instanceテーブル（および関連テーブル）に導入された2つの新しい統一フィールドです 。  

• life_cycle_stage (Life Cycle Stage): ライフサイクルの大きな段階（例: Operational, In Stock, Retired）を管理します。
• life_cycle_stage_status (Life Cycle Stage Status): 各段階におけるより詳細な状態（例: In Use, Available, Pending Disposal）を管理します。

従来のステータスフィールド同期の無効化

PI2.0を有効化すると、最も重要な変更として、これまでAssetとCIの間で状態を同期させていた複雑なビジネスルールが無効化されます。具体的には、従来のCIステータスフィールド（install_status, operational_status, hardware_status）とAssetのState/Substate、そして新しい統一ライフサイクルフィールド間の同期ロジックが停止します 。  

これにより、ライフサイクル状態に関する信頼できる唯一の情報源（Source of Truth）が、この2つの新しい統一ライフサイクルフィールドに一本化されます。

同期メカニズムの変革

この変更は、アーキテクチャを根本的に変革します。従来のモデルが、それぞれ独立して状態を持つAssetとCIという「2つの時計」の時刻を、ビジネスルールという仕組みで必死に合わせ続けるようなものであったのに対し、PI2.0は全く異なるアプローチを取ります。

PI2.0では、製品インスタンスが持つ統一ライフサイクルフィールドが「一つのマスタークロック」として機能します。Asset、CI、IBIのいずれかでこのマスタークロックの値が更新されると、PI2.0の同期エンジンがその変更を検知し、関連する他のオブジェクトにもその状態を自動的に伝播・反映させます 。  

このアーキテクチャは、「オブジェクト間の双方向同期」という複雑でエラーを起こしやすい処理から、「単一の信頼できる情報源からの状態伝播」という、よりシンプルで堅牢なデータフローへと進化しています。これにより、同期エラーの発生確率が劇的に低下し、データの一貫性がデータモデルのレベルで保証されるのです。

以下の表は、従来のCIステータスが、PI2.0の統一ライフサイクルステージにどのようにマッピングされるかの概念的な対比を示したものです。実際の移行に際しては、自社のカスタム値を含めて詳細なマッピング定義が必要です。

従来のフィールド	従来の値（例）	PI2.0 Life Cycle Stage	PI2.0 Life Cycle Stage Status	解説
install_status	1 (Installed)	Operational	In Use	資産が稼働中であり、サービスを提供している状態。
install_status	7 (In Stock)	In Stock	Available	資産が在庫にあり、展開可能な状態。
install_status	6 (Retired)	Retired	Disposed	資産が正式に廃棄処理された状態。
hardware_status	pending_disposal	Retired	Pending Disposal	資産が廃棄待ちの状態。
install_status	2 (On Order)	On Order	–	資産が発注済みで、納品を待っている状態。
install_status	4 (In Maintenance)	Operational	In Maintenance	資産がメンテナンス中で、一時的にサービスを停止している状態。

Google スプレッドシートにエクスポート

2.4. データモデル詳解：cmdb_pi_product_instanceテーブルの構造と役割

PI2.0アーキテクチャの中心に位置するのが、cmdb_pi_product_instanceテーブルです。このテーブルは、Asset、CI、IBIという異なるドメインのオブジェクトを一つの「製品インスタンス」として束ねるハブの役割を果たします。

主要なフィールドとリレーションシップ

cmdb_pi_product_instanceテーブルのスキーマを理解することは、PI2.0のデータモデルを把握する上で不可欠です。主要なフィールドとその役割は以下の通りです。

• Asset [asset]: alm_assetテーブルへの参照フィールド。製品インスタンスの財務的側面を担うAssetレコードを指します。
• Configuration item [ci_item]: cmdb_ciテーブルへの参照フィールド。製品インスタンスの運用的側面を担うCIレコードを指します。
• Install Base Item [install_base_item]: csdm_install_base_itemテーブルへの参照フィールド。製品インスタンスの顧客側面を担うIBIレコードを指します。
• Product Model [product_model]: cmdb_modelテーブルへの参照フィールド。この製品インスタンスが準拠する製品のテンプレートを指します。
• Life Cycle Stage [life_cycle_stage]: 統一ライフサイクルステージを格納する選択リストフィールド。
• Life Cycle Stage Status [life_cycle_stage_status]: 統一ライフサイクルステージステータスを格納する選択リストフィールド。life_cycle_stageの値に依存します。

スキーマ上の位置づけ

このデータモデルにおいて、cmdb_pi_product_instanceテーブルは、alm_asset、cmdb_ci、csdm_install_base_itemという3つの主要テーブルを正規化し、それらの間に存在する厳密な1対1対1の関係をデータ構造レベルで保証する中間テーブルとして機能します。これは、ビジネスルールに依存していた従来のモデルと比較して、はるかに堅牢なデータ整合性を実現します。

ServiceNowのスキーママップ機能（ >から任意のテーブルを選択し、をクリック）を利用することで、これらのテーブル間の関係性を視覚的に確認できます 。スキーママップ上では、cmdb_pi_product_instanceが中心となり、各ドメインのテーブルへ参照線が伸びている様子が描かれ、PI2.0がどのようにして異なるデータドメインを統合しているかが直感的に理解できます。  

このデータモデルは、単に個々の「モノ」を管理するだけではありません。例えば、PC、モニタ、ドッキングステーションから成る「新入社員セット」のようなバンドル製品や、Web/App/DBサーバーで構成される「サーバー・スタック」を、それぞれが一つの製品インスタンスとして、その構成要素もまた製品インスタンスとして階層的に管理することを可能にします 。これにより、管理の対象は個々のコンポーネントから、ビジネス価値を提供する「サービス」の単位へと進化します。これは、組織がIT管理の成熟度を高め、モノの管理からサービスの管理へと移行するための強力な技術的基盤を提供するものです。  

第3部：PI2.0導入実践プレイブック

Product Instance 2.0の導入は、単一の機能を有効化する以上の意味を持ちます。これは組織のデータ管理基盤を最新のアーキテクチャに移行させるプロジェクトであり、計画的なアプローチが不可欠です。ServiceNowは公式のプレイブック（KB1703219）を通じて、安全かつ効果的な導入手順を提示しています。本セクションでは、このプレイブックに基づき、導入プロセスを「分析」「有効化」「設定と同期」「データガバナンス」の4つのフェーズに分けて具体的に解説します。

3.1. フェーズ1：分析 – 導入前の現状把握と影響評価

PI2.0の有効化に着手する前に、現状の把握と、変更がシステムに与える影響を徹底的に分析することが成功の鍵となります。

PI2.0有効化状態の確認

まず、現在のインスタンスでPI2.0が有効になっているかを確認します。この確認には、ServiceNowが提供するCSDM and CMDB Data Foundations Dashboardが最も効果的です 。  

1. フィルターナビゲーターでCSDM and CMDB Data Foundationsと入力し、ダッシュボードを開きます。
2. ダッシュボード内のインジケーターに、「Product Instance 2.0 Enabled」といった項目が存在します。
3. このインジケーターの値が100%であればPI2.0は有効、0%であれば無効です 。  

このダッシュボードは、PI2.0の有効化状態だけでなく、CSDMの各要素がどの程度準拠できているかを測定するための重要なツールであり、継続的なデータ品質管理に活用すべきです 。  

影響分析

PI2.0を有効化する最大のインパクトは、従来のCIステータスフィールド（install_status, hardware_status, operational_status）とAssetのStateフィールド間の同期ロジックが無効化されることです 。したがって、これらの古いフィールドに依存している既存のカスタマイズをすべて洗い出し、修正計画を立てる必要があります。  

調査すべき対象は以下の通りです。

• カスタムスクリプト: ビジネスルール、スクリプトインクルード、クライアントスクリプトなどで、古いステータスフィールドを直接参照（読み取り）または更新（書き込み）している箇所を特定します。これらのロジックは、新しい統一ライフサイクルフィールド（life_cycle_stage, life_cycle_stage_status）を参照・更新するように修正する必要があります。
• レポートとダッシュボード: 古いステータスフィールドを条件やグループ化の基準として使用しているレポートやパフォーマンス分析（PA）のインジケーターを特定します。
• ワークフローとフロー: ワークフローやFlow Designerで、古いステータスフィールドをトリガー条件や分岐条件として使用している箇所を洗い出します。
• アクセス制御（ACL）: 特定のステータスに基づいてレコードの読み取り/書き込み権限を制御しているACLがないか確認します。
• 外部システム連携: APIやImport Setを通じて、外部システムが古いステータスフィールドを更新、または参照している場合、連携仕様そのものを見直す必要があります。これは最も影響が大きく、見落とされがちなポイントです 。  

この分析フェーズは、PI2.0への移行プロジェクトであると同時に、プラットフォーム内に蓄積された技術的負債を棚卸しし、解消する絶好の機会でもあります。

3.2. フェーズ2：有効化 – システムプロパティとプラグインによるアクティベーション手順

分析が完了し、修正計画の目処が立ったら、システムの有効化に進みます。このプロセスは、必ず非本番環境（開発インスタンスやテストインスタンス）で先行して実施し、十分なテストを経てから本番環境に適用するという鉄則を遵守してください 。  

前提条件

• PI2.0は、ServiceNowのXanaduリリース以降のインスタンスで利用可能です 。それ以前のバージョンを利用している場合は、まずプラットフォームのアップグレードが必要です。  

有効化プロセス

PI2.0の有効化は、通常、特定のシステムプロパティの値を変更することで行われます。詳細な手順はServiceNowの公式ドキュメントに記載されていますが、プレイブックKB1703219がその入り口となります 。  

一般的な手順は以下の通りです。

1. フィルターナビゲーターでsys_properties.listと入力し、システムプロパティのリストを開きます。
2. PI2.0の有効化を制御するプロパティを検索します（プロパティ名はリリースによって異なる可能性があるため、必ず公式ドキュメントで確認してください）。
3. 該当するプロパティの値をtrueに変更し、保存します。

以下の表は、PI2.0の有効化に関連する可能性のあるシステムプロパティの例です。

システムプロパティ名 (Property Name)	説明 (Description)	推奨値 (Recommended Value)	関連する機能/影響 (Function / Impact)
com.snc.pi2.activated (仮)	Product Instance 2.0のデータモデルと同期ロジックを有効化するマスタープロパティ。	true	このプロパティを有効にすると、従来のステータス同期が無効化され、統一ライフサイクルフィールドが有効になります。
com.snc.csdm.asset.sync_direction (仮)	Asset, CI, IBI間のライフサイクル同期の優先順位や方向性を制御します。	asset / ci	例えばassetに設定すると、Assetレコードの更新がCI/IBIに反映されるようになります。

Google スプレッドシートにエクスポート

技術的注意点: 過去のリリースでは、CSDM Life Cycle関連のプラグインを有効化した際に、マイグレーションスクリプトが意図せずハードウェア資産のステータスをConsumed（消耗済み）に変更してしまうという既知の問題（KB1433675）が報告されていました 。これは、ベーステーブルalm_assetのマッピングが複数存在し、ランダムに選択されてしまうことが原因でした。最新のリリースでは修正されている可能性が高いですが、有効化作業の際には、意図しないデータ変更が発生していないかを注意深く監視することが重要です。  

3.3. フェーズ3：設定と同期 – Asset、CI、IBI間のライフサイクル同期設定

PI2.0を有効化した後、Asset、CI、IBI間のライフサイクル状態をどのように同期させるかを定義します。これにより、組織の運用プロセスに合わせたデータフローを構築します。

同期オプションの構成

PI2.0は、どのオブジェクトの更新をマスター（正）とするか、同期の方向性を設定するオプションを提供します 。この設定は、組織のどのプロセスがライフサイクル管理の主導権を握るかという、業務上の意思決定に直結します。  

• ITAM主導モデル: 資産管理チームが調達から廃棄までのライフサイクル全体を厳密に管理している場合、Assetレコードの更新をCIとIBIに反映させる設定が適しています。
• ITOM/ITSM主導モデル: Discoveryや監視ツールによってCIの状態が自動的に更新され、それが最も正確な情報源である場合、CIレコードの更新をAssetとIBIに反映させる設定が考えられます。
• CSM主導モデル: 顧客に提供した製品の利用状況（IBI）がライフサイクルの起点となる場合、IBIの更新を他のオブジェクトに反映させる設定も可能です 。  

これらの設定は、システムプロパティや専用の設定画面を通じて行います。この意思決定は、ITAM、ITSM、CSMの各チーム間での役割と責任（RACI）を再確認し、合意形成を図る良い機会となります。

データ移行とクレンジング

有効化後、既存のレコードが持つ古いステータス情報を、新しい統一ライフサイクルフィールドに正しく移行させる必要があります。ServiceNowは、この移行を支援するためのスクリプトやスケジュールジョブを提供している場合があります。例えば、Backup bulk populate lifecycle fieldsといったジョブが、ライフサイクルフィールドの一括移入を実行することがあります 。これらのジョブの動作を理解し、実行前に影響範囲をテストすることが不可欠です。また、移行プロセスを通じて、これまで放置されてきたステータスの不整合データをクレンジングし、データ品質を向上させるべきです。  

3.4. データ投入戦略：プロアクティブな資産管理と一括登録

IT資産管理の成功は、データの正確性と適時性に大きく依存します。ここでは、CMDBの健全性を維持し、資産ライフサイクル全体を正確に追跡するためのデータ投入戦略について、ベストプラクティスを解説します。

3.4.1. プロアクティブな資産管理の重要性

CMDBのデータ品質を維持するための最も重要な戦略は、「プロアクティブな資産管理」です。これは、IT機器がネットワーク上で発見（Discover）される前に、調達・受領プロセスを通じて資産（Asset）レコードを先行して作成するアプローチを指します。

資産を登録する際には、IRE（Identification and Reconciliation Engine）が後からCIを一意に特定できる情報、特にシリアル番号を正確に登録しておくことが強く推奨されます。

1. 資産の先行登録: 機器が納品された段階で、資産管理チームがシリアル番号を含む資産（Asset）レコードを作成します。
2. CIの自動生成: この資産作成をトリガーに、シリアル番号が入力された「骨格」のCIレコードがCMDBに自動生成されます。
3. Discoveryによる突合と更新: 後日、その機器がネットワークに接続され、Discoveryツールがそれを発見すると、IREはそのシリアル番号をキーにCMDBを検索します。
4. 重複の防止: IREは、ステップ2で作成済みのCIを発見し、新しいCIを重複して作成する代わりに、既存のCIレコードにOSバージョンなどの技術情報を追記・更新します 。  

このプロセスにより、Discoveryツールがもたらす表記の揺らぎ（例：モデル名の微妙な違い）によって不正なモデルが乱立したり、CIが重複したりするのを防ぎ、CMDBをクリーンに保つことができます。

3.4.2. 一括登録の標準プロセス：インポートセットとトランスフォームマップ

大量の資産レコードを初期登録したり、定期的に一括更新したりする場合、インポートセットとトランスフォームマップを活用する方法が、ServiceNowにおける標準的かつ最も推奨されるプロセスです 。この手法には以下の利点があります。  

• トレーサビリティとエラーハンドリング: アップロードしたデータはまず中間テーブルにロードされるため、本番テーブルに反映する前に内容を確認し、エラーを修正することが容易です 。  
• 再利用性: 一度作成したトランスフォームマップ（どの列をどのフィールドに対応させるかの定義）は、将来のインポートで再利用できます。
• 重複防止機能（Coalesce）: トランスフォームマップで特定のフィールド（例：serial_number）をCoalesce（突合）キーとして指定することで、そのキーの値がターゲットテーブルに既に存在する場合はレコードを更新し、存在しない場合は新規作成するという動作を自動化できます。これにより、資産の二重登録をシステムレベルで防ぐことができます 。  

3.4.3. 発注から納品までの2段階登録プロセス（ベストプラクティス）

資産ライフサイクルは発注時点から始まりますが、その時点ではシリアル番号は不明です。この現実的な課題に対応するため、以下の2段階に分けた一括登録プロセスがベストプラクティスとなります。

第1段階：発注時の「シェル資産」の一括登録

1. データ準備: 発注システムから、発注番号（PO Number）、モデル、数量、コストなどの情報を含むファイル（Excel/CSV）を準備します。この時点ではシリアル番号の列は空欄です。
2. インポートと変換: インポートセットとトランスフォームマップを使い、資産（alm_asset）テーブルにデータをロードします。
   • 状態設定: トランスフォームマップで、これらの資産のStateを**「On Order」（発注中）**に設定します。
   • Coalesce設定: 発注番号と発注ライン番号の組み合わせなど、発注内で一意な情報をCoalesceキーに設定します。

これにより、ServiceNow上にはシリアル番号が空の「シェル資産」レコードが作成され、発注状況を正確に追跡できます。

第2段階：納品受領時のシリアル番号の一括更新

1. データ準備: 納品後、ベンダーから提供されたシリアル番号のリスト（発注番号を含む）を準備します。
2. インポートと更新: 再度インポートセットとトランスフォームマップを使用します。
   • Coalesce設定: 発注番号や資産タグなど、第1段階で作成したレコードを一意に特定できる情報をCoalesceキーに設定します。
   • 更新処理: ServiceNowはCoalesceキーを基に既存のシェル資産を検索し、新しいレコードを作成する代わりに、シリアル番号フィールドを更新します 。  
   • 状態更新: 資産のStateを**「In Stock」（在庫あり）**に更新します。

この2段階プロセスにより、資産ライフサイクルの初期段階からデータを正確に追跡し、後から物理的な情報でデータをエンリッチするという、クリーンで体系的な資産管理が実現します。さらに成熟したプロセスとして、ベンダーから出荷前に電子的にシリアル番号情報を受け取る**ASN（事前出荷通知）**を活用し、資産登録をさらに前倒しする方法もあります 。  

3.5. データガバナンス：移行後のデータ整合性を維持するための運用プロセス

PI2.0の導入は一度きりのプロジェクトで終わりません。その価値を継続的に享受するためには、データガバナンスのプロセスを確立することが不可欠です。

• オーナーシップの確立: CSDMのベストプラクティスに従い、Product Modelごとにプロダクトオーナーを任命し、そのモデルから作成される製品インスタンスのデータ品質に対する責任を明確にします 。  
• 継続的な監視: CSDM and CMDB Data Foundations Dashboardを定期的にレビューし、PI2.0の準拠状況や関連データの健全性を監視するプロセスを運用に組み込みます 。異常が検知された場合は、速やかに原因を調査し、是正する体制を整えます。  
• 変更管理プロセス: 組織のニーズに合わせて新しいライフサイクルステータスを追加する場合は、必ず正式な変更管理プロセスを通じて行います。Life Cycle StageとLife Cycle Stage Statusの選択リストを更新する際には、関連するワークフロー、レポート、権限設定への影響を評価し、ドキュメントを更新することを徹底します 。  

PI2.0への移行は、技術的なアップグレードであると同時に、データ中心のIT管理文化を組織に根付かせるための戦略的な取り組みです。このプレイブックに沿って計画的に導入を進めることで、その効果を最大限に引き出すことができるでしょう。

第4部：高度なユースケースと推奨事項

Product Instance 2.0の導入は、単にデータモデルを整理するだけでなく、これまで困難だった高度な資産管理やサービス運用を可能にします。本セクションでは、具体的なユースケースを通じてその価値を掘り下げ、導入を成功させるためのベストプラクティスと将来的な展望を示します。

4.1. ユースケース分析：バンドルモデル（PCセットアップ等）のライフサイクル管理

企業ITにおいて、複数の資産がひとつのパッケージとして提供されるケースは頻繁にあります。例えば、新入社員に支給される標準PCセット（ノートPC本体、外部モニタ、ドッキングステーション、キーボード、マウス）や、Webサーバー、アプリケーションサーバー、データベースサーバーで構成されるアプリケーションの実行環境（サーバー・スタック）などがそれに該当します。

バンドルモデルの課題

従来のAsset/CIモデルでは、これらの「バンドル」の管理には課題がありました。ServiceNowにはバンドルモデルを作成する機能がありますが、それはあくまで複数のモデルをグループ化するテンプレートに過ぎません 。実際に資産が展開されると、PC本体、モニタなど、個々のコンポーネントはそれぞれ独立したAsset/CIレコードとして管理されます。そのため、以下のような問題が発生しがちでした。  

• ライフサイクルの不整合: バンドル全体として「使用中」であっても、構成要素の一つであるモニタが故障して「修理中」になるなど、コンポーネントとバンドル全体のライフサイクル状態が一致しない。
• 管理の煩雑さ: バンドル全体を廃棄する場合、構成するすべてのコンポーネントのAsset/CIレコードを個別に探し出し、ステータスを更新する必要があり、手間がかかる上に更新漏れのリスクも高い。

PI2.0による解決策

Product Instance 2.0は、この課題に対してエレガントな解決策を提供します。PI2.0のデータモデルでは、バンドルやスタックといった論理的な集合体と、それを構成する個々のコンポーネントを、階層構造を持つ製品インスタンスとして表現できます 。  

1. まず、「新入社員標準PCセット」というバンドルモデル自体を、親となる一つの製品インスタンスとして作成します。
2. 次に、そのセットを構成するPC本体、モニタ、ドッキングステーションなども、それぞれが子となる製品インスタンスとして作成します。
3. これらの親子関係をCMDBのリレーションシップで定義します。

この構造により、統一ライフサイクルフィールドを活用した連動した管理が可能になります。例えば、親である「新入社員標準PCセット」のLife Cycle Stage Statusを「In Use」（使用中）に変更すると、その変更をトリガーとして、子の製品インスタンス（PC、モニタなど）のステータスも自動的に「In Use」に更新するようなワークフローを容易に構築できます。逆に、子のモニタが「Pending Repair」（修理待ち）になった場合、その状態を親の製品インスタンスに集約して表示し、バンドル全体が完全な状態ではないことを示すことも可能です。

このアプローチは、IT資産管理を個々の「個品管理」から、ビジネス価値を提供する論理的な単位、すなわち「ポートフォリオ管理」へと昇華させます。管理者は「PC-001のステータスは何か？」というミクロな問いだけでなく、「全社の開発者向けPCポートフォリオのうち、あと1年で保証が切れるものは何%か？」といった、より戦略的な問いにデータで答えられるようになります。

さらに、Hardware Asset Management Professional (HAM Pro) のような高度なライセンスを導入すると、これらのバンドル資産の調達、在庫管理、展開、廃棄に至るまでのライフサイクル全体を自動化する、より洗練されたワークフローが提供されます 。  

4.2. 導入におけるベストプラクティスと技術的注意点

PI2.0への移行を成功させるためには、技術的な正しさに加え、戦略的な導入計画が不可欠です。

• 段階的導入（Phased Rollout）: 全ての資産カテゴリに対して一斉にPI2.0を適用する「ビッグバン」アプローチは、リスクが高く推奨されません。まずは影響範囲が限定的で、価値を実証しやすい領域からスモールスタートすることが賢明です。例えば、「今後新規に購入するサーバークラスの資産のみ」を最初の対象とし、そこで得られた知見を基に、徐々にPCやネットワーク機器へと適用範囲を広げていくアプローチが有効です。
• 運用プロセスの再設計: PI2.0は単なるデータモデルの変更ではありません。これを機に、資産の要求、調達、在庫管理、展開（IMAC）、リース返却、廃棄といった関連するITAM/ITSMプロセス全体を見直し、統一ライフサイクルを前提とした、よりシンプルで自動化されたワークフローへと再設計すべきです。
• DiscoveryとService Mappingとの連携: ServiceNow DiscoveryやService Mappingは、ネットワーク上のCIを自動的に検出し、その状態を更新します。PI2.0導入後は、これらのツールによるCIのステータス更新（例：サーバーのシャットダウンを検知）が、life_cycle_stage / statusにどのように反映され、それがAssetレコードにどのような影響を与えるかを十分に検証する必要があります。意図せずAssetが「Retire」されてしまうような事態を防ぐための調整が必要になる場合があります。
• 厳格な権限管理: life_cycle_stageとlife_cycle_stage_statusは、資産のライフサイクル全体を支配する極めて重要なフィールドです。これらのフィールドを更新できる権限を持つロール（役割）を厳格に制限し、意図しない状態変更を防ぐためのアクセス制御（ACL）を慎重に設計することが、データガバナンスの観点から必須です。

4.3. 将来展望：PI2.0が拓く高度な資産管理とサービス運用

PI2.0によってもたらされる一貫性のある正確なライフサイクルデータは、将来的にさらに高度なIT管理機能を実現するための基盤となります。

• 予測的資産管理（Predictive Asset Management）: 統一されたライフサイクルデータと、インシデント履歴や利用状況データを組み合わせることで、AI/ML（人工知能/機械学習）を活用した高度な分析が可能になります。これにより、ハードウェアの故障時期を予測してプロアクティブに交換計画を立てたり、組織内での利用率が低い資産を特定して自動的に再配置を提案したりといった、予測的な資産管理が実現します。
• FinOpsとCloud Asset Managementへの展開: PI2.0の「製品インスタンス」という概念は、物理資産や仮想資産だけでなく、クラウドサービス（IaaS, PaaS, SaaS）の管理にも応用可能です。クラウドサービスの利用状況や構成（CI）と、その利用に伴うコスト（Asset）を単一の製品インスタンスとして統合管理することで、クラウドコストの最適化を目指すFinOpsの実践を強力に支援します。
• Enterprise Asset Management (EAM)への拡張: PI2.0が提供する統一ライフサイクルモデルは、IT資産に限定されるものではありません。工場設備、車両、医療機器、オフィス什器といった非IT資産（エンタープライズ資産）の管理にもこのフレームワークを適用することで、ServiceNowを企業全体の資産を統合管理するプラットフォームへと進化させることができます。
• サステナビリティ（ESG）への貢献: 企業のサステナビリティ目標（特に環境、社会、ガバナンスのうちの環境側面）の達成において、IT資産の管理は重要な役割を担います。PI2.0によって整備された正確なライフサイクルデータは、IT資産の消費電力の追跡、電子廃棄物（E-waste）の適切な管理、リサイクル率の向上といった活動の基盤となります。例えば、「廃棄待ち（Pending Disposal）」ステータスの資産一覧を正確に抽出し、認定リサイクル業者への引き渡しプロセスを自動化したり、旧モデルと新モデルの消費電力データを比較して、資産リフレッシュ計画がCO2排出量削減にどれだけ貢献したかを定量的にレポーティングしたりすることが可能になります。このように、PI2.0はIT運用の効率化に留まらず、企業の社会的責任を果たすためのデータインフラストラクチャとしての戦略的価値を持ちます。

結論：データドリブンなIT管理基盤の確立に向けて

本レポートでは、ServiceNowにおけるAssetとCIの連携について、標準的なアーキテクチャから、Product Instance 2.0（PI2.0）による革新的なデータモデルへの進化までを詳細に解説しました。

標準的な連携メカニズムは、Model Categoryを起点としたビジネスルールによる自動化を提供してきましたが、それぞれが独自のステータスを持つAssetとCIを後から同期させるアプローチは、本質的な複雑性とデータ不整合のリスクを内包していました。この連携は、各レコードに存在する参照フィールドによる直接的な1対1のリンクと、シリアル番号のような一意な識別子による突合によって技術的に実現されています。

これに対し、PI2.0は、Asset、CI、IBIを単一の「製品インスタンス」の異なる側面として捉え、Life Cycle StageとLife Cycle Stage Statusという統一フィールドによって状態管理を一元化する、というパラダイムシフトをもたらしました。このアーキテクチャの変革は、従来の同期の課題を根本的に解決し、CSDMフレームワークに準拠した、信頼性の高いデータ基盤を構築します。

PI2.0の導入は、システムプロパティを変更するだけの単純な技術作業ではありません。それは、既存のカスタマイズや運用プロセスを見直し、データガバナンス体制を再構築する「ミニ・トランスフォーメーションプロジェクト」です。しかし、その先には計り知れない価値があります。

• データ品質の飛躍的向上: 信頼できる唯一の情報源が確立され、レポートやダッシュボードの信頼性が向上します。
• 運用プロセスの簡素化と自動化: 複雑な同期ロジックが不要になり、ライフサイクルに基づいたワークフローの設計と自動化が容易になります。
• 戦略的な意思決定の実現: IT資産とITサービスを統合的に可視化・管理することで、コスト最適化、リスク管理、さらにはサステナビリティといった経営課題にデータで応えることが可能になります。

結論として、Product Instance 2.0への移行は、単なる技術的なアップグレードではなく、データ中心のIT管理文化を組織に根付かせ、将来にわたるServiceNowプラットフォームの価値を最大化するための戦略的投資であると言えます。本レポートが、その計画的かつ段階的な導入を推進するための一助となれば幸いです。データドリブンなIT管理基盤の確立に向けた第一歩は、自社のデータモデルを深く理解し、進化させることから始まります。