Update Setで移送できるもの できないものを整理する 最短理解ガイド

仕組みの前提 Update Setは何を運ぶ道具か

Update Setは、開発環境で行った変更を別インスタンスへ届けるための仕組みです。ただし重要なのは、Update Setが運ぶ中心は設定や構成の変更であって、日々増えていく業務データを丸ごと運ぶ仕組みではない、という前提です。

ここを曖昧にしたまま進めると、「移送したのに動かない」「画面はあるのにデータがない」「参照が切れている」などの違和感が出ます。CSAの学習でも、暗記で片付けずにこの前提を押さえておくと、開発・移送・運用の話がつながって理解しやすくなります。

Update Setが得意なのは、例えば次のような“アプリのふるまいを決める設定”です。

• テーブルやフィールドなどの定義
• フォームやリストのレイアウト
• Choiceの追加やラベル変更
• 一部のワークフロー系の定義
• カタログアイテム定義や変数などの設定

一方で、カタログをテストするために実際に発注して作られた注文やタスクは、Update Setの対象としては扱われません。これは公式ドキュメントでも「設定は追うが、注文などのプロセスデータは追わない」例として明確に説明されています。

この「設定を運ぶ」「実データを運ぶは別手段」という切り分けが、移送できる・できないを整理する最短ルートです。

---

移送できるものを見分ける基準 update synchと特別ハンドラ

では、何がUpdate Setに入るのか。公式ドキュメントは判断基準をかなりはっきり示しています。大きくは次の条件です。

• 対象テーブルに update_synch 属性がある
• 変更が複数テーブルにまたがる場合でも、特別ハンドラが用意されている
• 管理者が特定フィールドを「更新セット対象外」にしていない

ここで大事なのは、「Update Setに入るかどうか」は気分や経験だけでなく、仕組みとして決まっている点です。

update_synchで判断する考え方

公式では、update_synchが付いたテーブルが“Update Setで追跡される候補”であり、一覧は辞書から属性でフィルタできる、と説明されています。
つまり実務的にはこう考えられます。

• その変更が保存される先のテーブルにupdate_synchがある
  → 追跡される可能性が高い
• そもそもupdate_synchがない
  → 自動では追跡されない可能性が高い

そして、update_synchは「データ移送のために付け足すもの」ではありません。誤用すると性能問題や深刻な衝突につながるため、顧客が自由に付与できないようにしている、という強い注意書きがあります。
この注意書きは、Update Setが“データ移送ツールではない”という設計思想をそのまま表しています。

特別ハンドラがある変更の代表例

複数テーブルにまたがる変更は、そのままだと更新が欠けたりズレたりします。そこで公式は、次のような項目は特別ハンドラでひとまとめにして追跡すると説明しています。

• Workflows
• フォームセクション
• リスト・関連リスト
• Choice lists
• システム辞書エントリ
• フィールドラベル

ただし、この“ひとまとめ”には副作用もあります。フォームセクションやChoiceなどは削除して再挿入する動きをするため、参照関係があると想定外の結果やデータ損失につながり得る、という警告も明記されています。
ここはCSAでも、仕組み理解として押さえておくと「なぜ移送で壊れることがあるのか」を説明できるようになります。

---

移送できないことが多いもの 実データとプロセスデータの考え方

「移送できないもの」を丸暗記するより、なぜ対象外になりやすいかを言語化した方が強いです。コツは2つあります。

• 実データか
• プロセスデータか

実データは基本的に別ルート

公式は、Update Setはアプリケーションファイルとして移せるデータ量に限りがあり、大きなデータ移送にはImport SetやWebサービスなど別手段を使うよう案内しています。
この一文が示すのは、実データをUpdate Setで無理に運ぶより、データ移送はデータ移送の道具を選ぶのが正道、ということです。

実務で言う“実データ”の例はこんなイメージです。

• インシデントやリクエストなど、運用で日々蓄積されるレコード
• マスタっぽく見えるが、環境固有の前提が強いレコード
• 大量に存在し、更新頻度も高いデータ

これらは、Update Setが追う「設定」ではなく「結果や履歴」になりやすいため、移送の主役にすると設計が破綻しがちです。

プロセスデータは追跡しない例が公式にある

さきほど触れたカタログの例が分かりやすいです。カタログアイテムや変数の定義は追うが、テストで発生した注文・アイテム・タスクは追わない、と具体例つきで説明されています。
この切り分けを覚えると、他の領域でも応用できます。

• 定義や画面構成は“設定”
• 実行して生まれたものは“プロセスデータ”

