[Brazil調査] アップグレード後に確認するスキップされた変更：Upgrade History の見方と実機の記録
検証環境：Brazil PDI（Australia からメジャーアップグレード）/ OOTB / 2026-10-09 確認
メジャーアップグレードが終わったあと、カスタマイズした設定が新しい標準に置き換わっていないか、どこで確認すればよいのでしょうか。ServiceNow はカスタマイズ済みの記録を上書きせず、スキップした記録を履歴に残します。この PDI は Australia から Brazil へ上がったばかりなので、その履歴をそのまま見ました。スキップは1,219件ありましたが、見直しの対象として表示されたのは66件でした。
押さえておくこと
確認する場所は Upgrade History の1件の記録。開始・終了時刻、件数、スキップ一覧が1画面にまとまる
スキップは、カスタマイズを守るための「見送り」。上書きされた件数ではない
件数が大きく見えても、見直し対象は絞られる。66件・12件・3件のどれを見るかを先に決める
見る場所
アップグレードの記録は sys_upgrade_history に1件ずつ残り、スキップ一覧は sys_upgrade_history_log に入ります。画面は Upgrade Monitor（Admin Center の Upgrade Management）か、Upgrade History の一覧から開きます。公式の手順は次のとおりです。
Upgrade Monitor を開き、Upgrade Summary Report の Skipped 欄にある Review changes を選ぶ
System Upgrades フォームの Skipped Changes to Review 関連リストで、1件ずつ開いて判断する
主な判断は3通り（ほかに保留・レビュー済みのみの区分）。Reviewed and Retained（カスタマイズを残す）、Resolve Conflicts で統合（Merged）、Revert to Base System（標準へ戻す）
公式の説明では、スキップされた記録を見直したあと、変更した内容を十分にテストするよう求めています。
引用元：Process the skipped records list
この記事では、操作の画面を触らず、記録を読むだけにしています。スキップ記録の解決や標準への戻しは実行していません。
今回のアップグレード記録
Upgrade History を開くと、アップグレードの記録は2件ありました。
①の記録が今回の Australia から Brazil への移行です。その前に Yokohama から Australia へ上げた記録があります。以下は PDI の画面に表示された値です。
今回：Australia（patch3）から Brazil（patch0）へ。2026-10-08 06:33:08〜07:17:08（44分）
処理した変更：44,209件。適用43,460件、スキップ749件
前回：Yokohama から Australia へ。スキップ104件、処理102,297件
件数は Brazil の方が少なく、スキップは増えています。原因は確かめていない。
1件の記録で見る項目
①の記録を開いたフォームが、確認の中心になります。
画面の読み方は次のとおりです。
①の Upgrade started / finished で所要時間が分かる。今回は44分
②の Changes skipped（749）、Changes applied（43,460）、Changes processed（44,209）、Copies to review（3）、Auto resolved（18）が全体像
③のタブに Skipped Changes to Review（66）、Skipped Changes Reviewed（18）、Copies to Review（3）、Customizations Unchanged（1,207）が並ぶ
見直しの優先は、③の先頭にある Skipped Changes to Review（66）です。公式では、このリストがスキップ後に判断が必要な記録を集めた場所に当たります。Skipped Changes Reviewed（18）は、すでにレビュー済みとして移った記録です。
スキップの見直し手順
実際の環境では、次の順で絞ります。
Upgrade History の対象の記録を開き、Changes skipped と、Skipped Changes to Review の件数を見る
Skipped Changes to Review を、Priority の小さい順に開く（公式の区分は下記）
各記録で Resolve Conflicts を開き、標準側との差分を確認して Retained、Merged、Reverted のどれかを決める
Copies to Review がある場合は、元の記録が標準側で更新されているため、コピーの内容を確認する
解決後、変更した機能をテストする。公式でもテストを求めている
Priority の公式の区分は次のとおりです。
Priority 1（最優先）：UI ページ、UI マクロなど
Priority 2：ビジネスルール、セキュリティ ACL など
Priority 3：レポートなど
Priority 4：フォームセクション、選択肢セットなど
Priority 5（最低）：その他
Priority 2 が1,098件を占めるが、実際に開くのは Skipped Changes to Review の66件です。
自動で片づけたい繰り返しの種類があれば、Skipped Record Rules を作れます。公式では、アップグレード中の自動解決か、アップグレード後の手動実行に使うと説明しています。ただし今回は、ルールの作成も実行も行っていません。
関連：Explore Upgrade Skipped Record Rules Editor in Upgrade Console
公式の画面と状態
Upgrade Console は、アップグレードに関する情報とツールをまとめた画面です。公式の説明では、Upgrade History と Upgrade Monitor、Skipped Record Rules Editor、Upgrade Preview などがツールとして並びます。
Upgrade Monitor の状態
Upgrade Monitor は、次のアップグレードの予定を表示する画面です。公式の説明では、状態は3つあります。
No upgrade scheduled：予定なし。Schedule upgrade と Check for upgrade を選べる
Upgrade scheduled：開始日時が表示される。Reschedule upgrade で変更できる
Issue detected：アップグレードのトリガーが改変されているか、欠けている場合の警告
3つ目の警告は、Check distribution for possible upgrade と Check database for possible upgrade の2つのジョブが対象です。公式では、ServiceNow が運用していないインスタンスでは、この警告が問題を示すとは限らないと注記しています。
引用元：Upgrade Monitor schedule states
進行中に見える4段階
アップグレードの進行中は、Upgrade Progress の画面に4つの段階が出ます。
Upgrading Platform：プラットフォームの基盤になる要素を更新する
Updating Schema：プラグインを走査し、更新が必要なテーブルの一覧を作る
Loading Plugins：コアとオプションのプラグインを読み込む
Completing：前の3段階のあとに完了させる要素を更新する
公式では、進行バーの各区間の長さは、所要時間の比率を示さないと説明しています。
引用元：Upgrade Progress
完了後の Summary Report
アップグレードが終わると、Upgrade Monitor は Upgrade Summary Report を表示します。主な項目は Upgraded version、Upgrade duration、Skipped Records です。公式は、所要時間をほかのインスタンスのアップグレード時間の見積もりに使えると説明しています。本番と同じ時間になるかどうかは、この PDI では確かめられません。
アプリ更新側のスキップ
アップグレード本体のあとに、ストアアプリやプラグインの更新が続きます。sys_upgrade_history には、本体の2件のほかに次の記録がありました。
application：64件
plugin：5件
batch_install：3件
zboot：1件
Brazil のアップグレード後にあたる application の記録では、スキップが残っているものがありました。主なものは次のとおりです。
sn_build_agent：スキップ645件、適用577件
sn_glider：スキップ459件、適用757件
sn_aixf：スキップ137件、適用2件
sn_aiux_builder：スキップ67件、適用75件
本体の記録だけを見ると、これらのスキップは見えません。アップグレード後の確認では、本体の1件に加えて、直後に作られた application 記録の Changes skipped も並べます。件数が多いアプリは、Skipped Manual Merge の割合も確認対象です。たとえば sn_build_agent は645件のうち59件が Manual Merge でした。
この記事では、アプリ側のスキップの中身までは開いていません。
アップグレード後の確認項目
ここまでの内容を、確認の順に並べ直します。
所要時間：Upgrade started / finished の差。今回は44分
全体の件数：Changes processed、applied、skipped
見直し対象：Skipped Changes to Review の件数。今回は66件
要判断の種類：Skipped Manual Merge と Skipped Error。今回は57件と15件
変更不要に近い記録：Customizations Unchanged。今回は1,207件
種別の偏り：Type のグループ化。今回は ACL が約88％
後続のアプリ更新：application 履歴の Changes skipped
見直し後：変更した機能のテスト
最初の2つは数分で済みます。残りは、Skipped Changes to Review を先頭から開く作業が中心になります。
処分の内訳
フォームの件数だけでは、何が起きたかの全体が見えません。Upgrade Details（sys_upgrade_history_log）を処分（Disposition）でグループ化すると、1回のアップグレードで379,461件が記録されていました。
表の内容を文字でも書き出します。
Unchanged（314,374件）：ベースラインが変わらず、何もしなかった
Inserted / Updated / Deleted（22,738 / 20,443 / 386件）：新規追加・更新・削除した
Not Latest（11,713件）：適用後、同じアップグレード内で上書きされた
Skipped Apply Once（7,828件）：適用済みの一度きり変更のため見送った
Skipped（1,219件）：カスタマイズを守るため変更しなかった
Skipped Manual Merge（57件）：手作業の統合が必要で変更しなかった
Skipped Error（15件）：別スコープに同じ記録があるなどの理由で見送った
このほか Table Not Found が685件、Base Deleted が3件
①の Skipped は379,461件のうち約0.3％です。②の Skipped Manual Merge と Skipped Error は、人が判断しないと解消しない種類で、合わせて72件でした。
Disposition の定義
公式は処分の値を次のように定義しています。表の「意味」欄は、これを要約したものです。
Skipped：カスタマイズを守るため、システムがその記録を変更しなかった
Skipped Manual Merge：更新に手作業の介入が必要なため、変更しなかった
Skipped Error：別スコープに同じ記録があるなどの理由で、アップグレードを見送った
Skipped Apply Once：apply once フォルダの XML から更新済みのため、見送った
Unchanged：前のリリースからベースラインが変わっていないため、変更しなかった
Not Latest：変更を適用したが、同じアップグレード内で後から上書きされた
引用元：Review skipped records using related lists
スキップの種別
Skipped の1,219件を種別（Type）でグループ化すると、29種に分かれました。
①の Access Control（ACL）が1,072件で、全体の約88％を占めます。そのほかの主な種別は次のとおりです。
System Property：27件
View Template：27件
Business Rule：14件
Script Action：12件
AI Search Search Profile：11件
優先度（Priority）では、Priority 2 が1,098件、Priority 5 が117件、Priority 3 が2件でした。公式の分類では Priority 2 に Business Rules と Security ACLs が含まれます。ACL が大半を占めるため、Priority 2 が多くなっています。
カスタマイズ側の作成者
スキップされた1,219件について、カスタマイズ側の記録（sys_update_xml）の作成者を数えました。system が1,188件、admin が22件、ServiceNow 系のアカウントが9件です。個人ユーザーが作成した記録はありませんでした。admin 作成が22件です。記事では個別のレコード名を載せず、件数と種別だけにしています。
実機で気づいたこと
749と1,219は同じ数字ではない
フォームの Changes skipped は749でしたが、Upgrade Details で処分が Skipped の記録は1,219件でした。フォームの Changes skipped の定義（ヘルプ）は次のとおりです。
Changes skipped - The total number of records that were different from the previous upgrade and the upgrade component was not applied.
（訳：前回のアップグレードから変わっており、アップグレードの構成要素が適用されなかった記録の総数）
この定義から、749は前回から変更された記録だけを数えた値と読めます。フォームの内訳は skipped_and_different が677、Manual Merge が57、Error が15で、合計は749です。ログの Skipped 1,219件のうち1,207件は次の節のとおり前回から変わっていない記録で、749には含まれません。
実務では、どちらの数字を報告するかを決めておく必要があります。見直しの作業量はフォームのタブにある66件で見ると、実態に近くなります。
1,207件は変更不要の可能性が高い
Skipped の1,219件のうち、Changed by vendor が false の記録が1,207件、true が12件でした。フォームの Customizations Unchanged（1,207）と同じ数字です。Resolution が Not Reviewed になっているのも12件でした。
公式の定義では、Customization Unchanged は標準側が変わっていない記録を指します。標準が変わっていないなら、取り込むものがないため、確認の優先度を下げられると考えられます。確認が必要なのは、Changed by vendor が true の12件と、手作業の統合が必要な57件、Error の15件です。
公式にある段階は3区分と4段階
『7フェーズ』という言い方を見かけますが、公式 Docs で確認できたのは別の数え方でした。Guided upgrade は Pre-upgrade、Instance upgrade、Post-upgrade の3区分です。進行中の画面は Upgrading Platform、Updating Schema、Loading Plugins、Completing の4段階です。7段階の記載は見つかっていません。
進行中の4段階は、完了後には見えません。完了後に見るのは、履歴の件数とスキップの一覧です。
検証範囲とおことわり
検証は Australia から Brazil（Patch 0）へアップグレードした PDI 1台で、読み取りだけで行った。設定変更は行っていない
スキップ記録の解決、標準への戻し、Run Skipped Record Rules の実行はしていない
Upgrade Monitor の画面（$upgrade_monitor.do）は読み込みがタイムアウトし、撮影できなかった。公式の説明と、Upgrade History のフォームで代えている
749件と1,219件の差、66件の内訳は確かめていない
749件と1,219件の差は、ヘルプの定義から説明しているだけで、全件の突き合わせは行っていない。1,219件に重複して数えられた記録があるかは確かめていない
公式 release-notes の upgrades-overview は取得できていない
PDI のスキップは大半が ACL で、個人ユーザーが作成した記録はない。実際の環境ではスキップの中身が異なる
前回との件数比較は、環境の違いを考慮していない参考値
付録：調査で使った URL
次の URL はインスタンスの URL の後ろに付けます。
アップグレード履歴（本体だけ）：/sys_upgrade_history_list.do?sysparm_query=history_type=upgrade^ORDERBYDESCupgrade_started
履歴の1件のフォーム：/sys_upgrade_history.do?sys_id=<履歴の sys_id>
処分別の件数：/sys_upgrade_history_log_list.do?sysparm_query=upgrade_history=<履歴の sys_id>^GROUPBYdisposition
スキップの種別：/sys_upgrade_history_log_list.do?sysparm_query=upgrade_history=<履歴の sys_id>^disposition=4^GROUPBYtype
公式の関連ページは、Reviewing upgrade history です。
付録：用語
Upgrade History：アップグレードごとの記録。sys_upgrade_history
Upgrade Details：記録ごとの処理結果。sys_upgrade_history_log
Disposition：1件の記録に対して、アップグレードが何をしたかを示す値
Skipped：カスタマイズ済みの記録を守るため、変更しなかったこと
Skipped Record Rules：スキップ記録の解決を自動化するルール
