TPRMの基本設定（導入後に行う設定、システムプロパティなど）

TPRMをApp Managerから導入した直後、何から手を付ければいいか分かりにくいという声があります。決めるべき設定は5つに絞られました。 第一がエンジンの選択、第二が質問票テンプレートの作成。残る3つは、外部ポータルに出る組織名・7ロールの配布方針・自動作成された3グループへの担当者登録です。順番も1行で言えます。不可逆判断（sae_enabled）→ 雛形1件（Template）→ 自社名（company.name）→ ロール配布 → グループ登録 → 現場開放。このうちsae_enabledだけは、あとから取り消せません。Australia PDIの実機で、10件のプロパティと7件のロールの中身を確認しました。

導入の手順は別記事で扱いました。導入して何が増えるかの実測も別記事です。TPRMがGRCスイートのどこに位置するかという話も、それぞれ別記事にまとめています。この記事はその続きとして、導入が終わった直後に何を設定すれば現場で動かせる状態になるかだけに絞ります。

導入した直後、画面を開いただけでは何も進められない理由

TPRMを入れた担当者が最初に期待するのは、Vendor Management Workspaceを開けばすぐに評価を始められることです。実際に開くと、Total third parties欄には78という数字がいきなり表示され、何か動きそうな印象を受けます。しかしこの78は、会社マスタでベンダーフラグが立っているレコードを数えただけの数字で、Total engagementsは0のままでした。実機では、Assessment Template（アセスメントの雛形）が0件のまま導入が完了しており、1件も組んでいない状態では評価を1件も走らせられません。加えて、質問票の処理をどちらの評価エンジンに任せるかという選択が、値を戻せない形で待っています。動かせる状態にするために決めることは次の5点です。

• エンジンの選択：Classic方式のままにするか、Smart Assessment Engineに切り替えるか

• Assessment Templateの作成：質問票と実施条件を組み合わせた雛形を最低1件用意する

• 外部ポータルに出る組織名の変更：既定値のままだと自社名ではなく別の文字列が表示される

• 7ロールの配布方針：管理・実行・承認・回答の役割が分かれているので、誰に何を配るかを決める

• 自動作成グループへの担当者登録：導入直後はメンバーが1人も入っていない

この5点さえ決まれば、Third PartiesやEngagementsの画面を現場へ開放できる状態になります。

TPRMの初期設定は、他アプリの初期設定と何が違うのか

ロールとプロパティを確認して現場へ開放する型は、CIMを入れたときの初期設定と同じ考え方です。TPRMがGRC Profileという共通基盤に乗る作りも、PPM Standardが別プラグインを連れてくる依存構造に近いものだと言えます。TPRM固有なのは、一度決めると戻せない設定が含まれている点と、テンプレートを自分で組むまで評価を実行できない点の2つです。

もう1つ押さえておきたい点があります。GRCスイートの同族機能（Audit・Policy&Compliance・Risk Management）の依存プラグインは、TPRM導入後もInactiveのままでした。初期設定はTPRM単体の範囲で完結し、他のGRCアプリを併用するかどうかは後から独立して判断できます。

最初に決めるのは、Classic方式かSmart Assessment Engineか

質問票への回答をどちらの仕組みで処理するかを切り替えるプロパティがsn_vdr_risk_asmt.sae_enabledです。既定値はfalseで、Classic方式のまま動きます。公式の説明（原文・抜粋）はこうでした。

（訳: 警告：一度trueに設定すると元に戻せません。Smart Assessment EngineまたはAssessment Engineのどちらを使うか選択するオプションです……）引用元: /sys_properties_list.do?sysparm_query=name=sn_vdr_risk_asmt.sae_enabled

この記事で唯一の不可逆設定です。「あとで試して駄目なら戻す」が効きません。 他のtrue/false系プロパティと同じ感覚で触ると後戻りできないため、5つの中で最初に、検証環境で挙動を見てから決めます。

エンジンを選ぶ前提のデータは、すでに用意されている

