資産管理（Asset）運用設計書

この記事は、PDI（Zurich、2026-07-08 確認）の OOTB（初期設定）構成をもとに、資産管理（Asset）運用の設計判断を「なぜそう決めるか」まで整理した運用設計書です。状態区分の標準や棚卸しの頻度などの具体値は一例で、自社導入時のたたき台に使うことを想定しています。

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

会社が保有するIT機器・ライセンス・消耗品を、調達から廃棄まで台帳で追える状態に保つことを目的として、本設計書ではServiceNowの資産管理（Asset）運用の設計判断を一つずつ決める。どの状態区分で資産の現在地を表すか、資産台帳とCMDB（構成情報）の間で何を連動させるか、保管と払い出しの責任を誰が持つか。あとから運用を変えるときに判断の背景までさかのぼれるよう、決定とその理由をあわせて記録する。

Asset and CI managementの一般的な位置づけは、資産を alm_asset 系のテーブルで台帳管理し、モデルカテゴリの設定に応じて CMDB の CI（構成アイテム）と連動させる仕組みです。構造は「ServiceNow の資産管理テーブル alm_asset を実機で確認する」で確認済みです。CI 側は「ServiceNow CMDB の中心テーブル cmdb_ci を実機で読み解く」にあります。本設計書は構造の説明ではなく、その構造の上で運用をどう決めるかに重心を置く。

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

• 登録基準を人に依存させないことを目的として、資産クラスとモデルカテゴリの割り当てを設計する。

• 資産の現在地を一つの軸で判断できるようにすることを目的として、状態区分（install_status / substatus）の標準を設計する。

• 台帳と構成情報の二重入力をなくすことを目的として、Asset⇔CI 同期の起点と方向を設計する。

• 保管中・利用中・移動中の所在責任を切れ目なくつなぐことを目的として、保管・払い出し・回収の手続きを設計する。

• 廃棄の説明責任を台帳で果たせるようにすることを目的として、退役・廃棄の証跡を設計する。

• 台帳と実物のずれを検知し続けることを目的として、KPIと棚卸しを設計する。

操作の「やり方」は、対になる運用手順書「ServiceNowのPDIをもとにしたOOTB資産管理（Asset）運用手順書」で、ハードウェア資産1件を入庫から退役まで実機で回して扱っています。手順書は「どの画面で何が起き、どの値がどう変わるか」を順番に見せる。本設計書はそれに対して「どの状態を標準にし、何を同期に任せ、誰が責任を持つか」を決める。やり方を先に知りたい人は手順書が入口です。

対象範囲は、alm_asset（とくにハードウェア資産 alm_hardware）を中心とした資産管理運用とする。設計の対象は次のとおり。モデルカテゴリ（cmdb_model_category）による Asset クラスと CI クラスの対応、状態区分、Asset⇔CI 同期（マッピング3テーブルと Business Rule）。さらに保管場所（alm_stockroom）、契約（ast_contract）との紐づけ、KPIと棚卸しまでを含める。有償プラグインの HAM Pro（Hardware Asset Management Professional）は今回の実機検証範囲外とする。Transfer Order や Stock Rule を使った補充運用、減価償却の計算も同じく範囲外で、末尾に明記する。

設計の起点はOOTBとする。ServiceNowの資産管理は、何も作らない初期状態でも一式が組まれている。モデルカテゴリ128件による Asset⇔CI のクラス対応、状態の対応表（47件＋59件）とフィールドの対応表（29件）、それらを実行する Business Rule 32件、保管場所9件。OOTBの構成のうち、どこをそのまま使い、どこを自社の値へ置き換えるかを決めることを本設計書の方針とする。想定読者は、ITAM（IT資産管理）の導入・改善を任された運用設計者、台帳の正しさに責任を持つ資産管理者、資産との連動を設計したい構成管理（CMDB）担当者です。

設計領域の全体像

資産管理運用設計で決めることを6つの領域に分け、この順で設計を進める。

• 台帳設計（2章・3章）… 何を資産として登録するか。クラスとモデルカテゴリの割り当て。

• 状態設計（3章）… 現在地をどの区分で表すか。install_status / substatus の標準。

• CI同期設計（4章）… 構成情報と何を連動させるか。同期の起点・方向・CI を作る範囲。

• 保管・払い出し設計（5章）… 所在の責任を誰が持つか。stockroom・assigned_to・location。

• 退役・廃棄設計（6章）… 証跡をどう残すか。Retired と substatus・廃棄証明。

• 計測・棚卸し設計（7章）… 台帳と実物のずれをどう検知し、正すか。

