変更管理モジュールの基本設定

2026年9月4日 00:55

変更管理モジュールには、Normal・Standard・Emergencyという3つのtypeに加えて、chg_modelという6件のレコードが存在します。承認・リスク判定・CAB・コンフリクト検知は、このchg_modelの設定と組み合わさって動く仕組みです。本記事は、Australia PDIのデフォルト設定を対象に、Change Model・状態遷移・リスク評価・承認・CAB・コンフリクト検知の初期状態を実機で確認した記録です。推奨する設計や導入判断はこの記事では扱いません。個々の設定に対する推奨値・設計例は、シリーズ内の各巻（開発設計書・プロパティ・運用設計書）で扱います。

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

取得条件

調査環境：Australia PDI（Personal Developer Instance。インスタンス名は本文では非公開とし、evidence.mdに記録）
取得日時：2026-09-01（sttrm_stateのChange Registration・Cloud Infrastructure・Unauthorized Changeの初期状態のみ2026-09-03に読み取り専用で再実測）
集計範囲：件数は既定でactive=trueのレコードのみを対象にしました。無効化レコードを含む場合は本文にその旨を明記します
取得方法：tools/pdi_client.pyによるREST読み取り。書き込みは行っていません
クエリの対応：chg_model（全件、6件）／sttrm_state（sttrm_modelごとに絞り込み、initial_state=trueのレコードで初期状態を判定）／risk_conditions（全件、order順に4件）／sys_properties（nameSTARTSWITHで対象プレフィクスを絞り込み）／sysrule_assignment（table=change_request）／sysevent_email_action（collection=change_request）。個別のクエリ文字列は各表の直後に「証跡」として記載
未確認値の理由：Change RegistrationとCloud Infrastructureは件数・初期状態まで確認しましたが、状態が遷移する条件（何をきっかけに次へ進むか）までは自動化専用モデルのため追っていません。risk_conditionsを変更した場合の計算結果、Conflict Detectionを有効化した場合の実際の検知動作は、設定変更を伴う検証がこの記事の範囲外のため未確認です（詳細は末尾「検証範囲とおことわり」）

この記事で確認した設定

Change Model 6件とtypeの対応関係
標準変更テンプレート（std_change_producer_version）の内容
状態遷移（sttrm_state）のモデル別件数と初期状態
リスクの自動判定条件（risk_conditions）
承認（Flow Designer）とCABの構成
コンフリクト検知（Conflict Detection）の既定の有効・無効

確認済みのOOTB構成（要約）

Change Modelは6件、typeの選択肢は4値で数が一致しない
状態はNormal8・Emergency7・Standard6・Unauthorized3とモデルごとに異なる
承認はFlow Designerが担い、旧来の承認エンジンはoffになっている
コンフリクト検知は担当者の重複チェックなど一部が既定で無効

Change Modelとtypeの対応関係

change_requestのtypeフィールドは4つの値を持ちます。standard・normal・emergency・modelです。実際に変更を組み立てる単位はtypeそのものではなく、chg_modelという別テーブルの6件のレコードです。

6件の中身を並べると、typeとの対応がどう作られているかが分かります。

証跡：chg_model全件取得（evidence.md §1）

chg_modelという辞書を開いても、type列そのものは存在しません。typeを注入しているのはrecord_presetというテンプレート文字列です。Normalならtype=normal^EQ、Standardならtype=standard^EQという値がそのまま入っていて、新規作成のタイミングで一度だけ書き込まれます。

Standardはavailable_in_uiがfalseです。通常の新規作成画面には出てきません。Change RegistrationとCloud Infrastructureも同じくfalseで、こちらはtype=modelという自動化専用の値を使います。API経由や連携ツール経由での起票を想定した区分です。Unauthorized Changeは独自のtype値を持たず、record_presetの中でtype=emergencyにunauthorized=trueというフラグを重ねる形で表現されます。

record_presetの書式とChange Model追加時の設計は、変更管理モジュールの開発設計書（第10巻）で扱います。

参考：変更管理モジュールのテーブル・フィールド構成 … typeフィールド1つの詳しい追い方
参考：変更の流れを決めるChange Model（chg_model） … chg_model自体をさらに深く追う

標準変更テンプレートstd_change_producer_versionの構成

Standardモデルはavailable_in_uiがfalseなので、担当者が手で選んで起票する経路がありません。起票できるのはstd_change_producer_versionというテンプレートを経由したときだけです。

実機の6件はこの内容でした（evidence.md §2）。

テンプレート名versionClear BGP sessions on a Cisco router - 11Replace printer toner - 11Reboot Windows Server - 11Add network switch to datacenter cabinet - 11Decommission local office Domain Controller - 11Change VLAN on a Cisco switchport - 11

