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

TPRM（Third-party Risk Management）を本番に入れる前に、影響範囲を数字で知りたい。そう思って公式Docsを読んでも、依存アプリまで含めた増分は書かれていません。Australia PDIでTPRMを実際にInstallし、テーブル・ロール・ACLなど25項目を導入前後で数えました。結果はフィールドが+5,170件、ACLが+3,441件、テーブルが+363件です。しかもACLは数える角度で+3,441と1,537という2つの顔を持ちます（本文で種明かしします）。

TPRMを入れる前に、影響範囲を数字で知りたい

Storeアプリの詳細画面には「Install」ボタンと簡単な説明文があるだけで、テーブルやACLがどれだけ増えるかは書かれていません。読者が本番導入の判断をするとき欲しいのは、機能の説明ではなく「入れたら何が起きるか」という数字です。本記事はその数字を全部並べます。以前PPM Standardで同じ調べ方をしたときは、テーブルが+215件、ACLが+1,943件でした。TPRMはそれを上回る規模の依存関係を持つアプリです。同じ手順で数え直すと、どこまで違うのかを確かめます。

差分は25項目、最大はフィールド+5,170・次点がACL+3,441

まず数字から。増減の全体を1枚で見てしまいます。テーブル定義・フィールド定義など「設定が増えたら必ずどこかに行が増える」25項目を、導入前後で数えました。

最大の増分はフィールド定義の+5,170件。次がACLの+3,441件です。ゼロはワークフロー（wf_workflow）だけ。残り24項目はすべて増えています。以前PPM Standardのときのテーブル増分は+215件、ACL増分は+1,943件でした。同じ「アプリを1つ入れる」操作でも、TPRMはテーブルで1.7倍、ACLで1.8倍の規模です。

TPRMはGRCという傘の下にあるが、単体でも導入できる

TPRMは単独のアプリではなく、GRC（Governance, Risk, and Compliance）系アプリ群の一員です。GRCはポリシー管理・全社リスク管理・監査・第三者リスク管理をまとめた統制系アプリの総称で、TPRMはその「第三者リスク」担当にあたります。sys_remote_appのdependenciesにはsn_grc（GRC: Profiles）など5つのGRC系スコープが並びます。GRCには他にAudit・Policy & Compliance・Risk Managementという同族アプリもありますが、依存プラグインは導入後もすべてInactiveのままでした。TPRMはGRCの共通基盤（sn_grc）だけを共有し、単体で成立する作りです。

TPRMは何をするアプリなのか

第三者との取引（Engagement）を登録し、その取引先に対してアセスメント（質問票ベースの評価）を実施し、見つかった指摘事項（Issue）を追跡してタスクで是正する。この一連の流れがTPRMの中心です。外部の取引先自身がポータルから質問票に回答できる仕組みも持っており、社内担当者と社外の回答者の両方が同じデータに向き合う設計になっています。四者目（4th party、取引先がさらに委託する先）の関係も扱える点は、単純な取引先台帳とは違うところです。

公式説明は「集中管理プロセス」だと言う

sys_remote_appのshort_description（原文）はこうです。

（訳: 第三者との取引に関連するリスクを識別・評価・管理するための集中管理プロセス）

App Manager詳細画面のSummary（原文・抜粋）も同じ方向を向いています。

（訳: TPRMアプリは第三者ポートフォリオの管理と、第三者アセスメント・是正のライフサイクルを完了させる集中管理プロセスを提供する。他のGRCアプリとの連携により、統制とリスクに対するコンプライアンスの追跡性がさらに高まる）

引用元: /sys_store_app_list.do?sysparm_query=scope=sn_vdr_risk_asmt（導入前は sys_remote_app、導入すると sys_store_app に行が移ります）

「集中管理プロセス」という言葉が示すのは、取引先の情報とアセスメントの結果を、部門ごとのExcelではなく1つのプラットフォームに集約する狙いです。この狙いがどれだけの設定を連れてくるのかを、導入前後の実測で確かめます。

Reviewダイアログは3件、実際に増えたスコープは25件だった

