資産(alm_asset)とCMDB(cmdb_ci)を分ける理由
前回の記事で、CMDB の中心テーブル cmdb_ci を「構成の視点」として読み解きました。その中で「CI は asset（→alm_asset）で資産レコードと関連付けられる場合がある」「ただし、すべての CI が Asset と1対1で対応するわけではない」と触れました。この記事はその回収です。
ServiceNow では、同じ1つのモノ（たとえば1台のノートPC）を、cmdb_ci（構成の視点）と alm_asset（資産の視点）の2つのテーブルで管理することがあります。なぜ同じモノを2つのテーブルに分けるのか。どちらを見ればいいのか。この疑問に、実際の alm_asset テーブルを起点に答えます。
この記事では、資産管理をプロセス論だけで説明しません。実機の alm_asset を起点に、その中身を順番に確認します。具体的に見るのは次です。
継承する子クラス（alm_hardware / alm_consumable / alm_license / alm_facility）
CMDB の CI と紐づける ci フィールド
型番を表す model
状態を表す install_status / substatus
コストや所有を表す cost / po_number / assigned_to / owned_by
この記事は、ServiceNow の Incident は触ったことがあり、前回 cmdb_ci のクラス構造を読んだうえで「CMDB と Asset は何が違うのか」を理解したい人を想定しています。管理者・開発者が実機で確認するときに見るべきポイントとして、次を順番に確認します。
alm_asset の継承
ci での紐づけ
主要フィールド
install_status / substatus
この記事で分かること
同じモノを cmdb_ci（構成）と alm_asset（資産）の2視点で管理する理由
alm_asset が ci フィールドで cmdb_ci に紐づくこと、すべての CI が Asset と1対1ではないこと
alm_asset がルート基底で、その下に4つの子クラス（HW / 消耗品 / ライセンス / 施設）を持つこと
alm_asset がどんなフィールドを持つか（model / cost / po_number / assigned_to / owned_by）
install_status（State）と substatus（Substate）の関係
実機で確認するときに見るべき一覧URL
この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、クラス構成・フィールド・状態設定の内容が異なる場合があります。
Asset（資産管理）とは
Asset（資産管理）とは、組織が持つIT資産（ハードウェア・ソフトウェアライセンス・消耗品など）を管理する仕組みです。「いつ・いくらで・誰が買い、誰に割り当て、いつ廃棄するか」という調達・コスト・所有のライフサイクルで管理します。会計・在庫・契約の観点が中心になります。
ServiceNow では、この資産を格納する中心テーブルが alm_asset です。一方、前回見た cmdb_ci は「そのモノが何にどう依存し、どんな構成で動いているか」という構成・運用の視点で管理します。つまり、同じ1台のサーバでも視点ごとにテーブルが分かれています。調達・コストの側面は alm_asset、構成・依存の側面は cmdb_ci です。
構成の視点（cmdb_ci）と資産の視点（alm_asset）
CI と Asset は別テーブルで持ち、alm_asset の ci フィールドで結びつける関係でした。まず、CI と Asset がどう違うのかを確認します。同じモノを2つの視点で持ち、alm_asset の ci フィールドで両者をつなぐ、という構造です。
今回確認した PDI（Zurich / OOTB）では、alm_asset に ci というフィールドがあり、その参照先は cmdb_ci でした。つまり「この資産は、CMDB のどの構成アイテムに対応するか」を、Asset 側から指す構造です。
cmdb_ci（構成の視点） … そのモノが何に依存し、どんな構成で動くか。Incident / Change の影響範囲の土台。
alm_asset（資産の視点） … そのモノをいつ・いくらで買い、誰が所有・利用し、いつ廃棄するか。調達・コスト・所有。
注意したいのは、すべての CI が Asset と1対1で対応するわけではない点です。アプリケーションやサービスのような論理的な CI は、資産として管理しないことがあります。逆に、消耗品（alm_consumable）のように資産としては数えるが、個々を CI にしないものもあります。今回の PDI では、alm_asset の総レコードは 2,817 件、cmdb_ci は 2,784 件と近い値でしたが、この近さは1対1を意味しません。どちらも基底テーブルとして全サブクラスの合計を数えた値であり、内訳は別物です。
「どっちを見ればいいのか」は、知りたいことで変わります。コスト・発注・保証・割当を知りたいなら alm_asset、依存関係・障害影響・構成を知りたいなら cmdb_ci を見ます。
なお、ci フィールドで Asset と CI が参照関係を持つことと、両者のフィールドが同期されることは同じ意味ではありません。Asset と CI が1対1で対応するかどうかは、モデルカテゴリ・対象クラス・同期設定・運用方針によって変わります。また、同期される項目や方向は Asset-CI Field Mapping や Asset-CI Install Status Mapping などの設定に依存します。Asset と CI をどう結びつけて扱うかは、公式ドキュメントにまとまっています。この記事では ci の参照関係と主要フィールドの確認にとどめます。何がどちら向きに同期されるかという同期ロジックは扱いません。
CI と Asset の対応は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。
https://<YourInstance>/alm_asset_list.do?sysparm_query=ciISNOTEMPTY
alm_asset は資産クラス階層のルート
結論から先に言うと、今回の PDI では alm_asset は継承元を持たないルートで、直下に4クラスだけを持つ浅い構造でした。 alm_asset のまわりの継承関係を見ると、cmdb_ci とは対照的な構造が見えます。
今回確認した PDI（Zurich / OOTB）では、alm_asset は super_class（継承元）を持たないルート基底テーブルでした。ここが cmdb_ci との違いです。cmdb_ci は cmdb（Base CI）を継承する「子」でしたが、alm_asset は継承元を持たない「親」から始まります。
そして alm_asset の直下には、直接の子クラスが4件ありました。
alm_hardware（Hardware） … PC・サーバなどの物理ハードウェア資産
alm_consumable（Consumable） … トナー・ケーブルなど数量で管理する消耗品
alm_license（Software License） … ソフトウェアライセンス（テーブル名は alm_license）
alm_facility（Facility） … 施設
cmdb_ci が「直接の子102・さらに深い階層」と広く深いのに対し、alm_asset は直下4クラスとシンプルです。資産の種類は、ハード・消耗品・ライセンス・施設という大きな括りで分かれています。各サブクラス固有の項目（ハードウェアのCPU等）は、それぞれの子クラス側で確認します。
サブクラスごとの件数
alm_hardware … 902 ／ alm_consumable … 1,791 ／ alm_license … 77（いずれも全件・active問わず）。件数のうえでは消耗品がもっとも多く、資産全体の6割以上を占めていました。
クラス階層は、次のURLで確認できます。
https://<YourInstance>/sys_db_object_list.do?sysparm_query=super_class.name=alm_asset
alm_asset の主なフィールド
alm_asset は、どの資産にも共通する項目を持ちます（固有フィールドは74）。役割で分けると、識別・状態・紐づけ（CI / モデル）・コスト・所有担当に整理できます。
Field Label Type / 参照先 説明
---------------------------------------------------------------------------------------
asset_tag Asset tag String 資産タグ（資産の識別番号）
ci Configuration Item Reference → cmdb_ci 対応する構成アイテム（CMDB の CI）
model Model Reference → cmdb_model（必須） 型番（製品モデル）
model_category Model category Reference → cmdb_model_category（必須） モデルの分類
install_status State Integer（choice・default=1） 資産の状態（In use / In stock 等）
substatus Substate String（従属choice） install_status に依存する小分類
assigned_to Assigned to Reference → sys_user 割当先（利用者）
owned_by Owned by Reference → sys_user 所有者
cost Cost Currency 取得コスト
po_number PO number String 発注番号
serial_number Serial number String シリアル番号
quantity Quantity Integer（必須・default=1） 数量（消耗品で活用）
location Location Reference → cmn_location 設置・保管場所
stockroom Stockroom Reference → alm_stockroom 在庫保管庫
parent Parent Reference → alm_asset 親資産（自己参照）
warranty_expiration Warranty expiration Date 保証期限主なフィールドの代表は次のとおりです。ラベルは画面上の表示名で、実機どおり英語で記載します。
alm_asset は「資産台帳」として、次をまとめて持っています。
識別（asset_tag / serial_number）
CMDB との紐づけ（ci → cmdb_ci）
型番（model → cmdb_model、model_category → cmdb_model_category）
コスト（cost / po_number）
所有・割当（owned_by / assigned_to）
保管（location / stockroom / quantity）
主要フィールドの読み方
ci → cmdb_ci … この資産が対応する CMDB の構成アイテム。Asset から CI を指します。
model → cmdb_model（必須）／ model_category → cmdb_model_category（必須） … 今回の PDI では、この2つは必須フィールドでした。資産は「どの製品モデルか」を必ず持ちます。
cost / po_number … 取得コストと発注番号。cmdb_ci 側にはない、資産ならではの会計・調達の項目です。
assigned_to（利用者）／ owned_by（所有者） … 「誰が使っているか」と「誰が持っているか」を分けて持てます。
quantity（必須・初期値1） … 数量。消耗品（alm_consumable）のように1レコードで複数を数える資産で効きます。
parent → alm_asset … 資産の親子（自己参照）。
コスト・会計・日付まわりのフィールド
cost 以外にも、資産会計・スケジュールに関わるフィールドが並びます。
コスト・会計：resale_price（転売価格）, residual（残存価値）, salvage_value（処分価値）, depreciated_amount（減価償却累計）, invoice_number, gl_account
日付：purchase_date, order_date, delivery_date, install_date, warranty_expiration, retired / retirement_date
組織：cost_center（→cmn_cost_center）, department（→cmn_department）, company / vendor / beneficiary（→core_company）
同期・その他：skip_sync（boolean。CI との自動同期をスキップするフラグ）, request_line（→sc_req_item）, depreciation（→cmdb_depreciation）
全フィールドは、次のURLで一覧できます。
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=alm_asset^elementISNOTEMPTY
資産の状態（install_status と substatus）
alm_asset の状態は install_status と substatus の2段で、substatus は install_status に依存していました。資産の状態は、cmdb_ci の install_status / operational_status とは別の体系です。alm_asset では、大分類の install_status（画面ラベルは State）と、それに依存する小分類の substatus（Substate）の2段で表します。
この記事では、PDI で確認しやすい旧来の状態項目として install_status（State）と substatus（Substate）を扱います。ただし、実環境では Life Cycle Stage / Life Cycle Stage Status を使ったライフサイクル管理や、CSDM ライフサイクル同期が関係する場合があります。alm_asset にも life_cycle_stage / life_cycle_stage_status フィールドが存在します。そのため、install_status / substatus だけを見て Asset のライフサイクル全体を判断しないようにします。
フィールド 値
-----------------------------------
install_status（State・大分類） 2=On order / 6=In stock / 9=In transit / 1=In use / 10=Consumed / 3=In maintenance / 7=Retired / 8=Missing / 11=Build
substatus（Substate・小分類） install_status に依存する従属choice。例：In stock → available / reserved / pre_allocated など。値は親の install_status ごとに変わる今回確認した PDI（Zurich / OOTB）では、install_status の有効な選択肢は9種でした（value = label）。
2=On order（発注済）
6=In stock（在庫）
9=In transit（輸送中）
1=In use（使用中）
10=Consumed（消費済）
3=In maintenance（保守中）
7=Retired（廃棄済）
8=Missing（紛失）
11=Build（構築中）
ここで注意したいのは、同じ install_status でも cmdb_ci と alm_asset で値の意味が違う点です。たとえば値「1」は、cmdb_ci では Installed（設置済）ですが、alm_asset では In use（使用中）でした。CI と Asset を行き来するときは、同じ install_status という名前でも別の選択肢リストである、と意識します。
substatus は、install_status を親とする従属（dependent）選択肢でした。つまり単独の固定リストではなく、install_status の値ごとに選べる小分類が変わります。今回の PDI では、substatus フィールドの初期値が install_status が 6（In stock）のとき available という条件式になっていました。In stock の資産には available / reserved / pre_allocated などの小分類が紐づいています。On order / Retired など他の状態にも、それぞれ別の substatus 群が用意されています。
このため substatus は「install_status とセットで読む」ことが前提になります。install_status だけ、substatus だけを見ても状態を正しく把握できません。
install_status の選択肢は、次のURLで一覧できます。
https://<YourInstance>/sys_choice_list.do?sysparm_query=name=alm_asset^element=install_status^inactive=false^ORDERBYsequence
alm_asset の周辺テーブル
alm_asset は、CI・モデル・在庫・ユーザなど複数のテーブルと参照でつながっています。
今回の PDI で確認した主な参照先は次のとおりです。いずれもテーブルの存在を確認しています。
cmdb_ci（Configuration Item） … ci フィールドの参照先。構成の視点。
cmdb_model（Product Model） … model の参照先。製品モデル（型番）。
cmdb_model_category（Model Category） … model_category の参照先。モデルの分類。
alm_stockroom（Stockroom） … stockroom の参照先。在庫保管庫。
sys_user … assigned_to / owned_by / managed_by / supported_by の参照先。
alm_asset 自身 … parent の参照先（資産の親子）。
model と cmdb_model でつながる点が、CMDB と資産の橋渡しになっています。CI（cmdb_ci）も Asset（alm_asset）も、同じ製品モデル（cmdb_model）を共有できるため、「どの型番のモノか」という情報を構成・資産の両側から参照できます。
関連テーブルは、次のURLで開けます。
Stockroom : https://<YourInstance>/alm_stockroom_list.do
Model : https://<YourInstance>/cmdb_model_list.doalm_asset に関わる周辺機能
alm_asset の動きも、フィールド定義だけでは決まりません。保存時の処理や権限など、複数の設定が組み合わさって動きます。大まかな役割分担は次のとおりです。
保存時や状態遷移の処理：Business Rule
フォーム制御：Client Script / UI Policy
操作：UI Action
権限：ACL
今回確認した PDI（Zurich / OOTB・active 中心・2026-06-20 確認）では、alm_asset に次のような設定が紐づいていました。
設定の種類（物理テーブル） 件数 ざっくりの役割
---------------------------------------------------------------
Business Rules（sys_script） 32 保存時にサーバ側で動く処理
Client Scripts（sys_script_client） 13 フォーム上でブラウザ側が動く処理
UI Policies（sys_ui_policy） 10 項目の表示／必須／読み取り制御
UI Actions（sys_ui_action） 10 ボタンや右クリックメニュー
Notifications（sysevent_email_action） 1 メール通知
Access Controls（sys_security_acl） 6 ＋ 46 権限（テーブル＋フィールド・ACL）
Dictionary Entries（sys_dictionary） 74 固有フィールドの定義
Choices（sys_choice） 70 install_status / substatus 等の選択肢注意したいのは、ここで数えているのは alm_asset（基底）に直接紐づく設定だけ、という点です。実際には各サブクラス（alm_hardware など）にも固有の設定があり、資産の挙動はそれらが合わさって決まります。基底だけを見て全体を判断しないようにします。特に CI⇄Asset の自動作成・同期がどう発火するかは、Business Rule や skip_sync フラグなど複数の要素が関わります。本記事では件数構造の確認にとどめ、内部挙動には踏み込みません。
自分のインスタンスでは、次のURLで各一覧を開けます（先頭の <YourInstance> は置き換えてください）。
Business Rules : https://<YourInstance>/sys_script_list.do?sysparm_query=collection=alm_asset^active=true
UI Actions : https://<YourInstance>/sys_ui_action_list.do?sysparm_query=table=alm_asset
Access Controls: https://<YourInstance>/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHalm_assetServiceNow における alm_asset テーブルのポイント
今回の PDI では、alm_asset は 継承元を持たないルート基底テーブル でした。直下に alm_hardware / alm_consumable / alm_license / alm_facility の4クラスを持ちました。cmdb_ci（cmdb を継承し、深く広い階層を持つ）とは対照的な、浅くシンプルな構造です。
同じモノを cmdb_ci（構成）と alm_asset（資産）の2視点で管理し、alm_asset の ci フィールドで cmdb_ci に紐づけます。ただし、すべての CI が Asset と1対1ではありません。
資産ならではのフィールドとして、cost / po_number（コスト・調達）、owned_by / assigned_to（所有・割当）、quantity（数量）を持ちます。model / model_category は今回の PDI で必須でした。
状態は install_status（State・大分類）と substatus（Substate・小分類）の2段 で、substatus は install_status に依存します。同じ install_status でも cmdb_ci とは値の意味が異なります（例：1 は CI で Installed、Asset で In use）。
model は cmdb_model を参照し、CI・Asset が同じ製品モデルを共有できる点が CMDB と資産の橋渡しになります。
CI⇄Asset の自動作成・同期の具体的な挙動は実装差があるため、本記事では構造（階層・フィールド・状態・件数）の確認にとどめます。
alm_asset を調べるときは、まず「いま見ているのは資産の視点か、構成の視点か」を意識します。alm_asset 単体ではなく、ci でつながる cmdb_ci、model でつながる cmdb_model をセットで見ると全体像を取り違えずに済みます。
実機を見て気づいたこと
substatus は install_status（9種）ごとに候補が変わる従属選択肢で、確認できた値の総数は36種にのぼりました。install_status だけ見ていると気づきにくい細かさです。
alm_asset には request_line（→sc_req_item）という参照フィールドがあります。カタログ申請（Request Item）から資産レコードが自動で作られる経路があることを示すフィールドで、資産は購買だけでなく申請プロセスからも生まれる作りだと分かります。
次に読むなら
次に確認するなら、次のテーマです。
alm_asset の代表的なサブクラス（alm_hardware）の固有フィールド
CI⇄Asset の同期を担う Business Rule や skip_sync の挙動
ソフトウェアライセンス（alm_license）と Software Asset Management
Life Cycle Stage / Status を含むライフサイクル管理
特に「CI と Asset をどう同期させ、どちらを正とするか」は、資産・構成の両運用を設計するときに効いてきます。これらは本記事の「周辺機能」「状態」で触れた仕組みの先にあたり、別記事で扱う予定です。
前提として、構成の視点（cmdb_ci）を先に押さえると理解しやすくなります。前回の「ServiceNow CMDB の中心テーブル cmdb_ci を実機で確認する：クラス階層・状態・CI関連の見方」も合わせて読むことをおすすめします。
用語
PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
CI：Configuration Item（構成アイテム・cmdb_ci）
Asset：資産（alm_asset）。調達・コスト・所有の視点で管理するレコード
ALM：Asset Lifecycle Management（資産ライフサイクル管理。テーブル接頭辞 alm_）
従属選択肢（dependent choice）：親フィールドの値ごとに選べる候補が変わる選択肢（substatus が該当）
自分の環境で確認するときのURL
先頭に自分のインスタンスを付けると、同じ画面が開けます。
テーブル定義 : sys_db_object_list.do?sysparm_query=name=alm_asset
直接の子クラス : sys_db_object_list.do?sysparm_query=super_class.name=alm_asset
フィールド一覧 : sys_dictionary_list.do?sysparm_query=name=alm_asset^elementISNOTEMPTY
install_status : sys_choice_list.do?sysparm_query=name=alm_asset^element=install_status^inactive=false^ORDERBYsequence
CI と紐づく資産 : alm_asset_list.do?sysparm_query=ciISNOTEMPTY検証範囲とおことわり
確認した範囲：alm_asset の階層（ルート基底・直接の子4クラス）、固有フィールド数（74）、install_status（active 9）/ substatus（従属選択肢）
ci / model / model_category などの参照先、cost / po_number / assigned_to / owned_by
関連テーブルの存在、レコード件数、周辺設定件数。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています
確認していない範囲：CI⇄Asset の自動作成・同期の具体的な発火条件と挙動（skip_sync / Business Rule の内部ロジック）
各サブクラス（alm_hardware など）の固有フィールドと設定、減価償却（depreciation）の計算
Life Cycle Stage / Status の運用、Software Asset Management（ライセンス調整）の動作
Asset と CI が実データで1対1かどうかの突合（件数の近さは根拠にしません）
今回は PDI の OOTB（初期設定）を前提に、テーブルの構造を確認しました。実環境では、既存のカスタマイズによってフィールドや設定の数・内容が変わります。
