SAMとほかモジュールの連携（既存資産管理・CMDBとの棲み分け）

すでにCMDBで実機を管理し、Asset Managementでライセンスを台帳管理している環境があります。そこにSAM（Software Asset Management）を追加すると、それぞれ別のマスタが並び立ってしまうのではという不安が生まれます。結論は逆で、SAMは新しいマスタをほとんど作らず、既存のalm_asset・CMDB・core_companyにそのまま乗る設計です。 唯一の例外はライセンス製品カタログで、独自マスタを持ち込みます。Australia PDIで実際の参照関係をたどって確認します。

既存の資産管理とCMDBに二重のマスタができるのではという不安

Asset ManagementでPCやライセンスの台帳を運用し、CMDBで実機のCIを管理してきた環境があるとします。そこにSAMを追加した瞬間、ライセンスの権利がSAM独自のテーブルへ複製され、CMDB側の実機情報とは別に「SAM版の実機一覧」が生まれるとしたら、運用は二重管理です。同じPCの情報を2箇所で直す羽目になり、どちらが正か常に気にしながら運用することになります。読者が本当に知りたいのは、SAMを入れた瞬間に何が「新しく作られる」もので、何が「既存のものを参照するだけ」なのかという境界線です。

SAMは新しいマスタ管理ツールではなく、既存の資産管理に乗る照合エンジン

SAMという名前だけを見ると、独立したライセンス管理システムのように思えます。しかし実態は違います。既存のAsset Managementプラットフォームの上に乗る「ライセンス照合」担当のアプリケーションです。Asset Management自体の公式説明（原文）です。

（訳: Asset Managementプラグインは、すべての資産・消耗品・ソフトウェアライセンスを管理するために使います。）

引用元: /v_plugin_list.do?sysparm_query=id=com.snc.asset_management

「software licenses」という言葉が、SAM導入前からすでにAsset Managementの守備範囲に含まれています。SAMが追加するのは、この既存の資産に対して「権利と実態が合っているか」を照合するエンジンと、その判定に必要な製品カタログです。SAMも会社情報そのものは管理せず、既存マスタを参照して成り立ちます。プラグインが既存の共通基盤に乗る構造そのものは、プラグイン（v_plugin/sys_plugins）の有効・無効と依存で見た依存関係の読み方が前提になります。

SAM以前は、買った数と入っている数を名前で突き合わせるしかなかった

SAMを導入する前のAsset Managementにも、ライセンス（alm_license）とインストール実態（cmdb_ci_spkg）を結びつける仕組みは存在しました。ただし買ったライセンス数と実際のインストール数、alm_license・cmdb_ci_spkgを実機で読むで確認したとおり、正式な参照フィールドではなく名前の一致に頼る作りでした。

Software Entitlement（alm_license）のフォームを開くと、この構図がそのまま見えます。上段のPurchased rights・Active rights・Unit costはSAMが照合のために使う項目です。下段のCompany・Location・Department・Owned by・Serial numberは、Asset Managementが最初から持つ資産共通の項目です。1枚のフォームに、既存の資産属性とSAM独自の照合項目が同居しています。

連携相手は6つ。関係のかたちは継承・参照・独自マスタの3種類に分かれる

SAMが何とどうつながるのかを1枚にまとめます。

図の色は関係の種類を表します。濃紺が主役のSAM、緑が実データで直結している既存インフラ（既存の資産管理・CMDB・SAM独自の正規化ステージ）です。青は参照する共有マスタのcore_company、紫は独自の別マスタやSAMの外側にある別アプリケーションを表します。同じ内容を、何を共有して何を共有しないのかという観点で表にすると次のとおりです。

alm_assetを継承しているとは何を意味するのか

sys_db_objectでテーブル定義を確認すると、Software Entitlement（alm_license）のsuper_classはAssetでした。SAM専用の新しいテーブル階層ではなく、既存の資産管理の子クラスとしてそのまま実装されています。これは、CMDBのConfiguration Item（cmdb_ci）が独自の継承ツリーを持つのとは対照的です。ライセンスという「モノ」は資産（Asset）の一種として扱い、実機という「モノ」はCI（Configuration Item）として扱う、という役割分担がテーブル設計そのものに表れています。

この一覧に並ぶ77件のSoftware Entitlementは、SAMを導入したから増えたものではありません。SAM導入前からalm_licenseに存在する既存の資産管理のデモデータで、作成日はすべて2025年でした。今回の検証で作成した2件（Acrobat DC Professional・Standard）を加えて現在は79件です。SAMは既存の資産をゼロから作り直さず、既存のレコードに照合という新しい仕事を追加しただけだと分かります。