App Manager上でInstallを押すと、Review Installation Detailsダイアログが開きます。表示された依存はsn_vrm_ws・sn_grc_ftr_role・com.snc.grc_vrm_depの3件だけでした。

濃紺の起点がTPRM本体です。緑の3件はdependenciesに宣言されていて、かつダイアログにも表示された組です。橙の3件は宣言はあるのにダイアログには出ません。紫は、宣言にもダイアログにも名前が出ないまま連鎖してきた孫依存です。灰色の枠は、実際に増えた25スコープのうち個別に内訳を確認できていない18件を示します。

宣言された6件のうち、ダイアログに出たのは半分だけ

sys_remote_app.dependenciesをそのまま読むと、TPRMが宣言する依存は6件です。前半3件はsn_vrm_ws・sn_grc_ftr_role・com.snc.grc_vrm_depとなります。後半3件はsn_grc・sn_svdp・sn_comp_asmtです。このうちダイアログに表示されたのは前半3件だけで、後半3件は宣言されているのにダイアログには出ません。

さらにcom.snc.grc_vrm_dep自身のrequiresを見ると、com.snc.grc_profile_dep com.snc.vdr_risk_asmt_designer com.snc.vendor_core com.snc.assessment_core com.snc.document_managementという5件の孫依存が書かれています。この5件は宣言にもダイアログにも名前が出ないまま、実際には有効化されている計算になります。PPMのときも「宣言にあるのにダイアログに出ない」「宣言にすら無いのに入ってくる」という2種類のズレがありましたが、TPRMは依存の階層がもう1段深く、孫依存という3段目まで持つ構造です。

フィールドは+5,170件、1テーブルあたり14.2件のペースで増える

テーブル定義の増分363件に対してフィールド定義は5,170件増えているので、単純に割ると1テーブルあたり平均14.2フィールドという計算になります。PPMのときの1テーブルあたり18.2フィールドよりやや少なく、TPRMのテーブルはPPMのプロジェクト管理系テーブルほど項目数が多くない、比較的軽量な構造です。ACLは操作（read/write/create/delete）とフィールドの組み合わせで増えるため、テーブル数の9倍以上に膨らみます。権限がどの層で決まるかの全体像はServiceNowで権限はどこで決まる？にまとめています。

ビジネスルールは+908件、通知はわずか+66件にとどまる

ビジネスルールは+908件、スクリプトインクルードは+434件、クライアントスクリプトは+335件です。テーブルの増分363件に対して、自動化系の増分だけで1,700件を超えます。

この+908件が何をしているかは、アセスメントを1件動かすとすぐ体感できます。作成画面でテンプレートを選んで保存しただけで、紐付く質問票のリンクがビジネスルールに自動コピーされます。Submitボタンの実体は「stateを2に変える」だけの数行で、担当者への割当・回答用レコードの生成・回答期日の設定は、すべてボタンの裏で動くビジネスルールの仕事でした。+908という数字は、読者が画面で押すボタンの1つひとつに、見えない実処理が束ねられていることの表れです。保存前後や非同期でどう処理を分けるかはServiceNowのBusiness Ruleはいつ動く？の通りです。

一方で通知（sysevent_email_action）は+66件です。TPRM単体（sn_vdr_risk_asmtスコープ）に絞ると18件、GRC系5スコープの合計でも40件でした。名前はInternal（社内向け）とExternal（社外向け）で分かれ、社内担当者と社外の取引先で内容を変える設計です。棚卸しの手順はServiceNowの標準通知403件、実際に飛んでいるのはどれ？にまとめました。

選択肢は+977件、TPRM固有のジョブは4件だけ

選択肢（sys_choice）は+977件で、25項目の中でACL・フィールドに次いで増分が大きい項目です。ティア（重要度）やレーティング（リスク評価）のスケール、質問票の回答肢など、選ぶ場面が多いアプリであることが件数から見えます。だから本番設計では、TierとRatingの選択肢をどう使うかを先に決めておく必要が出てきます。

