update-set-management

更新セット管理

概要

更新セットは、ServiceNow の構成管理の基盤です。このスキルでは、次の内容を説明します。

• 適切な名前の更新セットを作成する
• 開発用の現在の更新セットを設定する
• 更新セットに取り込まれた内容を追跡する
• レコードを更新セット間で移動する
• デプロイに向けて更新セットを準備する
• 移行前に更新セットを検証する

使用するタイミング： ServiceNow の開発環境またはテスト環境で構成変更を行うときは、いつでも使用します。

前提条件

• ロール： admin または update_set_admin
• アクセス権： sys_update_set テーブルおよび sys_update_xml テーブル
• 環境： 開発インスタンスまたはテストインスタンス（本番環境では更新セットを作成しないでください）

手順

ステップ 1：新しい更新セットを作成する

命名規則に従って、内容がわかる更新セットを作成します。

命名規則：

[PROJECT]-[TYPE]-[DESCRIPTION]-[VERSION]

Examples:
- PROJ123-FEAT-NewTicketForm-v1
- HR-FIX-OnboardingWorkflow-v2
- ITSM-ENH-IncidentAutoAssign-v1

MCP を使用する場合：

Tool: SN-Create-Record
Parameters:
  table_name: sys_update_set
  data:
    name: "PROJ123-FEAT-CustomerPortal-v1"
    description: "New customer portal feature including:
      - Custom catalog items
      - Portal widgets
      - Service catalog categories"
    application: [app_sys_id]  # For scoped apps
    state: in progress

REST API を使用する場合：

POST /api/now/table/sys_update_set
Content-Type: application/json

{
  "name": "PROJ123-FEAT-CustomerPortal-v1",
  "description": "New customer portal feature...",
  "state": "in progress"
}

ステップ 2：現在の更新セットとして設定する

変更が取り込まれるように、新しい更新セットを有効にします。

MCP を使用する場合（自動！）：

Tool: SN-Set-Update-Set
Parameters:
  update_set_sys_id: [sys_id from step 1]

確認：

Tool: SN-Get-Current-Update-Set

期待される応答：

{
  "name": "PROJ123-FEAT-CustomerPortal-v1",
  "sys_id": "abc123...",
  "state": "in progress"
}

ステップ 3：構成変更を行う

構成変更を行います。すべてのカスタマイズが取り込まれます。

自動的に取り込まれるもの：

• UI ポリシー
• ビジネスルール
• クライアントスクリプト
• スクリプトインクルード
• フォームとリスト
• ACL
• プロパティ
• スケジュール済みジョブ

自動的には取り込まれないもの：

• データレコード（データ保護機能を使用してください）
• ユーザーレコード
• グループメンバーシップ
• 一部のシステムプロパティ

ステップ 4：更新セットの内容を確認する

定期的に、取り込まれている内容を確認します。

MCP を使用する場合：

Tool: SN-Inspect-Update-Set
Parameters:
  update_set_sys_id: [your_update_set_sys_id]

または、直接クエリする場合：

Tool: SN-Query-Table
Parameters:
  table_name: sys_update_xml
  query: update_set=[your_update_set_sys_id]
  fields: name,type,action,sys_created_on
  limit: 100

期待される出力：

名前	種類	アクション	作成日
My Business Rule	sys_script	INSERT	2026-02-06
Incident Form	sys_ui_policy	INSERT	2026-02-06

ステップ 5：誤った更新セットに入ったレコードを処理する

レコードが誤って Default または別の更新セットに入った場合：

MCP を使用する場合：

Tool: SN-Move-Records-To-Update-Set
Parameters:
  source_update_set: Default  # or sys_id
  target_update_set: [your_update_set_sys_id]
  query: sys_created_onONToday@javascript:gs.beginningOfToday()@javascript:gs.endOfToday()

手動で行う場合：

Tool: SN-Query-Table
Parameters:
  table_name: sys_update_xml
  query: update_set=[wrong_set_sys_id]^sys_created_onONToday
  fields: sys_id,name,type

# Then for each record:
Tool: SN-Update-Record
Parameters:
  table_name: sys_update_xml
  sys_id: [record_sys_id]
  data:
    update_set: [correct_update_set_sys_id]

