TPRMとほかモジュールの連携（core_company・ITSMベンダー管理との棲み分け）

すでにIncidentやChangeで取引先情報をcore_companyに登録し、日々の運用に使っている会社は少なくありません。そこにTPRM（Third-party Risk Management）を追加すると、ベンダー情報を二重管理することになるのではと身構えます。結論は逆で、TPRMは新しいベンダーマスタを作らず既存のcore_companyをそのまま参照する設計です。導入直後にワークスペースが見せる「Total third parties: 78」も、core_companyのvendorフラグが立った会社数そのものでした。Australia PDIで参照関係を実機でたどります。なお比較相手のITSM側（Vendor Manager Workspace）はblock_install=trueでPDIに導入できないため、この記事で言えるのはテーブル設計上の接点までです。その範囲を先に断ったうえで、この記事だけの発見を3つ持ち帰ってもらいます。

• 「Vendor Manager Workspace」と「Vendor Management Workspace」という紛らわしい2つの画面名が実在する

• ベンダーを登録してもsn_grc_profileは自動生成されない（他GRCアプリ連携には手作業が要る）

• 指摘事項（Issue）はTPRM専用ではなく、GRC共通のsn_grc_issueを継承している

既存のベンダー管理とTPRMは別のマスタになるのかという不安

core_companyにベンダーを登録し、CMDBの契約情報やIncidentの起票元と紐づけて運用してきた環境に、TPRMを追加するとどうなるか。たとえば、CMDBの契約管理者や請求先住所、過去のIncidentの起票履歴がすでに紐づいている取引先があったとします。TPRMを入れた瞬間にこの取引先の情報が別のテーブルへ複製され、CMDB側を更新してもTPRM側に反映されなくなるようだと、運用は一気に複雑になります。読者が本当に知りたいのは「もう一度入力し直す作業が発生するのか」、つまり両者が同じレコードを見ているのか、見た目が似ているだけの別物なのかという一点です。マスタが二重化すれば、どちらが正なのか常に気にしながら運用することになります。

TPRMはマスタ管理ツールではなく、GRCスイートに属する評価プロセス

TPRMという名前だけを見ると、独立したベンダー管理システムのように思えます。しかし実態は、GRC（Governance, Risk, Compliance）スイートに属する評価プロセスのアプリケーションです。GRCはポリシー・全社リスク・監査・第三者リスクを束ねる統制系アプリの総称で、TPRMは共通基盤（GRC: Profiles）の上に乗る「第三者リスク」担当という位置づけになります。取引先に「評価する」「指摘事項を追跡する」「是正させる」というワークフローを追加するのが役割で、会社情報そのものの管理は対象外です。具体的には取引先ごとにエンゲージメントを起票し、アセスメントで評価を実施し、指摘事項をIssueとして追跡した上で、是正完了まで状態を追いかける流れを提供します。この流れ全体を通じて、TPRMが必要とするのはcore_companyという既存の実体への参照だけです。プラグイン有効・無効と依存関係の基本で見た「共通基盤の上に乗る」構造がここでも繰り返されています。

名前がほぼ同じ「ITSM側」のワークスペースが存在する

読者の不安には根拠があります。ITSM側にはsn_itsm_vendorという別のリモートアプリが存在し、その名前は「Vendor Manager Workspace」でした。TPRM導入後にアプリメニューへ現れる自分のワークスペースの節タイトルは「Vendor Management Workspace」です。ManagerとManagementという紛らわしい綴り違いで、同じ「ベンダー」を扱う画面が2つ存在します。sn_itsm_vendorはblock_installがtrueのためPDIには導入できず共存の実態は確認できませんが、名前だけでも混同しやすい事実は実機のメニュー構成から確認できました。

連携相手は5つ。関係のかたちは参照・継承・委譲の3種類に分かれる

本題に入る前に、TPRMがどのモジュールとどうつながるのかを1枚にまとめます。

図の色は関係の種類を表します。濃紺が主役のTPRM、緑が実際に処理を受け持つ連携先（GRC基盤・Assessment Engine・外部ポータル）です。青は参照する既存マスタ、紫は旧世代のテーブルを表します。赤はPDIに導入できないITSM側、灰色は自動では動かないものです。点線は「つながっていない」ことを示す線で、この記事の主題である「棲み分け」はこの2本の点線に表れています。

同じ内容を、何を共有して何を共有しないのかという観点で表にすると次のとおりです。

core_companyを直接参照する設計は何をもたらすのか

TPRMの中核テーブルをsys_dictionaryで洗い出すと、ベンダーを指すvendorフィールドはすべてcore_companyを参照していました。独自のベンダーマスタテーブルを1つも持っていません。 導入した瞬間からcore_companyの177社ぶんのデータがそのままTPRMの母数になり、ベンダー一覧を作り直す作業は発生しません。

