SAM（Software Asset Management）の開発設計（実機から見る設計思想）

ServiceNowのSoftware Asset Management（SAM）を自社へ導入・拡張するとき、最初に必要になるのは開発設計書です。ところが公式ドキュメントは機能の説明が中心で、「設計書の章立てに沿って何をどう決めるか」という形にはなっていません。本書は、Australia PDIへ実際に導入したSAMの実装を根拠に、標準実装を設計書として書き起こしたものです。章立ては一般的な開発設計書の目次構成（システム概要・機能設計・画面設計・テーブル設計・ステータス設計・自動化設計・外部インターフェース設計・セキュリティ設計・パラメータ設計）に合わせました。章立てごと流用して、自社版の設計書の雛形にしてください。

1. はじめに

1.1 本書の目的と位置づけ

本書は、SAMの標準実装を「設計済みの成果物」として読み、そのまま自社の開発設計書の雛形に流用できる形へ整理することを目的とします。各章は、一般的な開発設計書の章立てに合わせています。各節の書き方は「設計方針を先に述べ、その根拠となる実測を添える」で統一しました。自社版を作るときは、方針文を自社の決定に置き換え、根拠を自社環境の確認結果に差し替えれば、そのまま設計書として成立します。

なお本書は技術寄りの設計書です。誰がどう回すかという体制側はで扱います。基礎知識から順に読みたい場合はを先に、実際の操作手順はを参照してください。同じ型で書いた前例としてTPRM（Vendor Risk Management）の開発設計書があります。

1.2 対象範囲

対象は、SAMを構成する3層（Storeアプリsn_itam_samp／Foundationcom.snc.sams／Professionalcom.snc.samp）と、初期データとして同梱されるコンテンツライブラリ（samp_sw_publisher／samp_sw_product／samp_sw_license_metricほか）です。次は対象範囲に含めません。

• Software Asset Workspace（sn_sam_workspace）を別途導入した場合の画面設計（今回のシリーズでは未導入）

• Oracle固有のライセンス体系（samp_oracle_options／samp_oracle_option_set）のスクリプト内部

• 7パブリッシャー（Microsoft, Adobe, Oracle, VMware, IBM, Red Hat, Citrix）それぞれの個別ライセンス規則の実装差

1.3 前提条件と制約

本書の根拠はAustralia PDI（OOTB＋TPRM導入済み）へ2026-08-23に導入した実測です。SAMはServiceNow Store配布のアプリケーションであり、Update Setでは移送できないため、環境ごとに導入して版を揃える前提で設計します。デモデータは付属しない（no_demo_data）ため、記載する初期件数はすべて「導入しただけの状態」の値です。導入前後の差分の数え方は、ServiceNowでプラグインを入れると何が変わる？ 影響調査でチェックする27か所の方法に従います。

1.4 用語定義

• entitlement（権利） … ソフトウェアの使用許諾数量を持つ台帳。資産としての権利定義（alm_license）と、誰にいくつ割り当てたかの明細（alm_entitlement）の2層で表現する

• reconciliation（照合） … 権利（entitlement）と実態（install）を突き合わせ、過不足を計算する処理

• Discovery Model（DM） … 実態のソフトウェア名を正規のSoftware Modelへ結び付けるための中間データ。cmdb_sam_sw_installの投入時に自動生成される

• normalization（正規化） … 表記ゆれのある実態データを標準のSoftware Model・パブリッシャー・製品へ寄せる処理

• license metric（ライセンスメトリック） … 消費数の数え方の定義。Device／User／Otherなどの種別を持つ

• unlicensed reason（非ライセンス理由） … 権利が不足している実態に付与される理由コード。本文では「非ライセンス理由」で統一する

• publisher result／product result（照合結果の集計単位） … 照合の実行結果を、パブリッシャー別・製品別に集計した単位

2. システム概要

2.1 全体構成

SAMは「Storeアプリ」「Foundation」「Professional」の3層で構成し、加えてコンテンツライブラリを外部サービス（CDS）から取り込む設計とします。この3層構造の理解が、本書全体の前提になります。

図の色は層の状態を表します。濃紺はStoreアプリ本体、緑は同時に自動導入されるFoundationです。赤は既定で無効になっているProfessionalを表します。水色はコンテンツマスタへの参照、紫は外部サービス（CDS）、橙は本来の主機能（照合）です。

詳しい増分の内訳（テーブル・フィールド・ACL・通知など）は差分調査編にまとめています。 設計上押さえるべきは、Storeアプリ単体が持ち込むのは全体の一部にすぎないという点です。「SAM」は1つのアプリケーションに見えますが、実体はStoreアプリ・Foundation・Professionalの3層です。Storeアプリの導入だけでは、総量の半分にも届きません。本書はこの事実を設計の前提として押さえます。