なぜ資産(alm_asset)とCMDB(cmdb_ci)はそもそも別テーブルなのか

両者の目的は別です。この設計を理解する前提として、資産と構成の違いを押さえておく必要があります。資産(alm_asset)とCMDB(cmdb_ci)を分ける理由で扱われているとおり、alm_assetは「いくらで買って誰が持っているか」という調達・会計の情報を持ちます。一方のcmdb_ciが持つのは「今どう構成され何に依存しているか」という運用の情報で、この役割分担はSAM導入前からの設計です。SAMがライセンスをalm_asset側の子クラスとして実装したのは、ライセンスが「調達した権利」という性格を持つ以上、自然な選択だと読み取れます。

cmdb_ciとの接点は「何が入っているか」と「誰が使っているか」の2本

CMDBとの接続は参照フィールドで実現されており、テーブルの継承は使われていません。インストールの実態を持つcmdb_sam_sw_installのinstalled_onフィールドの公式説明（原文）です。

（訳: そのソフトウェアがインストールされているハードウェア。）

引用元: /sys_documentation_list.do?sysparm_query=name=cmdb_sam_sw_install^element=installed_on

実際に検証用のインストール実態を投入すると、installed_onには*CHUCK-IBMやANDREWDWXP、DC01といった、SAM導入前からcmdb_ciに存在する実在のCIレコードがそのまま入りました。SAMのために新しいCIを作る必要はなく、既存のCMDBのCIを指すだけです。もう1本の接点は、権利の割り当てを表すalm_entitlementのallocated_toフィールドです。

（訳: このライセンストークンを消費しているCI。）

引用元: /sys_documentation_list.do?sysparm_query=name=alm_entitlement^element=allocated_to

「何がインストールされているか」はcmdb_sam_sw_install.installed_on、「誰がその権利を使っているか」はalm_entitlement.allocated_toと、2つの異なる意味でCMDBのCIを参照します。どちらのテーブルもCIクラスそのものを継承しておらず独立したテーブルなので、SAMを導入してもCMDBのクラス階層は変わりません。あくまで既存のCIを指す矢印が2本増えるだけです。

102クラスあるcmdb_ciのうち、SAMは特定のクラスに縛られない

cmdb_ciはServiceNowのCIはどのテーブルに入る？ cmdb_ciの102クラスを実機で確認で見たとおり、PC・サーバからネットワーク機器まで102クラスに枝分かれした継承構造を持っています。installed_on・allocated_toはどちらも基底クラスのcmdb_ciを参照先に指定しているため、SAMはどのクラスのCIかを問わずソフトウェアの導入先として扱えます。特定のクラスに限定しない設計のおかげで、将来CMDB側にクラスが追加・変更されてもSAM側の参照定義を直す必要がありません。

「Publisher」という同じ名前のマスタがもう1つ存在する

会社の実体を管理するcore_companyは、SAMからも直接参照されています。組織情報を一元管理するcore_companyの設計は組織テーブル：会社・部署・原価の3枚（core_company）で扱われているとおりです。照合結果の出版社集計を持つsamp_publisher_resultのpublisherフィールドと、インストール実態の正規化後の出版社を持つcmdb_sam_sw_installのnorm_publisherフィールドは、どちらも参照先がcore_companyです。ところが、SAMにはこれとは別に、独自の「Publisher」を名乗るテーブルがもう1つあります。

samp_sw_publisherというライセンス製品コンテンツの台帳で、1,794件のパブリッシャーが最初から入っています。この一覧のManufacturer列はcore_companyへの参照フィールドです。ただし表示されている20件はすべて空でした。実際に集計すると、1,794件のうちcore_companyと接続しているのはわずか49件で、残り1,745件は未接続でした。samp_sw_publisherは「世の中に存在するソフトウェア出版社の一般的なカタログ」であって、「自社が取引している会社」を管理するcore_companyとは母集団も目的も異なります。マスタは2系統あります。

同じ「Publisher」という名前の紛らわしさは、既存の資産管理側にも及んでいます。

