メインコンテンツへスキップ
見出し画像

TPRMのトラブル事例と解決


    TPRM(Third-party Risk Management)をAustralia PDIに導入し、ベンダー登録からアセスメント1件を実際に流し切りました。画面の指示どおりに進めたのに、止まる場面が何度もありました。エラーメッセージの原文を読んでも次に何をすればいいのか分かりにくいものもあります。設定した値の意味も読み違えやすいところがありました。原因はどれも実機で特定済みです。すべて再現できます。この記事は、遭遇した11件それぞれについて症状・原因・対処をまとめたものです。

    検証環境:Australia PDI/ OOTB / 2026-08-22 導入・確認。TPRM(sn_vdr_risk_asmt)をベンダー登録からアセスメント1件の完走まで実際に操作した状態を対象にする

    TPRMとは:Third-party Risk Management(サードパーティ・リスク管理)の略です。委託先や取引先といった社外の第三者について、リスクの洗い出しからアセスメントの実施、指摘事項の是正までを1本の流れで管理するアプリケーション群です。ServiceNow Store配布のアプリで、旧称はVendor Risk Managementです。

    TPRMシリーズ(全9本) — 導入から設計・運用・トラブルまで通しで書いています。

    つまずきは「見た目」「前提条件」「初期値」の3か所に集中する

    11件を並べると、原因は3種類に分かれました。

    1つ目は、画面に見えている数がそのまま実態ではないケース。質問票は5件揃っているのにアセスメントは1件も作れません。導入ダイアログが見せる依存は3件でも実際は25スコープが増え、Setup系のメニューを探してもTPRM専用のGuided Setupは見つかりません。

    2つ目は、操作を止める条件が画面のどこにも書かれていないケース。担当者を登録していないと発行できない、回答は割り当てられた本人しか開けない、外部ポータルは社外の第三者専用。どれもエラーメッセージに行き当たるまで気づけません。

    3つ目は、初期値のまま進めると設計や運用にそのまま影響するケース。Risk ratingは完走しても空のまま残り、ワークスペースのチャートもNo dataから動きません。TieringとRatingのスケールは同じ構造なのに高得点側の意味が逆になります。sae_enabledは戻せない片道スイッチで、外部ポータルの組織名は「ServiceNow」のままです。

    先に、持ち帰りの3点だけ言い切ります。①材料(質問票)と前提条件(担当者・テンプレート)は自分で作る ②スケールは「高いほど何を意味するか」をラベルで明示する ③外部画面の確認は管理者代行に頼らない。

    エラー文言から逆引きしたい方は、この索引からどうぞ。

    • At least one primary contact must exist for the third-party → 前提条件の節(担当者を1人登録する)

    • You are not authorized to take this third-party risk assessment → 前提条件の節(担当者本人で開く)

    • This page is only for third parties to use. → 前提条件の節(担当者アカウントで開く)

    • Invalid Life Cycle... 系や画面に出ないもの → 見た目と実態のズレの節・初期値の節

    この3つを軸に、実機で確認できた11件を1つずつ見ていきます。


    画像

    見た目と実態のズレ(3件)

    画面に見えている数と実態が食い違うグループです。数を数え直すか、無いものは自分で作れば解決します。

    TPRM専用のGuided Setupは無い

    症状:導入直後、初期設定の手順を知りたくてナビゲーターの「Setup」系メニューを探しても、TPRM用のガイド付きセットアップ(Guided Setup)が見当たりません。

    原因:TPRM関連スコープでガイド付きセットアップのモジュールを検索しても該当は0件でした。GRC同族のAudit・Policy & Compliance・Risk Managementも同じ状態です。ウィザードの中身を持つテーブルを直接開こうとしても、ACLの条件で拒否されます。

    対処[代替手順あり]:ウィザードが無い以上、初期設定はメニュー階層を上から辿る形になります。並びは業務系が前半、設定系が後半です。

    • 業務系: Vendor Management Workspace → Third Parties → Engagements → Internal / External Assessments → Issues/Tasks

    • 設定系: Assessment Setup / Tiering Setup / Scoring Setup → Risk Intelligence Provider Setup → Assessment Submission Rules → Administration

    この並び自体が、初期設定のチェックリスト代わりです。


    画像

    Reviewダイアログの依存表示は3件だけ

    症状:App ManagerでInstallを押すと開くReview Installation Detailsダイアログには、依存アプリが3件としか書かれていません。

    原因:表示は一部だけです。ダイアログに出るのはsys_remote_app.dependenciesの宣言のうち3件に限られます。実際に導入を終えてsys_scopeを数え直すと、新規に増えたアプリケーションスコープは25件でした。ダイアログの件数と実測の間には8倍以上の開きがあります。

    対処[導入前に1回確認]:ダイアログの件数を影響範囲の全部だと思わないことです。本番導入前に検証環境で一度実際に入れて、前後の件数を数え直す作業が欠かせません。同じ調べ方を別アプリで実行した記事をプラグイン(v_plugin/sys_plugins)の有効・無効と依存にまとめました。差分の数え方はServiceNowでプラグインを入れると何が変わる? 影響調査でチェックする27か所の通りです。


    画像

    アセスメントが作れないのは、Assessment Templateが0件だから

    症状:Vendor Management Workspaceで外部アセスメントを新規作成しようとしても、Assessment templateの選択肢が空で先に進めません。

    原因:質問票の種類(Assessment Metric Types)は5件あります。内訳はESG Questionnaire・Fourth-party registration questionnaire・Privacy・Sample Questionnaire・Basic。状態は全てActiveです。ところが、それらを組み合わせて実際に取引先へ送る実体であるAssessment template(sn_vdr_risk_asmt_template)は0件でした。材料は揃っているのに、組み立てる作業を管理者が済ませるまでアセスメントは1件も動きません。

    対処[要作成・可逆]:作れば直ります。管理者がAssessment Templateを新規作成し、使いたい質問票をひも付けるだけです。作成後のテンプレートはこの形になり、以降の外部アセスメント作成でその名前が選べるようになります。


    画像


    画像

    前提条件が画面に書かれていない(3件)

    操作を止める条件がエラーになって初めて分かるグループです。いずれも「正しい開き方」があります。

    「At least one primary contact must exist」で発行が止まる

    症状:取引先とのエンゲージメントやアセスメントを発行(Submit)しようとすると、このエラーで止まります(訳: この第三者には主担当の連絡先が最低1件必要です)。

    原因:送り先がいないからです。vm_vdr_contact(Vendor Contact)にprimary_contact=trueのレコードが1件も無い取引先は、質問票を送る相手を特定できず発行が止まります。取引先自体は組織テーブル:会社・部署・原価の3枚(core_company)に登録済みでも、担当者の登録は別に必要です。vm_vdr_contactはsys_userを継承したテーブルで、1レコード=1人という前提を保ったまま担当者を表現します。

    対処[1分・可逆]:対象のVendor Contactを作成し、Primary contactにチェックを入れます。作成しただけで登録状態(registration_status)はsentへ自動で進みます。検証環境ではSMTPが無効なため、実際のメールは送信されません。


    画像

    「You are not authorized to take this third-party risk assessment」で回答画面に入れない

    症状:発行済みアセスメントの回答URL(/assessment_take2.do)を管理者アカウントで開くと、このエラーで弾かれます(訳: あなたはこの第三者リスクアセスメントに回答する権限がありません)。

    原因:本人限定だからです。回答画面は割り当てられた担当者(Vendor Contact)だけが開ける作りで、管理者権限でも代行できません。ここで効いているのはロールの多寡ではなく、割当先そのものです。

    対処[確認手順の変更]:割り当てられた担当者本人で開くのが正解です。この画面を本来開くのは、社内の管理者ではなく取引先の担当者(vm_vdr_contact)です。担当者レコードを作成すると、snc_external・sn_smart_asmt.actor・vendor_contact・sn_vdr_risk_asmt.external_assessment_responderの4ロールが自動で付与されます(実測)。この組み合わせが「外部の回答者」の正体です。担当者でログインすると、同じURLで質問票がそのまま表示されます。


    画像

    社内から動作確認したい場合はテスト用の担当者を1件作って、そのアカウントで開きます。社内担当者が代理で回答したい場合は、割当先自体を変更する運用にします。


    画像

    「This page is only for third parties to use.」で/svdpから弾かれる

    症状:外部の取引先向け回答ポータル(/svdp)を、社内確認のつもりで管理者アカウントで開きました。すると「This page is only for third parties to use.」と表示されます(訳: このページは第三者専用です)。

    原因:/svdpは外部の第三者だけが使う経路として作られていて、社内ユーザーは管理者を含めてブロックされます。データを持つスコープと画面を提供するスコープが分かれている作りとも関係しており、/svdpは表示専用のスコープでした。

    対処[確認手順の変更]:取引先の担当者アカウントで開くのが正解です。担当者でログインすると、Assessments・Issues・Tasks・Documents・FAQのタブを持つポータルが表示され、自社の情報だけが見えます。


    画像

    社内からの動作確認には、テスト用の担当者アカウントを1件用意しておくのが確実です。


    画像

    初期値がそのまま設計に響く(5件)

    既定値の意味を知らないまま進めると、設計や運用で跳ね返るグループです。

    完走してもRisk ratingが空のまま

    症状:アセスメントを実際に最後まで完走させました。前半はDraft → Submitted to third party → Responses received。後半はGenerating observations → Finalizing with third party → Closedの計6段階です。それでもRisk rating欄は最後まで空のままです。

    ※この項目の原因は推測です(11件で唯一、原因が未確定の項目です)

    原因(推測・要検証):質問票側にスコアリングの紐付け設定が無いためと見られます。Default risk rating scalesにはESG用・Fourth-party用の紐付き行が用意されている一方、今回使った「Basic」に紐付く行はありません。回答した「Basic」質問票のRisk score・Risk rating列も空のままでした。この関連付けが必要なのかどうかは未検証です。

    対処[要スコアリング設定・原因は未確定]:導入直後にアセスメントを1件流すだけでは評価値は出ないと知っておきます。スコアを出したい場合は、テンプレート側のスコアリング設定を先に作り込む必要があると考えられます。


    画像

    ワークスペースのチャートがNo dataのまま

    症状:Vendor Management Workspaceの2つのチャートがNo data availableのままです。Risk rating by third-party tiersとTop risk areasのどちらも描画されません。取引先は79社見えているのに、グラフだけが空です。

    原因:チャートの集計元は、取引先(core_company)のRisk rating・Third-party tierと、リスクエリア別評価です。業務レコードの件数は関係しません。どの集計元も導入直後は空で、アセスメントを1件完走させても埋まりませんでした(前項)。

    対処[評価値の投入で描画される・実測]:エンゲージメントにRisk ratingを入れます。Business Rule「Calculate engagement component rating」と「Calculate total third-party rating」が連鎖して動きます。取引先側の評価は自動で集計されました。リスクエリア側は、設定(Risk area)がOOTBではDefault 1件だけです。Securityなど使う分野の設定を追加してから、取引先別の評価を登録します。2つのチャートが描画された状態が次の画面です。


    画像

    一覧側でも確認できます。取引先一覧をRisk ratingでグループ化すると、評価が付いた15社と空欄64社が1画面で分かれます。


    画像

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

    症状:設定画面でDefault third-party tiering scalesとDefault risk rating scalesを並べて見ました。どちらも0-19・20-39・40-59・60-79・80-100という同じ5段構造なのに、高得点側の意味が食い違います。

    原因:Tiering(重要度)は80-100が「1 - Very High」で最重要を意味します。一方Rating(リスク評価)は80-100が「5 - Very Low」で低リスク、つまり安全側を意味します。同じ数字の並びでも、Tieringは点数が高いほど重要、Ratingは点数が高いほど安全という逆向きです。

    対処[設計時にラベルで明示]:ダッシュボードやレポートを設計するとき、同じ0〜100のスケールでもどちらの表を見ているかで色分けの向きを変える必要があります。高得点=赤(危険)という配色をそのままRatingへ流用すると、意味が逆転します。2本を色付きで並べた次の図を、設計資料にそのまま貼っておくのが確実です。


    画像


    画像


    画像

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

    症状:初期設定の一覧で新方式の Smart Assessment Engine を試しに有効化しようとsae_enabledを開くと、公式の説明文に強い警告が添えられています。

    sn_vdr_risk_asmt.sae_enabledの公式説明(原文・抜粋):

    Warning: You will not be able to change this setting back once it's set to be "true". Option to use Smart Assessment Engine or Assessment Engine.

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

    原因:片道スイッチだからです。後から検証のためにfalseへ戻す手段は、公式に用意されていません。導入直後の値はfalseです。

    対処[不可逆・要事前判断]:機能を試してから決めるのではなく、後戻りできない前提で判断します。検証環境で先に挙動を確かめてから、本番の設定値を決める運用にします。


    画像

    外部ポータルの組織名は既定で「ServiceNow」

    症状:外部の取引先向けポータルに表示される組織名を確認すると、自社名ではなく「ServiceNow」という文字列のままになっています。

    原因:sn_vdr_risk_asmt.company.nameプロパティの初期値が「ServiceNow」のままだったためです。前段の画面で確認したプロパティ一覧にも、同じ値が並んでいます。

    対処[1分・可逆]:外部公開の前にcompany.nameを自社名へ変更するだけです。取引先が最初に目にする画面に関わる項目なので、導入直後のチェックリストへ入れておくのが確実です。

    実機で気づいたこと

    11件を1つずつ潰していく過程で、症状を追うだけでは見えてこない共通点が見つかりました。

    認可の境界が想像より厳しいアプリです。 権限がどの層で決まるかの全体像はServiceNowで権限はどこで決まる?の7層で整理できます。 /assessment_take2.doも/svdpも、管理者アカウントで開いても割当先本人でなければ弾かれます。他のアプリでは管理者が代行できる場面が多いので、TPRMではこの前提が通じないと最初に覚えておくべきでした。

    同じ構造のスケールが逆向きの意味を持つ点が、いちばん見落としやすいところです。 TieringとRatingはどちらも0〜100を5段に割った同じ形をしています。見た目が同じだからこそ、どちらの画面を開いているかを毎回確認しないと、設計やダッシュボードの色分けを逆に作ってしまいます。

    質問票とテンプレートが別物だという点も、最初は分かりにくいところでした。 質問票の種類が5件あるので「もう使える」と思い込みがちですが、実際に送る単位であるテンプレートは別に組み立てる必要があります。材料と完成品を混同すると、Assessment Templateが0件の理由が分かりません。

    実務では何に使えるか

    冒頭の一覧表を、そのまま導入チェックリストとして使う想定で読み直します。


    画像

    導入直後の作業に「材料と前提条件を作る」を1項目足す

    Assessment Template、Primary contact、company.nameの3つは、どれも導入しただけでは埋まらない項目です。動作確認を始める前に、この3つを揃える作業を導入手順に明記しておくと、同じつまずきを防げます。

    スケール系の設定は「高いほど何を意味するか」をラベルに明記する

    TieringとRatingの取り違えは、数字だけを見ていると気づけません。設定画面やレポートのラベルに「高いほど重要」「高いほど安全」という向きを明記しておくと、設計時の混乱を避けられます。

    外部確認は管理者代行に頼らない前提で運用を組む

    /svdpも回答URLも、管理者では代行できません。動作確認や障害調査の手順書には、割当先のリンクを使う方法をあらかじめ書いておく必要があります。担当者に自動付与されるロールの中身を確かめたいときは、ロールが想定外の権限を含んでいた理由のrole_containsのたどり方が使えます。

    用語

    Assessment template(sn_vdr_risk_asmt_template):質問票の種類を組み合わせて、実際に取引先へ送る単位。導入直後は0件で、管理者が作成するまで使えない。

    vm_vdr_contact(Vendor Contact):取引先の担当者情報を持つglobalスコープのテーブル。primary_contact=trueが1件必要。

    sae_enabled(Smart Assessment Engine):新方式のアセスメントエンジンへ切り替えるプロパティ。一度trueにすると元に戻せない。

    Tiering / Rating:どちらも0〜100を5段で表す評価スケール。Tieringは重要度(高いほど重要)、Ratingはリスク評価(高いほど安全)を表し、向きが逆になる。

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

    自分のインスタンス名に続けて開きます(TPRMの導入が前提です)。

    • TPRMアプリの詳細に直接入る:/now/app-manager/home/app/id/4c821a2d9f42220030581471367fcf2c/v/22.3.3

    • Vendor Management Workspace:/now/vendor-management

    • Assessment templateの件数:/sn_vdr_risk_asmt_template_list.do

    • Primary contactの保有者:/vm_vdr_contact_list.do?sysparm_query=primary_contact=true

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

    • company.nameプロパティ:/sys_properties_list.do?sysparm_query=name=sn_vdr_risk_asmt.company.name

    • Tieringスケール:/def_tier_scale_list.do

    • Ratingスケール:/def_rating_scale_list.do

    • 外部ポータル(第三者専用):/svdp

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

    この記事で引用した説明文は、ServiceNowが製品に同梱しているプロパティのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述を確認できます。

    • プロパティの公式説明(引用元):/sys_properties_list.do?sysparm_query=name=sn_vdr_risk_asmt.sae_enabled

    検証範囲とおことわり

    Australia PDI(OOTB)で2026-08-22に確認しました。デモデータはno_demo_dataのため、登場するレコードは検証のために自分で作成したものです。

    シリーズ共通の検証データ:既存デモ企業14社を流用し、検証用の取引先1社(Meridian Data Services)を追加。担当者15名・エンゲージメント29件・アセスメント36件(うちDraftからClosedまで完走2件)・イシュー8件をこのシリーズの検証で作成しています。数値は2026-08-22時点の実測です。

    つまずきの再現で主に使ったのは、このうちMeridian Data Services向けの一連のレコードです。

    ここに挙げた11件は、このシリーズの制作過程で実際に操作して見つけたものであり、想定される全てのつまずきを網羅したものではありません。Risk ratingが空のままになる原因はログとエラーメッセージから推測した範囲で、スコアリング設定を実際に作り込んで解消できるかは確認していません。

    GRCの同族アプリ(Audit・Policy & Compliance・Risk Management)は依存プラグインがInactiveのままの状態で確認しており、有効化した場合の挙動は未検証です。Now Assist for Third-Party Risk Managementなど、PDIでは導入できないアプリの挙動も未確認です。本番環境やバージョンによって、エラーメッセージの文言や挙動が変わる可能性があります。

    関連記事

     
     
    ServiceNowのPDI(Personal Developer Instance)を実機で観察して、Noteに記事を書いています 実装・運用・教育の現場視点で淡々と記録中です リクエストがあればその記事も書きます 個人の観察日記です

    あなたへのおすすめ