SAM（Software Asset Management）の基礎知識

2026年8月25日 17:13

買ったライセンスの数と、実際にインストールされている数。この2つが一致しているかを即答できる担当者は多くありません。ServiceNowのSAM（Software Asset Management）は、権利・実態・照合という3つのテーブル群でこのズレを継続的に計算する仕組みです。Australia PDIに実際に導入し、初期状態から1件の照合を完走させて実機で確かめます。

SAMは何のためのアプリで、既存のAsset Managementとどう違うのか
権利・実態・照合という3つの要素が、それぞれどのテーブルに対応するのか
導入直後のPDIには何が入っていて、何が空なのか
公式ドキュメントはSAMを何と説明しているのか

検証環境：Australia PDI / OOTB / 2026-08-23 確認

SAMとは：Software Asset Managementの略です。購入したソフトウェアライセンスの権利数と、実際のインストール実態を突き合わせ、過不足を継続管理する仕組みです。配布はStoreアプリ（sn_itam_samp）ですが、Foundation・Professionalという2つのプラグインまで有効化して初めて全機能が動きます。

導入後の最初の3手：①Professionalプラグイン（com.snc.samp）まで有効化する ②権利（alm_license）を登録し、対象ソフトウェアの製品紐付けを済ませる ③週次ジョブを待つか、Run Reconciliationを手動実行して結果を確認する

SAMの運用は「誰が・どの順で・何をするか」で捉えると全体がつかめます。先にライフサイクル全体を1枚にまとめます。

色の対応は、濃紺がSAM管理者の操作・水色が自動処理・緑がSAM利用者の確認・橙が判断の分岐点です。管理者が権利と実態を用意すると、あとは週次ジョブが自動で照合し、過不足があれば管理者が調整して次の週へ戻ります。

本記事は9本シリーズの親記事です。各論は次の記事で扱っています。

名前や役割が似ている機能との違い

SAMの周りには、似た言葉・似た役割の機能が複数あります。混同しやすいものの区別を先に済ませます。

Asset Management（資産管理） … PCや契約など「モノ」の台帳。SAMはこの台帳の上で、ソフトウェアライセンスの過不足計算だけを専門に担当します
CMDB（構成管理） … どのサーバに何が入っているかという構成の記録。SAMは記録そのものは持たず、記録と権利を突き合わせて過不足を出します
SAM FoundationとSAM Professional … 同じ「Software Asset Management」の名前を持つ2階層のプラグイン。Storeアプリの依存で自動的に入るのがFoundation、照合を動かすには別途Professionalの有効化が必要です
Software Asset Workspace … SAM用のワークスペース画面だけを提供する別のStoreアプリ。本体を入れても付いてきません

買った数と入っている数が一致しているとは限らない

ソフトウェアライセンスは、契約書と請求書と実際のインストール台数がそれぞれ別の場所で管理されがちです。ライセンス監査が入ったとき、購入した権利数を超えてインストールしていないかを即座に答えられる状態が理想です。担当者が本来期待するのは、権利と実態が自動で突き合わされ、過不足がひと目で分かる状態でした。

この理想と現実のギャップは、SAMを導入する前のServiceNowで先に確かめられています。alm_license（購入した権利）とcmdb_ci_spkg（インストールされたソフトウェアパッケージ）を実機で読んだ調査がそれです。両者を正式につなぐ参照フィールドは存在せず、名前の一致だけを頼りに突き合わせるしかないという結果でした。詳しくは買ったライセンス数と実際のインストール数、ServiceNowでどう突き合わせる？で扱っています。

SAMは、この突き合わせを構造化されたテーブル群と自動実行される照合処理に置き換える専用アプリです。

SAMは既存のAsset Management基盤の上に乗るITAM専門アプリだった

SAMを導入する前から、ServiceNowにはAsset Management（資産管理）が入っています。ハードウェアや契約を管理するalm_assetという共通のデータモデルで、会社が持つ「モノ」を管理する基盤がすでにあります。

Software Asset ManagementのStore上のカテゴリ名は「Software Reconciliation and Compliance」です。コンプライアンスという言葉が付きますが、依存関係はStore→Foundation→Professionalという3段のプラグインだけで、統制系の共通基盤への依存はありません。SAMは社内資産を扱うITAM（IT Asset Management）の専門アプリです。アプリとスコープの基本的な考え方はアプリとスコープ：Globalとx_の違い（sys_app）で扱った通りです。

