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

年末商戦やシステム統合の直前に、進行中の変更をまとめて止めたい場面があります。Brazil には、そのための標準機能 Change Lockdown が追加されました。期間と条件を決めて承認を通すと、該当する変更が On hold になります。

この記事では、まず公式ドキュメントの説明を整理し、そのあとアップグレードした PDI で実際に動かして、説明どおりに動いた点と動かなかった点を並べます。保留と競合検出は説明どおりに動きました。一方、承認フローは起動せず、Cancel 後の保留解除も自動では進みませんでした。そのため承認の標準経路は完了しておらず、保留と競合検出は、テスト用の補助操作（Scripts - Background）で Enforced にしたあとに確認しています。

検証環境：Brazil PDI（Australia からメジャーアップグレード）/ OOTB / 2026-10-09 確認

公式ドキュメントの説明

目的と使う場面

公式は、Change Lockdown を「変更管理者が進行中の変更の全部または一部を一時停止する機能」と位置づけています。使う場面は、計画外の大規模障害、重要な期間、決算などの財務イベントです。

（訳：Change lockdown は、変更管理者が進行中の変更の全部または一部を一時停止できるようにする。計画外の大規模な IT 障害、重要な期間、財務上のイベントで使う）

引用元：Change lockdown

Australia の公式ドキュメント（変更管理 192 ページ）に、lockdown を扱うページはありません。ブラックアウト期間のように、期間で変更を避ける仕組みはもともとありました。Brazil の Change Lockdown は、そこに承認の流れと、すでに進行中の変更を止める動きを足したものです。

操作できるロールと承認先

作成と管理には change_manager ロールが必要です。手順は Create a change lockdown にあります。メニューは「Change > Administration > Change Lockdown」と書かれており、実機では「Change > Change Lockdown」の位置にありました。

フォームの主な項目は次のとおりです。

• Name / Description：名前と目的

• Time zone：既定は Floating

• Filter by CI：オンにすると CI Condition タブが現れ、CI で対象を絞る

• Change Request Condition：保留する変更の条件

• Assignment group / Assigned to：承認依頼の宛先

• State：読み取り専用。新規は Draft

期間は Schedule Entries に1件以上入れます。エントリが無いと、lockdown は効力を持ちません。

4つの状態と動き

状態ごとの動きは Change lockdown states に表があります。

起点は Draft、橙は承認待ち、緑は変更が保留される状態、灰色は終了です。

• Draft：条件と期間を編集できる。保留中の変更はない。操作は Preview / Update / Request Approval / Delete

• Awaiting Approval：承認レコードが作られる。保留中の変更はまだない。操作は Preview / Revert to Draft / Cancel Lockdown / Delete

• Enforced：承認済みで有効。該当する変更が Schedule Lockdown Changes に入り、On hold が true になる。操作は Cancel Lockdown / Delete

• Cancelled：終了。取り消しも再利用もできない。操作は Delete のみ

却下された場合は Draft に戻ります。期間を縮めるか条件を絞って、承認を依頼し直す流れです。管理手順は Manage a change lockdown にあります。

Preview と最大件数

Draft と Awaiting Approval では Preview で、止まる変更を一覧できます。ダイアログには番号、短い説明、モデル、種別、状態、計画の開始日と終了日が並びます。

一覧の件数は、プロパティ com.snc.change_management.lockdown.preview.max_changes で決まります。出荷時の値は 1000 で、変更には sn_change_admin ロールが必要です。上限は表示だけが対象で、保留は該当する全件に行われると公式は説明しています。手順は Set the lockdown preview maximum にあります。

競合検出と Scheduling assistant の扱い

Brazil では競合の種類に Inside Change Lockdown が加わりました。有効な lockdown の期間と重なる変更を見つける種別です。公式の要点は次の3つです。

• 競合検出は、メンテナンスウィンドウやブラックアウトの確認と同じ実行の中で lockdown も確認する

• 期間内の変更を作成または再スケジュールすると、システムが自動で保留する

• Scheduling assistant は、メンテナンスウィンドウの候補を出すとき Enforced の期間を除外する

（訳：Scheduling assistant は、メンテナンスウィンドウを提案するとき、Enforced の lockdown 期間を除外する）

引用元：Change lockdown

