TPRM（Vendor Risk Management）の基礎知識

委託先の台帳はExcel、質問票はメール、是正の記録は共有フォルダ。ばらばらの置き場を行き来しながら「この会社に任せて大丈夫か」を答え続けるのは、担当者にとって消耗戦です。TPRM（Third-party Risk Management）は、この一連の流れを1つのアプリに集約した仕組みでした。この記事では、次の3つの問いを実機で確かめます。

• TPRMとは何者で、GRCスイート全部を入れなくても動くのか

• 中身はどんな3層構造で、リスクはどう数値化されるのか

• 評価される側（外部の取引先）からは、どんな画面が見えるのか

TPRMの運用は「誰が・どの順で・何をするか」で捉えると全体がつかめます。先にライフサイクル全体を1枚にまとめます。

色の対応は、濃紺がリスク管理者・緑がリスク評価者・紫が社外のベンダー担当者・橙が承認者・青が自動処理です。社内2ロールと社外1ロールが順番に担当を引き継ぎ、最後は自動起票で次のサイクルへつながります。

本記事は9本シリーズの親記事です。各論は次の記事で扱っています。

• 導入手順：App ManagerからTPRMは入るか

• 導入前後の差分調査：テーブルやロールは何が増えるか

• 基本設定：導入直後に行う設定と不可逆スイッチ

• 運用手順：ベンダー登録からアセスメント1件を処理する

• トラブル事例と解決：つまずいた点10件

外部委託先のリスクをどう管理したいのか、をまず決める

委託先やSaaSベンダーが増えるほど、「この会社に任せて大丈夫か」を継続的に判断する必要が出てきます。台帳と質問票がバラバラに管理されていると、誰にいつ何を聞いたか、回答をどう評価したか、問題対応をどう進めたかを追いにくくなります。

読者が本来期待するのは、取引先の一覧・評価の実施記録・問題対応の履歴という3つが1か所でつながっている状態です。TPRMは、この3つを1つのアプリの中でつなぐ仕組みでした。

TPRMはGRCスイート全体を入れなくても単体で動く

TPRMは名前の通りGRC（Governance, Risk, Compliance）ファミリーの一部として配布されています。sys_remote_appの公式short_description（原文）はこうです。

（訳: 第三者との関わりに伴うリスクを特定・評価・管理するための、一元化されたプロセス）

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

TPRMとGRCの関係を1枚に整理すると、この形になります。

GRC（Governance, Risk, and Compliance）は、ポリシー管理・全社リスク管理・監査・第三者リスク管理といった「統制系アプリの家族」の総称です。TPRMはその中で「社外の取引先」を担当する1人で、家族共通の実家にあたるのがGRC: Profiles（sn_grc）という共通基盤です。GRCファミリーと聞くと、Audit・Policy & Compliance・Risk Managementまで一式必要だとイメージするかもしれません。実機ではそうではありませんでした。宣言された依存は6件です（sn_grc・sn_svdp・sn_comp_asmt・sn_vrm_ws・sn_grc_ftr_role・com.snc.grc_vrm_dep）。UI部品などの連鎖まで含めると、スコープは25件増えます。それでも、GRCの同族プラグインであるAudit・Policy & Compliance・Risk ManagementのDependenciesは、導入後も一貫してInactiveのままでした。つまり、GRCの全社導入を待たずにベンダーリスク管理だけを先行できる。これが読者の意思決定に効く実測です。

依存プラグインcom.snc.grc_vrm_depの公式description（v_plugin・原文）はこうです。

（訳: GRC Vendor Risk Managementアプリケーションをサポートするために必要な依存プラグインを、すべてインストールします）

引用元: /v_plugin_list.do?sysparm_query=id=com.snc.grc_vrm_dep

TPRMは、GRC共通基盤（Profiles）とアセスメント基盤だけを引き連れて動く設計です。全社的なリスク管理やコンプライアンス管理を導入する予定がなくても、ベンダーリスクの管理だけを先に始められます。プラグインの依存関係を導入前に調べる一般的な手順は、プラグイン（v_plugin/sys_plugins）の有効・無効と依存で扱いました。導入前後で実際に何が増減したかを数える手順は、プラグインを入れると何が変わる？ 影響調査でチェックする27か所にまとめています。