既存の資産管理が持つSoftware Model（cmdb_software_product_model）にも「Publisher」という列があります。こちらは92件のデモデータです。SAM導入前から存在し、Publisher列にはcore_companyのAdobe Systemsなどへのリンクがすでに入っています。一方でProduct列（SAMのコンテンツ台帳samp_sw_productへの参照）はすべて空です。既存の資産管理は最初からcore_companyとつながっていたが、SAMのコンテンツ台帳とはまだつながっていなかった、という導入前の状態がそのまま画面に残っています。

Software Modelという名前は、Product Catalog（cmdb_model）の型番管理を受け継いでいる

cmdb_software_product_modelのsuper_classは「Product Model」でした。同じ系統のテーブルはProduct Catalog（cmdb_model）：型番を1件にまとめる台帳で扱われている、型番を1件にまとめる仕組みです。SAMのSoftware Modelは、この型番管理の枠組みをソフトウェア向けに使い回したもので、ハードウェアの型番と同じ考え方でソフトウェアのバージョン・エディションを1件にまとめています。

「Discovery」という名前のテーブルは、ITOM Discoveryの実行結果ではない

SAMのメニューには「Discovery Models」という項目があり、cmdb_sam_sw_discovery_modelというテーブルが対応します。名前だけを見ると、実機をネットワーク経由でスキャンするITOM Discoveryの結果を保存するテーブルに思えます。ITOM Discoveryが実際に何を調べに行くかはServiceNowのDiscoveryは何を調べに行く機能なのか？ discovery_probes 143件を実機で分類するで扱ったとおりです。ところが今回のPDIでは、ITOM Discoveryの実行に必要なcom.snc.itom.discovery.licenseプラグインはInactiveのままでした。ITOM Discoveryとは無関係に、cmdb_sam_sw_discovery_modelは動いています。

検証用のインストール実態を手動で投入すると、Business Ruleが自動的にDiscovery Modelを生成しました。生成されたレコードのdiscovery_sourceフィールドの値はManualです。この値が示すとおり、SAMの「Discovery Model」は実機スキャンの結果ではありません。インストールの実態（手動投入でもAPI連携でも構わない）を正規化する前段のステージという意味です。ITOM Discoveryを導入していない環境でも、SAMのDiscovery Modelという仕組み自体は動作します。両者は名前が似ているだけの別物です。この境界線を知らずに「Discoveryが必要」と誤解すると、導入検討の段階で余計な調達判断をしてしまいます。

実務ではどう役割分担して運用するか

ここまでの参照関係を踏まえると、運用の役割分担は次のように整理できます。推測を含む設計提案として読んでください。

• 実機の実在・所在情報はCMDB側で一元管理する。担当はインフラ・CMDB管理のチームで、SAMを入れてもcmdb_ciそのものを触る必要はありません。CMDB側のデータ品質を整える具体策はCMDB運用設計書にまとめています

• 会社の実在情報はcore_company側で一元管理する。取引先評価に使うのと同じレコードをSAMも出版社として使うため、vendor・manufacturerフラグの整備は部門横断で1回やれば両方に効きます

• ライセンス製品の正規化台帳（samp_sw_publisher・samp_sw_product）はSAM側の専任担当を置く。世の中のソフトウェア一般を対象にした別マスタなので、自社の取引先台帳とは別軸でメンテナンスが要ります

• Discovery Modelの投入経路は事前に決めておく。ITOM Discoveryを別途導入するのか、手動・API連携で正規化前レコードを作るのかによって、運用の負荷が大きく変わります

• 既存の資産台帳そのものの整備は既存の資産管理側の仕事として残る。調達から廃棄までの台帳運用は資産管理（Asset）運用設計書の対象で、SAMはその台帳の上に照合を足すだけです

会社という「モノ」はcore_company、実機という「モノ」はcmdb_ci、ライセンスという「モノ」はalm_assetという3つの既存マスタに、SAMは新しいレコードをほとんど足さずに乗っています。新しく足すのは、世の中のソフトウェアを正規化するためのsamp_sw_publisher・samp_sw_productという1系統だけです。導入前に確認すべき観点は、「SAMが何を作るか」よりも「どの既存マスタのデータ品質が照合結果に直結するか」です。

照合結果のPublisher列は、会社マスタcore_companyのレコードを指している

SAM独自のマスタsamp_sw_publisherが1,794社あるにもかかわらず、照合結果のPublisher列が指すのは既存の会社マスタです。実際に照合結果を開いて確かめます。

この画面のPublisher列「Adobe Systems」は、samp_publisher_result.publisherが指すcore_companyのレコードです。偶然の一致ではありません。sys_idを突き合わせると、会社マスタに1件だけ存在するAdobe Systemsのレコードそのものでした。core_company側でこのレコードはvendorとmanufacturerの両方が真になっています。

