変更管理モジュールの概要

2026年8月9日 05:22

変更を1件通すのに、CABの承認が2段階必要になる場合と、承認そのものが発生しない場合があります。同じchange_requestというテーブルなのに、なぜ扱いが分かれるのでしょうか。ServiceNowの変更管理は、change_requestが持つtypeという1つのフィールドで、参照するChange Modelを切り替える設計です。Australia PDIをデフォルト設定のまま開き、テーブル・状態・type・ロールを確かめました。

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

この記事で分かること

変更管理がIncident・Problemとどう役割を分けているか
change_requestの1件が、どのテーブルに、どんな項目で保存されるか
typeの4値とChange Model 6件が、record_presetという仕組みでつながる構造
Standard・Normal・Emergency・Unauthorizedをどう使い分けるか
承認・CAB・リスク評価・コンフリクト検知が、どこに実装されているか

先に押さえておくこと

変更管理の目的は、リスクを抑えながら変更を安全に通すことにある
change_requestはtaskを親に持つ1テーブルで、固有39項目と継承71項目の計110項目で構成される
chg_model自体にはtype列が無く、record_presetというテンプレート文字列でtypeを注入する設計になっている

変更管理の位置づけ

実際の画面を先に見ておきます。承認待ちのNormal Changeです。

上端の状態バーで、いまAuthorizeにいることが一目で分かります。右列のModelとTypeはともにNormalです。この2つがどうつながっているかが、この記事の中心的な問いです。

変更管理の目的は、リスクを抑えながら変更を安全に通すことです。原因の調査を担うのはProblemです。日々の対応はIncidentが引き受けます。Changeは、決まった対策や計画済みの作業を、承認とスケジュールを経て本番へ反映する役割を担います。

3プロセスの関係を図にします。

IncidentからChangeへは、辞書上の参照フィールドを持ちません。UI Action「Create Change Request」を押した瞬間に、新しいChangeレコードが作られる形です。一方Problemは、rfcというフィールドでChangeを直接参照します。恒久対策が決まったProblemは、このフィールドを通じてChangeへつながります。

この違いは実務に効きます。Incidentからの起票経路を追跡したいときは、辞書上の参照フィールドをあてにせず、UI Actionのログや作成日時の近さで拾う必要があります。

参考：インシデント管理モジュールの概要 … IncidentからChangeへつながる手前の仕組み

change_request・change_taskの継承構造

change_requestとchange_taskは、ともにtaskを継承しています。実機のsys_db_objectで確認できます。

継承元を並べると、5つのテーブルの性格の違いが見えます。

change_request / change_task：Task
chg_model：Model（状態遷移モデルの派生）
std_change_producer_version：継承なし（単独テーブル）
cab_meeting：Meeting（CAB Workbench専用のスコープアプリに属する）

同じ変更管理という括りでも、土台になっている仕組みはテーブルごとに異なります。

chg_modelがModelを継承している点は運用設計に効きます。Model系のテーブルは更新セットで他の環境へ運べる区分に属するため、開発環境で作ったChange Modelを本番へ移送できる作りです。

参考：taskテーブル：ITSM全プロセスの共通の親 … 共通項目の側から知りたいときに読む

公式のフィールド説明（sys_documentation）

ServiceNowは製品の中にフィールドの説明文を同梱しています。sys_documentationのhintです。change_requestとchange_taskで22件の説明がありました。

実務に有効な unauthorized の説明を紹介します。

Change activity detected without prior authorization. To unset this field create an Outage of type Outage or Degradation.

（訳：事前承認なしの変更活動を検知した状態。解除するにはOutageまたはDegradation種別のOutageレコードを作成する必要がある）

unauthorizedは承認外の変更を検知したときに立つフラグで、解除の手順まで公式説明に書かれています。無許可の変更を検知したら、Outageレコードを作ることが解除の条件です。

phaseの説明はこうです。

Dependent on Category value

（訳：Categoryの値に依存する）

「Categoryの値に依存する」としか書かれていません。どのCategoryでどのphaseになるかは、この一文だけでは分かりません。実機のデータかスクリプトの中身を確認する必要があります。

