どの処理が動いたかを確認する方法（Session Debug / Field Watcher）

ServiceNow で「思った値が入らない」「なぜかこの項目が消える」と言われたとき、どこから手を付けるでしょうか。

値を変えうるものは複数あります。候補になるのは Business Rule や Client Script、UI Policy や ACL、Flow、既定値です。手当たり次第に探すと時間がかかります。

ServiceNow には、どれが効いたのかを確認する機能が最初から入っています。この記事では、PDI（Personal Developer Instance / Zurich / OOTB）で確認した10個の方法と、それぞれの使いどころをまとめます。

想定読者は、Business Rule や Client Script は書けるものの、動かないときの調べ方が「ログを仕込んで試す」に偏っている人です。

この記事で分かること

• レコードの本当の中身を、フォームの表示に左右されずに見る方法

• ある項目の値を「誰が」変えたのかを記録させる方法

• どの Business Rule が発火したかを画面に出す方法

• 症状ごとに、どのデバッグ機能を選べばよいかの目安

• デバッグ出力に出る行の意味と、実行順との対応

• インスタンスの内部状態を見る診断用の画面

Show XML でレコードの素の中身を見る

フォームのヘッダを右クリックして Show XML を選ぶと、そのレコードが XML で表示されます。

フォームのレイアウトに左右されないのが利点です。次の3つを、表示を介さずに確認できます。

• 画面に配置されていない項目

• 参照先が削除されて表示が空になっている項目

• 表示ラベルではなく、実際に格納されている値

「画面では空に見えるのに処理が動く」という場合、表示と格納値がずれていることがあります。ここで見分けられます。

URL からも同じ内容を取得できます。

incident_list.do?XML&sysparm_record_count=2

既定では管理者だけが使えます。理由は単純で、レコードの生の値を誰でも見られると困る場面があるからです。他のロールにも開放したい場合は、右クリックメニューを定義する sys_ui_context_menu の条件を調整します。メニュー項目の追加手順はList context menusを参照してください。

Field Watcher で「誰が値を変えたか」を記録する

項目を右クリックして Watch field を選ぶと、その項目の値が変わるたびに、何が変えたのかが時系列で記録されます。

既定値・UI Policy・Client Script・Business Rule・ユーザー入力のどれが変えたかが記録の対象です。「保存すると値が戻る」という現象の原因を特定できます。公式ドキュメントのWatching fieldsでも、フィールドの値を変更した処理を追跡する機能として説明されています。

使うには、歯車アイコンから Developer を開き、「JavaScript Log and Field Watcher」を有効にします。その状態で項目を右クリックすると、メニューに Watch field が現れます。

記録は蓄積型です。1回のフォーム操作で値が複数回書き換わる場合、その全部が発生順に並びます。最後に勝った処理がどれかは、一覧の一番下を見れば分かります。

制約もあります。暗号化フィールドでは使えません。また Next Experience では対応していないため、Classic UI（UI16）で開く必要があります。

たとえば、保存すると status が自動的に「In Progress」へ戻ってしまう現象があるとします。Field Watcher を有効にして再現操作をすると、変更元の Business Rule 名が記録に残ります。犯人を推測する手間がありません。

Session Debug でどのルールが動いたかを出す

System Diagnostics > Session Debug には、発火したスクリプトの種類ごとにログを出す機能がまとまっています。公式ドキュメントのDebugging sessionsによると、現在のセッションで実行されたサーバー側の処理を画面上に表示する仕組みです。

System Diagnostics のメニューは、Classic UI の画面下部にあるツールバーから開きます。表示や切り替えには、相応の権限が要ります。

Debug Business Rule が出す情報

Debug Business Rule を有効にすると、画面の下に、そのページで発火した Business Rule の一覧が出ます。

発火順、条件の評価結果、かかった時間が並びます。「動くはずのルールが動いていない」のか「動いているが条件で弾かれている」のかが、ここで切り分けられます。詳しい出力の読み方はDebugging business rulesを参照してください。

