スケジュールジョブが動かないときの調べ方：sys_triggerの読み方

「毎晩動くはずのバッチが止まっている気がする」。ServiceNowの運用でこの相談を受けたとき、最初にどの画面を開くでしょうか。担当者の勘に頼って一覧を眺めるだけでは、動いているのか止まっているのか判断がつかないことがあります。

スケジュールジョブは、設定画面から作る「定義」と、実際に次回いつ動くかを持つ「実行予約」の2つのテーブルに分かれています。動かないという相談は、たいてい実行予約側の一覧を開けば手がかりが掴めるはずです。ただし、定義側で無効化されているだけというケースもあるため、見る順番を押さえておく必要があります。

この記事で分かること

• 定義（sysauto系）と実行予約（sys_trigger）の役割の違いと、動かないときにどちらを先に見るか

• 一覧画面でsys_triggerをStateごとにグループ化し、Errorが混ざっていないかを確認する手順

• next_action列を並べ替えて、実行予定が過去のまま止まっているジョブを見つける手順

• 実測837件のうち139件が「次回実行が過去のまま」だった実例の読み方

公式ドキュメントで押さえる基本

スケジュールジョブの動作は、Scheduled jobsとSystem Schedulerという2本のドキュメントにまたがって説明されています。読み解く前に、全体の構造を押さえておくと迷いません。

定義（sysauto系）と実行予約（sys_trigger）という2層構造

管理画面から「新規」で作るスケジュールジョブは、sysautoという親テーブルとその子テーブル（sysauto_scriptなど）に保存されます。ここに入っているのは、名前・実行頻度・Activeフラグといった設定そのものです。ジョブを止めたり動かしたりする操作は、まずこの定義側で行います。

一方、sys_triggerは「次にいつ動くか」という実行予約を持つ別のテーブルです。sysautoの定義1件につき、次の実行予定が1件sys_triggerに作られます。繰り返し実行されるジョブは、実行が終わるたびに次の予約が新しく積まれていきます。

「動かない」という相談の多くは、この2つのどちらに問題があるかを切り分けるところから始まります。定義側でActiveが外れていれば実行予約はそもそも作られませんし、定義側が正しくても実行予約側でエラーになっていれば処理は進みません。

sys_triggerが持つ主なフィールド

sys_triggerのリストを開くと、主に次の列が並びます。

• Name … 元になった定義（sysauto側）の名前

• Next action … 次に処理される予定の日時

• Trigger type … Interval（周期実行）、Run at System Startup（起動時のみ）、Disabledなど、予約の種類

• State … いま実行予約がどういう状態にあるか

• Job ID … 実際に呼び出されるジョブの種類

調査でまず見るのはNext actionとStateです。次にいつ動く予定で、いまどんな状態にあるかが分かれば、止まっていそうなジョブの見当がつきます。

stateが示す5段階の状態

stateは5つの値を取ります。マイナスの値がエラー系という設計です。

• -1 … Error（一時的なエラー）

• -2 … Permanent Error（恒久的なエラー。リトライされない）

• 0 … Ready（次の実行を待っている状態）

• 1 … Running（いま実行中）

• 2 … Queued（実行待ちの列に並んでいる状態）

見るべき順番としては、まずErrorとPermanent Errorが混ざっていないかを確認します。次に見るのは、Readyのうちnext_actionが過去のままのものです。この2点を押さえれば、実行予約側の調査はほぼ終わります。

実行予約を処理するのはノード上のワーカー

sys_triggerに積まれた実行予約は、ノードが持つワーカースレッドが拾って実行します。ServiceNowコミュニティの解説記事Understanding Scheduled Job Workersによれば、各ノードは既定で8本のScheduler Workerを持ちます。優先度25以下の高優先ジョブがキューで60秒以上待たされると、9本目のBurst Workerが動き出す仕組みです。

ノードの構成には、全種類の処理を1つのプールでさばくGenericと、UI操作とスケジュールジョブの処理プールを分けるUI/Workerの2種類があります。Understanding Application Nodesによれば、どちらの構成かはsys_cluster_stateテーブルのscheduler列（any / specified）で確認できるとされています。今回のPDIは単一ノードでの実測のため、複数ノードでの分散や偏りまでは確認していません。

一覧が面倒ならScheduled Jobsダッシュボードもある

Zurichには、個々のレコードを開かずに全体の状況を見るScheduled Jobsダッシュボードも用意されています。System EventsとJobsダッシュボードを開くには専用のロールが必要です。この記事では、権限を持たない担当者でも開ける標準の一覧画面とグループ化機能だけで調べる方法を扱います。