矢印の終点を計測から台帳へ戻しているのは、棚卸しで見つけた差異を台帳の修正と登録基準の見直しにつなげるためで、6つの領域が一巡して閉じる構造を設計の枠組みとする。

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

設計の土台を確かめることを目的として、OOTBの資産管理の構成をここで整理する。今回確認したPDIでは、資産（alm_asset）は全クラス合計で2,817件が入っていました。

2-1. 台帳のクラス構成と状態分布

台帳は4つのクラスに分かれ、ハードウェア902件・ソフトウェアライセンス77件・消耗品1,791件・基底クラスのまま47件という構成でした。

状態で見ると、In use 943件・In stock 100件・Consumed 1,774件に分かれていた。

フィールドの持ち方に構造上の特徴がある。alm_asset（基底）が74フィールドを持ち、alm_hardware がクラス固有に追加するのは eligible_for_refresh の1つだけでした（集合差で実測）。asset_tag も stockroom も assigned_to も基底側が持つ。この構造は、有料部で「資産クラスは増やさず、区分はモデルカテゴリで行う」と決める根拠になる。

2-2. モデルカテゴリ：Asset クラスと CI クラスの対応表

モデルカテゴリは機種（モデル）の分類であると同時に、どの Asset クラスとどの CI クラスを対応させるかの設定を持つ。Computer カテゴリを開くと、Asset class＝alm_hardware、CI class＝cmdb_ci_computer という対応が1画面で確認できる。

主要カテゴリの対応を表にする。

ここに設計上の分岐点が2つある。Monitor と Mobile Device は asset_class だけを持ち、cmdb_ci_class が空だった。つまり資産は登録するが CI は作らない設定です（少なくとも今回確認した PDI の OOTB では）。逆にアプリ系のカテゴリは asset_class が空で、CI だけが作られる。実データでも、ハードウェア資産のうち CI 参照が空のものが8件、cmdb_ci_computer のうち Asset 参照が空のものが2件あった。Asset と CI は常に1対1ではなく、どのカテゴリで対応させるかそのものが設計対象になる。

2-3. 状態の選択肢：install_status 9値と substatus

install_status は9値でした。On order(2)・In stock(6)・In transit(9)・In use(1)・Consumed(10)は、入庫・保管・移動・利用・消費の系列です。In maintenance(3)・Retired(7)・Missing(8)・Build(11)は、修理・退役・不明・組立の系列です。substatus は親の状態に従属する選択肢です。In stock では17値、Retired では10値ありますが、In maintenance には選択肢がありません。

状態のフィールドはこれだけではない。alm_asset には CSDM 系の life_cycle_stage / life_cycle_stage_status も存在する。ただし今回確認した PDI では、life_cycle_stage が入った資産は0件でした。CI と Asset の間でライフサイクルを同期するプロパティ（csdm.lifecycle.sync.between.ci.and.asset.activated）も false です。どちらを状態の軸に据えるかは、有料部の最初の設計判断として扱う。

2-4. Asset⇔CI 同期の実装：マッピング3テーブルと Business Rule

Asset と CI の同期は、スクリプトの中に埋まっているのではなく、3つの対応表にデータとして定義されていた。

同期の実行主体は、alm_asset を対象にした Business Rule 32件でした。挿入と同時に CI を自動生成する Create CI on insert、更新時に対応表へ従って CI を書き換える Update CI fields on change が代表格です。状態変更に応じて assigned_to や stockroom をクリアする規則も含まれていました。

フィールド対応29件には CI の operational_status（運用状態）が含まれません。状態の対応表（47件・59件）が書き換えるのも CI の install_status / hardware_status までです。operational_status に触れる定義はどこにも無かった。資産を退役させても CI の運用状態は自動では変わらない。この事実が、有料部の同期設計で「監視・稼働判断を Asset の状態に依存させない」と決める根拠になる。

2-5. 保管場所と契約

保管場所（alm_stockroom）は9件で、型は Warehouse と Central Warehouse の2種でした。manager が空の倉庫も混ざっており、所在責任を確定させる余地が残る。

契約（ast_contract）は111件でした。資産との紐づけは多対多テーブル clm_m2m_contract_asset（397件）が持ちます。大半はソフトウェアライセンス資産との紐づけでした。契約側の構造は「ServiceNow の契約管理テーブル ast_contract を実機で確認する」で確認済みです。

この構成を土台に、ここから先は状態の標準・同期の方針・保管と退役の責任・棚卸しの回し方を、自社で決めるパラメータ一覧・RACI・代替案の採否まで含めて一つずつ確定していく。