ServiceNowには最初から50本のガイドツアーが入っている（sys_embedded_tour_guide）
アプリケーションナビゲータにある「Guided Tour Designer」は、ServiceNow 自身が持つ 製品画面に重ねて手順を案内する機能 の入口です。画面上の特定の要素に吹き出し（コールアウト）やスポットライトを表示し、「次はここを押す」「この欄に名前を入れる」と一歩ずつ誘導します。Incident や Change といったコア機能に比べると表に出る場面が少なく目立ちませんが、公式に文書化された標準機能です。
この機能には、OOTB（初期設定）の時点で50本のツアーが同梱されています。同梱先は Platform Analytics のハブ、各種ワークスペース、Flow Designer など。この記事はプロセス論を扱いません。ツアーを保存しているテーブル sys_embedded_tour_guide と、各ステップを保存する sys_embedded_tour_step の実データを読みます。定義の構造、実測の分布、作成の入口の順に見て、どこまでが確認済みでどこからが検証範囲外かを分けて記録します。
この記事は、製品に組み込まれたガイドツアーの定義とステップを実機で確認したい管理者・開発者 を想定しています。実機で確認するときに開くべきテーブルと一覧 URL、読み取るべきフィールドを扱います。
この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、ツアーの数・内容・対応画面が異なる場合があります。
Guided Tours とは何か
Guided Tours（ガイドツアー）とは、製品画面の上に案内用の吹き出しやスポットライトを重ねて、操作手順を対話的に見せる機能 です。オンボーディングや新機能の紹介で「まずここを押して、次にこの欄を埋める」と示したいとき、ドキュメントを別に開かせるのではなく、画面の中で直接誘導できます。
ServiceNow では、この1本のツアーが sys_embedded_tour_guide テーブルの1レコードに対応します。ツアーの中の各ステップ（吹き出し1個ぶん）は、別テーブルの sys_embedded_tour_step に分かれて保存されます。作成・編集の窓口はアプリケーションメニューの「Guided Tour Designer」で、GUI 上でステップを並べていく仕組みです。名前に "embedded" と付くとおり、もともとは Embedded Help（製品内ヘルプ）の系譜にある機能です。いまはワークスペースや Next Experience のページにも対応が広がっています。
目立ちにくい理由は構造にあります。OOTB のツアーの多くは特定の画面を開いたときだけ、その場で起動するように作られていて、普段の一覧やフォームの画面にはツアーの一覧そのものは現れません。まとめて見るには、次に示す定義テーブルの一覧を開く必要があります。
どんなツアーが入っているのか
まず、実際に何が入っているのかを一覧で見てみます。次の画面は、有効なツアーだけを type 順に並べたものです。
列を見ると、各ツアーが持つ情報が読み取れます。Name（名前）、Type（種別）、Status（状態）、そして Context には適用先が入ります。Context の値には pa_dimensions_list・pa_indicators_list・contract_sla などが入ります。ほかに incident・$flow-designer・$interactive_analysis もあり、テーブル名や画面の識別子です。つまり どの画面で意味を持つツアーなのか が、この Context から追えます。名前を眺めるだけでも傾向が読み取れます。案内は Platform Analytics 関連（PA Breakdown Sources、PA Indicators など）や SLA 設定、Flow Designer に集中していました。管理・分析寄りの機能が中心です。
Tour ID 列にも特徴があります。TOUR0000007（Flow Designer View Toggle）のように ID が振られているツアーがある一方、多くの OOTB ツアーは Tour ID が空（empty）です。ID の有無は後述する type とも関係していて、Custom 型のツアーには ID が付く傾向がありました。
1本を開くと、ツアー定義のフォームが見えます。
このフォームには、ツアーを成り立たせている要素がひととおり並んでいます。Type は Workspaces、Context は now/builder/ui/experience（UI Builder の画面）でした。起動時に必要なパラメータは Route Parameters に JSON で入っていました。画面上部の「Edit with Designer」ボタンから GUI 編集に移れます。関連リンクの「Override tour Auto Launch preferences」で自動起動の設定を上書きできます。フォーム下部の「Guided Tour Steps」関連リストには、そのツアーのステップが順番に並び、order 0 が Introduction、そこから Step が続いていました。
注目したいのは、フォーム上部の帯です。「This record is in the UI Builder application and cannot be edited.」と表示されていました。このレコードは UI Builder アプリに属し、編集できないという意味です。OOTB のツアーは、それぞれが特定のアプリ（Private app）に属しているため、標準では読み取り専用として扱われます。
実際に動くツアーの見え方
定義テーブルを眺めるだけでは、ツアーが画面でどう見えるかは分かりません。Service Operations Workspace の On-call スケジュール画面（/now/sow/schedules）を開きました。そこで「Create an On-call Schedule」ツアーを起動し、利用者の目に映る様子を確認しています。起動は画面右上の「?」（Help Center）から「Guide me」で行えます。
ツアーを始めると、まず導入のモーダルが出ます。右側の Help Center には「Currently viewing : Guided tour」とツアー名、進捗の 0%、そして「End Tour」ボタンが表示されました。
「Begin tour」を押すと、案内が1ステップずつ進みます。次の画面では、吹き出しがカレンダー上部の「Create shift」ボタンを矢印で指し、「Click Create shift button.」と操作を促していました。吹き出しの右上には「1 / 10」と、全10ステップ中の現在地が出ます。
ボタンを押して次に進むと、開いたフォームの横に説明の吹き出しが出ます。ステップ 2 / 10 では、新規シフト作成フォームの各項目（Create new・Use template・All day shift・More options）を箇条書きで説明していました。「Next」ボタンで先へ進める形です。ステップの content に保存された HTML が、こうして画面上の吹き出しとして描画されます。
sys_embedded_tour_step に保存された内容が、実行時にはこの吹き出しとして順番に現れます。Help Center の「End Tour」を押せば、途中でも終了できます。
ツアー定義の構造（sys_embedded_tour_guide）
一覧とフォームで見た項目を、テーブルのフィールドとしてまとめます。sys_embedded_tour_guide の主なフィールドは次のとおりです。
name / description … ツアーの名前と説明
type … 対応する画面の種別（Workspaces / Custom / Platform など）
status … Published などの公開状態
active … 有効・無効の切り替え
context … 適用先の画面識別子（テーブル名や $flow-designer などのキー）
roles … 表示対象を絞るロール
autolaunch_order … 自動起動の順序。値が入っていれば、対象画面を開いたときに自動で始まる
has_intro / has_concl … 導入・結びのステップを持つか
route_parameters / additional_parameters … 起動時に渡すパラメータ
これらの値が、50本のツアーの中でどう散らばっているかを実測しました。
type は Workspaces が36本と過半 を占め、OOTB のツアーが各種ワークスペース向けに厚く用意されていることがわかります。status は Published が41本で、多くが公開状態でした。active はほぼすべて（48本）が有効です。
autolaunch_order と roles は、運用に直接効きます。自動起動の設定を持つツアーが40本 あり、対象画面を開いた時点でツアーが立ち上がる作りが主流だと読み取れました。ロールを指定したツアーは19本あり、担当ロールのユーザーにだけ案内を出します。全ユーザーへ一律には出しません。導入時に「誰に、いつ出すか」を絞れる設計だと読み取れます。
ツアー定義の一覧は、次の URL で直接開けます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。
https://<YourInstance>/sys_embedded_tour_guide_list.doステップの構造（sys_embedded_tour_step）
ツアーの中身は、ステップの並びで決まります。1つのステップが、画面上に出る吹き出し1個に対応します。sys_embedded_tour_step の主なフィールドは次のとおりです。
guide … 親となるツアーへの参照
order … ツアー内での表示順
step_type … Introduction / Step / Conclusion の種別
content … 吹き出しに表示する内容（HTML で保持）
target / target_ref … ハイライトする画面上の要素
placement … 吹き出しを対象要素のどちら側に出すか
action / action_event / action_target … 次に進むための操作の指定
skippable / link / view / window … 補助的な設定
実際に1本のツアーのステップを開くと、順序と内容の対応が見えます。次は「Create a page from scratch」のステップ一覧です。
order 0 が導入（Welcome の挨拶）で、そこから order 1、2、3… と手順が続きます。Content 列を見ると、中身が <p>Welcome!</p> のような HTML 断片 であることがわかります。ほかにも <p>Select <strong>Create a new page</strong></p> のような HTML が入ります。太字や段落を HTML で表現し、吹き出しの中にそのまま描画する仕組みです。Placement 列は Bottom / Right / Top / Left と切り替わっていて、案内する要素の位置に合わせて吹き出しの向きを変えているとわかります。なお、このツアーでは Target 列が空で Window だけが埋まっており、ワークスペース系のツアーでは対象の指定方法が要素そのものとは限らない点も見て取れます。
種別をまたいで、有効なステップを横断で見たものが次の画面です。
ステップ全体の分布を実測すると、次のようになりました。
step_type は Step が419件 で大半を占め、Introduction と Conclusion がそれぞれ30件台です。ツアーの多くが「導入 → 複数の手順 → 結び」という素直な流れで組まれているとわかります。placement は Bottom が212件と最多で、対象要素の下に吹き出しを出す形が基本でした。上下左右の四方向がひととおり使われているのは、案内する要素の位置に合わせて向きを選んでいるためだと読み取れます。
535件というステップ数は、50本のツアーで平均すると1本あたり約10ステップです。実際、「Create a page from scratch」は15ステップ、Flow Designer 関連のツアーは数ステップと、ツアーごとに長さの幅がありました。
どこで作り、どこで触るか
自作のツアーを追加したいときの入口は、アプリケーションメニューの「Guided Tour Designer」です。ここから対象の画面を開いてツアーを作成し、案内したい要素をクリックしながら吹き出しを配置します。GUI 中心の操作で、ステップの順序や文面をその場で組み立てられます。
既存の OOTB ツアーを見たいだけなら、テーブルの一覧を直接開くのが早道です。前掲の sys_embedded_tour_guide_list.do で定義を確認できます。ステップは sys_embedded_tour_step_list.do で、それぞれレコードとして見られます。ただし前述のとおり、OOTB のツアーは特定の Private app に属しているものが多く、フォームを開くと「cannot be edited」と表示されて編集できない場合があります。中身の参考にはできますが、そのまま書き換える前提の対象ではない、と捉えておくのが無難です。
自動起動の挙動を調整したいときは、ツアーフォームの関連リンク「Override tour Auto Launch preferences」が窓口になります。どのユーザーに、どの条件で自動起動させるかといった設定は、この上書きを通じて扱う形です。細かな挙動（既読の記録先など）の実測は本記事の範囲を超えるため、ここでは入口の存在だけ記録します。
使いどころと注意点
Guided Tours が向いているのは、社内導入時のオンボーディングや、新しいワークスペースの操作案内 です。マニュアルを別途配る手もありますが、Guided Tours なら実際の画面の上で「次はここ」と示せるため、はじめて触るユーザーの迷いを減らせます。ロール指定と自動起動を組み合わせれば、「特定の担当者が対象画面を開いたときにだけツアーを出す」といった出し分けもできます。
一方で、いくつか前提もあります。type が Workspaces のツアーは、対応するワークスペースやライセンスがある画面でこそ意味を持ちます。OOTB ツアーの Context がワークスペースや Platform Analytics に寄っているのも、そうした前提を反映したものです。また OOTB ツアーは基本が読み取り専用です。既存のものを直接は編集せず、Guided Tour Designer で自分のツアーを新しく作る進め方になります。content が HTML である以上、文面の作り込みには多少の HTML の知識も要ります。
ServiceNow の Guided Tours のポイント
Guided Tours は 製品画面に吹き出し／スポットライトを重ねて手順を案内する機能 で、1本のツアーが sys_embedded_tour_guide の1レコードに対応します。今回の PDI では OOTB で50本が同梱されていました。
ツアー定義は type / status / active / context / roles / autolaunch_order などのフィールドを持ちます。type は Workspaces が36本 と多く、自動起動40本・ロール指定19本と、出し分けの仕組みが実際に使われています。
各ステップは sys_embedded_tour_step（今回535件）に分かれ、order で順序、content（HTML）で表示内容、placement で吹き出しの向きを決めます。step_type は Step が419件、placement は Bottom が212件で最多でした。
作成の入口は Guided Tour Designer、閲覧はテーブル一覧です。OOTB ツアーは Private app に属し、多くが読み取り専用として表示されます。
使いどころは社内オンボーディングで、type=Workspaces のツアーは対応画面・ライセンスが前提になります。
ガイドツアーを調べるときは、まず sys_embedded_tour_guide の一覧で「どの画面（context）に、どんなツアーがあるか」を見ます。次に1本を開き、Guided Tour Steps 関連リストで order と content の並びを追うのが基本です。この順番だと見通しよく進みます。
その他、実機で確認した記録
ここからは実機確認用の記録です。読み物としては飛ばして構いません。すべて PDI（Zurich / 2026-07-12 確認）の OOTB の値です。
用語
PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
Guided Tours：製品画面に吹き出し／スポットライトを重ねて手順を案内する機能
sys_embedded_tour_guide：1本のツアーを格納するテーブル
sys_embedded_tour_step：ツアーの各ステップ（吹き出し1個ぶん）を格納するテーブル
Guided Tour Designer：ツアーを作成・編集するアプリケーションメニュー
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
ツアー定義の一覧 : sys_embedded_tour_guide_list.do
ステップの一覧 : sys_embedded_tour_step_list.do
有効なツアーのみ : sys_embedded_tour_guide_list.do?sysparm_query=active=true^ORDERBYtype
1本のステップ : sys_embedded_tour_step_list.do?sysparm_query=guide=<ツアーのsys_id>^ORDERBYorder実測の要点（再掲）
ツアー定義（sys_embedded_tour_guide）：50件。type=Workspaces 36 / Custom 3 / Platform 2 /（空）9。
ツアー定義の状態：status=Published 41、active=true 48、autolaunch_order 非空 40、roles 指定あり 19。
ステップ（sys_embedded_tour_step）：535件。step_type=Step 419 / Conclusion 37 / Introduction 34 /（空）45。
ステップの placement：Bottom 212 / Left 124 / Top 103 / Right 96。
関連記事
ServiceNow 画面・フォーム完全ガイド：どこを直せば見た目が変わるのか — ガイドツアーが重なる画面そのものの構成をどこで直すかをまとめた記事です
検証範囲とおことわり
確認した範囲は次のとおりです。
sys_embedded_tour_guide の件数（50件）と主なフィールド
type / status / active / autolaunch_order / roles の分布
sys_embedded_tour_step の件数（535件）と step_type / placement の分布
フォームと一覧の実画面
OOTB ツアーが Private app に属して読み取り専用表示になること
すべて PDI（Zurich / 2026-07-12 確認）の OOTB で REST 経由で取得しています。
確認していない範囲（断定しません）は次のとおりです。
実際の画面上でツアーがどう表示されるか（吹き出し・スポットライトのアニメーション）
autolaunch の発火条件とユーザーごとの既読管理の記録先
Guided Tour Designer の GUI 操作の詳細
target による要素ハイライトの実挙動
対応ワークスペース／ライセンスごとの差異
これらは対象画面を開いて実際に起動させる必要があり、本記事は REST 定義の実測に留めます。
今回は PDI の OOTB（初期設定）を前提に、Guided Tours（sys_embedded_tour_guide）の構造を確認しました。実環境では、既存のカスタマイズや導入済みアプリによってツアーの数・内容・対応画面が変わります。
