変更管理モジュールのプロパティ

変更管理の承認エンジンを設定するプロパティを開くと、Change Requestの承認は off になっています。それでも実際のChange Requestには、承認待ち・承認済みのレコードが大量に積まれています。一見矛盾したこの状態は、承認処理をFlow Designerへ引き継いだ結果です。Australia の PDI をデフォルト設定のまま開き、変更管理に関わる74件のプロパティのうち、設計判断が必要な項目を優先順位・推奨値・変更条件の形で整理しました。

確認した範囲

• 74件のプロパティを、件数ではなく設定変更の優先順位で並べ替えた分類

• コンフリクト検知の推奨セットと、無効化した場合のリスク

• Copy Changeで複製した直後に再評価すべき項目

• CAB・変更カレンダーの性能系設定と業務系設定、それぞれの影響確認方法

• 名前に change を含んでいても、変更管理と無関係なプロパティ

要点

• 優先して確認すべきは承認方式・コンフリクト検知・データ強制の3分類。件数の多寡と業務への影響範囲は一致しない

• コンフリクト検知はCI基準（4件）を既定のまま維持し、担当者基準（assigned_to）は掛け持ち体制なら有効化するのが推奨セット

• Copy Changeはriskをそのまま複製するため、複製直後の再計算が必須

• CABは性能系（表示件数）と業務系（出席者同期）で影響範囲と確認方法が異なる

プロパティで何が変えられるか

sys_properties を name で "change" 検索すると118件がヒットします。このうち変更管理そのものに関わるものは74件で、残りは名前が偶然 "change" を含むだけの無関係なプロパティです（詳細は本記事末尾）。

74件を役割で分けると7つのまとまりになりますが、件数の多寡は設定変更の優先順位と一致しません。承認方式やデータ強制のように件数が少なくても全Change Requestに影響する分類がある一方、CABの表示件数のように件数が多くても画面のパフォーマンス調整にとどまる分類もあります。

推奨するあるべき姿：設定変更に着手する順序は、影響範囲の広さで決めます。次の表は、件数ではなく優先順位で7分類を並べ替えたものです。

優先度1の3分類は、値を変えるとChange Requestの承認経路やデータ品質そのものが変わります。導入直後に必ず目を通します。優先度2はチーム体制や複製ルールに合わせて個別に判断する分類、優先度3は画面表示や単一の連携先など影響範囲が閉じた分類です。

• 参考：システムプロパティ（sys_properties）は設定値の置き場 … プロパティ全体の扱い方

コンフリクト検知に関連するプロパティ

Change Requestを1件登録すると、同じCIや同じ担当者に予定されている他の変更と重なっていないかを確認する仕組みがあります。コンフリクト検知（Conflict Detection）と呼ばれ、change.conflict.* の28件で挙動が決まります。

28件のうち19件がboolean型で、チェック項目を1つずつオン・オフする構成です。オンとオフの分かれ方を図にします。

CI（モノ）を基準にしたチェックは、同一CIへの重複予定・ブラックアウトウィンドウ・メンテナンスウィンドウ・関連するApplication Serviceのウィンドウの4種類がすべて有効です。同一CIチェックの公式説明を引用します。

（訳: 変更リクエストの衝突を確認する際、同一CIにすでに予定されている変更と照合する）

引用元: /sys_properties_list.do?sysparm_query=name=change.conflict.currentci

一方、担当者（ヒト）を基準にしたチェックは既定で無効です。

（訳: 変更リクエストの衝突を確認する際、他の変更リクエストがすでに同じ担当者に予定されていないかを確認する）

change.conflict.assigned_to の説明です。値は false で、1人の担当者に複数の変更作業が重なっていても、コンフリクト検知はそれを衝突として拾いません。CI参照のメンテナンススケジュール（ci_maint_sched）と、親子CIのブラックアウト・メンテナンス窓の4件も同様に無効です。

実行タイミングにも設計があります。change.conflict.refresh.conflicts は true で、CI・開始日・終了日・Stateが変更されるたびに自動で再検知が走ります。対して change.conflict.refresh.scheduled は false で、定期スケジュールでの再チェックは組み込まれていません。更新イベント駆動のみで運用する設計です。

CIを軸にした調整は既定で手厚く、担当者を軸にした調整は既定で手薄です。

推奨するあるべき姿：CMDBの品質が一定水準にある環境（対象CIのAffected CIs登録が運用として定着している環境）を前提に、次を推奨セットとします。

