資産管理（Asset）運用手順書

確認した環境：ServiceNow の PDI（Personal Developer Instance）、Zurich リリースの OOTB（初期設定）。2026-07-08 確認。

1. 目的・背景

この記事は、ServiceNow のハードウェア資産1件を実機で新規登録し、入庫 → 払い出し → メンテナンス → 退役の4状態を順に実走して確認した運用手順書です。MacBook Pro のハードウェア資産（alm_hardware）を1台登録しました。状態を変えるたびに、資産側で何が自動で変わるか、対応する CI（cmdb_ci_computer）に何が同期されるかを記録しています。

資産管理の操作で迷いやすいのは、資産（Asset）と CI の関係です。今回の実走でいちばん確かめたかったのは、資産を退役させても CI の Operational status は Operational のまま残るという動きでした。退役の操作で CI の Install status は Retired に変わるのに、稼働状態を表すフィールドだけが動きません。この点はステップ4で実測とあわせて扱います。

今回実走した資産のフォームが次の画面です。退役まで進めた後の状態では、State=Retired、Substate=Disposed です。Assigned to は空に戻り、右上の Configuration Item には自動生成された CI への参照が残っています。

想定読者は、ServiceNow で IT 資産の台帳運用（入庫・払い出し・退役）を担当する人です。資産管理の手順書を整える立場の人も対象です。テーブル構造そのものは「ServiceNow の資産管理テーブル alm_asset を実機で確認する：CI との関係・継承・状態の見方」で、資産に紐づく契約の管理は「ServiceNow の契約管理テーブル ast_contract を実機で確認する：State・期間・Asset との紐づけの見方」で扱っています。CI 側の全体像は「ServiceNow CMDB の中心テーブル cmdb_ci を実機で読み解く：クラス階層・状態・CI関連の見方」をご覧ください。

2. 操作フロー・概要

資産の基底テーブルは alm_asset で、ハードウェア資産が入るのはそれを継承した alm_hardware です。資産は「モデル（cmdb_model）」と「モデルカテゴリ（cmdb_model_category）」を参照していて、このモデルカテゴリが CI との連動を決めます。今回使った Computer カテゴリは、資産クラス=alm_hardware、CI クラス=cmdb_ci_computer という対応を持っていました。資産管理機能の公式の説明は Asset Management（Zurich） にあります。

資産と CI は別のテーブルです。台帳として買った物を数えるのが資産、構成情報として動いている物を記述するのが CI で、両者は「参照」（お互いを指すフィールド）と「同期」（一部フィールドの自動転記）という2つの仕組みでつながります。1対1に見えますが、常にそうではありません。今回確認した PDI にも、CI を持たないハードウェア資産が8件、Asset を持たない Computer CI が2件ありました。

今回確認した PDI のハードウェア資産一覧を State でグループ化すると、次のとおりでした。In use が819件、In stock が83件、そして Retired の1件が今回の実走で退役まで進めた資産です。

状態を表すフィールドは State（内部名 install_status）と Substate（substatus）の2つです。State は9値で、Substate は State ごとに選択肢が変わる従属フィールドでした。整理すると次のとおりです。

今回の実走は、このうち In stock → In use → In maintenance → Retired の4状態です。各ステップで資産側と CI 側がどう動いたかをまとめたのが次の図です。

ひとつ注意点があります。今回の実走は、フォームと同じフィールドを REST API で直接更新して確認しました。画面から同じ項目を入力して Update する操作に読み替えて書いていますが、フォーム上のボタン（Retire など）固有の動作は検証範囲外です。

この記事（無料部）で分かること

• 資産（alm_asset / alm_hardware）と CI の「参照」と「同期」の関係、State と Substate の従属関係

• ハードウェア資産を新規登録すると、保存と同時に CI が自動生成されることを確認する手順

• 登録時に Location が Stockroom の所在地で自動補完される動き

3. 操作手順

ここからは操作を番号付きで並べます。各ステップは、実施者／画面への行き方／入力項目と値／押すボタン／成功条件／注意点の順です。値は今回実際に PDI へ登録したものでそろえました。

1) 資産の新規登録と CI 自動生成の確認

• 実施者：資産管理担当（購入した機材を台帳に載せる人）

• 画面への行き方：アプリケーションナビゲーターで Asset > Portfolios > Hardware Assets を開き、右上の「New」

• 入力項目と値：

• Model category=Computer（CI 連動のカテゴリ。これで生成される CI のクラスが決まる）

• Model=Apple MacBook Pro 15"（モデルマスタから選ぶ）

• Asset tag=P1000999（自社の管理番号。未使用の番号であることを先に検索で確認）

• Serial number=C02XR9AKJHD5（機体のシリアル番号）

• State=In stock ／ Substate=Available

• Stockroom=Santa Monica Warehouse（保管先の倉庫）

• 押すボタン：右上の「Submit」

• 成功条件：保存と同時に Configuration Item フィールドへ「シリアル番号 - モデル名」形式の CI 参照が入ること。Location を入力していないのに、Stockroom の所在地（今回は Santa Monica）で自動補完されること

• 注意点：CI は保存後にバッチで作られるのではなく、挿入と同一トランザクションで Business Rule「Create CI on insert」により自動生成される。生成先のクラスはモデルカテゴリの設定に従う（Computer → cmdb_ci_computer）

入力で参照した2つのマスタは、どちらも OOTB のデータをそのまま使いました。Stockroom は Asset > Stockroom Administration > Stockrooms で一覧できます。今回確認した PDI には9件の倉庫がありました。

モデルは Product Catalog > Product Model > Product Models から、モデルカテゴリ=Computer で絞り込むと53件ありました。資産の入力ではこの中から選びます。

保存した直後に、自動生成された CI を開いたのが次の画面です。Name は「シリアル番号 - モデル名」形式で自動命名されます。Serial number / Asset tag / Model ID / Manufacturer は資産と同じ値になり、Asset フィールドには資産への参照が入っていました。CI 側の初期状態は Install status=In Stock、hardware_status=in_stock、hardware_substatus=available です。Operational status は Operational のままです。詳細は「コンピュータ CI クラス cmdb_ci_computer を実機で読み解く」で扱っています。

登録の時点で覚えておきたいのは、資産を作る操作が CI を作る操作を兼ねている、という点です。CI 連動のカテゴリでは、資産フォームの Submit ひとつで台帳（資産）と構成情報（CI）の両方が立ち上がり、以降の状態変更は資産側からの同期で CI に伝わります。この「同期で何が伝わり、何が伝わらないか」が有料部の主題です。

無料部はここまでです。有料部では、同じ資産を払い出しから退役まで進め、次を実測つきの手順として確認します。

• 払い出し（In use）で Stockroom が自動クリアされ、Location が利用者の所在地に自動変更される動き

• 資産の「In use」が CI では「Installed」に変換される状態マッピング

• 退役（Retired/Disposed）で retired に日付が自動セットされ、CI が Retired / scrapped になる動き

• 退役後も CI の Operational status が Operational のまま残る実測と、その仕組み

• 状態と Substate の従属関係を使った日常の見方、よくあるミスとリカバリ表