Update Setはどこに溜まるか：Defaultに1358件という実測
「Update Setを完了して移送したのに、実際に持っていった環境には反映されていない変更がある」。この種のつまずきの裏側には、たいてい同じ原因があります。作業中に切り替えたはずのUpdate Setが実は切り替わっておらず、変更が別の場所に流れ込んでいたというケースです。
その「別の場所」の代表が、どのインスタンスにも最初から存在するDefaultというUpdate Setです。PDIのUpdate Set一覧とその中身を開いて確認したところ、このDefaultに1,358件の変更が溜まっていました。23件あるUpdate SetのうちCompleteになっていたのはわずか1件だけで、残り22件はin progress（作業中）のまま放置されていました。
この記事では、まずUpdate Setを構成する3つのテーブルの役割を公式ドキュメントで押さえ、そのうえで実機の一覧画面を見ながら、なぜDefaultに変更が集中するのかを数字で追います。
この記事で分かること
Update Setがsys_update_set・sys_update_xml・sys_remote_update_setの3テーブルで動くこと
stateの選択肢は3つ（in progress / complete / ignore）で、値に半角スペースが入ること
実機の一覧画面ではDefaultに1,358件の変更が溜まっており、23件中Completeは1件だけだったこと
sys_update_xml 1,449件のうちTest Stepが7割近くを占める内訳
この記事は、ServiceNowのPDI（Personal Developer Instance、無料の個人検証環境）Zurichリリースで確認した実測メモです。Update Set関連の一覧画面を実際に開き、表示された件数をそのまま記録しました。本番環境では件数・運用状況が異なります。
公式ドキュメントで押さえる基本
Update Setは、開発環境で行った設定変更を検証環境や本番環境へ移すための仕組みです。実機の数字を見る前に、公式ドキュメントに基づいて基本を確認します。
Update Setとは何か
公式ドキュメント「System update sets」によると、Update Setはインスタンス間で設定変更をまとめて移送するための仕組みです。開発中に行ったカスタマイズは、その時点で選ばれているUpdate Setに自動的に記録されます。1件ずつ手作業で環境間の設定を合わせる必要がなく、開発した内容をそのまま別の環境へ運べる点が狙いです。
3つのテーブルが役割を分担する
Update Setの仕組みは1つのテーブルだけで完結しません。公式ドキュメントで定義されているとおり、次の3つのテーブルが役割を分担しています。
sys_update_set（Update Set本体）… 変更をまとめる箱。name・state・applicationを持つ
sys_update_xml（Customer Update）… 箱の中身。変更1件が1レコードで、update_setフィールドで親を参照する
sys_remote_update_set（Retrieved Update Set）… 他インスタンスから受け取った側の記録。移送先で作られる
sys_update_setが「作業中の箱」、sys_update_xmlが「箱に入った1件ずつの変更」、sys_remote_update_setが「よそから受け取った箱の記録」という関係です。開発側で変更を積んでいくのが最初の2つ、移送先で受け取った履歴を持つのが3つ目という役割分担になります。テーブル定義そのものは、公式のSystem update setsにまとまっています。
Defaultという特別な置き場
公式ドキュメント「Working with update sets」は、Update Setを作成・選択しないまま行った変更の扱いも明記しています。専用のUpdate Setへ切り替えていない状態で行った変更は、Defaultという、どのインスタンスにも最初から存在するUpdate Setに記録されます。そしてDefaultは他インスタンスへ移送できない置き場として扱われる特別なUpdate Setです。ここに積み上がった変更は、原則として持ち出せません。
移送はretrieve→preview→commitの3手順
開発側で変更を積み終えたら、Update Setをcomplete（完了）にしてエクスポートし、移送先のインスタンスで取り込みます。公式ドキュメントの「Retrieve an update set」「Commit an update set」によると、取り込み側の操作は3段階に分かれます。手順はretrieve（取得）・preview（プレビューで競合を確認）・commit（適用）です。retrieveした時点でsys_remote_update_setにレコードが作られ、previewで既存レコードとの競合（Collision）を検出し、commitで実際に変更が適用されます。
実機で確かめる
ここからは、上で確認した基本がPDIの実機でどう見えるかを画面ごとに確認します。
一覧の見方
Update Setsの一覧はApplication Navigatorの System Update Sets > Update Sets から開けます。Name・Application・State・Installed from・Createdなどの列が並び、作成日時の新しい順に表示されていました。
この一覧だけでは、23件全体でstateがどう分布しているかまでは見えません。次にState列でグループ化して確認します。
stateは3つだけ
sys_update_setのstate項目には、選択肢が3つしかありません。sys_choiceの一覧を開くと、次のとおり確認できます。
見落としやすいのがValue列の表記です。表示ラベルは「In progress」ですが、内部値はin progressとアルファベットが2語に分かれ、間に半角スペースが入ります。GlideRecordのクエリやスクリプトの条件式でstate=inprogressのようにスペースを詰めて書くと、意図した条件と一致しません。
Update Sets一覧の画面でState列でグループ化すると、実際の分布が見えます。
グループの見出しには件数がそのまま表示されます。合計23件のうち、in progress（作業中）が22件、complete（完了）が1件でした。ignoreは0件です。差は歴然でした。完了して初めて移送の対象になる、という前提に立つと、この時点で移送できる状態にあったUpdate Setは23件中1件しかなかったことになります。残り22件は、開発が終わっていないのか、完了への切り替えを忘れているだけなのか、一覧の見た目だけでは区別できません。
Defaultの中身は1,358件
23件のうちDefaultを開き、update_setがDefaultと一致する変更（Customer Update, sys_update_xml）を一覧表示すると、次の画面になります。
一覧の総件数を確認すると1,358件です。Defaultは1つのUpdate Setとしては突出した量の変更を抱え込んでいました。
23件のUpdate Setのうち、実際に変更が入っていたのは何件だったのかも確認します。sys_update_xmlをupdate_setでグループ化して件数順に並べると、次の結果になりました。答えは5件でした。
変更が1件以上入っていたUpdate Setは、23件中わずか5件でした。5件の変更数を合計すると1,449件になり、これはsys_update_xmlの総件数と一致します。残る18件のUpdate Setは、作られただけで一度も変更が記録されていない空の箱だったことになります。5件の内訳を見ると、Defaultが1,358件で全体の93.7%を占めていました。2番目に多かったソフトウェア利用申請の開発用に作られたUpdate Setでも68件、そのほかは十数件以下です。
Defaultの詳細を1件だけ抜き出すと、スコープはGlobal、stateはIn progressでした。ここに積み上がった変更は、移送を前提に開発を進めるなら原則として持ち出せないものと考えておく必要があります。
変更の内訳
sys_update_xmlの総件数1,449件を、type別に集計した結果です。
結果は明確でした。最も多かったのはTest Stepで997件、全体の68.8%でした。これはATF（Automated Test Framework）のテストケースを構成するステップです。2位はAccess Control（84件）、3位はSystem Property（79件）で、ここまでの3種類で全体の8割に達します。
実際の一覧画面でもType列でグループ化すると、この内訳を確認できます。
Test Stepが多い理由として考えられるのは、ATFのテストケースを組み立てる作業そのものが、ステップ単位で細かく変更を積み重ねる性質を持つ点です。1つのテストシナリオを作るだけで、数十件のステップが記録されることも珍しくありません。ただしこの比率は、あくまで今回のPDIに限った傾向です。ATFを使わない開発が中心の環境では、Business RuleやScript Includeが上位に来ることも十分に考えられます。この分布を一般化はしません。
取り込み側の記録
送り出す側だけでなく、受け取る側の記録も確認します。Retrieved Update Sets（sys_remote_update_set）の一覧です。
このテーブルには、他インスタンスからUpdate Setを受け取ったときの記録が並びます。実機では1件のみで、名前は「Bulk Download-Rename of Update Sets」、stateはCommittedでした。Committedは、previewを経て実際に変更が適用された状態を指します。開発の大半がこのインスタンス上で直接行われていたため、受け取り側の記録は少なかったと考えられます。
事故が起きる仕組みと防ぎ方
なぜDefaultに溜まるのか
理由は単純です。Update Setには「今どれが選ばれているか」を示す、セッションごとの現在値があります。開発を始めるときに専用のUpdate Setを作って切り替えていれば、その後の変更は選んだUpdate Setに記録される仕組みです。反対に、切り替えを忘れたまま、あるいは切り替えたつもりで実は切り替わっていない状態で作業を続けると、変更はその時点で選択されているUpdate Setに記録され続けます。
今回の一覧確認に照らすと、23件中18件が空でした。多くのUpdate Setが「作っただけで使われなかった」ことになります。新しいUpdate Setを作る運用そのものは徹底されていたようです。ただ、実際に選択を切り替える手順のほうが抜け落ち、変更の大半がDefaultに流れ込んだという筋道が浮かび上がりました。ServiceNowのコミュニティにも、Defaultを不用意に操作しないよう促す記事があります。「ServiceNow Update Set Leading Practices Part 2」には、Defaultを扱う際の注意点が載っています。sys_update_xmlのupdate_setフィールドを直接書き換えないこと、Defaultをback out（差し戻し）しないことの2点です。
どう防ぐか
打ち手は難しくありません。Update Setを「作る」ことと「選択して使い続ける」ことは別の手順だという点を意識するだけで、切り替え忘れは見つけやすくなります。作業の起点をUpdate Setの新規作成ではなく、作成直後に現在のUpdate Setとして選ばれているかどうかの確認に置くとよいでしょう。
件数の面でも公式の目安があります。出典は「ServiceNow Update Set Leading Practices Part 1」です。1つのUpdate Set（sys_update_xmlレコード）につき500〜1,000件程度に抑え、それを超える場合は分割するのが望ましいとされています。今回のDefaultは1,358件で、この目安をすでに超えていました。定期的にDefaultの中身を件数だけでも確認し、増え続けているようなら作業用のUpdate Setへ切り替えるタイミングだと判断できます。
つまずきやすい点
valueの半角スペース。stateの内部値はin progressで、スペースを詰めたinprogressと書くとクエリが一致しません。
Defaultは移送できない置き場として扱われます。ここに積み上がった変更は、原則として他インスタンスへ持ち出せません。
空のUpdate Setは一覧に紛れます。今回も18件が中身ゼロでした。state別・update_set別にグループ化しない限り、この空の箱には気づきにくいものです。
Completeにしただけでは移送は終わりません。完了は「移送可能な状態にした」という印にすぎず、実際に運ぶにはretrieve・preview・commitという別の手順が必要です。
上位のUpdate Set名だけでは中身が判断できません。名前が付いていないUpdate Set（今回も1件ありました）が普通に存在し、これも移送候補になり得ます。
よくある質問
Default Update Setを今すぐ空にしてもいい？
Defaultの中身を実際に移動・削除する操作は、この記事では検証していません。1,358件の変更を別のUpdate Setへまとめて移し替える一括操作の有無や、その安全性については確認範囲外です。手を付ける前に、まず自分の環境でテストしてから進めることをおすすめします。
state=in progressが22件あるのは異常なこと？
件数だけで異常とは判断できません。開発中のUpdate Setがin progressのままなのは自然な状態です。ただし今回確認した一覧では、23件中18件が中身ゼロでした。in progressのまま長期間放置されているUpdate Setがあるなら、開発が止まっているのか、単に切り替え忘れているだけなのかを個別に確認する価値があります。
Update Setを完了するとどうなる？
stateがcompleteに変わり、一般には移送可能な状態として扱われます。ただしこの記事では、実際に完了操作を行って前後の挙動を比較してはいません。complete後の具体的な変化は、公式ドキュメントのWorking with update setsで確認できます。
sys_remote_update_setが1件しかないのはなぜ？
Retrieved Update Setsの一覧に並ぶのは、retrieve（取得）が行われた記録です。読み込んだだけでは変更は反映されず、previewでの競合確認とcommitを経て初めて適用されます。1件だけだったのは、このPDIでは外部からの取り込みがほとんど発生していなかったことの表れです。開発の大半がこのインスタンス上で直接行われていたと考えられます。
この記事の数字は自分の環境にもそのまま当てはまるか？
当てはまりません。件数や比率はこのPDI固有の実測値です。特にTest Stepの比率は、ATFを使う開発の有無で大きく変わります。自分の環境で同じ確認をする場合は、Update Sets一覧をStateやUpdate setでグループ化し、実際の分布を見ることをおすすめします。
まとめ
Update Setはsys_update_set（本体）・sys_update_xml（個々の変更）・sys_remote_update_set（受け取り側）の3テーブルで動く
stateの選択肢は3つ（in progress / complete / ignore）で、値には半角スペースが入る
一覧の確認では23件中Completeは1件だけ、22件がin progressのままだった
変更が入っていたUpdate Setは23件中5件のみで、残り18件は空だった
Defaultには1,358件が集中し、これは変更が入っていた5件の合計の93.7%にあたる
sys_update_xml全体1,449件のうちTest Stepが997件（68.8%）を占める
数字を並べてみると、問題は「Update Setという仕組みが複雑だから」ではなく、「作業を始めるときの切り替えという1手順が抜け落ちやすいから」という側面が大きいと分かります。Update Setを新しく作る操作と、それを現在のUpdate Setとして選び続ける操作は別物です。この2つを混同しないことが、Defaultへの集中を防ぐ最初の一歩になります。
用語
Update Set … 設定変更をまとめて別インスタンスへ運ぶための仕組み
sys_update_set … Update Set本体。name・state・applicationを持つ
sys_update_xml（Customer Update） … Update Setに記録される個々の変更1件
sys_remote_update_set（Retrieved Update Set） … 他インスタンスから受け取ったUpdate Setの記録
Default … 各インスタンスに最初から存在するUpdate Set。移送できない置き場として扱われる
ATF（Automated Test Framework） … 自動テストの仕組み。Test StepがUpdate Setに記録される
Commit … retrieveしたUpdate Setの変更を実際に適用する操作。previewで競合を確認したあとに行う
自分のインスタンスで確認する場合のURL
自分のインスタンスで同じ確認をする場合は、次のURLが役立ちます。Update Set名やsys_idの部分は自分の環境の値に置き換えてください。
/sys_choice_list.do?sysparm_query=name=sys_update_set^element=state^ORDERBYsequence（state選択肢の一覧）
/sys_update_set_list.do?sysparm_query=name=Default（Default Update Setの詳細）
/sys_update_xml_list.do?sysparm_query=GROUPBYupdate_set（Update Set別の変更件数）
/sys_update_xml_list.do?sysparm_query=GROUPBYtype（type別の変更件数）
/sys_remote_update_set_list.do（取り込み側の一覧）
参考リンク
ServiceNow Update Set Leading Practices Part 1（ServiceNow Community）
ServiceNow Update Set Leading Practices Part 2（ServiceNow Community）
Everything You Need To Know About Using Update Sets（ServiceNow Community）
検証範囲とおことわり
確認した範囲：sys_update_setのstate選択肢と件数（23件）、Default Update Setの詳細と変更数（1,358件）、変更数の多いUpdate Set上位5件、sys_remote_update_setの件数（1件）、sys_update_xmlの総件数（1,449件）とtype別内訳です。すべてPDI（Zurich）を対象に、Update Set関連の一覧画面・グループ化表示で確認しました。
確認していない範囲（断定しません）：Update Setを実際に作成・完了・エクスポート・取り込み・プレビュー・コミットする一連の操作です。コミット時の競合（Collision）の実例も確認していません。Update Setに入らない変更（データ、スコープ外、sys_propertiesの一部など）の網羅、Update Set Batchの挙動も確認していません。
本番環境での件数や運用状況は、この記事の数字とは異なります。特にTest Stepの比率はこのPDI固有の傾向で、ATFを使わない環境ではそのまま当てはまりません。
Defaultに溜まった変更を安全に移し替える具体的な手順は、この記事の範囲外です。実施する場合は、必ず検証環境で確認してから進めてください。