設計例：以下は、設計内容を具体化するための推奨例です。実際の組織名／グループ名／時間／閾値／通知先は、導入先の運用体制に合わせて確定してください。

• currentci・blackout・currentwindow・relatedservices は既定のtrueを維持する

• assigned_to は、担当者が複数チームの変更を掛け持ちする体制であればtrueへ変更する

無効化・未対応のリスク：CI基準の4件をfalseにすると、同一CIへの重複予定をCABが見落とし、承認後に本番で衝突します。担当者基準を掛け持ち体制のまま既定のfalseで放置すると、1人に複数の変更が同時に割り当たっても検知されません。

ロールバック方法：assigned_toはtrueからfalseに戻すだけで判定が即座に既定へ戻ります。すでに生成したconflictレコードは自動削除されないため、不要な場合は手動で削除します。

本番導入前の検証事項：assigned_toを変更したら、同一担当者に重複するChangeを2件作成し、conflict_statusが更新されるかを確認します。

• 参考：変更管理モジュールの概要 … コンフリクト検知が関わるNormal Changeの全体像

引用した公式説明を実機で確認する方法（コンフリクト検知）

引用元: /sys_properties_list.do?sysparm_query=nameSTARTSWITHchange.conflict^descriptionISNOTEMPTY

リスク評価に関連するプロパティ

Change Requestのフォームには risk（Risk）という項目があり、リスク条件（Risk Conditions）に基づいて自動計算されます。ここに関わるプロパティは2件だけです。

どちらもポップオーバーの見せ方を決める表示設定です。リスクの計算ロジックそのものは、これらのプロパティではなく risk_conditions テーブルとScript Include RiskCalculator が担います。プロパティを変更しても、リスクの判定結果は変わりません。

リスクの判定基準を変えたい場合、触る対象はプロパティではなく risk_conditions レコードです。この切り分けを知らずにプロパティ側を探すと、目的の設定にたどり着けません。

承認エンジンに関連するプロパティ

変更管理には、承認の方式を切り替えるプロパティが2件あります。ここが本記事でもっとも見落としやすい設定です。

glide.approval_engine.change_request の値は off です。姉妹プロパティ glide.approval_engine.std_change_proposal も同じく off で、こちらには意味を補う説明が付いています。

（訳: std_change_proposalテーブルに使う承認エンジン。有効な選択肢は、空欄ならApproval Rules、'process_guide'ならProcess Guides、'off'ならそのテーブルの承認エンジンを無効化する。Workflowで承認を管理する場合は'off'に設定する）

引用元: /sys_properties_list.do?sysparm_query=nameINglide.approval_engine.change_request,glide.approval_engine.std_change_proposal

offという値だけを見ると、承認の仕組み自体が無効化されているように読めます。実際には逆で、承認をWorkflowやFlow Designerで管理するときにoffへ設定する仕様です。

実機では sysapproval_approver に732件の承認レコードがあり、Normal・Standard・Emergency・Unauthorizedの4種類すべてに専用のFlowが揃っています。プロパティの値だけで承認の有無を判断すると、稼働している承認の仕組みを見落としかねません。

推奨するあるべき姿：offのままFlow Designerに任せる既定の設計を維持します。Approval Rulesへ全面的に戻す組織方針が決まった場合のみ値を変更します。

ロールバック方法：値を空欄に戻す操作自体は1件の編集で完了します。ただし進行中のsysapproval_approverとFlowの承認が併存する期間が生まれるため、変更前に進行中の承認レコード件数を控え、変更後に承認経路が二重に動作していないかを個別に確認します。

• 参考：ServiceNow 承認（Approval）完全ガイド：申請はどこで誰に回り、なぜ止まるのか … 承認経路のたどり方

• 参考：Flow Designerの中身は3テーブル（sys_hub_flow） … 承認Flowを構成するテーブル

• 参考：レガシーWorkflow（wf_workflow）とFlowの違い … 旧classic workflowプラグインとの併存を理解する手がかり

Change Management本体に関連するプロパティ

com.snc.change_management.* の9件は、変更管理という機能全体の挙動を決めます。

代表は com.snc.change_management.enforce_data_requirements です。値は true。

（訳: Change Requestプロセスのデータ要件を強制する。Change Requestテーブルへの変更は、標準フォームのUI Policyが定めるデータ要件と同じ制約を受ける。制約はGlideRecordレベルで強制され、フォーム・Flow・Workflow・REST/SOAP API・JavaScriptからの更新すべてに適用される）

