変更管理モジュールの連携機能

2026年9月4日 01:07

Changeのフォームを開くと、他プロセスから作られたことを示す参照フィールドがほとんど見当たりません。IncidentやProblemから変更を起票したとき、値はどこにコピーされるのでしょうか。CMDBのCIやCAB会議とはどうつながっているのでしょうか。Australia PDIをデフォルト設定のまま開き、Incident・Problem・CMDB・CAB・標準変更カタログとの接続経路を実機で確かめました。

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

確認する連携先

Incidentから変更を起票する2つのUIアクションと、コピーされる項目
CMDBの対象CI・影響CIをChangeとConflict Detectionがどう扱うか
CABが変更をどう議題に乗せ、承認結果をどう同期するか
change_taskの使われ方と、標準変更カタログへの接続

連携の全体像

change_requestを参照する実テーブルは少なく、多くの連携はUIアクションによる起票と書き戻しで実現している
incident.rfcは辞書に無い痕跡フィールドで、書き戻しスクリプトは今も動こうとしている
標準変更のテンプレートは、Change管理の外にあるService Catalogのアイテムそのものとして存在する

Changeから他プロセスへつながる経路

change_requestを参照する実テーブルをsys_dictionaryで調べると16件でした。多くはchange_taskやconflictなどChange管理自身の周辺テーブルで、他モジュールからの参照は限られます。incidentは、この一覧に一件も現れません。

数少ない他モジュールからの参照の中に、Release Management（release_feature・release_rfcs）がありました。どちらも列名はrfcです。incidentのrfcは辞書に無い痕跡でしたが、こちらは実在する参照フィールドで、リリースに含める変更を紐づける役割を持ちます。同じ列名でも、テーブルによって「今も機能する参照」と「痕跡だけの列」に分かれる点は覚えておく価値があります。

残りの13件はchg_policy_applied（適用済みポリシー）・change_risk_details（リスク判定結果）・dmn_demand（PPMの需要案件）など、Change管理自身か隣接する運用機能のテーブルでした。他モジュールからの本格的な参照はProblemとRelease Managementに限られ、Change側から見ると接続先の少なさが目立ちます。

確認済みのOOTB構成：連携経路の分類

参照テーブルの少なさは、Changeが他プロセスとつながっていないことを意味しません。多くの連携はテーブル参照ではなくUIアクションやビジネスルールという「動き」で実現されています。ここでは確認できた経路を、新規レコード自動作成／フィールドコピー／参照関係作成／元レコードへの書き戻し／関連リスト更新／非同期処理／画面遷移のみ、の7分類のどれに当たるかで整理します。障害調査でどのテーブルを見ればよいか、改修でどの経路に手を入れるとどこまで影響するかを判断するための分類です。

対象はAustralia PDIのOOTB定義とデモデータ、集計は2026-09-01時点です。

表から読み取れる重要事項は3つです。新規レコード自動作成を伴う経路（Emergency起票・Problem起票・Standard Change Taskの複製）は、ボタン1つで審査前のレコードが増える経路でもあります。元レコードへの書き戻しを伴う経路（rfc・cab_date・decision）は、書き戻し先の項目が辞書に存在するかを個別に確認しないと片方向でしか機能しません。画面遷移のみの経路（標準変更カタログ・Create Change Task）は値を一切引き継がないため、担当者の手入力が前提です。

改修時に変更してよいのは主にUIアクション側のスクリプト（コピー項目の追加・削除）です。標準変更カタログの接続構造（テーブル継承）は変更しない前提とします。継承を崩すとCatalog Item機構自体が使えなくなるためです。個々のUIアクション・ビジネスルールの実装は次節以降で確認します。

Incidentから緊急変更を起票すると6項目がそのままコピーされる

IncidentのUIアクション一覧をtable=incident^nameLIKEChangeで絞り込むと、Change関連のボタンは2件でした。

「Create Emergency Change」はForm actionがtrueの、通常のフォームボタンです。スクリプトを読むと、ChangeRequest.newEmergency()で新しいChangeを直接insertしていました。

var changeRequest = ChangeRequest.newEmergency();
changeRequest.setValue("short_description", current.short_description);
changeRequest.setValue("description", current.description);
changeRequest.setValue("cmdb_ci", current.cmdb_ci);
if (changeRequest.hasValidChoice('priority', current.priority))
    changeRequest.setValue("priority", current.priority);
changeRequest.setValue("sys_domain", current.sys_domain);
changeRequest.setValue("company", current.company);
changeRequest.insert();

コピーされる項目は6つです。

