SAMのトラブル事例と解決

「Run Reconciliationを実行してCompletedと出たのに、結果が0件のまま動かない」。SAM（Software Asset Management）のReconciliation（照合）を触った担当者が最初につまずく場面です。画面にはエラーが出ず、ログを開かない限り原因が分かりません。Australia PDIで権利の登録から割当の作成まで実際に1周させたところ、同じように途中で何度も止まりました。原因はすべて実機で特定済みで、再現できます。この記事は、遭遇した10件それぞれについて症状・原因・対処をまとめたものです。

SAMシリーズ（全9本） — 導入から設計・運用・トラブルまで通しで書いています。

• ①導入手順：SAM（Software Asset Management）プラグインのインストール手順

• ②影響調査：導入後にテーブルやロールがどう変わるか

• ③基礎知識：SAM（Software Asset Management）とは

• ④基本設定：導入後に行う設定とシステムプロパティ

• ⑤運用手順：ライセンス登録から照合1件を処理する手順

• ⑥開発設計書：実機から見る設計思想

• ⑦運用設計書：体制・役割・運用思想

• ⑧連携：既存資産管理・CMDBとの棲み分け

• ⑨トラブル：つまずいた点と解決（この記事）

10件を並べると、止まる場所は3か所に集中する

10件を並べると、止まる場所は3種類に分かれました。

1つ目は、照合を実行した「あと」に気づくズレです。画面上はCompletedと表示されているのに、結果は0件のまま。ログを開くと理由が書いてありますが、ログを見に行かない限り気づけません。値が正しく保持されているはずのフィールドが、読み取るとnullになっている場面もあります。

2つ目は、次の画面へ進むための前提条件が、どの画面にも書かれていないケースです。インストール実態にモデルを直接セットしても保存すると消えます。モデルにコンテンツ製品を紐付けないと対象台数は増えません。設定すべき項目が2つとも空のままだと、いつまでも対象0件から動きません。

3つ目は、割当まで進めて初めて分かる初期値と上限です。ライセンス（資産としての権利）を登録しただけでは消費は動かず、別に割当を作る必要があります。作った権利の名前は自分の意図と違う形に変わり、割当は購入数の上限で必ず止まります。

先に、持ち帰りの3点だけ言い切ります。①権利（alm_license）と割当（alm_entitlement）は別物で、両方作らないと消費は計上されない。②エラー画面より先に照合ログの一文を読む癖をつける。③SAM Professionalを有効化しないと照合は空振りする。

エラー文言から逆引きしたい方は、この索引からどうぞ。

• Number of licensable installs and subscriptions: 0 → 照合は動いたように見えても中身が空になるの節

• SAMP plugin is not active → 照合は動いたように見えても中身が空になるの節

• license_under_managementがnull → 照合は動いたように見えても中身が空になるの節

• sys_store_appへの参照がHTTP 403 → 照合は動いたように見えても中身が空になるの節（※推測）

• No applicable software entitlement → 割当まで進めて初めて分かる初期値と上限の節

• Cannot allocate more licenses than available rights. → 割当まで進めて初めて分かる初期値と上限の節

• Ensure Entitlements do not exceed rights（Business Rule名） → 割当まで進めて初めて分かる初期値と上限の節

この3つを軸に、実機で確認できた10件を1つずつ見ていきます。

続けて、10件がどの順番で連鎖するのかを1枚の図にまとめました。ハンズオンでは60台のインストール実態を投入し、権利登録から割当作成までを実際に1周させています。

照合は動いたように見えても中身が空になる（4件）

照合そのものは正常に終了したように表示されるのに、中を開けると何も入っていないグループです。原因はログの記載内容か、隠れたプラグイン状態にあります。

照合はCompletedなのに結果が0件

症状：Run Reconciliationを実行すると、確認ダイアログのあとにジョブが始まり、しばらくするとsamp_reconciliation_result一覧に新しい番号が並びます。StatusはすべてCompleted・Progressは100%です。ところが、紐づくsamp_publisher_result以下の集計テーブルを開くと中身が空でした。

