ServiceNowが遅いときどこを見る？ 5秒超の97.5%はジョブで一覧は9件だった
「システムが遅い」という報告を受けたとき、最初にどこを見るでしょうか。ログ全体を眺めるだけでは、遅いのが画面なのかバックグラウンドジョブなのか区別がつきません。Zurich PDIのsyslog_transactionを種別（type）で絞り、5秒を超える処理の内訳を実機で数えました。
検証環境：Zurich PDI / OOTB / 2026-08-08 確認
結論：type で絞る、遅いのはジョブ、SQL回数だけが原因ではない
先に全体像です。
遅い処理を疑うときは、応答時間の大きい順に並べるだけでなく type（種別）で絞るのが先です。type を見ずにログ全体を眺めると、バックグラウンドジョブの遅さを見て「画面が遅い」と誤診します。
5秒を超えるトランザクションを種別ごとに数えると、Scheduler（バックグラウンドジョブ）が大半を占め、List（一覧画面）はごくわずかでした。遅いと騒がれているものの正体は、たいてい人が画面で待っている処理ではありません。
応答時間が長くてもSQL回数・SQL時間がまったく大きくないトランザクションがあります。SQL回数の多さだけを原因と決めつけると、待ち時間の正体を取り違えます。
図の色には意味を持たせています。濃紺は最初に見る起点で、緑は画面側で健全だった結果です。橙はジョブ側に処理が集中している状態を示し、赤は原因が確定した状態、灰は今回の検証範囲の外を表します。上から下へたどるだけで、次に何を見ればよいかが分かる形にしました。
全体像：syslog_transaction の何割が「遅い」のか
syslog_transactionはServiceNowが処理した1リクエストごとの応答時間を記録するテーブルです。フォームを開いた、一覧を絞り込んだ、スケジュールジョブが動いた。その一つひとつが1行として残ります。
PDIで件数を数えると、全体は46,056件でした。このうち処理時間が1秒（1,000ミリ秒）を超えたものは15,538件で、割合にして34%です。3件に1件が1秒を超えている計算になります。10秒を超えたものに絞っても6,116件、13%が残りました。8件に1件は10秒待たされている状態です。
数字は大きく見えます。この数字だけを見ると、ずいぶん遅いインスタンスだと感じるかもしれません。ただしこの数字には、画面を開いて待っている人の待ち時間と、深夜に動くバックグラウンドジョブの処理時間が、区別なく混ざっています。人が待っている遅さなのか、誰も見ていない裏側の遅さなのか。これを分けずに件数だけで語ると、実態とは違う印象を持ってしまいます。
次の疑問はシンプルです。遅いのは画面か、それともジョブか。件数を眺めているだけでは、この問いに答えられません。答えを出すには、typeという列で分けて、種別ごとの内訳を数える必要があります。次に見るべきは、この中身の内訳です。
type で絞ると見え方が一変する
5秒を超えたトランザクションは7,783件ありました。これを種別（type）ごとに集計します。
差は歴然です。Scheduler（バックグラウンドジョブ）が7,592件で全体の97.5%を占め、次いでRESTが94件、Formが64件と続きます。人が直接触る一覧画面（List）は、7,783件中わずか9件。割合にして0.1%でした。5秒超という数字だけを見て「画面が重い」と判断すると、この内訳を知らずに的外れな調査を始めることになります。
この時点で言えるのは単純な事実です。遅い処理の大半はバックグラウンドジョブであり、画面ではありません。内訳がすべてです。ログ全体の件数に驚く前に、まずtypeで絞る意味はここにあります。
一覧（List）で本当に遅いものはあるか
typeがListのトランザクションだけに絞って、応答時間の降順に並べてみます。
List全体は426件登録されていて、平均応答時間は668ミリ秒でした。多くの一覧は1秒もかからず開きます。それでも最大は13,903ミリ秒あり、上位を占めるのはプラグイン一覧（v_plugin_list）や更新セットの一覧（sys_upgrade_）、ATFのテスト結果一覧（sys_atf_test_l）といった、件数の多い管理系の画面でした。
incident_listも2件、この上位に顔を出しています。応答時間は10,396ミリ秒と5,833ミリ秒で、いずれもインシデント一覧を開いたときの記録でした。日常的に開く画面が遅くなる例は、皆無ではありません。ただし全体426件の中の2件であり、恒常的に遅いというより、特定のタイミングでの一時的な遅延だと考えるのが自然です。
フォーム（Form）はどうか
同じ絞り込みをFormでも行います。
Form全体は14,721件あり、平均応答時間はわずか241ミリ秒でした。フォームを開く操作は、体感でもまず遅さを感じない速度です。最大でも16,586ミリ秒で、これは$uxapp.do（Next Experience UIのシェル読み込み）が繰り返し上位に出ていました。UI Policyや大量のClient Scriptを抱えるフォームは、初回読み込みが重くなる傾向があります。ログイン直後のリダイレクト処理（login_redirect）も11,387ミリ秒で上位に入っており、セッション確立の直後は多少の遅さが出やすいことがうかがえます。
List・Formのどちらも、5秒を超える件数はごくわずかでした。画面側は基本的に健全という結論を、この2つの絞り込みが裏付けています。
SQL回数と応答時間は比例するとは限らない
次に、応答時間が長いトランザクションの中身を見ます。全体を応答時間の降順に並べると、上位には見覚えのある処理名が並びました。
先頭は「JOB: BackgroundProgressJob」で、応答時間は3,589,895ミリ秒です。同じ処理名が2位・4位にも登場し、応答時間はそれぞれ1,992,779ミリ秒・1,795,138ミリ秒でした。3位は「JOB: ASYNC: Upgrade Summary Job」、5位は「JOB: events process 0」です。上位5件すべてがジョブで、画面から発生した処理は一つも入っていません。
続いて10秒を超えたものを新しい順に並べます。
並んだ行の中に「JOB: Check Glide Service Status」という処理が繰り返し出てきます。応答時間は88,050ミリ秒から93,137ミリ秒の範囲でばらついていますが、SQL回数はどれも140回ほど、SQL時間は68ミリ秒から98ミリ秒にとどまっていました。応答時間の9割以上が、SQL以外の何かに費やされていることになります。
応答時間が最も長いトランザクションを表にすると、傾向がさらにはっきり見えます。
最も遅い「JOB: BackgroundProgressJob」は応答時間3,589,895ミリ秒でした。SQL回数は730,930回、SQL時間は2,256,711ミリ秒で、SQLだけで応答時間の63%を占めています。ここまで極端だと、DBが主因だという判断に迷いはありません。
一方で表の最後の行は「JOB: Check distribution for possible upgrade」です。応答時間1,149,238ミリ秒、約19分に対して、SQL回数はわずか351回、SQL時間は915ミリ秒でした。応答時間のほぼ全体が、SQL以外の待ち時間で説明されます。SQL回数が多いから遅い、少ないから速いという単純な図式は、ここでは成り立ちません。
5秒を超えたトランザクションの中で処理名を数えると、「Check Glide Service Status」が832件でもっとも多くありました。テーブルのクリーンアップ処理（table_cleaner）は153件、コンプライアンス計算（SC - Calculate Compliance）は39件と続きます。証明書失効リスト（CRL）を再生成するジョブも14件ありました。いずれも監視やメンテナンスの目的で定期的に動く処理です。画面由来で唯一目立ったのは/api/now/ui/polaris/menuの14件で、これはナビゲーションメニューを開いたときの内部APIでした。ジョブ由来の処理が上位を占める中で、画面から発生している処理は数えるほどしかありません。
こうして並べてみると、応答時間の長さと原因の種類は一対一で結びついていないと分かります。DBが重いのか、外部への呼び出しを待っているのか、内部のロックが解けるのを待っているのか。応答時間という1つの数字の裏には、いくつもの違う待ち方が隠れています。SQL回数とSQL時間を横に並べて比べることが、その違いを見分ける最初の一歩になります。
実機で気づいたこと
遅い処理を上から眺めるだけでは、画面の問題は見つかりません。5秒超は7,783件ありますが、そのうちListはたった9件です。割合にして0.1%。応答時間の降順で並べても、上位はジョブで埋まります。9件の中に答えがあっても、7,592件のジョブに埋もれて目に入りません。
だから順番が逆です。眺めてから絞るのではなく、最初に絞ってから眺める。画面の遅さを調べたいなら type=List や type=Form で先に絞り込みます。この一手間で、見る対象が7,783件から数十件になります。件数の少ない種別ほど、この絞り込みの効き目は大きくなりました。
比率も添えておくと判断が速くなります。Listの9件は5秒超のうち0.1%、Formの64件でも0.8%です。対してSchedulerは97.5%。この3つの数字を頭に入れておけば、報告を受けた時点で「まず画面から疑うべきか、ジョブから疑うべきか」の見当がつきます。とはいえ比率は環境によって違うもの。一度は自分の手で数えておきたいところです。本番環境では利用者の操作が多いぶん、FormとListの比率はこれより高く出ると考えられます。
発見はもう1つありました。応答時間の内訳に出てくる列の多さです。SQL回数・SQL時間だけでなく、ACL Timeという列も並んでいます。CMDBの集計処理を見ると、応答時間23,290ミリ秒のうちSQL時間は7,804ミリ秒、ACL Timeは327ミリ秒でした。合わせても応答時間の3分の1程度で、残りは依然として説明がつきません。最初はSQL回数さえ見ればおおよその原因が分かると思っていましたが、実機で数字を並べると、SQL・ACL・その他の待ち時間という3層で切り分ける必要がある処理が一定数あると分かりました。
Performance Analyticsのコレクター処理も応答時間282,202ミリ秒という記録を残していて、SQL時間は21,861ミリ秒でした。応答時間全体からするとSQLが占める割合は1割に満たず、こちらもSQL以外の待ち時間が大半を占めています。分析系のジョブは、収集対象の範囲が広がるほど、SQL以外の処理にも時間がかかりやすいという印象を持ちました。
一覧・関連リストの設定量に対して、遅い一覧はわずか
画面側がなぜ健全なのか、設定の量からも確認しておきます。
一覧の定義を持つsys_ui_listは4,652件、その列を定義するsys_ui_list_elementは23,980件登録されていました。
関連リストの定義sys_ui_related_listも1,540件あります。ビュー（sys_ui_view）は707件、ビュー切り替えルール（sysrule_view）も156件登録されていました。一覧まわりの設定は、テーブルの数だけ細かく作り込まれています。これだけの設定量がありながら、実際に5秒を超えて遅くなっている一覧はたった9件です。設定の複雑さと表示の遅さは、必ずしも比例しません。
数字を並べると理由が見えてきます。1つの一覧画面の裏には、レイアウト定義・列定義・関連リスト定義・ビュー・ビュー切り替えルールという何層もの設定が積み重なっています。層が厚いほど遅くなりそうに思えますが、実際に表示のたびに走るのはインデックスの効いたシンプルなクエリが中心です。設定の量は「作り込みの複雑さ」を表す数字であって、「実行時の重さ」を表す数字ではありません。この違いを混同すると、遅さの原因を見当違いの場所に探しに行くことになります。
実務では何に使えるか：遅いと言われたときの確認順
問い合わせを受けたとき、自分は次の順番で当たりを付けます。
まずtypeでグループ化し、Schedulerが大半を占めていないかを見ます。占めていれば、報告のあった画面そのものは、いったん疑わずに済むはずです。次に該当のtype（ListならList、FormならForm）に絞って応答時間の降順に並べ、実際に遅いレコードが何件あるかを数えます。最後にSQL回数とSQL時間を確認し、応答時間との差が大きい場合はSQL以外の待ち時間を疑う、という流れです。
近道はここです。この順番で進めれば、いきなり個別のスクリプトやACLの条件式を読みに行かずに済みます。手前の段階、特に最初のtypeによる絞り込みだけで、多くの「遅い」報告は的外れな調査に発展せず終わります。
チームで手順を引き継ぐときも、この5段階はそのままチェックリストにできます。typeを見た、対象のtypeで絞った、SQLを確認したと1つずつ消していけば、どこまで調べたかが誰の目にも分かる状態になります。急いでいるときほど、順番を飛ばして個別のスクリプトを読みに行きたくなりますが、手前の段階で解決する報告のほうが実際には多いというのが、件数を数えての実感です。
さらに詳しく知りたい人へ
遅い処理を特定する手順（syslog_transaction） — Transaction logを使った調査手順を、実際に打つクエリまで含めて整理した記事
スケジュールジョブが動かないときの調べ方：sys_triggerの読み方 — 今回遅さの大半を占めたSchedulerの実行予約側を追う記事
定期実行（sysauto_script）：定義と実行キューの2層 — Schedulerの処理がどのテーブル構造で動いているかの解説
よくある質問
Q1. 遅いという報告を受けたら最初に何を見ればいいですか
syslog_transactionをtypeでグループ化して、どの種別が件数を占めているかを見ます。Schedulerが大半であれば、報告のあった画面そのものよりも先にバックグラウンドジョブ側を疑う番です。応答時間の降順だけで並べると、画面もジョブも同じランキングに混ざってしまい、原因の方向を見誤ります。
Q2. Schedulerが遅いのは異常ですか
件数の多さだけでは異常とは言えません。今回のPDIでも5秒超の97%近くをSchedulerが占めていましたが、これは深夜バッチや監視系ジョブが積み重なった結果です。多いことと、遅すぎることは別の話です。異常かどうかは、そのジョブが本来どれくらいの時間で終わるはずかという基準と比べて判断します。単発の重い処理と、恒常的に時間がかかっている処理は、そもそも別物として扱うべきです。同じジョブ名の応答時間を数日分並べて、急に伸びていないかを見るだけでも、判断の手がかりになります。
Q3. SQL回数が少ないのに遅い場合は何を疑えばいいですか
SQL時間・ACL Time以外の待ち時間を疑います。今回確認した「Check distribution for possible upgrade」はSQL回数351回・SQL時間915ミリ秒に対して、応答時間が約19分でした。外部呼び出しの待ち、ロックの取得待ち、スクリプト内の意図的な待機など、SQL以外に時間を使う要因はいくつも考えられます。個別のトランザクションを開いて、URLと処理名から何のジョブかを特定するところから始めます。
Q4. Listで遅いものが1件だけあった場合、無視していいですか
比率が低くても、その1件が業務上重要な画面であれば無視すべきではありません。今回の検証でも、incident_listのように日常的に開く一覧が上位に含まれる例がありました。全体の傾向としては画面側は健全でも、個別の画面ごとに確認する価値はあります。
Q5. PDIでの実測は本番の参考になりますか
傾向をつかむ参考にはなりますが、数値をそのまま本番に当てはめることはできません。PDIは共有基盤で、他のユーザーの検証作業が同じインスタンスで動いています。応答時間の絶対値は、常に変動します。本番環境の負荷や同時アクセス数はまったく違うため、絶対値は別物として扱ってください。参考にできるのは、type別に見たときの内訳の傾向や、SQL回数と応答時間の関係が一致しないケースがあるという構造の部分です。数字そのものより、確認の順番と着眼点を持ち帰る記事だと考えてください。
まとめ
syslog_transactionは46,056件のうち34%が1秒超、13%が10秒超でした。数字だけを見ると重いインスタンスに見えますが、5秒超をtypeで絞ると、大半がScheduler（バックグラウンドジョブ）で占められていて、List（一覧画面）はごくわずかという結果になりました。
遅いという報告を受けたときは、応答時間の降順に並べる前に、まずtypeで絞ります。画面かジョブかを見分けたうえで、SQL回数とSQL時間が応答時間をどれだけ説明しているかを確認する。この順番を守ると、遠回りせずに原因の方向へたどり着けます。
件数は増えます。今日数えた46,056件も、来週開けばもっと増えているはずです。それでも「typeで絞る」という手順そのものは古くなりません。ログが積み上がるほど、絞り込みの効果はむしろ大きくなります。
用語
syslog_transaction（Transaction log） … 1リクエストごとの応答時間・種別・実行者を記録するテーブル
type … トランザクションの種別。Scheduler / List / Form / REST など
response_time … 総応答時間（ミリ秒）
sql_count / sql_time … そのトランザクションで発行されたSQLの回数と所要時間
ACL Time … アクセス制御（ACL）の評価に費やした時間
実機で調べるときに開いたURL
/syslog_transaction_list.do?sysparm_query=response_time>5000^GROUPBYtype（5秒超をtypeでグループ化）
/syslog_transaction_list.do?sysparm_query=ORDERBYDESCresponse_time（応答時間の降順）
/syslog_transaction_list.do?sysparm_query=type=List^ORDERBYDESCresponse_time（Listのみ降順）
/syslog_transaction_list.do?sysparm_query=type=Form^ORDERBYDESCresponse_time（Formのみ降順）
/syslog_transaction_list.do?sysparm_query=response_time>10000^ORDERBYDESCsys_created_on（10秒超を新しい順）
/sys_ui_list_list.do?sysparm_query=ORDERBYname（一覧の定義一覧）
/sys_ui_related_list_list.do?sysparm_query=ORDERBYname（関連リストの定義一覧）
参考リンク
Effective Troubleshooting of Slow Transactions（ServiceNow Community）
How to troubleshoot a slow transaction?（ServiceNow Community）
検証環境と未検証範囲
件数と表の数値はZurich PDI（OOTB）で確認したものです。syslog_transactionは常時追記されるテーブルのため、同じ条件で開き直すと合計件数は増えていきます。本文の内訳は、5秒超の全件（7,783件）を種別で集計した時点の値です。
PDIは共有基盤で、他のユーザーの検証作業が同じインスタンス上で動いています。応答時間の絶対値は、本番環境と直接比較できません。今回確認したのは件数と種別の内訳、応答時間・SQL回数・SQL時間・ACL Timeという記録された数値までです。遅い処理を実際に改善して速くなるかどうかの検証、SQLの中身やインデックスの有無、個々のジョブが遅い理由の特定は、いずれも範囲外としています。