6件すべてversionが1でした。提案から一度も改版されていないことになります。versionという列を持つ以上、この仕組みは改版を前提に設計されているはずです。

chg_modelが6件、std_change_producer_versionも6件で総数が一致します。ただし「1モデルにつき1テンプレート」という対応関係までは確認していません。件数が同じという事実と、対応関係が決まっているという主張は別物です。

com.snc.change_request.standard_change.abort_insert_inactive_templateというプロパティはtrueでした。非アクティブなテンプレートを指定した新規作成は止まります。テンプレートの改訂履歴の残し方は、変更管理モジュールの運用設計書（第11巻）で扱います。

参考：変更申請テンプレートには切り戻し手順まで入っている？ sttrm_base_templateを実機で読む … テンプレートに入る項目そのものの構造

状態遷移はモデルごとに数も内容も違う

chg_model_stateやchg_model_state_transitionという専用テーブルは存在しません。状態遷移を実際に担うのはsttrm_stateという汎用の仕組みで、chg_modelのレコードごとに参照先のモデルが変わります。

6件のchg_modelそれぞれに、sttrm_stateを数えました。

証跡：sttrm_modelと名前が一致するsttrm_stateをモデルごとに絞り込んで取得（evidence.md §3）。初期状態はinitial_state=trueのレコードで確認

Normalは8件で状態全体を使います。Emergencyは7件で、Assessだけを除いた形です。Standardは6件で、AssessとAuthorizeの両方を除きます。Unauthorized Changeは3件しかなく、初期状態はReviewです（initial_state=trueの実測）。NewやScheduledやImplementを経由せず、承認外の実施を検知した後の事後審査からレコードが始まる構造です。

4モデルの流れを並べると、どこを削っているかがひと目で分かります。

Change RegistrationとCloud Infrastructureも同じ仕組みでsttrm_stateを持ちます。件数はそれぞれ3件と2件で、初期状態はChange RegistrationがReview、Cloud InfrastructureがAuthorizeでした（いずれもinitial_state=trueの実測）。どちらも自動化専用のモデルで、通常の画面から使うものではないため、状態が遷移する具体的な条件は本記事では未確認です。

sttrm_stateはchg_modelのレコード単位で保持されます。Normalに状態を1件追加してもEmergencyやStandardには影響しない、モデルごとに独立した設定です。

参考：State Transition Models（sttrm_model）：変更タイプごとに状態遷移を定義する仕組み … sttrm_stateの定義構造そのもの
参考：変更管理モジュールの概要 … 3種別の使い分けをより詳しく比較

リスク評価はrisk_conditionsとRiskCalculatorが担う

リスクを算出する機構を探すと、dl_risk_valueという似た名前のテーブルにたどり着きます。ところがこれはProject Portfolio Management向けのLookupテーブルで、変更管理とは無関係でした。実際にchange_requestのリスクを決めるのはrisk_conditionsという4件の条件と、Script Include RiskCalculatorです。

4件の中身をまとめます。

証跡：risk_conditions全件取得（evidence.md §4）

order順に評価され、最初の3件はリードタイム不足・重要サービスの変更・重要サービスへの影響という具体的な条件を持ちます。4件目だけはconditionが空に近く、状態だけを条件にした既定の条件です。他のどれにも一致しなかったときに、これが低リスクとして扱う既定の受け止め役になります。

com.snc.change_management.risk_conditions.match_allというプロパティはtrueでした。複数の条件に一致した場合、最も高いリスクが採用されます。

change_request.riskの選択肢は5段階定義されていますが、両端（Very High・None）は無効化されていて、実質はHigh・Moderate・Lowの3段階しか選べません。risk_conditionsが返す値もこの3段階の範囲に収まります。

質問票方式のRisk Assessmentプラグインは無効でした。条件ベースの計算だけが動いている状態です。risk_conditionsを追加・変更する際の設計例は、変更管理モジュールの開発設計書（第10巻）で扱います。

承認はFlow Designerが担い、CABが合議する

glide.approval_engine.change_requestというプロパティの値はoffでした。公式の説明はこうです。

set to 'off' when using Workflow to manage approvals

（訳：Workflowで承認を管理する場合は'off'に設定する）

引用元：/sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.approval_engine

旧来のApproval Rulesエンジンは使われていません。実際に承認を進めるのはFlow Designerです。

normal・standard・emergency・unauthorizedの4type全てに専用のFlowがあります（evidence.md §5）。Normalなら「Assess・Authorize・Implement」の3段階です。Emergencyなら「Authorize・Implement・Review」の3段階になります。typeごとにフローの構成が変わる作りです。

承認の合議はCABが担います。

cab_meetingは6件、全件がPending（未開催）でした。会議体の設定テンプレートにあたるcab_definitionは1件だけで、「Network CAB」という名前です。ネットワーク関連の変更に絞ったCABが1つ用意されている状態で、他の領域向けのCABは登録されていません。