原因：単純です。照合対象がゼロだったからです。照合の実行ログ（samp_recon_progress_summary.log、JSON形式）を開くと、Number of licensable installs and subscriptions: 0という行があります。60台投入したインストール実態のうち、licensableと判定されたものが1台もない状態で照合が終わっていました。同じログのNumber of in use entitlements: 79は、デモの既存データ分をそのまま数えている値で、今回投入した分の消費ではありません。

なお、この照合は手動実行だけでなく、SAM - Software License Reconciliationという名前で毎週月曜02:00に自動実行するジョブとしても登録されています。ジョブが実際に走っているかどうかをrun_countと次回実行時刻から見分ける方法は、ServiceNowのスケジュールジョブは本当に動いている？にまとめています。

対処［ログ確認・要設定］：手順は単純です。ステータス欄のCompletedを信用せず、ログのlicensable件数を先に見ます。0件であれば、このあとの節で扱う設定（product紐付け・norm列）が抜けている可能性が高いです。

実行そのものはこの確認ダイアログから始まります。「Run」を押すとバックグラウンドで処理が進み、この一覧に新しい番号が積まれていく流れです。

ログに「SAMP plugin is not active」と出て止まる

症状：判定は空振りです。前項のログをさらに読み進めると、Number of software models with LUM false: N/A - SAMP plugin is not activeという行があります。LUM（license_under_management、ライセンス管理対象かどうか）の判定自体が行われていません。

原因：導入したのはSAM本体（Storeアプリsn_itam_samp）とFoundation（com.snc.sams）までです。照合エンジンを持つSAM Professional（com.snc.samp）は、この時点でまだfalseのままでした。導入ダイアログのReview Installation Detailsに表示された依存は1件だけで、この依存関係は画面には出てきません。ダイアログの表示件数を実際の依存の全部だと考えない方がよいという点は、プラグイン（v_plugin/sys_plugins）の有効・無効と依存でも扱っている注意点です。導入前後の差分を数え直す具体的な手順は、ServiceNowでプラグインを入れると何が変わる？ 影響調査でチェックする27か所にまとめています。

対処［プラグイン有効化が必要］：SAM Professionalの有効化が必要です。有効化はApp Manager画面からは行えず、プラグインの有効化操作として実行します。完了メッセージはPlugin activated/upgraded successfulyという表記（successfullyではなくsuccessfulyという製品側のタイプミス）で返ってきます。

有効化が完了すると、この表示が反転します。

license_under_managementの読み取りが常にnullになる

症状：Software Model（cmdb_software_product_model）のlicense_under_management（LUM）にあらかじめtrueを設定しておいたのに、あとで読み返すと値がnullになっています。設定した記憶はあるのに、確認するたびに空扱いです。

原因：SAM Professionalが無効な間は、license_under_managementの読み取りがnullになります。値そのものは保持されたままで、読み取りだけがブロックされている状態です。前項でSAM Professionalを有効化すると、同じフィールドから元の値が読めるようになります。

対処［Pro有効化で解消］：nullを見て設定が消えたと早合点しないことです。まずSAM Professionalの状態を確認し、有効化してから改めて値を確認します。

導入後、sys_store_appへの参照だけHTTP 403に変わる

症状：SAMを導入する前は、sys_store_appテーブルへのREST参照が200（空リスト）で返っていました。導入後に同じ参照を送ると、HTTP 403に変わります。

アクセス拒否そのものの切り分け方はロールを付けたのに見えない理由：ACL（sys_security_acl）にまとめています。権限がどの層で決まるかの全体像は、ServiceNowで権限はどこで決まる？の7層で整理できます。

対処［原因未確定・回避策のみ］：この参照が必要な場合は、REST APIではなく画面（App Manager経由）から確認します。原因の切り分けは検証範囲外としました。