alm_license（Software Entitlement、権利の台帳）は、alm_assetを継承するサブクラスとして実装されています。SAMは資産管理を置き換えず、既存の資産台帳の上にソフトウェアライセンス専用の照合エンジンを積み増す設計です。資産とCMDBを別テーブルに分けている理由は資産(alm_asset)とCMDB(cmdb_ci)を分ける理由で扱った通りで、SAMのライセンス台帳もこの資産側の枝に位置します。

Storeアプリ・Foundation・Professionalという3枚の板を積み重ねる構成

3層構造は、実際に増える量を見るとはっきり分かります。

Storeアプリ（sn_itam_samp）は7パブリッシャー分のライセンス知識をコンテンツとして持ち込むだけの層です。データモデルの基盤を作るのはFoundation（com.snc.sams）、照合エンジンそのものを動かすのはProfessional（com.snc.samp）です。Storeアプリだけを入れた段階の増分は、Professional有効化後の半分に届きません。層ごとの増分（テーブル・ACL・通知など25項目）は差分調査編にまとめました。

権利・実態・照合という3つのテーブル群でライセンスの過不足を計算する

SAMが扱うデータは、大きく3つに分かれます。購入した権利、実際のインストール実態、そして両者を突き合わせる照合です。

権利はalm_license（保有数）とalm_entitlement（消費明細）の2段で持つ

権利は1つのテーブルでは完結しません。alm_license（ラベルはSoftware Entitlement）が「何のライセンスを何本買ったか」という保有数を持ちます。alm_entitlement（ラベルはLicense Entitlement）が「どのデバイスやユーザーに割り当てたか」という消費明細を持つ、2段構えの作りです。テーブルどうしの参照関係は開発設計編で図にしています。

導入直後のPDIには、alm_licenseがすでに77件登録されています。数字だけ見ると、権利はもう揃っているように見えます。

どの行もActive rightsとPurchased rightsが同数でした。これは導入時のデモデータであって、SAMが計算した消費実績ではありません。列にはTotal cost（総費用）も持っており、権利1件ごとの調達コストを、契約テーブルとは独立して保持できる作りです。契約が資産をどう守っているかは契約はどの資産を守るか（ast_contract）で扱った構造が前提になります。権利側のテーブルは、SAMを入れる前から存在する既存の資産管理データに、ライセンス専用の列を足す形で機能します。

実態はDiscovery Modelを経由して正規化されたインストール実績

実態を表すのはcmdb_sam_sw_install（インストール記録）です。ただしインストール記録を直接書き込んでも、そのままでは照合の対象になりません。インストールが登録されると、まずcmdb_sam_sw_discovery_model（Discovery Model）という中間テーブルが自動生成されるためです。このDiscovery Modelを実在のソフトウェア製品（samp_sw_product）へ紐付け、norm_product・norm_publisherという正規化列を埋めます。ここまで終えて、インストール記録は初めて照合できる状態になります。実態側の情報がどこから来るかは、ServiceNowのDiscoveryは何を調べに行く機能なのか？で扱ったProbeの分類が前提です。

照合の結果は入れ子の結果テーブルへ積み上がる

権利と実態が揃うと、照合エンジンが両者を突き合わせます。結果は入れ子の結果テーブル群に積み上がります。頂点が照合の実行単位、最下層が「どの権利をどの端末が使ったか」という消費明細（Rights Used By）です。階層の全体像とテーブル設計は開発設計編で扱います。実行は手動でも可能です。加えてSAM - Software License Reconciliationというスケジュールジョブが、月曜02:00の週次で導入直後からスケジュール済みでした。

ライセンスを何単位で数えるかも、あらかじめ定義済みのコンテンツです。

デバイス単位・ユーザー単位・その他（コアやプロセッサなど）という3種類の数え方が、165件のメトリック定義としてあらかじめ用意されています。Oracleの名前を含むメトリックは1件もなく、Oracle固有の計量は別のテーブル群（samp_oracle_options等）に分かれています。

公式説明は「7パブリッシャーのライセンスコンプライアンス」と定義している

フィールドやアプリの公式説明は、sys_documentationやsys_store_appといった製品同梱のドキュメントテーブルから引用しています。この取得方法はフォームのラベルはどこから出るか（sys_documentation）で扱いました。

SAM（sn_itam_samp）のStoreページに書かれている公式のshort_description（原文）はこうです。

Enables license compliance for the following publishers: Microsoft, Adobe, Oracle, VMware, IBM, Red Hat, and Citrix

（訳: 次の発行元についてライセンスコンプライアンスを可能にします＝Microsoft・Adobe・Oracle・VMware・IBM・Red Hat・Citrix）