引用元：/sys_documentation_list.do?sysparm_query=nameINchange_request,change_task^hintISNOTEMPTY

フィールド構成

sys_dictionaryを数えると、change_request固有が39項目、change_task固有が8項目でした（システムが自動生成するsys_id等を除く）。

taskから継承する71項目と合わせると、change_requestは110項目、change_taskは79項目で構成されます。

change_request固有39項目のうち、運用で意味を持つものを挙げます。

backout_plan：切り戻し手順
implementation_plan：実施の逐次手順。依存関係と担当者も記入する
risk_impact_analysis：想定リスクと影響
cab_date / cab_delegate / cab_recommendation：CABの日時・代理出席者・勧告
unauthorized：無許可変更の検知フラグ
exclude_from_conflict_detection：コンフリクト検知の対象外指定
conflict_status / conflict_last_run：コンフリクト検知の実行結果と最終実行日時
phase / phase_state：Categoryに連動する進行段階

実施手順・リスク分析・切り戻し手順の3項目が最初から揃っています。監査で必ず問われる項目が、フィールドとして用意されている作りです。

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

change_task固有は8項目にとどまります。change_request（参照）・change_task_type・created_from・on_hold・on_hold_reasonなど、実施の分担に必要な最小限です。stateやassigned_toはtask側の継承にあたります。

93項目に絞ったIncidentと比べると、Changeの固有項目はより多く、承認・リスク・CABという固有の関心事がフィールド設計に反映されています。

状態は8つ、Modelごとに使う数が違う

sys_choiceでstateの選択肢を確認すると8件でした。すべて有効です。

valueは-5から始まり4まで続きます。負の値を使うのはIncidentやProblemの標準stateと番地が衝突しないためです。

この8つはフィールド全体の選択肢です。実際にどの状態を通るかはChange Modelが決めます。この対応関係は次の節で扱います。

typeとChange Modelの関係

change_requestにはtypeというフィールドがあり、4つの値を持ちます。standard・normal・emergency・modelです。この値がどのChange Modelを参照するかを決めます。

実機のchg_modelは6件です。type選択肢は4つしかないため、数が一致しません。ここに、この記事でいちばん確かめたかった仕組みがあります。

chg_modelという辞書を調べても、typeという列は存在しません。typeを注入しているのはrecord_presetというテンプレート文字列です。

record_presetの中身を見ると、Normalはtype=normal^EQ、Standardはtype=standard^EQという文字列がそのまま入っています。typeという値は、chg_modelという別のテーブルの1フィールドに、新規作成時のテンプレートとして書き込まれる形で決まります。テンプレート文字列から都度注入される値です。

Standard・Normal・Emergencyという名称は、ITILの変更プロセス区分そのものです。chg_modelのitil_change_processというフィールドに、公式の説明が書かれています。

The ITIL Change Process (Standard, Normal, Emergency) this model is used for. Only one active model can be selected for each of the processes.

（訳：このモデルが対応するITILの変更プロセス（Standard、Normal、Emergency）。各プロセスに対して選択できるアクティブなモデルは1つだけである）

プロセスごとに選べるアクティブなモデルは1つに限られます。Normal用のモデルも常に1件だけです。自社でChange Modelを追加するときは、この1対1の制約を踏まえて、既存の3モデルとの役割分担を先に決めます。

引用元：/sys_documentation_list.do?sysparm_query=name=chg_model^hintISNOTEMPTY

種別ごとの役割と動きは、次の節で1つずつ確かめます。

変更種別ごとの適用基準と選定ルール

4つの種別を選ぶ基準を1枚の表にまとめます。新しいChangeを起票する際、どの種別を選ぶかを判断する目的で使う表です。状態の数は、Change Modelごとにsttrm_stateを数えて確認しました（2026-09-01実測、有効な状態のみ）。

表から読み取れる重要事項は、状態数の差がそのままリードタイムの差になる点です。状態が多いほど評価・承認の工程が多く、実施までの日数が伸びます。Standardだけは新規作成画面に出てこないため、Change Modelの一覧を眺めるだけでは選べません。