（訳: 「彼らから物を買っている」「彼らは私たちが買うものを作っている」）

引用元: /sys_documentation_list.do?sysparm_query=name=core_company^elementINvendor,manufacturer

SAMが見ているのは「manufacturer=true（製造元）」という側面です。同じレコードの「vendor=true（購入先）」という側面は、購買や取引先管理の機能が使います。1つの会社レコードに複数の側面のフラグを持たせ、各アプリが必要な側面だけを参照するという会社マスタの設計です。この設計が、照合結果の1画面にそのまま現れています。

実機で気づいたこと

症状: 「Publisher」という同じ列名が、参照先の異なる3つの意味で使われている。 samp_sw_publisher（SAM独自のコンテンツ台帳1,794件）、samp_publisher_result.publisher（core_company参照）、cmdb_software_product_modelのPublisher列（同じくcore_company参照）が、同じ表示名を持ちます。名前が同じでも別物です。原因はcore_companyがvendor・manufacturerという複数の側面フラグを1レコードに持たせる設計にあります。複数のアプリが、同じ会社レコードを別の役割で参照します。回避策は、列名だけで同一テーブルと判断せず、参照先テーブル（Reference先）を必ず確認することです。

症状: Discovery Modelsという名前から、ITOM Discoveryのスキャン結果を想像してしまう。 検証用のインストール実態を投入して生成されたレコードのdiscovery_sourceはManualでした。原因はcmdb_sam_sw_discovery_modelがインストール実態を正規化する前段のステージを表すテーブルで、ITOM Discoveryとは別系統だからです。ITOM Discoveryプラグイン（com.snc.itom.discovery.license）が検証環境でInactiveのままでも、Discovery Modelの生成は動作しました。スキャンは不要です。回避策は、導入検討時にdiscovery_sourceの値で実行元を判別し、「Discoveryが必要」という誤解で余計な調達判断をしないことです。

症状: 既存デモ（Entitlement 77件・Model 92件）がSAM導入後もほぼそのまま残っている。 原因はSAMが既存レコードを作り直さず、既存の資産に照合という処理を追加するだけの設計だからです。回避策は、導入前後の件数を比較するときに、テーブル定義の増分（差分調査編で実測済み）と業務データの行数を分けて数えることです。定義系の増分とレコード件数を混同すると規模を見誤ります。

用語

• cmdb_ci（CMDB） … 実機・サーバのConfiguration Item。SAMは参照するだけでCIクラスは継承しない

• core_company（会社マスタ） … 会社情報の一元管理テーブル。vendor・manufacturer等のフラグで種別を判別する

• samp_sw_publisher … ソフトウェア出版社1,794件を持つSAM独自の別マスタ。core_companyとの接続は一部のみ

• cmdb_sam_sw_discovery_model … インストール実態を正規化する前段のステージ。ITOM Discoveryの実行結果ではない

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

• Software Entitlements一覧：/alm_license_list.do

• 既存の資産管理のSoftware Models一覧：/cmdb_software_product_model_list.do

• SAMのコンテンツ台帳（Publisher）一覧：/samp_sw_publisher_list.do

• Discovery Models一覧：/cmdb_sam_sw_discovery_model_list.do

• Publisher Resultsの一覧：/samp_publisher_result_list.do

引用した公式説明を自分で開く

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINcmdb_sam_sw_install,alm_entitlement,core_company^hintISNOTEMPTY

• プラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=id=com.snc.asset_management

検証範囲とおことわり

Australia PDIに、OOTBの状態からTPRM（sn_vdr_risk_asmt）と、SAM本体（Storeアプリ＋Foundation＋SAM Professional）を導入して確認しました。2026-08-23時点のこの環境のものです。導入手順は、照合を成立させるまでの実機ハンズオンはで扱っています。確認していない範囲は次のとおりです。

• ITOM DiscoveryおよびSoftware Asset Workspace（sn_sam_workspace）という、今回導入していない周辺アプリを追加した場合の連携・画面差分

• samp_sw_publisherの残り1,745件が、将来のコンテンツ更新でどこまでcore_companyと接続されるか

• 本番相当の規模（数万台のインストール実態）で参照関係のパフォーマンスがどう変わるか

関連記事

• 前提知識：SAM（Software Asset Management）の基礎知識（）

• 次に読む：SAMの基本設定（）