スケジュールジョブ（sysauto_script）は+43件ですが、このうちTPRM固有のスコープに属するのは4件だけでした。定期的に動くのは、リスク評価の再計算（期限切れや条件変更のたびに実行）・セキュリティスコアのクリーンアップ（日次）・繰り返しアセスメントのスケジューリング（日次）の3件です。残る1件は、名前に「DO NOT RUN THIS MANUALLY」と明記された移行用ジョブでした。定期実行ジョブが本当に動いているかを見分ける方法はServiceNowのスケジュールジョブは本当に動いている？にまとめています。

テーブルを持つのはsn_vdr_risk_asmtとsn_grcの2スコープだけ

増えた25スコープのうち、テーブル数を確認できた6スコープで見ると、実際にテーブルを1件でも持つのはsn_vdr_risk_asmt（62件）とsn_grc（96件）、それにsn_comp_asmt（3件）だけでした。sn_svdp（外部ポータル）・sn_vrm_ws（ワークスペース）・sn_vendor_core（共通コア）はテーブルを0件しか持ちません。

画面を提供するスコープとデータを持つスコープが分かれているのは、UIの見た目を変える改修とデータ構造を変える改修で、触るべきスコープが違うという意味です。目的別にスコープを絞り込む具体例は後半で図にまとめます。

ロールとACLはGRCとTPRM本体の2スコープに集中する

ロール（sys_user_role）の増分は全体で+71件ですが、内訳を確認できた範囲ではsn_grcが22件、sn_vdr_risk_asmtが7件とこの2スコープに集中しています。ACLもsn_grcが900件、sn_vdr_risk_asmtが587件です。テーブルを持たないsn_svdpにもACL8件があり、「SVDPVendorPortalSurvey」という処理型ACL（execute）が外部ポータルの操作を制御しています。ACLの読み方の基本はロールを付けたのに見えない理由：ACL（sys_security_acl）の通りです。

TPRM固有の7ロールは、管理者（vendor_risk_admin）→マネージャ（vendor_risk_manager）→レビュアー/アセッサーという3段の継承構造です。承認者（approver）には直接紐づくACLが0件で、承認という行為は他のロールが持つACLの上で成立する純粋な承認専用ロールです。ロールの包含関係で想定外の権限が広がる仕組みはServiceNowで付けたロールが想定外の権限を含んでいた理由で確認できます。

ベンダーマスタは新テーブルを持たず、core_companyを直接参照する

TPRMを入れると取引先（vendor）専用のマスタテーブルができると考えがちですが、実際にはsn_vdr_risk_asmt_vendor_engagement（取引テーブル）のvendorフィールドは、既存のcore_companyを直接参照していました。組織情報の保存先は組織テーブル：会社・部署・原価の3枚（core_company）の通りです。

導入直後にVendor Management Workspace（/now/vendor-management）を開くと、Total third partiesの欄に78という数字が並びます。取引（Engagement）やアセスメントは0件なのに78社が表示されるのは、core_companyのvendorフラグがtrueの会社を数えているからです。デモの177社のうち78社にvendorフラグが立ち、TPRMは業務データが0件でも会社マスタをそのまま母数に使います。

連絡先だけ、旧Vendor Managementのテーブルを流用している

取引先の担当者情報を扱う指摘事項（sn_vdr_risk_asmt_issue）のvendor_contactフィールドは、sn_vdr_risk_asmtスコープではなくvm_vdr_contactというglobalスコープのテーブルを参照しています。vm_vdr_contactはsys_userを継承したテーブルで、旧Vendor Management（TPRMの前身）の遺構です。新しいアプリであるTPRMが、連絡先の管理だけは古い仕組みをそのまま使い回している格好です。

sae_enabledは一度trueにすると元に戻せない

sn_vdr_risk_asmt.*のシステムプロパティは10件です。中でも目を引くのはsae_enabled（新方式の Smart Assessment Engine へ切り替えるスイッチ）で、公式の説明文にはこう書かれています（原文・抜粋）。

（訳: 警告。この設定を一度trueにすると、falseに戻すことはできない。Smart Assessment EngineとAssessment Engineのどちらを使うかを選ぶオプション）