4つを選ぶ軸は、①緊急性（いま止めなければ被害が広がるか）②事前承認の可否（作業前に通常の審査時間を確保できるか）③事後レビューの要否（先に実施し、あとから承認と記録を残す運用を許容するか）の3つです。影響の大きさだけで選ぶと判断を誤ります。「障害対応だから常にEmergency」という判断も誤りです。障害対応であっても、通常のリードタイムを確保できるならNormalを使います。

種別ごとの選定条件・選定してはいけない条件・誤選定時の影響を、次に1つずつ示します。

Normal Change

影響が読み切れない変更や、複数チームの調整が要る変更を、CABの承認に載せて通すルートです。既定モデル（default_change_model=true）でもあります。

状態は8つです。New→Assess→Authorize→Scheduled→Implement→Reviewと進み、Closedで完了します（Newからの中断はCanceledへ分岐）。AssessとAuthorizeの2段階があり、Assessで影響を評価し、Authorizeという状態でCABが承認します。承認の実処理を担うのはFlow Designerです。専用フローはAssess・Authorize・Implementの3フェーズに1つずつ用意されています（Change - Normal - Assess／Authorize／Implement）。

冒頭で見たCHG0000076は、このNormal ChangeがAuthorize状態にある実例です。available_in_ui=trueで、通常の新規作成画面から起票できます。

状態の流れと、各段階の実施役割を図にします。

選定条件：影響評価が必要で、かつ通常のリードタイム（実施まで数日以上の猶予）を確保できる変更
選定してはいけない条件：障害の影響をいますぐ止める必要がある変更（Emergencyを選ぶ）、承認済みテンプレートに完全一致する定型作業（Standardを選ぶ）
誤選定時の影響：定型作業をNormalに乗せると不要なCAB審査で実施が数日から数週間遅れます。評価が必要な変更をEmergencyへ回すとAssessを経ないまま実施され、二次障害のリスクを負います
具体例：複数チームが関わるネットワーク構成の変更、影響範囲が読み切れないミドルウェアのバージョン変更

Standard Change

承認済みのテンプレートに一致する定型作業を、都度の審査なしで通すルートです。

新規作成画面には出てきません（available_in_ui=false）。起票の入口はstd_change_producer_versionという標準変更テンプレートで、実機には6件登録されています。状態は6つで、AssessもAuthorizeも持ちません。承認という工程自体は消えておらず、テンプレートを作る段階の審査に前倒しされているだけです。専用フローは3つあります（Change - Standard／Change - Standard - Proposal／Change - Standard - Implement）。このうちProposalの承認が、テンプレート側の審査にあたります。

個々のChangeを起票するたびの承認レコードは作られません。

状態の流れを図にします。テンプレート審査という別系統の工程が、New状態の手前にある点が特徴です。

選定条件：過去に承認されたテンプレートと内容が完全に一致する、反復可能な定型作業
選定してはいけない条件：テンプレートに存在しない変更、過去の実施内容と少しでも異なる変更（Normalを選ぶ）
誤選定時の影響：テンプレートと異なる内容をStandardで通すと個々のChangeでは審査が働きません。未評価の変更が無審査のまま本番へ反映されます
具体例：定期パッチ適用、承認済み手順に沿ったディスク拡張作業

Emergency Change

すでに発生している障害の影響を先に止め、承認の記録を後から残すルートです。

状態は7つで、Normalの8状態からAssessだけを除いた形になります。省略されているのは評価の手順で、Authorizeという承認の状態そのものは残ります。専用フローはAuthorize・Implement・Reviewの3フェーズに1つずつ用意されています（Change - Emergency - Authorize／Implement／Review）。

available_in_ui=trueで新規作成画面からも起票できます。実務では障害対応の最中にまず作業を進め、Authorizeで事後承認を受ける使い方になります。

状態の流れを図にします。Assessが抜け、New直後にAuthorizeが来る点がNormalとの違いです。

選定条件：障害がすでに発生しており、通常のリードタイムでCAB承認を待つと被害が拡大する変更
選定してはいけない条件：まだ発生していない予防的な変更、通常のリードタイムを確保できる変更（Normalを選ぶ）
誤選定時の影響：緊急性のない変更をEmergencyで通すとAssessによる影響評価を経ないまま本番へ反映されます。多用はCABの事後レビュー負荷も増やします
具体例：本番障害の切り分けで判明した設定ミスの緊急修正