引用元: /sys_properties_list.do?sysparm_query=name=com.snc.change_management.enforce_data_requirements

フォームのUI Policyだけでなく、API経由の更新にも同じ必須項目チェックが及びます。画面からの入力だけを固めても、Flowやスクリプトからの直接更新で必須項目が抜けることを防ぐ設計です。

推奨するあるべき姿：既定のtrueを維持し、変更しない設定として扱います。falseにするとフォームのUI Policyが効かないFlow・API経由の更新で、必須項目が入力漏れのまま保存されてしまいます。

もう1件、com.snc.change_management.risk_conditions.match_all は true です。複数のリスク条件に一致した場合、もっとも高いリスクを採用します。falseにすると、最初に一致した条件だけを採用する挙動に変わります。

Change Request固有の動作に関連するプロパティ

com.snc.change_request.* は23件あり、複製・標準変更・関連リストの自動更新を制御します。

com.snc.change_request.copy.attributes には、Copy Change機能で複製する項目が16個並びます。category・cmdb_ci・risk・chg_model・typeなど、変更の性質を決める項目が中心です。状態や承認履歴は含まれません。関連リストも copy.related_lists で別途5種類が指定されています。

Copy Changeで複製した直後に再評価する項目

確認済みのOOTB構成：copy.attributesの16項目にはriskが含まれます。一方、start_date・end_date・承認履歴（approval_history/approval_set）・close_code・close_notesは含まれません。複製直後はこれらが空欄になり、stateは既定値（New）に戻ります。

推奨するあるべき姿：riskは複製元の評価をそのまま引き継ぐため、CIや周辺状況が変わっていても再計算されません。複製後は保存前に必ず再評価します。

設計例：以下は、設計内容を具体化するための推奨例です。実際の組織名／グループ名／時間／閾値／通知先は、導入先の運用体制に合わせて確定してください。

• risk：一旦空値に戻して保存し、Risk Conditionsによる自動計算を再度走らせる

• start_date・end_date：複製元の日程を転記せず、新しい日程を入力する

• 承認履歴・作業結果：複製元の実績を根拠にせず、新しいChangeとして改めてCABに諮る

再評価しない場合のリスク：riskをそのまま使うと、CMDBの依存関係が増えたCIでも古い低リスク評価のまま承認が進み、実際の影響範囲を過小評価します。

本番導入前の検証事項：Copy Changeで1件複製し、risk欄が保存時に再計算されるか、start_date未入力のまま保存が進んでしまわないかを確認します。

com.snc.change_request.enable_unauthorized は false です。Unauthorized（無許可変更）のマーク機能そのものが無効化されています。このプロパティには公式説明が付いていません。23件のうち説明が空欄なのはこの1件ともう1件だけで、他の21件には説明があります。

com.snc.change_request.event.state_updated.enabled も false です。Stateが変わっても sn_change.state.updated イベントは発火しません。この値をtrueにすると、State変更を起点にした通知やインテグレーションを追加で組める余地が生まれます。

com.snc.change_request.populate_business_application と populate_service_offering はどちらもfalseです。影響を受けた業務アプリ・サービスオファリングを自動で埋める機能は既定で止まっています。CMDBの整備状況に依存する機能のため、誤った関連付けを避ける安全側の初期値です。

• 参考：変更の流れを決める Change Model（chg_model） … typeとModelの対応関係

CAB・変更カレンダーに関連するプロパティ

CAB（Change Advisory Board）とChange Scheduleの画面には、専用のプロパティが9件あります。確認済みのOOTB構成として、影響範囲が異なる2種類が混在しています。画面の表示件数を決める性能系設定と、CAB運営のルールを決める業務系設定です。変更後に確認する方法もこの2つで分かれるため、節を分けます。

表示件数などの性能系設定

Change Scheduleの表示件数は3段階で制御されています。画面を開いた瞬間は change_soc_initial_limit（既定40件）、スクロールするたびに change_soc_scroll_load_limit（既定20件）が追加読み込みされ、change_soc_total_limit（既定1000件）を上限に止まります。1000件を超える変更を1画面に並べる運用は想定されていません。

変更時の影響確認方法：limitを引き上げたら、予定件数が多い期間のChange Scheduleを実際に開き、初期表示までの時間とスクロール時の応答を確認します。件数を増やすほど画面側の描画負荷が増えるため、体感速度の劣化がないかも合わせて見ます。

ロールバック方法：件数を既定値（40／20／1000）に戻すだけで即時反映されます。データの再計算は発生しません。

CAB運営に関わる業務系設定

