Virtual Agentの会話シナリオはどこに保存されるか（sys_cs_topic）

2026年6月27日 09:34

ServiceNow のチャットボット Virtual Agent（バーチャルエージェント）に「live agent につないで」と話しかけると、有人対応への引き継ぎが始まります。このとき「どの発話で、どの会話シナリオが動き出すか」を1件ずつ定義しているのがトピック（Topic）、テーブル名で言うと sys_cs_topic です。Virtual Agent はこのトピックの集まりでできています。

この記事は、Virtual Agent を触ったことはあるが、会話シナリオがどんなテーブルに、どんな形で保存されるのかを確認したい管理者・開発者を想定しています。利用者の発話（utterance）からどう起動するのかも、あわせて確認します。PDI（Zurich / OOTB）で sys_cs_topic を実際に開き、1行＝1つの会話シナリオであることを確かめます。発話とトピックを結ぶ key_phrases（認識キーワード）と model_type（照合方式）、トピックの分類を決める type を確認します。あわせて、PDI 実機での件数分布も順に見ます。

この記事で分かること

Virtual Agent のトピックは sys_cs_topic の1行＝1つの会話シナリオとして保存されること
sys_cs_topic が業務レコードではなく、sys_metadata（Application File）を継承する「設定（メタデータ）」であること
発話からトピックが起動する仕組みが key_phrases（認識キーワード）× model_type（NLU/Keyword か LLM）で決まること
トピックには type が4種（STANDARD / TOPIC_BLOCK / SETUP_TOPIC / CUSTOM_INPUT）あること
PDI 実機 74件中 STANDARD が34件で最多であること
active / published / is_system_topic といった状態フラグの意味と、PDI 実機での分布
起動したトピックが会話フローを進め、その実体が sys_cs_conversation（会話インスタンス）に記録される、という全体像

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

Virtual Agent トピック（sys_cs_topic）とは

トピックとは、Virtual Agent の 会話シナリオ1本を1件＝1レコードで定義したものです。たとえば「有人対応へ引き継ぐ」「カタログ品目を申請する」「AI Search でナレッジを探す」といった会話の流れが、それぞれ sys_cs_topic の1行として保存されています。

ポイントは、トピックが 「いつ起動するか（発話との結びつき）」と「何をするか（会話フロー）」をひとまとめに持つことです。下の実画面は、その1行をフォームで開いたものです。

このレコードは、Name に「Live Agent Support.」、Key phrases に「agent」「live agent」などの認識キーワードが入っています。利用者が「live agent」と話せば、この語句に反応してトピックが起動し、有人対応への会話が進む、という仕組みです。

PDI（Zurich / OOTB）の sys_cs_topic には、すでに 74件のトピックが入っていました。挨拶やフォールバックといった内部用のものから、カタログ申請・AI Search・有人引き継ぎといった利用者向けのものまで含まれます。Virtual Agent の会話は、すべてこのテーブルの集まりで成り立っています。

sys_cs_topic はどこに位置するテーブルか

名前が sys_cs_topic なので何かの業務テーブルに見えますが、継承元を確認すると違いました。

今回確認した PDI（Zurich / OOTB）では、sys_cs_topic の super_class（継承元）は sys_metadata（Application File） でした。つまりトピックは Incident のような業務レコードではなく、更新セットで捕捉・配布される「設定（メタデータ）」です。アプリとして開発・移送する対象だ、ということです。

トピックの中身を決める固有フィールドは 39件あり、会話シナリオを成り立たせる中核は次のようなフィールドです。

name・title・type・model_type・key_phrases の5つで「どんな会話を・どの発話で・どう起動するか」のあらましが決まります。フィールド一覧は次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_cs_topic^elementISNOTEMPTY

発話からトピックが起動する仕組み：key_phrases と model_type

Virtual Agent の要は、利用者の発話（utterance）に対して、どのトピックを起動するかを決めることです。その照合のしかたを決めるのが model_type（照合方式）で、起動の手がかりになるのが key_phrases（認識キーワード）です。

PDI 実機の model_type は 2種類でした。

NLU/Keyword（nlu_keyword）… key_phrases（認識キーワード）や NLU モデルで発話を照合する従来方式。
LLM（llm）… 大規模言語モデルで発話の意味から照合する新しい方式。

たとえば先ほどの「Live Agent Support.」は、key_phrases に agent / live agent を持っていて、利用者がこれらの語を含む発話をすると起動します。次の実画面は、別のトピック「Issue Auto-Resolution」（type=STANDARD・model_type=NLU/Keyword）を開いたものです。

照合方式ごとにトピックを並べると、どの方式がどれだけ使われているかが分かります。

照合方式と状態フラグの実機分布は次の通りです。

74件中、NLU/Keyword が20件、LLM が9件、残り45件は model_type が空でした。空が多いのは、次節で見る TOPIC_BLOCK や CUSTOM_INPUT のように「発話で直接起動しない」トピックが照合方式を持たないためです。

なお、発話を NLU や LLM がどのように解釈してトピックを選ぶか、その内部のマッチング処理は今回の検証範囲外です。ここではテーブル上の定義（key_phrases と model_type）までを確認します。

トピックの type は4種類