TPRMスコープのAssessment Metric Type（質問票テンプレート）は5件登録されていて、すべてactiveです。Smart Assessment Engine側のsae_rating_scaleも、すでに85件用意されていました。sae_enabledがfalseのままでも、切り替えたときに使うデータは事前に準備されています。 つまりSAEへ切り替えても評価基準が空の状態から始まらない、という判断材料になります。

Assessment Templateが0件、質問票の素材はあるのに動かせない

Assessment Metric Typeは5件です。名称はESG Questionnaire・Fourth-party registration questionnaire・Privacy・Sample Questionnaire・Basicでした。

5件とも対象テーブルはCompany（core_company）という会社マスタで、条件は揃ってvendor=trueです。質問票を割り当てる相手は、会社マスタのベンダーフラグに固定されていると分かります。Basicは11問構成で、実際に1件のアセスメントを完走させた記録でもこのBasicを使いました。

基礎知識編では「0件だと動かない」という事実として紹介しました。設定編のここでは、最初の1件を組む作業として扱います。実際の評価にはsn_vdr_risk_asmt_template（Assessment Template）で対象の取引先・質問票・実施条件を1つにまとめる必要があります。このテンプレートが導入直後は0件です。 1件も作らないまま現場に開放すると、評価を始められません。最初の実作業は、テンプレートを最低1件組むことです。

外部ポータルの自社名は、既定で「ServiceNow」

既定値のまま公開すると、取引先の画面に自社名ではなく「ServiceNow」と表示されます。プロパティ一覧のsn_vdr_risk_asmt.company.nameがその設定で、既定値は「ServiceNow」でした。Description欄の見出しは「Organization Name」で、外部の取引先が回答するポータルに表示される自社名の設定だと分かります。この値を変更しないまま外部に質問票を送ると、相手の画面には「ServiceNow」という表示が残ります。 製品名がそのまま出てしまう格好です。外部の目に触れる設定なので、後回しにしにくい項目です。

ロール7件を、誰にどう配ればいいか

TPRMスコープのロールは7件です。名前と説明を実機で並べると、役割の分かれ方がそのまま見えます。

vendor_risk_adminの説明（原文）はこうでした。

（訳: Vendor Risk Administratorロールは、Vendor Risk Managementの全データを完全に制御します。Assessment Metric Typesについても完全に制御します。）

vendor_risk_managerの説明（原文）はこうです。

（訳: 取引先・連絡先・取引先アセスメントテンプレート・質問票テンプレート・書類請求テンプレート・スケジュール済みアセスメントを管理します。）

引用元: /sys_user_role_list.do?sysparm_query=sys_scope.scope=sn_vdr_risk_asmt

vendor_assessorは取引先・連絡先・アセスメント・issueを管理し、依頼を完了させる役割です。vendor_assessment_reviewerはアセスメントの編集だけを許す役割で、approverは承認だけを行う役割でした。approverだけは直接のACLを1件も持ちません。 external_assessment_responderとinternal_assessment_responderの2件は、Descriptionが空欄のままです。

管理者からユーザーまで、権限は3段階で継承される

7ロールの関係は、admin→manager→assessor/reviewerという3段の継承、別系統のapprover、さらに別系統の回答者ロールという構造です。managerの直接ACLは93件、adminは10件ですが、adminは他のGRCアプリのadmin系ロールも継承するため管理範囲は数字より広くなります。external_assessment_responderの継承先はsn_smart_asmt.actor（106件のACL）のみ、internal_assessment_responderはそれに加えsn_grc_workspace.userとtask_readerも継承します。内部と外部の違いは、GRCワークスペースに入れるかどうかだけです。

導入時には自動でグループが3つ作られ、いずれもメンバーは0人でした。admin用グループはありません。ユーザー・グループ・ロールの中間表でグループへ入れるか個人に直接割り当てるかは現場の判断ですが、adminだけはDelegated Developmentの絞り込みと同じく担当者を絞るのが安全です。

ここから先は「今すぐ決める5つ」ではなく、公開前に一度見ておく確認項目です。決める作業と見る作業を分けると、頭の整理が楽になります。

スコアは今のところ、外部アセスメントの結果だけで決まる