そのほかのモデル

Unauthorized Change：事前承認を経ずに実施が検知された変更を、事後に追跡するモデルです。typeの選択肢に独自の値は無く、type=emergencyにunauthorized=trueという真偽値フラグを重ねた組み合わせで表現されます。状態はわずか3つで、New（受付）を経由しません。専用フローは「Change - Unauthorized - Authorize」「Change - Unauthorized - Review」です。

状態の開始点は数値の並びだけでは判断できません。sttrm_stateのinitial_stateフラグを確認すると、実際の初期状態はReview（値0）でした。Authorize（値-3）は数値こそ小さいものの、initial_stateはfalseです。無許可変更を検知した時点でまずReviewへ入り、そこからCABが事後承認の可否を判断してAuthorizeへ進む流れになっています。

Unauthorizedは、事後に検知された結果として付く状態です。件数が増える場合は、Emergencyを使うときの事前申請ルール（誰が・いつ承認者へ連絡するか）が徹底されていないサインとして扱います。正当な緊急対応までUnauthorizedとして記録され続けると、監査で「無許可変更が多い組織」と評価されるリスクを負います。

Change Registration・Cloud Infrastructure：どちらもtype=modelを使う自動化専用のモデルです。available_in_ui=falseのため、通常の新規作成画面には出てきません。record_presetにはそれぞれshort_description=Automated : Changeや連携先のassignment_groupがあらかじめ書き込まれており、API経由や連携ツール経由での起票を想定した区分です。Cloud Infrastructureには専用フロー「Change - Cloud Infrastructure - Authorize」が用意されています。人が新規作成画面から選ぶ種別ではないため、選定条件の検討対象から外れます。

設計例

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

定型かつ反復可能で、事前承認済みのテンプレートに一致する変更 → Standard
影響評価が必要で、通常の承認プロセス（CAB）を通せる時間がある変更 → Normal
通常のリードタイムを確保できない、緊急性の高い変更に限り → Emergency
承認を経ずに実施が検知された変更は、事後の統制対象としてUnauthorizedで扱う

承認の仕組みを概観する

承認・CAB・リスク評価・コンフリクト検知という4つの仕組みが、種別ごとの状態遷移を横断的に支えています。詳細は後続の巻に譲り、ここでは実在の確認だけを示します。

sysapproval_approverは、change_requestに紐づくものが732件ありました（requested 376・not_required 290・approved 66・rejected 0）。承認の実処理を担うのはFlow Designerで、旧来のApproval Rulesエンジンはglide.approval_engine.change_request=offのとおり使われていません。

参考：承認（Approval）運用手順書 … 承認そのものの操作手順

種別ごとの専用フローは前節のとおりです。承認の合議はCABが担います。

CABの会議体はcab_meetingというテーブルに6件登録されています。全件Pendingでした。会議進行を伴わない承認だけの運用も可能で、CAB Workbenchという機能そのものは任意です。

リスクの算出はrisk_conditionsという4件の条件とScript Include RiskCalculatorが担い、質問票方式のRisk Assessmentプラグインは無効のため条件ベースの計算だけが動いています。コンフリクト検知はconflictテーブルとFlow「Change - Conflict Detection」が稼働可能な状態で待機していますが、デモデータでは実例がありません。

参考：グループ承認：N人を1つに束ねる仕組み（sysapproval_group） … 承認の基本機構を先に知りたいときに読む
参考：CAB Workbench（/cab）の入口はカレンダー1枚：ウィジェットも1個だけ … CAB Workbenchの画面構成

変更管理を構成するOOTB資産とカスタマイズ影響範囲

change_requestとchange_taskの動きは、テーブルの外に置かれた設定の集まりが支えています。どの種類の設定がどれだけあるかを把握し、自社でカスタマイズするときにどこから手を付けるかを判断する目的で、テーブル別に数えました（2026-09-01実測、有効なレコードのみ）。