引用元: /sys_properties_list.do?sysparm_query=name=sn_vdr_risk_asmt.sae_enabled

導入直後の値はfalseです。有効化するかどうかは機能を試してから決めるのではなく、後戻りできない前提で判断する必要があります。会社名を表示するcompany.nameプロパティの初期値も「ServiceNow」のままで、外部ポータルに表示される項目なので、本番導入では自社名への変更を忘れないかを確認するポイントです。

Assessment Templateは0件、入れただけでは1件も流せない

質問票の元になるアセスメント種別（asmt_metric_type）はTPRMスコープに5件あり、ESG・第四者登録・プライバシーなどのテーマ別テンプレートがすべてActiveの状態で入っています。ところがアセスメントを実際に作成するときに使うsn_vdr_risk_asmt_template（Assessment template）は0件でした。

材料となる質問票の種別は揃っているのに、それを組み合わせて1本のアセスメントとして流すためのテンプレートは、管理者が自分で作成するまで存在しません。導入した直後は「アセスメントの種類は選べるが、実際に取引先へ送る質問票は1つも無い」状態です。重みの初期値も、Third-party Risk Assessmentsだけが100でEngagementsやSubsidiariesは0という設定でした。導入直後の総合スコアは、外部アセスメントの結果だけで決まる作りになっています。

実機で気づいたこと

ACLの増分を2つの角度から数えると、違う数字が出てきました。25項目の差分集計では+3,441件でしたが、TPRM関連7スコープに絞ってsys_security_aclを数えると合計1,537件です。差は約1,900件。TPRM関連スコープの外、つまりcore_companyのような既存テーブルに新しく作られたACLや、他スコープにまたがるACLだと考えられます。スコープ単体の集計だけでは、増分の全体像を見誤るところでした。

もう一つ意外だったのは、def_rating_scaleとdef_tier_scaleという2つのスケールが、同じ0-19/20-39/40-59/60-79/80-100という5段のバンド構造を持ちながら、高得点側の意味が逆になっていたことです。レーティング（リスク評価）は0-19が「1-Very High」つまり高リスク、80-100が「5-Very Low」で低リスクを意味し、スコアが高いほど安全という向きです。ところがティア（重要度）は逆で、80-100が「1-Very High」つまり最重要という向きでした。同じ画面に「高いほど安全」なスケールと「高いほど重要」なスケールが並ぶため、設定画面ではどちらを見ているかを毎回確認する必要があります。

増えた部品は、レコードを流し始めるとこう見える

増分の数字だけでは、導入後の画面の変わりようは想像しにくいものです。検証用に取引先14社・エンゲージメント29件・アセスメント35件を実際に流した状態の一覧がこちらです。

+363のテーブルのうち、日々の運用で開くのは実質この一覧（assessment）とengagement・issueの数枚です。残りの大半は、この画面を裏で支える設定・履歴・中間テーブルとして働きます。ワークスペースの数字も、流した分だけ動きます。

Risk rating系のチャートが「No data available」のままである点も実測どおりです。評価値はスコアリング設定を作り込むまで空のままなので、導入直後のダッシュボードは件数系のカードから埋まっていきます。

本番導入前に何を確認するか

TPRMはServiceNow Storeアプリなので、Update Setには乗りません。設定を別環境へ運ぶ仕組みの基本はUpdate Set（sys_update_set）：設定を運ぶ2層の箱の通りです。ただしStoreアプリ自体は対象外なので、各環境で個別にInstallし、バージョンを揃えて管理する必要があります。今回の実測でTPRM本体は22.3.3、依存のsn_svdpは22.3.2でした。バージョンのズレは動作差につながるため、複数環境では番号を記録しておくことが欠かせません。

画面を直すのかデータ構造を直すのかで、触るべきスコープは変わります。

ポータルの見た目を直すならsn_svdp、アセスメントの項目を増やすならsn_vdr_risk_asmtやsn_grcというように、改修の目的で確認先を絞り込めます。

