State Transition Models（sttrm_model）：変更タイプごとに状態遷移を定義する仕組み

ServiceNow の変更管理を触ると、変更タイプごとに進み方が違うことに気づきます。Normal（通常変更）は Assess や Authorize を通ります。Standard（標準変更）は承認を挟まずに進み、Emergency（緊急変更）は審査を飛ばして承認から入る。この違いがどこで決まるのかを実機でたどると、コードの分岐ではなく sttrm_model（State Transition Model） というテーブルの定義に行き着きました。

State Transition Models は、アプリケーションメニューに「State Transition Models」として項目がある標準機能です。変更フォームの上では状態ボタンとして現れるだけで、その背後にある定義テーブルは通常の業務一覧には出てきません。日々の運用画面に出ないため、注目される場面は少なめです。それでも公式にドキュメント化された標準機能です。この記事では、PDI（Zurich / OOTB）で sttrm_model と、その状態（sttrm_state）・遷移（sttrm_state_transition）の実データを読みます。「変更タイプで進み方が違う」実体を、ここで確認します。

この記事は、ServiceNow の変更管理を管理者・開発者として設定側から理解したい人を想定しています。State Transition Model の定義が実機でどう並ぶかを、9つのモデルの一覧・モデルの中身・3タイプの状態集合の対比・遷移の定義の順に見ます。

この記事で分かること

• 変更タイプごとの進み方が、sttrm_model という定義テーブルの状態集合の違いとして表現されていること

• sttrm_model が基底テーブルで、Change Model（chg_model）などがこれを継承していること

• Normal 8状態・Standard 6状態・Emergency 7状態という実測の差（Assess・Authorize の有無）

• 状態を定義する sttrm_state と、許可経路を定義する sttrm_state_transition の役割

• 実機で確認するときに見る一覧 URL

State Transition Model とは何か

State Transition Model は、あるテーブルの state フィールドについて、どの状態からどの状態へ遷移できるかを宣言的に定義する仕組みです。「この状態のときに進める先はこれとこれ」という許可経路を、スクリプトではなくレコードとして持ちます。

変更管理では、Change のタイプ（Normal / Standard / Emergency など）ごとに別々のモデルが用意されています。同じ change_request テーブルを扱いながら、タイプによって通る状態が違うのは、タイプごとに参照するモデルが別で、そのモデルが持つ状態集合と遷移が違うためです。処理の分岐に「Standard なら承認をスキップ」と書いてあるわけではありません。「Standard のモデルには承認状態そのものが無い」という形です。

このモデルを格納する中心テーブルが sttrm_model（画面ラベル: State Transition Model）です。関連して、各モデルの状態を持つ sttrm_state（Model State）があります。許可される遷移を持つのが sttrm_state_transition（Model State Transition）です。3つとも sys_metadata（Application File）を継承する「アプリ構成」側のテーブルで、業務データではなく設定として管理されます。

9つのモデルの一覧

アプリケーションメニュー「State Transition Models」を開くと、モデルの一覧が並びます。今回の PDI（Zurich / OOTB）では 9件でした。

各モデルは「どのテーブルの、どのフィールドの遷移を定義するか」を持ちます。9件を対象テーブル（table_name）と state_field で整理すると、Change 系が6モデル、Problem 系が3モデルでした。すべて state フィールドの遷移を定義しています。

ここで実測から一つ分かったことがあります。sttrm_model は基底テーブルで、レコードの実クラス（sys_class_name）は3種類に分かれていました。Change 系6件は chg_model（Change Model）、Problem 系は prb_model と prb_task_model です。sys_db_object で継承関係を確認すると、chg_model の super_class は sttrm_model でした。つまり Change Model は State Transition Model を継承した拡張テーブルです。基底の state 定義に、変更管理向けのフィールド（色や既定モデルの指定など）を足した形です。

モデルの中身を開く

一覧から Normal を開きます。実クラスが chg_model のため、フォームの見出しは「Change Model / Normal」です。sttrm_model の基底フィールド（name・table_name・state_field など）に加えて、変更管理向けの項目が並びます。Color や Default change model、Record preset などです。

フォーム下部の関連リスト「Model States」に、このモデルが持つ状態が並びます。状態は sttrm_state テーブルのレコードです。主なフィールドは5つあります。親モデルへの参照（sttrm_model）・state_label（表示名）・state_value（内部値）・state_sequence（並び順）・initial_state（初期状態か）です。

Normal の状態だけを sttrm_state で絞ると、8件でした。

New だけが initial_state=true でした。変更を作成した直後の入口です。ここから先、どの状態へ進めるかを決めるのが遷移の定義です。

変更タイプで状態集合が違う

State Transition Model のいちばんの要点は、変更タイプごとに状態集合そのものが違うことです。Normal・Standard・Emergency の3つを sttrm_state で数えると、状態の数と顔ぶれが次のように分かれていました。

• Normal は8状態：New → Assess → Authorize → Scheduled → Implement → Review → Closed（と Canceled）。審査（Assess）と承認（Authorize）の両方を通ります。

• Standard は6状態：New / Scheduled / Implement / Review / Closed / Canceled。Assess と Authorize が無い。標準変更は事前に承認済みの定型作業として扱うため、審査・承認のステップがモデル上に存在しません。

• Emergency は7状態：New / Authorize / Scheduled / Implement / Review / Closed / Canceled。Assess が無く、New から Authorize へ入る。緊急のため審査を省き、承認から始める形になっています。