競合検出の実行契機は、変更の状態、CI、計画の開始日・終了日の変更です。詳細は Change lockdown conflict detection にあります。lockdown を競合検出の対象にするかどうかは、プロパティ change.conflict.lockdown（出荷時 true）で切り替わります（Conflict detection properties）。さらに、変更モデルの状態に Allow Conflict Detection 属性を付けると、競合検出はその状態に着いたときだけ動きます（Limit conflict detection to a change model state）。

実機で見た構成

アップグレード後の PDI で、lockdown に関わる定義を調べました。

テーブルとメニュー

• cmn_schedule_lockdown「Change Lockdown」：Condition Schedule を継承。固有項目は name、change_condition（既定 active=true）、change_condition_table（change_request）、filter_by_ci（既定 true）、state（既定 draft）

• cmn_schedule_lockdown_change「Schedule Lockdown Change」：変更と lockdown を結ぶ。継承なし

• state の選択肢：draft / awaiting_approval / enforced / cancelled

• モジュール：Change > Change Lockdown（change_manager）

ボタンの表示条件

ボタンの表示条件は Script Include の ChangeLockdown にまとまっています。

• Preview：Draft か Awaiting Approval で、スケジュールエントリがある

• Request Approval：Draft

• Revert to Draft：Awaiting Approval

• Cancel Lockdown：Awaiting Approval か Enforced

Draft に Cancel Lockdown が無い点は、公式の manage ページ（Draft でも Cancel できると読める書き方）と食い違います。

承認とリリースを担うフロー

Global スコープで Published、有効なフローが4つあります。

• Change Lockdown - Request Approval：cmn_schedule_lockdown の更新（条件 state=awaiting_approval）で起動し、承認を作って Enforced に進める

• Change Lockdown Request Approval for Specified State：Ask For Approval と Wait For Condition を持つ

• Change Lockdown - Reinstate Change Requests：chg_mgt_worker の作成で起動し、保留を外す

• Change Lockdown Handler：Change - Conflict Detection から呼ばれ、保留を調整する

Cancel の処理は、chg_mgt_worker（type は Change Lockdown）を1件作ります。

プロパティ

• change.conflict.lockdown = true

• com.snc.change_management.lockdown.preview.max_changes = 1000

• 競合の種別に Inside Change Lockdown（値は lockdown）

作成と Preview

テスト用の lockdown を作りました。名前は「年末商戦フリーズ」、2026-10-12 の1日を全日で止める設定です。変更の条件は「短い説明が検証用の接頭辞で始まり、有効であること」としました。Filter by CI はオフです。

• ①State は読み取り専用で、新規は Draft から始まる

• ②Change Request Condition で、止める変更を条件で絞る

• ③Schedule Entries で期間を決める。エントリが無いと Preview は使えない

Preview を押すと、今の条件に該当する変更が表示されます。このときテスト用の変更は2件ありました。期間内の変更 A と、期間外の変更 B です。表示されたのは A の1件だけでした。

①のとおり、承認前に影響範囲を確かめられます。

承認レコードが作られない

ここから公式の説明と食い違いました。Request Approval を押すと、State は Awaiting Approval に変わり、ボタンは Preview / Revert to Draft / Cancel Lockdown に切り替わりました。公式の手順では、レコードを開き直すと Approvers タブに承認レコードが出ます。

実機では、②の Approvers タブが空のままでした。承認テーブルにもレコードはなく、lockdown 用のフローが動いた記録もありません。やり直しても結果は同じでした。

承認依頼のボタンは State を変えるだけで、承認レコードの生成は Flow「Change Lockdown - Request Approval」が受け持っています。このフローは cmn_schedule_lockdown の更新を契機に動く設計です。ところがフローの起動登録（record trigger）に、このテーブルがありませんでした。

これは、Australia からアップグレードしたこの PDI で観察した状態です。新規に払い出した Brazil インスタンスで同じことが起きるかどうかは、確かめていません。

自分の環境で確かめる方法

次の一覧は、いずれも参照だけです。

• フローの起動登録：/sys_flow_record_trigger_list.do?sysparm_query=table=cmn_schedule_lockdown（0件なら登録なし）

• 承認レコード：/sysapproval_approver_list.do?sysparm_query=source_table=cmn_schedule_lockdown

