[Brazil調査] ITIL change process の割り当て：独自モデルを Normal の代表にする

Normal、Standard、Emergency の変更を API で作るとき、使われるモデルはこれまで標準の3つに固定でした。自社用に作った変更モデルを Normal の代表にしたい場合は、Brazil で追加された変更モデルの「ITIL change process」項目を使います。割り当てると、ChangeRequest API はそのモデルで変更を作ります。

割り当ては、公式の説明どおりに動きます。食い違うのは、同じ種別を2つのモデルに割り当てたときです。公式は「システムが変更をブロックする」と書いていますが、実機は保存を通し、先に割り当てたモデルの値を自動で空にしていました。

公式ドキュメントの説明

変更モデルに、そのモデルが Normal、Standard、Emergency のどの ITIL プロセスを表すかを指定できます。これまで API の newNormal、newStandard、newEmergency は、標準で入っている3つのモデルに固定されていました。Brazil では、独自に作ったモデルも代表にできます。

（訳：これまで ChangeRequest API の newNormal、newStandard、newEmergency は、標準提供の特定の変更モデルから変更を作っていた。種別ごとに1つのモデルが決まっていた）

引用元：ITIL change process assignment for change models

API がモデルを決める手順は、公式では次のとおりです。

• 種別に対応する、有効で指定済みのモデルを探す

• 見つかればそのモデルで変更を作る

• 無ければ、その種別の標準のモデルを使う

設定する人は change_manager ロールを持つ人です。公式は次の規則も書いています。

• 同じ種別を指定できる有効なモデルは、ドメインごとに1つ

• 2つ目を有効にすると、システムが変更をブロックする

• すでに指定されているモデルへの書き込み権限が無いと、保存がブロックされる

手順は Assign an ITIL change process to a change model にあります。

変更モデルは何を決めるものか

ITIL change process の割り当てを理解するには、まず変更モデルの役割を押さえる必要があります。公式は、変更モデルを「よくある変更のユースケースに合わせた、目的に適したプロセスを用意する仕組み」と位置づけています。

（訳：変更モデルは、特定のよくある変更のユースケースに合わせて目的に適したプロセスを整え、変更要求を効率化する）

引用元：Change model management

モデルは、状態や遷移、承認ポリシー、テンプレートの組み合わせで定義されます。注目したいのは、選ぶモデルによって、その後に通る状態が変わる点です。公式の整理は次のとおりです。

• Normal：New、Assess、Authorize、Scheduled、Implement、Review、Closed をすべて通る

• Standard：事前承認済みのため、Assess と Authorize を飛ばして New から Scheduled へ進む

• Emergency：Assess を飛ばすが、Authorize は通る

状態の進み方は State progression for normal, standard, and emergency changes にあります。標準の Normal モデルには、実機でも8つの状態が並んでいました。つまり、API がどのモデルを選ぶかは、変更の承認の流れそのものを選ぶことにつながります。

モデルを新しく作る手順は Create a Change model、全体の構成は Enhanced Change data model に書かれています。

Australia の場合

Australia の変更管理には、この項目の説明がありません。公式の Brazil 向け差分ノートで、新機能として載っています。引用元：Australia から Brazil への変更管理の差分

公式の Previously の記述から、Australia では API が標準の3モデルを使い続け、自社モデルを使うには API の呼び出し側を直す必要があったと読めます。Australia のインスタンスでは確かめていません。

Brazil PDI の状態

フォームの項目

標準の Normal モデルを開くと、Implementation states の隣に「ITIL change process」があり、初期値は -- None -- です。

選択肢は Standard、Normal、Emergency の3つです。辞書では、項目 itil_change_process は 2026-09-15 に作られた String 型で、既定値は空でした。

標準の6モデルは次のとおりです。

• Normal / Standard / Emergency

• Change Registration / Cloud Infrastructure / Unauthorized Change

どのモデルも ITIL change process は空でした。アップグレード後も、割り当てるまでは従来どおり標準の3モデルが使われる状態でした。

割り当てた独自モデルの扱い

Normal を複製した独自モデル A を作り、ITIL change process に Normal を指定しました。そのうえで、スクリプトで newNormal を呼びました。

• 割り当て前：newNormal は標準の Normal を返す

• 割り当て後：newNormal は A で変更を作り、種別は normal

• Standard と Emergency：標準のモデルのまま

切り替わるのは、指定した種別だけです。モデルを選ぶ処理は、有効で table_name が change_request のモデルのうち、その種別が指定されたものを探します。複数あれば sys_id の昇順で先頭が選ばれ、無ければ標準の sys_id を返します。

重複指定時の動き

ここが公式の説明と食い違う箇所です。同じ Normal を指定した2つ目のモデル B を作ったところ、保存は成功し、先に指定していた A の値が空に変わっています。B だけが Normal の代表になり、newNormal も B を使っていました。