state_sequence の番号を見ると、この関係がはっきりします。Emergency は New（seq 1）の次が Authorize（seq 3）で、Assess にあたる seq 2 が欠けています。Standard は seq 2（Assess）と seq 3（Authorize）の両方が欠けて、New（seq 1）の次が Scheduled（seq 4）です。番号は3タイプで揃っていて、無いステップの分だけ抜けている、という並びでした。

「Standard は承認を飛ばせる」「Emergency は審査を飛ばす」という運用上の違いは、処理の分岐で実現しているのではなく、モデルごとに状態集合そのものを変えて表現しています。

遷移の定義（どの状態からどこへ進めるか）

状態集合が決まったら、次は「どの状態からどこへ進めるか」です。これを持つのが sttrm_state_transition（Model State Transition）テーブルです。1レコードが1つの許可経路にあたります。from_state（起点）・to_state（終点）・name（表示名）・automatic（自動遷移かどうか）を持ちます。

この一覧は全モデルの遷移をまとめて持ち、今回の PDI では 65件ありました。ひとつ注意したいのは、sttrm_state_transition にはモデルへの直接の参照フィールドが無いことです。モデルへの帰属は from_state（→ sttrm_state → sttrm_model）をたどって決まります。そのため一覧を sttrm_model=... で絞ろうとしても、この表にその列が無いため絞り込まれず、全65件が出ます。上の画像も、From 昇順の先頭に Assess 起点の遷移が複数モデル混在で並んでいて、Normal 単独ではありません。

from_state を Normal のモデルにたどって絞ると、Normal の遷移は15件でした。主な経路は次のとおりです。

• New → Assess（手動）

• Assess → Authorize（automatic=true）

• Authorize → Scheduled（automatic=true）

• Scheduled → Implement（手動）

• Implement → Review（automatic=true）

• Review → Closed（手動）

• New・Assess・Authorize・Scheduled・Implement の各状態から Canceled への手動遷移、および Assess → New / Authorize → New という差し戻し（automatic=true を含む）

automatic=true は条件が成立したときに自動で次へ進む遷移、それ以外は操作で進める遷移です。Normal では Assess → Authorize や Authorize → Scheduled、Implement → Review が自動遷移として定義されていました。どんな条件で自動遷移が発火するか（sttrm_condition_type 側の条件式）は、まだ追っていません。この定義が変更フォームの状態ボタンや状態プルダウンにどう反映されるかも同じです。こうした実行時の挙動はレコードを操作して追う必要があり、今回の確認範囲には含めていません。

実機で確認するときに見る場所

State Transition Model は、アプリケーションメニュー「State Transition Models」から一覧できます。URL で直接開くなら次のとおりです（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

モデル一覧   : https://<YourInstance>/sttrm_model_list.do?sysparm_query=active=true
状態一覧     : https://<YourInstance>/sttrm_state_list.do
遷移一覧     : https://<YourInstance>/sttrm_state_transition_list.do

特定モデルの状態だけを見たいときは、状態一覧をそのモデルで絞ります。sttrm_state にはモデルへの参照（sttrm_model）があるため、次の形で絞り込めます。

https://<YourInstance>/sttrm_state_list.do?sysparm_query=sttrm_model=<モデルのsys_id>^ORDERBYstate_sequence

遷移一覧はモデル列で直接は絞れないため、from_state 経由（from_state.sttrm_model=<モデルのsys_id>）でたどるか、モデルのフォームから関連リストで開くのが確実です。

まとめ

• State Transition Model は、テーブルの state フィールドの遷移を宣言的に定義する標準機能で、中心テーブルは sttrm_model（状態は sttrm_state、遷移は sttrm_state_transition）。今回の PDI ではモデルが9件でした。

• sttrm_model は基底テーブルで、Change 系のレコードは chg_model（Change Model）が sttrm_model を継承したものでした。Normal を開くとフォーム見出しが「Change Model」になるのはこのためです。

• 変更タイプごとの進み方の違いは、状態集合の違いとして表現されていました。Normal は8状態、Standard は6状態（Assess・Authorize が無い）、Emergency は7状態（Assess が無い）です。

• 遷移は from_state → to_state の許可経路として持ち、automatic フラグで自動遷移かどうかを区別します。sttrm_state_transition はモデルへの直接参照を持たず、モデルへの帰属は from_state 経由でたどります。

変更タイプによる挙動の差は、「どこで分岐しているのか」と処理を追いたくなります。ただ少なくとも今回確認した範囲では、その多くが State Transition Model の定義側で決まっていました。設定を読むときは、まずモデルの状態集合と遷移を見るのが近道です。

検証範囲とおことわり

• 確認した範囲：sttrm_model / sttrm_state / sttrm_state_transition の件数（9 / 43 / 65）、9モデルの table_name・state_field・実クラス、Normal / Standard / Emergency の状態集合、Normal の遷移15件と automatic フラグ。すべて PDI（Zurich / 2026-07-12 確認）の OOTB で取得しています。

• 確認していない範囲（断定しません）：遷移の condition（sttrm_condition_type）で使われる条件式、automatic 遷移の発火タイミングの内部処理、この定義が実際の変更フォームの状態ボタン・状態プルダウンにどう反映されるかの UI 挙動、Problem 系モデル（prb_model / prb_task_model）の状態・遷移の詳細。これらは対象レコードを操作して追う必要があり、別途扱います。

参考（ServiceNow 公式ドキュメント・Zurich）

• State model and transitions（Change Management）

• Add a state model and transitions（Platform administration）

関連記事

• ServiceNow 変更管理（Change）完全ガイド：Standard・Normal・Emergencyをどう使い分けるか — sttrm_model が定義する状態集合の違いを、実務でどう使い分けるかという運用面から確認できます。