Update Set（sys_update_set）：設定を運ぶ2層の箱

2026年6月21日 12:48

ServiceNow で開発した変更（Business Rule や Script Include、ACL など）を、別の環境へ運ぶ仕組みが Update Set です。開発インスタンスで作った設定を、検証環境や本番環境に「移送」するときに使います。公式ドキュメントでも、複数のインスタンス間でカスタマイズを移すための仕組みとして説明されています（System update sets）。

この Update Set は、ひとつのテーブルではなく、2つのテーブルの組み合わせで成り立っています。変更をまとめる箱が sys_update_set（Update Set 本体） です。その中に記録される個々の変更が sys_update_xml（Customer Update）です。この記事では、この2つのテーブルを実機で確認します。Update Set がどう変更を記録し、どう環境間を移送されるのかを構造として示します。Update Set は「設定をまとめる箱」と「箱に記録される個々の変更」の2層です。運ばれるのは設定であって、テーブルのデータではありません。

この記事は、ServiceNow の Incident などは触ったことがある管理者・開発者を想定しています。Update Set による移送の仕組み（何がどこに記録されるのか）を、これから理解したい人向けです。とくに「移送したのに反映されない」「Update Set を持っていったのにデータが入っていない」という疑問の背景を、テーブル構造から読み解きます。

この記事で分かること

Update Set が sys_update_set（本体）と sys_update_xml（個々の変更）の2層でできていること
sys_update_set の state（in progress / complete / ignore）と application（scope）の意味
変更が sys_update_xml に type 別に記録されること（PDI 実機の type 分布）
「設定は記録され、テーブルのデータは原則記録されない」という観察
retrieve → preview → commit という移送の流れと、関わるテーブル
「移送したのにデータが入っていない」と感じる理由の手がかり

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、Update Set の件数・記録される変更の種類・移送の挙動が異なる場合があります。

Update Set（移送の仕組み）とは

Update Set とは、ServiceNow 上で行った設定変更（カスタマイズ）をひとまとめにして、別の環境へ運ぶための仕組みです。開発インスタンスで Update Set を「開いた」状態にしておくと、その間に行った設定変更が自動的にその Update Set へ記録されていきます。開発が終わったら Update Set を完了させ、移送先のインスタンスで取り込みます。

ポイントは、Update Set 自体が変更内容を直接持つのではなく、変更1件ごとに別レコード（Customer Update）として記録される点です。この記事では、その入れ物である sys_update_set と、中身である sys_update_xml を分けて確認します。

今回確認した PDI（Zurich / OOTB）では、sys_update_set と sys_update_xml はどちらも他のテーブルを継承しない単独のテーブル（ルートテーブル）でした。task や cmdb_ci のような継承ツリーは持たず、両者は「参照（reference）」でつながっています。

Update Set 本体（sys_update_set）と個々の変更（sys_update_xml）

Update Set の構造は、「箱（本体）」と「中身（変更）」の親子関係として見ると分かりやすくなります。

sys_update_set（Update Set 本体）は、name（名前）・state（状態）・application（対象アプリ）などを持つ「箱」です。一方、sys_update_xml（Customer Update）は「変更1件＝1レコード」を表します。Business Rule を1つ変更した、System Property を1つ変えた、といった内容です。sys_update_xml は update_set フィールドで、自分がどの Update Set に属するかを指しています。

今回確認した PDI では、sys_update_set（本体）は 21 件、sys_update_xml（記録された個々の変更）は 1,337 件ありました。1つの Update Set に多数の変更がぶら下がるため、本体の数より変更の数のほうがずっと多くなります。

主なフィールド

それぞれの主なフィールドは次のとおりです。ラベルは画面上の表示名で、実機どおり英語で記載します。

テーブル        Field        Label        Type / 参照先               説明
--------------------------------------------------------------------------
sys_update_set  name         Name         String                      Update Set の名前
sys_update_set  state        State        String（choice）            in progress / complete / ignore
sys_update_set  application  Application  Reference → sys_scope       対象アプリ（scope）
sys_update_set  parent       Parent       Reference → sys_update_set  親 Update Set（Batch）
sys_update_set  is_default   Default Set  Boolean                     既定の Update Set か
sys_update_xml  type         Type         String                      変更の種類（Business Rule 等）
sys_update_xml  target_name  Target name  String                      変更対象の名前
sys_update_xml  table        Table        Table name                  変更対象の物理テーブル
sys_update_xml  update_set   Update set   Reference → sys_update_set  属する Update Set
sys_update_xml  payload      Payload      String（XML）               変更内容そのもの
sys_update_xml  action       Action       String                      INSERT_OR_UPDATE 等