Debug Security Rules が出す情報

Debug Security Rules を有効にすると、各項目の横に虫のアイコンが出ます。クリックすると、その項目に対する ACL の評価結果が見られます。

通ったか、落ちたか、どのルールが効いたかまで表示されます。「なぜかこの項目が読めない」という調査は、ロールを付け替えて再現させる前に、まずこの画面を見るのが早道です。

これらの出力は画面に出るだけで、syslog テーブルには残りません。調査が終わったら無効に戻します。

デバッグ出力の読み方

Business Rule の発火順は、テーブルの order 列と when（display / before / after / async）で決まります。この実行順はExecution order of scripts and enginesに製品仕様として定義されています。

Debug Business Rule の出力に並ぶ行は、この実行順と対応しています。上から display、before、保存後の after、最後に async という並びです。同じ when の中では order の値が小さいものから実行されます。

条件式で弾かれたルールも一覧には出ます。ただし状態を示すマークが「実行しなかった」側になっているだけです。ここを見落として「動いていない」と早合点しないよう、全行を実行の有無まで含めて確認します。

どのデバッグをいつ使うか

症状によって最初に開く画面を変えると、原因にたどり着くまでが早くなります。

値が入らない、あるいは保存後に消える場合は Field Watcher から始めます。変更元のスクリプトが記録に残るため、犯人探しの時間を節約できます。

権限が原因で項目やレコードが見えない場合は Debug Security Rules です。ACL 単位で通過・却下が分かるため、ロールの当て推量をせずに済みます。

想定したルールが動かない、あるいは動いてほしくない場面で動く場合は Debug Business Rule です。条件式の評価結果まで出るため、条件文を1行ずつ疑わずに済みます。

通知やメールが届かない場合は、後述する gs.info() と syslog の組み合わせで追います。処理が重い、あるいは返ってこない場合は、これも後述する threads.do と stats.do の出番です。

SQL単位の重さを個別に見たいという要望もよくあります。ただしこの記事では、公式ドキュメントで裏付けが取れる範囲に絞っているため、SQL に特化した機能は扱いません。まずは threads.do と stats.do で全体の状況をつかむ流れをおすすめします。

Background Script で使い捨てのスクリプトを流す

sys.scripts.do

Background Scripts は、その場でコードを書いて、その場で実行する画面です。保存や配布を前提としない、使い捨てのスクリプト実行に向いています。公式ドキュメントのBackground Scripts moduleでも、開発・テスト用の実行環境として説明されています。

Background Script と Fix Script の違いは次のとおりです。

Background Script はコード自体が残らないため、あとから何を流したかをレビューできません。本番のデータ修正には Fix Script を使います。

実行そのものはロールバック用に記録されています。実行後に出る「Script execution and recovery available here」からの巻き戻しが可能です。同じ環境で複数人が並行して作業する場合は、他人の実行結果と自分の実行結果を混同しないよう注意します。詳しい注意点はBackground Scripts supportを参照してください。

gs.print と gs.info と Debug Log の出力先

ログを仕込むとき、どこに出るかを知らないと探し回ることになります。

使い捨ての確認は gs.print()、後から追いたいものは gs.info() と使い分けます。公式ドキュメントのWriting to the debug logにも、デバッグ用の出力先を分ける考え方が説明されています。

gs.info() を使うときは、第2引数に区別用の文字列を渡します。syslog の Source 列で絞り込めるようになります。

gs.info('対象 ' + gr.getValue('number'), '棚卸2026-08');

syslog は放っておくと膨れます。PDI でも約79万件ありました。定期実行のジョブの中で無造作にログを吐くのは避けます。

スコープドアプリの中では gs.print() は使えません。代わりに gs.debug() を使います。出力先は gs.info() と同じ syslog です。

threads.do で今動いている処理を見る

threads.do

threads.do を開くと「Servlet thread information」という一覧が表示されます。いまインスタンス上で動いている処理の一覧です。