その裏付けが、/now/vendor-managementを開いた瞬間に表示される数字です。

Total third parties: 78という数字は、TPRMの業務レコードが1件も無い状態でいきなり表示されます。正体はcore_companyのvendor=trueが立っている会社数でした（全177社中）。マスタを共有する設計が、導入直後の1画面で現れていました。

マスタ共有の実像は、1社の詳細画面を開くとさらにはっきりします。

Vendor type（Software）やVendor managerは、TPRM導入前からcore_companyにあった既存のフィールドです。その同じレコードの上に、TPRMが追加したRisk ratingとThird-party tierのバッジが並びます。会社の基本情報は既存資産のまま、リスク評価の属性だけがTPRMのフィールドとして追加される。棲み分けが1画面に同居して見える構図です。

5つの中核テーブルはそれぞれ何を参照しているか

テーブル定義を1つずつ確認する手法は、CIMプラグイン導入手順やPPMの影響調査でも使ったやり方です。sn_vdr_risk_asmtスコープの中核テーブルは、参照先が2種類に分かれていました。

Engagement・Assessmentはどちらもvendorフィールドでcore_companyを直接指します。engagement.vendorの公式説明（原文）です。

（訳: このエンゲージメントを所有する第三者）

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

「Third party」という語が使われており、TPRMの世界ではcore_companyのレコードそのものが「取引先」の実体として扱われていると分かります。

「4th party」という考え方もcore_companyの中で完結する

sn_vdr_risk_asmt_m2m_upstream_downstreamというテーブルも見つかりました。upstream・downstreamという2フィールドの参照先はどちらもcore_companyです。委託先の再委託先という連鎖を表す多対多テーブルだと読み取れます。業界でいう「4th party」もcore_company同士をつなぐだけで表現していました。この設計が便利なのは、同じ会社が複数の役割を同時に持てる点です。ある取引先Aは自社から見れば直接のベンダーですが、別のエンゲージメントでは取引先Bの再委託先として登場することもあります。core_companyが唯一のマスタである以上、Aのレコードを複製せずどちらの関係も表現できます。

連絡先だけは別世代のテーブルが使われている

ここまではcore_companyへの一本化が徹底していましたが、1か所だけ例外がありました。担当者の連絡先です。sn_vdr_risk_asmt_issueのvendor_contactフィールドの参照先はcore_companyではなく、vm_vdr_contactというglobalスコープのテーブルでした。連絡先だけはsys_userを継承した古いテーブルを流用しています。

実際にベンダー担当者を1件作成すると、この設計の癖がすぐ表れます。

担当者を14社ぶん登録した状態の一覧がこちらで、vm_vdr_contactはこのように取引先の窓口を1人1行で持ちます。

担当者「Alex Rivera」を作成しただけで、registration_statusフィールドが自動的にsentへ遷移しました。PDIはSMTP無効で実際のメールは飛びませんが、保存した時点で「招待メールを送った」状態に自動で進む作りです。

なぜ連絡先だけ新しいテーブルにならなかったのか

これは実機の構造から読み取れる推測です。vm_vdr_contactのvm_は、TPRMより前から存在していた旧世代のVendor Managementの名残だと考えられます。連絡先には「ログインできる人物」の性質が求められるため、既存のユーザー系テーブルを流用したのではと考えられます。会社という「モノ」はcore_company、人という「ヒト」はsys_user系という役割分担です。対象物そのものを表すテーブルと、それを操作・応答する人を表すテーブルを分けておくと、片方の仕様を変更しても、もう片方への影響を抑えやすいという利点があるはずです。

TPRM本体の管理者ロールvendor_risk_managerの公式説明（原文）にも、この線引きが表れていました。

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

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

「third parties」と「third-party contacts」が、公式の説明文でも別の対象として並べて書かれています。会社と連絡先が別の管理対象だという設計思想は、テーブル構造だけでなくロールの説明文にも一貫していました。

Issueだけ別の系統から生まれている

sn_vdr_risk_asmt_issue（指摘事項）を継承関係で見ると、Engagement・Assessmentとは出自が違います。継承しているのはplanned_taskでなく、sn_grc_issueという共通のGRC基盤テーブルでした。指摘事項の骨格はTPRM専用に作られたものでなく、GRCスイート全体で共有される基盤の上に乗っています。検証用に8件のIssueを起票した一覧がこちらで、暗号化やアクセスレビューといった指摘が取引先とアセスメントに紐づいて並びます。

GRC Profileはベンダーを登録しても自動生成されない