承認の全体像を図にします。

sysapproval_approverはchange_requestに紐づくものが732件あり、requested 376・not_required 290・approved 66・rejected 0という内訳でした。not_requiredが4割近くを占めます。承認レコードが作られても、必ず人が判断するとは限りません。not_requiredの判定条件をどう扱うかは、変更管理モジュールの運用設計書（第11巻）で扱います。

参考：グループ承認：N人を1つに束ねる仕組み（sysapproval_group） … 承認の基本機構
参考：CAB Workbench（/cab）の入口はカレンダー1枚：ウィジェットも1個だけ … CAB Workbench画面の構成
参考：Flow Designerの中身は3テーブル（sys_hub_flow） … Flow自体の構造
参考：承認（Approval）運用手順書 … CAB承認を1件通す操作手順

コンフリクト検知は種類ごとに有効・無効が分かれる

conflictというテーブルは実在します。プラグイン「Collision Detector」も有効です。ただしデモデータでは0件でした。仕組みは動く状態で用意されています。

主なプロパティをまとめます。

証跡：sys_propertiesをnameSTARTSWITHchange.conflictで絞り込んで取得（evidence.md §6）

同一CI・ブラックアウトウィンドウ・メンテナンスウィンドウ・関連サービスの4種は既定で有効です。一方、担当者の重複スケジュールチェック（change.conflict.assigned_to）は既定で無効でした。CIのメンテナンススケジュール参照（change.conflict.ci_maint_sched）と、定期スケジュールでの再チェック（change.conflict.refresh.scheduled）も無効です。

既定のコンフリクト検知は「モノ」の重なりを見る設計で、「ヒト」の重なりは見ていません。同じ担当者が同じ週に3件のEmergencyを抱えていても、既定の設定では検知されません。

change.conflict.refresh.scheduledが既定で無効な点も確認しました。コンフリクトの再チェックはCI・開始日・終了日・状態の変更をきっかけにしたイベント駆動だけで動きます。定期実行でまとめて洗い直す仕組みは既定では組み込まれていません。

各プロパティの推奨値と変更条件は、変更管理モジュールのプロパティ（第4巻）で扱います。

SLA・割り当てルールの実測

contract_slaをcollection=change_requestで確認すると、0件でした。ProblemやIncidentと同じく、変更管理にも標準のSLA定義は入っていません。

割り当てルール（sysrule_assignment）はchange_requestに1件だけありました。

名前は「Assign unauth change to chg management」、条件はunauthorized=true^chg_modelISEMPTY^EQです（evidence.md §7）。無許可変更が検知され、なおかつChange Modelが未設定のときだけ、変更管理チームへ自動で割り当てます。change_taskには割り当てルールが1件もありません。

自動割り当ての対象がUnauthorized専用の1件だけという構成です。Normal・Standard・Emergencyには自動割り当ての仕組みがありません。sysrule_escalate（無操作監視）もchange_request・change_task双方で0件でした。割り当てルール・エスカレーションルールの追加設計は、変更管理モジュールの開発設計書（第10巻）で扱います。

通知の実測

sysevent_email_actionをcollection=change_requestで確認すると16件でした（evidence.md §8）。

on_hold関連の3件は、どれもapproval.cancelledという汎用イベント名を流用していました。保留になったとき・保留が解けたとき・状態が変わったときに依頼者へ通知します。「Unauthorized change created」という1件だけはantivirus.infectedという無関係なイベント名を使っています。無許可変更の検知を、既存のイベント名に相乗りさせた実装です。

イベント名が使い回されている通知は、on_hold関連3件と「Unauthorized change created」の計4件です。16件の内訳と個別の通知設計は、本シリーズ第1巻「変更管理モジュールの概要」と運用設計書（第11巻）で扱います。

参考：メール通知が飛ぶまでの4段階（Notification） … 通知が届かないときの追い方

ここまでの設定を1枚にまとめます。

設定変更は更新セット（Update Set）に記録される

ここまでの設定は、すべて更新セット（Update Set）に記録されます。移送済みかどうかを確認する際の対象一覧として使う表です（platform共通の仕様で、変更管理固有のクエリはありません）。

変更するもの更新セットに入るかChange Model（chg_model）入るリスク条件（risk_conditions）入るCAB定義（cab_definition）入る割り当てルール（sysrule_assignment）入るシステムプロパティ（sys_properties）入る

検証環境で調整した設定は、更新セットにまとめて本番へ運べます。検証環境から本番への移送手順は、変更管理モジュールの開発設計書（第10巻）の移送設計章で扱います。

参考：Update Set（sys_update_set）：設定を運ぶ2層の箱 … 移送の仕組みそのもの

実機で気づいたこと

標準変更テンプレートは一度も改版されていない

