概要 

ServiceNow University でデルタ試験を完了する際には、この学習ガイドを使用してください。このナレッジ記事に記載されている内容は、認定資格を維持するために合格する必要がある試験の内容です。さらに、ServiceNow の製品ドキュメントを参照することも常にお勧めしています。 

デルタ試験学習ガイドの内容 

ServiceNow の System Update Sets (システムアップデートセット) を習得する方法：アドミン向けの楽しさと実用性を兼ね備えたガイド 

ServiceNow インスタンス間での構成変更を管理したことがあるなら、System Update Sets を操作したことがあるでしょう。System Update Sets は単なるツールではなく、あらゆる経験豊富なアドミンにとっての通過儀礼となっています。拡張機能を展開する場合でも、アプリにパッチを適用する場合でも、単に本番環境を壊さないようにする場合でも、更新セットは信頼できる相棒です。ちょっとした遊び心とたくさんの実践的な知恵を見ていきましょう。  

更新セット 101：更新セットの概要と重要な理由 

更新セットの中心は構成変更のコンテナであり、開発からテスト、本番に移行する前に荷造りするスーツケースのようなものと考えてください。更新セットにより、sys_metadata を拡張するテーブルへの変更を追跡し、ビジネスルール、クライアントスクリプト、UI ポリシー、UI アクション、ACL、スクリプトインクルード、フローまたはワークフローなどのカスタマイズをバンドルして移行できます。更新セットは、ServiceNow 構成のソースコントロールアーティファクトのように扱ってください。編成されたセットは、予測可能な展開と同等です。  

内部的には、更新セットは XML として表され、以下が含まれます。 

• 変更したレコード (更新レコードとして) 

• 構成デルタ 

• 取得/プレビュー/コミットに関するステータスおよびメタデータ 

更新セットは、以下の場合に最適です。 

• 特定のバージョンのアプリケーションを保存して適用する 

• パッチとホットフィックスを展開する 

• バックアップ、監査、またはロールバック計画のための構成をエクスポートする 

取り込むものと取り込まないもの 

更新セットに取り込むものと取り込まないものを覚えておくと役に立ちます。不明な場合は、テーブルで sys_metadata が拡張されているかどうかを確認するか、テスト変更とプレビューを通じて取り込みを検証します。取り込むものの例には、以下が含まれます。 

• ビジネスルール、クライアントスクリプト、UI ポリシー、UI アクション 

• スクリプトインクルード、ACL、データポリシー 

• 辞書エントリ、フォームまたはレイアウトの変更 

• sys_properties およびアプリモジュールのメニュー構成 

• アプリ内でスコープ対象となる Workflow Studio (ワークフロースタジオ) のコンテンツ 

取り込まないものの例： 

• データ (インシデント、CMDB レコード、タスクなど) 

• ユーザー、グループ、またはロール (通常、メタデータではない) 

• 添付ファイル、イメージ、および一部のバイナリ資産 

• MID Server (MID サーバー) 構成、外部統合のランタイムステータス 

• アプリリポジトリまたはプラグインによって管理される一部のインストール済みストアアプリのコンテンツ 

はじめに：構成ハイジーン 

優れたアドミニストレーターは、単に「機能させる」だけでなく、反復可能かつ監査可能で安全なものにします。成功に向けて準備を整えるためのヒントをいくつか紹介します。 

• 命名規則が重要： 要件やチケットに関連付けられた短く意味のある名前を使用します (STRY1001-IncidentFix など)。日付やイニシャルなどの冗長な情報は既に追跡されている可能性があるため、避けてください。 

• バッチ処理とスコープ：単一のアップデートセットは1つのアプリケーションスコープに限定されます。ただし、アップデートセットのバッチ処理(親/子階層)を使用すると、異なるスコープのアップデートセットを1つの親の下にグループ化でき、技術的および運用上の負債を回避するのに役立ちます。例: 親アップデートセット(グローバルスコープ)↳ 子アップデートセット1(ITSMスコープ)↳ 子アップデートセット2(CSMスコープ)。