「重い」「返ってこない」というときは、まずここで何が走っているかを確認します。一覧を見れば、原因の処理が動いているかどうかがすぐに分かるからです。自分の処理を止めたい場合は cancel_my_transaction.do を開きます。中断すると「Cancel Notification」という応答画面に切り替わります。

stats.do でノードと構成を確認する

stats.do

開くと「Servlet statistics」という一覧が表示されます。接続中のノード名、システム構成、メモリの状況が並びます。PDI での応答サイズは28KBでした。

複数ノード構成の環境で、特定のノードだけ挙動が違うときの切り分けに使います。XML 形式で全項目がほしい場合は xmlstats.do を使いますが、PDI での応答は17.7MBありました。丸ごと取らず、セクションを絞って取得するのが現実的です。この2つのエンドポイントの使い方はstats.do・xmlstats.doの解説（ServiceNow Community）にもまとまっています。

cache.do でキャッシュを落とす

cache.do

「GLIDE Servlet cache」という画面が開きます。応答は1KBほどの小さなページです。

辞書やリスト定義を変えたのに画面に反映されないときに使います。ただし影響の範囲はクラスタ全体です。本番で無造作に叩くと、全ユーザーがキャッシュ再構築の遅延を被ります。検証環境で使うものと考えてください。

system_diagnostic_database_page.do でDB基盤を確認する

system_diagnostic_database_page.do

データベースの診断ページが開きます。Driver 欄が PostgreSQL になっていれば、そのインスタンスは新しいデータベース基盤（RaptorDB）へ移行済みだと判断できます。

性能まわりの相談を受けたとき、まず前提を確認する場所として使えます。

$ で始まるUIページに直接飛ぶ

ServiceNow の新しめのツールは、$ で始まる URL を持っています。

$flow-designer.do

Zurich でこの URL を開くと、画面のタイトルは「Workflow Studio」になっています。 ネット上の記事の多くは「Flow Designer が開く」と書いていますが、リリースによって画面の名前が変わっています。

URL 自体は生きているので移動には使えます。人に説明するときの名前は、環境に合わせたほうが混乱がありません。

調べ物に効く一覧URL

調査でよく開くテーブルをまとめておきます。

どれも一覧画面の URL に条件を足しているだけです。sysparm_query で対象テーブルを絞り込めば、調査のたびに同じ画面をブックマークし直す必要がなくなります。

デバッグは必ず元に戻す

Session Debug も Field Watcher も、有効・無効の状態はセッションや sys_user_preference に紐づきます。切り忘れると、次の調査に入ったときに古い出力が残っていて混乱します。

共有アカウントで作業している場合は、とくに注意が必要です。自分が有効にしたデバッグ表示が、別の担当者の画面にも出続けることがあるからです。調査が終わった時点で、必ずオフに戻します。

本番環境での利用には制約もあります。Debug Business Rule や Debug Security Rules は画面の描画のたびに評価結果を集計するため、通常より応答が遅くなるからです。障害調査で一時的に使う場合でも、対象ユーザーを絞り、確認が終わり次第すぐに無効化します。

つまずきやすい点

• Workspace や Next Experience では出ない。右クリックメニューや画面下のデバッグ出力は Classic UI（UI16）の機能です。Agent Workspace や Next Experience で同じ操作をしても、メニュー自体が現れません。

• 非同期処理は別セッションになる。Business Rule の async や Scheduled Job、Flow の一部は、元の画面のセッションとは別プロセスで実行されます。Session Debug は自分のセッションしか見ないため、これらの処理は一覧に出ません。syslog にログを仕込む方法へ切り替えます。

• 出力が多すぎるときは対象を絞る。Business Rule が多いテーブルでは一覧が長くなり読みにくくなります。まず対象のテーブルを1つに絞り、それでも多い場合はレコードを1件に絞って再現させます。

• Elevate Privilege 中は結果が変わることがある。ロールを昇格した状態と通常権限の状態では、ACL の評価結果が異なります。再現性を保つには、実際に問題が起きた権限のまま調査します。