GRCスイートには、レコードをどのワークスペースに表示するかを決めるsn_grc_profileという仕組みがあります。functional_domainフィールドの公式説明（原文）です。

（訳: このレコードと関連レコードを機能ドメインに配置すると、適切なワークスペースに表示されるようになります。……）

引用元: /sys_documentation_list.do?sysparm_query=name=sn_grc_profile^element=functional_domain

GRCスイートの他アプリと連携させるならsn_grc_profileが接点になるはずです。ところがcore_companyにベンダーを1件登録しただけでは、対応するsn_grc_profileは自動生成されませんでした。アセスメントを完走させたあとでも0件のままです。TPRM単体のサイクルには支障がありませんが、Risk ManagementやAuditなど他のGRCアプリからベンダーを横断的に見たい場合は、Profileを別途作成する作業が要ります。実務では、TPRM単体で評価サイクルを回している間は気づきにくい制約です。ある日セキュリティ部門から「このベンダーはRisk Managementの登録リスクとも紐づけて見たい」と要望が出た瞬間、Profileが存在しないという事実に直面します。導入直後の設定作業に、Profile作成の要否を確認する項目を1つ加えておくと後戻りが少なくて済みます。

ITSM側のVendor Manager Workspaceと同居させたらどうなるか

冒頭で触れたsn_itsm_vendorはblock_installがtrueで、このPDIには導入できません。両方を有効化した場合の挙動は検証範囲外です。言えるのはテーブル設計上の接点だけです。TPRMがcore_companyを直接参照する以上、sn_itsm_vendor側も同じ参照先にしていれば会社マスタのレベルでは競合しない可能性があります。逆に独自のベンダーテーブルを持っていた場合は、core_companyとは別の「ベンダーの顔」が生まれ、冒頭の不安がITSM側との間で再燃します。断定はできません。すでにITSM側のVendor Manager Workspaceを本番で使っている読者もいるはずです。TPRMを検証環境に試験導入する前に、契約管理者や更新履歴といった項目の置き場を確認しておくとよいでしょう。それがcore_company側にあるのかsn_itsm_vendor固有のテーブルにあるのかを先に把握しておくと、あとで参照先の食い違いに気づきやすくなります。

プラグイン導入の影響調査でチェックする27か所と同じやり方で、テーブル・ロール・ACLの重複を先に洗い出しておくと安全です。

外部の取引先はどこから入るのか

TPRMには、社内の管理者が使う/now/vendor-managementとは別に、取引先自身が使う外部向けの専用経路が用意されています。sp_portalには「Third Party Portal - Scoped」というポータルがあり、URLの末尾はsvdpでした。

管理者権限のまま/svdpを開くと、「This page is only for third parties to use.」（このページは第三者専用です）と表示され、アクセスを拒否されました。管理者向け画面と取引先向けの画面が明確に分離されている証拠です。質問票への回答リンクも同様で、本人以外がアクセスすると認可エラーになります。

一方、取引先の担当者アカウントでログインすると、同じ/svdpが正常に表示されます。見えるのは自社のエンゲージメントと自分のアセスメントだけで、core_companyの一覧のような社内マスタには触れられません。

実務ではcore_companyとTPRMをどう役割分担して運用するか

ここまでの参照関係を踏まえると、運用の役割分担は次のように整理できます。推測を含む設計提案として読んでください。

• 会社の実在・基本情報はcore_company側で一元管理する。担当は購買・調達やCMDB管理のチームで、TPRMを入れても変える必要はありません

• リスク評価・指摘事項・是正計画はTPRM側で管理する。担当は情報セキュリティやコンプライアンスのチームで、必要なのは会社レコードを選ぶことだけです

• 連絡先の登録は評価担当者が都度作成する運用になりやすい。globalスコープである以上、vendor_risk_managerロールの範囲で閉じておくことをおすすめします

• GRC Profileの作成要否は、他のGRCアプリを使う計画があるかで判断する。TPRM単体運用なら不要ですが、Risk ManagementやAuditと連携する予定があるなら早めに作成しておくと手戻りが減ります

vendorフラグを立てる作業は、IT資産の調達プロセスと近い場所で発生しがちです。IT資産管理の運用設計書の調達から廃棄までの流れと、TPRMのベンダーライフサイクルは、同じcore_companyを起点にする別目的の流れだと捉えると整理しやすくなります。

アセスメントをDraftからClosedまで動かしてみると、役割分担が画面上の数字にも表れます。