• より小さい論理ユニット：大型の「いろいろ取り揃えた」セットよりも、より小さい専用の更新セットが好ましいでしょう。テスト、レビュー、デバッグが簡単になります。 

• バックアウトに関するプロパティ：システムプロパティまたは機能の切り替えを利用し、必要に応じて変更をすばやく無効にします。この方法は、バックアウトに頼るよりもはるかに安全です。 

• 更新を手動で再ターゲットしない： レコードの update_set フィールドを変更して変更内容を「移動する」ことはしないでください。プラットフォームメカニズム (取得、プレビュー、コミット、[Merge Update Sets (更新セットを結合)] モジュールなど) を使用して、整合性を維持します。 

更新セットの作成と選択 

1. 要件または機能ごとに新しい更新セットを作成します。  

2. 作成したセットを現在のセットとして選択してから変更を加えます。Update Set Picker (更新セットピッカー) (統一ナビゲーション) を使用して切り替えます。   

3. ServiceNow Studio (ServiceNow スタジオ) では、[Deployment (展開)] タブまたはアプリコンテキスト内で更新セットを管理できます。   

4. 委任開発者は、許可されていればセットを作成/切り替えできるため、チームのコラボレーションに役立ちます。  

 プロのヒント：承認者が着目している内容がわかるように、更新セットレコード内の要件に簡単な説明またはリンクを追加します。 

検査とレポート：内容を把握する 

更新セットは単なるコンテナではなく、完全にナビゲート可能なレコードとして機能するため、更新セットの内容を把握することが重要です。更新セットを開くと、それに含まれるすべての更新を簡単に参照したり、個々のレコードにドリルダウンしたり、そうした更新セットと現在のバージョンの違いを確認したりすることもできます。   

概要をより明確に把握するために、変更されたすべてのビジネスルールなど、更新タイプ別に内容を確認するレポートを迅速に生成できます。さらに、更新セットとターゲットインスタンスを比較すると、展開前に潜在的な競合を特定できるようになります。リスクパターン、ベストプラクティスの違反、スコープの不一致、および一般的なアンチパターンをチェックするインスタンススキャンを実行することをお勧めします。重要な分岐の場合、または更新セットが [Complete (完了)] ステータスになった場合は、こうしたスキャンを自動化すると、展開プロセスをさらに強化できます。  

パッケージング：結合とバッチ 

作業をグループ化するには、次の 2 つの方法があります。 

結合：[Merge Update Sets (更新セットを結合)] を使用して、レコードを 1 つのセットに結合します。複数の小さいセットを 1 つの成果物にまとめるのに便利ですが、使いすぎたり遅すぎたりするとリスクが発生します。 

バッチ処理 (推奨)：親更新セットを作成し、その下にスコープ対象の子更新セットを挿入します。バッチでは、それぞれの子を論理的に独立させながら、一貫したリリースとして展開します。スコープ別や機能別のバッチ処理により、展開がより明確になり、ロールバック/先を見越した修正の決定がはるかに簡単になります。 

インスタンス間の移動：取得、プレビュー、コミット 

バッチ化された更新セットをリモートインスタンスから取得するのは簡単です。 

1. ソースから更新セット (XML) をエクスポートします。 

2. ターゲットインスタンスにインポートします ([Retrieve (取得)] を使用)。  

3. ターゲットインスタンスのエラー、欠落している依存関係、および競合を明らかにするためにプレビューします。 

4. ターゲットインスタンスで、クリーンな状態のときに (または競合を解決した後に) コミットします。 

本番環境でコミットした後、更新セットを [Ignore (無視)] としてマークします。これにより、今後の取得中 (クローン作成後など) に同じセットが再適用されなくなります。   

プロのヒント：コミットする前に必ずプレビューしてください。決してスキップしないでください。プレビューは早期警告システムです。 

