アンケート・評価は定義・設問・回答に分かれる（Survey）

2026年6月22日 20:27

ServiceNow の Incident / Problem / Change は、task を継承する1枚のテーブルで「1件＝1レコード」として理解できました。一方、アンケート・評価（Survey / Assessment）は、1枚のテーブルでは完結しません。「定義」「設問」「回答」が別々のテーブルに分かれ、参照でつながって動きます。

この記事では、アンケート機能を画面の操作手順だけで説明しません。実際のテーブルを起点にします。アンケート/評価の定義である asmt_metric_type、設問である asmt_metric を確認します。回答1回分を表す asmt_assessment_instance、回答の1問1問を保存する asmt_assessment_instance_question も確認します。

この記事は、ServiceNow の Incident は触ったことがあるが、アンケート・評価のテーブル構造（定義・設問・回答がどう分かれているか）をこれから理解したい人を想定しています。管理者・開発者が実機で確認するときに見るべきポイントは、テーブルの分かれ方と設問タイプ（datatype）です。あわせて、回答インスタンスの State、周辺設定も順に確認します。

この記事で分かること

アンケート/評価が「定義・設問・回答」の複数テーブルに分かれていること
asmt_metric_type（定義）と asmt_metric（設問）が metric_type で結ばれること
回答が asmt_assessment_instance（回答1回）と asmt_assessment_instance_question（1問1行）に分かれること
設問タイプ（datatype）に何が用意されているか
回答インスタンスの State（ready → wip → complete）
実機で確認するときに見るべき一覧URL

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、テーブル構成・フィールド・件数・設定の内容が異なる場合があります。

アンケート・評価（Survey / Assessment）とは

ServiceNow の Survey（アンケート）/ Assessment（評価） は、利用者やレコードに対して設問を配信し、回答を集めてスコア化する仕組みです。問い合わせ解決後の満足度アンケート、NPS、サービスデスク評価などに使われます。

ServiceNow では、これを「アンケート用紙」のような1枚のレコードでは管理しません。実際には、「どんなアンケートか（定義）」「どんな設問か（設問）」「誰がどう答えたか（回答）」を別々のテーブルに分けて持ち、参照でつなぎます。だから、アンケートを理解するには「いま定義側を見ているのか、回答側を見ているのか」を意識する必要があります。

公式の Assessments and surveys（Zurich）に、アンケートと評価の全体像（定義・設問・トリガー・スコアリング）が概観されています。

アンケート・評価は「定義・設問・回答」に分かれる

まず全体の構造を見ます。中心は asmt_metric_type（定義）で、ここから設問と回答の両方に枝が伸びます。

今回確認した PDI（Zurich / OOTB）では、テーブルは次の役割で分かれていました。

asmt_metric_type（定義） … アンケート/評価1種＝1レコード。19件ありました（うち publish_state が published のものは18件）。「NPS Metric Type」「Service Desk Satisfaction Survey」などが該当します。
asmt_metric（設問） … 1問＝1レコード。metric_type で所属する定義を参照します。128件ありました（うち active は127件）。
asmt_assessment_instance（回答インスタンス） … 「誰かが1回答える」単位。metric_type でどの定義の回答かを参照します。88件ありました。
asmt_assessment_instance_question（回答明細） … 回答の1問1問。instance（どの回答か）と metric（どの設問か）を参照します。1,394件ありました。
asmt_metric_category（設問カテゴリ） … 設問をグループ分けするカテゴリです。29件ありました。
asmt_assessment（評価グループ） … 複数の定義をまとめるグループです。31件ありました。

つまり、「設問」と「回答」は別のテーブルで、回答明細が両者を instance / metric で結びつけて1行ずつ保存する、という構造です。設問が128件、回答インスタンスが88件、その掛け合わせとして回答明細が1,394件になっています。

定義の一覧は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/asmt_metric_type_list.do?sysparm_query=publish_state=published^ORDERBYname

主要テーブルの役割と件数は次のとおりです。

主要6テーブルの件数まとめ