std_change_producer_versionは全6件がversion=1でした。versionという列がある以上、テンプレートは改版される前提で設計されています。

実機のデモデータは初回登録のまま止まっていました。手順の見直しが発生していないか、そもそも見直した結果を新しいversionとして登録する運用が根付いていないか、どちらかだと考えられます。改訂履歴の残し方は運用設計書（第11巻）で扱います。

自動割り当てが用意されているのは無許可変更だけ

割り当てルールを確認すると、change_requestに1件しかなく、しかもUnauthorized専用でした。日常的に発生するNormalやStandardには自動割り当ての仕組みがありません。

通常は逆を想像します。件数の多いルートにこそ自動化が要ると考えがちです。ところが実機は逆で、例外処理であるはずのUnauthorizedにだけ自動割り当てが用意されていました。無許可変更は検知した瞬間に誰かが対応しなければならないため、割り当ての空白期間を作らない設計だと読み取れます。

コンフリクト検知はCIの重なりだけを見ている

コンフリクト検知の関連プロパティを並べると、有効なものはCI・ブラックアウト・メンテナンスウィンドウ・関連サービスの4種でした。担当者の重複は既定で見ていません。

最初はCIと担当者の両方を既定でチェックしていると考えていました。実機を確認すると、既定で有効なのはモノの重なりだけで、ヒトの重なりは対象外でした。CI単位でスケジュールを管理する運用を前提に設計されていて、要員の稼働管理は別の仕組みに委ねる作りだと分かります。

基本設定項目のOOTB既定値一覧

ここまでの設定を1枚の表にまとめます。判断のための表ではなく、確認済みの既定値を一覧化した表です。

証跡：本記事の各節で確認した値の再掲（個別の証跡は各表・evidence.mdの該当節を参照）

表から読み取れるのは、既定で有効になっている仕組みと、既定で無効・未登録のまま残っている仕組みの境界です。有効：Change Model 6件・状態遷移・リスク条件4件・Flow Designerによる承認・コンフリクト検知のCI系4種。無効・未登録：担当者重複のコンフリクト検知、Normal/Standard/Emergency向けの自動割り当てルール、Network CAB以外のCAB会議体です。

この一覧をもとにした推奨値・優先順位・設計例は変更管理モジュールの開発設計書（第10巻）、導入前の確認事項・体制設計は運用設計書（第11巻）で扱います。

用語

OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNowが無償で提供する個人検証用インスタンス
CAB：Change Advisory Board。変更の実施可否を協議する承認会議体
record_preset：Change Modelが新規レコード作成時に注入する、変更不可のテンプレート値
sttrm_state：State Transition Rule Modelの状態定義テーブル。chg_model以外の機能とも共有する汎用機構

検証範囲とおことわり

検証環境：Australia PDI / OOTB / 2026-09-01 確認（sttrm_stateの一部初期状態のみ2026-09-03に読み取り専用で再実測）
件数はすべてOOTBの設定・定義の数です。本番環境やカスタマイズ済み環境では異なります
Change RegistrationとCloud Infrastructureは状態の件数・内訳・初期状態までは確認しましたが、状態が遷移する条件（何をきっかけに進むか）は未確認です
risk_conditionsを実際に追加・変更したときの計算結果への影響は確認していません
Conflict Detectionを有効化した場合の実際の検知動作は、デモデータが0件のため確認できていません
std_change_producer_versionとstd_change_proposal（承認申請側）の紐付け運用は本記事の範囲外です
この記事は確認済みのOOTB構成の記録です。推奨設計・導入判断は扱わず、開発設計書（第10巻）・プロパティ（第4巻）・運用設計書（第11巻）に委ねます

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

Change Model一覧：/chg_model_list.do
標準変更テンプレート：/std_change_producer_version_list.do
状態遷移：/sttrm_state_list.do?sysparm_query=sttrm_model.name=Normal^ORDERBYstate_sequence
リスク条件：/risk_conditions_list.do
承認Flow：/sys_hub_flow_list.do?sysparm_query=nameSTARTSWITHChange^active=true
CAB会議：/cab_meeting_list.do
コンフリクト検知プロパティ：/sys_properties_list.do?sysparm_query=nameSTARTSWITHchange.conflict
割り当てルール：/sysrule_assignment_list.do?sysparm_query=table=change_request
通知：/sysevent_email_action_list.do?sysparm_query=collection=change_request

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

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

プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.approval_engine

変更の流れを決めるChange Model（chg_model） … record_presetを含むchg_model自体をさらに詳しく追う
State Transition Models（sttrm_model）：変更タイプごとに状態遷移を定義する仕組み … 状態遷移の定義そのものを実機で追う
CAB Workbench（/cab）の入口はカレンダー1枚：ウィジェットも1個だけ … CABの画面構成を実機で見る