変更管理モジュールのテーブル・フィールド構成

切り戻し手順やCAB日時といった変更管理特有の項目は、どこで定義されているのでしょうか。change_request と change_task は、どちらも task テーブルを直接継承する2階層構造です。固有フィールドはそれぞれ39項目・8項目でした。状態遷移を管理する専用テーブル chg_model_state は存在せず、実際には sttrm_state という汎用の仕組みが動いています。Australia の PDI をデフォルト設定のまま開き、フィールドの内訳と辞書上書き、type・risk・state の選択肢構成を確かめました。

確認する項目

• change_request / change_task の固有フィールドと task 継承フィールドの内訳

• type・risk・impact・category の選択肢構成と chg_model との対応

• 状態遷移を実際に担っている仕組み

• 辞書の上書き（sys_dictionary_override）で何が変わっているか

• incident.rfc という「定義の痕跡だけが残るフィールド」の実態

この記事の要点

• change_request と change_task はどちらも task を直接継承する2階層構造で、固有フィールドはそれぞれ39項目・8項目

• 状態遷移を管理する専用テーブル（chg_model_state）は存在せず、汎用の sttrm_state 機構が担う

• incident.rfc はメタデータ上に存在しない隠しフィールドで、Business Ruleでの能動利用も見つからない

テーブルの継承構造

change_request と change_task は、どちらも task を直接継承しています。2段階の継承構造で、Incident や Problem と同じ形です。

sys_db_object で5つのテーブルを並べると、継承元の違いが確認できます。

chg_model の継承元は Model、cab_meeting の継承元は Meeting です。task を継承していません。cab_meeting は CAB Workbench 専用のスコープアプリに属しており、change_request や change_task とは所属するアプリケーション自体が異なります。

change_request にはさらに、これを継承する3層目のテーブル change_request_imac（ラベル：IMAC）があります。IMAC は Install / Move / Add / Change の頭文字です。固有フィールドは sys_id を除き7項目で、次のとおりです。

• Reference：move_to_dc・move_user・move_department・move_from・move_to・move_from_dc

• True/False：network_component

CAB や risk のような承認系フィールドは持たず、機器の移設先・移設元という物理的な移転情報だけで構成されています。change_request 本体の39項目は承認・実施計画が中心で、性格が異なります。オフィス移転やネットワーク切替のような構成変更をひとまとめに扱う拡張用途の子テーブルです。

• 参考：taskテーブル：ITSM全プロセスの共通の親 … 親テーブル側の役割

フィールドの総数と型の分布

sys_dictionary を数えると、change_request 固有が39項目、change_task 固有が8項目でした。task から継承する項目は、両テーブルとも71項目で共通です。

name=change_request^elementISNOTEMPTY は実際には40件返ります。差分の1件は sys_id（GUID、テーブルごとに機械的に付く内部識別子）です。change_task も同様に9件中1件が sys_id でした。業務項目を数えるときは、この内部識別子を除いて考えます。

change_request 固有39項目を型で分けると、String が最多の16項目でした。

Reference は6項目のみで、内訳は次節で扱います。承認や実施計画の多くは Reference ではなく String 型です。自由記述として持たせる設計になっています。

change_task 固有8項目の内訳は次のとおりです。

• Reference：change_request（1件）

• String：change_task_type / close_code / created_from / on_hold_reason（4件）

• True/False：on_hold（1件）

• Date/Time：planned_end_date / planned_start_date（2件）

CAB やリスクに関わる項目は一切なく、実作業の枠組みだけを持っています。

• 参考：ServiceNowのフィールド設定はどこに保存される？ sys_dictionaryを実機で読む … 辞書テーブルの読み方

参照フィールドのつながり先

change_request 固有の Reference 6項目が、どのテーブルを指しているかを整理します。

cab_delegate と requested_by は User への参照です。chg_model と chg_model_template は変更モデル側、std_change_producer_version は標準変更テンプレートの版を指します。copied_from は change_request 自身への自己参照で、Copy Change 機能で使われる項目です。

task 継承の参照は16項目あり、assigned_to・assignment_group・cmdb_ci・business_service など Incident と共通の構成です。この一覧は SN-INC-021 で扱ったものと同じテーブルを参照するため、詳細はそちらに委ねます。

change_task の固有参照は change_request の1項目だけです。1件の change_task は必ず1件の change_request にぶら下がる、単純な親子構造になっています。