priorityだけはhasValidChoice()でChange側に有効な選択肢があるときに限られます。Problem側の同名スクリプト（Create Normal/Emergency Change）と、コピーする項目・条件はほぼ同じ作りでした。

priorityはコピーされるが、riskは自動的に決まらない

6項目のうちIncident側の値をそのまま引き継ぐのはpriorityだけです。impact・urgencyはコピー対象になっておらず、Changeを新規insertした時点の既定値のままです。riskはChange固有のフィールドで、この6項目には含まれません。

Incidentのpriorityは「影響度×緊急度」で決まる、障害が業務に与える影響の指標です。Changeのriskは「この変更を実施すること自体のリスク」を表す別の指標で、Risk ConditionsやCalculate Riskアクションによる評価を前提にしています。目的の異なる2つの指標のため、priorityが高いからriskも高いとは判断できません。

推奨するあるべき姿：Emergency Change起票直後に、riskとimpactの再評価を必須操作とします。Incidentのpriorityコピーは初期値の補完であり、リスク評価の代わりにはなりません。運用ルールにその旨を明記したうえで、riskが空欄のままAuthorize状態へ進んでいないかを定期確認の対象に加えます。

Incident側の書き戻しはセッション経由という遠回りな作り

Problemのボタンはcurrent.rfc = changeRequest...; current.update();と、その場で直接書き戻していました。Incident側は違います。

var target = {};
target.table = current.getTableName();
target.sysid = current.getUniqueValue();
target.field = 'rfc';
gs.getSession().putProperty('change_link', target);

insertした直後にこのセッション情報を設定するだけで、incident側のレコードを直接更新する行はありません。書き戻しを担うのは、change_request側のビジネスルール「Link change to incident in Wkspace」でした。

var linkData = session.getProperty('change_link');
var taskGr = new GlideRecord(linkData.table);
if (taskGr.get(linkData.sysid)) {
    taskGr.setValue(linkData.field, current.getUniqueValue());
    taskGr.update();
}

Changeがinsertされたあとにこのルールが動き、セッションに残った情報をもとに元のレコードのrfc欄へ新しいChangeのIDを書き込む設計です。

Create Change Requestは通常変更と標準変更カタログの分岐点

もう一方の「Create Change Request」は、Form actionがfalseでした。値のコピーはせず、クライアントスクリプトだけを持っています。

クリックするとWorkspace上にモーダルが開き、担当者は「通常のChangeを作る」か「標準変更カタログから選ぶ」かを選択します。カタログを選んだ場合はsysparm_parent_table=incidentという形で元のIncidentのIDを引き継ぎ、標準変更カタログの申請画面へ遷移する作りでした。

通常の作成を選んだ場合も、insert前に同じセッション情報（change_link）が設定されます。書き戻しの仕組み自体は「Create Emergency Change」と共通です。

incident.rfcは痕跡、problem.rfcは実在の参照

書き戻し先のincident.rfcは、テーブル・フィールド構成編で確認したとおりsys_dictionaryに存在しない列でした。Business Ruleでの能動的な利用も見つかっていません。対してproblem.rfcはchange_requestを参照する実テーブルの一覧に名を連ねる、辞書に実在する列です。同じ「変更への逆参照」という役割でも、Problem側は生きた参照フィールド、Incident側は書き戻しスクリプトだけが残る痕跡という違いがあります。

Problemから変更を起票する経路は別記事に委ねる

Problem側にも同じ発想の2つのボタンがあり、6項目のコピーとrfcへの書き戻しを行います。書き戻しはIncidentのようなセッション経由ではなくその場での直接更新でした。同じChangeへの接続を実装しているのに、参照先の書き戻し方がProblemとIncidentで違う理由は、problem.rfcが辞書に実在する列である一方、incident.rfcが実在しない列だからだと考えられます。書き戻し先が存在するかどうかで、実装の遠回り具合まで変わってくる形です。項目の対応表や重複起票を防ぐ表示条件など、詳しい内容は問題管理シリーズの連携編で扱っています。

CMDBとの紐づけ：cmdb_ciと影響CI(task_ci)

Changeが対象とするCIは、taskから継承するcmdb_ciが1件だけを持ちます。値の選択肢はTaskUtilsの参照修飾子で、関連する業務サービスに応じて絞り込まれます。同じTaskUtilsのフィルタはbusiness_serviceにも使われており、対象CIと対象サービスの候補を同じロジックで絞り込む作りでした。

1件のChangeが複数のCIに影響する場合は、関連リスト「Affected CIs」（task_ci）を使います。