テキストでも件数を並べておきます。

役割         物理テーブル                        件数
-------------------------------------------------------------
定義         asmt_metric_type                    19（published 18）
設問         asmt_metric                         128（active 127）
設問カテゴリ asmt_metric_category                29
評価グループ asmt_assessment                     31
回答インスタンス asmt_assessment_instance         88（complete 78）
回答明細     asmt_assessment_instance_question   1,394

継承の見方（定義はメタデータ、回答は運用データ）

task 系のテーブルは task を業務継承していましたが、アンケート系は継承の向きが違います。

今回確認した PDI（Zurich / OOTB）では、次のようになっていました。

asmt_metric_type（定義）と asmt_metric（設問） … どちらも super_class が sys_metadata でした。つまり「設定・定義の一種（メタデータ）」として扱われ、Update Set で移送される対象になります。
asmt_assessment_instance（回答インスタンス） … super_class が空、つまり sys_metadata を継承しない独立した運用データでした。回答は日々生まれる業務データなので、定義側とは性質が分けられています。

この「定義側はメタデータ、回答側は運用データ」という分け方は、移送やバックアップの観点でも重要です。アンケートの定義・設問を別環境に持っていくときは sys_metadata 系を、回答データは運用データとして別に扱う、という整理になります。

固有フィールド数は、定義（asmt_metric_type）が47、設問（asmt_metric）が52、回答インスタンス（asmt_assessment_instance）が36でした。設問テーブルが最も多くの固有フィールドを持つのは、後述する設問タイプや採点・条件表示の設定を1テーブルで吸収しているためです。

定義レコードの中身は、次のように1枚のフォームで確認できます。

定義（asmt_metric_type）の主なフィールド

フォームに並ぶ項目のうち、主なものを挙げます。

publish_state（公開状態。draft/published）
scoring_type（採点方式。percent/absolute）
scale_factor（採点の係数）
allow_retake（再回答を許すか）
anonymize（回答を匿名化するか）
allow_public（公開回答を許すか）
one_click_survey（ワンクリック回答にするか）
chat_survey（チャット経由で回答させるか）
survey_owners（→sys_user。アンケートの所有者）
signature（→asmt_signature。回答に署名を紐づける）

設問テーブル（asmt_metric）と設問タイプ（datatype）

設問は asmt_metric に1問＝1レコードで保存されます。役割で分けると、設問内容・所属・表示制御・採点に整理できます。

主なフィールドは次のとおりです。設問の見た目と回答形式を決めるのが datatype（Data type）で、metric_type でどの定義に属するかを、category で設問カテゴリを参照します。

設問の入力形式は datatype 列で決まります。今回の PDI（Zurich / OOTB）では、次の19種類が用意されていました。

ポイントは、同じ「設問」でも datatype を変えるだけで、はい/いいえ・単一選択・段階評価（Likert）・自由記述・星評価など、回答形式を切り替えられることです。たとえば満足度は Likert Scale や Ratings、自由意見は String、推奨度は Numeric Scale、というように使い分けます。

設問の一覧は、次のURLで確認できます。metric_type 列を見ると、どの定義に属する設問かが分かります。

https://<YourInstance>/asmt_metric_list.do?sysparm_query=active=true^ORDERBYmetric_type

設問タイプの選択肢そのものは、次のURLで一覧できます。

https://<YourInstance>/sys_choice_list.do?sysparm_query=name=asmt_metric^element=datatype^inactive=false^ORDERBYsequence

公式の Create a metric definition（Zurich）に、設問（metric）の作成手順と datatype の選び方が説明されています。

datatype の value 一覧

画面のラベルだけでなく、スクリプトや API で条件指定するときは value（内部名）を使います。今回の PDI で確認した19種類の value は次のとおりです。

attachment, checkbox, choice, custom, date, datetime, duration, imagescale
scale（Likert Scale）, multiplecheckbox, long（Number）, numericscale
percentage, ranking, rating, reference, string, template, boolean（Yes/No）

回答インスタンス（asmt_assessment_instance）の State