sys_update_xml 側で見るべきフィールドは type（変更の種類）、target_name（変更対象の名前）です。ほかに table（変更対象の物理テーブル）、payload（変更内容そのものを表す XML）もあります。payload に実際の変更内容が XML として丸ごと入っているため、移送先ではこの XML を適用することで変更が再現されます。

テーブル定義は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_update_set_list.do
https://<YourInstance>/sys_update_xml_list.do

Update Set の state（in progress / complete / ignore）と scope

state（3つの段階）

sys_update_set の state は、その Update Set が今どの段階にあるかを表します。今回確認した PDI（Zurich / OOTB）では、state の選択肢は3つでした。

in progress（開発中） … 既定値。この状態の間、行った設定変更がこの Update Set に記録されます。
complete（完了） … 開発を締めた状態。一般に、移送先へ運ぶのはこの完了済みの Update Set です。
ignore（無視） … 移送対象から外したい場合の状態です。

今回の PDI では、state=in progress が 20 件、complete が 1 件、ignore が 0 件でした。また is_default=true（既定の Update Set）が 1 件あり、これはどの Update Set も明示的に選んでいないときに変更が記録される受け皿になります。

application（scope）による記録先の違い

もうひとつ大事なのが application（scope）です。sys_update_set は application フィールドで sys_scope（アプリケーション）を参照します。Update Set は「どの scope の変更を集めるか」を持つわけです。今回の PDI では、記録された変更（sys_update_xml）1,337 件のうち application=global が 1,246 件でした。残りは個別の scoped アプリに属していました。scope が違うと変更の記録先も変わります。移送のときは scope を意識しておくと安全です。

state は、次のURLで一覧できます。

https://<YourInstance>/sys_choice_list.do?sysparm_query=name=sys_update_set^element=state^ORDERBYsequence

何が記録され、何が記録されないか（type 分布から見る）

先に結論です。Update Set に記録されるのは設定（コンフィグレーション）であって、テーブルに入っている業務データそのものは、一般に記録されません。「移送したのにデータが入っていない」という疑問は、この点に行き当たります。どのカスタマイズが追跡されるかは、公式の Customizations tracked by update sets に整理があります。

type 別の件数（実測）

これを実機の type 分布で確認します。sys_update_xml には type（変更の種類）があり、type 別に件数を数えると、記録されているのが設定オブジェクトであることが分かります。

type（変更の種類）  件数   メモ
-------------------------------
Test Step           995    ATF テストのステップ。PDIに多い
System Property     71     sys_properties（システム設定値）
Access Control      56     ACL（権限定義）
UI Action           8      ボタン・メニュー
Dictionary          8      フィールド定義
Business Rule       5      保存時のサーバ処理
Field Label         5      フィールドのラベル
その他（裾）        約189  Script Include / View Template / UI Page / Table / Module 等

今回の PDI（Zurich / OOTB）では、type は Test Step が 995 件と最多でした。続いて System Property 71、Access Control 56、UI Action 8 です。ほかに Dictionary 8、Business Rule 5、Field Label 5 もあります。残り約189件は Script Include / View Template / UI Page / Table / Module など多種にわたります。Test Step が突出しているのは、この PDI に ATF（自動テスト）のステップが多数記録されているためで、この分布はこの PDI 固有のものです。一般化はしません。

注目したいのは、これらがいずれも「設定」だという点です。実際に、target_name が「INC」で始まるレコードを確認します。14 件すべてが type=Access Control（incident.close_notes や incident.* などへの ACL 定義）でした。つまり「INCxxxxxxx という incident の業務レコード」ではなく、incident テーブルに対する権限設定が記録されているのです。

一般に、こうした設定は Update Set に記録されます。具体的には Business Rule・Script Include・UI Action・ACL・Dictionary・System Property・UI Policy などです。incident や task などのテーブルに入っている業務データ（レコードそのもの）は記録されません。だから、設定を移送しても「テーブルのデータ」は運ばれず、移送先でデータが空に見えることがあります。これが「移送したのにデータが入っていない」と感じる主な理由です。

ただし、「何が記録され何が記録されないか」を網羅的に確定するのは PDI 単体では難しく、ここでは type 分布と target_name の実例からの観察にとどめます。細部（特定テーブルが記録対象か否かの完全な一覧）は確認範囲外です。

変更の一覧は、次のURLで type 別に確認できます。

https://<YourInstance>/sys_update_xml_list.do?sysparm_query=update_set=<Update SetのsysID>

移送の流れ（retrieve → preview → commit）と関連テーブル

移送は「受け取る（retrieve）→ 事前検証する（preview）→ 適用する（commit）」の3段階を踏みます。開発側で完了させた Update Set を移送先に反映するまでの流れです。各段階の操作は、公式の Working with update sets にまとまっています。

ServiceNow における Update Set のポイント

