一度だけ流す後始末スクリプト（Fix Script）

2026年6月27日 09:33

ServiceNow でアプリを入れたりアップグレードしたりすると、「既存データの既定値をまとめて直したい」「古いテーブルから新しいテーブルへレコードを移したい」といった、一回だけ流せば済む後始末が必要になることがあります。こうした処理を開発環境で書いて、移送先で一度だけ確実に実行するための専用テーブルが Fix Script（sys_script_fix） です。

この記事は、Business Rule や Background Script は触ったことがあるものの、「Fix Script は何が違うのか」「なぜわざわざ専用テーブルがあるのか」を整理したい管理者・開発者を想定しています。PDI（Zurich / OOTB）で sys_script_fix を実際に開いて確認したのは4点です。テーブルの位置づけ（メタデータ）、固有フィールド、Update Set に乗って移送先で1回だけ動くライフサイクル、そして Business Rule・Background Script との違いです。

この記事で分かること

Fix Script が sys_script_fix に1件＝1レコードで保存され、sys_metadata（Application File）を継承するメタデータであること
だから Update Set に乗って移送先へ運べ、移送先で「Run Fix Script」を押して一度だけ実行する設計であること
固有フィールドは6つ（name / description / script / before / record_for_rollback / unloadable）で、when・order・collection・active が無いこと
PDI 実機には 924 件の Fix Script があり、用途はデータ移行・辞書修正・クリーンアップが中心であること
record_for_rollback で実行を記録して巻き戻せること（PDI では 405 件が true）
Fix Script（一度だけ手動）/ Business Rule（毎回自動）/ Background Script（その場限り・コードが残らない）の棲み分け

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、フィールドの値・件数・スクリプトの内容が異なる場合があります。

Fix Script（フィックススクリプト）とは

Fix Script とは、アプリの導入やアップグレードのあとに、データ整合性や安定化のために「一度だけ」流すサーバ側の JavaScript です。たとえば「既存レコードの既定値を一括で直す」「旧テーブルのデータを新テーブルへ移す」といった、運用上1回やれば終わる後始末を担います。

ServiceNow では、この Fix Script を格納するテーブルが sys_script_fix（画面ラベル: Fix Script）です。画面では System Definition ＞ Fix Scripts から一覧でき、各レコードが1つのスクリプトに対応します。下の実画面は、その1件をフォームで開いたものです。

このレコードは「Clear default value from model category」という名前です。Script 欄には sys_dictionary の既定値（default_value）を空に更新する処理が書かれています。製品モデルのカテゴリ既定値を一括で直す、一度流せば終わりの処理です。常時動かす必要はなく、必要な環境で1回だけ実行します。

PDI（Zurich / OOTB）の sys_script_fix には、すでに 924 件の Fix Script が入っていました。これらはプラットフォームやプラグインが「導入・アップグレード時の後始末」として同梱しているものです。

sys_script_fix はどこに位置するテーブルか

最初に押さえたいのは、sys_script_fix が incident のような「業務データのテーブル」ではない、という点です。

今回確認した PDI（Zurich / OOTB）では、sys_script_fix の super_class（継承元）は Application File、すなわち sys_metadata でした。sys_metadata は Update Set で持ち運べる「アプリ構成（メタデータ）」の基底です。つまり Fix Script は業務レコードではなく、Business Rule（sys_script）や ACL、Update Set 定義と同じ「設定・構成」側のレコードとして管理されます。

地味ですが効いてくる事実です。メタデータだからこそ、Fix Script は Update Set に捕捉されて別環境へ運べます。テーブル定義は次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=sys_script_fix

Fix Script の固有フィールドは6つだけ

Fix Script のフィールドは、Business Rule と比べると驚くほどシンプルです。今回 sys_dictionary で sys_script_fix の固有フィールドを確認すると、sys_id を除けば 6つだけでした。

主な固有フィールドを整理すると次のとおりです。ラベルは画面上の表示名で、実機どおり記載します。

ここで決定的なのは、Business Rule にある when（実行タイミング）・order（実行順）・collection（対象テーブル）・active が、Fix Script には無いことです。Business Rule は「いつ・どのテーブルで自動的に発火するか」を持ちます。Fix Script は自動で発火する仕組みを持ちません。人が「Run Fix Script」を押したときに、その場で1回だけ動く、という前提のテーブルです。

なお、当初は run_type（once / everytime）のような「実行回数の種別」フィールドがあるかと想定していましたが、Zurich の sys_script_fix にそうしたフィールドは存在しませんでした。Fix Script は構造そのものが「一度だけ」を前提にしており、回数を切り替える設定は持ちません。

各フィールドの役割は次のとおりです。

name / description … スクリプトの名前と、「何をする1回処理か」の説明。
script … 実行するサーバ側 JavaScript 本体（最大 8000 文字）。GlideRecord でデータを更新・移行・削除する処理を書きます。
before … 真偽値のフラグで、PDI では 84 件が true でした。実行タイミングに関わるフラグですが、その厳密な内部挙動（アップグレード処理の前後など）は今回の検証範囲外とします。
record_for_rollback … 「実行を記録して、あとで任意に巻き戻せるようにする」フラグ（hint: *Record execution of the script so that it may be optionally reverted if desired.*）。既定は true で、PDI では 405 件が true でした。
unloadable … hint は *Will not create updates when false*。PDI では 37 件が true でした（Update Set 捕捉に関わるフラグで、正確な挙動は検証範囲外）。

Fix Script のライフサイクル：作って・運んで・1回流す

Fix Script は「開発環境で書き、移送先で一度だけ実行する」という運用の流れとセットになっています。