画面でたどる調べ方

ここからは、実際に管理画面をたどりながら状態を確認する手順です。手順は5つです。スクリプトを書く必要はなく、一覧とフィルタ、グループ化の機能だけで完結します。

以下の画面は2026-08-08に開き直したものです。数字の実測（2026-08-05）とは数日ずれています。sys_triggerは常時更新されるテーブルなので、合計件数が数十件動くのは普通のことです。ここで見るのは正確な合計ではなく、グループ化や並べ替えでどこに手がかりが出るかという手順そのものです。

1. 定義側 ― sysautoの一覧を開く

まずsysauto_scriptの一覧を開き、Name・Active・Class・Updatedの列を確認します。目的のジョブ名で検索すれば、Activeがtrueかfalseかがすぐに分かります。

sysautoはクラス階層になっているため、Class列でグループ化すると内訳が見えます。今回の実測ではスクリプト実行系（Scheduled Script Execution）が360件と最多でした。次いでScheduled Data Collectionが43件、Scheduled Email of Query Builderが11件、Auditが10件と続きます。

2. 実行予約側 ― sys_triggerをStateでグループ化する

sys_triggerの一覧を開き、State列のヘッダーからGroup Byを選ぶと、State別に件数がまとまって表示されます。1件ずつ開かなくても、Errorが混ざっているかどうかが一目で分かります。

グループ化すると、ほとんどの行が「State: Ready」にまとまり、Error・Permanent Errorはごくわずか、あるいは現れないことが確認できます。エラーが見えたら、そのグループを展開して個別のジョブ名を確認します。

3. 次回実行が過去のまま止まっていないか確認する

Next action列のヘッダーをクリックして昇順に並べ替えると、最も古い予定時刻のジョブが上に来ます。この一覧には、何年も前の日付のまま残っているレコードが並ぶことがあります。

ただし、古い日付が残っていること自体は異常とは限りません。Trigger typeがRun at System Startupのジョブは、次に起動したときに動く設計なので、次回実行日時が過去のままでも正常です。一方、IntervalやDisabledのままNext actionが古いジョブは、確認したほうがよい候補です。この一覧ではReadyの表示が黒色と赤色に分かれており、Run at System Startup以外のジョブが赤色で強調されているように見えました。色分けの基準そのものは公式ドキュメントに明記が見当たらないため断定はできませんが、目視で優先順位をつける手がかりになると考えられます。

4. stateの値の意味を確認する

state列の数字だけを見ても意味が分かりにくいので、sys_choiceから選択肢を確認しておきます。テーブルをsys_trigger、要素をstateで絞り込むと、値とラベルの対応が一覧で出ます。

ここで確認できる値は、先に挙げた5段階（Error / Permanent Error / Ready / Running / Queued）と一致します。リストで数字だけが見えたときは、この一覧を思い出せば読み替えられます。

5. ジョブの設定項目を確認する

原因が定義側にありそうなら、該当ジョブのフォームを開いて設定内容を確認します。新規作成フォームを開くと、Active・Run（実行頻度）・Time zone・Timeといった主要な項目が並びます。

Runのプルダウンでは、Daily・Weekly・Periodicallyなど実行頻度の型を選びます。選んだ型に応じて、sys_trigger側に作られる予約のTrigger typeが変わります。Time zoneを指定しなければ入力したユーザーのタイムゾーンで実行時刻が解釈される点も、設定を疑うときに見落としやすいところです。

実測で見る内訳

ここからは、画面で確認した内訳を数字として整理します。件数だけを眺めても意味が薄いので、状態の内訳と定義側の内訳を分けて見ます。

stateの選択肢は5段階

sys_choiceから取った選択肢は5つでした。覚える数はそう多くありません。マイナスの値がエラー系という設計は、リストで数字だけが見えたときの読み替えに使えます。

sys_trigger 837件の内訳

sys_triggerは合計837件でした。このうち829件がReady、1件がstate未設定です。Error（-1）とPermanent Error（-2）は、状態別の集計に1件も現れませんでした。829件のうち139件は、next_actionが現在時刻より過去のままでした。割合にするとおよそ17%です。

Readyというラベルだけを見ると「次を待っている正常な状態」に見えますが、next_actionを合わせて見ると印象が変わります。予定していた時刻を過ぎても実行に移っていないジョブが一定数あるという実測です。この139件が具体的にどんな原因で滞留しているかまでは、今回の調査では踏み込んでいません。件数として把握できることと、原因を特定できることは別の作業です。

定義側sysautoの件数