前提条件が画面のどこにも書かれていない（3件）

操作は通っても、次の設定をしないと数字が増えないグループです。エラーにすらならず、静かに0のまま止まります。

installに直接セットしたsoftware_modelは保存すると消える

症状：cmdb_sam_sw_install（インストール実態）のsoftware_modelフィールドに、対応するモデルを直接指定して保存しました。保存自体はエラーなく完了しますが、レコードを開き直すとsoftware_modelが空欄に戻っています。

原因：正規化はDiscovery Model経由で行う仕様のため、Business Ruleが直接セットした値をクリアします。インストール実態を保存すると、表示名・発行元・バージョンからDiscovery Modelが自動生成され、モデルとの紐付けはこのDiscovery Model側で行う経路が正しい流れです。

対処［仕様・回避手順あり］：software_modelを直接編集しません。自動生成されたDiscovery Model（cmdb_sam_sw_discovery_model）を開き、そちらでmodelを設定してstatusをManually Normalizedにします。

productを紐付けないと対象台数が増えない

症状：まだ足りません。Discovery Modelをモデルに紐付け、statusもManually Normalizedにしました。それでもlicensableな台数は増えず、対象は0のままです。

原因：モデル側にコンテンツ製品（samp_sw_product）への紐付けが必要です。この紐付けが無いと、モデルは名前が付いているだけの状態で、SAMのコンテンツライブラリと接続されません。紐付けた瞬間に、publisher result・product resultといった集計レコードが生成されました。

対処［要設定］：モデルのフォームからproductを検索し、該当するコンテンツ製品を選びます。検索は表示名の一部（発行元名など）で絞り込むと候補が出てきます。

norm_product/norm_publisherが空だと対象0のまま

症状：モデルにproductを紐付けたのに、まだlicensableな台数が0のままです。

原因：モデル側の設定だけでは不十分で、インストール実態（cmdb_sam_sw_install）自身が持つnorm_product・norm_publisherという正規化フィールドが空のままでした。この2つが埋まって初めて、そのインストールが照合対象として扱われます。

対処［要設定］：インストール実態側のnorm_product・norm_publisherを設定します。設定すると、対象60件すべてがlicensable=trueに変わりました。

割当まで進めて初めて分かる初期値と上限（3件）

licensableになったあとも、消費が計上されるまでにもう1段階あります。ここで初めて、権利と割当が別物だと分かります。

licensableでも消費0で「No applicable software entitlement」

症状：60台がすべてlicensable=trueになりました。それでも消費（consumed）は0のままです。全台のunlicensed reasonには「No applicable software entitlement」（訳: 適用できるソフトウェア権利がありません）という同じ理由が並びます。

原因：構造は2段です。消費を計上する実体はalm_entitlement（割当明細）で、alm_license（資産としての権利）を登録しただけでは消費は動きません。実際に確認すると、既存デモの権利1件に対する割当明細は0行でした。買った数と入っている数を結ぶ参照の作りそのものは、買ったライセンス数と実際のインストール数、ServiceNowでどう突き合わせる？でも扱っています。

対処［要作成］：作業は単純です。alm_licenseとは別に、対象デバイスへの割当（Device Allocation）を作成します。割当を作ることで、初めてalm_entitlement側の行が生まれ、消費として数えられるようになります。

似た文脈で、alm_licenseのunrestricted_consumption（無制限消費）というチェック項目の公式説明（sys_documentationのhint・原文）も確認しておく価値があります。

（訳: 消費ルールに関わらず、どのエンティティも権利を消費できるようにします。ライセンスプールは引き続き尊重されます）

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

このチェックは、消費ルール（samp_sw_ent_consumption_rule）が設定されている権利向けの例外設定で、消費そのものを発生させる機能ではありません。今回のように消費ルールを何も設定していない権利では、チェックを入れようとしても「消費ルールが無ければ既に無制限消費」という趣旨のエラーで止まります。消費の入口にあたる操作は、あくまで割当（alm_entitlement）の作成です。

