買ったライセンス数と実際のインストール数、ServiceNowでどう突き合わせる？ alm_license・cmdb_ci_spkgを実機で読む
ソフトウェアライセンスを何本買ったかは契約書や発注履歴で分かります。しかし「実際に何台に入っているのか」は、ServiceNowでは別テーブル（cmdb_software_instance）を見ないと分かりません。買った記録（alm_license）とソフトの型（cmdb_ci_spkg）を結ぶ参照フィールドは用意されているのに、実機で確認すると1,767件中0件しか使われていませんでした。正式な参照が実データ上は存在しない以上、突き合わせは製品名の文字列一致に頼るしかなく、版の表記ゆれひとつで簡単に破綻します。
検証環境：Zurich PDI / OOTB / 2026-08-09 確認
この記事で分かること
「買った」「ソフトの型」「実際に入っている」の3テーブルがどう役割分担しているか
3テーブルの間に、実データ上は正式な参照リンクが存在しないという実機での確認結果
参照がないとき、名前の文字列一致だけで突き合わせるとどんな誤りが起きるか
棚卸しをするとき、どこから手をつければよいか
結論：3つのテーブルは「買った」「型」「実体」に分かれている
先に全体像です。ソフトウェアライセンスの管理は、大きく3つのテーブルに分かれています。
alm_license（77件） … 何本買ったか。契約・お金の視点
cmdb_ci_spkg（1,767件） … Discovery（検出）が作る、ソフトウェアの「型」の定義
cmdb_software_instance（6,580件） … 実際に1台へインストールされた記録
図の中央、alm_license と cmdb_ci_spkg の間の矢印だけ点線にしてあります。理由は後半で実機の数字とともに説明しますが、先に結論だけ書くと、この2つを結ぶ参照フィールドは存在するのに、今回のPDIでは1件も使われていませんでした。一方、cmdb_ci_spkg と cmdb_software_instance の間は実際に機能している参照関係でした。
買った記録：alm_license は何を持っているか
alm_license は、前回までの記事で確認した alm_asset の子クラスの1つです。資産管理の基底テーブル alm_asset を継承しているので、asset_tag・cost・vendor といった共通項目に加えて、ライセンス固有の項目を持っています。
一覧には Rights 列があります。今回のPDIでは77件すべてが State=In use で、Retired や Expired になっているライセンス記録はありませんでした。
rights と条件フィールド
固有フィールドで押さえておきたいのは次の3つです。
rights（Integer）… 購入した本数。ラベルは "Rights"
assigned_condition（ラベル "Assigned condition"）… 77件中4件で条件式が入っていました
entitlement_condition（ラベル "Allocated condition"）… 77件中7件で条件式が入っていました
条件式は、たとえば「Location が Apac のときだけ100本のうちから割り当ててよい」というような絞り込みです。実機で見つかった例だと、Citrix GoToMeeting 4.8（100本）には location.full_nameLIKEApac という条件が、Microsoft SQL Server 6.5（100本）には特定3社限定の条件が入っていました。すべてのライセンスに条件があるわけではなく、多くは条件なし（誰でも割当可能）です。
フォーム画面で分かったこと
このフォームで少し意外だったのは、General タブに assigned_condition や entitlement_condition そのものが項目として並んでいない点です。代わりに Device Entitlements と User Entitlements という関連タブが用意されていて、割当条件はこの関連レコード側で扱う設計になっていました。フィールドの存在と、実際に画面でどう使うかは別問題だと分かります。
ソフトの型と、実際のインストール：cmdb_ci_spkg と cmdb_software_instance
買った記録の次は、実際に動いている側です。ここは2段階に分かれています。
cmdb_ci_spkg は、Discovery（自動検出）や資産情報の取り込みによって作られる「ソフトウェアの型」の定義です。name・version・publisher に加えて、install_count という、そのソフトが何台に入っているかのロールアップ集計フィールドを持っています。
cmdb_software_instance は、1台へのインストール実体です。software フィールドで cmdb_ci_spkg を、installed_on フィールドで cmdb_ci（そのマシンのCIレコード）を参照します。
6,580件という数は、77件のライセンスや1,767件のソフト定義よりずっと多くなります。1つのソフトの型（例: ".NET Framework 2002"）が何台にもインストールされるので、当然この関係は1対多です。
cmdb_ci_spkg → cmdb_software_instance の software 参照は、実機のサンプルで確認した限りすべてのレコードで値が入っており、実際に機能している参照関係でした。
install_countは信頼できるか
install_count はこの1対多の関係を毎回数えなくて済むように用意されたロールアップ集計と考えられます。実機で2件をスポットチェックした結果は次のとおりです。"Access"（version 2000）は install_count=37 に対し、cmdb_software_instance を software 指定で実際に数えても37件でした。"3D Pinball"（version 5.0）も install_count=36 に対し実カウント36件で、どちらも完全に一致しました。棚卸しで「このソフトは何台に入っているか」をざっくり知りたいだけなら、cmdb_software_instance まで潜らずに cmdb_ci_spkg の一覧を見るだけで足ります。
3つの間はどう繋がっている？ 実は繋がっていなかった
ここが今回いちばん確認しておきたかった点です。「買った(alm_license)」と「ソフトの型(cmdb_ci_spkg)」は、同じ"ソフトウェア"という言葉を扱っています。両者を正式に結びつける参照フィールドはあるのでしょうか。
alm_license 側は alm_asset を継承しているので model フィールド（Reference → cmdb_model）を持っています。一方 cmdb_ci_spkg 側にも model_id（ラベル "Model ID"、Reference → cmdb_model）という、同じ cmdb_model を参照できるフィールドが用意されていました。フィールドの型を見る限り、両者は cmdb_model 経由で繋がる設計に見えます。
ところが実機で model_id に値が入っている cmdb_ci_spkg レコードを絞り込みました。結果は0件でした。
1,767件のうち、model_id が設定されているレコードは1件もありませんでした。同様に、cmdb_ci_spkg には alm_asset を直接指す asset フィールドも用意されていますが、これも1,767件中0件でした。
つまり、alm_license（買った記録）と cmdb_ci_spkg（ソフトの型）を正式な参照で自動的に突き合わせる仕組みは用意されています。ところが今回のPDIのデータでは、この参照が1件も使われていませんでした。この2つのテーブルを繋ぐには、名前やバージョンを人間が読んで判断するか、SAM Pro のようなソフトウェア正規化（Normalization）機能を別途使う必要があります。SAM Pro 系のテーブル（cmdb_sam_sw_install など）は今回のPDIには存在しないため、正規化の実際の挙動は本記事の検証範囲外です。
名前で突き合わせると何が起きるか
理屈だけでは分かりにくい。実際の数字で確認します。alm_license には "Symantec Norton 360 5.0" として4件登録されていました。
購入記録を集計する
4本の契約（rights=50 / 100 / 250 / 150）を合計すると、550本購入している計算になります。これに対応する実際のインストールを探してみます。
実際のインストールを探す
まず cmdb_ci_spkg で "Norton 360" という名前のソフトの型を検索すると、結果は0件でした。
では実際にインストールされている cmdb_software_instance の側で、製品名に "Norton" を含むものを検索してみます。
41件見つかりました。ただし中身を見ると、Norton AntiSpam・Norton AntiVirus 2004・Norton AntiVirus 2005 など、同じSymantecブランドの別製品です。"360" という文字列を含む製品名は1件もありませんでした。
Norton 360として550本購入した記録があっても、その名前そのもののインストール実体は1台も見つかりません。alm_license と cmdb_ci_spkg を結ぶ正式な参照が実データ上存在しないことの、具体的な現れです。 実際には旧世代の Norton AntiVirus から乗り換えている、あるいは購入済みで未展開といった事情も考えられます。ただし、システムが自動で「これは同じソフトの新旧関係だ」と判断してくれるわけではありません。名前の文字列に頼る突き合わせでは、こうした表記ゆれがそのまま失敗として表面化します。
なぜ名前だけでは合わないのか
Norton 360だけが特殊なのか、他の購入記録でも同じ確認をしました。ズレ方には大きく2つのパターンがありました。
1つ目はバージョンのズレです。alm_license の購入データは2010〜2013年前後のエディション名が中心でした。具体例は Microsoft Word 2010 や Adobe Systems Acrobat DC Professional です。一方 cmdb_ci_spkg 側の検出データは、同じ製品名でも古い版が中心です。購入253本の Microsoft Word 2010 に近い名前は、cmdb_ci_spkg では "Word" version=2000（install_count=37）しかありませんでした。名前が一致していても、バージョンまで同一視してよいかは別の判断が必要になります。
2つ目は該当する型が存在しないケースです。該当するソフトの例は、Citrix GoToMeeting 4.8（購入630本）と IBM WebSphere Application Server 8.0.0 です。ほかに The Eclipse Foundation Eclipse 3.7.1 も同様でした。この3つはいずれも、cmdb_ci_spkg に近い名前の型そのものが1件もありませんでした。
名前が部分的に一致する場合でも、単純な文字列一致だけで突き合わせようとすると、「本当は同じ製品なのに一致しない」と「名前は似ているが実は別物なのに一致してしまう」の両方の誤りが起こり得ます。
なぜ3つのテーブルに分かれているのか
契約・定義・実体の3つに分かれているのには理由があります。
alm_license（買った） … 調達・IT資産管理担当が扱う。契約書・発注・コストの世界。人が入力する
cmdb_ci_spkg / cmdb_software_instance（型・実体） … Discovery や外部連携（SCCM等）が自動生成する。実機の状態を反映する世界
以前の記事で確認した「資産(alm_asset)とCMDB(cmdb_ci)を分ける理由」と同じ構図がここにもあります。「いくらで何本買ったか」という契約の話と、「実際に何が動いているか」という実機の話は、そもそも情報の出所が違うので別テーブルになっている、という理解が近いはずです。前者は人が発注時に入力し、後者は自動検出が実機から吸い上げます。出所が違う2つの世界を正しく突き合わせるには、単純な名前一致では足りず、正規化のロジックが必要になります。それを担うのが SAM Pro のソフトウェア正規化機能ですが、今回のPDIには存在せず、検証範囲外です。
もう一つ考えられる理由は、発注のタイミングと検出のタイミングがそもそもズレるという業務上の事情です。ライセンスは契約時点で1レコードが作られますが、実際にインストールされてDiscoveryに検出されるまで数週間〜数ヶ月かかることもあります。退職者のPCを回収した後もライセンス側の記録だけが残り、インストール側の実体だけ先に消えることもあります。もし alm_license と cmdb_ci_spkg が強い外部キーで固定されていたら、こうした時間差のたびに片方のレコードが宙に浮くはずです。ゆるく繋がる（あるいは今回のように繋がっていない）設計は、無関係な2つの業務プロセスの時間差を吸収する余白なのかもしれません。
実務でどう使うか：棚卸しはどこから見るか
ライセンスの過不足を確認したいとき、実務では次のような順序になります。
alm_license で「何本買ったか」を確認する … rights 列を製品ごとに集計する。今回のPDIのように条件付き（assigned_condition / entitlement_condition）の場合は、条件も合わせて確認する
cmdb_ci_spkg の install_count で「実際に何台に入っているか」の概算をつかむ … 前段で確認した通り install_count は実カウントと一致していたので、まずここでざっくり掴む。細かい内訳（どのマシンに入っているか）まで必要なときだけ cmdb_software_instance を software 別に絞り込む
1と2を製品名・バージョンで突き合わせる … 今回確認した通り、自動で結びつく参照は使われていないため、人が名寄せするか、SAM Pro の正規化ルールに頼る
ここまで見てきた alm_license / cmdb_ci_spkg / cmdb_software_instance の3テーブルは、SAM Foundation の範囲にあたります。ここだけで分かるのは、「買った数」と「検出された実インストール数」それぞれの実数です。この2つを自動で結びつけてコンプライアンス違反を判定するところまでは、Foundation の範囲では確認できませんでした。過不足を機械的に出したい場合は、SAM Pro のエンタイトルメント・正規化機能の導入を検討することになります。
参考：Run software reconciliation in the workspace（ServiceNow公式ドキュメント）
自分の環境で確認するときのURL
以下のURLの末尾を自分のインスタンスに付け替えると、本記事と同じ画面をそのまま開けます。
ライセンス一覧 : alm_license_list.do
ソフトの型一覧 : cmdb_ci_spkg_list.do
インストール実体一覧 : cmdb_software_instance_list.do
名前で絞り込む（型） : cmdb_ci_spkg_list.do?sysparm_query=nameLIKE<キーワード>
名前で絞り込む（実体） : cmdb_software_instance_list.do?sysparm_query=software.nameLIKE<キーワード>
model_idが設定済みか確認 : cmdb_ci_spkg_list.do?sysparm_query=model_idISNOTEMPTY自分の環境の alm_license と cmdb_ci_spkg でも、同じように名前とバージョンを見比べてみてください。
実機で気づいたこと
cmdb_ci_spkg には model_id（cmdb_model参照）と asset（alm_asset参照）という、alm_license側と正式に繋がるためのフィールドが用意されているのに、1,767件中どちらも0件でした。 フィールドが存在することと、実データで使われていることは別問題だと痛感しました。空のフィールドを見て「このシステムでは使われていない機能」と決めつけず、まず件数を数えて確認する癖がついた瞬間でした。
「Norton 360」を550本購入した記録があるのに、実インストールは0件でした。 近い名前の製品（Norton AntiVirus等）は41件見つかりましたが、購入した製品名そのものは1つも見当たりませんでした。名前が近いからといって同じ製品として数えてはいけない、という当たり前のことを実データで再確認できました。
alm_license のフォームには assigned_condition / entitlement_condition という項目名の割当条件フィールドがあるのに、標準フォームのGeneralタブには表示されていませんでした。 代わりに Device Entitlements / User Entitlements という関連タブで扱う設計です。ラベルも entitlement_condition は "Allocated condition" と表示され、フィールド名と画面表示名が一致していません。ドキュメント上のフィールド名だけを頼りに画面を探すと迷うポイントだと感じました。
参考ドキュメント
今回の内容に対応する公式ドキュメントです。
用語
PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
関連記事
資産(alm_asset)とCMDB(cmdb_ci)を分ける理由 … alm_asset が資産クラス階層のルートで、alm_license がその子クラスであることを確認した記事
契約はどの資産を守るか（ast_contract） … ソフトウェアライセンス契約とSAMの連携を本記事の先の話として位置づけていた記事。本記事はその接続にあたる
Product Catalog（cmdb_model）：型番を1件にまとめる台帳 … 本記事で「対応する参照が0件だった」と確認した cmdb_model を扱う記事
検証環境・検証範囲
検証環境：ServiceNow Zurich PDI（Personal Developer Instance）・OOTB（初期設定）・2026-08-09 確認。REST APIと実画面の両方で件数・フィールド値を確認しました
確認した範囲：alm_license / cmdb_ci_spkg / cmdb_software_instance の件数・主要フィールド・参照関係の有無、Symantec Norton 360を含む複数ソフトの名前・バージョンでの突き合わせ結果
検証範囲外にしたこと
SAM Pro（cmdb_sam_sw_install 等）… テーブル自体がこのPDIに存在せず、ソフトウェア正規化（Normalization）の実際の挙動は確認できていません
CI⇄Asset・ソフトウェア⇄ライセンスの自動同期ロジックの内部実装
Device Entitlements / User Entitlements 関連レコードの詳細な作られ方
今回のOOTBデモデータで購入記録と実インストールが一致しなかった具体的な原因（デモデータの生成時期のズレなのか、実運用でも起こりうる典型パターンなのかの切り分け）
本記事はPDIのOOTBデモデータに基づく検証です。実環境ではSAM Pro導入状況やDiscovery連携の設定によって、突き合わせの精度は大きく変わります。
