ServiceNow Platform Toolsの使い分け｜VTB・Analytics・Virtual Agent・Workflow Studio

Visual Task Boards、Platform Analytics、Virtual Agent、Workflow Studioは、いずれもServiceNow上で業務を改善する機能ですが、目的は大きく異なります。VTBは作業の可視化、Platform Analyticsはデータの分析、Virtual Agentは対話型セルフサービス、Workflow Studioは処理の自動化です。

機能名だけを暗記すると、「グラフを作るならVTB」「チャットならFlow」といった混同が起きます。本記事ではPDIで実在する入口・レコード・実行結果を確認し、どの画面で何を作り、どのDBレコードや業務データに影響するかを分けて説明します。

4機能の使い分け

Visual Task Boards：一覧をカンバンへ変える

VTBはServiceNowのリストをカンバン形式のボードへ変換し、カードをドラッグして状態変更や分類を行う機能です。PDIの管理用Boardフォームには「このフォームは管理・デバッグ用。作成や変更はMy Task BoardsまたはShow Visual Task Boardへ」という注意が表示されていました。そのため、記事用の見栄えを作る目的で管理テーブルへ直接レコードを挿入せず、正規入口を確認しました。

基本手順

1. AllメニューからVisual Task Boards > My Task Boardsを開きます。
2. 既存リストから作る場合は対象リストを絞り、Show Visual Task Boardを使います。
3. レーンの意味をState、Assignment groupなど業務上の列へ合わせます。
4. カード移動が元レコードのどのフィールドを更新するかを確認します。
5. メンバー、共有範囲、個人情報の露出をレビューします。

VTBのベストプラクティス

• 「見やすいから」ではなく、会議や日次判断で更新する対象を選ぶ
• ボードと元リストのフィルタ条件を一致させる
• レーンを増やし過ぎず、状態遷移が分かる粒度にする
• 大量データの集計・傾向分析はVTBではなくPlatform Analyticsを使う

Platform Analytics：DBレコードを分析可能な可視化へする

Platform Analyticsは、TableやIndicatorなどのデータソースからData visualization、Dashboard、Filter、KPIを管理する統合分析画面です。PDIではPlatform Analytics > Library > Data visualizationsを開き、131件の可視化レコードが表示されることを確認しました。空一覧や古いReports画面を「Platform Analyticsの証拠」として使わず、現在のLibraryを撮影しています。

Data visualization作成時の入力

1. 何を判断するための可視化かを1文で決めます。
2. データソースをTableかIndicatorかで選びます。
3. 集計方法をCount、Sum、Averageなどから選びます。
4. Group byとFilterを設定し、母集団を明示します。
5. 閲覧Role、共有先、更新頻度、認証済み表示の責任者を決めます。

Platform Analyticsのベストプラクティス

可視化を作る前に「件数」「割合」「推移」「目標との差」のどれを知りたいか決めます。Incident件数だけを表示しても改善行動につながらない場合は、期限超過率、平均解決時間、再オープン率などの定義を揃えます。タイトルへ母集団と期間を入れ、Filterが見えない場所でも誤解しない命名にします。

公式ドキュメントでは、Platform Analytics experienceはAnalytics OverviewとLibraryを中心に、Dashboards、Data visualizations、Filters、KPI Detailsなどを扱うと説明されています。Core UI Reportsが残る環境もあるため、試験や実装ではUI世代を区別します。

Virtual Agent：会話をTopicとして設計する

Virtual Agentはチャット画面そのものの名称だけではありません。利用者の目的をTopicとして設計し、入力、応答、分岐、Action、再利用可能なTopic blockなどを組み合わせます。PDIではTables一覧でsys_cs_topicを検索し、Topicと関連テーブルが存在することを確認しました。

この画像が証明するのはTopicの保存構造がPDIにあることまでで、会話が期待どおり実行された証拠ではありません。実装記事で「動かした」と言うには、Assistant DesignerまたはVirtual Agent DesignerでTopicを開き、Testで会話を最後まで通し、入力・分岐・結果レコードを確認する必要があります。

Virtual Agent Topicの基本手順

1. 解決したい利用者目的を1つに絞ります。
2. 使用できるライセンスとLLM / NLU・keywordの方式を確認します。
3. 入力、確認、分岐、Action、完了メッセージを設計します。
4. 実在する前提データと失敗ケースでTestします。
5. Inactiveのままレビューし、公開後の発見率・離脱率・解決率を観測します。

Virtual Agentのベストプラクティス

• Topic名ではなく利用者が達成したい目的から設計する
• 1つのTopicへ多数の業務を詰め込まない
• 本人確認、機密情報、書き込みActionにACLとサーバー側検証を適用する
• 失敗時に有人対応やKnowledgeへ戻れる経路を用意する
• Publish前に複製・Test・レビューを行い、直接本番Topicを編集しない

Workflow Studio：TriggerからDB更新まで実動作で確認

Workflow Studioでは、検証用Flow「Codex Demo – Add work note」を作成しました。TriggerはIncident Created、条件はShort descriptionが検証文字列と一致する場合だけです。ActionはTriggerのIncident RecordをUpdate Recordへ渡し、Work notesへ「Flow Designerが作成後に追記しました。」と設定します。

FlowはActivateせずDraft / Inactiveのまま、Testで対象Incidentを指定しました。これにより、検証以外のIncident作成へ継続的な影響を与えません。実行後のExecution DetailsではTriggerとUpdate RecordがCompletedになり、4373msで完了したことを確認しました。

さらに対象Incident INC0010008を開くと、ActivityにFlowが追加したWork notesが残っていました。ここまで確認して初めて、「Flow設定が保存された」ではなく「Flowが実行され、業務レコードのJournalフィールドへ結果を書き込んだ」と言えます。

Workflow Studioのベストプラクティス

• Trigger条件を業務対象まで絞り、全レコードで動くFlowを避ける
• Action間は固定値ではなく、正しいTrigger RecordのData pillを渡す
• 同じ更新で再度Triggerされる再帰や二重実行を確認する
• 機密値をExecution Detailsへ残し過ぎない
• Testは成功だけでなく、レコードなし、権限不足、Action失敗も試す
• Activate前に所有者、エラー通知、ロールバック、停止手順を決める

同じ要望を4機能へ誤配分しない判断例

CSA理解確認問題

問題：担当者がIncidentの月別件数と平均解決時間をDashboardで追跡し、共有したいと考えています。最も適した機能はどれですか。

1. Visual Task Boards
2. Platform Analytics
3. Virtual Agent
4. Workflow Studio

まとめ

4機能は「画面が新しい」「ノーコードで使える」という共通点より、成果物で分けると理解しやすくなります。カードならVTB、可視化ならPlatform Analytics、会話ならVirtual Agent、処理ならWorkflow Studioです。記事や設計書で実動作を示すときは、入口画面だけでなく、実レコード、実行履歴、更新された対象データまで確認します。

CSA学習ガイド ／ Business RuleとFlow Designerの違い ／ CSA練習問題

公式資料

• ServiceNow: Visual Task Boards
• Platform Analytics experience
• Assistant Designer Asset library
• Create a Virtual Agent topic