定期実行（sysauto_script）：定義と実行キューの2層
ServiceNow には「毎晩このクリーンアップを動かす」「1分ごとにこの処理を回す」といった定期実行（Scheduled Jobs）の仕組みがあります。管理画面では Scheduled Script Execution（定期実行スクリプト）として1つのフォームに見えます。内部では「いつ・何を動かすかの定義」と「次にいつ動くかを管理する実行キュー」という2つのテーブルが連動しています。
この記事では、実際の sysauto_script（Scheduled Script Execution＝定義）を起点にします。sys_trigger（Schedule Item＝実行キュー）も起点にします。両者がどう継承され、どんなフィールドを持つかを確認します。定義を保存すると次回実行時刻（next_action）がどう作られるかも、PDI（Zurich）の OOTB で確認します。
想定読者は、ServiceNow の Incident は触ったことがあるが、裏側で動く定期処理の仕組み（どのテーブルが何を担うか）をこれから理解したい管理者・開発者です。実機で確認するときに見るべき順番は、sysauto_script の継承、主要フィールド、run_type（実行頻度の種別）です。そして sys_trigger の next_action / state を追います。
この記事で確認する内容は次のとおりです。
定期実行が「定義（sysauto_script）」と「実行キュー（sys_trigger）」の2層で成り立つこと
sysauto_script が sysauto（Scheduled Job）を継承する薄いサブクラスで、スケジュール定義の本体は親 sysauto 側にあること
run_type（Daily / Periodically / Once 等）と sys_trigger の trigger_type / state の関係
「次回実行時刻」を sys_trigger の next_action で管理すること
sys_trigger が定期実行専用ではなく、システム内部ジョブも並ぶ共有キューであること
実機で確認するときに見るべき一覧URL
この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、ジョブの数・実行間隔・周辺設定の内容が異なる場合があります。
定期実行（Scheduled Jobs）とは
定期実行（Scheduled Jobs）は、指定した時刻や周期でサーバ側の処理を自動で動かす仕組みです。古いレコードの削除、集計の更新、外部連携などを担います。メール送信のまとめ処理など、人が毎回操作しなくてよい裏方の処理です。
このうち任意のスクリプトを動かすものが sysauto_script（Scheduled Script Execution） です。画面の「Run this script」に書いた処理が、指定した頻度で実行されます。フォーム上では1つに見えても、「実行する内容と頻度の定義」と「次にいつ動くかのキュー」は別テーブルに保存されています。この記事で確認するのは、その2層構造です。
sysauto_script は sysauto（Scheduled Job）の薄いサブクラス
まず定義側の継承関係から確認します。
今回確認した PDI（Zurich / OOTB）では、sysauto_script は sysauto（Scheduled Job）を継承していました。sysauto はさらに sys_metadata（Application File）を継承していました。sysauto の直接の子クラスは16あります。sysauto_script（スクリプト実行）のほか、sysauto_report（レポートのメール送信）、sysauto_template（テンプレート生成）があります。sysauto_pa（データ収集）など、定期実行の種類ごとにサブクラスが分かれています。
固有フィールド数を見ると役割分担がはっきりします。今回の PDI では、sysauto_script の固有フィールドはわずか2つ（script と sys_id）でした。親の sysauto は28の固有フィールドを持ちます。run_type（実行頻度）、run_time（時刻）、run_period（周期）といった「いつ動くか」の定義があります。conditional / condition（条件）、run_as（実行ユーザー）も、すべて親 sysauto 側に集約されています。sysauto_script は「スクリプトを実行する種類の Scheduled Job」を表す薄いサブクラスです。
クラス階層は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。
https://<YourInstance>/sys_db_object_list.do?sysparm_query=super_class.name=sysauto
定義側の主なフィールド（いつ・何を動かすか）
sysauto_script（とその親 sysauto）のフィールドは、「いつ動くか」「何を動かすか」「どんな条件・権限で動くか」に分けて読めます。
主なフィールドの代表は次のとおりです。ラベルは画面上の表示名で、実機どおり英語で記載します。
押さえる点は3つあります。
run_type が実行頻度の種別を決めます。Daily を選べば run_time（時刻）、Periodically を選べば run_period（周期）というように、選んだ種別によって意味を持つフィールドが変わります。
conditional / condition で「動かす条件」を足せます。Conditional を true にすると、Condition スクリプトが true を返したときだけ本体（Run this script）が実行されます。毎時動かしつつ特定の曜日・時間帯だけ実処理する、といった制御に使えます。こうした条件分岐の特殊なケースは、公式の Special cases in job schedules にまとまっています。
run_as で実行ユーザー（権限の文脈）が決まります。既定はジョブ作成者ですが、明示的に指定もできます。
実際のフォームを見ると、この構造が1画面に集約されているのが分かります。
このジョブ「Disconnected Chat Timeout」は、今回の PDI では run_type=Periodically（1分周期）／ conditional=false でした。切断されたチャットセッションを定期的に片付けるスクリプトが入っていました。右上の Execute Now で手動実行もできます。
いま新しく定期スクリプトを作るなら
新規に Scheduled Script Execution を作る場合、このフォームで最低限決めるのは Run（run_type）と Run this script（script）です。たとえば「毎晩3時に古いログを消す」なら、Run=Daily を選び、表示される Time に 03:00:00 を入れ、Run this script に削除処理を書いて保存します。「特定の平日だけ動かしたい」なら Conditional をオンにして、Condition 側に曜日判定を書きます。保存した時点で、後述の sys_trigger 側に対応するレコードと次回実行時刻が作られます。
全フィールドは、次のURLで一覧できます。
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sysauto^elementISNOTEMPTY公式の Schedule a script execution（Zurich） に、Scheduled Script Execution を作成する手順とフィールドの意味が説明されています。
実行頻度の種別（run_type）
run_type は、ジョブをどんな頻度で動かすかの種別です。今回の PDI（Zurich / OOTB）では、有効な選択肢として次の11種を確認しました。
value label 意味
-------------------------------------------------------------------------------------------
daily Daily 毎日（run_time の時刻に）
weekly Weekly 毎週
monthly Monthly 毎月
periodically Periodically 指定周期ごと（run_period）
once Once 一度きり
on_demand On Demand 手動/呼び出し時のみ
day_and_month_in_year Day and Month in Year 毎年の特定月日
week_in_month Week in Month 月内の特定週
day_week_month_year Day in Week in Month in Year 年内の特定週の曜日
business_calendar_start / business_calendar_end Business Calendar: Entry Start / End 業務カレンダー基準daily（毎日）と periodically（周期）が定期実行の基本で、once / on_demand は一回限りや手動寄りの種別です。Zurich では、より細かい時刻指定の run type も追加されています（詳しくは公式コミュニティの Zurich's new run types for scheduled jobs を参照）。
run_type の選択肢は、次のURLで一覧できます。
https://<YourInstance>/sys_choice_list.do?sysparm_query=name=sysauto^element=run_type^inactive=false^ORDERBYsequence
定義から実行キューへ（sysauto_script → sys_trigger）
定期実行の「次にいつ動くか」は、定義テーブル（sysauto_script）の中では管理されません。sys_trigger（Schedule Item）という別テーブルに、1スケジュール＝1レコードとして保存されます。
今回の PDI で実機をたどると、次のことが確認できました。
Scheduled Job を保存すると、同じ name の sys_trigger が作られます。定義側の「Disconnected Chat Timeout」（periodically・1分）に対し、sys_trigger 側には同名のレコードがありました。trigger_type=Repeat（repeat=1 Minute）／ state=Ready ／ next_action=次回実行時刻 が入っています。run_count（累積実行回数）は確認時点で 90,321 回まで進んでいました（1分周期のジョブなので、見るたびに増えていきます）。
sys_trigger は定期実行専用のテーブルではありません。sysauto_script だけでなく、sysauto_pa（データ収集）など他種別の Scheduled Job からもトリガーが作られます。システム内部のジョブ（イベント処理・SLA・アップグレード等）も同じ sys_trigger に並びます。実際の一覧では Job ID 列に RunScriptJob / TablePerHierarchySizer など多様なジョブクラスが見えます。
定義側（sysauto_script）の run_type と、キュー側（sys_trigger）の trigger_type は対応していますが、同じ名前ではありません。run_type=periodically はキューでは trigger_type=Repeat になります。run_type=daily は trigger_type=Daily になります。このように、定義の頻度種別とキューのトリガー種別を別々に持っています。
sys_trigger の一覧は、次のURLで確認できます（next_action の昇順で「次に動くもの順」に並びます）。
https://<YourInstance>/sys_trigger_list.do?sysparm_query=state=0^ORDERBYnext_action
この一覧を next_action 順で開くと、いま先頭に来ているトリガーが「次にサーバが動かすジョブ」です。ジョブが動かないと相談されたときは、まずこの画面で対象ジョブの行を探し、next_action がいつになっているか、state が Ready のままか Error に落ちていないかを見ます。
キュー側の主なフィールドと状態（sys_trigger）
sys_trigger は固有フィールドが52と多く、「次回実行」と「実行の記録」を持つのが特徴です。
主なフィールド
中心になるのは次のフィールドです。
next_action（次回実行時刻） … いつ動くか。サーバのタイムゾーン基準で持ちます。各アプリノードのスケジューラが「next_action が現在時刻以下」のトリガーを拾って実行する、というのが基本的な考え方です（内部挙動の詳細は検証範囲外）。
state（状態）… Ready（0）/ Running（1）/ Queued（2）/ Error（-1）/ Permanent Error（-2）。
trigger_type（トリガー種別）… Repeat / Daily / Run Once / Interval など、有効な選択肢は13種類ありました。
run_count / error_count / last_error / claimed_by … 実行回数・エラー回数・直近エラー・実行を確保したノード。
state の遷移
state は次のように遷移します。
繰り返しジョブは、実行が終わると次回の next_action がセットされ、再び Ready に戻ります。一度きり（Run Once）のトリガーは、実行が終わると役目を終えます。エラーが続くと Error から Permanent Error に至ります。
sys_trigger は「いま何が待っているか／次にいつ動くか」を映す動的なテーブルです。定義（sysauto_script）が設計図なら、sys_trigger は実行待ち行列にあたります。「ジョブが動かない」ときは、定義の active だけでなく、対応する sys_trigger の state と next_action を見ます。
実機で見えた件数・分布
今回の PDI（Zurich / OOTB）で件数を数えると、定義側と実行キューの規模感がつかめます。
ここから読み取れることは次のとおりです。
定義全体（sysauto、全16サブクラス合計）は447件でした。そのうちスクリプトを実行する sysauto_script が370件で、うち有効（active）は323件です。run_type の内訳は Daily 147 / Periodically 113 が大半で、毎日実行と周期実行が定期処理の中心でした。
実行キュー（sys_trigger）は確認時点で775件と定義より多く、うち774件が Ready、Running は0でした。sys_trigger が定期実行以外のジョブも含む共有キューであることと整合します。
trigger_type は Daily 228 / Repeat 212 / Interval 81 が多く、Disabled も80件ありました。Disabled なトリガーは、定義が無効化されたジョブなどが残っているものと読めます（個々の対応関係までは追っていません＝検証範囲外）。
周辺設定を見ると、sysauto_script には Business Rule 2件・UI Action 4件・Access Control 6件が、sys_trigger には Business Rule 19件・Access Control 17件が紐づいていました。挙動はテーブルのフィールドだけでなく、こうした周辺設定と合わさって決まります。
定義側の一覧は、次のURLで確認できます。
https://<YourInstance>/sysauto_script_list.do?sysparm_query=active=true^ORDERBYrun_type
ServiceNow における定期実行のポイント
定期実行は「定義（sysauto_script）」と「実行キュー（sys_trigger）」の2層で動きます。フォームは1つでも、裏では別テーブルが連動します。
sysauto_script は sysauto（Scheduled Job）を継承する薄いサブクラスで、固有フィールドは2つだけです。run_type / run_time / conditional などの定義本体は親 sysauto 側にあります。
run_type（定義の頻度種別）と trigger_type（キューのトリガー種別）は別物です。periodically↔Repeat、daily↔Daily のように対応します。
「次回実行時刻」は sys_trigger の next_action が持ちます。スケジューラは next_action ≤ 現在時刻 のトリガーを拾い、繰り返しジョブは実行後に次回をセットし直します。
sys_trigger は共有キューで、定期実行以外のシステム内部ジョブも並びます。今回の PDI では定義370件に対しトリガー775件でした。
定期実行を調べるときは、まず「いま見ているのは定義か、実行キューか」を区別し、sysauto_script（設計図）と sys_trigger（実行待ち行列）をセットで見ます。
実機で気づいたこと
最初は sysauto_script が定期実行の設定をひととおり持っていると思っていましたが、実際に開くと固有フィールドは script だけでした。run_type も conditional も run_as も、すべて親の sysauto 側にあります。「Scheduled Script Execution」という名前の強さに反して、実体はほぼ空のサブクラスでした。
sys_trigger の一覧を next_action 順に開くと、Job ID の列に RunScriptJob だけでなく TablePerHierarchySizer のような見慣れないクラス名が並んでいました。定期実行のジョブと、プラットフォーム内部の処理が同じキューに混ざっている実感が持てます。
trigger_type の選択肢は13種類あり、Repeat や Daily のような日常的な種別だけでなく、Run at System Startup（起動時実行）や Business Calendar 系まで含まれていました。1分周期のジョブだけを眺めていては気づかない多様さです。
次に読むなら
次のテーマとして残るのは3つです。conditional / condition を使った「動かす条件」の書き方、run_as による実行権限の扱いです。そして sys_trigger と worker（ジョブを実際に処理するスレッド。参考: Understanding Scheduled Job Workers）の関係です。特に「定義は有効なのにジョブが動かない」ときに、sys_trigger の state / next_action / error_count をどう読むかは、運用で効いてきます。これらは本記事の「定義から実行キューへ」「キュー側の状態」で確認した仕組みの先にあたり、別記事で扱う予定です。
用語
PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
Scheduled Job（sysauto）：定期実行の定義の基底テーブル（label: Scheduled Job）
Scheduled Script Execution（sysauto_script）：スクリプトを実行する種類の定期実行
Schedule Item（sys_trigger）：次回実行時刻と状態を持つ実行キュー
next_action：sys_trigger の次回実行時刻（サーバTZ基準）
自分の環境で確認するときのURL
先頭に自分のインスタンスを付けると、同じ画面が開けます。
定義の種類（子クラス） : sys_db_object_list.do?sysparm_query=super_class.name=sysauto
定義フィールド一覧 : sys_dictionary_list.do?sysparm_query=name=sysauto^elementISNOTEMPTY
run_type 選択肢 : sys_choice_list.do?sysparm_query=name=sysauto^element=run_type^inactive=false^ORDERBYsequence
定義一覧（スクリプト） : sysauto_script_list.do?sysparm_query=active=true^ORDERBYrun_type
実行キュー一覧 : sys_trigger_list.do?sysparm_query=state=0^ORDERBYnext_action検証範囲とおことわり
確認した範囲：sysauto_script → sysauto → sys_metadata の継承、sys_trigger の独立性、各固有フィールド数（2 / 28 / 52）です。加えて、run_type / state / trigger_type の選択肢、主要フィールドと参照先も確認しました。定義→トリガーの name 連動（実例 "Disconnected Chat Timeout"）も確認しました。各テーブルの件数と分布、周辺設定件数も確認しました。すべて PDI（Zurich / 2026-06-20 確認、件数は 2026-06-21 取得、動的な値は 2026-06-23 再確認）の OOTB で取得しています。
確認していない範囲（断定しません）：スケジューラスレッドの内部実行挙動・claim/lock の詳細、max_drift による実行時刻の分散幅、各 Business Rule の内部処理です。ほかに、Automation Creator ウィザードの動作、複数ノード（クラスタ）での実挙動、Disabled トリガーと定義の個別の対応関係も確認していません。これらは別記事で扱います。
今回は PDI の OOTB（初期設定）を前提に、定期実行のテーブル構造と定義→キューの連動を確認しました。実環境では、既存のカスタマイズや負荷によってジョブの数・実行間隔・状態が変わります。