定義側はsysautoが465件、うちactiveが393件でした。72件が非アクティブということになります。sysauto_scriptは386件中339件がactiveです。スクリプト実行型だけで定義全体の8割強を占めており、独自に追加するスケジュールジョブの多くもこのクラスに属することになるはずです。

sysauto_report（旧スケジュールレポート）とsysauto_par（Par Scheduled Export）は、どちらも0件でした。この2つは古い機能で、現行のOOTBでは使われていないと読めます。対応は不要です。

sys_triggerの一覧だけを見ていると、この72件の非アクティブなジョブには気づけません。非アクティブなジョブは実行予約自体が作られないため、sys_triggerにレコードが存在しないからです。「動くはずのジョブがsys_triggerに見当たらない」という相談を受けたときは、この非アクティブの可能性を先に確認したほうが早く終わります。

切り分けの順番

「動かない」と言われたときに開く順番は、次のとおりです。

1. sysauto側でActiveを確認する。外れていれば、それだけで実行予約が作られない

2. sys_triggerを該当ジョブ名で検索し、レコードがあるかを見る。無ければ手順1に戻る

3. あればStateを確認する。ErrorやPermanent Errorが出ていないか

4. Next actionが現在より過去でないかを確認する。Trigger typeがRun at System Startup以外で過去のままなら要調査

5. ここまでで異常が見当たらなければ、ジョブの設定内容（Run条件・スクリプト本体）を開いて中身を確認する

近道はこれだけです。この順番を押さえておけば、原因の無いところを延々と探すことを避けられます。

つまずきやすい点

実測を振り返ると、数字の見え方でつまずきやすい点が5つありました。

• Readyは異常のサインではありません。829件のうち大半は次回実行を待っているだけの正常な状態です。件数の多さに驚いて全件を調べる必要はありません。

• next_actionが過去でも、即・障害とは限りません。負荷の高い時間帯や一時的な処理の遅れでも、next_actionが押し流されることがあります。139件という数字は「先に見るべき候補が139件ある」という意味で受け取るほうが安全です。

• sys_triggerに無いから壊れているとは限りません。定義側でActiveが外れているだけの可能性があります。実行予約が無い場合は、まず定義側を確認します。

• sys_triggerは常時更新されるテーブルです。いま同じ一覧を開くと、本記事の実測（837件）から合計件数がずれていることがあります。日によって件数が動くこと自体は正常です。逆に、動いてはいけないはずの値（Error件数など）が増えていたら、そちらが調査のきっかけになります。

• ノード構成によって実行の速さが変わることがあります。Scheduler Workerは1ノードあたり既定8本、高優先ジョブ用のBurst Workerが9本目として動く設計だとコミュニティの解説記事にあります。今回のPDIは単一ノードでの実測のため、複数ノードにまたがる偏りは確認していません。

よくある質問

現場で聞かれることが多い5問をまとめました。

next_actionが未来の日時になっているジョブは放置してよいですか

放置して問題ありません。next_actionは「次にいつ動くか」を表すフィールドなので、未来の日時が入っているのは待機中の正常な状態です。今回の実測でも、Ready829件の大半はこの状態にあたります。慌てて全件を開いて確認するより、過去日時のものだけを一覧で絞り込むほうが調査の効率は上がります。

stateがRunningのまま長時間変わらないときは何を見ればよいですか

該当レコードのUpdated（更新日時）の推移を見ます。前段で触れたとおり、実行を拾うのはノード上のワーカーなので、特定のノードに負荷が偏っていないかも合わせて確認する余地があります。ただし、その場合の具体的な復旧手順は今回の調査の範囲外です。

sysauto_reportとsysauto_parが0件なのは異常ですか

今回のPDIでは異常ではなく、単に使われていないという状態です。この2つは古いスケジュールレポート・Par Scheduled Exportの機能で、OOTBの初期状態では作られません。ゼロ件であること自体は自然な結果であり、本番環境でこの2クラスにレコードが多く残っているなら、過去に作られた古い定義が消化されずに残っている可能性を疑う材料になります。

sysautoをactive=falseにするとsys_triggerの予約はどうなりますか

今回はレコードを変更していないため、実際の挙動は確認していません。一般的には、次回実行が確定していない定義を無効化すれば、新しい実行予約は作られなくなると考えられます。確定済みのsys_triggerレコードがどう扱われるかまでは、この記事の検証範囲では確認していません。無効化する前に、依存している他の処理が無いかを別途確認しておくほうが安全です。

ErrorやPermanent Errorが出ているジョブを見つけたらどうすればよいですか

