Product Catalog（cmdb_model）：型番を1件にまとめる台帳

同じ機種のノートPCを100台導入したとします。メーカー名と型番。画面サイズ、メモリ、価格。この仕様を100回入力したい人はいません。仕様は機種ごとに1回だけ書いて、100台の資産はそれを指させばいい。この分け方を ServiceNow は cmdb_model（モデル）というテーブルで実現しています。

分けておくと、後から効いてきます。「この機種の標準価格が改定された」というとき、直す場所はモデル1件だけ。100台の資産を触る必要はありません。

アプリケーションナビゲータには Product Catalog というメニューがあり、モジュールが15本ぶら下がっています。All Models、Model Categories、Hardware & Software Items、Vendors。名前だけ見ると資産管理のどこに効くのか分かりにくいのですが、中心にあるのは1つです。「型番の台帳」。今回は、この台帳が資産（alm_asset）や CI（cmdb_ci）とどう繋がるのかを、実機の件数と画面で確認します。

モデル・資産・CI は役割が違う

先に3つの言葉を並べておきます。似ているようで、指しているものが違います。

モデル（cmdb_model） は型番にあたります。「Dell Alienware M14x」という機種そのものを指し、何台持っていても台帳では1件。

資産（alm_asset）のほうは、買った1台ごとの記録になります。資産タグ、購入日、今どこにあるか、誰が使っているか。1台ずつ違う情報がここに入ります。

CI（cmdb_ci）は構成の視点で見た1台。どのサービスを支えているか、何と繋がっているか。障害調査や影響範囲の確認で使う側の顔です。

同じPC1台が、資産としてもCIとしても登場します。財務・調達の目で見れば資産、システム構成の目で見ればCI。そして両方が、共通の仕様として同じモデルを指します。

図の左端がモデル台帳です。ここから2本の道が出ています。1本は資産へ、もう1本は CI へ。その分岐を決めているのが真ん中の「モデルカテゴリ」で、この記事でいちばん見どころのある部分です。

モデル台帳の全体像

実測203件

まず一覧を開きます。cmdb_model_list.do が入口です。

登録されているモデルは 203件 でした。列は Name（名前）、Manufacturer（メーカー）、Model number（型番）、Model categories（モデルカテゴリ）。PDI の初期状態でこれだけ入っているので、動かしながら確認するには十分な量です。

6つのクラスに分かれている

モデルは1つのテーブルに全部入っているわけではありません。クラス（sys_class_name）で継承の枝に分かれています。一覧をクラスでグループ化すると、内訳が見えます。

ソフトウェアが92件で最多、ハードウェアが80件で続きます。消耗品15件、契約10件、設備1件。そして基底クラスのまま作られたものが5件あります。

ここで押さえたいのは、ソフトウェアや契約も「モデル」として扱われている点です。実物のあるハードだけが型番を持つのではありません。「Microsoft Access 2013 Windows」というソフトウェア製品も、「3年保守」という契約商品も、同じ台帳に型番として並びます。買うものはすべてモデルにできる、という設計です。

モデルカテゴリが決める2つの行き先

cmdb_model_category は 128件 ありました。名前を見ると Computer、Printer、Rack、Linux Server。一見すると単なる分類ラベルですが、このテーブルには2つの重要なフィールドが入っています。

asset_class：どの資産テーブルに作るか

1つめが asset_class です。そのカテゴリのモデルから資産を作るとき、どのテーブルに行を作るかを決めます。

• Computer カテゴリなら alm_hardware

• Consumable カテゴリなら alm_consumable

• Software License カテゴリなら alm_license

cmdb_ci_class：どのCIクラスに作るか

2つめが cmdb_ci_class です。CI 側の行き先で、Computer カテゴリなら cmdb_ci_computer、Printer なら cmdb_ci_printer。サーバは OS ごとに細かく分かれていて、AIX Server は cmdb_ci_aix_server、ESX Server は cmdb_ci_esx_server に対応します。

実機の設定を並べると、この2列の組み合わせがよく見えます。

片方だけのカテゴリもある

表をよく見ると、両方が埋まっていないカテゴリがあります。Consumable と Software License は asset_class だけ持ち、cmdb_ci_class は空。消耗品やライセンスは台帳に載せたいが、構成図に置くものではないからです。逆に Business Service は cmdb_ci_class だけを持ち、asset_class は空。サービスは構成の要素であって、買った1台ではありません。