総合スコアを構成する要素（component_definition）は4件登録されています。Third-party Risk Assessments・Engagements・Subsidiaries・Risk intelligence ratingの4系統です。重みの初期値はThird-party Risk Assessmentsだけが100で、残り3件は0でした。つまり初期状態の総合スコアは、外部に送った質問票の結果だけで決まります。 エンゲージメントの進行状況や子会社の情報、外部のリスクインテリジェンスは、それぞれの重みを上げるまでスコアに反映されません。third-party risk area definitionも12件登録されていますが、実際に有効化されて重みを持つのは既定の1件だけでした。初期状態のまま運用を始めても動作はしますが、「単一の物差ししか使っていない」状態だと理解したうえで始めるのが安全です。 複数の観点を組み合わせて評価したいなら、この重み配分を先に見直しておく必要があります。

分野別のリスクエリアを使うなら、設定行の追加が必要

リスクエリアの設定（Risk area）は、OOTBではDefaultの1行だけです。定義（definition）は12種ありますが、定義があるだけでは取引先別の分野評価は登録できません。SecurityやPrivacyなど分野別に評価したい場合は、使う分野の設定行を追加してから運用を始めます。

設定と評価値が入ると、導入直後はNo data availableだったワークスペースの2チャートが描画されます。基本設定の仕上がり確認として、この画面まで見ておくと確実です。

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

どちらも同じ0〜100の5バンドですが、80〜100の意味が正反対です。取引先の重要度を表すTiering scaleと、リスクの評価結果を表すRating scaleを並べると、同じ構造に見えて点数が高いほうの意味が逆でした。基礎知識編では仕組みとして触れた論点ですが、ここでは「設定としてどう扱うか」に絞ります。

Tiering scaleは1-Very High（80〜100点）が最上位で、点数が高いほど重要な取引先という意味になります。

一方Rating scaleは1-Very High（0〜19点）が最上位で、点数が高いほど安全という意味になります。同じ「1-Very High」「5-Very Low」というラベルと、同じバンド幅を使っているのに、向きだけが逆です。2つを1枚に並べると、取り違えの危なさがよく分かります。

通知18件とスケジュールジョブ4件、公開前に確認しておくこと

公開前に、TPRMの通知18件がすべてactiveであることを確認しておきます（参考: GRC系5スコープ全体では40件、うちTPRM単独が18件）。

TPRM固有のスケジュールジョブは4件です。日次で動く2件（Clean third-party security scores / Vendor risk repeating assessment schedule）は既定のままで問題ありません。条件変化に応じて動く「Recalculate risk rating upon valid to overdue or criteria change」も同様です。「Migrate industry column - DO NOT RUN THIS MANUALLY」だけは要注意です。 名前にそのまま「手動実行するな」と明記されています。既定でactiveですが実行種別はonce（1回きり）なので、運用中にうっかり手動で走らせないよう名前だけは覚えておく価値があります。

Guided Setupが無い代わりに、Setup系メニューがそのままガイドになる

PPMなど他のアプリでは導入直後にGuided Setupのウィザードが用意されていることがありますが、TPRMにはGuided Setupに相当するメニューがありません。 代わりに、左メニューのThird-party Risk Management配下には設定系モジュールが並んでいます。順はAssessment Setup・Tiering Setup・Scoring Setupと続きます。そのあとRisk Intelligence Provider Setup・Assessment Submission Rules・Administrationが続く構成です。この並びが、実質的な設定ガイドの役割を果たしています。ここまで説明した質問票・テンプレート・重み・スケールの設定は、ほぼこの並び順のままメニューから到達できます。この並び順を「初期設定のチェックリスト」として上から辿るのが、実質的な最短ルートです。

実機で気づいたこと

質問票5件の条件が、1件残らずvendor=trueで統一されていました。 質問票ごとに対象条件を作り込む機能ではなく、「誰に送るか」は会社マスタのベンダーフラグ側で管理し、質問票側は内容の違いに専念する設計だと分かります。

エンジン選択用のスケールデータ（sae_rating_scale）が、機能を有効化する前から85件も用意されていました。 使っていない機能のデータを事前に持たせておくのは無駄に見えますが、切り替えた瞬間に空の状態から始めずに済むという意味では、後戻りできないスイッチの裏側として理にかなっています。