引用元: /sys_store_app_list.do?sysparm_query=scope=sn_itam_samp

対応する発行元は7社に限定されています。実機のコンテンツには1,794社の発行元データが入っていますが、SAMが継続的な更新（照合ルールの反映）を約束しているのはこの7社だけです。

アプリ詳細ページのSummary（原文）には、SAMとProfessionalの関係も明記されています。

The Software Asset Management application enhances the capabilities of the SAM Professional plugin by delivering regular updates that reconcile entitlements and installations in line with the latest licensing rules from major publishers.

（訳: Software Asset Managementアプリケーションは、主要な発行元の最新のライセンスルールに沿って権利とインストールを照合する定期更新を提供します。この定期更新によって、SAM Professionalプラグインの機能を強化します）

引用元: /sys_store_app_list.do?sysparm_query=scope=sn_itam_samp

Storeアプリは単体の製品としてではなく、Professionalという既存プラグインの強化パックとして説明されています。導入するアプリの名前が示す機能と、実際に照合を担うプラグインが別物であることを、公式の文章自身が認めています。

権利の1レコードにも公式の注記が付いている

alm_license.unrestricted_consumptionフィールドの公式説明（sys_documentation・原文）はこうです。

Allows any entity to consume rights regardless of consumption rules. License pools are still honored.

（訳: 消費ルールに関わらず、あらゆるエンティティが権利を消費することを許可します。ライセンスプールは引き続き尊重されます）

引用元: /sys_documentation_list.do?sysparm_query=name=alm_license^element=unrestricted_consumption

権利1件ごとに「消費ルールを無視して誰でも使ってよいか」を制御する列が、はじめから用意されています。割当方針は権利1件単位で切り替える設計です。

実機は導入直後から1,794社・1,596製品のコンテンツを持って始まる

SAMを導入すると、業務データは1件も入っていないのに、参照用のコンテンツだけは最初から大量に入っています。

発行元マスタ（samp_sw_publisher）が1,794件、製品マスタ（samp_sw_product）が1,596件、前述のライセンスメトリックが165件です。加えて、言語定義188件・UNSPSC分類115件・不要ライセンス理由（unlicensed_reason）56件も、導入と同時にコンテンツとして投入されていました。コンテンツ由来のレコードはsys_created_onが過去日付のまま入るため、作成日でSAM由来かどうかを見分けることはできません。

一方でトランザクション系のテーブルはすべて0件でした。動いているのはコンテンツだけです。cmdb_sam_sw_install（インストール記録）もsamp_reconciliation_result（照合結果）も、業務で使い始めるまでは空のままです。

既存のデモ資産77件はSAMが足したものではない

先に見たalm_licenseの77件やSoftware Models（cmdb_software_product_model）の92件は、SAM導入前からこの環境に入っていたPDIのデモデータでした。作成日はいずれも古く、導入後の新規作成は0件です。SAMのコンテンツライブラリが持ち込んだ発行元1,794件・製品1,596件と、資産管理側にもともとあったデモの77件・92件は出どころが異なり、混同すると数字の意味を取り違えます。

実務では、導入直後にProfessionalまで有効化してから使い始める

実際にインストール実績を投入し、権利を登録し、Run Reconciliationを実行しました。それでもStoreアプリ（sn_itam_samp）とFoundation（com.snc.sams）だけでは、照合結果は0件のままでした。照合の進捗ログ（samp_recon_progress_summary.log）には、対象インストール台数が0件という記録が残ります。原因として「SAMP plugin is not active」という一文も記録されていました。照合エンジン自体が、Professional（com.snc.samp）というプラグインの機能であるためです。

Storeアプリを入れただけで満足せず、Professionalまで有効化する。これがSAMを実務で使い始める最初の分岐点です。結局何が必要なのかを一覧にすると、次の4つに収まります。

プラグインの依存関係を導入前に確認する一般的な手順は、プラグイン（v_plugin/sys_plugins）の有効・無効と依存で扱いました。導入前後の増減を数える手順は、ServiceNowでプラグインを入れると何が変わる？影響調査でチェックする27か所にまとめています。SAM固有の導入手順は導入手順編で扱います。テーブルやロールの差分は差分調査編にまとめました。

SAM独自のロールはsam_admin・sam_developer・sam_userの3種類です。直接ACL件数や継承構造は運用設計編で扱う予定です。ロールの一般的な調べ方はServiceNowの権限は誰が持っている？ユーザー・グループ・ロールを中間表からたどるが参考になります。プロパティ16件の中身と基本設定の手順は基本設定編で扱います。システムプロパティを一般に調べる方法は、システムプロパティ（sys_properties）は設定値の置き場で扱った通りです。