• A：割り当てが空に変わった

• B：Normal の代表になった

• 標準の Normal モデル：空のまま

この重複時の動きは、業務ルールで実装されています。詳しくは後述の「公式の説明と実機の差を整理する」に画面を載せました。

既存の画面や処理への影響

割り当ては API の選び方を変えるため、影響は「newNormal などを呼んでいる場所」に及びます。実機で、スクリプトに newNormal、newStandard、newEmergency の文字列を含む設定を探しました。

• UIアクション：Create Normal Change が2件、Create Emergency Change が2件

• ビジネスルール：Generate Template On Approval が1件

UIアクションの名前から、画面のボタンも同じ API を使っている可能性があります。ただし、これらが ChangeModelChgReqAPISNC 経由で動くかどうかまでは、今回の確認範囲に入っていません。割り当てる前に、自社で使っているボタンや連携が新しいモデルでも動くかを、テスト用の変更で試す必要があります。

特に注意するのは、独自モデルの中身です。Normal を複製しても、状態や遷移、承認ポリシーは複製元と同じとは限りません。実機の標準 Normal は8つの状態を持ちますが、複製した直後のモデルに同じ状態が付いてくる保証はありません。割り当てた瞬間から、newNormal を使う経路で作る Normal 変更は、そのモデルで作られます。

割り当てるまでの手順

公式の手順を、実機のフォームに沿って整理します。設定にはロール change_manager が必要です。

1. All > Change > Administration > Change Models を開き、代表にしたいモデルを開く（新規なら New で Name を入れる）

2. ITIL change process で Standard、Normal、Emergency のいずれかを選ぶ。代表にしないなら -- None -- のままにする

3. Save を押す

保存できないときについて、公式は、同じ種別を持つ別の有効モデルを無効にするか、別の種別を選ぶよう案内しています。実機では2つ目の保存が通るため、保存できない原因として最初に疑うのは、すでに指定されているモデルへの書き込み権限です。

プラグインの前提は Activate Change Management - Change Models に書かれています。変更管理全体の設定は Configuring Change Management から辿れます。

他の機能との関係

同じ Brazil の変更管理では、Change Lockdown が追加されました。lockdown は進行中の変更を止める機能で、ITIL change process は新しく作る変更のモデルを決める機能です。働く場面が違うため、組み合わせた動作は試していません。lockdown の検証は Change lockdown とあわせて、別の記事にまとめています。

Brazil の変更管理の新機能は、公式の差分ノート Australia から Brazil への変更管理の差分 に一覧があります。この機能は、そこで Scaled Change と並んで紹介されています。

実務で何をするか

• 自社モデルを Normal の代表にするなら、割り当てだけで API の呼び出し側を直さなくて済む

• 割り当て前に、すでに別のモデルが同じ種別を持っていないか一覧で確認する。持っていると、保存した時点でエラーを出さずに相手の値が空になる

• 標準の Normal、Standard、Emergency モデルは編集せず残しておく。指定を外せば、API は自動で標準に戻る

• 複製して新しいモデルを作るときは、Default change model の項目に注意する

• 割り当ての結果は、スクリプトで newNormal を呼んで確認する。画面だけでは API が選ぶモデルまでは分からない

• 戻すときは、独自モデルの ITIL change process を -- None -- に戻す方法が考えられます。今回確かめたのは独自モデルの削除で、削除すると標準モデルに戻りました。-- None -- に戻す操作は試していません

実機で気づいたこと

複製したモデルが既定のモデルを奪う

検証の1回目、Normal を複製してモデルを作ると、複製元の Default change model がオンのまま作られます。保存すると、標準の Normal の Default change model が false に変わりました。標準の Normal は、自分でオンへ戻しています。モデルを複製するときは、この項目を最初に外してください。

「ブロック」は先に割り当てた側の値の解除だった

公式の文章は、2つ目の保存が失敗するように読めます。実機は違いました。スクリプトからの保存は成功し、先の割り当てが消え、エラーにもなりませんでした。フォームで保存したときの表示は確かめていません。表示の有無にかかわらず、誰かの割り当てを上書きしても気づきにくい挙動です。変更管理者が複数いる環境では、割り当ての変更を事前に共有しておくと安全です。

割り当てで変わる範囲

項目は1つでも、効果は大きい設定です。選ぶモデルが変わると、状態も承認も変わります。影響は全部に及ぶため、本番で触る前に、変更管理者のレビューを通し、割り当て前後で getModelOrDefault の結果が意図どおりかを確かめる流れにします。

標準モデルは触らなくても使える