今回のPDIでは0件だったため、実例をもとにした手順は示せません。まずは該当レコードのsys_triggerを開き、エラーの詳細情報が残っていないかを確認するのが調査の起点になります。同じ定義から生まれた別の実行が正常に終わっているかどうかも、原因を切り分ける手がかりになるはずです。原因の特定や復旧の手順は、この記事では扱っていません。

まとめ

答えは、2つのテーブルのどちらを見るかに尽きます。スケジュールジョブが動かないという相談は、定義側（sysauto系）と実行予約側（sys_trigger）のどちらに問題があるかを切り分けるところから始まります。実行予約が見当たらないなら定義側のActiveを、実行予約はあるのに動いていないように見えるならStateとNext actionを見る。この順番を押さえておけば、遠回りせずに手がかりへたどり着けます。

実測では、sys_trigger837件のうち829件がReady、139件が次回実行時刻を過ぎたまま残っていました。Error・Permanent Errorは0件です。定義側は465件中393件がactiveで、72件は非アクティブでした。数字だけを見ると多く感じますが、内訳を分けて見ると、対応が必要な範囲はもっと絞り込めます。

一覧とグループ化だけで数分あれば確認できます。障害調査の第一歩として、まずこの規模感を掴んでおくと、その後の個別調査にどれだけ時間を割くべきかの見当が付けやすくなります。

用語

• sysauto（Scheduled Job） … スケジュールジョブの定義を持つ親テーブル。名前・スケジュール・Activeを管理する

• sysauto_script … sysautoの子テーブルで、スクリプトを実行するタイプの定義

• sys_trigger（Schedule Item） … 実行予約のテーブル。Next action（次回実行時刻）とState（実行状態）を持つ

• Next action … sys_triggerが次に処理される予定の日時

• Trigger type … sys_triggerの予約の種類。Interval、Run at System Startup、Disabledなど

• state … sys_triggerの実行状態。Error / Permanent Error / Ready / Running / Queuedの5段階

• Scheduler Worker … ノード上でsys_triggerのキューを処理するスレッド。既定8本＋高優先ジョブ用のBurst Worker1本

• sys_cluster_state … ノードごとの稼働状態を持つテーブル。scheduler列でジョブ処理の担当区分が分かる

画面を開くときのURL

• /sysauto_script_list.do?sysparm_query=ORDERBYname（定義側の一覧をName順に）

• /sysauto_list.do?sysparm_query=GROUPBYsys_class_name（定義側をクラス別にグループ化）

• /sys_trigger_list.do?sysparm_query=GROUPBYstate（実行予約をStateでグループ化）

• /sys_trigger_list.do?sysparm_query=ORDERBYnext_action（実行予約をNext actionの古い順に）

• /sys_choice_list.do?sysparm_query=name=sys_trigger^element=state（stateの選択肢）

• /sysauto_script.do?sys_id=-1（新規ジョブの設定フォーム）

参考リンク

• Scheduled jobs（ServiceNow Product Documentation・Zurich）

• System Scheduler（ServiceNow Product Documentation・Zurich）

• Understand your Scheduled Jobs dashboard（ServiceNow Product Documentation・Zurich）

• Monitor System Events and Scheduled Jobs dashboards（ServiceNow Product Documentation・Zurich）

• System Events and Jobs dashboard roles（ServiceNow Product Documentation・Zurich）

• Understand your System Events dashboard（ServiceNow Product Documentation・Zurich）

• Domain support and schedules（ServiceNow Product Documentation・Zurich）

• Understanding Scheduled Job Workers（ServiceNow Community）

• Understanding Application Nodes（ServiceNow Community）

検証範囲とおことわり

• 件数・state・next_actionはPDI（Zurich / OOTB）の実測です。本番環境では件数・傾向が異なります。

• sys_triggerは常時更新されるテーブルです。記事公開後に同じ一覧を開くと、合計件数は実測時点（2026-08-05）から変わっている可能性があります。

• 実際にジョブを止めて復旧させる検証は行っていません。今回は画面での確認のみです。

• Error・Permanent Errorが出ている状態の実例は確認できていません。今回のPDIでは0件でした。

• ノードが複数あるクラスタ環境での挙動、ノード間の偏りは調べていません。

• ドメイン分離環境でのスケジュールの扱いは公式ドキュメントに別途解説がありますが、今回は検証していません。

• 「次回実行が過去のまま」が必ず異常を意味するかどうかは断定していません。負荷や一時的な遅延でも起こり得ます。

• next_actionの色分け（黒/赤）がTrigger typeによる仕様かどうかは、公式ドキュメントで明記を確認できていません。目視での観察に基づく記述です。