• 参考：参照フィールドと参照修飾子：候補はどう絞られるか … 参照先の候補はここで絞られる

Change Modelごとの起票経路と初期状態

change_request.type の選択肢は standard / normal / emergency / model の4件です。

typeを実際に動かしているのは chg_model です。本PDIには6件（全件active）登録されていました。

chg_model の辞書には type という列自体が存在しません。type の値は record_preset という汎用テンプレート文字列（例: type=normal^EQ）に埋め込まれています。この設計により、Unauthorized Change モデルは独自の type を持たず、type=emergency と unauthorized=true というフラグの組み合わせで表現されます。Standard モデル自体は available_in_ui=false で、新規作成画面には出てきません。標準変更は std_change_producer_version のテンプレートからだけ起票されます。

確認済みのOOTB構成：6つのChange Modelは、起票経路・対象利用者・初期状態が三者三様です。chg_model.description（公式説明）まで実測すると、UI表示可否の理由が読み取れます。

初期状態はNormal/Standard/Emergencyの3モデルがNew(-5)で共通です。一方、Change RegistrationとUnauthorized ChangeはReview(0)、Cloud InfrastructureはAuthorize(-3)から始まります。終了状態はどのモデルもClosed(3)またはCanceled(4)で共通です。

UI表示可否（available_in_ui）がfalseの4モデルは、公式説明でも「人が新規作成画面から都度選ぶ」経路として書かれていません。

• Standard：承認済みテンプレートの複製

• Change Registration：承認を伴わない自動記録

• Cloud Infrastructure：パイプライン連携

• Unauthorized Change：事後統制の捕捉

Cloud Infrastructureの初期状態がAuthorizeなのは、連携元のパイプライン側で計画・査定を終えている前提だからです。人には承認だけを求める設計と読み取れます。

推奨するあるべき姿：自社でCMDB連携やITAM連携から自動起票するChange Modelを追加する場合を考えます。available_in_ui=falseのまま、初期状態をAuthorize以降に設定するのが妥当です。連携元システムが計画・査定を終えている前提を崩さないためです。

設計例：以下は設計を具体化するための推奨例です。組織名・グループ名・時間・閾値・通知先などの実際の値は、導入先の運用体制に合わせて確定してください。record_presetにassignment_groupとshort_descriptionを固定します。初期状態をAuthorizeに設定し、人が確認する操作を承認だけに絞る設計にします。

例外：連携元システムの査定精度を信頼できない場合は、初期状態をAssess(-4)に留め、人による査定を1段挟みます。

本番導入前の検証事項：新しいChange Modelを追加したら、available_in_ui・record_preset・初期状態の3点が意図通りかを、実際に1件起票して確認します。

リスクは5段階中3段階しか選べない

change_request.risk の選択肢は5段階で定義されていますが、両端（1-Very High と 5-None）が inactive でした。

実際に選べるのは 2-High / 3-Moderate / 4-Low の3段階です。impact は change_request 固有の choice を持たず、task 継承（1-High / 2-Medium / 3-Low の3段階）をそのまま使います。

カテゴリは9種類の文字列選択肢

category は9種類です。

• Hardware / Software / Service / System Software / Applications Software / Network / Telecom / Documentation / Other

internal_type は Integer ではなく String です。値そのものがラベルとほぼ一致する、疑似的な選択肢になっています。

状態遷移を担うのはchg_model_stateではない

state の選択肢は8件で、欠番がありません。

New（-5）から始まり、Closed（3）・Canceled（4）まで、負数中心の独自の番地です。task 標準の state 値とは重複しません。

「type ごとに状態遷移が違うなら chg_model_state のような専用テーブルがあるはず」と考えて sys_db_object を nameLIKEchg_model で検索すると、該当は3件だけでした。

内訳は chg_model / chg_model_attribute / chg_model_condition_type の3件です。chg_model_state と chg_model_state_transition という名前のテーブルは存在しません。状態遷移の実体は、chg_model の implementation_states フィールドです。参照先は sttrm_state（State Transition Rule Model）という汎用の状態遷移機構です。

Change 専用の状態遷移テーブルを新設せず、既存の汎用機構に接続する形で実装されている点が、この調査でいちばん意外だった箇所です。

確認済みのOOTB構成：8つの状態には、UI Action（sys_ui_action）の表示条件とUI Policy（sys_ui_policy_action）の必須化条件を突き合わせると、責任者・開始条件・完了条件・必須入力・戻し可否まで実測できました。

