SAMの導入後のテーブルやロールなどの変化を調査

「で、結局何件増えるの？」。新しいアプリの本番投入前、変更管理のレビューで必ず聞かれる質問です。SAM（Software Asset Management）の場合、Storeアプリの説明画面を見てもこの答えは載っていません。しかも導入はStoreアプリの導入とSAM Professionalの有効化の2段階に分かれていて、増分は2回に分けて数えないと合計を誤ります。Australia PDIでこの2段階を実際に踏み、導入前後の件数を突き合わせて数えました。

影響調査でまず知りたいのは「結局何件増えるのか」という実数

新しいアプリを本番環境に入れる前、情報システム部門やセキュリティ部門が確認したいのは、テーブルやACL、ロールが実際どれだけ増えるかという実数です。変更管理のレビュー範囲もセキュリティ監査の対象も、この実数が根拠です。ServiceNowでプラグインを入れると何が変わる？ 影響調査でチェックする27か所ではこの数え方を27項目に整理しましたが、SAMの場合はこの手法を2段階に分けて当てはめる必要があります。

SAMは1回のInstallでは全量が入らない、差分調査として一癖ある対象

多くのアプリは、Installを押した瞬間にテーブルもロールもACLも一括で入ります。SAMは構造が異なります。依存表示に出るのはFoundation（com.snc.sams）だけで、SAM Professional（com.snc.samp）はダイアログのどこにも現れないまま既定で無効です（実画面は導入手順編に掲載）。 「何が増えるか」には2つの答えが要ります。

テーブル・ACL・通知など、何を数えれば「影響範囲」と言えるのか

差分調査で数える項目は3グループに分かれます。テーブル定義（sys_db_object）とフィールド定義（sys_dictionary）はデータモデルの広がりを示す数字です。ロール（sys_user_role）とACL（sys_security_acl）はセキュリティレビューの対象範囲そのもので、通知（sysevent_email_action）やFlow（sys_hub_flow）は運用面の変化を示します。この3グループがそろって初めて、「影響範囲」という言葉に実体が伴う構図です。ロールとACLがそれぞれ何を指すのかは、ユーザー・グループ・ロールを中間表からたどる記事で先に押さえておくと、後段の数字が読みやすくなります。

ストア詳細画面のCustom Table Countは実際の増分を示していない

App Manager詳細画面のCustom Table Countは、SAMの場合0でした（表示画面は導入手順編に掲載）。 これはライセンス上の指標で、実際の増分とは別の数字です。正確な増分件数はStore画面にもドキュメントにも公開されていないため、sys_db_objectやsys_security_aclなどの対象テーブルを導入前後で直接カウントしました。この0という表示を根拠に「影響は小さい」と報告すると、後述する実増分（テーブル+235・ACL+1,712）と矛盾します。変更管理の申請には、Store画面の値ではなく実測の差分表を添えてください。

Storeアプリを入れただけで64表・523件のACLが増える

実測した2段階の様子を1枚の図に整理すると、次のようになります。

Storeアプリ（sn_itam_samp）とFoundation（com.snc.sams）を入れた時点で、テーブル定義は+64、フィールド定義は+1,358、ACLは+523件増えました。ビジネスルールも+124件追加されていて、これだけでもそれなりの規模のアプリが入ったことが分かります。一方で通知（sysevent_email_action）は0件、Flow（sys_hub_flow）も0件、Performance Analytics指標（pa_indicators）も0件でした。この段階のSAMは、データモデルと権限だけを広げ、メールや自動化フローで何かを知らせてくることは一切ない状態です。

Professionalを有効化すると増分はほぼ2〜3倍に膨らむ

SAM Professional（com.snc.samp）を有効化すると、増分の規模が変わります。Storeアプリの増分・Professional有効化後の増分・両方を合算した合計を、項目ごとに並べたのが次の表です。

テーブル定義はStoreの+64に対してProfessional有効化で+171、ACLは+523に対して+1,189です。Professional単独の増分だけで、先ほどのStoreアプリ全体を上回ります。ビジネスルールは+124→+247、スクリプトインクルードは+105→+189で、どちらも2倍前後です。合計するとテーブル定義は+235、ACLは+1,712になります。Storeアプリの数字だけを見て影響調査を終えると、実際の半分以下しか数えていないことになります。