数で見るとさらにはっきりします。asset_class が入っているカテゴリは 31件 だけでした。内訳は alm_hardware が27件、alm_asset が2件、alm_consumable と alm_license が各1件。残る 97件 は asset_class が空です。つまりカテゴリの4分の3は、資産を作らず CI 側だけを担当しています。

資産にするかどうかはモデル側でも指定できる

カテゴリで決まった行き先を、モデル単位で上書きすることもできます。それが asset_tracking_strategy フィールドで、選択肢は3つでした。

• Leave to category（カテゴリの決めに従う）… 既定値

• Create consumable asset（消耗品として作る）… 1台ずつではなく数量で数える

• Don't create assets（資産を作らない）… 台帳に載せない

3つめが効くのは、たとえばマウスやケーブルのような、金額が小さく1本ずつ追う意味の薄いものです。全部を資産にすると台帳が膨らむだけなので、モデルの時点で「これは作らない」と決めておく。台帳を実務で使い続けるための、地味ですが効く設定です。

資産テーブルも継承で枝分かれしている

カテゴリが指す asset_class の値を並べると、資産側も1枚のテーブルではないことが分かります。実測で登場したのは4つでした。

• alm_asset … 資産の基底テーブル。2,819件すべてがここに含まれる

• alm_hardware … 実物の機器。1台ずつ資産タグを持つ

• alm_consumable … 消耗品。数量でまとめて数える

• alm_license … ソフトウェアライセンス

モデル側が6クラスに分かれていたのと同じ構図です。型番の性質に合わせて資産の持ち方も変わるので、両者が対で分岐している。カテゴリはその対応表として真ん中に立っています。

この構造を知らないまま alm_hardware だけを見ていると、「資産が819件しかない」と読み違えます。基底の alm_asset を見れば2,819件。どの枝を見ているかで数字が変わるので、件数を報告するときはテーブル名まで添えるのが安全です。

メーカーは会社テーブルを参照する

モデルの Manufacturer は自由入力ではありません。core_company（会社）への参照でした。Dell Inc. も APC も Asus も、会社レコードとして1件ずつ存在します。

参照にしておく利点は、表記ゆれが起きないことです。「Dell」「DELL」「Dell Inc.」がばらばらに入ると、メーカー別の集計が壊れます。参照なら選ぶだけなので、同じ会社は必ず同じ1件を指します。

core_company は仕入先や顧客としても使われる共通テーブルです。同じ会社が、あるモデルではメーカー、ある契約ではベンダーとして登場する。会社を1か所にまとめておく設計が、ここでも効いています。

1件開いてみる：Dell Alienware M14x

一覧から Hardware Model を1件開きます。

上部の3項目

フォームの最上部に Display name、Manufacturer、Name が並びます。実測では Display name が「Dell Inc. Alienware M14x」、Manufacturer が「Dell Inc.」、Name が「Alienware M14x」でした。Display name は自分で入力する項目ではありません。メーカー名と機種名を繋げた表示用の値です。参照先から選ぶときに「どのメーカーの何か」が一目で分かるようになっています。

General タブに並ぶもの

タブは General から始まり、実測の値はこう入っていました。

• Short description … DELL Alienware M14x Intel Core i5 2430M(2.40GHz) 14" 8GB Memory 750GB HDD NVIDIA GeForce GT 555M

• Model categories … Computer（鍵アイコン付き）

• Model number … AM14x-6667SBK

• Barcode … AM14x-6667SBK

• Asset tracking strategy … Leave to category

• Cost … $2,099.99

• Salvage value … $0.00

• Status … In Production

• Certified … オン

Model categories に鍵アイコンが付いているのは、この値が複数選択のリスト型（glide_list）で、編集にひと手間かかる状態を示しています。1つのモデルが複数のカテゴリに属せる作りです。

Cost は「この機種の標準価格」であって、実際に買った1台の取得価格ではありません。個々の購入価格は資産側に入ります。モデルは定価、資産は実売。この住み分けを覚えておくと、金額の食い違いに悩まずに済みます。

6つのタブと4つの関連リスト

タブは General / Information / Compatibles / Substitutes / Configuration items / Product Catalog の6つ。このうち Compatibles は互換品、Substitutes は代替品を持つタブになります。「この機種はもう買えないが、これで代用できる」という知識を、型番同士の関係として台帳に残せる作りです。