実機で気づいたこと

一覧の見た目では、既存データとSAMのコンテンツを区別できない

症状：Software Entitlementsの一覧に77件の権利が最初から並び、SAMが用意したデータに見えます。

原因：メニューの「Licensing」の枝に、既存デモ資産の一覧とコンテンツ由来の辞書が同居しているためです。SAMが持ち込むのは発行元・製品という辞書です。契約情報である権利は1件も増えません。

回避策：データの出どころは並びではなく作成日で確かめます。この環境では77件すべてがSAM導入よりずっと前の日付で、既存のPDIデモ資産だと確定できました。

非準拠になっても、標準ではメールが1本も飛ばない

症状：照合で不足が出ても、誰にもメールが届きません。

原因：通知の増分はStore段階で0件、Professional有効化後も7件で、非準拠を知らせる通知は標準に含まれないためです。1,189件のACLと247件のビジネスルールを抱えるアプリが、計算した結果を自分からは知らせてきません。

回避策：気づく経路は運用設計として自分で決めます。結果一覧の定例確認を当番制にするか、通知を追加するかの設計は運用設計編で扱います。

実務では何に使えるか

導入したら、その日のうちにProfessionalまで有効化する

Storeアプリだけを入れた状態は、照合が動かない見せかけの導入です。最初の作業として、Professional（com.snc.samp）まで有効化し、週次ジョブが実際に動く状態にしてから運用を始めます。

監査前に慌てないよう、権利登録は契約更新のタイミングに合わせる

権利（alm_license）は手動で登録する必要があります。ソフトウェアの契約を更新したタイミングで権利を登録する運用をあらかじめ決めておかないと、照合エンジンがあっても実態と権利がずれたまま放置されます。

用語

SAM（Software Asset Management）：購入したソフトウェアライセンスの権利数と、実際のインストール実態を突き合わせ、過不足を管理する仕組み。Storeアプリはsn_itam_samp。

alm_license：権利（Software Entitlement）の台帳。alm_assetを継承する。

alm_entitlement：権利の消費明細（License Entitlement）。デバイスやユーザーへの割当を記録する独立テーブル。

Reconciliation（照合）：権利と実態を突き合わせる処理。結果は入れ子の結果テーブル群に記録される。

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

自分のインスタンス名に続けて開きます（SAMプラグインの導入が前提です）。

Software Entitlements（権利の一覧）：/alm_license_list.do
License Entitlements（消費明細）：/alm_entitlement_list.do
License Metrics（メトリック定義）：/samp_sw_license_metric_list.do
Software publishers（発行元マスタ）：/samp_sw_publisher_list.do
Run Reconciliation：/ui_page_process.do?name=samp_run_reconciliation_by_publisher

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

この記事で引用した説明文は、ServiceNowが製品に同梱しているアプリ・フィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述が表示されます。

アプリの公式説明（引用元）：/sys_store_app_list.do?sysparm_query=scope=sn_itam_samp
フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=alm_license^element=unrestricted_consumption

検証範囲とおことわり

Australia PDI（OOTB＋TPRM導入済み）にSAM（sn_itam_samp 4.1.4）を導入して確認しました。デモデータは付属しません（no_demo_data）。

シリーズ共通の検証データ：既存デモのalm_license 77件・cmdb_software_product_model 92件を確認用に流用し、検証用にAcrobat DC ProfessionalとAcrobat DC Standardの権利2件・インストール記録60件・照合結果4件を作成しています。数値は2026-08-23時点の実測です。

Professional（com.snc.samp）はGlidePluginManagerWorkerで有効化しました。sys_store_appへのREST参照が導入後に403へ変化する事象を確認していますが、原因は未確定です。Guided Setup（セットアップ誘導）の画面内容は未確認です。samp_sw_license_metric.scriptの中身やOracle計量（samp_oracle_options）の参照関係も、この記事の検証範囲には含めていません。

買ったライセンス数と実際のインストール数、ServiceNowでどう突き合わせる？ alm_license・cmdb_ci_spkgを実機で読む — SAMが自動化する前は、この突き合わせが手作業だったことを示す記事
資産(alm_asset)とCMDB(cmdb_ci)を分ける理由 — alm_licenseがなぜalm_assetの子クラスとして実装されているかの前提知識
アプリとスコープ：Globalとx_の違い（sys_app） — Store・Foundation・Professionalという3段のプラグイン構造を理解する前提知識