TPRM（Vendor Risk Management）プラグインのインストール手順
TPRM（Third-party Risk Management、旧Vendor Risk Management）を試すときの最初の関門は価格表示です。App Managerの詳細画面には「Pricing: Paid」と出ます。有償の表示を見て、検証環境にすら入れられないのではと手が止まった方もいるはずです。実測の答えは「Paid表示のままPDIでもInstallは通る」でした。本体のスコープが現れるまでは約2分。依存プラグインの連鎖まで含めた完了は約26分です。Australia PDIで実際に導入し、押してから何が起きるかをたどります。
検証環境：Australia PDI / OOTB / 2026-08-22 確認。Third-party Risk Management（sn_vdr_risk_asmt v22.3.3）を導入
この記事に出てくる3つの数字：宣言された依存 6件 ／ 確認ダイアログに表示 3件 ／ 実際に増えたスコープ 25件。以降の数字はすべてこの3つの枠に収まります
TPRMとは：Third-party Risk Management（サードパーティ・リスク管理）の略です。委託先やサプライヤーなど社外の取引先について、選定時の評価から契約中の継続モニタリング、問題発生時の是正までを1つのプロセスで管理する仕組みです。旧称はVendor Risk Managementで、現在はServiceNow Storeのアプリとして配布されています。
社外の取引先リスクを1か所で管理したいとき、何が要るのか
委託先の選定時にセキュリティ質問票を送り、契約中は年1回の再評価を求め、問題が見つかったら是正計画を追う。これを調達・情報セキュリティ・法務が別々のExcelとメールで回していると、「今どの取引先が要注意か」を答えるのに時間がかかります。本来欲しいのは、評価履歴と指摘事項（Issue）が1つの記録に紐づく仕組みです。TPRMはこの領域を担うアプリケーションとして、ServiceNow Storeから配布されています。
TPRMはGRCスイートのどこに位置する機能か
TPRMという名前だけを見ると独立したアプリに思えますが、実際はGRC（Governance, Risk, Compliance）スイートの一員です。GRCスイートにはAudit、Policy & Compliance、Risk Managementなど同族アプリが並びます。Risk Managementが自社内のリスク登録簿を扱うのに対し、TPRMは社外の取引先に特化します。
sys_remote_appに記録されている公式のshort_description（原文）はこうです。
Centralized process to identify, assess, and manage risk associated with third-party engagements.
（訳: 第三者との取引に関連するリスクを特定・評価・管理するための、一元化されたプロセス）
引用元: /sys_store_app_list.do?sysparm_query=scope=sn_vdr_risk_asmt（導入前は sys_remote_app にある行が、導入すると sys_store_app へ移ります）
同族のGRC機能（Audit / Policy&Compliance / Risk Management）とは何が違うか
GRCスイートには同族のDependenciesプラグインが存在します。TPRMを導入したあとも、Audit・Policy&Compliance・Risk Managementの依存プラグインはInactiveのままでした。GRCスイート全体を抱き合わせで入れる必要はなく、TPRM単体の導入が成立します。
TPRMは何を統合し、何が有益なのか
App Manager詳細画面には、取引先ポートフォリオの一元管理と、評価から是正までのライフサイクルを完走させる仕組みだという説明が表示されます。Summaryの末尾には次の一文もありました（原文）。
Integration with other GRC applications provides additional traceability for compliance with controls and risks.
（訳: 他のGRCアプリケーションと連携することで、統制やリスクに対するコンプライアンスの追跡性がさらに高まります）
引用元: App Manager詳細ページのSummary表示（上のsn-inst-03画面）
TPRM単体でも評価と是正は完結しますが、Auditなど他GRCアプリを併用すると追跡性がより高まるという位置づけです。
依存関係が示す設計：GRC Profileの上に単体で乗る仕組み
sys_remote_appのdependenciesは次の6件です。
sn_grc:22.3.3（GRC: Profiles）
sn_svdp:22.3.2（GRC: Vendor Portal）
sn_comp_asmt:22.3.2（GRC: Compliance Assessment）
sn_vrm_ws:22.3.2（GRC: Vendor Risk Management Workspace）
sn_grc_ftr_role:22.3.0（GRC Feature roles）
com.snc.grc_vrm_dep（プラットフォーム側の依存束ねプラグイン）
com.snc.grc_vrm_depの公式説明（原文）はこうでした。
Installs all the dependent plugins required to support the GRC Vendor Risk Management application.
（訳: GRC Vendor Risk Managementアプリケーションの動作に必要な、依存プラグイン一式をまとめて導入します）
引用元: /v_plugin_list.do?sysparm_query=id=com.snc.grc_vrm_dep
sn_grc（GRC: Profiles）を共通基盤として、その上にVendor Portal・Compliance Assessment・Workspaceが乗ります。GRC ProfileはTPRM専用ではなく、他のGRCアプリとも共有される基盤です。
App Managerで検索してもPricing「Paid」と出る。それでもPDIでは入るのか
詳細画面には次のフィールドが並びます。
Pricing: Paid
Category: Vendor Risk Management
Release compatibility: Australia
Custom Table Count: 0（ストア詳細画面の表記で、ライセンス対象のカスタムテーブル数。導入で増えるテーブル定義の数=+363とは別の指標です）
「Paid」の表示を見ると検証環境でも試せないアプリかと構えます。しかし実際にはPDIで問題なくInstallが通りました。block_installはfalseで、価格表示とインストール可否は別の判定軸だと分かります。もう一点demo_dataはno_demo_dataでした。PPM Standardのようにデモの業務レコードが一括で入るタイプではなく、導入後も業務データは0件のままです。
Application Managerでの検索から詳細画面まで実際にたどる
Application Managerは/now/app-manager/homeです。検索欄に「Third-party Risk Management」と入力すると候補が並びます。
検索結果に並ぶ関連アプリ、Now Assistは押しても入らない
同じ検索結果には、TPRMと名前の近い周辺アプリも並びます。並んで見えても、導入できるかどうかはblock_install次第で分かれます。
導入できない側の代表は3つです。sn_tprm_genai（Now Assist for TPRM）、sn_ai_irm_fdn（Integrated Risk Management Foundation）、sn_itsm_vendor（Vendor Manager Workspace）。いずれもblock_installがtrueで、PDIでは導入できません。 AI系の追加機能まで一括で試したい場合は選択肢から外れます。
Installを押すと出るReview Installation Detailsの中身
Installを押すと確認ダイアログが出ます。表示された依存は次の3件でした。
GRC: Vendor Risk Management Workspace 22.3.2
GRC Feature roles 22.3.0
GRC: Vendor Risk Management Dependencies
demo_dataがno_demo_dataのため、PPM Standardにあった「Load demo data」のチェックボックスはここには出ません。選ぶのはInstall nowかInstall laterだけで、今回はInstall nowを選びました。Install laterは日時を指定して夜間などに実行を回すための選択肢です。本番作業では業務時間外へ回す判断もあり得ますが、今回のように検証環境で挙動を観察したい場合は、目の前で走らせる方が確認しやすくなります。
ダイアログの依存3件と、実際に増えた25スコープ
ダイアログが見せるのは1段目の3件だけです。3件目のcom.snc.grc_vrm_dep自身がさらにgrc_profile_dep assessment_core document_management vendor_core vdr_risk_asmt_designerという5件を要求しており、ここが画面に出ない2段目です。しかもvendor_coreとvdr_risk_asmt_designerはAustraliaのv_pluginにレコードが存在せず、ストアアプリのsn_vendor_coreなどに置き換わっていました。
こうして最終的に増えたアプリケーションスコープは25件です。PPM Standardのときは「ダイアログ3件・実際10プラグイン」でしたが、TPRMはそれを上回る乖離でした。宣言・ダイアログ・実態が違う数字を示すのはGRC系プラグイン共通の傾向かもしれません（推測）。プラグイン導入の影響調査27か所と同じやり方で差分を数えています。
Installを押してから完了までにかかった時間
Installを押すと画面には「Install from the App Repository」という進行表示が出ます。画面のメッセージだけを見て「終わった」と判断すると、実際にはまだ処理が続いている状態を見落とします。CIMプラグインを導入したときも、本体がactiveになった裏でATFプラグインが処理中でした。TPRMでも同じ落とし穴があります。
本体のscopeが出るまで約2分、依存連鎖が終わるまで約26分
09:07:28にInstallを押した後、本体sn_vdr_risk_asmtのsys_scopeは09:09時点ですでに存在していました。押下から約2分です。しかし依存を束ねるcom.snc.grc_vrm_depがactiveになったのはそこから20分近くあとで、最終更新時刻は09:33:38でした。押下からここまでで26分10秒です。本体のスコープが見えた時点で「もう使える」と判断すると、依存プラグインの導入が半分も進んでいない状態で次の作業に入ることになります。
補足として、このとき実行中のワーカーは33件ありましたが、中身はすべて常駐の「Instance Scan」でTPRM導入とは無関係でした。名前を見れば切り分けられます。
「終わったかどうか」は3つのレコードで見分けられる
進行ダイアログは「Run in background」で閉じてしまって問題ありません。閉じたあとに完了を確かめる場所は3つあります。1つ目はsys_store_appです。導入前はsys_remote_appにあったアプリの行が、導入が終わるとsys_store_appへ移り、App ManagerのInstalledタブにも同じものが現れます。2つ目はsys_scopeで、本体のsn_vdr_risk_asmtを含む新しいスコープが並んでいれば取り込みは済んだ合図です。3つ目が依存連鎖の終点であるcom.snc.grc_vrm_depで、v_pluginでこのプラグインがactiveになっていれば、2段目・3段目の依存まで含めて処理が終わったと判断できます。本体スコープの出現だけで判断せず、この3点目まで見てから次の作業に入ると安全です。3か所とも一覧URLを開くだけで確認でき、管理者権限があれば1分で終わる作業です。
導入後にApp Managerと左メニューはどう変わるか
導入前後で何がどれだけ増えたかは、次の表のとおりです。
テーブル定義が363、フィールド定義が5,170、ロールが71、ACLが3,441増えました。PPM Standardのときと同じ観点で数えていますが、GRCという共通基盤を持つぶん、フィールド定義とACLの増加量がひときわ大きくなっています。
ナビゲーターに現れる新しいメニュー
増えたアプリケーションメニューは5件でした。中心はThird-party Risk Managementです。配下にはThird Parties・Engagements・Internal/External Assessments・Issues/Tasksが並びます。一方、導入した6スコープのうち5つは独自のメニューを持たない補助スコープでした。内訳はVendor Portal・Compliance Assessment・Workspace・Feature roles・Vendor Coreの5つ。画面に見えている以上の作りが、共通基盤側に入った構成です。
メニューの並びは、そのまま初期設定の順路を兼ねた作りでした。Setup系のセクション（Assessment Setup / Tiering Setup / Scoring Setup）が後半にまとまっています。Guided Setupを持たないTPRMでは、この階層を上から順に辿ることが実質のセットアップ手順です。管理画面の使い分けはAdmin Centerの回で整理しています。
Vendor Management Workspaceの初期表示：Total third parties 78の正体
導入直後に/now/vendor-managementを開くと、Total third parties: 78という数字がいきなり表示されます。TPRM自身の業務レコードは0件のはずなのに、この78はどこから来るのでしょうか。答えはcore_companyでした。全177社のうちvendor=trueが立っている78社を、会社マスタから直接数えています。Total engagementsは0のままで、TPRM固有のレコードがまだ無いという実態どおりの表示です。画面右側にはQuick actionsが6つ並びます。Create third party / engagement / internal assessment / external assessment / issue / task。業務データ0件の状態からでも、起点になる操作を一覧できる作りです。導入直後のこの画面は、TPRMの初期状態を関係者に説明する1枚目としても使えます。数字の出どころまで添えれば、「もうデータが入っている」という誤解を先回りで防げます。
本番環境に入れる前に確認しておくこと
PDIでの実測をもとに、本番の作業計画を考えると次の3点が要点になります。推測を含む設計提案として読んでください。
契約・ライセンス：Pricing欄の「Paid」表示は導入可否とは別の話です。本番で使うにはサブスクリプション契約の対象かどうかを本番側で確認します
作業時間：ダイアログの依存件数を鵜呑みにせず、検証環境で実測した所要時間を使います。今回は26分でしたが、PDIの性能に依存する値なので本番では余裕を持たせます
アンインストール：今回は試していません。「入れられる」ことと「安全に戻せる」ことは別なので、戻す前提で計画するなら検証環境で先に試しておくことをおすすめします
セキュリティレビュー：ACLが3,441件、ロールが71件増えるため、権限設計のレビュー対象が一気に広がります。承認を取る資料には「何件増えるか」を先に載せておくと、レビューが差し戻しになりにくくなります
バージョンの記録：今回入ったのは本体22.3.3に対して依存のVendor Portalなどは22.3.2と、版番号が揃っていません。Storeアプリは環境ごとに個別導入になるため、複数環境で運用するなら「どの環境に何の版が入っているか」の台帳を導入当日から残しておくと差異調査が楽になります
実機で気づいたこと
ダイアログが見せた依存は3件、実際に増えたスコープは25件でした。 PPM Standardの「3件→10プラグイン」よりも開きが大きく、GRCという基盤の上に立つプラグインほど乖離が広がるのかもしれません。
デモデータが無いプラグインでも、画面はいきなり数字を出してきます。 Vendor Management Workspaceの「78」は、TPRM自身のレコードではなくcore_companyのvendorフラグを数えているだけでした。数字の出どころを確かめずに「データが入っている」と思い込むと、話がかみ合わなくなります。
依存の数が多いのに、PPMより短い時間で終わりました。 PPM Standardのときはワーカーが消えるまで31分でした。TPRMは今回26分です。スコープの増分はTPRMの方がずっと大きいのに時間は短く、デモデータの読み込みが無いことが効いていると考えられます（推測）。所要時間は「依存の数」ではなく「何を読み込むか」で決まる、というのが2回の実測から見えた傾向です。
検索結果に並んでいるからといって、同列に扱えるとは限りません。 Now Assist for Third-Party Risk Managementは同じ検索結果に表示されますが、block_installがtrueで押しても入りません。並びだけで導入計画を立てると後で崩れる箇所です。
導入はここまでで完了ですが、この時点ではアセスメントを1件も流せません。アセスメントの実行に必要なテンプレートが0件のためで、最初に行う設定は本シリーズの基本設定編で扱います。
用語
TPRM … Third-party Risk Management。社外の取引先リスクを評価・管理する仕組み。旧称Vendor Risk Management
GRC … Governance, Risk, Compliance。統制・リスク・コンプライアンスを扱うアプリケーション群の総称
block_install … sys_remote_appのフィールド。trueだとApp Managerからのインストールが機能しない
Review Installation Details … Installを押した直後に出る確認ダイアログ。表示される依存は1段目まで
スコープ（sys_scope） … アプリケーションごとの名前空間。導入したプラグインの単位を数える基準
自分の環境で確認するときのURL
インスタンスのURLに続けて開いてください。
Application Manager：/now/app-manager/home
TPRMの詳細に直接入る：/now/app-manager/home/app/id/4c821a2d9f42220030581471367fcf2c/v/22.3.3
Vendor Management Workspace：/now/vendor-management
引用元: アプリケーションの説明/sys_store_app_list.do?sysparm_query=scope=sn_vdr_risk_asmt／プラグインの説明/v_plugin_list.do?sysparm_query=id=com.snc.grc_vrm_dep
検証範囲とおことわり
Australia PDIに、OOTBの状態からTPRM（sn_vdr_risk_asmt v22.3.3）を導入して確認しました。デモデータは元々選択肢が無く、入れていません。所要時間と件数は2026-08-22時点のこの環境のものです。
シリーズ共通の検証データ：既存デモ企業14社を流用し、検証用の取引先1社（Meridian Data Services）を追加。担当者15名・エンゲージメント29件・アセスメント36件（うちDraftからClosedまで完走2件）・イシュー8件をこのシリーズの検証で作成しています。数値は2026-08-22時点の実測です。
確認していない範囲は次のとおりです。
アンインストール（ロールバック）とInstall laterを選んだ場合の挙動
本番インスタンスでのライセンス契約・課金の扱い
PDIで導入できなかったNow Assist等の周辺アプリ、他GRCアプリを併用した場合の差
導入後の詳細な初期設定（ロール・通知・スケジュールジョブの内訳）は本記事の範囲外。所要時間もPDIの性能に依存する