調達の現場では、この情報が口伝えで消えていきがちです。担当者の頭の中にある「あれの後継はこれ」を、モデル同士のリンクとして残しておく。それだけで、次に同じ検討をする人の時間が浮きます。

フォーム下部の関連リストは Assets（1件）、Model Components、Vendor Catalog Items（1件）、Hardware Model Lifecycles の4つ。Assets タブには「Model = Dell Inc. Alienware M14x」という条件が表示され、この機種の実機が何台あるかがその場で分かります。台帳と現物が、モデルを介して繋がっている様子がここで見えます。

Model Components は構成部品です。1つの機種が複数の部品から成るとき、その組み合わせを持てます。Hardware Model Lifecycles は、発売から販売終了、サポート終了までの日付を持つタブ。「この機種はいつまで買えて、いつまで直してもらえるか」を機種側に持たせておけば、更改計画の材料になります。

Related Links には「Publish to Hardware Catalog」というリンクがありました。これが後述の製品カタログへの出口です。

実際の資産はどのカテゴリに寄っているか

モデル側の設計を見たので、資産側の実態も数えておきます。alm_asset は 2,819件 ありました。モデルカテゴリで集計すると、偏りがはっきり出ます。

上位2つで2,600件を超えます。消耗品が最多なのは、1行が「在庫のまとまり」を表すからです。置き場所ごとに行が増えます。Computer の819件は、実際のPC台数に近い数字です。

この集計は、モデルカテゴリが単なる分類ではなく、資産の集計軸として実際に使われていることも示しています。「PCが何台あるか」を数えるとき、カテゴリで絞れば済みます。

製品カタログ品目：買える形にしたモデル

Product Catalog メニューには、モデルとは別にもう1つのテーブルがあります。pc_product_cat_item（製品カタログ品目）で、実測 54件 でした。

ハードウェアとソフトウェアで分かれる

こちらもクラスで分かれていて、pc_hardware_cat_item が41件、pc_software_cat_item が13件。実データはこうなっていました。

モデルとの違い

モデルと製品カタログ品目は、同じ製品を別の角度から持ったもの。モデルは仕様の台帳で、寸法や消費電力まで入ります。いっぽう製品カタログ品目は売り物としての姿になり、価格と説明が主役に変わります。Access という品目が Microsoft Access 2013 Windows というモデルを参照しているのは、この2つが橋渡しされている印です。

表の1行目に注目すると、プライバシーフィルタの品目にはモデルが設定されていません。品目だけ作ってモデルを紐づけない状態もあり得る、ということです。この状態でも注文はできますが、買った後に資産として台帳に残す道筋は弱くなります。

先ほどモデルのフォームで見た「Publish to Hardware Catalog」は、この橋を渡すためのリンクです。台帳に登録した機種を、注文できる品目として出す。ベンダー品目（pc_vendor_cat_item）も134件あり、同じ製品を仕入先ごとに持ち分ける仕組みが用意されています。同じPCでも仕入先によって値段と納期が違うので、その差をここで吸収します。

モデルに増えた環境負荷のフィールド

cmdb_model の辞書を眺めていて目についたのが、環境負荷に関するフィールド群です。実測では次の項目が標準で並んでいました。

• manufacturing_emission（製造時の排出 kgCO2e）

• transportation_emission（輸送時の排出 kgCO2e）

• usage_emission（使用時の排出 kgCO2e）

• eol_emission（廃棄時の排出 kgCO2e）

• expected_lifetime_co2e（生涯 CO2e）

• typical_energy_consumption（標準消費電力量 kWh）

• energy_star（Energy Star 適合）

製造から廃棄までの4段階を、それぞれ別のフィールドで持っています。1台ごとではなく機種ごとに持つのは理にかなっています。同じ型番なら製造時の排出量は同じで、台数を掛ければ全体が出るからです。資産管理の台帳が、そのまま環境報告の元データになる作りです。

ただし、この PDI で値が入っているモデルがあるかどうかまでは確認していません。項目が用意されていることだけを確認しました。

どこから触るか

実機で追うときの入口をまとめておきます。いずれも自分のインスタンスのURLの後ろに付けます。

• /cmdb_model_list.do … モデル台帳の全件

• /cmdb_model_list.do?sysparm_query=GROUPBYsys_class_name … クラス別の内訳

• /cmdb_model_category_list.do … モデルカテゴリと2つの行き先