Third Party・Engagement・Assessmentの3層で成り立つ仕組み

TPRMが管理するデータは、大きく3層に分かれています。取引先そのものであるThird Party、その取引先との関わり方を表すEngagement、実際に送る評価であるAssessmentです。これに加えて、取引先の重要度をあらかじめ格付けするTiering（内部アセスメント）と、評価で問題が見つかったときに起票するIssueが付属します。

engagement.vendorフィールドの公式説明（sys_documentation・原文）はこうです。

（訳: このEngagementを所有する第三者）

引用元: /sys_documentation_list.do?sysparm_query=name=sn_vdr_risk_asmt_vendor_engagement^element=vendor

Third Partyが台帳の主役、Engagementが関わり方を記録する単位、Assessmentが実際に投げる質問票です。1社に複数のEngagement、1つのEngagementに複数のAssessmentが積み上がる構造になっています。

TieringとIssueも同じThird Partyにぶら下がる

Tieringは、Third Party自身の重要度を内部で格付けする仕組みです。重要度が高い取引先を頻繁に確認し、低い取引先は簡易確認で済ませる、という選別に使います。

Issueはtask.visible_in_vendor_portalフィールドの説明にある通り、第三者側にも見せられる形で問題を追跡するテーブルです。

（訳: このタスクを第三者向けポータルに表示するかどうかを示します）

引用元: /sys_documentation_list.do?sysparm_query=name=sn_vdr_risk_asmt_task^element=visible_in_vendor_portal

評価結果から自動生成されることもあれば、外部ポータル経由で第三者に見せながら是正を進めることもできます。検証用に起票したIssueの一覧を見ると、暗号化の未設定やMFA未導入といった指摘が、取引先とアセスメントに紐づいて並ぶ様子が分かります。

実機では78社・エンゲージメント0件から始まる

導入直後のTPRMは、業務データを一切持ちません。engagement・assessment・issue・taskはすべて0件でした。それでもワークスペースを開くと、いきなり数字が表示されます。

Total third parties欄の78という数字は、TPRM独自のテーブルの集計ではありません。会社マスタcore_companyのうち、vendor=trueが立っているレコードの件数でした（全177社中、manufacturer=trueは151件）。業務レコードが1件も無い状態でも、既存の会社マスタさえあれば78社が「Third Party候補」として見えるわけです。

ワークスペースはURL /now/vendor-management で開きます（sys_app_moduleのDIRECTリンクで実測）。ワークスペースと従来フォームのどちらを直せば画面が変わるかは、ServiceNowのワークスペースは従来のフォームと何が違う？が参考になります。

社内から開くメニューは、実はかなり絞り込まれています。有効なアプリケーションメニューは5件だけでした。

TPRM本体（sn_vdr_risk_asmt）が持つ独自メニューは1件だけです。残りはGRC共通（GRC User Hierarchy／GRC Administration／GRC Exceptions／GRC Confidential Records）でした。導入で連鎖した7スコープのうち、sn_svdp・sn_comp_asmt・sn_vrm_ws・sn_grc_ftr_role・sn_vendor_coreの5つは、独自のメニューを持ちません。

テーブルを持つのはsn_vdr_risk_asmt（62）とsn_grc（96）、sn_comp_asmt（3）だけです。画面（ポータルとワークスペース）とデータ（テーブル）は別スコープに分かれ、画面専用のスコープはデータを一切所有しません。

リスク評価が入ると、No dataだった2つのチャートが描画される

初期状態の確認で終わらせず、評価が入った後の姿も確かめました。検証用に15社へThird-party tierとRisk ratingを設定し、29件のエンゲージメントにも評価を入れています。リスクエリアはSecurityなど5種の設定を追加で有効化し、取引先別の評価を10件投入しました。同じワークスペースがこう変わります。

No data availableだった2つのチャートが、どちらも描画されました。左のRisk rating by third-party tiersは、重要度の列ごとに評価の内訳を棒で並べるチャートです。重要度が高い列に評価の悪い棒が立っていないかを最初に見ます。右のTop risk areasはリスクエリア別の平均スコアです。情報セキュリティやプライバシーといった分野のどこに問題が偏っているかを示します。

高リスクの取引先は、ヘッダーのバッジとRisk areasカードですぐ分かる