Newへ戻せるのはEmergencyのAuthorizeとNormalのAssessの2状態だけです（UI Action「Revert to New」のcondition実測）。それ以外は前に戻せず、キャンセルのみが選べます。「Request Approval」はAssess用とCAB用の2種類があります。承認フローがAssess段階の軽い承認とCAB段階の正式承認という2段階構成であるためです。必須化のUI Policy「Mandatory - Assignment Group」の条件はstateがIN -4,-3,-2,-1,0,3です。Canceled(4)だけがこの対象から外れています。取り消した変更にはassignment_groupの入力を求めない設計です。

推奨するあるべき姿：状態ごとの必須入力は、UI Policyだけで止めず、末尾order（300〜999）のBusiness Rule側でも重ねて強制する構成が妥当です。フォームを経由しないAPI・Flow経由の更新でも、同じ入力品質を保てるためです。

顧客確認事項：差し戻し運用を多用する現場では、Newへ戻せるのがEmergencyのAuthorizeとNormalのAssessに限られる制約が、自社の運用と合うかを確認します。

本番導入前の検証事項：状態を1つずつ進めます。各段階でRequest Approval／Implement／Review／Closeのボタンが表示される状態と表示されない状態を、実際に1周動かして確認します。

辞書の上書き（sys_dictionary_override）

task の定義を change_request / change_task 用に変えている上書きが、それぞれ4件・3件ありました。

change_request（4件）

element上書き内容実務での意味state既定値 -5（New）、close_states=3;4;7どの状態を「終了」とみなすかの定義。ACLやレポートの判定と連動するcmdb_ci参照修飾子：TaskUtils のフィルタ対象CIの候補を、業務サービスに応じて絞るassigned_to参照修飾子：roles=itil^ORroles=sn_change_write担当者の候補が itil か sn_change_write を持つユーザーに絞られるbusiness_service参照修飾子：TaskUtils のフィルタサービスの候補を絞り、関連マップの表示を有効にする

change_task（3件）

element上書き内容実務での意味assigned_to参照修飾子：roles=itil^ORroles=sn_change_write^ORroles=sn_change_task_assigned_userchange_task には専用ロールが1つ多く候補に加わるcmdb_ci参照修飾子：TaskUtils のフィルタchange_request 側と同じ絞り込みstateclose_states=3;4change_request より単純。異常な値は含まない

change_request.state の close_states には 3;4;7 という3つの値が指定されています。state の選択肢は8値（-5〜4）で、7という値は定義されていません。実測で確認した事実で、原因は分かっていません。旧バージョンの残骸である可能性が高く、断定は避けます。change_task.state 側の close_states は 3;4 だけで、同じ異常はありませんでした。

CABフィールドの入力責任と品質基準

change_request 固有39項目の中心は、実施・切り戻し・CABに関わる文字列と日時の項目です。この節は、誰がいつ何のために記入するか、記入した内容がどの品質基準を満たせばCAB審議に使えるかを扱います。

implementation_plan・backout_plan・test_plan の3項目は、いずれも String 型の自由記述です。承認前に何を実施し、失敗したらどう戻すか、どうテストするかを1組で管理する設計になっています。cab_required 以下の4項目はCABに関わる日時・代理出席者・勧告メモ、risk と risk_impact_analysis はリスクの値と分析メモです。

確認済みのOOTB構成：implementation_plan の公式説明（sys_documentation）は、単なる自由記述欄ではないことを示しています。

（訳: この変更を実装する逐次的な手順を記入する。加えて、手順間の依存関係と各手順の担当者詳細も記入する）

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

公式説明が求めているのは「手順」「依存関係」「担当者」の3要素です。承認するCAB側が読むのは、この3要素が揃っているかどうかになります。

推奨するあるべき姿：implementation_plan は、手順・担当者・開始条件・終了条件・依存関係の5要素が揃って初めて、CABが承認可否を判断できる記入とみなします。1行だけの記述は、記入不備として差し戻す運用が妥当です。

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

良い例は担当者・時刻・完了条件・失敗時の分岐まで書かれており、CABは「何時に何が起きるか」を承認判断にそのまま使えます。悪い例は誰が・いつ・どう終わるかが分からず、CABが差し戻すか、チャットで別途確認する手戻りが発生します。