フィールド定義の合計は+5,028列です（Store+1,358・Professional+3,670）。テーブル定義の合計+235で割ると、1テーブルあたり平均21列という計算になります。この数字はデータモデルのレビュー粒度を決める材料です。235テーブルを1件ずつ開いて確認する運用は現実的でないため、レビューでは「どのテーブルを見るか」を先に絞り込み、残りは種別ごとの件数確認で済ませる方式にしたほうが破綻しません。絞り込みの起点には、後述する照合結果系のテーブルと権利の台帳（alm_licenseまわり）が向いています。

システムプロパティ（sys_properties）はStoreで+16、Professionalで+32、合計+48件です。設定できる項目の数がそのまま倍以上に増えるということで、基本設定を1回で終わらせようとすると見落としが出やすくなります。選択肢（sys_choice）もStoreの+292に対してProfessionalは+1,019で、合計の大半をProfessional側が占めるという内訳です。ドロップダウンやステータスの選択肢は、権利や実態のデータを入力し始める段階になって初めて本格的に増える項目だと分かります。

ビジネスルールとスクリプトインクルードは自動化層としてさらに増える

ロジックを担う層の増分も見ておく価値があります。ビジネスルール（sys_script）は合計+371件、スクリプトインクルード（sys_script_include）は+294件です。+371件の中には、権利数を超える割当を拒否する「Ensure Entitlements do not exceed rights」のような統制系のBusiness Ruleが含まれます。件数の増分がそのまま挙動の増分だという例です。クライアントスクリプト（sys_script_client）は+250件、UIアクション（sys_ui_action）は+106件、UIポリシー（sys_ui_policy）は+147件でした。処理をどこに書くか、どの層が肥大化しているかを普段から件数で見ておくと、追加開発の見積もりが立てやすくなります。Business Rule・Client Script・ACLの使い分けを実機の件数から考える記事では「件数比で処理の置き場を判断する」という考え方を扱いました。同じ考え方は、SAMのようにロジックが分厚いアプリの棚卸しにもそのまま使えます。

通知は0件から7件に変わり、FlowとPA指標はProfessionalでしか出てこない

特に性格が変わるのが通知・Flow・PA指標の3項目です。PA指標の+63件は、Performance Analyticsのダッシュボードで追跡できる数値の定義がSAM向けに63種類増えるという意味です。非準拠の件数やTrue-up Costを時系列で追う素材が、レポートとは別枠で用意されています。Storeアプリの段階ではどれも0件でした。Professionalを有効化すると、通知は+7件・Flowは+19件・PA指標は+63件、それぞれ新たに追加されます。Storeアプリだけの状態は、テーブルと権限は広がっているのに、何かが起きても誰にもメールが飛ばない状態です。導入直後の環境で「通知が来ないから設定が間違っているのでは」と疑う前に、まず自分の環境がどちらの段階にいるかを確認したほうが早く原因にたどり着けます。メール通知が飛ぶまでの4段階を追った記事のとおり、通知はNotificationレコード（sysevent_email_action）そのものが無ければ最初の段階にすら進みません。条件を満たすイベントが起きても、受け取る側の設定が無いので何も起きないということです。SAMの通知が持つ運用上の意味は運用設計編で扱います。

増分を自分の環境で数えるときは、リストの件数表示で足りる

特別なツールは要りません。手順は3つです。

1. 導入前に、対象テーブルのリスト（例：/sys_db_object_list.do。ほかは付録のURL一覧を参照）を開き、右下の総件数を記録する

2. Storeアプリの導入後に同じリストを開き直し、同じ場所の件数を記録する

3. Professionalの有効化後にもう一度記録し、2つの差分を並べて表にする

この記事の差分表も、この3手順を27項目に広げて作ったものです。注意点は1つだけあります。1回目の計測を取り忘れると、その環境の差分は二度と確定できません。 導入前の記録だけは省略しないでください。また、前後の計測はなるべく近い時刻で揃えると、無関係な日次処理による増減を差分に拾わずに済みます。スコープで絞れる項目はsysparm_query=sys_scopeSTARTSWITHsn_itam_sampのようなクエリでも数えられますが、globalスコープに入る増分（vm_系のような旧世代テーブル）はこの絞り込みから漏れるため、総数方式のほうが確実です。

新旧2つのメニューにモジュールが分かれて実装されている

アプリメニューは+2件、モジュールは+29件（名前をそろえると22件）増えました。実際にナビゲーションを開くと、この増分がどう画面に現れているかが分かります。

