ServiceNow Brazilへのアップグレードは、公式の7段階で進める

Brazilリリースまとめは、Brazilで何が変わるかを扱いました。この記事は自社のインスタンスをいつ、どの順で上げるかを決めるための整理です。

先に結論を書くと、BrazilはアーリーアベイラビリティでEAのお客様に公開されていますが、パッチングプログラムの対象ではなく、一般提供（GA）は11月の予定です。年末の作業とぶつかりやすい日程のため、検証を先に進めておくかどうかが、計画の分かれ目になります。以下はServiceNow Docsのリリースノートを原文で読んで確認した内容です。

日程の見方#

項目	内容
EA（アーリーアベイラビリティ）	2026年9月24日から。EAのお客様が対象
GA（一般提供）	2026年11月の予定
Q3 2026のパッチングプログラムの対象	Australia Patch 5a、Zurich Patch 12、Yokohama Patch 13 Hotfix 5a W39。Brazilは含まれない

ServiceNowの公式ドキュメントでは、Brazilは9月24日に機能リリースとして公開され、「EAのお客様が利用できる」とされています。バージョンの提供状況は3つに分かれます。

• Available: どのユーザーもアップグレードできる。インスタンスのアップグレード管理ダッシュボードに表示される
• Available by request: Customer Service and Supportに連絡して承認を得る必要がある
• Unavailable: 利用できない

パッチングプログラムの対象は、すぐに利用でき、バージョンの権利を申請する必要もありません。Brazilは対象に入っていないため、いまBrazilに上げられるのは、EAのお客様です。

GAの日付は読んだ公式ドキュメントに書かれていません。情報サイトのNowBenは、EAを9月の中旬、GAを11月と案内しています。NowBenの解説では、Early Release ProgramのEAは、GAの少なくとも45日前に始まるとされています。BrazilのEAは9月24日なので、計算上、GAは11月8日以降です。

年末にぶつかる日程#

2026年1月、ServiceNow Communityのスレッドで、利用者がBrazilのGAが11月になると、アップグレードが12月に重なると指摘しました。年末は休暇と決算の作業で時間を取りにくいためです。ServiceNowの社員は、メジャーリリースが年2回である点は変わらないと答えた上で、今回の日程が例年より遅い点を十分に伝えていなかったと認めました。

公式のチェックリストにも、クローンやアップグレードの時期に影響する変更凍結期間（四半期末など）を、アップグレードの前に確認する項目があります。年末年始の凍結期間を先に確かめ、本番のアップグレードを12月に置けるか、年明けにするかを決めておくと、検証の日程が逆算できます。

アップグレード元#

Brazilのリリースノートは、アップグレード元として、Australia、Zurich、Yokohamaからのリリースノートを案内しています。公式ドキュメントは最新のファミリーに直接アップグレードできると説明しています。複数のバージョンをまたぐときは、現在のバージョンと目標のバージョンのあいだにある、各バージョンのリリースノートを確認するよう求めています。

リリースノートには、次のツールがあります。

• Personalized PRB release notes: 現在のバージョンから目標のバージョンまでに修正される問題を、一覧にして生成する
• Combined product release notes for cross-family upgrades: 製品ごとに、あるファミリーから別のファミリーまでの変更を、1ページにまとめて表示する

サポートの期限はNow SupportのKnowledge Baseで確認してください。End-of-Lifeのアップグレードプログラムの案内（KB2177115）と、自社のインスタンスのステータスが手がかりになります。

公式の7段階#

公式の進め方は次の7段階です。順番どおりに進めることが推奨されています。

段階	やること
1	リリースノートを読み、計画を立てる
2	開発インスタンスのアップグレードの準備をする。本番から開発へクローンを取る
3	アップグレードの設定を確認し、Now Supportで開発インスタンスの日程を登録する
4	開発インスタンスをアップグレードして検証する
5	テストなど、ほかの本番以外のインスタンスをアップグレードして検証する
6	本番のアップグレードを準備する
7	本番をアップグレードする

チェックリストで、具体的な項目を確認します。