表から読み取れる重要事項は、ACLとビジネスルールの多さです。change_requestのACLは72件、ビジネスルールは81件で、Incidentのビジネスルール38件と比べても倍以上あります。承認・リスク・CABという固有の関心事を、フィールドだけでなく処理の量でも支えている構造です。SLA定義（contract_sla）は0件で、利用者への期限を約束する仕組みは標準で入っていません。期限の管理はCABのスケジュールとImplementの計画日で行う設計です。

新しい制御をどこに追加するかで迷ったときの判断表です。

サーバー側で必ず強制したい制約：ビジネスルールまたはデータポリシーに実装します。フォーム経由だけでなく、Flow・REST API経由の更新にも同じ制約が及びます
画面上の入力可否や表示・非表示だけを変えたい：UIポリシーに実装します。サーバー側の値は変わらないため、API経由の更新までは制約しません
誰が読み書きできるかを制御したい：ACLに実装します。ロールとレコード条件（condition）の組み合わせで判定されます
利用者の操作の起点（ボタン）を追加・変更したい：UIアクションに実装します。表示条件はスクリプトで判定します
承認や複数ステップの処理を新設・変更したい：Flow Designerに実装します。旧来のWorkflowエンジンはglide.approval_engine.change_request=offのとおり使われていません

変更時に確認する優先順位は、影響範囲の広さで決めます。①状態遷移に関わるビジネスルール（Change Modelの中核処理）②承認Flow ③ACL ④UIポリシー・UIアクションの順です。①②はサーバー側の処理そのものを変えるため、変更後は必ずAssessからClosedまで1件のChangeを通しで動かして確認します。③④は画面や権限の見た目に閉じるため、対象ロールでのログイン確認で足ります。

ビジネスルール

保存ボタンを押すと、サーバ側では複数の処理が順に実行されます。この処理の置き場がビジネスルール（sys_script）です。

order順では、前半（40〜100）にChange Modelの中核処理が集まります。type別の自動設定・状態遷移検証・フィールドの読み取り専用化・リスクの自動計算・CAB議題との承認同期です。末尾（300〜999）には、ENFORCE_DATA_REQ_PROPを条件とする必須化・読み取り専用化のルールが集まります。フォームだけでなくFlow・API経由の更新にも同じ制約が及ぶ設計です。change_taskの19件はon-hold連動が中心で、親のchange_requestが保留になると子の状態変更を止めます。各ルールの中身は本シリーズ第6巻「変更管理モジュールの自動設定構成」で扱います。

通知

Changeの状態が変わると、条件に合う通知がメールを送ります。定義の置き場はsysevent_email_actionです。

16件のうち3件はon_holdの変化（発生・解除・状態変化）に反応し、依頼者（requested_by）へ通知します。「Unauthorized change created」だけはイベント名にantivirus.infectedという無関係な名前を流用しており、導入時はこの1件の条件と宛先を確認しておく方が安全です。

UIアクション（ボタン）

フォーム上のボタンは、sys_ui_actionにレコードとして定義されています。

Request Approval・Implement・Review・Close・Schedule・Cancel Changeは、すべてChangeFormUI(current).isXxx()という統一パターンで表示条件を判定します。Request Approvalが「CAB」と「Assess」に分かれる点は、承認がCAB・Assessの2段階であることの表れです。change_taskのUIアクションは2件（Assign to me、Close Task）のみで、change_requestの28件より著しく少ない数です。状態変更はフォーム直接編集かビジネスルール側の制御に委ねます。

変更管理の権限モデルと最小権限設計

誰が何を操作できるかは、ロールとACLの2段で決まります。利用者区分ごとにどのロールを割り当てるべきかを判断する目的で、専用ロールの構成を確認しました。

表から読み取れる重要事項は、専用ロールが7件と、Incidentの6件より1つ多い点です。差分は「自分に割り当てられたChange Taskだけにアクセスできる」sn_change_task_assigned_userと、Change Schedule画面専用の管理者ロールsn_chg_soc.change_soc_adminの2つになります。担当者ごとの守備範囲を細かく分けて管理できます。

itil・sn_change_write・change_managerの境界

標準のitilロールを持つ担当者は、追加設定なしでsn_change_write（連鎖してsn_change_read）を持ちます。itilを持たない外部委託先など、変更管理だけに限定したアクセスを与えたい場合に限り、sn_change_writeを単独で付与します。change_managerは、承認・CAB運営に関わる操作を追加する別軸の権限です。実施担当者に安易に重ねて付与しません。