自分で付けたモデル名が別の名前に変わる

症状：ソフトウェア権利のフォームで、モデル名として「Acrobat DC Professional」に相当する名前を意図して登録したはずでした。保存後に開き直すと、Display nameもSoftware modelも「Adobe Systems Acrobat 9.0」に変わっています。

原因：ソフトウェアモデルの名前は、Business Rule「Calculate software model name」が自動で再計算します。productにコンテンツ製品を紐付けた時点で、名前は作り直されます。組み合わせ元はコンテンツ側のpublisher・product・versionです。今回のケースでは、紐付けた製品バージョンが9.0だったため、その表記に揃えられました。

対処［仕様として理解する］：発想の転換が要ります。モデル名を自由文字列だと考えないことです。表示名を固定したい場合は、紐付けるコンテンツ製品側のバージョン表記を先に確認してから登録します。

31台目の割当だけ「Cannot allocate more licenses than available rights」で拒否される

症状：作成した権利（purchased_rights=30）に対して、Device Allocationを1台ずつ作成します。30台目までは問題なく作成できるのに、31台目だけ次のエラーで拒否されます。

Cannot allocate more licenses than available rights.（訳: 利用可能な権利数を超えて割り当てることはできません）

原因：Business Rule「Ensure Entitlements do not exceed rights」が、購入数量を超える割当をalm_entitlement_assetへの保存時点で止めています。上のフォームで見えていたAllocations available（割当可能数）が0になった時点が、この上限に達したタイミングと一致します。同じ検証でPurchased rights=50の権利には20台しか割り当てていないため、そちらはまだ余裕があり拒否されません。複数のBusiness Ruleが連鎖して保存を止める挙動そのものは、Business Ruleはどの順番で動くかでも実測しています。

対処［仕様どおりの動作・要追加権利］：エラーが出たら台数の入力ミスをまず疑うのではなく、権利数そのものが不足していると考えます。台数を増やしたい場合は、Device Allocationではなくalm_license側のPurchased rightsを見直します。

実機で気づいたこと

症状を1つずつ追うだけでは見えてこない、テーブル構造の共通点を3つ残します。

「権利がある」と「使える」は別のテーブルに分かれています。 alm_licenseに権利を登録した時点では、まだ何も消費されません。消費を発生させるのはalm_entitlement（割当明細）です。デモデータではalm_entitlementが8,536行あるのに対し、自分で作った権利は0行のままでした。権利を登録したら、消費が動く前に割当（Device Allocation）の作成もセットで確認する運用にします。

エラーより先に、ログの一文が答えを持っています。 照合が空振りする原因は、画面のどこにもエラーとして表示されません。samp_recon_progress_summary.logのlicensable installsが0という一文を読まない限り、Completed表示だけを見て正常終了と誤認します。Run Reconciliationのあとは、Completed表示の前にこのログを先に開く手順にします。

モデル名の自動再計算は、命名の自由度を制限する仕様です。 Business Rule「Calculate software model name」が、publisher・product・versionという構造化されたキーから名前を自動生成する設計です。表記ゆれを防げる一方、自分がつけた表示名はそのまま残りません。表示名を固定したい場合は、紐付けるコンテンツ製品側のバージョン表記を先に確認してから登録します。

実務では何に使えるか

冒頭の一覧表を、そのまま照合トラブルの一次切り分けチェックリストとして使う想定で読み直します。

照合を回す前のチェックリストに使う

照合結果が空になる原因の大半は、実行前の設定漏れです。確認すべき点は3つあります。SAM Professionalは有効か、モデルにproductは紐付いているか、インストール実態のnorm列は埋まっているか。この3点をRun Reconciliationを押す前に確認する運用にしておくと、空振りの照合を何度も繰り返さずに済みます。

ログの読み方を先に確立しておく