approverロールだけ直接のACLを持たない設計は、最初は見落としました。 他の6ロールがすべて何らかの直接ACLを持つ中で1件だけ0件というのは、権限の棚卸しでは「このロールは何を参照できるのか」を別枠で確認する必要があることを示しています。

実務では何に使えるか

ここまでの内容を、今すぐ決めることと後回しでよいことに分けます。

今すぐ決めること

• sae_enabledをtrueにするかどうか：不可逆のスイッチなので、業務要件と照らして先に判断します

• Assessment Templateを最低1件組む：0件のままでは評価を1件も始められません

• company.nameを自社名に変更する：既定値のまま外部ポータルに表示されてしまいます

• 7ロールの配布方針を決める：管理・実行・承認・回答の役割ごとに配る相手を分けます

• 3つの自動作成グループに担当者を入れる：導入直後はメンバー0人のままです

後回しでよいこと

リスクエリアの重み配分や通知文面のカスタマイズは、初期状態のまま運用を始めても動作します。スケジュールジョブの実行タイミングも、既定のperiodically/dailyで当面は問題ありません。多面的な評価やカスタマイズが必要になった時点で、優先順位を付けて直していけば十分です。

小さく始める順番

1. sae_enabledを触るかどうかを、不可逆であることを踏まえて先に決める

2. Assessment Templateを1件組み、Basicなど既存の質問票を紐付けて動作を確認する

3. company.nameを自社名に変更する

4. 7ロールを管理・実行・承認・回答の単位で担当者に割り当てる

5. 自動作成された3グループに担当者を登録する

6. ここまで終わったらThird PartiesとEngagementsの画面を現場へ開放する

用語

sae_enabled：Classic方式とSmart Assessment Engineを切り替えるプロパティ。一度trueにすると戻せない。

Assessment Template：対象の取引先・質問票・実施条件をまとめた雛形。これが無いとアセスメントを開始できない。

Tiering scale / Rating scale：どちらも5段階の点数区分だが、高得点の意味が重要度と安全度で逆になる。

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

自分のインスタンス名に続けて開いてください（TPRM導入が前提です）。引用したプロパティ・ロールの説明文もこの一覧から確認できます。

• TPRM関連プロパティ一覧：/sys_properties_list.do?sysparm_query=nameLIKEsn_vdr_risk_asmt

• TPRMロール一覧：/sys_user_role_list.do?sysparm_query=sys_scope.scope=sn_vdr_risk_asmt

• 質問票テンプレート一覧：/asmt_metric_type_list.do?sysparm_query=sys_scope.scope=sn_vdr_risk_asmt

• Assessment Template一覧：/sn_vdr_risk_asmt_template_list.do

• Tiering scale：/sn_vdr_risk_asmt_def_tier_scale_list.do?sysparm_query=ORDERBYorder

• Rating scale：/sn_vdr_risk_asmt_def_rating_scale_list.do?sysparm_query=ORDERBYorder

• スケジュールジョブ一覧：/sysauto_script_list.do?sysparm_query=sys_scope.scope=sn_vdr_risk_asmt

検証範囲とおことわり

Australia PDIに、OOTBの状態からTPRMを導入した直後の状態で2026-08-22に確認しました。

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

• sae_enabledをtrueに切り替えた後の画面挙動：不可逆のため今回は試していません

• Assessment Templateを実際に作成した後の運用（アセスメントを1件流し切る手順は別記事の範囲）

• 重み配分やTiering/Rating scaleの値を変更した場合の再計算結果、通知18件の文面をカスタマイズした場合の配信結果

関連記事

• 前提知識：システムプロパティ（sys_properties）は設定値の置き場

• 同じ「入れた直後の設定」を扱った例：ServiceNowのPPMを入れたら最初にやる設定は？ プロパティ・ロール・カレンダーを実機で確認する

• ロールの権限が及ぶ範囲の調べ方：ロールを付けたのに見えない理由：ACL（sys_security_acl）