• /pc_product_cat_item_list.do … 製品カタログ品目

• /alm_asset_list.do?sysparm_query=GROUPBYmodel_category … 資産をカテゴリで数える

カテゴリの一覧では、列に asset_class と cmdb_ci_class を出しておくと理解が早くなります。この2列が、資産とCIの作られ方を決めている実体だからです。

まとめ

型番を1件にまとめる。この単純な仕組みの上に、資産管理の実務がのっています。

モデルは仕様の台帳で、実測203件が6クラスに分かれていました。モデルカテゴリ128件が asset_class と cmdb_ci_class の2つの行き先を持ち、資産とCIのどちらを作るかを決めています。作るかどうかはモデル側の asset_tracking_strategy で上書きでき、消耗品扱いにも対象外にもできる。そして製品カタログ品目54件が、同じ製品を価格つきの売り物として持ち直します。

資産2,819件の内訳がカテゴリごとにきれいに分かれていました。この設計が実データの上でも機能している証拠です。

台帳を作るとき、モデルを飛ばして資産だけ登録することもできてしまいます。ただ、それをやると同じ機種の仕様が資産の数だけ散らばり、後から直せなくなります。先にモデルを整えてから資産を積む。順番を守るだけで、台帳の寿命が変わります。

用語

• モデル（cmdb_model） … 型番の台帳。何台あっても1件。仕様と定価を持つ

• モデルカテゴリ（cmdb_model_category） … 資産テーブルとCIクラスの行き先を決める分類

• asset_class … そのカテゴリのモデルから作る資産テーブル（alm_hardware など）

• cmdb_ci_class … そのカテゴリのモデルから作るCIクラス（cmdb_ci_computer など）

• asset_tracking_strategy … 資産を作るかどうかのモデル単位の指定（3択）

• 製品カタログ品目（pc_product_cat_item） … モデルを価格つきの売り物として持ち直したもの

• ベンダー品目（pc_vendor_cat_item） … 同じ製品の仕入先ごとの持ち分け

自分の環境で確認するときのURL

• /cmdb_model_list.do（モデル台帳203件）

• /cmdb_model_list.do?sysparm_query=GROUPBYsys_class_name（クラス別内訳）

• /cmdb_hardware_product_model.do?sys_id=...（1件のモデルフォーム）

• /cmdb_model_category_list.do?sysparm_query=asset_classISNOTEMPTY（行き先が設定されたカテゴリ）

• /pc_product_cat_item_list.do（製品カタログ品目54件）

実測の要点（再掲）

• cmdb_model 203件 ＝ Software 92 / Hardware 80 / Consumable 15 / Contract 10 / 基底 5 / Facility 1

• cmdb_model_category 128件のうち、asset_class が入っているのは31件（残り97件はCI側だけ）

• asset_tracking_strategy は Leave to category / Create consumable asset / Don't create assets の3択

• alm_asset 2,819件の上位は Consumable 1,789 / Computer 819 / Software License 77

• pc_product_cat_item 54件 ＝ Hardware 41 / Software 13。pc_vendor_cat_item は134件

• Alienware M14x の実測: 型番 AM14x-6667SBK、カテゴリ Computer、Cost $2,099.99、Status In Production

検証範囲とおことわり

• 件数・項目・選択肢は PDI（Zurich / OOTB）の実測です。本番環境の設定・データとは異なります。

• モデルから資産やCIが自動生成される受入処理そのものは、この記事では実行していません。カテゴリの設定値までの確認です。

• 製品カタログ品目とサービスカタログ品目（sc_cat_item）の連携動作は未検証です。参照フィールドの存在だけを確認しました。

• 環境負荷フィールドは項目の存在を確認しただけで、値の有無や算出方法は検証範囲外です。

• ITAM 系のモジュールはライセンスやプラグインの前提により、環境ごとに見え方が変わります。

参考リンク

• Model categories（ServiceNow Docs）

• Models（ServiceNow Docs）

• Creating software models（ServiceNow Docs）

• Create model categories（ServiceNow Docs）

• Enterprise model categories and corresponding classes（ServiceNow Docs）

• Assets, Configuration Items, and Model Categories（ServiceNow Community）

• Asset tracking strategy の Leave to Category（ServiceNow Community）

• Assets and CIs: Understanding the Difference（ServiceNow Community）

• Model categories and asset class（ServiceNow Community）