例外：Standard Change はテンプレート側に手順が固定されているため、change_request 側の implementation_plan はテンプレートのまま流用できます。Normal・Emergency では都度の記入を必須の粒度として扱います。

本番導入前の検証事項：implementation_plan と backout_plan の記入必須化は、フォーム上のUI Policyだけで止めません。API経由の更新でも同じ基準を強制できているかを、実際に1回試して確認します。

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

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

（訳: 実装前の状態に戻す手順を記入する。実装中いつ戻せるか、変更ウィンドウにバックアウト時間が含まれるかも記入する）

backout_plan の説明です。切り戻し手順は、実施タイミングと時間枠まで書く前提のメモだと分かります。

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

unauthorized の説明です。このフラグはフォームで直接オフに戻す想定ではなく、Outage レコードの作成という別の操作を経て解除する仕組みだと読み取れます。

phase の説明は「Dependent on Category value」（Categoryの値に依存）です。phase_state の説明も同様に「Dependent on Phase value」（Phaseの値に依存）で、具体的な対応関係までは書かれていません。

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

他プロセスから見たchange_requestとincident.rfcの実態

change_request を参照する実テーブルは16件ありました。change_task・conflict・dmn_demand・std_change_proposal などが名前を連ねる中、problem.rfc という項目が含まれています。Problem 側には Change への逆参照フィールドが辞書上に明示的に存在します。

一方、この16件の一覧に incident は一件も現れません。

incident.rfcの実在確認

incident 側にも rfc という項目名の言及があるという情報から、sys_dictionary を name=incident^elementSTARTSWITHrfc で確認しました。

該当は0件です。sys_dictionary_override にも0件、REST APIで rfc を指定して取得しても値は返りません。rfcISNOTEMPTY という条件で incident を絞り込んでも、全73件がそのまま返ってきました。架空のフィールド名で同じ絞り込みを試しても結果は同じ73件で、条件そのものが黙って無視されていることが分かります。

それでも、メタデータより下の層には rfc という名前の痕跡が残っていました。ACL に incident.rfc（operation=query_range、public ロール）が1件、プロパティ（com.snc.incident.copy.attributes など2件）の値の中に rfc という文字列が明記されています。Business Rule のスクリプト本文で rfc を使っているものは0件でした。

problem.problem_id も同じく sys_dictionary には現れない隠しフィールドです。ただし Business Rule「SNC - ITIL - Update Related Incidents」の中で実際にクエリされています。incident.rfc にはこの能動利用が見つかりませんでした。メタデータに存在しない点は同じでも、使われているかどうかは別問題です。

推測になりますが、incident.rfc は過去のバージョンで存在していたフィールドか、UI上だけ非表示化された設定だった可能性が考えられます。断定はできません。

実機で気づいたこと

stateの上書き属性に存在しない値7が混ざっている

change_request.state の close_states 属性は 3;4;7 でしたが、state の選択肢は8値（-5〜4）で7という値は定義されていません。change_task.state の close_states は 3;4 だけで、この異常は見当たりませんでした。

旧バージョンの終了状態の名残が、上書き属性の中にだけ残っている可能性が高いと考えられます。sys_choice の定義とsys_dictionary_overrideの属性は別のテーブルなので、片方だけ更新され片方が古いまま残る、ということが起こり得ます。

自社で state の close_states 属性を追加・変更するときは、その環境の sys_choice に実在する値と必ず突き合わせます。過去の設定をそのままコピーすると、存在しない値を終了状態として扱ってしまう恐れがあります。

chg_model自身の辞書にtype列がない

chg_model の6件は、どれも type の値（standard / normal / emergency / model）と対応しているように見えます。ところが chg_model テーブルの辞書定義自体には、type という列が存在しません。type の値は record_preset という汎用のテンプレート文字列に埋め込まれています。

Change Model は「type専用の設定テーブル」ではなく、任意の初期値をレコードに注入する汎用テンプレート機構として設計されていると読み取れます。だからこそ Unauthorized Change モデルは、type としては Emergency を流用しつつ unauthorized フラグを追加する、という変則的な表現が可能になっています。

自社で Change Model を追加するときは、record_preset に書ける値が type に限らないことを踏まえます。担当グループや短い説明文など、任意のフィールドへ初期値を注入するテンプレートとして使えます。

incident.rfcはBusiness Ruleで一度も使われていない