ステップ 6：更新セットを完了する

開発が完了したら、完了としてマークします。

MCP を使用する場合：

Tool: SN-Update-Record
Parameters:
  table_name: sys_update_set
  sys_id: [your_update_set_sys_id]
  data:
    state: complete
    description: "COMPLETED: [original description]

    Contains:
    - 3 Business Rules
    - 2 UI Policies
    - 1 Script Include
    - 5 Form modifications

    Tested by: [tester name]
    Test date: 2026-02-06"

ステップ 7：デプロイ前の検証

上位環境にエクスポートする前に、次の項目を確認します。

問題がないか確認：

Tool: SN-Query-Table
Parameters:
  table_name: sys_update_xml
  query: update_set=[sys_id]^type=sys_script^actionINinsert,update
  fields: name,payload

検証チェックリスト：

• ハードコードされた sys_id がない
• ハードコードされたインスタンス URL がない
• テストデータが含まれていない
• すべてのスクリプトにエラー処理がある
• スクリプトに認証情報が含まれていない
• 依存関係が文書化されている

ステップ 8：エクスポートして移行する

XML にエクスポート： 更新セット → 関連リンク → XML にエクスポート に移動します。

リモートインスタンスの場合：

1. 対象インスタンスで、システム更新セット → 取得済み更新セット → XML からインポート の順に選択します
2. 更新セットをプレビューします
3. 競合を確認します
4. 更新セットをコミットします

更新セットの状態

┌─────────────┐     ┌──────────┐     ┌───────────┐
│ In Progress │────►│ Complete │────►│ Exported  │
│   (build)   │     │ (ready)  │     │ (shipped) │
└─────────────┘     └──────────┘     └───────────┘
                          │
                          ▼
                    ┌──────────┐
                    │ Ignore   │
                    │ (voided) │
                    └──────────┘

ツールの使用概要

操作	MCP ツール	REST エンドポイント
作成	SN-Create-Record	POST /sys_update_set
現在のセットに設定	SN-Set-Update-Set	Custom API
現在のセットを取得	SN-Get-Current-Update-Set	GET /sys_user_preference
一覧表示	SN-List-Update-Sets	GET /sys_update_set
内容を確認	SN-Inspect-Update-Set	GET /sys_update_xml
レコードを移動	SN-Move-Records-To-Update-Set	PATCH /sys_update_xml
複製	SN-Clone-Update-Set	POST /sys_update_set

ベストプラクティス

• 更新セットごとに 1 つの機能： 関連のない変更を混在させないでください
• わかりやすい名前： 命名規則に一貫して従ってください
• 定期的にコミット： 更新セットは一度にまとめず、段階的に完了させてください
• 昇格前にテスト： 必ず先に下位環境でテストしてください
• 依存関係を文書化： 先に適用する必要がある他の更新セットがあれば記録してください
• 本番環境では編集しない： 必ず開発環境またはテスト環境で開発してください

トラブルシューティング

レコードが Default 更新セットに入る

原因： 現在の更新セットが設定されていないか、リセットされました 解決策： 変更を行う前に、必ず現在の更新セットを確認してください。

Tool: SN-Get-Current-Update-Set

更新セットでレコードが見つからない

原因： レコードタイプが追跡対象になっていないか、更新セットを設定する前に作成されていません 解決方法：

1. レコードタイプが追跡対象かどうか確認します（sys_update_set_source）
2. 関連リンクの「更新セットに追加」を使用して手動で追加します

コミット中の競合

原因： 同じレコードが複数の更新セットで変更されています 解決方法：

1. まず更新セットをプレビューします
2. 競合を慎重に確認します
3. ローカルの内容を保持するか、スキップするか選択します
4. 競合の解決内容を記録します

更新セットが大きすぎる

原因： 1つの更新セットに変更が多すぎます 解決方法：

1. 新しい更新セットに複製します
2. 機能ごとに論理的に分割します
3. 不要なレコードを削除します

関連スキル

• admin/deployment-workflow - デプロイの全プロセス
• admin/application-scope - スコープ付きアプリケーションのベストプラクティス
• itsm/change-management - デプロイの変更プロセス

参考資料

• ServiceNow 更新セット
• 更新セットのベストプラクティス