テスト用取引先「Meridian Data Services」をcore_companyにvendor=trueで追加すると、Total third partiesは78から79に変わりました。エンゲージメントを1件作成すると、Total engagementsも0から1になります。業務レコードを1件作るにはcore_company側にレコードが要ります。この順序は逆にできません。先にTPRM側でエンゲージメントの器だけを作り、あとから会社情報を紐づけるという運用は想定されていないはずです。評価を始める前に、対象の取引先がcore_companyに存在するかどうかを必ず確認する手順が要ります。

実機で気づいたこと

「Vendor Manager Workspace」と「Vendor Management Workspace」という、1文字違いの2つの画面名が実機のメニューに存在していました。 前者はITSM側のsn_itsm_vendor、後者はTPRM自身のワークスペースです。「どっちで管理するのか」という疑問は、機能の重複だけでなく名前の近さそのものが原因になっている可能性があります。

担当者を1件作成しただけでregistration_statusがsentに自動遷移したのは想定外でした。 本番環境では、保存した瞬間に招待メールの送信まで走る可能性が高い挙動です（SMTP無効のPDIでは状態遷移だけを確認しました）。テスト目的で担当者を作成する場合、実在するメールアドレスを入力しないよう注意が必要です。

GRC Profileが自動生成されないという事実は、公式のヒント文だけでは気づけませんでした。 functional_domainの説明はいかにも「配置すれば連携する」ように読めますが、ベンダーを登録しただけでは何も起きません。ドキュメントの説明と実機の自動化は別物だと再認識させられました。

TPRM自体はデモデータを1件も持ち込みませんでした（demo_data: no_demo_data）。 それでもワークスペースを開いた瞬間に78という数字が出てくるのは、core_companyという既存の資産の上に乗っているからです。空のはずのアプリが最初から「使える」ように見えるのは、参照先にすでにデータがあるからだと気づいて、少し安心しました。

用語

• core_company … 会社情報を一元管理するテーブル。vendor等のフラグで種別を判別する

• TPRM（Third-party Risk Management） … 取引先のリスクを評価・管理するGRCスイートのアプリ。旧称Vendor Risk Management

• vm_vdr_contact … globalスコープの連絡先テーブル。sys_userを継承し、TPRMが流用している

• sn_grc_issue … GRCスイート共通の指摘事項テーブル。sn_vdr_risk_asmt_issueはこれを継承する

• sn_grc_profile … レコードをどのGRCワークスペースに表示するか決める仕組み。ベンダー作成時には自動生成されない

• sn_itsm_vendor … ITSM側のVendor Manager Workspace。block_installがtrueでPDIには導入できない

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

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

• Vendor Management Workspace（TPRM側）：/now/vendor-management

• 中核テーブルの参照フィールド一覧：/sys_dictionary_list.do?sysparm_query=nameINsn_vdr_risk_asmt_vendor_engagement,sn_vdr_risk_asmt_assessment,sn_vdr_risk_asmt_issue,sn_vdr_risk_asmt_m2m_upstream_downstream^internal_type=reference^ORDERBYname

• vm_vdr_contactの一覧：/vm_vdr_contact_list.do

• GRC Profileの一覧：/sn_grc_profile_list.do

• Third Party Portal（外部向け）：/svdp

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

引用した説明文はServiceNow製品同梱のドキュメントです。次のURLで同じ記述を確認できます。

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

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

検証範囲とおことわり

Australia PDIに、OOTBの状態からTPRM（sn_vdr_risk_asmt v22.3.3）を導入して確認しました。2026-08-22時点のこの環境のものです。

この記事の参照関係の確認で主に使ったのは、このうちMeridian Data Services（取引先1社・担当者1名・エンゲージメント1件・完走済みアセスメント）です。

確認していない範囲は次のとおりです。

• sn_itsm_vendorを実際に導入し、TPRMと同居させた場合の挙動（block_install=trueで導入不可）

• 本番環境でのメール送信・招待フロー（PDIはSMTP無効のため未確認）

• sn_grc_profileを手動作成した場合、他のGRCアプリからベンダーがどう見えるか

• vm_vdr_contactに紐づく取引先の担当者として実際にログインした場合の画面の見え方（今回は管理者権限での確認にとどまる）

• core_companyのACLがTPRM側の参照読み取りにどう及ぶかの実機検証（権限設定を変えての確認はしていない）

関連記事

• 前提知識：組織テーブル：会社・部署・原価の3枚（core_company） … TPRMが参照するcore_companyのテーブル構成を扱っています

• 同じシリーズの導入手順：TPRM（Vendor Risk Management）プラグインのインストール手順 … 「Total third parties 78」の内訳と依存プラグインの連鎖

• 実務編：taskテーブル：ITSM全プロセスの共通の親 … Assessmentが継承するplanned_taskの考え方の前提になります