とりわけ際立つのが通知とFlowです。Storeアプリだけを導入した状態では、通知は0件・Flowは0本のままです。通知が1件も無いままメール連携を待っていても何も届きません。通知が届くようになるのはProfessionalを有効化してからで、それでも+7件です。この少なさは9章・7章で改めて扱います。

2.2 方式設計

SAMのアプリケーション方式は、次の3点を採用します。

• Storeアプリとしての配布：sn_itam_sampはServiceNow Store配布のアプリケーションであり、依存関係は「Software Asset Management Foundation」1件のみが導入確認画面（Review Installation Details）に表示されます。依存の連鎖が浅いのが特徴で、単体導入が容易な設計です

• Professionalの明示的な分離：照合（Reconciliation）そのものはcom.snc.samp（SAM Professional）という別プラグインの機能として実装され、Storeアプリの導入では自動的に有効化されません。機能の本体を意図的に切り離す設計です

• コンテンツライブラリの外部更新：パブリッシャー・製品・ライセンスメトリックの定義は、CDS（Content Distribution Service）を通じて外部から取得する構成です。自動反映のジョブ「SAM - Apply latest content changes」は既定でinactiveのため、最新のライセンス規則を反映するかどうかは運用側の判断に委ねられています

アプリの目的は、公式のshort_description（原文）が一文で表しています。

（訳: 次のパブリッシャーについてライセンスコンプライアンスを実現します。Microsoft・Adobe・Oracle・VMware・IBM・Red Hat・Citrix）

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

対応するパブリッシャーを7社に限定して明記している点が特徴です。導入前のApp Manager詳細ページには、この一文に続けてSummaryも表示されます。要旨は「Professional pluginの能力を拡張し、主要パブリッシャーの最新ライセンス規則に沿って権利とインストールを定期的に照合する」という内容です。この説明はApp Manager内の商品説明ページで確認できます。short_descriptionの主語は「Storeアプリ」ですが、Summaryの主語は「SAM Professional plugin」です。公式の説明文の中に、Storeアプリだけでは完結しないという構造がすでに書き込まれていると読み取れます。

3. 機能設計

3.1 機能一覧

SAMが提供する機能は、次の6系統で構成されます。

• コンテンツライブラリ管理：パブリッシャー1,794件・製品1,596件・ライセンスメトリック165件からなる、SAM独自のマスタデータ

• ライセンスモデル管理：ソフトウェア製品モデル（cmdb_software_product_model）に、管理対象かどうかのフラグ（License Under Management）を立てて対象を選ぶ

• 権利管理：購入した権利数（alm_license）と、誰にいくつ割り当てたかの明細（alm_entitlement）を管理する

• 実態の正規化：インストール実態（cmdb_sam_sw_install）をDiscovery Model経由でSoftware Modelへ正規化する

• 照合エンジン：正規化済みの実態と権利を突き合わせ、過不足を計算する（Reconciliation）

• コンプライアンスレポート：照合結果をパブリッシャー別・製品別に集計し、超過（Out of Compliance）を検出する

メニューは新旧2系統が並存する構成です。モジュールは25本（active）あり、内訳は「Software Asset」17本・「Software Asset Classic」8本です。中核機能（Software Models／Entitlements／Discovery Models／Run Reconciliation）は両メニューに重複して存在します。詳細は4章で扱います。

購入すると何が手に入るか

有料エリアには、3.2以降の機能設計と、4章から12章までの設計内容が入っています。そのまま仕事に使える成果物は次の3つです。

• 開発設計書の章立てそのもの（3.2 権利とライセンスモデル → 3.3 正規化 → 3.4 照合エンジン → 4 画面 → 5 テーブル → 6 状態 → 7 自動化 → 8 外部インターフェース → 9 セキュリティ → 10 パラメータ → 11 制約と変更禁止 → 12 設計判断チェックリスト）。見出しを自社名に差し替えれば設計書の骨格になります

• 設計判断表（10論点） … コンテンツマスタの持ち方から外部コンテンツ更新の扱いまで、SAMの実装と踏襲/変更の指針を1枚にまとめた表

• テーブル設計を確かめるときのチェックリスト（9項目） … SAM以外のServiceNowアプリケーションでも使い回せる、設計意図を把握するための確認表

分量は本文の約7割です。すべてAustralia PDIの実測とUI Action・Business Ruleの実装確認に基づいています。権利30件に対しインストール40件（不足10件）というシナリオを、実際に1件通した検証記録も含みます。

💰 ここから先は有料エリア