CAB側では cab.refresh_group_attendees が true で、CAB Boardグループのメンバーが増減すると出席者リストが自動更新されます。ただし対象は refresh_group_attendees.meeting_state に指定されたミーティング状態、既定では pending のみです。ミーティングが進行中や完了に変わったあとは、メンバー変更が出席者リストへ自動反映されません。

変更時の影響確認方法：meeting_stateの対象を広げたら、進行中のCABミーティングでグループメンバーを増減させ、cab_attendee 関連リストが実際に更新されるかを確認します。想定していないタイミングで出席者が入れ替わっていないかも合わせて見ます。

• 参考：CAB Workbench（/cab）の入口はカレンダー1枚：ウィジェットも1個だけ … CAB Workbenchの画面構成

他プロセスとの連携先に関連するプロパティ

Change Requestは、フォーム以外の経路からも作られます。関係するプロパティが1件あります。

com.snc.task.add_change_request の値は problem,incident です。

（訳: 一覧画面からChange Requestを追加できるようにしたい、タスクの種類をカンマ区切りで並べたリスト）

引用元: /sys_properties_list.do?sysparm_query=name=com.snc.task.add_change_request

Problem・Incidentの一覧画面から、複数件をまとめてChange Requestに起票できる導線がこのプロパティで登録されています。

• 参考：インシデント管理モジュールのプロパティ … Incident側から見た連携の形

変更管理とは無関係のプロパティ

118件の "change" 検索結果のうち44件は、変更管理そのものではありませんでした。

glide.kmf.adhoc_key_exchange.number_of_retries はその1つです。

（訳: AdHoc Key Exchangeが失敗した場合に、成功するまで試行するリトライ回数）

これは "exchange" という単語の部分文字列として "change" を含んでいるだけです。暗号鍵交換の設定で、Change Managementとは関係ありません。

glide.timezone_changer.roles はタイトルバーのタイムゾーン切替ウィジェットを使えるロールの一覧、css.label.changed.background.color はフォーム上で「変更されたフィールド」を示す色の設定です。どちらも名前に change を含みますが、Change Requestとは無関係です。

glide.ecmdb.change_end_date はやや紛らわしい例です。公式説明は "Change Request field used for end_date" で、一見Change Requestに関係しそうに読めます。ところが接頭辞の glide.ecmdb はCMDB Discovery側のプロパティで、値も work_end という、change_requestには存在しないフィールド名です。プレフィックスがどのモジュールに属するかを見ないと、説明文の字面だけでは判断を誤ります。

名前に "change" が入っているという理由だけでプロパティを一覧に加えると、無関係なものが4割近く混ざります。棚卸しをするときは、プレフィックス単位で1件ずつ確認する作業が欠かせません。

プロパティを変更する前の確認事項

74件のうち、実際に触る機会が多いものを前提・推奨値・変更条件・影響・検証方法の5列で整理しました。この表を確認する目的は、値を変える前に「なぜ変えるのか」を先に固めることです。対象は本記事で扱った代表例で、全74件の網羅ではありません。

表から読み取れる重要事項は、9件中7件が既定値を維持する判断になる点です。明確に変更を推奨するのは担当者基準のコンフリクト検知とUnauthorized Changeのマーク機能の2件だけで、それ以外はCMDBの整備状況や運用体制という前提条件が満たされてから動かします。原則として変更しないのは com.snc.change_management.enforce_data_requirements で、falseにするとAPI経由の入力漏れが素通りします。

変更する前に、次の3点を確認します。

1. 説明文を読む：70件に公式説明があります。値の意味を推測で決めません

2. 値に並ぶ項目名の実在：カンマ区切りのリスト型は、存在しない項目名が入っていても素通りします

3. 変更の記録：プロパティの変更は更新セットに入ります。移送の対象になるかを確認します

実機で気づいたこと

承認エンジンのoffは、承認の停止ではなく管理方式の切り替え

glide.approval_engine.change_request の説明文は "Change Requests approval engine:" とだけ書かれ、値の意味そのものは説明されていません。姉妹プロパティ glide.approval_engine.std_change_proposal の説明を読んで初めて、offがWorkflow/Flow Designerで承認を管理する設定であると分かりました。

説明が薄いプロパティに出会ったら、同じ接頭辞を持つ別のプロパティの説明文を探します。同じ仕組みを別テーブル向けに提供しているプロパティでは、説明の詳しさに差があることがあります。

コンフリクト検知は「モノ」に強く「ヒト」に弱い

