Zurich対応：ServiceNowの開発変更を本番へ安全に移す基本フロー（Update Set／App Repo／ATF）

ServiceNowの学習を進めていくと、どこかで必ずぶつかるのが「開発した変更を、どうやって本番に持っていくのが正しいの？」というテーマです。
CSAを目指す段階でも、用語としてのUpdate Setや、テストと本番の関係、ロールや権限の考え方は“前提として扱われやすい”ので、丸暗記ではなく、筋の通った理解を作っておくのが近道になります。

この記事では、Zurich環境を前提にしつつ、ServiceNow公式ドキュメントの考え方に沿って「開発→テスト→本番」の基本フローを、手順だけでなく“なぜそうするか”まで整理します。
（現場のルールは会社ごとに違いますが、土台になる原則は共通です。）

---

開発→本番移送は「3つの原則」で整理すると迷いにくい

最初に、細かい操作の前に“判断基準”を揃えます。ここが曖昧だと、移送のたびに手順がブレて事故が起きます。

原則1：開発は開発環境、テストはテスト環境、本番は本番で完結させる

• 開発環境：変更を作る場所（作り直しが効く）
• テスト環境：本番相当で検証する場所（検証の結果で修正が出る）
• 本番環境：利用者の業務が走っている場所（安全第一）

当たり前に見えますが、現場でよくあるのが「テスト環境で直接直して、そのまま本番へ…」の流れです。これをやると、変更の出どころが分からなくなり、再現性が崩れます。

原則2：「移送単位」を決めてから作る（Update Setか、アプリ配布か）

ServiceNowの変更には大きく2系統あります。

• 構成変更（設定・定義）を束ねて運ぶ：Update Set中心
• スコープアプリとしてバージョンで配布する：Application Repository（My Company Applications）中心

どちらも公式に用意された仕組みですが、向き不向きがあります。ここを混ぜるほど管理が難しくなります。

原則3：本番反映は「確認→適用→戻せる」をセットで運用する

本番は一発勝負にしないのが基本です。

• 確認：プレビューやテストで、差分と影響を見える化
• 適用：コミット／インストールで反映
• 戻せる：Back outやバージョン戻しなど、復旧導線を準備

---

Update Setの基本フロー：Retrieve→Preview→Commitを“意味”で理解する

Update Setは、ServiceNowの構成変更（レコードとしてのカスタマイズ）をまとめて移す仕組みです。Zurichでも基本は同じで、公式ドキュメントでも「プレビューして問題を解消してからコミットする」という流れが明確です。

Update Setで移しやすいもの

代表例（イメージ）

• フォームレイアウト、フィールド属性の変更
• Business Rule、Client Script、UI Policyなどの設定
• テーブル定義の一部（設計次第）
• ACLやロール周りの調整（ただし設計と検証が重要）

Update Setに頼りすぎると混乱しやすいもの

• データ移行（マスタデータ大量投入など）
• 環境依存の値（インスタンス固有の参照先）
• 「本番でしか存在しないもの」に依存する変更
• “気づいたら本番で直してた”系の変更（履歴が分断される）

Update Setは万能ではありません。だからこそ、後半で扱う「スコープアプリの配布」と使い分けが効いてきます。

---

開発→テストへの移送：Retrieve（取得）を使う考え方

移送には大きく2通りあります。

• XMLエクスポート／インポート：ファイルで持ち運ぶ
• Retrieve Completed Update Sets：インスタンス間で取得する（ネットワーク・権限前提）

公式ドキュメントでは、Completed状態のUpdate Setを対象に「Retrieve Completed Update Sets」で転送し、転送先でRetrieved Update Setsとして扱う流れが説明されています。
ここで重要なのは、**「開発でCompletedにしたものを、テストに持っていく」**という“節目”を作ることです。

ポイント：CompletedにしたUpdate Setは基本的に戻さない

よくある運用ミスが「Completedにしたけど追加が出たから、同じUpdate SetをIn progressに戻して追記」です。
これは公式の考え方としても推奨されにくく、基本は追加分は別のUpdate Setにするほうが、差分が追いやすく安全です（後から追跡・切り分けが効く）。

---

テスト側で必ずやること：Preview→Commitの意味

Preview：適用前に“衝突”と“依存”を見つける工程

プレビューは「やっておくと良い」ではなく、実務的には“保険”です。
依存関係が欠けていたり、先に入っている変更と衝突すると、この段階で違和感が出ます。

Commit：変更を反映し、ローカルに適用履歴を残す工程

公式ドキュメントでも、プレビュー後に問題を解消してからコミットする流れが説明されています。コミットは単に反映するだけでなく、適用内容がローカルに記録されていくイメージです。
ここを雑にすると「いつ、何が、どこまで入った？」が追えなくなります。

---

スコープアプリの移送：Application Repositoryを軸にすると整う

Update Setが「構成変更を束ねる」なら、スコープアプリは「アプリのバージョンとして配布する」発想です。

Application Repository（My Company Applications）でできること

公式ドキュメントでは、アプリケーションをアプリケーションリポジトリに公開し、別環境で「My Company Applications」からインストールする手順が整理されています。
この方式の良さは、バージョンが軸になることです。

• 開発：v1.2.0を作る
• テスト：v1.2.0をインストールして検証
• 本番：同じv1.2.0をインストールして反映