Update Set は sys_update_set（本体・箱） と sys_update_xml（Customer Update＝個々の変更） の2層でできています。本体が name / state / application を持ち、変更が update_set 参照で本体にぶら下がります。今回の PDI では本体 21 件・変更 1,337 件でした。
state は in progress（開発中・記録される）／ complete（移送可能）／ ignore（除外）の3つでした。is_default の Update Set が記録の受け皿になります。
application（scope）によって変更の記録先が変わります。今回の PDI では変更の多く（1,246 / 1,337）が global scope でした。
sys_update_xml には設定オブジェクト（Business Rule / ACL / System Property / Dictionary / Test など）が記録されます。type 別に区別されます。incident などの業務データそのものは一般に記録されません。target_name=INC* の実例も、incident レコードではなく incident テーブルへの ACL 設定でした。
移送は retrieve（受け取る）→ preview（検証）→ commit（適用）の流れです。sys_update_set_source（取得元）・sys_remote_update_set（受け取り）・sys_update_preview_problem（問題）が関わります。

「移送したのに反映されない／データが入っていない」と感じたら、まず「運ぼうとしているのは設定か、それとも業務データか」を切り分けます。設定なら Update Set に記録されますが、テーブルのデータは原則 Update Set では運ばれません。次に、Update Set が complete になっているかを確認します。移送先で commit まで進んでいるか（sys_remote_update_set の state）、preview で problem が出ていないかも確認します。

実機を見て気づいたこと

sys_remote_update_set（受け取り側）の state は loading / loaded / previewed / committed 程度だろうと思っていましたが、実機で選択肢を数えると batch・stash 系を含めて全15値ありました。単純な受け取り→適用だけでなく、複数の Update Set をまとめて扱ったり、一時的に退避したりする運用まで想定した作りになっています。
sys_update_set には base_update_set・merged_to という見慣れないフィールドがあります。最初は Update Set は1件ずつ単独で移送するものだと思っていましたが、これは複数の Update Set をまとめて移送する Batch Update Set の手がかりで、単体の移送だけを前提にした設計ではありませんでした。

次に読むなら

次に確認するなら3つあります。1つ目は、Update Set に変更が記録される仕組みそのもの（sys_update_version によるバージョン管理と、どの操作が記録対象になるか）です。2つ目は、scoped アプリと global の移送の違いです。3つ目は、Batch Update Set（親子でまとめて移送する仕組み・parent / base_update_set）です。さらに、ServiceNow が推奨する Update Set 以外の移送手段（Source Control 連携や、アプリ単位の配布）との使い分けも、運用設計では効いてきます。これらは本記事で触れた sys_update_xml / sys_remote_update_set の仕組みの先にあたり、別記事で扱う予定です。

用語

PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
Update Set：設定変更をまとめて環境間で運ぶ仕組み
Customer Update：Update Set に記録される個々の変更（sys_update_xml の1レコード）
scope（application）：変更が属するアプリケーション範囲（global / scoped）
retrieve / preview / commit：受け取る／事前検証する／適用する、の移送3段階
ATF：Automated Test Framework（自動テスト。Test Step を生む）

自分の環境で確認するときのURL

先頭に自分のインスタンスを付けると、同じ画面が開けます。

Update Set 本体     : sys_update_set_list.do
記録された変更       : sys_update_xml_list.do
state 選択肢         : sys_choice_list.do?sysparm_query=name=sys_update_set^element=state^ORDERBYsequence
取得元インスタンス   : sys_update_set_source_list.do
受け取った Update Set: sys_remote_update_set_list.do
プレビュー問題       : sys_update_preview_problem_list.do

検証範囲とおことわり

確認した範囲：sys_update_set / sys_update_xml の階層（共にルートテーブル）、固有フィールド、state 選択肢、件数（本体21 / 変更1,337）です。加えて、type 分布（実測 count）、target_name=INC* の正体（incident への ACL であって業務データではない）も確認しました。関連テーブル（sys_update_set_source / sys_remote_update_set）の存在と件数も確認しました。sys_update_preview_problem / sys_update_version の存在と件数も確認しました。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています。
確認していない範囲：記録対象テーブルの完全な一覧（何が記録され何が記録されないかの網羅）、retrieve → preview → commit の実動作です。ほかに、scope（global / scoped）ごとの移送挙動の細部は確認していません。sys_update_version によるバージョン管理・ロールバックの詳細、Batch Update Set の挙動も確認していません。これらは別記事で扱う予定です。type 分布（特に Test Step の多さ）はこの PDI 固有であり、一般の環境を表すものではありません。

今回は PDI の OOTB（初期設定）を前提に、Update Set のテーブル構造を確認しました。実環境では、既存のカスタマイズや運用方針によって、記録される変更の種類・件数・移送の手順が変わります。