高リスクと判定された取引先を開くと、見た目がはっきり変わります。検証で高リスクに設定したMeridian Data Servicesの画面です。

ヘッダーに評価と重要度のバッジが並び、Risk areasカードがどの分野のリスクかを示します。左ナビのIssuesには是正対象が1件ぶら下がっています。リスクの発見から是正の進捗まで、この1画面から追える作りです。

重要度が高くても評価が良好なら、落ち着いた画面になる

対比のために、重要度は高いが評価は良好という取引先も見ておきます。

Third-party tierは2-High（重要な委託先）のまま、Risk ratingは4-Low（リスク小）です。重要度と評価が独立しているため、「重要だが健全」と「重要かつ危険」を区別できます。この区別を全取引先に対して機械的に維持できることが、台帳をExcelで持つ場合との差です。高リスク判定が出た後に誰が気づき、どう是正へつなぐかという運用は、運用設計の記事で扱っています。

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

Third Partyという概念に対応する独自テーブルは、TPRM側には存在しません。engagement.vendorフィールドが直接core_companyを参照する形で実装されています。core_companyはTPRM専用のテーブルではなく、ServiceNow全体で会社情報を持つ共通テーブルです。会社・部署・原価がどう分かれているかは、組織テーブル：会社・部署・原価の3枚（core_company）で扱った構造が前提になります。

連絡先（担当者）だけは事情が異なります。vm_vdr_contactというテーブルが使われていますが、TPRMのスコープ（sn_vdr_risk_asmt）ではなくglobalスコープに存在します。sys_userを継承した、旧Vendor Management時代の遺構です。新しいTPRMアプリが、連絡先だけ古いグローバルテーブルを流用しています。

Globalスコープとxで始まるScopedアプリの違いを理解しておくと、この断層の意味がつかみやすくなります。詳しくはアプリとスコープ：Globalとx_の違い（sys_app）で扱いました。

外部の第三者からはどう見えるのか、2つの経路がある

TPRMを内部の管理画面として見ているだけでは、この製品の半分しか理解できません。評価対象である第三者自身も、ServiceNowにログインして質問票に答える必要があるからです。実機で確認すると、外部向けの経路は2系統存在していました。

1つはService Portal「Third Party Portal - Scoped」（url_suffix=svdp）です。sp_portalの実測で確認しました。もう1つはUXワークスペース「GRC: Third Party External Workspace」（landing_path=smart-asmt）です。社内メニューからのリンクは無く、マウントパスも実機では特定できませんでした。

Service Portalの構成を理解しておくと、なぜ外部専用の別ポータルがここまで簡単に用意できるのかが分かります。ServiceNow Service Portalはどこを直せば画面が変わる？で扱った7テーブル構成の応用です。

管理者が/svdpを開くと「third partiesのための画面」と拒否される

管理者アカウントで/svdpを実際に開くと、次のメッセージが表示されました。

（訳: このページは第三者のみが使用できます）

社内の管理者アカウントであっても、このポータルの中身には入れません。外部専用の経路として、アクセス制御が明確に分離されている実例です。

この画面を本来開くのは、社内の管理者ではなく取引先の担当者（vm_vdr_contact）です。担当者レコードを作成すると、snc_external・sn_smart_asmt.actor・vendor_contact・sn_vdr_risk_asmt.external_assessment_responderの4ロールが自動で付与されます（実測）。この組み合わせが「外部の回答者」の正体です。実際にこの担当者としてログインすると、同じ/svdpが正常に表示されます。

見えるのは自社の情報だけです。My companyには自分の会社、Engagementsには自社の1件だけが並び、他の取引先の情報は一切表示されません。管理者を拒否し、担当者には自社スコープだけを見せる。この2枚が、外部ポータルのアクセス設計の全体像です。

回答URLはアサインされた本人以外「認可されていません」

Assessmentを1件、Draftから第三者への送付（Submitted to third party）まで進めると、回答用のURL（/assessment_take2.do）が自動生成されます。このURLを、割り当てられた担当者ではない管理者アカウントで開くとどうなるかを確認しました。

（訳: この第三者リスクアセスメントに回答する権限がありません）

回答画面は、アサインされた本人以外には開放されません。URLさえ知られれば誰でも回答できる作りにはなっておらず、担当者単位で認可を絞っています。

割り当てられた本人でログインし直すと、同じURLで質問票が開きます。