アドミンガードレール：権限と責任 

更新セットは削除すべきではありません。削除すると履歴レコードが孤立し、将来の比較や監査が複雑になる場合があります。デフォルトの更新セットはシステムに固有であり、変更すると重大な問題を引き起こすおそれがあるため、バックアウトは避けてください。更新セットの参照を手動で編集するのではなく、必ずプラットフォームの組み込みの結合、バッチ、取得の各機能を使用して、整合性を維持します。   

意図せずにスコープを混在させないように注意してください。正確性を保つために、変更を行う前に現在のアプリケーションスコープとアクティブな更新セットの両方を確認します。最後に、本番環境で更新セットをコミットした後、[Ignore (無視)] に設定して、今後のクローン作成中や取得サイクル中に誤って再適用されないようにします。  

競合解決：ローカルとリモートの比較 

競合は、特に多忙な組織で発生します。この比較は、完了前のチェックリストに含めてください。比較ツールを使用して、以下を行います。 

• ローカルセットとリモートセットをプレビューし、重複レコードや競合レコードを特定する。 

• 適切なバージョンを選択して先に進む (通常は、最新バージョンまたはターゲット設計に沿ったバージョン)。 

• 必要に応じて、特に複数のチームが触れる可能性のあるスクリプト、UI ポリシー、ACL、辞書エントリで、レコードごとに解決する。  

ベストプラクティス 

• 効率的なバッチ処理：親/子セットを使用して、スコープ、機能、およびリリース別に編成します。後期段階の結合よりもバッチ処理を優先します。 

• 慎重な命名： チケットや機能に関連付けられる短く意味のある名前 (STRY1001-IncidentFix など)。日付やイニシャルは、ServiceNow ラボ環境以外ではお勧めしません。 

• 頻繁なスキャン：[Complete (完了)] になる前、インポート後、コミット前にインスタンススキャンを実行します。可能な場合は自動化します。 

• 先を見越した修正：変更をバックアウトするのではなく、機能の切り替えまたはシステムプロパティを優先して、問題のある動作を無効にします。 

• 一貫した小さいセットを保持：セットごとに 1 つの論理的な変更 (または少数の関連する変更) レビュー、テスト、および昇格が容易になります。 

• 実際の作業に「デフォルト」を使用しない： デフォルトの更新セットは、意図しないドリフトをキャプチャするためだけのものであり、そのセットでプロジェクトを実行することはありません。 

• スコープに留意：何らかの操作を行う前に、アプリケーションスコープと現在の更新セットを確認してください。これにより、偶発的なスコープ漏れが回避されます。 

• 毎回プレビュー：プレビューで競合や欠落している依存関係を解決します。これを行わずにコミットしないでください。 

• 理由を文書化：説明の 1 行に要件へのリンクを含めると、コードのレビューや監査がスピードアップします。 

• 環境パリティ：開発、テスト、本番全体にわたってプラグイン、アプリのバージョン、プロパティを一致させて、プレビューのノイズを減らします。 

• セキュリティレビュー：ACL、スクリプトインクルード、または統合を変更する場合は、さらにピアレビューが必要です。 

• 手動フィールドハックなし：update_set フィールドを手動で変更したり、セットを削除したり、デフォルトをバックアウトしたりしないでください。 

最後に：洗練された更新セット 

System Update Sets は、ServiceNow において最も目立つツールではないかもしれませんが、不可欠です。このアプリを尊重すれば、スムーズな展開と深夜のロールバックの削減というメリットが得られます。  

次回リリースを準備するときは、「効率的なバッチ処理」、「慎重な命名」、「頻繁なスキャン」、「先を見越した修正」を覚えておいてください。 

更新セットおよびその他の関連するプラットフォーム機能の詳細については、ServiceNow 製品ドキュメントを参照するか、ServiceNow コミュニティにアクセスしてください。