新しいメニューはSoftware AssetとSoftware Asset Classicの2つに分かれています。Software Models・Entitlements・Discovery Models・Run Reconciliationのような中核モジュールは、両方のメニューに重複して存在しています。旧UIと新UIが並存する作りです。背後に見えているSoftware Entitlementsの一覧は77件でしたが、これはSAMが新規に作ったレコードではなく、既存のPDIデモ資産（alm_license）がそのまま見えている件数です。データの中身は連携編で扱います。

スケジュールジョブは9本、稼働しているのは8本

スケジュールジョブはStoreアプリ導入で+9本、Professional有効化でさらに+31本（合計+40本）増えます。名前の先頭にSAM -が付く9本を一覧にすると、次のとおりでした。

9本のうち8本がactiveで、Apply latest content changesだけがfalseでした。有効な8本の中には週次で照合を実行するジョブも含まれていて、Storeアプリを入れただけの段階でもジョブ自体はスケジュールされています。ジョブが具体的に何をいつ実行するかは基本設定編で扱います。

ロールは合計4種類だけ。ACLの規模とは不釣り合いに少ない

権限まわりの増分には、はっきりした偏りがあります。新設されるロールはStoreアプリでsam_admin・sam_developer・sam_userの3種、Professional有効化でsn_itam_common.asset_execが加わり合計4種類にとどまりました。4種目の名前が示すとおり、Professional側の追加は資産系ワークスペース向けの閲覧ロールが1つだけで、SAMの権限体系はStore段階の3種でほぼ完結しています。部署別・機能別に細かく分ける設計を最初から採っていません。運用設計編で扱うとおり、Store由来の3ロールは管理者・開発者・参照者が一直線に継承する構造です。

一方でACLは合計+1,712件です。1,700件を超えるアクセス制御を、わずか4種類のロールで束ねる構図になります。ロールの少なさだけを見て権限設計をシンプルだと判断すると、実際のACL規模を見誤ります。セキュリティ審査で規模を示すときは、ロール数ではなくACL件数を主な指標にするのが安全です。

内訳にも意外性があります。3ロールに直接ひもづくACLを数えると、sam_adminが41件・sam_developerが4件・sam_userが122件でした。いちばん多いのは参照系のsam_userです。直接ACLの件数は、ロールの強さと比例しません。sam_developerは4件しか持たない一方で、sys_admin級のスクリプト作成権限を別の仕組みで持ちます。継承まで含めた実効権限の読み方は運用設計編に譲ります。

レポートとイベント登録は件数こそ小さいが変更管理の対象になる

テーブルやACLほど目立ちませんが、レポート（sys_report）は+4→+20で合計+24件増えました。名前には「Products Out of Compliance」「Publishers Out of Compliance」「True-up Cost」のようなものが並びます。非準拠状況やコスト超過を、そのまま示すレポート名です。経営層やライセンス担当者に定期報告する資料は、この増分の中にすでに用意されている計算です。UIページ（sys_ui_page）も+2件増え、samp_run_reconciliation_by_publisherのような専用画面が追加されます。イベント登録（sysevent_register）も+2件で、cds.download.retryとsamp.reset.install.deduplicatedという名前が新しく現れました。件数としては小さくても、外部連携やジョブの再試行に関わる仕組みが増えている以上、変更管理のレビュー対象から外す理由にはなりません。

実務では何に使えるか

数える作業で終わらせず、次の5つの場面でそのまま使える形にしておくと役に立ちます。

• 変更管理チケットのレビュー範囲を数字で示す：「テーブル+235・ACL+1,712」という実数を添えると、レビュー担当者が確認すべき範囲を具体的に伝えられます

• StoreとProfessionalを別の変更として申請するかを判断する：通知0→7件・Flow0→19件という挙動の変化がある以上、2つの変更を1件の申請に合体させると、どちらの操作でどの機能が有効になったのかを後から追いにくくなります

• ロールの少なさだけで権限審査を済ませない：セキュリティ審査ではロール数ではなくACL件数（+1,712）を主な指標として説明します。ACLと画面表示の関係を層で切り分ける手順はAccess Analyzerの記事で扱っています

• StoreとProfessionalは環境ごとに個別操作が必要だと周知する：プラグインの導入・有効化はUpdate Setで運ばれる変更ではなく、各環境で個別に実行する操作です。開発・テスト・本番のそれぞれでStoreアプリ導入とProfessional有効化を同じ2ステップで再現する前提でスケジュールを組みます。SAM自体の上に独自のBusiness RuleやACLを追加した場合は、その差分だけがUpdate Setの対象です