ACLとロールの増加数は、セキュリティ担当が必ず聞く項目です。「ACLが3,441件増えます、そのうち1,537件はTPRM関連スコープの中です」と内訳を示せば説明はそれで十分です。監査ログ（sys_audit）の対象も、既存のcore_companyにフィールドが増えた分だけ広がります。仕組みはServiceNowの変更履歴はどこに残る？の通りです。

sae_enabledのような不可逆スイッチがあるアプリは、検証環境で先に試してから本番の設定値を決めるほうが安全です。Assessment Templateが0件から始まる点も見落としやすく、テンプレートを作らなければ質問票を1件も送れません。

用語

TPRM（Third-party Risk Management）：第三者との取引に関するリスクを識別・評価・是正するアプリケーション群。旧称Vendor Risk Management。

dependencies（sys_remote_app）：そのアプリが必要とする他のアプリのスコープ一覧。ここに書かれていてもReview Installation Detailsダイアログには表示されないことがある。

Assessment template（sn_vdr_risk_asmt_template）：アセスメント種別を組み合わせて実際に取引先へ送る質問票の実体。導入直後は0件で、管理者が作成するまで使えない。

sae_enabled（Smart Assessment Engine）：AIによるアセスメント支援機能を有効化するプロパティ。一度trueにすると元に戻せない不可逆スイッチ。

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

自分のインスタンス名に続けて開きます。

• TPRMアプリの詳細：/sys_remote_app_list.do?sysparm_query=id=sn_vdr_risk_asmt

• TPRM関連の新規スコープ：/sys_scope_list.do?sysparm_query=nameLIKEvendor%5EORnameLIKEgrc%5EORDERBYname

• TPRM本体のテーブル一覧：/sys_db_object_list.do?sysparm_query=sys_scope.scope=sn_vdr_risk_asmt

• sae_enabledプロパティ：/sys_properties_list.do?sysparm_query=name=sn_vdr_risk_asmt.sae_enabled

• Assessment templateの件数：/sn_vdr_risk_asmt_template_list.do

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

引用したsys_remote_appとsys_propertiesの説明文は、以下のURLを自分のインスタンスで開くと読めます。

• アプリの説明（引用元）：/sys_remote_app_list.do?sysparm_query=idINsn_vdr_risk_asmt

• プロパティの説明（引用元）：/sys_properties_list.do?sysparm_query=nameLIKEsn_vdr_risk_asmt%5EdescriptionISNOTEMPTY

検証範囲とおことわり

Australia PDI（OOTB）で2026-08-22にTPRM（sn_vdr_risk_asmt、latest_version 22.3.3）を1つ導入しました。導入先は検証用のPDIで、本番環境ではありません。デモデータはno_demo_dataのため、業務レコードは導入直後は0件です。本記事の差分数値は、下記の検証データを投入する前に計測したものです。

数えたのは25種類のテーブルの件数増減だけです。これ以外にも増えているものはあり、網羅ではありません。実際に増えた25スコープのうち、個別に役割・件数を確認できたのは7スコープにとどまり、残り18スコープは未特定です。

外部の取引先がアクセスする経路はsn_svdp（外部ポータル）と「GRC: Third Party External Workspace」（UXワークスペース）の2系統です。後者のマウントパスは実測では特定できませんでした。GRCの他の同族アプリ（Audit・Policy & Compliance・Risk Management）は依存プラグインがInactiveのままで、その状態での挙動しか確認していません。

アンインストール（ロールバック）は試していません。Now Assist for Third-Party Risk Managementなど、PDIではblock_installがtrueでインストールできないアプリの挙動は未確認です。他のアプリでは依存の構成も増える数も変わるため、この記事の数字はTPRMの場合であって一般化はできません。

関連記事

• ServiceNowにPPMを入れると何が増える？ — 同じ手順をPPM Standardで実行した記事

• ServiceNowでプラグインを入れると何が変わる？ 影響調査でチェックする27か所 — 同じ調べ方をCIMで実行した記事

• ServiceNowで権限はどこで決まる？ — 増えたACL・ロールがどの層で効くかの全体像