フィールド型役割taskReference→Task影響を記録する側のレコードci_itemReference→cmdb_ci影響を受けるCIappliedTrue/False実際に変更を適用したCIかどうかapplied_dateDate/Time適用日時manual_proposed_changeTrue/False手動で追加されたCIか

Change向けのtask_ciは66件でした。

appliedがtrueなのは6件、9%だけです。残り60件は「影響する可能性があるCI」として登録されているものの、実際に変更を適用した記録はまだ付いていません。計画段階で対象CIを広めに登録し、実施後に確定させる運用を想定した項目だと分かります。CMDBのクラス構造そのものは、CI連携ガイド（後述）で扱っています。

Conflict Detectionは影響CIをどう使うか

同じCIや同じ担当者に予定された変更が重ならないかを確認するConflict Detectionは、主要な対象をcmdb_ciに置いています。プロパティchange.conflict.modeがadvancedのときは、この1件に加えてtask_ciの関連リスト全体もチェック範囲に含まれます。Basicモードなら自CIだけです。

チェックする観点も複数あります。同じCIへの予定衝突・ブラックアウトウィンドウとの重なり・CIのメンテナンスウィンドウ内かどうか、といった観点は既定で有効ですが、同一担当者への重複割り当てチェックは既定で無効でした。プロパティの全件と、保存のたびに動くビジネスルールの流れは、プロパティ編・自動設定の回で扱いました。ここでは「主役はcmdb_ci、advancedモードでtask_ciまで広がる」という対象範囲の違いだけを押さえておきます。

CABの議題化：cab_agenda_itemが変更を議事録に乗せる

CAB（変更を審査する会議体）に変更を諮る流れは、cab_agenda_itemが担います。フィールドはミーティング機能の基底テーブルから継承するtask（参照先はTask型）を含み、Changeそのものへ直接つながっていました。

デモデータでは60件全件がPending、decision欄も全件空欄です。

この表を確認する目的は、議題の追加と承認結果の反映がどのビジネスルールで実装されているかを特定することです。対象はcab_agenda_itemとchange_requestに登録されたアクティブなビジネスルールで、2026-09-01時点の実測です。

表だけでは、5件のビジネスルールがどの順番でつながっているかまでは分かりません。実際にはChange→CAB・CAB→Change・承認→Agenda Itemの3方向に分かれ、それぞれ別のタイミングで動きます。

cab_requiredの公式説明を引用します。

CAB approval is needed for this change request

（訳: この変更要求にはCAB承認が必要）

引用元: /sys_documentation_list.do?sysparm_query=name=change_request^element=cab_required

cab_requiredにチェックが入ったChangeが議題化の起点です。「Restrict adding agenda items」（before, order100）が会議がPending状態のときだけ追加を許可し、それ以外はsetAbortAction(true)で中断します。実際のレコードを1件開くと、added欄に"Automatically"という値が入っていました。順序（order）は500や700といった値で、複数の議題を並べる余地を残した採番です。担当者が手動で1件ずつ追加する経路は用意されているものの、デモデータで確認できたのは自動追加のパターンだけでした。

会議日時の反映は逆方向です。実装は「Update CAB Date in Change Request」（cab_agenda_item, after, order100）です。このBRがchange_request.cab_date／cab_date_timeを更新します。change_request側の「Sync "cab_date" and "cab_date_time"」（before, order950）は、2項目の不整合を補正します。

承認結果の反映は3つ目の方向です。change_request.approvalがapproved／rejectedに変わると、対応するビジネスルールが動きます。「Sync approval with agenda item」（after, order100）が、cab_agenda_item.decisionと議事メモへ結果を書き込みます。「Auto Agenda Decision」（after, order100）は別の経路です。会議がin_progress／pausedから完了状態へ移った時点でdecisionが空欄のままなら、議事メモへその旨を記録するフォールバックです。承認結果の転記そのものではなく未決のまま会議が終わったことを残す処理だと読み取れます。CAB Workbenchの画面構成そのものは、既存記事（後述）で確認できます。

change_taskは実装計画をどう分担するか

Changeの実装作業を分担する仕組みがchange_taskです。種類は4つ登録されています。

値ラベルplanningPlanningimplementationImplementationtestingTestingreviewReview

辞書にはchange_task_typeの既定値としてplanningが設定されています。ところが実際にGROUPBYで集計すると、10件全件が空欄でした。

既定値はフォームから新規作成したときに働く仕組みで、投入済みのデモデータには反映されません。他テーブルの既定値を見るときも、辞書の定義と実データの値は別物として確認する必要があります。

公式の説明も引用します。

Enter sequential steps to implement this change. In addition, enter dependencies between steps and assignee details for each step