• 同じ数え方を他のアプリにも使う：sys_db_object・sys_dictionary・sys_security_aclなどの対象テーブルを導入前後でカウントする方法は、SAMに限らず27か所の影響調査で使った手法と同じです

• 複数アプリの導入順を決める材料にする：ほかのアプリも同じ数え方で測っておけば、どのアプリから先に本番へ入れるとレビュー負荷が小さいかを、感覚ではなく実数で比較できます

実機で気づいたこと

表と図に収まらなかった注意点を3つ残します。

選択肢の増分は、テーブル定義の増分より大きい。 選択肢（sys_choice）は合計+1,311件で、テーブル定義の+235件を大きく上回ります。原因はSAMの設計にあります。状態・メトリック種別・非準拠理由といった設定項目を選択肢で表現するためです。影響調査のチェックリストにsys_choiceが入っていない場合は追加してください。テーブルとACLだけ数える調査では、この+1,311件がまるごと落ちます。

増分には内部処理向けの小さな設定が混ざっている。 イベント登録の増分はわずか2件ですが、名前はcds.download.retryとsamp.reset.install.deduplicatedで、コンテンツ配信の再試行とインストール重複排除のリセットに関わる設定です。件数の大きい項目だけを追う調査では、この種の増分が落ちます。回避策は単純で、種別ごとに前後の総数を突き合わせる方式に統一し、増えた項目はゼロ件でない限りすべて列挙することです。

定義の件数とレコードの件数を混ぜて報告しない。

Software publishersの一覧には1,794件のパブリッシャーが並びます。この件数はテーブル定義の増分（+64・+235）とは別物で、SAMコンテンツライブラリが最初から持っている業務データの行数です。定義の増分とレコードの増分はどちらも「件数」という同じ形をしているため、影響調査のレビューで混ぜて報告すると、テーブル設計側の担当者に誤った規模感が伝わります。報告書では「定義系の増分」と「初期データの行数」を必ず別の欄に分けてください。

用語

• Storeアプリ … App Managerからインストールする配布単位。SAMではsn_itam_samp

• Foundation（com.snc.sams） … Installダイアログの依存として自動導入される、SAMの基本機能を動かす基盤

• SAM Professional（com.snc.samp） … 権利と実態を突き合わせる照合エンジン本体。既定は無効で、Storeアプリの依存表示には出てこない

• PA指標 … Performance Analyticsのpa_indicatorsに定義される、ダッシュボードで追跡する数値の定義

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

インスタンスのURLに続けて開いてください。

• テーブル定義の増分を確認：/sys_db_object_list.do?sysparm_query=sys_scopeSTARTSWITHsn_itam_samp

• ACLの一覧を確認：/sys_security_acl_list.do?sysparm_query=sys_scopeSTARTSWITHsn_itam_samp

• ロールの一覧を確認：/sys_user_role_list.do?sysparm_query=nameSTARTSWITHsam_

• スケジュールジョブの一覧を確認：/sysauto_script_list.do?sysparm_query=nameSTARTSWITHSAM

• 選択肢の増分を確認：/sys_choice_list.do?sysparm_query=sys_scopeSTARTSWITHsn_itam_samp

• Professionalプラグインの有効・無効を確認：/v_plugin_list.do?sysparm_query=nameLIKESoftware Asset

どのクエリもsys_scope（アプリケーションスコープ）を起点に絞り込んでいるため、SAM以外のアプリに応用するときは対象のスコープ名を差し替えるだけで、同じ考え方をそのまま流用できます。

検証範囲とおことわり

検証対象はAustralia PDI（OOTB。別シリーズの検証でTPRM導入済み）です。Software Asset Management（sn_itam_samp v4.1.4、Store＋Foundation）の導入前後と、SAM Professional（com.snc.samp）有効化前後の両方を対象にしました。差分は種別ごとに前後の総数を突き合わせる方法で確定させています。確認していない範囲は次のとおりです。

• Software Asset Workspaceなど今回導入していない周辺Storeアプリの増分と、Professionalを先に有効化した場合の挙動差

• 本番同等のカスタマイズが既に乗った環境での増分（今回はPDIの素の状態での実測。定義系と業務データの境界にあたる一部マスタは集計対象外）

• スコープ増分（合計+8件）の内訳を1件ずつ確認すること

関連記事

• 前提知識：ServiceNowでプラグインを入れると何が変わる？ 影響調査でチェックする27か所

• 同シリーズ：（SAMプラグインのインストール手順）

• 次に読む：（SAMの基礎知識）