samp_recon_progress_summary.logは、照合の実行結果一覧からたどり着けるJSON形式のログです。licensable installs・in use entitlements・software models with LUM falseの3項目を先に見る癖をつけておくと、Completed表示だけでは分からない中身の空振りに気づけます。ログの読み方を先に確立しておく考え方は、システムログ（syslog）の読み方と溜まり方とも共通しています。

権利と割当は別物と教育する

導入直後の担当者が最初につまずくのは、ほぼ確実にこの構造です。ライセンスを買った（alm_license）ことと、誰にどれだけ配ったか（alm_entitlement）を分けて説明しておくと、登録したのに消費0のままという問い合わせを事前に減らせます。同じ形式で別アプリのつまずきをまとめた記事にServiceNowのPPMでつまずく点と直し方もあります。

用語

samp_recon_progress_summary.log：照合1回ぶんの実行結果を持つJSON形式のログ。licensableな台数・在庫中の権利数・SAM Professionalの状態が記録される。

license_under_management（LUM）：ソフトウェアモデルをライセンス管理の対象にするかどうかのフラグ。SAM Professionalが無効な間は読み取りがnullになる。

alm_license / alm_entitlement：alm_licenseは資産として登録する権利（購入数量）。alm_entitlementはその権利を実際に誰・どのデバイスへ配ったかを示す割当明細で、消費はこちら側で計上される。

Discovery Model（cmdb_sam_sw_discovery_model）：インストール実態から自動生成される、正規化前の中間レコード。ソフトウェアモデルへの紐付けはここで行う。

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

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

• Reconciliation Results一覧：/samp_reconciliation_result_list.do

• インストール実態一覧：/cmdb_sam_sw_install_list.do

• Discovery Model一覧：/cmdb_sam_sw_discovery_model_list.do

• Software Model（コンテンツ製品の紐付け確認）：/cmdb_software_product_model_list.do

• Software Entitlement（権利）一覧：/alm_license_list.do

• 割当明細（alm_entitlement）の件数：/alm_entitlement_list.do

• SAM Professionalの有効状態：/sys_properties_list.do?sysparm_query=nameLIKEcom.snc.samp

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

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

• unrestricted_consumptionの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=alm_license^element=unrestricted_consumption

検証範囲とおことわり

検証環境はAustralia PDI（OOTB＋TPRM導入済み）です。2026-08-23に確認しました。SAMはsn_itam_samp（Storeアプリ）・com.snc.sams（Foundation）・com.snc.samp（Professional）の3層構成で、この記事の内容はProfessionalまで有効化した状態を対象にしています。検証で作成した主なデータは2種類です。alm_license 2件（Acrobat DC Professional 権利30・Acrobat DC Standard 権利50）と、cmdb_sam_sw_install 60件（PC 60台ぶんの実態）です。ほかにDevice Allocation（Professional 30件・Standard 20件）、Reconciliation Results 10件前後も作成しました。デモの既存権利77件・ソフトウェアモデル92件はSAM導入前から存在するPDIのデモデータで、この検証で追加したものではありません。確認していない範囲は次のとおりです。

• ここに挙げた10件は、このシリーズの制作過程で実際に操作して見つけたものであり、想定される全てのつまずきを網羅したものではありません

• sys_store_appへの参照がHTTP 403になる原因は、ACLの新設が理由ではないところまでは確認しましたが、それ以上は特定できていません（推測の範囲であることは該当節に明記）

• 本番環境やバージョンによって、エラーメッセージの文言や挙動が変わる可能性があります

関連記事

• プラグイン（v_plugin/sys_plugins）の有効・無効と依存 — SAM Professionalのようにダイアログに出ない依存プラグインを読み解く前提知識

• 買ったライセンス数と実際のインストール数、ServiceNowでどう突き合わせる？ — alm_licenseとインストール実態の突き合わせを扱う関連記事

• TPRMのトラブル事例と解決 — 同じ「症状→原因→対処」形式で別アプリのつまずきをまとめた記事