回答は asmt_assessment_instance に「誰かが1回答える」単位で保存されます。回答が進むと、State（state）が変化します。

今回確認した PDI（Zurich / OOTB）では、State の選択肢は次の4つでした（sequence 順）。

ready（Ready to take） … 配信済みで、まだ着手していない状態
wip（In progress） … 回答中
complete（Complete） … 回答完了。88件中78件がこの状態でした
canceled（Cancelled） … 取消

回答インスタンスが持つおもな参照フィールド

State 以外にも、次のような参照フィールドを持ちます。

user（→sys_user）… 誰の回答か
assessment_group（→asmt_assessment）… どの評価グループに属するか
task_id（→task）… どの task レコードに紐づくか

asmt_assessment_instance（回答1回分）と asmt_assessment_instance_question（回答の1問1問）は別のテーブルです。ここが注意点です。1つの回答インスタンスが完了すると、その中の設問の数だけ回答明細レコードが生まれます。だから今回の PDI では、回答インスタンスが88件なのに対し、回答明細は1,394件になっています。

回答インスタンスの一覧は、次のURLで確認できます。

https://<YourInstance>/asmt_assessment_instance_list.do?sysparm_query=ORDERBYDESCsys_created_on

回答の1問1問（回答明細）は、次のURLで確認できます。instance 列と metric 列が、どの回答のどの設問かを指しています。

https://<YourInstance>/asmt_assessment_instance_question_list.do?sysparm_query=ORDERBYDESCsys_created_on

公式の Metric types and assessable records（Zurich）に、metric type と評価対象レコード（assessable records）のひも付けの考え方が説明されています。

アンケート・評価に関わる周辺機能

アンケート・評価の動きも、フィールド定義だけでは決まりません。配信・採点・通知など、複数の設定が組み合わさって動きます。大まかには、配信や採点の処理は Business Rule、通知は Notification、権限は ACL が関係します。

今回確認した PDI（Zurich / OOTB・active 中心）では、主要テーブルに次のような設定が紐づいていました。

注意したいのは、設定が定義側（asmt_metric_type）と回答側（asmt_assessment_instance）に分かれて紐づく点です。Business Rule は定義側22件・設問側17件・回答側9件、Access Control は定義側13件・回答側11件と両側にまたがります。一方、Client Script は定義側16件のみでフォーム側の操作を支えます。Notification は回答側26件のみで配信・リマインドを担い、UI Action も回答側3件・UI Policy は回答側0件でした。どちらか片方だけを見て全体を判断しないようにします。

自分のインスタンスでは、次のURLで各一覧を開けます（先頭の <YourInstance> は置き換えてください）。

Business Rules（定義）: https://<YourInstance>/sys_script_list.do?sysparm_query=collection=asmt_metric_type^active=true
Notifications（回答） : https://<YourInstance>/sysevent_email_action_list.do?sysparm_query=collection=asmt_assessment_instance
Access Controls（回答）: https://<YourInstance>/sys_security_acl_list.do?sysparm_query=name=asmt_assessment_instance

ServiceNowにおけるアンケート・評価のポイント

アンケート/評価は1枚のテーブルで完結しません。「定義（asmt_metric_type）」「設問（asmt_metric）」「回答（asmt_assessment_instance / _question）」に分かれます。中心は定義で、設問と回答の両方が metric_type で定義を参照します。
今回確認した PDI では、定義19件・設問128件・回答インスタンス88件・回答明細1,394件でした。設問×回答の掛け合わせとして回答明細が積み上がります。
設問の入力形式は datatype（19種）で決まり、Yes/No・Choice・Likert Scale・Ratings・String などを切り替えられます。
回答インスタンスの State は ready → wip → complete（＋ canceled）です。回答1回分（instance）と回答の1問1問（instance_question）は別テーブルです。
継承の向きは、定義・設問が sys_metadata（メタデータ）、回答インスタンスが独立した運用データでした。移送やバックアップの観点でこの違いが効きます。
周辺設定は定義側と回答側に分かれて紐づきます（例：通知は回答側に26件）。片側だけ見て全体を判断しないことが重要です。