• 段階2: 本番から開発へのクローンで、本番と同じ規模なら、本番の監査ログと添付ファイルを含め、除外のオプションを外す。本番に近い環境で試すためです
• 段階3: 「Check distribution for possible upgrade」のスケジュールジョブの実行頻度を確認し、Now Supportで日程を登録する。必要なら、バージョンの権利を申請する
• 段階4: Upgrade Monitorで進捗を見て、完了後にスキップされたレコードを処理する。アップグレードの前と後に、開発インスタンスでスモークテストを行う
• 段階5: 開発インスタンスで入れたプラグイン、カスタムアプリケーション、アップグレード後の修正スクリプト、アップデートセットを入れ直す
• 段階6: IT部門と業務部門の承認、アップグレード当日の支援体制、実施計画の作成、変更記録の承認、利用者への連絡、アップグレード前の性能の記録を行う
• 段階7: 日程を登録し、アップグレードを監視して、アップデートセットと修正スクリプトを適用し、ユーザー受け入れテスト（UAT）で確かめる

Brazilのアップグレードと更新は、前のリリースよりかなり短時間で終わるとされています。公式ドキュメントは短く終わったことだけで失敗したとは考えず、テストで確かめるよう注意しています。

テストの進め方#

ServiceNowは、開発、テスト、本番の順に上げることを求めています。インスタンスが3つでない場合も、本番から最も遠いインスタンスから上げます。

インスタンス	必要なテスト
開発	スモークテスト
テスト	Automated Test Framework（ATF）のクイックスタートテストと製品別のテストスイート。余裕があればUATも
本番	UATのみ。ATFは本番以外のインスタンスで使う

ロールバック#

ServiceNowには、全てのアップグレードに使えるロールバックはありません。ロールバックできるのは、同じファミリーの中での更新（パッチからパッチ、パッチからホットフィックスなど）です。期間は既定で10日で、glide.rollback.expiration_daysで変えられます。依頼はCustomer Service and Supportに連絡して行います。

本番をバックアップから戻すことは、ほかに方法がないときの最後の手段です。停止時間とデータの損失が出るためです。ServiceNowはオンデマンドのバックアップを取らず、インスタンスは、ServiceNowが決めた非ピークの時間帯に、毎日自動でバックアップされます。ファミリーをまたぐアップグレードには、戻す手段がありません。事前のテストで、問題を見つけておく必要があります。

リリースノートで先に拾っておく変更#

「Changes to Brazil features and products」には、アップグレードで動作が変わりうる項目があります。新しく作ったインスタンスでは新しい既定値になり、アップグレードしたインスタンスでは古い動作が残るものがあります。

• ACLの厳格な拒否: ACLが参照するロールがインスタンスに全く存在しないとき、アクセスを拒否する。新しいインスタンスでは既定で有効。アップグレードしたインスタンスは、glide.security.acl_with_invalid_roles_strict_denyで有効にする
• 解決済みのインシデントの自動クローズ: カレンダー上の日数ではなく、営業日数で閉じる。日数はglide.ui.autoclose.timeで設定し、0にすると無効になる
• Incident Managementのロール: 継承していたitilロールを外す変更は、新しく作ったインスタンス（zBootのインスタンス）だけが対象。アップグレードしたインスタンスでは、itilロールの継承が残る
• Service Graph Workspace: このリリースから非推奨で、機能はCMDB Workspaceに統合される
• AWSのDiscovery: データセンターのリージョンが有効かどうかの判定が、Config APIからResource Explorer APIに変わる

ここに挙げたのは一覧の一部です。製品ごとのアップグレードの作業は、「Pre- and post-upgrade tasks for various products」に、製品とファミリー別にまとまっています。自社で使う製品のところだけを読み、アップグレード元のファミリーを確認します。

今日から始める準備#

1. 自社のインスタンスのファミリーと、パッチの状況を確認する。サポートの期限はNow Supportで確認する
2. 変更凍結の期間を洗い出し、本番のアップグレードを置ける時期を決める
3. Brazil版のPDIで、新機能と既存のカスタマイズへの影響を確かめる
4. Personalized PRB release notesを生成し、自社に関係する修正を確認する
5. 本番のクローンを開発インスタンスに取り、実際のデータでアップグレードにかかる時間を測る
6. ATFのテストの範囲を確認し、足りない部分は、UATの手順に入れる
7. バージョンの権利の申請が必要かどうかを、Now Supportで確認する

GAを待つか、EAで先に上げるかは、自社の変更凍結の期間と、検証にかけられる時間で決まります。EAで上げる場合も、段階の順番は変わらず、まず開発インスタンスで確かめます。