incident.rfc は problem.problem_id と同じ「メタデータに存在しない隠しフィールド」構造を持ちますが、Business Rule での能動利用は0件でした。problem_id は実際にBRでクエリされています。

incident.rfc は ACL とプロパティに名残があるだけで、実際の連携処理には使われていない可能性が高いと考えられます。名前が残っているからといって、機能が生きているとは限りません。

自社で incident から Change を起票する連携を組むときは、rfc フィールドに頼らず、明示的な参照フィールドか Flow の変数を自分で用意したほうが安全です。存在しない項目に依存したクエリは、条件が無視されたまま気づかれずに動き続けます。

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

自社向けに項目を設計するとき、確認する順序を決めておくと迷いません。

1. 追加先の判断：change_request だけで使うか、change_task や他プロセスでも使うか

2. 型の選択：文字列で自由記述にするか、Reference で候補を絞るか

3. 既定値の仕組み：固定値で足りるか、chg_model のようなテンプレート機構が要るか

4. 状態遷移の設計：sttrm_state の汎用機構に載せるか、自前の仕組みを作るか

5. 上書きの要否：task の項目を change_request / change_task だけで変えたいとき、sys_dictionary_override に行があるかを確認する

6. CAB・切り戻し項目の運用：backout_plan などの自由記述項目に、どこまでの粒度で書かせるかを決める

7. 他モジュールとの連携：rfc のような隠しフィールドに頼らず、明示的な参照を用意するか

用語

• OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態

• PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス

• CAB：Change Advisory Board（変更諮問委員会）。リスクの高い変更の承認を検討する会議体

• chg_model：Change Model。type ごとの初期値とライフサイクルをまとめたテンプレート機構

• sttrm_state：State Transition Rule Model。Change に限らず使われる汎用の状態遷移機構

検証範囲とおことわり

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

• 件数はすべて OOTB の定義の数です。本番環境やカスタマイズ済み環境では異なります

• Business Rule・UI Policy・ACL の条件式の中身は、本シリーズ第6巻「変更管理モジュールの自動設定構成」・第3巻「変更管理モジュールのロール」で扱います

• 選択肢の値を実務でどう使い分けるかは、本シリーズ第5巻「変更管理モジュールの基本設定」で扱います

• chg_model と std_change_producer_version の対応関係は本調査では確認していません

• incident.rfc の由来は推測にとどまり、断定していません

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

• change_request の項目定義：/sys_dictionary_list.do?sysparm_query=name=change_request^elementISNOTEMPTY

• change_task の項目定義：/sys_dictionary_list.do?sysparm_query=name=change_task^elementISNOTEMPTY

• 継承関係：/sys_db_object_list.do?sysparm_query=nameINchange_request,change_task,chg_model,cab_meeting,change_request_imac

• type の選択肢：/sys_choice_list.do?sysparm_query=name=change_request^element=type

• state の選択肢：/sys_choice_list.do?sysparm_query=name=change_request^element=state^ORDERBYsequence

• risk の選択肢（inactive含む）：/sys_choice_list.do?sysparm_query=name=change_request^element=risk^ORDERBYsequence

• Change Model 一覧：/chg_model_list.do?sysparm_query=active=true

• 上書きの定義：/sys_dictionary_override_list.do?sysparm_query=name=change_request

• chg_model系テーブルの実在確認：/sys_db_object_list.do?sysparm_query=nameLIKEchg_model

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

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

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINchange_request,change_task^hintISNOTEMPTY

関連記事

• taskテーブル：ITSM全プロセスの共通の親 … change_request / change_task が共有する71項目の出どころ

• インシデント管理モジュールのテーブル・フィールド構成 … 同じ task 継承構造を持つ姉妹編

• State Transition Models（sttrm_model）：変更タイプごとに状態遷移を定義する仕組み … 本記事で触れた sttrm 系機構の詳細

参考：

• 選択肢Choice（sys_choice）：ドロップダウンの中身

• 参照フィールドと参照修飾子：候補はどう絞られるか

• APIやインポートにも効く必須制御（Data Policy）

• CAB Workbench（/cab）の入口はカレンダー1枚：ウィジェットも1個だけ

• グループ承認：N人を1つに束ねる仕組み（sysapproval_group）

• ServiceNowの変更申請テンプレートには切り戻し手順まで入っている？ sttrm_base_templateを実機で読む