変更管理モジュールのトラブル事例と解決
「承認が一向に進まない」「Implementに進めない」「typeを直したいのに変わらない」。Change管理を導入した直後によく出るこの3つは、承認エンジンが最初からoffだったり、Change Modelが状態を絞り込んでいたりする、デフォルトの作りが原因です。Australia の PDI をデフォルト設定のまま開き、9つの症状について原因候補・確認順序・正常値・復旧後確認・恒久対策までを整理しました。
検証環境：Australia PDI / OOTB / 2026-09-03 確認
この記事で判断できること
どの症状がどの設定・BusinessRuleに対応するか
何が見えれば正常で、何が見えれば異常か
復旧後に何を確認すれば完了と言えるか
恒久対策をどの巻（設計書）に引き継ぐか
症状から原因をたどる順序
変更管理の相談は、まず3つに分けます。
保存できない：ACLのscript条件、Business Ruleのabort
状態が先へ進まない：Change Modelの遷移条件、そのモデルに該当状態が無い
後続が動かない：承認、リスク自動計算、コンフリクト検知、通知
原因を間違えると時間を失います。「Implementが選べない」という相談に権限の調査から入っても、原因はChange Modelにその状態が無いことで、権限とは無関係な場合があります。
承認が始まらない・進まない
症状：Change Requestを起票しても承認依頼が誰にも届かない。CABに議題を上げても承認状態が変わらない
影響範囲：Authorize状態を持つ4モデル（Normal/Emergency/Unauthorized/Cloud Infrastructure）。Standard・Change RegistrationはAuthorize自体を持たず対象外
原因候補：①Flow無効・未公開／②Flowがエラー・取消で停止／③CAB決定の反映待ち／④承認者解決の項目未入力
正常値：sys_flow_context.stateはWAITING（実測62件全件がWAITING、ERROR・CANCELLEDは0件）。sysapproval_approverのstateはrequestedまたはnot_required
異常時の対応：ERRORならerror_messageの内容を解消してから状態を戻し再実行する。CANCELLEDならFlowを手動で再起動するか、Change自体を作り直す
復旧後確認：sysapproval_approverのstateがapproved/rejectedへ進み、change_request.stateがAuthorizeから次へ動いたかを見る。CAB経由の反映はBusiness Rule 1件を挟むため数分単位のズレを見込む
恒久対策：承認Flowの設計は開発設計書、CAB運営体制は運用設計書に引き継ぐ
確認順序
typeとchg_modelから対象Flowを特定する（例：normal→Change - Normal - Authorize。他3モデルも同型のAuthorize用Flowを持つ）
sys_hub_flowでそのFlowがactive・publishedかを確認する
sys_flow_contextをsource_record=対象sys_idで絞り込み、stateとerror_messageを見る
sysapproval_approverをsysapproval=対象sys_idで絞り込む。レコード自体が無ければFlowが承認生成ステップに未到達
参考：Flow Designerのフローが動かないときどこを見る？ 実行記録sys_flow_contextで切り分ける … 止まっているFlowを実測で切り分ける手順
参考：承認は1人1レコード（sysapproval_approver） … 承認レコードの構造
参考：CAB Workbench（/cab）の入口はカレンダー1枚：ウィジェットも1個だけ … CABの画面構成
Implementに進めない
症状：Change Requestを進めていくとImplementの手前で止まる。フォームに選択肢自体が無い場合もある
影響範囲：Change Registration・Unauthorized Change・Cloud Infrastructureの3モデル配下。Normal/Standard/Emergencyは対象外
原因候補：①モデルにImplement状態が未定義／②遷移条件（Not On hold／Risk evaluation／Authorized）を未充足／③on_hold=trueで遷移不可
正常値：目的の状態がsttrm_stateに定義されている。初期状態はモデルで異なる：Normal/Standard/Emergency=New(-5)、Change Registration/Unauthorized=Review(0)、Cloud Infrastructure=Authorize(-3)
異常時の対応：Implementが必要な業務ならモデル選定自体を見直す。定義はあるが条件未充足なら、保留解除・リスク評価・承認のうち欠けている条件を先に満たす
復旧後確認：状態が意図した値へ進み、chg_model_condition_typeの3条件をすべて通過しているかを見る
恒久対策：モデル選定基準は開発設計書、種別の使い分けは概要巻に引き継ぐ
確認順序
change_request.chg_modelで現在のモデルを確認する
sttrm_stateでそのモデルの状態一覧を見て、Implementが定義されているかを確認する
定義があるならchg_model_condition_typeの3条件のどれで止まっているかを見る
Business Rule「Change Model: Check State Transition」のエラーメッセージに含まれる条件名を読む
sttrm_state／sttrm_modelはProblem管理とも共有される汎用の状態遷移エンジンで、Change専用ではありません。
参考：State Transition Models（sttrm_model）：変更タイプごとに状態遷移を定義する仕組み … 遷移モデルの基本構造
保存できない・弾かれる
症状：Change Taskを更新しようとすると保存が失敗する。項目を1つ変えただけなのに他の変更も消える
影響範囲：親のChange Requestがon_hold=trueの間、配下のChange Task全体の保存
原因候補：on_hold／state／on_hold_reasonそれぞれの変更で発火するBR計3件がsetAbortAction(true)でレコード全体を中断する
正常値：親のon_hold=falseならChange Taskは通常どおり保存できる
異常時の対応：親を保留解除するか、保留理由に沿った対応を先に済ませてから再保存する
復旧後確認：親のon_holdがfalseに変わった後、止まっていた項目が保存できることを確認する
恒久対策：on_hold運用の手順は運用手順書に引き継ぐ
確認順序
対象Change Taskの親change_request.on_holdを確認する
trueなら、変更しようとした項目（on_hold／state／on_hold_reason）を特定する
sys_scriptをcollection=change_task^nameLIKEon holdで確認し、該当BRの条件を見る
参考：ServiceNowのBusiness Ruleはいつ動く？ before/after/asyncの違いを実機の件数で確認 … before/afterの実行順序の基本
typeが変えられない
症状：起票時に選んだtype（Normal/Standard/Emergency）を後から直したいのに保存すると元に戻る。adminで試しても変わらない
影響範囲：change_request.typeの変更操作全般（新規作成後）
原因候補：①ACL（新規作成時のみ許可、adminはnobodyロールで素通り）／②order90 BR（初期状態以外は理由問わずabort）／③order300 BR（normal/emergencyへの変更を無言で戻す）／④order900 BR（standardへの変更を明示エラーで中断）
正常値：初期状態（New）のうちであれば、itil/sn_change_writeロールでtypeを変更できる
異常時の対応：値を戻してから初期状態のうちに変更するか、起票し直す。normal/emergency間の変更はエラーが出ないため、保存後に値を見て気づく運用になる
復旧後確認：change_request.typeが意図した値のまま保持され、Change Modelとの対応（record_preset）がずれていないかを確認する
恒久対策：種別選定のチェックは概要巻の選定基準、入力チェックの強化は開発設計書に引き継ぐ
確認順序
sys_security_aclでname=change_request.type^operation=writeの3件を確認する
sys_scriptでcollection=change_request^nameLIKETypeを見て、order90・300・900のどれに該当するかを判定する
エラーメッセージが出るか（order90・900）、値が無言で戻るか（order300）を区別する
参考：変更管理モジュールのテーブル・フィールド構成 … typeが承認経路に与える影響
参考：変更の流れを決める Change Model（chg_model） … Change Modelの構造
Closeで保存が完了しない
症状：Change Requestをclosedにしようとすると保存が止まる。エラーが出たのにclose_codeが空のまま保存されることもある
影響範囲：state=3（Closed）へ変更する保存操作
原因候補：①close_notesが空（中断する）／②close_codeが選択肢に無い不正値（中断する）／③close_code自体が空（中断しない。エラーメッセージだけ出て保存は完了する）
正常値：close_notesが入力済みで、close_codeが選択肢内の値であること
異常時の対応：close_notesを入力してから再保存する。close_codeが空のまま完了した保存は、後から追記して整合させる
復旧後確認：state=Closedのレコードで、close_code・close_notesの両方が埋まっているかを一覧で確認する
恒久対策：Close時の入力ルールは運用手順書、必須項目の設計判断は開発設計書に引き継ぐ
確認順序
保存しようとしたclose_notes・close_codeの値を確認する
close_notesが空なら、BR「Mandatory Closure Information」（order900）がabortしていると判断する
close_codeが選択肢に無い値でも同じBRがabortする
close_codeだけが空の場合はエラー表示のみで保存が完了している可能性を疑う
リスクが自動で入らない
症状：Change Requestを保存してもriskとimpactが最初の値のまま変わらない。risk_conditionsを見直しても変わらない
影響範囲：risk・impactフィールドの自動更新のみ（保存自体は失敗しない）
原因候補：①glide.ui.risk_calculate_ruleが既定ui_actionでBR「Calculate Risk」の発火条件を満たさない／②複数のrisk_conditionsに一致した場合の優先順位を誤解している／③risk_conditions自体（4件）の条件式が想定と違う
正常値：ボタン実行後にrisk/impactがrisk_conditionsの判定結果へ更新される
異常時の対応：手動運用を前提にするなら、保存前に必ずボタンを押す運用を周知する。自動化したいならプロパティをbusiness_ruleへ変更する（公式は非推奨）
復旧後確認：risk/impactの値と、Edit Risk Conditionsで条件式を変更していないかを確認する
恒久対策：リスク運用方針は開発設計書に引き継ぐ
確認順序
glide.ui.risk_calculate_ruleの値を見る（既定ui_action）
ui_actionなら「Calculate Risk」ボタンを手動で押した結果を見る
risk_conditions（4件）の条件式とorderを見直す
公式の説明は次のとおりです。
Recommended best practice is to use a UI Action to calculate risk on demand which is the default OOB behavior.
（訳：オンデマンドでリスクを計算するにはUI Actionを使うのが推奨される標準の挙動）
コンフリクトが検出されない
症状：同じCIを対象にした変更が重なっているはずなのに、コンフリクトの警告が出ない
影響範囲：change.conflict.assigned_to=false環境での担当者重複、および後から登録された側のChange
原因候補：①担当者の重複スケジュールチェックが既定off／②定期実行のスケジュールチェッカーも既定off・専用ジョブも無い／③自分側のChangeが再保存されない限りconflictレコードが作られない
正常値：同一CI・ブラックアウトウィンドウ・メンテナンス窓・関連サービスの4種は既定trueで動く
異常時の対応：担当者基準も必要ならchange.conflict.assigned_toを有効化する。後続の衝突は自分側の再保存か、定期チェックの仕組みで洗い出す
復旧後確認：conflictテーブルにレコードが生成されたかを確認する
恒久対策：コンフリクト検知の推奨設定はプロパティ巻に引き継ぐ
確認順序
change.conflict.assigned_toの値を見る（既定false）
change.conflict.refresh.scheduledの値を見る（既定false）
sysauto_scriptをnameLIKEconflictで見て、専用の定期ジョブが無いことを確認する
標準変更にできない
症状：新規作成画面でtypeにStandardを選ぼうとしても、選択肢が絞られていて選べない
影響範囲：新規作成画面からの直接起票のみ（テンプレート経由の起票には影響しない）
原因候補：①Standardモデルはavailable_in_ui=falseで新規作成画面に出ない設計（異常ではない）／②使いたい定型作業のテンプレートがまだ無い
正常値：該当テンプレートがあれば、そこから新規作成することでStandardのChange Requestが作れる
異常時の対応：テンプレートが無い場合はFlow「Change - Standard - Proposal」の承認を経て追加する
復旧後確認：std_change_proposalのstateがClosed（提案完了）になり、std_change_record_producerに新しいテンプレートが増えたかを確認する
恒久対策：テンプレート追加の運用ルールは運用手順書に引き継ぐ
確認順序
std_change_record_producerでactive=trueの一覧を見る（実測6件）
使いたい定型作業が含まれているかを確認する
無ければ「Propose a Standard Change Template」からテンプレート提案を起票する
プラグインの公式説明は次のとおりでした。
Change Management feature which allows Standard change templates to be proposed, approved, and published in the ServiceNow Service Catalog.
（訳：標準変更テンプレートをService Catalogで提案・承認・公開できるようにするChange Management機能）
参考：変更管理モジュールの概要 … 3種別の使い分け全体
通知メールが届かない
症状：Change Requestを承認・却下しても、担当者にメールが届かない
影響範囲：メール通知全体（生成と送信の両方に依存する）
原因候補：①通知定義自体が無効（このPDIは16件全件active）／②SMTP送信そのものが既定off／③宛先フィールドが空
正常値：sys_emailにレコードが生成され、typeが送信済み相当になっている
異常時の対応：glide.email.smtp.activeがfalseなら、本番相当の検証時にtrueへ切り替える。宛先が空なら通知定義のrecipient_fieldsを見直す
復旧後確認：対象の通知が実際に届き、sys_emailのstateが送信済みになっているかを確認する
恒久対策：通知の設計方針は運用設計書に引き継ぐ
確認順序
sysevent_email_actionのactive状態を確認する（このPDIは全件active）
sys_emailに該当メールが生成されているかを見る（生成無しなら通知定義の条件式を見直す）
生成済みならtypeを見る（送信待ちのまま残っていればSMTP設定の問題）
glide.email.smtp.activeはfalseでした。公式説明は「Email sending enabled」（訳：メール送信の有効化）です。
参考：メール通知が飛ぶまでの4段階（Notification） … 通知が届かないときの4段階
実機で気づいたこと
同じ「typeを守る」BRでも、値によってエラーの有無が変わる
order900「Prevent Type change to Standard」は明示エラーを出しますが、order300「Modify Change Type」はエラー無しで値を戻すだけでした。
保存が失敗してもメッセージが出ないと、利用者は反映されたと誤解します。ガード系BRを棚卸しするときは、abortの有無だけでなくエラーメッセージの有無まで確認します。
「自動」という言葉には前提条件がある
第6巻ではリスク計算の仕組み自体を扱いましたが、動くかどうかを決めるスイッチの値までは確認していませんでした。今回glide.ui.risk_calculate_ruleの既定値がui_actionだと分かり、保存時の自動計算は起きないと判明しました。
「仕組みがある」ことと「実際に動く」ことは別の話です。動作モードを決めるプロパティの値まで確認してから、利用者への案内に反映します。
必須化のBRは、分岐ごとに厳しさが揃っていない
Close時の必須化BR「Mandatory Closure Information」を全文確認しました。close_notesとclose_codeの不正値は保存を中断しますが、close_code自体が空のときだけ中断しません。
同じBRの中でも分岐ごとに強制力が異なる例です。「必須化されている」という説明だけで安心してはいけません。どの分岐がどこまで強制するかは、スクリプトで確かめます。
導入時の確認リスト
ここまでの内容を、導入時に確認する形にまとめました。
大半が「デフォルトでは動かない、または限定的にしか動かない設定」です。承認はFlow任せ、リスク計算は手動、コンフリクトはCI基準のみ。動かないことを前提に、必要なものだけを有効化していく進め方になります。
実務で順番に検討する箇所
導入直後の確認は、次の順序で進めます。
承認Flow：type別のFlowが有効かをまず確認する（Authorizeを持つ4モデルが対象）
Change Model：使うモデルにImplementなど必要な状態があるかを確認する
on_holdの運用：保留がChange Taskの保存全体を止める前提で手順を組む
typeの選定：初期状態のうちに確定し、後から直さない運用にする
Close時の入力：close_notesとclose_codeの両方を必須として運用する
リスク自動計算：手動運用のままでよいか、business_ruleへ切り替えるかを決める
コンフリクト検知：担当者基準も見たいなら個別に有効化する
標準変更テンプレート：既存6件で足りない定型作業を洗い出す
通知の送信経路：本番相当で試すならSMTP設定を先に確認する
用語
OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNowが無償で提供する個人検証用インスタンス
Change Model：typeごとの状態遷移とテンプレートを束ねる仕組み
sttrm_state：状態遷移モデルが使う状態定義テーブル。Change専用ではない
setAbortAction：Business Ruleから保存トランザクションそのものを中断させる呼び出し
検証範囲とおことわり
検証環境：Australia PDI / OOTB / 2026-09-03 確認（初回調査2026-09-01、外部レビュー対応の追加実測2026-09-03）
件数と設定値はすべてOOTBのものです。本番環境やカスタマイズ済み環境では異なります
各症状を実際に再現し、対処して直ることまでは確認していません。スクリプト・プロパティ・状態定義・sys_flow_contextの実測から原因を整理しています。sys_flow_contextの実測62件はすべてWAITINGで、ERROR・CANCELLEDの実例は確認できていません
PDIへの書き込みは行わず読み取りのみで調査し、Flow Designer内部のステップ単位の中身とドメイン分離環境での挙動差は確認していません
付録：自分の環境で確認するときのURL
承認Flow一覧：/sys_hub_flow_list.do?sysparm_query=nameLIKEChange^active=true^type=flow
Flow実行記録：/sys_flow_context_list.do?sysparm_query=source_table=change_request^ORDERBYstate
Change Modelの一覧：/sttrm_model_list.do?sysparm_query=table_name=change_request
typeを守るBR一覧：/sys_script_list.do?sysparm_query=collection=change_request^nameLIKEType
Close必須化BR：/sys_script_list.do?sysparm_query=collection=change_request^nameLIKEMandatory Closure
on_hold関連のBusiness Rule：/sys_script_list.do?sysparm_query=collection=change_task^nameLIKEon hold^active=true
リスク計算のスイッチ：/sys_properties_list.do?sysparm_query=name=glide.ui.risk_calculate_rule
コンフリクト関連プロパティ：/sys_properties_list.do?sysparm_query=nameSTARTSWITHchange.conflict
標準変更テンプレート：/std_change_record_producer_list.do?sysparm_query=active=true
SMTP送信の設定：/sys_properties_list.do?sysparm_query=name=glide.email.smtp.active
引用した公式説明を実機で確認する方法
引用元はいずれも製品同梱のプロパティ・プラグイン説明です。
プロパティ（引用元）：/sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.approval_engine
プラグイン（引用元）：/v_plugin_list.do?sysparm_query=id=com.snc.change_management.standard_change_catalog
関連記事
変更の流れを決める Change Model（chg_model） … type・状態遷移の前提になる仕組み
State Transition Models（sttrm_model）：変更タイプごとに状態遷移を定義する仕組み … Implementの有無を左右する遷移モデル
Flow Designerのフローが動かないときどこを見る？ 実行記録sys_flow_contextで切り分ける … 承認が止まったときの切り分け手順