• フローの実行履歴：/sys_flow_context_list.do?sysparm_query=source_table=cmn_schedule_lockdown

Awaiting Approval のまま承認が来ないときは、この3つを上から順に見ます。起動登録が0件なら、担当者の操作を疑う前に、フローの状態を調べる段階です。

承認から Enforced へ進める標準経路は、この PDI では動きませんでした。以降の保留と競合は、テスト用に Scripts - Background で State を enforced に更新し、保留を設定する処理（ChangeLockdown の setChgRequestsOnHold）を実行して確かめています。承認フローが内部で使う部品と同じもので、公式の手順ではありません。本番で State を直接書き換える運用は想定できません。

Enforced 後の保留

Enforced にしたあと、期間内の変更 A は次の状態になりました。

• On hold が true

• On hold reason に「This record is placed on hold due to the lockdown record（lockdown 名）」

• lockdown の Schedule Lockdown Changes タブに登録

②の2件目は、Enforced になったあとに作った変更 C です。理由は次の節で説明します。Enforced の画面に残るボタンは Cancel Lockdown と Delete だけです。条件も期間も編集できなくなるため、直したいときは Cancel して作り直します。

CI の無い変更の保留

公式は、期間内に変更を作成または再スケジュールすると、自動で保留されると説明しています。

（訳：lockdown の期間内に変更を作成または再スケジュールすると、システムは自動的にその変更を保留する）

引用元：Change lockdown

これを確かめるため、Enforced のあとに期間内の変更 C を作りました。C は主 CI も影響 CI も持たない変更です。結果は保留されず、Conflict status は Not Run のままでした。なお、CI の無い変更 A は、Enforced にした直後の保留設定の処理で保留されています。保留されなかったのは、Enforced のあとに新規作成した変更 C です。

原因は競合検出の前提条件にあると見ています。実機のスクリプトでは、競合検出モードが advanced でも、構成アイテム（CI）も影響を受ける CI も持たない変更は、検出そのものを実行しない作りです。lockdown の判定は競合検出の中にあるため、このPDIでは、Enforced 後に作成した主 CI・影響 CI ともに無い変更が止まりませんでした。

C に CI を付けて保存すると、同じ保存の中で競合検出が走りました。

• Conflict status が Conflict に変わる

• On hold が true になり、保留の理由に lockdown 名が入る

• Conflicts タブに Inside Change Lockdown が追加される

• ①Change is currently on hold が出る

• ②On hold reason に、どの lockdown が止めたかが残る

• ③Conflict status は Conflict になる

同じ画面には Not In Maintenance Window という別の競合も出ています。こちらはメンテナンスウィンドウに関する競合で、lockdown とは別に判定されます。

期間外へ戻したときの動きも試しています。変更 B（CI あり）を期間内へ移すと、保留と Inside Change Lockdown が付きました。期間外へ戻すと保留と理由が外れ、Inside Change Lockdown も消えます。公式の「再スケジュールで競合が消え、保留の理由が消える」という説明と一致する結果です。

自分の環境で確かめる方法

• 競合の一覧：/conflict_list.do?sysparm_query=type=lockdown

• 保留中の変更：/change_request_list.do?sysparm_query=on_hold=true^on_hold_reasonLIKElockdown

• CI の無い変更の件数（読み取りだけの Scripts - Background）

var ga = new GlideAggregate('change_request');
ga.addQuery('active', true);
ga.addNullQuery('cmdb_ci');
ga.addAggregate('COUNT');
ga.query();
if (ga.next()) gs.print('CI が空の有効な変更: ' + ga.getAggregate('COUNT'));

CI が空の変更が多い環境では、Enforced 後に作る変更のうち保留されないものが残る可能性があります。

Cancel 後の保留解除

Enforced の lockdown に対して Cancel Lockdown を押すと、State は Cancelled になりました。公式は、Enforced を Cancel すると保留中の変更が解除され、On hold 列が true から false に変わると説明しています。

実機では、②の On hold 列が true のままでした。Cancel の処理は、保留を解除する作業用のレコード（chg_mgt_worker）を1件作る作りです。このレコードは Waiting のまま進まず、約4分待っても保留は残りました。変更を自動で再開させる Flow「Reinstate Change Requests」も、この作業用レコードの作成を契機にします。承認のときと同じく、フローが動かない状態でした。