開発インスタンスで作成 … sys_script_fix に1件のレコードとしてスクリプトを書きます。
Update Set に捕捉 … sys_script_fix はメタデータ（Application File）なので、Update Set に「アプリ構成」として乗ります。Update Set の中身（Customer Update / sys_update_xml）の一種として運ばれます。
移送先で取り込み … テスト環境や本番へ Update Set を Retrieve → Commit すると、Fix Script レコードが移送先にも現れます。
移送先で手動実行 … 移送先の管理者が、Fix Script フォームの「Run Fix Script」を押して実行します。移送しただけでは動きません。明示的に人が実行します。
一度だけ実行 … その環境のデータに対して処理が1回流れます。record_for_rollback が true なら実行が記録され、必要なら巻き戻せます。

この「移送はするが、自動では動かさず、移送先で人が1回だけ流す」という設計が、Fix Script を「データ移行・後始末」に向いた道具にしています。常時効かせたい処理（Business Rule）とも、その場限りの使い捨て（Background Script）とも違う立ち位置です。

PDI の Fix Script は何に使われているか

PDI 実機の 924 件を眺めると、Fix Script が「一度だけの後始末」に使われていることがよく分かります。

代表的なものを抜き出すと、用途は大きく「データ移行」「辞書修正」「バックフィル」「クリーンアップ」「参照付け替え」に分かれます。

たとえば「Migrate signing jobs」は、旧テーブル（sys_mass_encryption_job）から新テーブル（sys_signing_job）へ該当レコードを移すデータ移行スクリプトです。このレコードは record_for_rollback が true になっており、実行を記録して巻き戻せるようにしてあります。

いずれも「アップグレードで新しいテーブルや項目ができたので、既存データをそれに合わせて一度だけ整える」という性格の処理です。常時動かす必要はなく、該当する環境で1回流せば役目を終えるものばかりでした。

なお before フラグの分布を一覧で見ると、ほとんどが false で、true は一部に限られていました。

PDI 実測では before=true は 84 件 / 924 件でした。残りは false です。before が何を切り替えるフラグなのかという正確な内部挙動は今回の検証範囲外ですが、大半の Fix Script は before を使っていないと読めます。

Business Rule・Background Script との違い

Fix Script の立ち位置は、似たもの2つと比べると一番はっきりします。Business Rule（常時自動）と Background Script（その場限り）です。

Business Rule（sys_script） … レコードの挿入・更新・削除・照会のたびに自動で毎回動きます。テーブル（collection）に紐づき、条件に合えば何度でも発火します。「保存したら必ず State を整える」のような常時効かせたいルール向きです。PDI では sys_script に 5500 件ありました。
Background Script（sys.scripts.do） … 管理画面の Scripts - Background から、その場でコードを貼って即実行する使い捨ての仕組みです。スクリプト本文はレコードとして保存されないため、Update Set にも乗らず、別環境へは運べません（実行そのものは Record for rollback の記録が既定でオンで、実行履歴から巻き戻せます）。「今この環境でちょっと試したい」「1回確認したい」という用途です。
Fix Script（sys_script_fix） … 開発環境で書いてレコードとして残り、Update Set で移送先へ運べ、移送先で人が手動で1回だけ実行します。record_for_rollback で実行を記録・巻き戻しできます。「移送先で1回だけ確実に流したい運用処理」向きです。

表にすると、3者の違いが整理できます。

判断の軸はシンプルです。「常時・自動で効かせたい」なら Business Rule、「今ここで試すだけ」なら Background Script、「別環境へ運んで1回だけ確実に流したい」なら Fix Script です。とくに Fix Script と Background Script は「1回流す」点が似ていますが、移送できるか・スクリプト自体が残るかで分かれます。本番のデータ移行を Background Script でその場打ちすると、流したコード自体が残らないため、あとから何を実行したかを再現・レビューできません。だからこそ移送・記録できる Fix Script が用意されています。

実機で確認するときに見るべきURL

最後に、今回見た画面を自分のインスタンスで開くためのURLをまとめます（<YourInstance> は置き換えてください）。

# Fix Script の一覧
https://<YourInstance>/sys_script_fix_list.do?sysparm_query=ORDERBYname

# テーブル定義（Extends: Application File を確認）
https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=sys_script_fix

# Fix Script のフィールド定義
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_script_fix^elementISNOTEMPTY

まとめ

Fix Script は sys_script_fix に1件＝1レコードで保存され、sys_metadata（Application File）を継承するメタデータ。業務データではなく「アプリ構成」側で管理される。
メタデータなので Update Set に乗って移送先へ運べ、移送先で「Run Fix Script」を押して一度だけ手動実行する設計。移送しただけでは動かない。
固有フィールドは6つ（name / description / script / before / record_for_rollback / unloadable）。when・order・collection・active は無く、自動発火の仕組みを持たない。
PDI 実機には 924 件。用途はデータ移行・辞書修正・バックフィル・クリーンアップなど「一度だけの後始末」が中心。record_for_rollback で実行を記録・巻き戻しできる（405 件が true）。
使い分けは、常時自動＝Business Rule、その場限り＝Background Script、移送して1回だけ＝Fix Script。Fix Script は移送できてスクリプトが残る点が Background Script と違う。

Fix Script の考え方は、ServiceNow 公式の Fix scripts（Zurich）でも「アプリ導入・アップグレード後にデータ整合性のため流すサーバ側スクリプト」として説明されています。

次に読むなら

Fix Script が「メタデータとして移送され、移送先で1回流す」道具だと分かると、その前提にある Update Set（sys_update_set / sys_update_xml）の仕組みが効いてきます。また、Fix Script の script 本体で呼ぶ再利用ロジックは Script Include（sys_script_include）にまとめられますし、「1回ではなく定期的に流したい」処理は Scheduled Jobs（定期実行）の領域になります。常時自動で効かせたいロジックとの対比は Business Rule の記事で確認できます。