SAM（Software Asset Management）の運用設計（体制、役割、運用思想）
SAMを導入して照合を1回動かしたものの、非準拠が出たときに誰が気づき、どう対処すればよいか分からない。そう感じる担当者は多いはずです。ServiceNowのSAMは sam_developer から sam_admin・sam_user まで3ロールが一直線に継承する構造を持ちます。照合ジョブは導入した時点からすでに週次で自動的に動いています。ただし非準拠を知らせる通知はほとんど用意されていません。Australia PDIで権利登録から照合の実行、非準拠の確認までを完走させ、3ロールの権限構造と、気づく仕組みをどう自分で設計するかを実機で確認しました。型から先に示します。
検証環境：Australia PDI / OOTB / 2026-08-23 確認
SAM（Software Asset Management）シリーズ（全9本） — 導入から設計・運用・トラブルまで通しで書いています。
SAM（Software Asset Management）の運用設計（体制、役割、運用思想）（この記事）
1. はじめに
1.1 「作りの記事」と「回し方の記事」を分ける
開発設計の記事は、SAMがどう組み立てられているかを扱います。この記事が扱うのは別の問いです。3つのロールを誰に配り、週次で自動的に動く照合サイクルをどう見届け、非準拠が出たときにどう対処するかという、体制と運用の側になります。同じ型の運用設計書は、TPRMの運用設計書でも使っています。型は同じです。
1.2 この記事が扱う範囲
対象はSAM本体（Foundation・Professional共通）が持つ3ロールです。加えて、Software Model・Entitlement・Reconciliation Resultという主要テーブルが回る週次サイクルも扱います。導入手順や初期設定は別記事の範囲のため、この記事では扱いません。テーブルやスクリプトの作りも開発設計の記事に譲ります。
1.3 3ロールと週次照合を運用の前提に置く
運用設計に効く実測を先に並べます。SAMは3ロールを持ち、sam_developerからsam_admin、sam_userへと一直線に継承する構造です。直接ACLの件数はsam_developer4件・sam_admin41件・sam_user122件で、権限の重さとは比例しません。照合ジョブ（SAM - Software License Reconciliation）は毎週月曜02:00に自動実行される設定で、導入した時点からすでに動いています。非準拠を知らせる通知はほとんど無く、気づく仕組みは運用側が自分で用意する領域です。通知は当てにできません。
1.4 用語
sam_developer / sam_admin / sam_user：SAM本体（Foundation・Professional共通）が持つ3ロール
alm_license：ライセンス権利を表す資産（alm_assetを継承）。ラベルは「Software Entitlement」
alm_entitlement：割当明細。実際に消費として数えられるのはこちら側
samp_reconciliation_result：照合結果の起点テーブル。Publisher Result→Product Result→License Metric Result→Entitlement Resultへと連なる
unlicensed reason：install側に付く未ライセンス理由。samp_unlicensed_reasonに56件の定義が入っている
LUM（license_under_management）：Software Modelを照合対象にするかどうかのフラグ
2. developer・admin・userという3ロールをどう配るか
3ロールの作り（継承の実装）は開発設計の記事の範囲です。この章では同じ3ロールを「誰に配るか」という運用の視点で扱います。
2.1 sam_developerからsam_adminへ、sam_userへと一直線に継承する
sam_adminの公式説明はこうです。
This role grants a user full access to the respective features of the Software Asset Management application including the ability to create Custom Products and Pattern Normalization Rules. The same role is used for both SAM foundation and SAM professional so the features available for the sam_admin may be limited based on the application in use.
（訳: このロールは、Software Asset Managementアプリケーションの各機能へのフルアクセスを許可する。Custom ProductsやPattern Normalization Rulesを作成する権限も含む。同じロールがSAM FoundationとSAM Professionalの両方で使われるため、sam_adminが使える機能は導入しているアプリケーションによって制限されることがある）
sam_developerの公式説明はこうです。
Grants a user the script writing capabilities on the ServiceNow platform which are comparable to the script writing privileges granted to a sys_admin. This user must be a ServiceNow trained administrator.
（訳: sys_adminに付与されるスクリプト作成権限に匹敵する、ServiceNowプラットフォーム上のスクリプト作成能力をユーザーに付与する。このユーザーはServiceNowのトレーニングを受けた管理者でなければならない）
sam_userの公式説明はこうです。
This role grants a user access to the Software Asset Management application. This user would not be able to perform sam_admin functions. The same role is used for both SAM foundation and SAM professional so the features available for the sam_user may be limited based on the application in use.
（訳: このロールは、Software Asset Managementアプリケーションへのアクセスを許可する。このユーザーはsam_adminの機能を実行できない。同じロールがSAM FoundationとSAM Professionalの両方で使われるため、sam_userが使える機能は導入しているアプリケーションによって制限されることがある）
引用元：/sys_user_role_list.do?sysparm_query=nameINsam_admin,sam_developer,sam_user
sam_adminはこれに加え、他モジュールのロールも束ねています。model_manager・contract_manager・assetという既存の資産管理系ロールを含んでおり、SAMの管理者は既存のIT資産管理の管理権限もセットで持つ設計です。sam_userはcmdb_read・workspace_user・report_userを束ね、参照範囲はCMDBの読み取りやワークスペースの利用にも及びます。権限がどの層で決まるかを7層まで広げて整理する考え方は、ServiceNowで権限はどこで決まる？で扱いました。
2.2 直接ACL数と権限の重さは比例しない
直接ACLの件数だけを見ると、sam_userが122件でもっとも多く、sam_developerはわずか4件です。件数だけを見るとsam_userが一番強い権限に見えますが、実際は逆になります。sam_userはsam_admin機能を実行できない参照専用ロールで、sam_developerはsys_admin級のスクリプト作成権限を持つ、もっとも強い権限のロールです。承認できるロールほど直接ACLが少ないという同じ構図は、TPRMの運用設計書のapproverロール（直接ACL0件）でも確認しています。ロールを付けたのに画面が見えないという疑問が出たときの切り分け方は、ロールを付けたのに見えない理由：ACLにまとめました。
2.3 メニューは新旧2系統。どちらを正にするか決めておく
導入すると、ナビゲーションに「Software Asset」と「Software Asset Classic」という2つのメニューが並びます。有効なモジュールは合計25本で、内訳はSoftware Asset側17本、Classic側8本です。Software Models・Entitlements・Discovery Models・Run Reconciliationという中核4モジュールは、両方のメニューに重複して存在します。新旧のUIが並存する状態です。手順書のスクリーンショットをどちらのメニューで撮るかがチーム内で揃っていないと、同じ操作でも画面が違って見え、問い合わせの原因になります。運用を始める前に、新メニュー（Software Asset）を正の手順とし、Classicは参照用に留めるといった方針を決めておく必要があります。
3. 週次照合サイクルはもう動いている。見るのは人の役目
3.1 照合は月曜02:00に導入直後から自動で走る
SAMの照合ジョブ「SAM - Software License Reconciliation」は、Weekly・月曜02:00で最初から有効になっています。稼働させるための追加設定は要りません。運用設計で決めるべきは「照合を動かすかどうか」ではなく、「動いた結果を誰がいつ見るか」です。
3.2 日次の整備ジョブが照合対象のデータを整える
週次の照合を支える形で、日次相当のジョブが5本動きます。
Subscription Maintenance（01:15）
Set client pull schedules（23:00）
Set assigned_to Field on Licensable Install Records（16:00）
Deduplicate Install Table（16:00）
Proactively fix core company reference（0時台）
インストール実態や参照データの重複・欠損を、月曜の照合より前に整えておく役割です。日曜には別のWeeklyジョブ（Calculate Asset Refresh Eligibility）も動きます。スケジュールジョブが有効かどうかと、実際に走っているかどうかは別問題です。run_countと次回実行時刻から実行実態を見分ける方法があります。ServiceNowのスケジュールジョブは本当に動いている？にまとめています。
3.3 月次・オンデマンドは例外対応の経路になる
月次では、関連するインストールが無くなったDiscovery Modelを削除するジョブが1本動きます。オンデマンドは2本用意されていますが、SAM - Apply latest content changesは無効です。日常の運用は週次と日次の組み合わせで完結し、オンデマンドと月次は例外時に手を動かす経路と位置づけます。
4. 非準拠が出たときにどう気づき、どう対処するか
判定が出た後に誰が気づき、どの画面で根拠を確かめ、どう是正へつなぐかまで決めて、はじめて運用として成立します。この章のために検証環境で照合を実走させ、非準拠が出た後の見え方を実機で確かめました。
4.1 通知は気づく合図にならない
SAM Foundation（Storeアプリ）の段階では、通知（メール通知）は1本も追加されません。SAM Professionalを有効化すると通知は7件まで増えますが、SAM Professional本体のスコープ（sn_samp）に絞って中身を確認すると、有効な通知は2件だけでした。1件は自動回収を知らせるNotify user auto reclamation、もう1件は承認依頼のRECC User Approvalです。どちらも、照合が完了したことや、ある製品が非準拠になったことを知らせる通知ではありません。権利を超える割当はBusiness Ruleが自動で止める設計ですが（4.5で扱います）、前提は無通知です。非準拠そのものをメールで教えてくれる仕組みは、標準では用意されていないと考えたほうが安全です。承認できるロールほど直接ACLが少ないという構図と同じく、止める・防ぐ設計の考え方は承認（Approval）運用設計書とも共通します。合図は自分で作ります。気づく仕組みは、運用側が組み立てる領域です。
4.2 気づく場所を3つに固定する
気づく経路が人によってバラバラだと、見落としの原因調査ができません。次の3つに固定する設計とします。
定期の一覧確認：Publisher Results・License Metric Resultsを、週次照合の翌日に確認する
明細の確認：Rights Used By（Entitlement Result）で、どの端末が未割当のまま残っているかを確認する
履歴の確認：Historical Resultsで過去の実行結果を並べ、悪化・改善の傾向を確認する
4.3 実測で見た非準拠：不足10・過剰30が同時に出た
Acrobat DC Professional（権利30・インストール40）とAcrobat DC Standard（権利50・インストール20）で照合を実走させました。License Metric Resultsには、Rights owned 30・Rights used 30・Rights available 0という行があります。もう一方には、Rights owned 50・Rights used 20・Rights available 30という行が並びます。前者は権利をすべて使い切って不足が残っている状態、後者は権利の6割が余っている状態です。Publisher Results側では、この2製品を含むAdobe Systemsの結果が4件並び、3件がNot compliant、1件がCompliantでした。同じPublisherの中でも、製品によって不足と過剰が同時に起きます。
Adobe Systems Acrobat 9.0のSoftware Entitlementフォームを見ると、値が並んでいます。Purchased rights 30・Active rights 30・Allocations available 0です。Allocations availableが0の行こそ、権利を追加すべき製品だと判断できる箇所です。
4.4 対処は「原因確認→権利追加or割当見直し→再照合」を型にする
非準拠が出たときの対処を、次の4段階の型として設計します。
原因の確認：License Metric Resultsのavailableとunused、install側のunlicensed reasonを確認する。今回の検証では「No applicable software entitlement」という理由が、割当（alm_entitlement）の無い端末に付いていました
権利追加：availableが0で不足している製品は、alm_licenseのpurchased_rightsを増やすか、新しい権利を追加する
割当見直し：unusedが継続している製品は、使われていない割当を他の端末へ動かすか、次回契約更新での削減候補として記録する
再照合：Run Reconciliationを再実行し、consumedとavailableが更新されたかを確認する
権利側の実体はalm_licenseです。消費の実体はalm_entitlementという別テーブルです。権利を登録しただけでは消費として数えられず、割当を作って初めて消費に反映されます。
4.5 割当超過はBRが防ぐが、権利不足の放置は防がれない
検証中、Acrobat DC Professionalの権利30に対して31台目の割当を作ろうとしました。Business Rule「Ensure Entitlements do not exceed rights」が処理を拒否しています。権利を超える割当は、システム側が自動で止める設計です。一方で、権利が足りないままインストールだけが増えていく状態を止める仕組みはありません。unlicensed reasonが付いたまま放置しても、システムはエラーを出しません。割り当てすぎは防がれても、足りないまま気づかれない状態は防がれない、非対称な設計です。ここが運用の勘所です。4.2で決めた3つの場所を定期的に見に行く運用が、この非対称を埋める役目を持ちます。
実機で気づいたこと
ACLが最多のsam_userが、いちばん軽い権限だった
直接ACLの件数だけでロールの重みを判断すると、SAMでは判断を誤ります。もっとも多い122件を持つsam_userは参照専用で、もっとも少ない4件のsam_developerがsys_admin級のスクリプト権限を持つ、逆転した構図でした。権限の重さはACLの件数ではなく、公式の役割説明で確認する必要があります。件数は目安になりません。
Software AssetとClassicのメニューに同じモジュールが重複する
中核4モジュール（Software Models・Entitlements・Discovery Models・Run Reconciliation）は、新旧2つのメニューに重複して存在します。新メニューのSoftware Assetと旧メニューのSoftware Asset Classicの両方から同じ画面を開けます。原因は新旧のUIが並存する実装で、旧メニューを残したまま新メニューが追加されているためです。同じRun Reconciliationでも、どちらの経路から開いたかでチーム内の手順書が割れる余地があります。運用を始める前に、正とするメニュー（Software Asset）を1つ決め、Classicは参照用に留めるとチームで合意しておくと、この余地を防げます。
ここまでで、3ロールの権限構造と週次照合サイクル、非準拠への気づき方と対処の型を確認しました。ここから先は、3ロール×13プロセスのRACI表と、気づく方法・エスカレーション基準など6項目を決める運用設計書テンプレート、監視・レビュー周期の叩き台をまとめています。自社の運用ルールを決めるときの叩き台としてそのまま使える分量です。
💰 ここから先は有料エリア