「同じものを入れる」という当たり前を、仕組みとして担保しやすくなります。

Update Setより向いているケース

• きちんとスコープアプリとして開発している
• バージョン管理と配布が必要
• 複数環境へ同じアプリを展開する前提がある

---

ソース管理連携：Zurichでも“使い方”を誤ると逆に辛くなる

ServiceNow Studioには、Gitリポジトリと連携できる「ソースコントロール統合」が用意されています（公式ドキュメントで説明あり）。
ただし、ここで誤解しやすいのは「Gitがあるから本番移送が全部自動になる」という発想です。

現実的には、こう整理すると混乱しにくいです。

• ソース管理：開発の履歴・差分・レビューを強くする
• 環境への反映：App Repo（バージョン配布）またはUpdate Set（構成変更配布）で統制する

つまり、ソース管理は“開発の品質”を上げる側、環境反映は“運用の品質”を上げる側、という役割分担です。

---

本番前の品質担保：ATFで「確認ポイントを固定」する

本番移送で怖いのは、「移送手順」よりも「確認漏れ」です。
人の目だけに頼ると、忙しい時ほど抜けます。

そこで役に立つのが、公式にも用意されているATF（Automated Test Framework）です。ATFは、変更後にテストを実行してインスタンスの整合性を確認する仕組みとして紹介されています。

ATFを導入する時の現実的な始め方

最初から全部を自動化しようとすると挫折します。おすすめは次の順番です。

• まずは“壊れたら困る業務”を1つ選ぶ
  例：インシデント起票、承認フロー、カタログ申請など
• その画面操作をATFでテスト化する
• Update Set適用後、またはアプリ更新後に毎回走らせる

公式ドキュメントでも、テストスイートを実行する手順（SuitesからRun Test Suite）が整理されています。
運用に落とすなら「テストスイート＝本番前の儀式」にしてしまうのがコツです。

---

本番反映の運用：チェックリスト化すると事故が減る

ここからは、手順というより“運用の型”です。どの方式（Update Set／App Repo）でも使えます。

反映前に揃えるもの

• 変更の目的が1文で言える（何を解決するか）
• 影響範囲が言語化できている（誰のどの操作が変わるか）
• 依存関係が洗い出せている（前提の設定・ロール・プラグインなど）
• テスト観点が決まっている（ATF＋手動確認の範囲）

反映直前にやること

• テスト環境で、同じ移送物が入っている状態を作る
• ATF（または同等の確認）を実行して結果を残す
• 反映手順を短くする（当日の操作を減らす）

---

切り戻しの考え方：Back outと“戻せる設計”は別物

公式ドキュメントには、Update SetをBack outする手順も用意されています。
ただし、ここで押さえたいのは「戻せる＝ボタン1つで完全に元通り」ではないことです。

• Back outは有効な武器だが、影響が広い変更ほど慎重に
• そもそも戻しやすい粒度で変更を分ける（Update Setを小さく、目的単位に）
• 依存関係が絡むと、戻す順序の設計が必要になる

“切り戻し”は最後の手段で、理想は「切り戻しが不要なくらい事前確認が強い」状態です。そのために、Update Setの粒度、App Repoのバージョン運用、ATFの実行が効いてきます。

---

よくある事故パターンと回避策（Zurichでも起きる）

テストで直したのに、開発に戻していない

症状：本番では再現しない／差分が合わない
回避策：修正は必ず開発へ戻してから、同じ流れで再移送する（“出どころ”を一本化）

Update Setが巨大化して、依存が追えない

症状：プレビューで大量の衝突、原因が不明
回避策：目的単位で小さく分け、必要ならまとめて適用（順序も管理）

本番だけでこっそり変更してしまう

症状：次の移送で上書き衝突、監査で説明できない
回避策：緊急時も「本番変更→必ず開発へ再現」をルール化

---

学習を最短にするコツ：手を動かすなら“教材で型”を先に入れる

ここまで読んで、「理解はできるけど、実際に触ると迷いそう…」となるのが普通です。
移送は画面操作も多いので、体系的に流れをまとめて学べる教材を1つ挟むと早いです。

たとえばUdemyには、CSA学習の延長で「Update Set」「スコープアプリ開発」「ATF」「変更管理」の考え方をハンズオンで整理してくれる講座がいくつかあります。
公式ドキュメントを軸にしつつ、実操作の“迷いどころ”を動画で潰していく、という使い方が相性いいです。

---

まとめ：Zurichの本番移送は「方式の使い分け」と「確認の固定化」で安定する

開発→本番移送は、手順を覚えるよりも、次の3点を軸にするとブレなくなります。

• 移送単位を決める：構成変更はUpdate Set、スコープアプリはApp Repo（必要に応じてソース管理）
• 反映前に確認を挟む：Preview、テスト環境での検証、ATFで確認ポイントを固定
• 戻せる前提で運用する：変更を小さく分け、依存を意識し、Back outやバージョン運用を“最後の保険”として準備

この整理ができると、CSA学習でも「用語を知っている」から一歩進んで、「なぜその選択が安全なのか」を説明できる状態になります。
次に公式ドキュメントを読むときも、単なる操作説明ではなく“意図”が見えてくるはずです。