CI・ブラックアウト・メンテナンス窓・関連サービスという4種類のCI基準チェックはすべて有効でした。一方、担当者の重複を確認する change.conflict.assigned_to は既定でfalseです。

コンフリクト検知という名前から、担当者の予定も自動でチェックされると考えていましたが、実機の既定値はCIを軸にした衝突だけを見る作りでした。1人の担当者が複数の変更作業を抱えていないかは、別途の運用手順で確認する必要があります。

118件のうち4割は無関係というノイズの大きさ

nameLIKEchange で検索した118件のうち、変更管理に関わるものは74件にとどまりました。"exchange" が "change" を含むように、英単語の部分一致は避けられません。

変更管理のプロパティを棚卸しするときは、nameLIKEchange の結果をそのまま採用せず、change.conflict や com.snc.change_request のようなプレフィックス単位で確認する手順を勧めます。

プロパティを調整するときの検討順序

プロパティを調整するとき、確認する順序を決めておくと迷いません。

1. 説明文を読む：70件に公式説明がある。姉妹プロパティの説明も併せて確認する

2. コンフリクト検知の対象：CI基準4件は既定のtrueを維持し、担当者基準（assigned_to）は掛け持ち体制かどうかで判断する

3. 承認の管理方式：既定のoffを維持し、Flow Designerに任せる。Approval Rulesへ戻すのは組織方針が決まった場合のみ

4. 複製で引き継ぐ項目：既定の16項目を維持し、riskは複製後に再計算する運用を追加する

5. 標準変更の起票制限：非アクティブなテンプレートでの起票を阻止する設定を維持する

6. 影響サービスの自動更新：CMDBの完成度を確認してから有効化する

7. Change Scheduleの表示件数：大規模環境で上限に達しないかを性能系の節に沿って確認する

8. 無関係なプロパティの除外：プレフィックス単位で棚卸しし、ノイズを取り除く

用語

• OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態

• PDI：Personal Developer Instance。ServiceNowが無償で提供する個人検証用インスタンス

• コンフリクト検知：Conflict Detection。予定されている変更どうしの日程・CIの重なりを検知する機能

• CAB：Change Advisory Board。変更の承認可否を協議する会議体、およびその管理画面

• risk_conditions：Changeのリスクを自動判定する条件を保持するテーブル

検証範囲とおことわり

• 検証環境：Australia PDI / OOTB / 2026-09-01 確認

• 件数と既定値はすべてOOTBの状態です。本番環境やカスタマイズ済み環境では異なります

• 推奨セット・設計例は、CMDBの整備状況や体制が一般的なITSM導入企業に近いことを前提にした例です。導入先の運用体制に合わせて確定してください

• プロパティを実際に変更して挙動が変わることは、コンフリクト検知の再検証手順以外は確認していません

• com.snc.change_management.velocity.process_opt_project が指すレコードの中身までは追っていません

• 各プロパティを読んでいるBusiness Rule・Script Includeの実装は、本シリーズ第6巻「変更管理モジュールの自動設定構成」で扱います

• Problem・Incidentとの連携の全体像は、本シリーズ第8巻「変更管理モジュールの連携機能」で扱います

付録：自分の環境で確認するときのURL

• change関連のプロパティ：/sys_properties_list.do?sysparm_query=nameLIKEchange

• コンフリクト検知：/sys_properties_list.do?sysparm_query=nameSTARTSWITHchange.conflict

• 承認エンジン：/sys_properties_list.do?sysparm_query=nameINglide.approval_engine.change_request,glide.approval_engine.std_change_proposal

• Change Management本体：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.change_management.

• Change Request固有動作：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.change_request.

• CAB・変更カレンダー：/sys_properties_list.do?sysparm_query=nameSTARTSWITHsn_change_cab^ORnameSTARTSWITHsn_chg_soc

• 説明が入っているプロパティ全体：/sys_properties_list.do?sysparm_query=descriptionISNOTEMPTY

引用した公式説明を実機で確認する方法

この記事で引用した説明文は、ServiceNowが製品に同梱しているプロパティの説明です。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。

• プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameLIKEchange^descriptionISNOTEMPTY

関連記事

• 変更管理モジュールの概要 … typeとChange Modelの全体像

• ServiceNow 承認（Approval）完全ガイド：申請はどこで誰に回り、なぜ止まるのか … 承認エンジンがoffでも動く仕組みの裏付け

• インシデント管理モジュールのプロパティ … 同じ切り口でIncidentを扱った回