自分の環境で確かめる方法と、検証用の補助操作

• 作業用レコード：/chg_mgt_worker_list.do?sysparm_query=type=lockdown（State が Waiting のまま進まなければ、解除が止まっている）

• 保留の残り：/cmn_schedule_lockdown_change_list.do（Cancelled の lockdown に紐づく行の変更が On hold のままでないか）

保留が残ったとき、この PDI では次の Scripts - Background で解除できました。公式の手順ではなく、検証用の補助操作です。このテスト環境の変更3件に対してだけ確かめており、読者向けの回避手順としては勧めません。

// 検証用の補助操作（公式手順ではない）。<lockdown の sys_id> を置き換える
new global.ChangeLockdown().releaseChangeRequests('<lockdown の sys_id>');

実行後は、変更 A、B、C の On hold が false になり、保留の理由も空になりました。解除の処理そのものは正常に動きます。

公式には、Cancel の前から別の理由で保留中だった変更は、Cancel 後も保留のままという注意書きもあります。この補助操作が、別の理由で保留中の変更や、複数の lockdown に該当する変更にどう働くかは確かめていません。確かめるまでは、実際の環境で使わないでください。

運用チェックリスト

観察した動きを踏まえ、運用の順に並べます。

1. 条件を決める：止める変更を、種別や担当グループなどの条件で具体的に書く。Filter by CI を使う場合は、CI の条件も決める

2. 期間を入れる：Schedule Entries を1件以上入れる。全日か時間指定か、タイムゾーンを決める

3. Preview で件数を見る：想定外の変更が混ざっていないか確かめる。上限（既定 1000）を超える見込みなら、先にプロパティを確認する

4. 変更に CI を入れる運用にそろえる：Enforced 後に作る変更で CI が空だと、競合検出が走らず保留されない可能性がある

5. 承認を依頼し、承認レコードを確認する：Approvers タブに承認レコードが出ることを見る。出なければ、フローの起動登録と実行履歴を調べる

6. Enforced 後に On hold を確認する：Schedule Lockdown Changes タブで、止まるはずの変更が On hold の true か確かめる

7. 期間内に新規の変更を1件作って試す：CI を入れた変更で、Inside Change Lockdown の競合と保留が付くか確かめる

8. 解除は Cancel のあとに確認する：On hold 列が false に戻ったか、作業用レコードが完了したかを見る。戻らなければ、保留が残った変更を個別に調べる

期間が終わったあとの State と保留解除の動きは確かめていません。導入前に、期間終了後の状態と保留解除も確認対象に含めます。

実機を見て気づいたこと

• 状態の表と UI の動きが違う箇所がありました。公式の手順は Draft でも Cancel できると読める書き方ですが、状態表とボタンの表示条件では、Cancel は Awaiting Approval と Enforced だけです

• 画面の状態は動いても、裏のフローが動いていなければ、承認と解除は進みません。Awaiting Approval で Approvers が空なら、承認が来ないのは担当者の問題とは限りません。フローの実行履歴を先に見るのが近道です

• Enforced 後に作る変更の保留は、期間よりも CI の有無に左右されました。大型イベントの前に、テスト用の変更を1件作って、保留されるか確かめておくと安全です

検証範囲とおことわり

• 検証は、Australia から Brazil Patch 0 へアップグレードした PDI で行いました。承認フローの起動登録が無い状態は、このインスタンスで観察したものです。新規インスタンスでは未確認です

• 承認から Enforced への標準経路は確認できていません。Enforced と保留解除の確認には、Scripts - Background で標準の処理を呼びました

• Scheduling assistant が Enforced の期間を避けて候補を出す動き、Allow Conflict Detection 属性を付けた変更モデルでの動き、承認者への通知は確認していません。Scheduling assistant の説明は、公式の lockdown 概要ページの記述をそのまま引用したものです

• 期間の境界時刻と、タイムゾーンを指定した lockdown の動きは確認していません。今回は全日の Floating 設定のみです

• テスト用のレコードはすべて削除しました。メール送信は無効の環境で、外部へのメールと通信は行っていません

• 公式 Docs は Brazil 版（2026-09-10 更新）を参照しました

関連記事

• 変更管理モジュールの概要

• 変更管理モジュールのプロパティ

• 変更管理モジュールの自動設定構成