質問票「Basic」の中身は、ベンダーとの関係の戦略性、顧客データ・PII・PCIの取扱、FISMAやGDPRなどのコンプライアンス影響という構成でした。名前は「Basic」でも、第三者リスクの定番論点をひととおり押さえた11問です。

7つのロールはadmin・managerを頂点に、assessor/reviewer/responderへ枝分かれする

TPRM独自のロールは7件です。継承構造はadmin → manager → assessor/reviewerの3段になっています。

vendor_risk_adminの公式description（原文）はこうです。

（訳: Vendor Risk Administratorロールは、Vendor Risk Managementの全データに全権限を持ちます。Assessment Metric Typeについても全権限を持ちます）

引用元: /sys_user_role_list.do?sysparm_query=name=sn_vdr_risk_asmt.vendor_risk_admin

vendor_risk_managerの公式description（原文）はこうです。

（訳: 第三者・第三者の連絡先・第三者アセスメントテンプレート・質問票テンプレート・文書依頼テンプレート・スケジュール済みアセスメントを管理します）

引用元: /sys_user_role_list.do?sysparm_query=name=sn_vdr_risk_asmt.vendor_risk_manager

興味深いのはapproverロールです。直接紐づくACLは0件で、承認の実務権限は継承した他のロール側に委譲されています。external_assessment_responder（外部回答者）は直接ACLこそ1件です。しかし継承しているsn_smart_asmt.actorロールに106件のACLが紐づき、外部アクセスを実質支えているのはこちらでした。ロールの見え方を整理する考え方は、ServiceNowの権限は誰が持っている？がそのまま当てはまります。

リスクを測る仕組みはTiering・重み・スケールの3つの設定で決まる

Assessmentの結果からリスクをどう数値化するかは、Tieringのスケール、リスクエリアの重み、評価スケールという3つの設定の組み合わせで決まります。導入直後の初期値を見ると、TPRMは最初から多面評価が動く設計ではありませんでした。

総合スコアは4要素（Engagements／Subsidiaries／Risk intelligence rating／Third-party Risk Assessments）で構成されます。重みが入っているのはThird-party Risk Assessmentsだけ（値100）で、残り3つは0です。導入直後は、総合スコアが外部アセスメントの結果だけで決まります。

リスクエリアは12定義中1件しか有効化されていない

リスクエリア（risk_area_definition）は12件定義されていますが、weight>0で実際に使われているのはDefault（weight=100）の1件だけでした。

財務・情報セキュリティなど12種類の切り口がありますが、初期状態は単一スコア扱いです。細かく評価したい場合は、導入後に重み配分を設定する作業が要ります。

RatingとTierは高得点の意味が逆

どちらも同じ5バンド（0-19／20-39／40-59／60-79／80-100）ですが、80-100の意味が正反対です。

Rating Scale（def_rating_scale）は得点が高いほど安全（Very Low risk）を意味します。Tier Scale（def_tier_scale）は得点が高いほど重要（Very High tier）を意味します。並べて見比べないと、この逆転には気づけません。

Smart Assessment Engineは一度onにすると元に戻せない

質問票への回答方式には、従来型のAssessment Engineと、新しいSmart Assessment Engine（SAE）の2種類があります。切り替えはsn_vdr_risk_asmt.sae_enabledというプロパティで行いますが、公式説明には重要な注意書きがありました。

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

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

導入直後の値はfalse（従来型）でした。設定値の置き場所を一覧で把握しておく一般的な方法は、システムプロパティ（sys_properties）は設定値の置き場で扱った通りです。片道スイッチである以上、SAEへの切り替えは検証環境で十分に試してから本番に適用すべき設定だと分かります。

実機で気づいたこと

Assessment Templateが0件だと、送るものが無い

質問票テンプレート（asmt_metric_type）は5件（ESG／Fourth-party registration／Privacy／Sample／Basic）が最初からactiveでした。一方でAssessment Template（sn_vdr_risk_asmt_template）は0件です。管理者がAssessment Templateを組み立てるまで、1件のAssessmentも作成できません。素材（質問票）と実行単位（テンプレート）が分かれていて、後者は導入時点では空という構成です。

Closedまで進めてもrisk_ratingは空のままだった