アンケート・評価を調べるときは、まず「いま定義側を見ているのか、回答側を見ているのか」を意識します。そのうえで、定義（metric_type）を起点に、設問（metric）・回答インスタンス（instance）・回答明細（instance_question）をセットで見ます。

実機で気づいたこと

asmt_metric_type に signature（→asmt_signature）という参照フィールドがあるのは意外でした。アンケートというと単純な質問と回答の集まりだと思っていましたが、署名と結びつけられる作りになっている点から、満足度調査だけでなく承認・サインオフを伴う評価にも使える設計だと分かります。
最初は task 系のテーブルと同じように、定義から回答まで1本の継承でつながっていると思っていました。実際には定義（asmt_metric_type / asmt_metric）だけが sys_metadata を継承し、回答（asmt_assessment_instance）は独立した運用データでした。この違いに気づくと、アンケートの回答が Update Set の移送対象にならない理由が腑に落ちます。
19件の asmt_metric_type のうち published は18件、128件の asmt_metric のうち active は127件と、それぞれ1件だけ公開・有効化されていないレコードが残っていました。デモデータにも「作りかけ」のレコードが混じっている点は、実務で棚卸しをするときに「定義されているように見えて実は下書きのまま」のケースがあり得ることを示しています。

次に読むなら

次に確認するなら3つあります。1つ目は、回答からスコアを計算する仕組み（Decision Matrix / scoring_type）です。2つ目は、評価対象レコード（Assessable Records）を条件で自動的にひも付ける仕組みです。3つ目は、トリガー条件による自動配信です。特に「集めた回答をどうスコア化し、ダッシュボードで読むか」は、アンケート・評価を運用に乗せるうえで重要です。これらは本記事の「定義」「回答インスタンス」で触れた仕組みの先にあたり、別記事で取り上げる予定です。

用語

PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
Survey：アンケート（利用者に設問を配信して回答を集める）
Assessment：評価（レコードや対象を設問で評価しスコア化する）
metric type（asmt_metric_type）：アンケート/評価の定義
metric（asmt_metric）：設問
instance（asmt_assessment_instance）：回答1回分（回答者1人の1回）
datatype：設問の入力形式（Yes/No・Choice・Likert Scale など）

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

先頭に自分のインスタンスを付けると、同じ画面が開けます。

定義一覧         : asmt_metric_type_list.do?sysparm_query=publish_state=published^ORDERBYname
設問一覧         : asmt_metric_list.do?sysparm_query=active=true^ORDERBYmetric_type
回答インスタンス : asmt_assessment_instance_list.do?sysparm_query=ORDERBYDESCsys_created_on
回答明細         : asmt_assessment_instance_question_list.do
datatype 選択肢  : sys_choice_list.do?sysparm_query=name=asmt_metric^element=datatype^inactive=false^ORDERBYsequence

検証範囲とおことわり

確認した範囲：asmt_metric_type / asmt_metric / asmt_assessment_instance の継承（sys_metadata / 独立）です。固有フィールド数（47 / 52 / 36）も確認しました。加えて、設問→回答の参照構造、各テーブルのレコード件数も確認しました。state / publish_state / scoring_type / datatype の選択肢、主要フィールドと参照先、周辺設定件数も確認しました。すべて PDI（Zurich / 2026-06-21 確認）の OOTB で取得しています。
確認していない範囲（断定しません）：スコア計算（Decision Matrix / asmt_metric_result）の内部ロジックです。Survey Designer / Assessment Designer のUI動作も確認していません。ほかに、トリガー条件による自動配信の挙動、Scheduled Assessment の実行も確認していません。各 Business Rule / Client Script の内部スクリプト、評価対象レコード（Assessable Records）のひも付け運用も確認していません。これらは別記事で扱います。

今回は PDI の OOTB（初期設定）を前提に、テーブルの構造を確認しました。実環境では、既存のカスタマイズによってテーブルや設定の数・内容が変わります。