（訳: この変更を実装する手順を順番に記入する。あわせてステップ間の依存関係と、各ステップの担当者情報も記入する）

引用元: /sys_documentation_list.do?sysparm_query=name=change_request^element=implementation_plan

このimplementation_planは自由記述のString項目で、106件中78件、74%に記入がありました。ステップごとの依存関係や担当者まで構造化して残すならchange_taskへ切り出す必要がありますが、実際は1つのテキスト欄に手順をまとめる運用の方が優勢だと読み取れます。

タスクの生成方法もタイプごとに違います。Standardはビジネスルール「Create Standard Change Tasks」がStdChangeUtilsを呼び出し、標準変更テンプレートに登録済みのタスクをその場で複製します。Normal・Emergencyは「Create Change Task」ボタンから、担当者がそのつど作成する形です。

implementation_planと対になるbackout_plan（切り戻し手順）も同じString型で、標準変更テンプレートの側にひな形が用意されています。テンプレートに切り戻し手順まで入っている実例は、ServiceNowの変更申請テンプレートには切り戻し手順まで入っている？ sttrm_base_templateを実機で読むで確認できます。

標準変更カタログ：承認済みテンプレートはService Catalogの中に置かれる

標準変更は、承認から公開までの流れがChange管理の外に伸びています。

審査段階のstd_change_proposalは6件すべてがClosedでした。承認されたテンプレートはstd_change_producer_versionとして発行され、こちらも6件、全てversion=1です。

ここから先が他モジュールとの接続点です。std_change_producer_version.std_change_producerが参照するstd_change_record_producerは、sys_db_objectで継承元を確認すると「Record Producer」でした。

「Record Producer」（sc_cat_item_producer）はさらに「Catalog Item」（sc_cat_item）を継承します。標準変更テンプレートは参照フィールドで他モジュールとつながっているのではなくテーブルの継承関係そのものによって最初からCatalog Itemの一種として存在します。

実際にsc_cat_itemをクラスで絞り込むと、6件の標準変更テンプレートがカテゴリ・価格つきで返ってきます。

内訳はNetwork Standard Changesが3件、Server Standard Changesが2件、Hardware Assetが1件です。価格は全件$0.00、Rolesはsnc_internalに限定されていました。一般利用者向けというより、内部の運用担当者が申請する前提のカタログアイテムだと分かります。

std_change_producer_versionにはpercent_successful・closed_change_count・unsuccessful_change_countという3つの実績フィールドもあります。標準変更を1件実行するたびに、このテンプレートの成功率が更新される仕組みです。

6件のうち5件は成功率100%でした。「Change VLAN on a Cisco switchport」だけは違いました。closed_change_count=3・unsuccessful_change_count=1で、成功率は66.67%です。全体の3割弱にあたる件数で、切り戻しや手戻りが起きていた計算です。審査を通ったテンプレートを公開して終わりにせず、公開後の実行実績まで同じレコードで追跡する設計になっています。標準変更として承認したテンプレートでも、実行結果を定期的に見直す運用が前提になっていると読み取れます。

実機で気づいたこと

incident.rfcへの書き戻しは、フィールド不在のまま実行されようとする

「Create Change Request」「Create Emergency Change」の表示条件には、共通してgs.fieldExists('incident', 'rfc')という一句が入っています。テーブル・フィールド構成編で確認したとおり、incidentの辞書にrfcという列は存在しません。fieldExists()は辞書に列があるかどうかを確認するAPIのため、この条件は満たされない可能性が高いと考えられます。だとすれば2つのボタンは、このPDIのIncidentフォームには表示されない設計になっているはずです。本記事はUIアクション定義のリスト画面から実測しており、実際のフォームでボタンの有無を目視で確認する検証は行っていません。書き戻し先の列が無いのにボタンの条件式は列の存在を前提にしている、という食い違いだけは実測できました。旧バージョンでrfcが使われていた名残がボタンの条件にまで及んでいる、という見立てになります。

change_taskを持つChangeは106件中2件だけだった

change_task 10件の内訳をGROUPBYで確認すると、紐づく変更はわずか2件（6件と4件）でした。残り104件のChangeにはタスクが1件も無く、実装計画は前節のimplementation_plan欄1つに頼っている状態です。change_taskによる作業分担は、デモデータを見る限り一部のChangeでしか使われていません。自社で導入するときは、どの規模・種類のChangeからタスク分割を必須にするか、運用ルールとして線引きしておく価値があります。

標準変更テンプレートは、他の申請アイテムと同じ画面に並ぶ