標準の6モデルはすべて空のままで、API は標準の3モデルを使い続けます。この機能は、必要なときだけ割り当てる追加の仕組みです。アップグレードしただけで、既存の変更の作られ方は変わりません。

確認に使った API 呼び出し

今回の確認は、Scripts - Background に次のような処理を流して行いました。変更レコードは保存せず、API が返すレコードのモデルと種別だけを見ています。

var id = ChangeModelChgReqAPISNC.getModelOrDefault('normal');
var m = new GlideRecord('chg_model');
m.get(id);
gs.print(m.getValue('name'));

この処理は、有効なモデルから指定済みのものを探し、無ければ標準の sys_id を返します。画面の ITIL change process を見るだけでは、有効かどうか、table_name が change_request かどうかまでは分かりません。API が最終的にどのモデルを選ぶのかを見るには、この呼び出しが最短です。

newNormal を直接呼ぶと、そのモデルで初期化された変更の GlideRecord が返ります。種別（type）が normal になっていることと、chg_model が割り当てたモデルになっていることを、あわせて見ました。

実機で割り当てを試すときの確認項目

自分の環境で試す場合は、次の順で進めると安全です。

1. 本番ではなく、検証用のインスタンスで試す

2. 標準の Normal の ITIL change process が空であることを確認する

3. 複製したモデルでは、Default change model をオフにしてから保存する

4. ITIL change process に Normal を指定して保存する

5. Scripts - Background で ChangeModelChgReqAPISNC.getModelOrDefault('normal') を実行し、返ってくる sys_id が自分のモデルかを確かめる

6. 画面の Create Normal Change ボタンで、新しい変更がそのモデルの状態から始まるかを見る

7. 終わったら ITIL change process を -- None -- に戻す

手順5は、API が実際に選ぶモデルを直接見られる確認方法です。画面の項目だけでは、有効かどうかや table_name の条件を満たしているかまでは分かりません。

公式の説明と実機の差

chg_model には、ITIL change process に関する業務ルールが2件あります。

①は保存の後で動き、同じ種別を持つ他の有効モデルの値を空にして更新します。ブロックは行いません。②は保存の前で動き、すでに指定されているモデルに書き込み権限が無いときだけ保存を止めます。

食い違いは、読み方によって2通りに解釈できます。

• 公式の「ブロック」は、書き込み権限が無い場合の保存拒否だけを指している

• 公式の「ブロック」は、重複時の挙動を指しているが、実装は自動解除に変わっている

実機で確認できたのは、重複時に保存が通り、他のモデルの値が空になる動きまでです。どちらの解釈が正しいかは、公式の記述だけからは決められません。そのため、割り当ての運用は、実機の動きを前提に組むのが現実的です。

具体的には、次の3点を運用に入れます。

• 割り当ての変更は、変更管理者が1人で行うか、事前に共有する

• 割り当てを変えた直後に、getModelOrDefault の結果を確認する

• どのモデルがどの種別を持つかを、一覧で定期的に見る

スクリプトからの保存ではエラーになりませんでした。フォームで保存したときの表示は確かめていないため、上書きされた側の担当者は、気づかないまま別のモデルで変更を作り続ける可能性があります。

用語

• ITIL change process：変更モデルが代表する変更の種別（Standard、Normal、Emergency）を指定する項目

• 変更モデル：状態、遷移、承認、テンプレートを束ねて、変更の進め方を決める仕組み

• ChangeRequest API：Normal、Standard、Emergency の変更を作る標準のスクリプト API

• Default change model：新規の変更で既定になるモデルを示す項目

調べたURL

• 公式：ITIL change process assignment for change models

• 公式：Assign an ITIL change process to a change model

• 実機：辞書は /sys_dictionary_list.do?sysparm_query=name=chg_model^element=itil_change_process

• 実機：業務ルールは /sys_script_list.do?sysparm_query=collection=chg_model^nameLIKEITIL

• 実機：変更モデルは /chg_model_list.do

検証範囲とおことわり

• 標準の Normal モデルを複製した独自モデルで、Normal の割り当てだけを試しました

• Standard、Emergency の割り当て、ドメイン分離、書き込み権限が無いユーザーの保存は動かしていません

• 変更レコード自体は保存せず、API が返すレコードのモデルと種別を確認しています

• 検証用モデルは作成後に削除し、残りが0件であることを確認しています

• 1回目の検証で標準 Normal の Default change model が false になったため、true に戻しました。標準 Normal の更新日時は変わっています

• 重複時の保存は Scripts - Background の GlideRecord で試しており、フォームで保存したときの警告やエラーの表示は確かめていません

• ドキュメントのブロックの記述が、別の条件（権限、ドメイン）を指す可能性は確認できていません

関連記事

• [Brazil調査] Change Lockdownの承認・保留・解除：PDIで確認できた範囲