よくある質問

Session Debug と Field Watcher はどちらを先に使うべきですか

症状で決めます。値そのものがおかしいなら Field Watcher、画面の見え方や権限がおかしいなら Session Debug です。両方の可能性がある場合は、まず Field Watcher で変更元を特定し、それが Business Rule なら Session Debug で条件式を確認する順番が近道です。

Debug Business Rule を有効にしても一覧に何も出ません

対象のページでサーバー側の処理が発生していない可能性があります。参照している画面が Next Experience やワークスペースになっていないかも確認します。Classic UI のフォームで再現させると確実です。

本番環境でも同じ手順が使えますか

機能自体は使えますが、権限が管理者に限定されていることが多く、性能への影響も考える必要があります。恒常的な調査環境としては PDI や検証環境を使うほうが安全です。

syslog に記録が残らないのはなぜですか

Session Debug の出力は、ブラウザにその場で描画されるだけの情報です。gs.info() のように明示的にログ関数を呼び出さない限り、syslog テーブルには書き込まれません。あとから追いたい情報は gs.info() で明示的に記録します。

Field Watcher で記録が途中から始まらないのはなぜですか

Field Watcher は、有効化した後に発生した変更だけを記録します。ページを開いた時点ですでに入っていた値の来歴までは追えません。原因不明の値を調べる場合は、値を戻してから、有効化した状態でもう一度操作して再現させます。

Debug Security Rules と ACL の一覧画面は何が違いますか

ACL の一覧画面は、定義そのものを確認する場所です。条件式や対象ロールを直接編集できます。一方 Debug Security Rules は、特定のレコードに対してその定義がどう評価されたかを見る機能です。定義を疑うか、評価結果を疑うかで使い分けます。

用語

• Session Debug: 現在のセッションで実行されたサーバー側処理を、画面上にログとして表示する機能群

• Field Watcher: 項目の値が変わるたびに、変更元の処理を時系列で記録する機能

• ACL: Access Control List の略。テーブルや項目単位での読み取り・書き込み権限を定義するレコード

• syslog: gs.info() などで出力したログが蓄積されるテーブル

• RaptorDB: PostgreSQL をベースにした、ServiceNow の新しいデータベース基盤

• Fix Script: Update Set に乗せて、環境をまたいで実行できる保存済みスクリプト

• Classic UI（UI16）: 右クリックメニューや Session Debug の出力に対応する、従来型の画面テーマ

検証範囲外のこと

• Script Debugger（ブレークポイントを置いてステップ実行するツール）は、今回は開いていません。サーバースクリプトを1行ずつ止めて変数を確認したい場合は、別途そちらを使います

• glide.rest.debug などのデバッグ用プロパティは、有効化すると性能に影響するため PDI でも試していません

• 右クリックメニュー系は Classic UI（UI16）の機能です。Next Experience やワークスペースでは別のUIになります

• Session Debug の各機能に必要なロールは、環境によって割り当てが異なる場合があります。開放範囲は自社の運用方針に合わせて調整してください

まとめ

調べる順番は次のとおりです。

1. Show XML でレコードの実体を見る。表示と中身のずれをまず消す

2. Field Watcher で、値を変えた処理を記録させる

3. Session Debug でどのルールが発火したかを出す

4. それでも分からなければ gs.info() を仕込んで syslog で追う

ログを仕込むのは最後です。先に上の3つを使えば、仕込む場所を絞り込めます。

どの機能も、原理は同じです。ServiceNow が内部でどう処理したかを、画面の外に出して見せているだけです。特別な予測や勘に頼らなくても、たどれる形で答えが残ります。

デバッグの表示は必ずオフに戻します。切り忘れは次の調査を混乱させるだけでなく、共有環境では他の担当者にも影響します。

検索欄に打つだけの小ワザ、URL に足すだけの小ワザについては、それぞれ別の記事にまとめています。