Basic質問票（11問）でAssessmentを1件、DraftからClosedまで実際に完走させました。回答は良好側で揃え、イシューは自動生成されていません。状態はDraft→Submitted→Responses received→Generating observations→Finalizing→Closedと正常に進みました。

ところがrisk_rating（総合リスク評価）とcomputed_risk_ratingは、Closedになった後もずっと空のままでした。

実務では何に使えるか

導入したら最初にAssessment Templateを最低1件作る

TPRMを導入しただけでは、質問票テンプレートが揃っていても1件のAssessmentも送れません。最初の作業は、既存の質問票テンプレート（Basic等）を紐付けたAssessment Templateを1件作ることです。あわせてRating Scaleとの対応も確認しておくと、前述の「スコアが空のまま」という事態を避けられます。

最初に評価するのはTieringで重要度が高い取引先に絞る

78社全部にいきなり質問票を送ると、負荷が現場にのしかかります。まずTieringで格付けし、重要度が高い取引先から評価を始めるのが現実的です。リスクエリアの重みも、最初はDefaultの単一スコアで始め、必要になった段階で調整するほうが無理がありません。

用語

TPRM（Third-party Risk Management）：第三者（取引先・委託先・SaaSベンダー）のリスクを評価・追跡する仕組み。プラグインはsn_vdr_risk_asmt。旧称Vendor Risk Management。

Third Party：TPRM上の取引先。独自テーブルを持たず、core_companyのvendor=trueレコードを指す。

Engagement（sn_vdr_risk_asmt_vendor_engagement）：Third Partyとの関わり方を表す独立テーブル。

Assessment（sn_vdr_risk_asmt_assessment）：Engagementに対して実施する質問票評価。planned_taskを継承する。

Tiering（Internal Assessment）：Third Party自身の重要度を内部で格付けする評価。

Issue（sn_vdr_risk_asmt_issue）：評価で見つかった問題を追跡するレコード。sn_grc_issueを継承する。

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

自分のインスタンス名に続けて開きます（TPRMプラグインの導入が前提です）。

• Vendor Management Workspace：/now/vendor-management

• Third Party一覧（core_company側から）：/core_company_list.do?sysparm_query=vendor=true

• リスクエリア定義：/sn_vdr_risk_asmt_risk_area_definition_list.do

• Rating Scale（評価）：/sn_vdr_risk_asmt_def_rating_scale_list.do?sysparm_query=ORDERBYorder

• Tier Scale（重要度）：/sn_vdr_risk_asmt_def_tier_scale_list.do?sysparm_query=ORDERBYorder

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

この記事で引用した説明文は、ServiceNowが製品に同梱しているアプリ・プラグイン・フィールド・ロール・プロパティのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述が表示されます。

• アプリの公式説明（引用元）：/sys_store_app_list.do?sysparm_query=scope=sn_vdr_risk_asmt

• プラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=id=com.snc.grc_vrm_dep

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINsn_vdr_risk_asmt_vendor_engagement,sn_vdr_risk_asmt_task^hintISNOTEMPTY

• ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameSTARTSWITHsn_vdr_risk_asmt.

• プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameSTARTSWITHsn_vdr_risk_asmt.^descriptionISNOTEMPTY

検証範囲とおことわり

Australia PDI（OOTB）にTPRM（sn_vdr_risk_asmt 22.3.3）を導入し確認しました。デモデータは付属しません（no_demo_data）。

Assessmentを1件、DraftからClosedまで実際に完走させ、状態遷移と外部URLの認可を確認しています。送信メールは実際には送られていません（PDIのSMTPは無効）。risk_ratingが空のままだった原因は推測で、確定していません。sn_tprm_genai（Now Assist for TPRM）・sn_ai_irm_fdn・sn_itsm_vendorの3スコープはblock_install=trueのため未検証です。SAEは一度onにすると元に戻せないため、今回はfalse（既定）のまま検証しました。GRC Confidential Recordsはinactiveのため未確認です。

関連記事

• アプリとスコープ：Globalとx_の違い（sys_app） — Third PartyがなぜCore_companyというglobalテーブルを直接参照するのかの前提知識

• 組織テーブル：会社・部署・原価の3枚（core_company） — Third Partyの実体であるcore_companyの構造を掘り下げる

• ServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表からたどる — 7ロールを実際に割り当てるときの実務編