sc_cat_itemのクラスを絞り込むだけで、6件の標準変更テンプレートがカテゴリと価格つきで一覧に出てきました。Service Catalogの管理画面を素のまま開くと、これらは他の一般的な申請アイテムと見分けがつかない形で並びます。カタログの棚卸しをするときは、クラス列（sys_class_name）でstd_change_record_producerを除外するか、逆にそれだけを抽出するかを最初に決めておくと、Change由来のアイテムを取り違えずに済みます。

連携を設計するときに決めること

ここまでの実測をもとに、4つの連携について推奨するあるべき姿を先に示します。

推奨するあるべき姿

Emergency Changeは、Incidentの「Create Emergency Change」からの起票を標準経路とします。障害対応中のリードタイムを優先し、承認前レコードが増える分はCAB議題化の基準（後述）で絞り込みます
Standard Changeは、承認済みの標準変更カタログ（std_change_record_producer）経由の起票に限定します。新規作成画面には出さない設計（available_in_ui=false）をそのまま踏襲し、フォームからtypeを直接standardへ変更できない状態を維持します
Affected CI（task_ci）は、計画段階で対象範囲を広めに登録し、appliedは実施後に確定する運用とします。計画時点でのCI登録を必須項目にはしません
CAB議題化は、cab_required単独ではなくType（Normal／Emergency／Standard）×Risk（High以上）×Conflict Detectionの結果、の組合せで判定する基準を設けます

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

設計例

表から読み取れる重要事項は、Emergency起票とStandard起票の経路をそれぞれ1本に固定すると、審議対象を絞り込みやすくなる点です。変更してよいのは公開範囲やCI登録タイミングの運用ルールで、テーブル継承で実現している標準変更カタログの接続構造そのものは変更しません。

例外：影響範囲が自明な軽微な変更（設定ファイル1点の書き戻し等）は、Standard相当の定型作業として扱い、Emergency経路は使いません。CAB議題化もType×Risk×Conflictの組合せ判定から除外してよい対象です。

検証：起票経路の集計（Emergency起票のうちUIアクション経由の比率）と、CAB議題1回あたりの審議件数を月次で確認し、基準の妥当性を見直します。

用語

OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNowが無償で提供する個人検証用インスタンス
CAB：Change Advisory Board。変更を審査する会議体
RFC：Request for Change。変更要求のこと
Record Producer：入力フォームから新規レコードを作成する、Service Catalogのアイテム種別

検証範囲とおことわり

検証環境：Australia PDI（patch3）/ OOTB / 2026-09-01 確認
件数はすべてOOTBの定義・デモデータの数です。本番環境やカスタマイズ済み環境では異なります
IncidentフォームでCreate Change Request／Create Emergency Changeの表示・非表示を目視で確認する検証は行っていません。UIアクション定義と表示条件のスクリプトからの推測です
実際にUIアクションを押してChangeを起票する操作は行っていません
標準変更カタログから実際に申請する操作は行っていません
Conflict Detectionを実行して衝突を検知する動作は確認していません（デモデータに実例が無いため）

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

IncidentのChange関連UIアクション：/sys_ui_action_list.do?sysparm_query=table=incident^nameLIKEChange^active=true
書き戻しビジネスルール：/sys_script_list.do?sysparm_query=collection=change_request^nameLIKELink
CAB関連ビジネスルール（3方向の実装）：/sys_script_list.do?sysparm_query=collection=cab_agenda_item^active=true^ORDERBYorder
影響CI（Change向け）：/task_ci_list.do?sysparm_query=task.sys_class_name=change_request
CAB議題：/cab_agenda_item_list.do
Change Task：/change_task_list.do
標準変更テンプレート（Catalog Item扱い）：/sc_cat_item_list.do?sysparm_query=sys_class_name=std_change_record_producer
テーブルの継承関係：/sys_db_object_list.do?sysparm_query=nameINstd_change_record_producer,sc_cat_item_producer

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

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

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

インシデント管理モジュールの連携機能 … Incident側から見た同じ接続経路
変更管理モジュールの概要 … Change自体の種別と承認経路
ServiceNowのCIはどのテーブルに入る？ cmdb_ciの102クラスを実機で確認 … CMDB側の構造

参考：

CAB Workbench（/cab）の入口はカレンダー1枚：ウィジェットも1個だけ … CAB画面の構成
State Transition Models（sttrm_model）：変更タイプごとに状態遷移を定義する仕組み … change_requestの状態遷移機構
グループ承認：N人を1つに束ねる仕組み（sysapproval_group） … CABの承認が複数人に届く仕組み
承認（Approval）運用手順書［有料・100円］ … Change承認を実機で1件動かした手順書