試験でも現場でも、ここを取り違えると混乱しやすいポイントです。

---

例外や注意点 ホームページ 辞書変更 アプリ配布方式で起きること

この章は、Update Set移送で「できるはずなのに…」が起きやすいところを、公式の注意書きベースで整理します。

ホームページとコンテンツページは自動では入らない

公式は、ホームページとコンテンツページはUpdate Setにデフォルトでは追加されないと明言し、必要ならアンロードで追加する、と説明しています。さらに新しい体験ではダッシュボードが主流であり、変換ツールの案内まであります。
ここは“移送できない”ではなく、“自動追跡の対象外なので手当が必要”という理解が近いです。

辞書変更は安全側に倒れる

辞書変更は危険度が高いので、Update Setはデータ損失につながる変更をブロックしたり、コミット時にスキップしたりします。例えば、テーブル削除は追跡しない、型変更は追跡しても損失が出るなら対象側でスキップしてログに残す、といった動きが説明されています。
ここを知らないと「Update Setに入っているのに反映されない」という現象が起きます。反映されないのは失敗ではなく、安全のために止めている場合がある、という視点が重要です。

アプリ配布方式を混ぜない

スコープアプリ開発で、Update Setとアプリ配布の仕組みを混ぜると、スキップやコミットエラーなど多数の問題につながる、と公式は注意しています。いったんアプリ配布方式で進めたなら、その方式で継続すべき、という趣旨です。
これも「移送できる・できない」というより、移送の方式選定の話です。方式を統一するのが結局いちばん安定します。

---

実務の進め方 プレビューと依存関係 代替手段 つまずき回避

最後は、現場で再現性が高い進め方に落とします。ここを押さえると、Update Setの話が“知識”から“運用”になります。

プレビューで見るべきは差分ではなく依存

Update Setはプレビューで衝突や不足を見つけやすくなっていますが、重要なのは「差分があるか」より「依存が満たされているか」です。例えば、フォームは移っても、参照先のマスタや前提設定が別ルート管理だと、画面は出ても選択肢が空になる、といったことが起きます。

おすすめの考え方はこれです。

• 反映したい変更を一文で言えるようにする
• それを成立させる前提設定を洗い出す
• 前提がUpdate Set対象かどうかをupdate_synch観点で当たりを付ける
• 対象外なら、最初から別ルートを選ぶ

データ移送の代替手段を先に用意する

公式が案内している通り、大きなデータ移送はImport SetやWebサービスなどを検討します。
「Update Setで頑張る」より「正しい道具を選ぶ」方が、結果として工数が減ります。

整理するとこうです。

• 設定変更
  → Update Set
• 大きなデータ移送
  → Import Set、インスタンス間インポート、Webサービスなど
• スコープアプリの配布
  → 方式を決めて混ぜない

学習者向けのつまずき回避メモ

CSA学習者が混乱しやすいのは、「見た目が設定っぽいものが、実はデータ寄り」のケースです。ホームページが代表で、自動で入らないからこそ、移送設計で意識しておく価値があります。
また辞書変更は、反映されないこと自体が仕様の可能性があるので、ログと安全設計の視点で理解しておくと整理しやすいです。

体系的に学ぶ教材の一例

Update Setは「何が入るか」ではなく「なぜ入るか」を押さえると一気に楽になります。独学だと点の知識になりがちなので、体系的に環境移送や開発プロセスを学べる教材を一本持っておくのも手です。例えば Udemy のServiceNow管理・開発入門系講座は、画面操作と概念整理をセットで追えるものが多く、復習にも向きます。

---

まとめ

Update Setで移送できるもの・できないものは、暗記よりも「仕組みで判断」する方が安定します。公式が示しているポイントはシンプルで、Update Setは主に設定変更を追跡し、追跡されるかどうかはupdate_synchや特別ハンドラなどの条件で決まります。

また、カタログの定義は追うが注文などのプロセスデータは追わない、という具体例がある通り、実データや実行結果をUpdate Setで運ぶのは設計としてズレやすいです。大きなデータ移送はImport SetやWebサービスなど別手段を選ぶのが公式の案内です。

ホームページが自動で入らない、辞書変更が安全のためにスキップされ得る、アプリ配布方式を混ぜると問題が起きやすい、といった注意点も公式にまとまっています。
このあたりを「なぜそうなるか」まで理解しておくと、移送のトラブル対応だけでなく、CSA学習でも前提知識として整理しやすくなります。なお、理解を点から線につなげたい場合は、ServiceNow の開発や移送の流れを通しで扱う教材を一つ用意して、手を動かしながら復習するのが近道です。