利用者区分ごとの推奨付与

一般申請者（変更を起票するだけの利用者）：itilのみで足ります。change_managerやsn_change_adminは付与しません
実施担当者（Change Taskの実施のみ）：sn_change_task_assigned_userを付与します。担当外のChangeへの書き込み権限が不要に広がるため、sn_change_writeは重ねません
変更管理者（CAB運営・承認判断）：change_managerをグループ経由で付与します。個人への直接付与は、担当交代時に権限が残る原因になります
CAB運営者（会議体の運営のみで承認判断は行わない）：sn_change_cab.cab_manager単体で足り、change_managerとは重ねません
設定管理者（Change Model・状態遷移の設定変更）：sn_change_adminをグループ経由で付与し、日常の運用担当者には持たせません

禁止する組み合わせ

change_managerとsn_change_task_assigned_userを同一利用者に付与しません。承認者が自分の実施タスクを承認する構図になり、職務分離が崩れます。sn_change_adminも一般の変更管理者へ広く付与しません。Change Modelや状態遷移の設定変更まで許可範囲が広がります。

ACL側では、change_taskに素のconditionを持つACLが15件あります。その大半は「担当者は自分」という条件で、sn_change_task_assigned_userロールの実体的な権限定義にあたります。ロールを付けるだけでなく、レコード側の条件も権限を決めている点は、権限のトラブルを切り分けるときの手がかりです。

各ロールの守備範囲とACL 72件の内訳は、本シリーズ第3巻「変更管理モジュールのロール」で扱います。

change_requestを参照しているテーブル

sys_dictionaryでchange_requestを参照しているフィールドを検索すると98件が該当します。

内訳を見ると、82件はFlow Designerの内部変数テーブル（var__m_で始まる自動生成テーブル）でした。実テーブルは16件だけです。

change_task.change_request：change_taskからの参照
problem.rfc：Problemからの逆参照（恒久対策としての起票）
release_feature.rfc / release_rfcs.rfc：リリース管理側からの参照
conflict.change / conflict.conflicting_change：コンフリクト検知の対象ペア
chg_policy_applied.change_request：適用されたChange Policyの記録

incidentは、この16件のどこにも現れません。incident側にはrfcという名前のフィールドがありますが、sys_dictionaryやREST APIのフィールド一覧からは見えない隠しフィールドで、rfcISNOTEMPTYという条件を付けても全件がそのまま返ります。ACLとプロパティにはrfcという名前の痕跡が残っていますが、能動的にスクリプトで使われている形跡はありません。Incidentから変更を起票する経路は、辞書上の参照ではなくUI Actionという操作の形で用意されています。

参考：変更管理モジュールのテーブル・フィールド構成 … change_requestのフィールド1つ1つを追う
参考：変更の流れを決めるChange Model（chg_model） … chg_modelの詳細
参考：State Transition Models（sttrm_model）：変更タイプごとに状態遷移を定義する仕組み … sttrm_stateの遷移定義そのものを追う

実機で気づいたこと

chg_modelにtype列が無い

typeの選択肢は4つ、chg_modelのレコードは6件です。数が合わないので、最初はどこかに対応表があるはずだと考えました。

実際にchg_modelの辞書を開くと、type列そのものが存在しません。typeを決めているのはrecord_presetというテンプレート文字列で、新規作成時に一度だけ書き込まれます。値の対応関係は、フィールドの参照ではなく、テンプレートの中身として実装されています。

chg_modelが6件に対し、typeの選択肢はこの4件だけです。自社でChange Modelを追加するときは、このrecord_presetの書式を先に確認します。値の対応をどこか別のマスタで管理していると誤解すると、新モデルの追加で必ずつまずきます。

テンプレートの審査を厳しくすれば足りる

Standardの状態にAssessもAuthorizeも無いのを見て、承認そのものが不要なルートだと最初は考えました。

実際には、承認のタイミングがテンプレート作成側（std_change_proposalの審査）に前倒しされているだけでした（仕組みの詳細は「Standard Change」の節）。審査の対象が、Changeからテンプレートへ移っているだけです。

