アップグレードで設定が消えない運用レシピ：Upgrade Historyの読み方

ServiceNow のバージョンアップと聞くと、「せっかく作った設定が上書きで消えるのでは」と身構える方は多いはずです。ですが、その心配はかなりの部分が杞憂です。ServiceNow は、あなたが手を入れた設定を勝手には上書きしません。そして「何を適用し、何を守ったか」を1件ずつ記録に残しています。その記録が Upgrade History（アップグレード履歴） です。

この履歴を読めるようになると、アップグレードは「祈りながら実行するイベント」から「結果を数字で確認できる作業」に変わります。どのファイルが更新され、どれがあなたのカスタムを守るためにスキップされたか。それが全部テーブルに残っている。だから、消えたように見える設定も、たいていは「消えた」のではなく「守られてスキップされた」だけです。

この記事は、その履歴を実機で開き、読み方を具体的に示すものです。無料部では「なぜ消えないのか」という仕組みと全体像を、有料部では「アップグレード後に何を、どのクエリで確認するか」という実践レシピを扱います。

アップグレードは「上書き」ではなく「突合」

まず、いちばん大事な仕組みから。アップグレードとは、新バージョンのメタデータをあなたのインスタンスへ流し込む作業です。メタデータとは、UIアクションやスクリプト、ビジネスルールといった「設定の実体となるレコード」を指します。このとき ServiceNow は、全部を一律に上書きしたりしません。1ファイルずつ「あなたはこの設定を変更したか」を突き合わせます。

判断はシンプルです。あなたが触っていない設定なら、新バージョンをそのまま適用する。あなたが変更した設定なら、上書きせずに既存を残す。後者が、いわゆる「スキップ（Skipped）」です。スキップは失敗ではありません。あなたのカスタマイズを守るための、正常な動作です。この一点を押さえるだけで、アップグレードへの不安はだいぶ軽くなります。

図の流れがそのまま実体です。新バージョンが届く。設定ごとに「変更した？」を判定する。変更していなければ適用（Inserted / Updated）、変更していれば保護（Skipped）。その結果を、実行単位のテーブルと、ファイル単位のテーブルに書き残す。最後に、スキップされたものを人がレビューして、自社の版を残すか、新機能を取り込むかを決める。この一連が、ServiceNow の「設定が消えない」を支える骨組みです。

実機の全体像：67回の記録が残っていた

では、実機の履歴を開いてみます。この検証環境には、アップグレードやプラグイン導入の記録が 67 件 残っていました。テーブル名は sys_upgrade_history。画面では「System Upgrades」と表示されます。

一覧には From / To（どのバージョンからどこへ）や、Upgrade started / finished（開始と終了）が並びます。右側には Changes skipped / Changes applied / Changes processed という集計列があります。これが実行1件ごとの「適用した数・スキップした数」です。上から6行目の com.glide.ide の行を見てください。Changes skipped が 1、applied が 5、processed が 6 と記録されています。スキップが実際に発生し、履歴に残ることが読み取れます。

67件の内訳は、プラグインやアプリの導入が中心でした。実際のリリースアップグレード（Zurich 本体）も1件記録されていましたが、この環境は新規のため、既存カスタムと衝突するものが無く、リリース時のファイル変更集計はゼロでした。ここが大事な前提です。カスタムが少ない環境ほどスキップは少なく、作り込んだ本番ほどスキップは増えます。つまりスキップの数は、あなたがどれだけ設定を育ててきたかの裏返しでもあります。

ここまでが「なぜ消えないのか」の全体像です。ここから先は、アップグレード後に実務で何を確認すればよいか、具体的な手順とクエリに踏み込みます。disposition（処理区分）の読み分け、Skipped だけを絞り込むフィルタ、そして1件ずつの判断（Retain / Merge / Revert）まで、実測値とともにまとめました。