sys_cs_topic を type でグループ化すると、トピックが役割ごとに分かれているのが分かります。

PDI 実機の 74件中、STANDARD が34件で最多でした。それぞれの役割は次の通りです。

STANDARD（34件）… 発話を起点に会話を進める基本のトピック。利用者が直接呼び出すシナリオの中心。
TOPIC_BLOCK（24件）… 他のトピックから呼び出される再利用部品。共通処理を1か所にまとめておくためのものです。なお sys_cs_topic_block という別テーブルは存在せず、これは type の選択値でした。
SETUP_TOPIC（12件）… 挨拶（Greetings.）やフォールバック（Fallback Topic.）など、会話全体の枠組みを担う設定トピック。
CUSTOM_INPUT（3件）… 入力コントロール用のトピック。

利用者が「会話のテーマ」として認識するのは主に STANDARD で、TOPIC_BLOCK や SETUP_TOPIC は会話を裏で支える部品、という分担になっています。

active / published / is_system_topic：状態フラグの見方

トピックには「使えるか」「公開されているか」「内部用か」を表す状態フラグがあります。PDI 実機での分布は次の通りでした。

active（有効フラグ）… true 73件 / false 1件。ほぼ全件が有効です。
published（公開フラグ）… 74件すべてが true。OOTB のトピックはすべて公開済みの状態で入っていました。
is_system_topic（システム内部トピックか）… true 36件 / false 38件。_hi_ _bye_ _help_ _agent_ のような内部用トピックと、利用者向けトピックがほぼ半々です。
foundational（基盤トピックか）… true 2件のみ。ごく限られたトピックだけが基盤として扱われています。

利用者の目に触れるのは is_system_topic が false の利用者向けトピックで、_ で始まる名前の内部用トピックは会話の制御（挨拶・割り込み・トピック探索など）を裏で担っています。

起動したあと：会話フローと sys_cs_conversation

トピックが起動すると、その中の 会話フロー（質問・回答・分岐・アクション） が順に進みます。この「いま誰がどのトピックでどこまで話したか」という会話の実体を記録するのが、別テーブルの sys_cs_conversation（Conversation＝会話インスタンス） です。

トピックが「シナリオの設計図（メタデータ）」なら、conversation は「実際に走った1回の会話（データ）」にあたります。今回の PDI では会話を実行していないため、sys_cs_conversation は0件でした。会話フローのノードや分岐をどう組み立てるか（Conversation Builder の中身）と、conversation の実行時の挙動は、今回の検証範囲外とします。

トピックは単独で完結するのではなく、ほかの機能と組み合わさって動きます。たとえば「Request Catalog Item」トピックはサービスカタログの申請（Request / RITM / Catalog Task）につながり、「AI Search」系トピックはナレッジ（kb_knowledge）の記事を会話の中で提示します。会話の途中で自動処理を回す部分は Flow Designer（sys_hub_flow）のアクションと組み合わせるのが定番で、Virtual Agent 自体は Service Portalなどの画面に埋め込まれて利用者に届きます。トピックの考え方は ServiceNow 公式の Virtual Agent topics（Zurich）でも説明されています。

実機で確認するときに見るべきURL

最後に、今回見た画面を自分のインスタンスで開くためのURLをまとめます（<YourInstance> は置き換えてください）。

# トピックの一覧（有効なものを名前順）
https://<YourInstance>/sys_cs_topic_list.do?sysparm_query=active=true^ORDERBYname

# トピックを type でグループ化
https://<YourInstance>/sys_cs_topic_list.do?sysparm_query=GROUPBYtype

# トピックを model_type でグループ化
https://<YourInstance>/sys_cs_topic_list.do?sysparm_query=GROUPBYmodel_type

# sys_cs_topic のフィールド定義
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_cs_topic^elementISNOTEMPTY

まとめ

Virtual Agent のトピックは sys_cs_topic の1行＝1つの会話シナリオとして保存される。
sys_cs_topic は業務レコードではなく、sys_metadata（Application File）を継承する設定（メタデータ）。更新セットで移送する対象。
発話からの起動は key_phrases（認識キーワード）× model_type（NLU/Keyword か LLM）で決まる。PDI 実機は NLU/Keyword 20件・LLM 9件・空 45件。
トピックの type は4種（STANDARD / TOPIC_BLOCK / SETUP_TOPIC / CUSTOM_INPUT）。PDI 実機 74件中 STANDARD が34件で最多。sys_cs_topic_block という別テーブルはなく、TOPIC_BLOCK は type の値。
状態は active（73件）・published（全74件）・is_system_topic（36件）で表され、内部用と利用者向けがほぼ半々。
起動したトピックは会話フローを進め、その実体は sys_cs_conversation（PDIでは0件）に記録される。会話フローの中身と NLU/LLM の内部処理は検証範囲外。

Virtual Agent のトピックが分かると、他の仕組みともつながって見えてきます。自動化を担うのは Flow Designer（自動化）です。申請につながるのはサービスカタログ（申請）です。知識の提示元になるのはナレッジ（AI Search の提示元）です。会話の埋め込み先になるのは Service Portal（埋め込み先）です。「会話・自動化・申請・知識・画面」という形で、ひとつにつながって見えてきます。