TPRM（Vendor Risk Management）の開発設計（実機から見る設計思想）
ServiceNowのThird-party Risk Management（TPRM）を自社へ導入・拡張するとき、最初に必要になるのは開発設計書です。ところが公式ドキュメントは機能の説明が中心で、「設計書の章立てに沿って何をどう決めるか」という形にはなっていません。本書は、Australia PDIへ実際に導入したTPRMの実装を根拠に、標準実装を設計書として書き起こしたものです。章立ては一般的な開発設計書の目次構成（システム概要・機能設計・画面設計・テーブル設計・ステータス設計・自動化設計・セキュリティ設計・パラメータ設計）に合わせました。章立てごと流用して、自社版の設計書の雛形にしてください。
検証環境：Australia PDI / OOTB / 2026-08-22 確認。TPRM（sn_vdr_risk_asmt v22.3.3）を導入した直後の実測に基づく
1. はじめに
1.1 本書の目的と位置づけ
本書は、TPRMの標準実装を「設計済みの成果物」として読み、そのまま自社の開発設計書の雛形に流用できる形へ整理することを目的とします。各章は、一般的な開発設計書の章立てに合わせています。各節の書き方は「設計方針を先に述べ、その根拠となる実測を添える」で統一しました。自社版を作るときは、方針文を自社の決定に置き換え、根拠を自社環境の確認結果に差し替えれば、そのまま設計書として成立します。
なお本書は技術寄りの設計書です。誰がどう回すかという体制側は、運用設計の記事で扱います。同じ型で書いた前例としてServiceNowのContinual Improvement Management（CIM）の開発設計書があります。
1.2 対象範囲
対象は、TPRM本体（sn_vdr_risk_asmt）と、導入時に連鎖する依存スコープ（sn_grc／sn_svdp／sn_comp_asmt／sn_vrm_ws／sn_grc_ftr_roleほか）が構成するアプリケーション一式です。次は対象範囲に含めません。
Smart Assessment Engine（sae_enabled=true）を有効化した場合の設計（既定のClassic方式を対象とする）
Now Assist for Third-Party Risk Management（sn_tprm_genai。block_install=trueのためPDIでは検証不可）
Audit・Policy & Compliance・Risk Managementなど他GRCアプリを併用した場合の設計
1.3 前提条件と制約
本書の根拠はAustralia PDI（OOTB）へ2026-08-22に導入した実測です。TPRMはServiceNow Store配布のアプリケーションであり、Update Setでは移送できないため、環境ごとに導入して版を揃える前提で設計します。デモデータは付属しない（no_demo_data）ため、記載する初期件数はすべて「導入しただけの状態」の値です。導入前後の差分（テーブル+363・フィールド+5,170・スコープ+25など）の数え方は、ServiceNowでプラグインを入れると何が変わる？ 影響調査でチェックする27か所の方法に従います。
1.4 用語定義
third party（取引先） … リスク評価の対象になる会社。TPRM独自のマスタを持たず、既存の会社テーブルの1レコードとして表現する
engagement（エンゲージメント） … 特定の取引先との具体的な契約・業務内容の単位。本文では「エンゲージメント」で統一する
assessment（アセスメント） … 取引先に対して実施する評価。内部評価（Tiering）と外部評価の2系統がある
questionnaire template（質問票テンプレート） … アセスメントで使う質問セットの定義（asmt_metric_type）
assessment template … 質問票と実施条件を束ね、実際に発行する単位（sn_vdr_risk_asmt_template）
third-party contact（取引先の担当者） … 取引先側でアセスメントに回答する人物（vm_vdr_contact）
issue（イシュー） … アセスメントの結果や監査で見つかった是正対象。本文では「イシュー」で統一する
2. システム概要
2.1 全体構成
TPRMは「データを持つスコープ」と「画面を提供するスコープ」を分離した構成とします。標準実装では、テーブルを所有するのはsn_vdr_risk_asmt（62テーブル）と共通基盤のsn_grc（96テーブル）、補助のsn_comp_asmt（3テーブル）に限られ、外部ポータル（sn_svdp）・ワークスペース（sn_vrm_ws）・sn_vendor_coreはテーブルを1つも所有しない表示専用スコープです。分け方は明快です。
図の色はスコープの役割を表します。濃紺がデータを持つ中核スコープ、緑が共通基盤として使われるGRC側のスコープ、灰色がテーブルを持たない表示専用スコープです。水色は既存マスタへの参照、紫はglobalスコープに残る別系統の実装を示します。
取引先マスタは新設せず、既存のcore_companyを直接参照する構成とします。会社としての基本属性（住所・業種・親子関係）は既存資産に乗せ、TPRM側はリスク階層や評価結果といった評価固有の情報だけを自分のテーブルに持ちます。会社情報の持ち方は組織テーブル：会社・部署・原価の3枚（core_company）の構造が前提です。
2.2 方式設計
TPRMとGRCファミリーの関係は次のとおりです。TPRMはGRCファミリーの一員として共通基盤（GRC: Profiles）に乗ります。同族のPolicy & Compliance・Risk Management・Auditは有効化しないまま、単体で成立します。
アプリケーション方式は、次の3点を採用します。
GRC共通基盤への搭乗：プロファイル・イシュー管理はsn_grc（GRC: Profiles）を共通基盤とし、TPRM専用に再実装しない。依存を束ねるプラグインの公式説明（v_plugin・原文）は次のとおり。引用元: /v_plugin_list.do?sysparm_query=id=com.snc.grc_vrm_dep
Installs all the dependent plugins required to support the GRC Vendor Risk Management application.
（訳: GRC Vendor Risk Managementアプリケーションの動作に必要な依存プラグイン一式をまとめて導入します）
共通Assessment Engineへの委譲：質問票の配布・回答はServiceNow共通のAssessment Engine（asmt_assessment_instance）に委譲し、回答テーブルを自作しない
単体導入の成立：同族のAudit・Policy & Compliance・Risk ManagementのDependenciesは導入後もInactiveのまま。TPRM単体で完結する導入を設計の前提にできる
アプリの目的は、公式の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 に行が移ります）
注目は動詞です。「特定（identify）」「評価（assess）」「管理（manage）」の3つが並びます。台帳と業務プロセスを1つのアプリに持たせる方針が、この一文に表れています。
3. 機能設計
3.1 機能一覧
TPRMが提供する機能は、次の6系統で構成されます。
取引先管理：core_companyのvendorフラグを母数に取引先を一覧・管理する。導入直後の「Total third parties: 78」は、会社マスタでvendor=trueが立つ78社（全177社中）をそのまま数えた値
エンゲージメント管理：取引先ごとの契約・業務内容をsn_vdr_risk_asmt_vendor_engagementで管理する
内部評価（Tiering）：取引先の重要度を格付けし、評価の頻度と深さを決める
外部評価（External assessment）：質問票を取引先担当者へ発行し、回答を回収・評価する
是正管理（Issue／Task）：評価で見つかった指摘を追跡し、是正完了まで管理する
外部ポータル：取引先自身が回答に使う専用画面（社内画面とは分離）
メニュー構成もこの6系統に沿っています。業務系（Third Parties〜Issues/Tasks）が前半。設定系（Assessment Setup・Tiering Setup・Scoring Setup・Administration）が後半という並びです。ガイド付きセットアップ（Guided Setup）はTPRM向けには用意されていません。そのため、設定系メニューの並びを初期設定の順路として扱う設計とします。
購入すると何が手に入るか
有料エリアには、3.2以降の機能設計と、4章から12章までの設計内容が入っています。そのまま仕事に使える成果物は次の3つです。
開発設計書の章立てそのもの（3.2 取引先・担当者 → 3.3 エンゲージメント・アセスメント → 3.4 イシュー → 4 画面 → 5 テーブル → 6 状態 → 7 自動化 → 8 外部インターフェース → 9 セキュリティ → 10 パラメータ → 11 制約と変更禁止 → 12 設計判断チェックリスト）。見出しを自社名に差し替えれば設計書の骨格になります
設計判断表（11論点） … ベンダー情報の持ち方から不可逆設定の扱いまで、TPRMの実装と踏襲/変更の指針を1枚にまとめた表
テーブル設計を確かめるときのチェックリスト（9項目） … TPRM以外のServiceNowアプリケーションでも使い回せる、設計意図を把握するための確認表
分量は本文の約7割です。すべてAustralia PDIの実測とUI Action・Business Ruleの実装確認に基づいています。
💰 ここから先は有料エリア
