変更の流れを決める Change Model（chg_model）
前回の Change Request 記事で、「type（Normal / Standard / Emergency）ごとに承認や流れが変わる。その流れを定義しているのが Change Model（chg_model）だ」と書きました。この記事では、Change Model が具体的に何を指すのか、どんなテーブルで、どこに何が書いてあるのかを確認します。前回の続きです。
この記事では、Change Model をプロセス論ではなく実テーブルから読み解きます。具体的には次を確認します。
chg_model テーブルの継承（どこから来たテーブルか）
固有フィールド
本PDIに登録された6つのモデル（内訳は本文で確認します）
各モデルが持つ状態の数
change_request.chg_model との関係
この記事は、ServiceNow の Change Request のテーブル構造（task 継承・State・type）はひととおり押さえたことを前提にしています。想定する読者は、「type ごとに流れが違うのは、いったいどこで定義されているのか」という疑問を持った管理者・開発者です。実機で確認するときに見るべきポイントは、chg_model の継承・フィールド・6モデル・状態モデル系テーブル（sttrm_*）の所在です。
この記事で分かること
Change Request がたどる状態モデルの起点が chg_model テーブルであること（承認や遷移条件の内部定義は chg_model 単体では完結しないこと）
chg_model が sttrm_model（State Transition Model＝汎用の状態遷移モデル）を継承していること
本PDIに登録された6つの Change Model と、それぞれの属性（既定 / Create New 表示 / 状態数）
chg_model と change_request.chg_model（Reference）の関係
今回の PDI で確認できた状態モデル系テーブルが sttrm_*（sttrm_state / sttrm_state_transition）であること
実機で確認するときに見るべき一覧URL
この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、モデル構成・フィールド・状態の数・関連設定の内容が異なる場合があります。
Change Model（chg_model）とは
Change Model（変更モデル）とは、「ある種類の変更が、どんな状態をたどり、どこで承認を通すか」をひとまとめにした定型フローの定義です。Change Request 1件は、起票時にいずれかの Change Model に結びつき、そのモデルが定めた状態の流れに沿って進みます。
参考: State model and transitions。状態と遷移を定義する仕組みが公式ドキュメントで説明されています。
前回見たとおり、Change Request は type（Standard / Normal / Emergency / Model）という分類を持っていました。ただし type は「大まかな分類のラベル」であって、実際の状態の流れや承認の入り方を持っているのは type そのものではなく、type に対応する Change Model です。本PDIの OOTB では、この Change Model が chg_model というテーブルに、1モデル＝1レコードとして登録されていました。
つまり、「type ごとに流れが違う」という前回の話の出発点は、chg_model テーブルにあります。change_request は chg_model を参照し、chg_model は状態の集合（後述の sttrm_state）を持つ、という構造です。
ただし、Change Model は Change Request がたどる状態モデルの「起点」です。承認の詳細・UI Action・遷移条件・Flow / Business Rule といった内部処理までは、chg_model 単体で完結するわけではありません。この記事では chg_model と sttrm_state から確認できる「どのモデルがどの状態を持つか」までを扱い、遷移条件や承認の内部定義には踏み込みません。
今回確認した PDI（Zurich / OOTB）では、change_request の chg_model フィールドは chg_model テーブルへの Reference でした。画面上のラベルは「Model」で、参照先のレコードを指す項目です。1件の Change が「どのモデルに従うか」を、この参照で保持します。
Change Model の一覧は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。
https://<YourInstance>/chg_model_list.do?sysparm_query=active=true
chg_model の継承（State Transition Model の特化版）
chg_model のテーブル定義（sys_db_object）を見ると、chg_model は単独で生まれたテーブルではなく、より汎用的なテーブルを継承していることが分かります。
今回確認した PDI（Zurich / OOTB）では、chg_model は sttrm_model（State Transition Model＝状態遷移モデル）を継承していました。その sttrm_model はさらに sys_metadata（Application File）を継承していました。
ここがポイントです。chg_model は「変更管理専用の特別なテーブル」ではありません。ServiceNow が持つ汎用の「状態遷移モデル（sttrm_model）」を、変更管理向けに特化したものでした。
汎用の枠組みは親の sttrm_model 側にあります。どのテーブルにモデルを当てるか（table_name・既定 task）、どのフィールドを状態に使うか（state_field・既定 state）、有効か（active）、といった部分です。chg_model 側には Change らしい項目（既定モデルか / Create New に出すか / 色 / 実施とみなす状態）が足されていました。
なお、chg_model は前回の change_request（task 系）とは別系統です。change_request が「作業」を表す task 系のテーブルだったのに対し、chg_model は change_request が参照する「設定（メタデータ）」側のテーブルです。両者は Reference（change_request.chg_model）で結びつきます。
テーブルの定義は、次のURLで確認できます。
https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=chg_model
chg_model の主なフィールド
chg_model のフィールドは、大きく2つに分けられます。継承元 sttrm_model 由来の「どこに・何を状態として適用するか」という枠組みと、chg_model 固有の「画面表示・既定・実施状態」です。ラベルは画面上の表示名で、実機どおり英語で記載します。
フィールド ラベル 型 役割
--------------------------------------------------------------------------------
table_name Table name table_name（既定 task） このモデルが適用されるテーブル。6モデルとも change_request
state_field State field choice（既定 state） 状態を保持するフィールド。6モデルとも state
active Active boolean モデルの有効/無効
name Name translated_text モデル名（Normal / Emergency …）
default_change_model Default change model boolean 既定モデルか（Normal のみ true）
available_in_ui Available in 'Create New' boolean Create New 画面に出すか
color Color color 画面表示色
implementation_states Implementation states glide_list → sttrm_state 「実施」とみなす状態
description Description translated_text 説明
record_preset Record preset template_value レコード生成時のプリセット押さえておきたい3フィールド
特に押さえておきたいのは次の3つです。
table_name / state_field … 継承元 sttrm_model のフィールドで、モデルをどのテーブルのどのフィールドに適用するかを決めます。今回確認した6つの Change Model は、いずれも table_name=change_request、state_field=state でした。つまり全モデルが「change_request の state を進める」ためのモデルです。
default_change_model … そのモデルが既定モデルかどうかを表す boolean です。今回の PDI で true だったのは Normal だけでした。
available_in_ui（Available in 'Create New'） … モデルを Create New（新規作成）画面に出すかどうかを表します。今回の PDI では Normal / Emergency だけが true で、Standard やその他は false でした。
なお継承元 sttrm_model には、状態管理以外のフィールドもありました。read_roles / write_roles / advanced_security というアクセス制御系のフィールドです。今回の6モデル比較では扱いませんが、ロールで読み書きを制御する余地があることが分かります。
全フィールドは、次のURLで一覧できます。
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=chg_model^elementISNOTEMPTY
本PDIの6つの Change Model
今回確認した PDI（Zurich / OOTB）では、chg_model に6件のモデルが登録されており、いずれも active=true でした。
参考: Change Models（Activate Change Management）。Change Model をどう有効化し、どう作るかがまとまっています。
3グループの分け方
6モデルは3グループに分けると分かりやすくなります。
Create New（新規作成）画面に出るもの … Normal / Emergency
テンプレ経由で使うもの … Standard
Create New に表示されないもの … Change Registration / Cloud Infrastructure / Unauthorized Change
各モデルの属性は次のとおりです。
モデル名 既定 Create New 表示 状態数 位置づけ（今回のOOTBでの観察）
-----------------------------------------------------------------------------------
Normal ○ ○ 8 リスク評価＋CAB承認を通す標準的な変更。既定モデル
Emergency － ○ 7 緊急変更。ECAB で簡略承認し先に実施、事後レビュー
Standard － － 6 事前承認済みの定型変更。テンプレ経由で作成
Change Registration － － － Create New 非表示（用途・経路は未確認）
Cloud Infrastructure － － － Create New 非表示（用途・経路は未確認）
Unauthorized Change － － － Create New 非表示（用途・経路は未確認）各モデルの位置づけ
Normal … 既定モデル（default_change_model=true）で、Create New にも出ていました。状態は8つで、前回の change_request の State と一致します（詳細は後述）。
Emergency … Create New に出ていました。状態は7つで、Normal より1つ少ない構成でした。
Standard … Create New には出ません（available_in_ui=false）。Standard は事前承認済みの定型変更をテンプレ（std_change_record_producer）から作る前提のため、通常の新規作成画面ではなくテンプレ経由で使う構成です。状態は6つでした。
Change Registration / Cloud Infrastructure / Unauthorized Change
いずれも available_in_ui=false で、Create New 画面には表示されないモデルです。名前から用途は推測できます（既存変更の登録・クラウド基盤の変更・未承認変更の記録）。ただし、どの経路で使用されるか、どの処理から参照されるかは本記事では確認していません。
注意したいのは、「6モデルすべてが日常的に新規作成で使われるわけではない」点です。画面から手で起票するときに選べるのは Create New に出る Normal / Emergency が中心で、残りはテンプレや特定の自動処理から使われます。モデルの存在＝日常運用での選択肢、ではないことに注意します。
状態モデルの実体（sttrm_state / sttrm_state_transition）
先に結論を書くと、状態の集合は sttrm_state、遷移は sttrm_state_transition という専用テーブルにありました（chg_model 本体ではありません）。
Change Model が「状態の流れ」を持つと言いましたが、その状態の集合と遷移は chg_model テーブルの中にあるわけではありません。専用の状態モデル系テーブルに、1状態＝1レコード、1遷移＝1レコードとして保存されます。
今回ここで確認できたことがあります。今回確認した PDI（Zurich / OOTB）では、状態モデル系の実体は sttrm_*（State Transition Model）ファミリでした。sys_db_object を sys_cd 前方一致で確認した範囲では、sys_cd_* 系の状態モデルテーブルは見つかりませんでした（該当0件）。ServiceNow はリリースやプラグイン構成で内部テーブルが変わることがあるため、ここでは「Zurich PDI で確認できた sttrm_* を対象に説明する」という立場で扱います。
状態モデル系テーブルの一覧
主な状態モデル系テーブルは次のとおりです。
sttrm_model（State Transition Model） … モデル本体。chg_model の継承元。
sttrm_state（Model State） … モデルが持つ状態。どのモデルの状態かは sttrm_model（Reference）で結びつきます。
sttrm_state_transition（Model State Transition） … 状態遷移。from_state / to_state（→sttrm_state）と automatic（自動遷移か）を持ちます。
sttrm_transition_condition / sttrm_condition_type ほか … 遷移の条件を定義するテーブル群。
モデル別の状態数
各モデルの状態数を sttrm_state で数えると、今回の PDI では次のとおりでした。
テーブル 物理テーブル 件数 補足
----------------------------------------------------------------------------
Change Model chg_model 6（全て active） Normal/Emergency/Standard/Change Registration/Cloud Infrastructure/Unauthorized Change
State Transition Model sttrm_model 9 chg_model 6 ＋ 他テーブル用 3
Model State sttrm_state 43 モデル横断の合計（Normal 8/Emergency 7/Standard 6 等）
Model State Transition sttrm_state_transition 65 モデル横断の合計。モデル別内訳は確認範囲外
Standard Change Template std_change_record_producer 6 Standard を生成するテンプレ
Change Request change_request 102 変更レコード本体（参考）Normal は8状態、Emergency は7状態、Standard は6状態でした。sttrm_state はモデル横断で合計43件、sttrm_state_transition は合計65件です。ただし、遷移の中身は本記事では確認範囲外とします。ここでいう遷移の中身とは、どの状態からどの状態へ・どの条件で遷移するか、モデル別の遷移件数、どの UI Action や承認で進むかを指します。chg_model と sttrm_state で確認できる「状態がいくつあるか」までを扱い、状態モデルの内部実装には踏み込みません。
状態モデルは、次のURLで確認できます。
State Transition Model : https://<YourInstance>/sttrm_model_list.do
Model State : https://<YourInstance>/sttrm_state_list.do
前回の State は Normal モデルの状態と一致した（前回 Change Request 記事の回収）
結論から書くと、前回 change_request の State として見ていた番号体系は、今回の PDI では Normal モデルの状態定義（sttrm_state）と一致しました。
前回の Change Request 記事で、change_request の State として New=-5 から Closed=3、Canceled=4 という独自の番号体系を示しました。その正体が、ここで確認できます。
Normal モデルの状態（sttrm_state）を sequence 順に並べると、画面の表示名（state_label）と内部値（state_value）は次のように対応していました。これは前回示した change_request の State 値と完全に一致します。
Normalモデルの状態一覧
New … -5（初期状態）
Assess … -4
Authorize … -3
Scheduled … -2
Implement … -1
Review … 0
Closed … 3
Canceled … 4
今回確認した PDI では、前回「change_request の State」として見ていた状態の並びを確認しました。この並びは、Normal という Change Model の状態定義（sttrm_state）と一致しています。Change Request のフォームで見えていた状態は、参照先の Change Model が持っている状態の集合だった、と読み取れます。
承認の入り方の違いは、前回の記事で確認したとおりです。今回の OOTB で確認した範囲では、3モデルの流れは次のとおりでした。
Normal … Authorize で CAB（変更諮問委員会）の承認を通す
Emergency … ECAB（緊急 CAB）で簡略承認のうえ先に実施し、事後レビュー
Standard … 事前承認済みのためテンプレから作成し、スケジュール・実施へ進む
状態の数（Normal 8 / Emergency 7 / Standard 6）の違いが、この流れの違いとおおむね対応します。ただし、各遷移の条件や承認の内部定義そのものは確認範囲外です。
実機で気づいたこと
6モデルのうち4モデルには color フィールドに値が入っていました。内訳は Normal（緑 #8fdf84）・Emergency（赤 #ea3423）・Standard（黄 #f4c95c）・Change Registration（青 #488df4）です。Cloud Infrastructure と Unauthorized Change には色の設定がありませんでした。色は一覧画面や関連リストでモデルを見分けるための表示用途と考えられます。日常的に使われるモデルほど色分けが徹底されている、という運用上の配慮に見えます（推測です）。
状態モデル系のテーブルも、sttrm_state や sttrm_state_transition だけではありませんでした。遷移条件を扱う sttrm_transition_condition / sttrm_condition_type などがあります。ユーザー基準を扱う sttrm_model_user_criteria_read/write/hide_mtom もあり、思っていたより細かくテーブルが分かれています。chg_model の画面には出てこない部分に、遷移条件やアクセス制御のための下部構造が広がっていました。
ServiceNowにおける Change Model（chg_model）のポイント
Change Request の「type ごとに流れが違う」の出発点は chg_model テーブルです。change_request は chg_model を Reference（画面ラベル「Model」）で参照し、その先のモデルが状態の流れを持ちます。ただし、承認や遷移条件、UI Action などの内部処理まで chg_model 単体で完結するわけではありません。
chg_model は sttrm_model（State Transition Model）を継承した特化版です。親の sttrm_model に table_name / state_field / active などの汎用枠組みがあります。chg_model には default_change_model / available_in_ui / color / implementation_states などが加わります。
今回の PDI では Change Model は6件・全て active でした。
内訳: Normal / Emergency / Standard / Change Registration / Cloud Infrastructure / Unauthorized Change
いずれも table_name=change_request・state_field=state です。
既定モデルは Normal のみ、Create New に出るのは Normal / Emergency のみでした。Standard はテンプレ経由、残り3つは Create New には表示されません（用途や呼び出し経路は未確認）。
今回の PDI（Zurich）で確認できた状態モデル系の実体は sttrm_* でした（sys_cd 前方一致では該当0件）。状態は sttrm_state、遷移は sttrm_state_transition に保存されます。状態数は Normal 8 / Emergency 7 / Standard 6 でした。
前回 change_request の State で見た New=-5 〜 Closed=3 / Canceled=4 は、Normal モデルの状態定義（sttrm_state）と一致しました。
Change Model を調べるときは、chg_model 単体ではなく3点をセットで見ます。参照元の change_request.chg_model、継承元の sttrm_model、状態の実体である sttrm_state / sttrm_state_transition です。これにより、Change Request の画面で見える状態の流れと、その裏にあるモデル定義がつながって理解できます。
次に読むなら
3タイプの使い分け全体は「ServiceNow 変更管理（Change）完全ガイド：Standard・Normal・Emergencyをどう使い分けるか」で一望できます。そのうえで次に確認するなら、sttrm_state_transition が定義する状態遷移の中身です。どの状態からどの状態へ、どの条件（sttrm_transition_condition）で、どの UI Action や承認をトリガーに進むかを指します。本記事では状態の「数」までを確認し、遷移の「中身」は範囲外としました。Normal の CAB 承認・Emergency の ECAB・Standard のテンプレ承認が、状態モデル側でどう表現されているかは、状態モデル内部実装として別記事で解説する予定です。
用語
PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
chg_model：Change Model（変更モデル）。type 別の定型フロー定義
sttrm_model：State Transition Model（状態遷移モデル）。chg_model の継承元
CAB：Change Advisory Board（変更諮問委員会）
ECAB：Emergency CAB（緊急変更諮問委員会）
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
テーブル定義 : sys_db_object_list.do?sysparm_query=name=chg_model
フィールド一覧 : sys_dictionary_list.do?sysparm_query=name=chg_model^elementISNOTEMPTY
Change Model 一覧 : chg_model_list.do?sysparm_query=active=true
State Transition Model: sttrm_model_list.do
Model State : sttrm_state_list.do
標準変更テンプレ : std_change_record_producer_list.do検証範囲とおことわり
確認した範囲は次のとおりです。
chg_model の継承（→sttrm_model→sys_metadata）
固有フィールドと継承元フィールド
6モデルの属性（active / default_change_model / available_in_ui / color）
6モデルの属性・続き（table_name / state_field / implementation_states）
各種件数、change_request.chg_model 参照
状態モデル系テーブルの実体（sttrm_*）
モデル別の状態数、Normal の状態一覧
すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています。
確認していない範囲は次のとおりです。
各モデルの状態遷移の中身（どの状態からどこへ・条件・自動遷移）
承認ポリシーの内部定義
どの UI Action / 承認で状態が進むか
Flow との連携
sttrm_transition_condition の詳細
これらは状態モデルの内部実装にあたり、別記事で扱います。また、sys_cd_* 系テーブルは今回の PDI（Zurich）には存在しませんでした（実体は sttrm_*）。
今回は PDI の OOTB（初期設定）を前提に、Change Model の構造を確認しました。実環境では、既存のカスタマイズによってモデル・フィールド・状態の数や内容が変わります。