Standardを増やす運用を検討するときは、個々のChangeよりも、テンプレートの審査プロセスを厳しくする対応が必要です。

Unauthorizedの集計はtypeだけでは絞れない

typeの選択肢一覧にunauthorizedという値は無いため、最初は独自の種別が別にあると考えていました。

実際にはtype=emergencyにunauthorizedという真偽値フラグを重ねた組み合わせでした（仕組みの詳細は「そのほかのモデル」の節）。

無許可変更の集計をしたいときは、type=emergencyのレコードからunauthorized=trueで絞り込む必要があります。typeだけを条件にすると、通常のEmergencyと混ざってしまいます。

実務で順番に検討する箇所

変更管理を新しく設計するとき、確認する順序を決めておくと迷いません。

type別の判断基準：テンプレートに一致するか、障害がすでに起きているかを先に問い、それでもなければNormalへ進む順番を決める
Change Modelの状態集合：自社の運用にAssess段階が必要かどうかを、既存6件を参考に決める
リスク条件：既定の4件を、自社のCI構成や運用に合わせて追加・修正する
CABの運用：会議体を伴う承認にするか、承認レコードだけで完結させるかを決める
通知16件の取捨：宛先と条件を1件ずつ確認し、自社の運用に合わないものは調整する
コンフリクト検知の有効化：既定でオフの項目（担当者の重複など）を確認し、必要なら有効化する

各項目の詳細設定は、本シリーズ第4巻「変更管理モジュールのプロパティ」・第5巻「変更管理モジュールの基本設定」で扱います。

用語

OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNowが無償で提供する個人検証用インスタンス
CAB：Change Advisory Board。変更の実施可否を協議する承認会議体
record_preset：Change Modelが新規レコード作成時に注入する、変更不可のテンプレート値
ACL：Access Control List。どのロールがどのテーブル・項目を読み書きできるかの規則

検証範囲とおことわり

検証環境：Australia PDI / OOTB / 2026-09-01 確認
件数はすべてOOTBの設定・定義の数です。本番環境やカスタマイズ済み環境では異なります
Change Modelごとの状態集合はsttrm_stateの件数から確認したもので、遷移条件そのものの中身までは追っていません
ACL 72件の内訳、承認Flowの内部ロジック、実際の起票からクローズまでの操作は、このシリーズの後続記事で扱います
業務レコードの分布（どの状態に何件あるか）はデモデータ固有のため、本記事では扱っていません
Change Registration・Cloud Infrastructureという自動化専用の2モデルは、通常の新規作成画面に出ないため本記事では深く扱っていません

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

テーブル定義：/sys_db_object_list.do?sysparm_query=nameINchange_request,change_task,chg_model
フィールド定義：/sys_dictionary_list.do?sysparm_query=name=change_request^elementISNOTEMPTY
状態の選択肢：/sys_choice_list.do?sysparm_query=name=change_request^element=state^language=en
typeの選択肢：/sys_choice_list.do?sysparm_query=name=change_request^element=type^language=en
Change Model一覧：/chg_model_list.do
ビジネスルール：/sys_script_list.do?sysparm_query=collection=change_request
通知：/sysevent_email_action_list.do?sysparm_query=collection=change_request
UIアクション：/sys_ui_action_list.do?sysparm_query=table=change_request
ロール：/sys_user_role_list.do?sysparm_query=nameLIKEchange^ORnameLIKEchg^ORnameLIKEcab
ACL：/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHchange_request
承認Flow：/sys_hub_flow_list.do?sysparm_query=nameSTARTSWITHChange^active=true
CAB会議：/cab_meeting_list.do

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

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

フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINchange_request,change_task^hintISNOTEMPTY
プロパティの状態（引用元）：/sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.approval_engine

taskテーブル：ITSM全プロセスの共通の親 … Changeの親テーブルを先に知ると、110項目の内訳がつかみやすくなる
変更の流れを決めるChange Model（chg_model） … record_presetを含むchg_model自体をさらに詳しく追う
State Transition Models（sttrm_model）：変更タイプごとに状態遷移を定義する仕組み … 状態遷移の定義そのものを実機で追う