変更管理モジュールのロール

変更管理者を割り当てていないのに、サービスデスクの担当者が Change Request を起票し、実装まで進められます。change系の専用ロールは7つありますが、実際に変更を書き込む権限の大半は itil が運ぶという設計によるものです。Australia の PDI をデフォルト設定のまま開きました。参照・起票更新・タスク実施・変更管理・CAB運営・設定管理という6つの職務があります。どのロールを組み合わせれば最小権限になるかを、change_request・change_task に紐づく121件のACLの実測から確かめます。

この記事で分かること

• 参照・起票更新・タスク限定・変更管理・CAB運営・設定管理という6つの職務に、どのロールを組み合わせるか

• query_range・report_view・list_editが、readやwriteと何を分けて判定しているか

• 複数のACLが同じ項目に重なったとき、どの順序でAND/OR判定されるか

• itilとsn_change_writeのどちらを選ぶかを、他プロセスへのアクセス範囲から決める基準

• 保有者数の実測から、付与しすぎているロールをどう見つけるか

先に押さえておくこと

• change系の専用ロールは7つで、書き込み権限の大半はitil経由で配られている

• typeは新規作成時のみ、on_holdは保存そのものを止める形で編集を制限している

• 一般利用者はロールなしでChange Requestを直接作成できない

• ロールは原則グループ経由で付与し、個人への直接付与は避ける

職務ごとのロールセット

先に、6つの職務とロールの対応を1枚で示します。参照だけの関係者にはsn_change_read、変更を起票・更新する担当者にはsn_change_write、CABを運営する担当者には専用ロールを足します。職務ごとに、最小限のロールを組み合わせる構成が基本形です。

この対応がなぜ成り立つのかを、ロールの定義とACLの実測で確かめます。

変更管理に関わるロール

sys_user_role で名前に change・chg・cab を含むロールを検索すると、Change Managementと直接関係するものは7件でした。ほかに表示モード切り替え用の view_changer が1件該当しますが、対象外とします。

7件すべてに公式説明（description）が入っています。itilも含めた8ロールを、参照・起票更新・タスク限定・変更管理・CAB運営・設定管理という6つの職務に当てはめて整理します。

表から読み取れる重要事項は、6つの職務のうち4つ（参照者・Change Task限定担当・変更管理者・CAB運営者）が単独のロールで完結する点です。起票・更新担当と設定管理者だけは、範囲の異なる2ロールから選ぶ形になっています。

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

（訳: 変更マネージャの役割）

sn_change_cab.cab_manager の説明も具体的です。

（訳: Change Advisory Boardの管理者）

sn_change_task_assigned_user の説明は割り当ての条件まで書かれています。

（訳: そのchange_taskがユーザーに割り当てられている場合、change_taskへアクセスできる）

変更管理者を代表して、change_manager の定義画面も確認しておきます。

引用元: /sys_user_role_list.do?sysparm_query=nameLIKEchange^ORnameLIKEcab^ORnameLIKEchg

ロールの包含関係

sys_user_role_contains を実測すると、change系7ロールは、管理系とitil系という2つの経路がsn_change_writeで合流する構造でした。

7ロールの階層を図にします。

管理系の経路はここまで一直線です。

sn_change_admin
  ├ change_manager --> sn_change_write
  │   └ sn_chg_soc.change_soc_admin
  └ sn_change_cab.cab_manager --> sn_change_write

itil側にはもう1本の経路があります。

itil --> sn_change_write --> sn_change_read

sn_change_write はさらに6ロール（template_editor・email_composer・cmdb_query_builderなど）を含みます。sn_change_read はさらに8ロール（cmdb_read・dependency_viewsなど）を含みます。

図の下位5ロール（change_manager〜sn_chg_soc.change_soc_admin）は、sn_change_admin が間接的にすべて含みます。1つ付けるだけで、下位5ロールがすべて有効になります。この一括包含によって、管理者ロールへの個別付与の手間を省けます。

itilが含むロールの総数は27件でした。27件の中にはsn_incident_write・sn_problem_write・sn_request_writeも含まれています。Incident・Problem・申請（Request）の書き込み権限も、同時に付与されます。change管理はそのうちの1つの経路にすぎません。

実際の割り当て数は、付録「ロール保有者数」にまとめました。

• 参考：ServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表からたどる … 割り当ての実態はここで追える

• 参考：ユーザー（sys_user）は1行＝1人 … 割り当て先となるユーザーテーブル

ACL評価の読み方

sys_security_acl で change_request と change_task を個別に集計すると、有効なACLはそれぞれ72件・49件、合計121件でした。nameLIKEchangeという部分一致では無関係テーブルが混入して470件というノイズになるため、テーブルごとのnameSTARTSWITH集計が必須です。

この表は、operationの種類ごとにACLの役割を切り分ける目的で作成しました（2026-09-01実測、有効なACLのみ）。

writeは43件（24＋19）で全体の3分の1を超えます。readの22件の2倍近くです。読むことは広く許し、書くことは細かく分ける方針が、この比率に表れています。deleteはあわせて5件だけでした。

readとwriteは、値そのものを見せる・書き換える権限です。query_rangeとreport_viewは、値の使い方を制限します。change_request.riskを実測すると、read専用のACLは存在せず、query_range（role=public）だけが定義されていました。一覧やレポートの絞り込み条件としてriskを使うことは誰でもできます。値そのものを見られるかどうかは別です。フィールド固有ACLが無い場合は change_request.* のread ACL（role=snc_internal）や change_request 自体のread ACL（role=sn_change_read）にフォールバックします。読み取りとquery_rangeは別のACL行で、片方があってももう片方が自動で付くわけではありません。

report_view（4件）は、change_request全体をレポートやPerformance Analyticsの集計対象にできるかを判定します。roleはsn_change_read・itil・sn_cim.improvement_coordinatorの3種類で、1件はロール指定がありませんでした。read権限とは別枠のため、フォーム上は読めてもレポートには出せない、という設定が可能です。

list_edit（4件）は、一覧画面のセルを直接編集できるかの権限です。対象はchange_request.type・state・on_hold・unauthorizedの4項目に絞られ、4件ともrole=nobodyでした。write ACL自体はitilやsn_change_writeに許可されていても、一覧からの即時編集だけは誰にも許可されていません。フォームを開いて保存する経路だけを使わせる設計です。

導入時に確認するのはquery_rangeの対象範囲です。既定ではpublicが多く、フィルタ条件として公開して問題ない項目かどうかを見ます。list_editのrole=nobody指定は変更しません。一覧編集を許可すると、フォーム側のBusiness Rule・Client Scriptを経由しない書き換えが起きます。後述するtype・on_holdのゲートを迂回する経路になります。

• 参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACLの基本的な読み方

複数のACLが重なったときの評価順序

有効121件のうち、条件式（condition）を持つのは19件でした。change_requestが4件、change_taskが15件です。

条件式の内訳を整理します。

1つの項目に対して、複数のACLが同時に定義されている場合もあります。change_task.state（write）を実測すると、3件のACL行が同時に存在していました。

• role=sn_change_task_assigned_user、条件式は change_request.on_hold=false と assigned_to=自分（DYNAMIC）

• role=itil・task_editor、条件式は change_request.on_hold=false のみ

• role=sn_change_write、条件式は change_request.on_hold=false のみ

行の中はANDで、行同士はORで評価されます。1件の中では、役割と条件式の両方を満たす必要があります。3件のうちどれか1件を満たせば、書き込みが通る仕組みです。sn_change_task_assigned_userを持つ担当者は、自分に割り当てられたChange Taskだけをon_hold=falseの条件下で書き込めます。itilやsn_change_writeを持つ担当者は、割り当てに関係なく同じ条件で書き込めます。3件ともadmin_overridesはfalseです。管理者であっても、on_hold=falseという条件を満たさない限り書き込めません。

親テーブルであるtaskへ遡って判定されることはありません。task単体のACLはreport_view3件・delete1件の計4件のみで、read・write・createの直接ACLを持ちません（タスク管理モジュールの実測）。change_requestとchange_taskの読み書き権限は、この親テーブル側の空白を埋める形で、すべて自前で定義されています。ACLが「見つからない」という相談を受けたら、taskまで遡っても手がかりが無い前提で、change_request・change_task自身のACLだけを確認します。

判定の全体像を図にします。

sys_security_acl_roleを実測すると、ロールが指定されている行は延べ126件で、11種類のロールが使われていました。もっとも多いのはitilの25件、次いでpublicの24件です。publicの大半はquery_range（取得範囲の既定値公開）で、読み書きそのものの権限ではありません。

change_request側の条件式はわずか4件で、itilを持っていれば担当していない変更にも読み書きできます。change_task側は15件中12件がassigned_to=自分で、sn_change_task_assigned_userロールとセットになって初めて意味を持つ設計です。

role=nobodyの9件のうち、4件は前節のlist_edit（type・state・on_hold・unauthorized）です。残る5件のうち1件はchange_task.state（list_edit）です。ほかの4件は、change_request.on_hold_task・conflict_status・conflict_last_run・typeへのwrite ACLにあたります。on_holdやコンフリクト検知の実行結果は、Business Ruleやスクリプトが計算して埋める値です。人が直接書き込む項目には含まれません。

スクリプトで判定するACLは4件で、change_requestに3件（read1・type write2）、change_taskに1件です。change_request.typeのスクリプトは次の節で扱います。

• 参考：変更の流れを決める Change Model（chg_model） … chg_modelの構造はここで扱っています

• 参考：Access Analyzer：「見えない」の理由を層で切り分ける … 判定の層を順に確認する道具

typeとon_holdによる編集制限

Incidentの記事では、incident_state NOT IN 7,8という条件式が26件のACLに入っており、クローズ済みレコードをまとめて守っていました。Changeの条件式19件の中に、state値やClosed・Canceledを理由に書き込みを拒否するものはありません。編集の制限はどこにあるのでしょうか。

答えは、レコードが閉じたあとを縛るのではなく、変更が起きる瞬間ごとにゲートを置く設計にありました。

typeの変更は、新規作成時だけに限定されています。change_request.typeのwrite ACLには、isNew()でなければ拒否するスクリプトの行と、role=nobodyの行が両方存在します。admin_overridesもfalseで、管理者でも登録後にtypeを変え直すことはできません。type・state・on_hold・unauthorizedの4項目は、一覧画面からの直接編集（list_edit）も同じくrole=nobodyで塞がれています。フォームを開いて保存する経路以外から、これらの項目を動かす手段はありません。

on_holdはさらに徹底しています。Business Rule「Read only State」を読むと、直前がon_hold=trueだったレコードは、on_holdをfalseへ戻す保存も含めて中断されます。フィールド単位の読み取り専用にとどまらず、保存そのものを止める実装です。on_holdを解除できないという相談を受けたら、まずこのBusiness Ruleを疑います。

Closedへ進める場面では、Business Rule「Mandatory Closure Information」がclose_code・close_notesの入力を確認します。どちらかが空、またはclose_codeが選択肢定義外の値だと、クローズ自体が中断されます。クローズしたあとの記録を凍結するより、クローズに入る手前で必須項目を確認する設計です。

• 参考：ServiceNowでadminを配らずに開発させるには？ Delegated Developmentで権限を絞る … 強い権限を持つロールでも通らない設計の考え方

• 参考：変更管理モジュールの概要 … typeの使い分け全体はここで整理しています

承認者とCAB出席者の決め方

change_requestには、ロールとは別に、承認とCABの仕組みがあります。ここだけはロールの一覧では説明がつきません。

sysapproval_approver（変更に紐づく承認）を集計すると、732件でした。requested 376・not_required 290・approved 66・rejected 0です。承認先を指定するapproverフィールドはsys_userへの参照で、groupフィールドはsysapproval_groupへの参照です。ロールを指定する欄はありません。

CABも同じ構造です。cab_meetingは6件、cab_agenda_itemは60件、cab_attendeeは18件でした。出席者はcab_meetingのboard_members（sys_userの参照リスト）やboard_groups（グループの参照リスト）、個々のcab_attendeeレコードで決まります。こちらにもロールを指定する欄はありません。

sn_change_cab.cab_managerロールが持つのは、CABミーティングを作成・運営する権限です。会議に誰を呼ぶかはロールの範囲外で、ミーティングごとのレコードに個別に登録します。承認者もCAB出席者も、この会議・このChangeに名指しで登録された人だけが対象になる仕組みです。ロールを持っているかどうかは関係ありません。

• 参考：グループ承認：N人を1つに束ねる仕組み（sysapproval_group） … 複数人の承認をまとめる別の仕組み

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

ドメイン分離を使う場合の注意

ACLとは別に、レコードの見える範囲を分ける仕組みがあります。sys_domainとsys_domain_pathの2項目です。

change_requestのレコードにもこの2つが含まれており、既定値はそれぞれglobalと/でした。1社で使う環境では意識する場面はありません。

複数の会社や部門で1つのインスタンスを共有する場合、ドメイン分離を有効にすると、ACLの判定より前にドメインで絞り込まれます。ここまで見てきたロールとACLを正しく設定しても見えないときは、ドメインの設定を先に確認します。

• 参考：ドメイン分離は2つのフィールドで決まる（sys_domain） … 分離の仕組み

権限設計の推奨ロールモデル

itilを持つ担当者は、追加設定なしでsn_change_write（連鎖してsn_change_read）を持ちます。前述のとおり、この27ロールにはIncident・Problem・Requestの書き込みロールも含まれます。

Change管理だけに閉じたアクセスを与えたい場合は、itilではなくsn_change_writeを単独で付与します。他プロセスも兼務する担当者（サービスデスクなど）には、itilをそのまま使います。線引きの基準は、複数プロセスを兼務する実態があるかどうかです。

6つの職務ごとの推奨ロールを一覧にします。

表から読み取れる重要事項は、6職務すべてがグループ経由での付与を基本とする点です。個人への直接付与は、変更管理者に例外として認める場合に限ります。

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

• 一般申請者（起票のみ）：itilのみを付与する。change_managerやsn_change_adminは付与しない

• 実施担当者（Change Taskのみ）：sn_change_task_assigned_userを付与する。sn_change_writeは重ねない

• 変更管理者：change_managerをグループ経由で付与する

• CAB運営者：sn_change_cab.cab_manager単体を付与する

• 設定管理者：sn_change_adminをグループ経由で付与し、日常の運用担当には持たせない

外部委託先などitilを持たせられない担当者には、sn_change_writeを単独で付与します。Change管理だけを委託する体制では、この構成が唯一の選択肢になります。

change_managerとsn_change_task_assigned_userは同一利用者に付与しません。承認者が自分の実施タスクを承認する構図になり、職務分離が崩れます。sn_change_adminも一般の変更管理者へ広く付与しません。Change Modelや状態遷移の設定変更まで許可範囲が広がります。

付与後はsys_user_has_roleのinherited列を確認します。falseの行が意図した職務以外に付いていないかを見れば、想定外の直接付与を検出できます。

typeの変更・on_holdの解除・Closedの入力項目・CAB出席者の登録は、ロールではなく前の各節で扱った仕組み（ACL・Business Rule・レコードへの個別登録）で決まります。権限設計とあわせて、これらの手順も導入前に確認します。

実機で気づいたこと

on_holdへ入ると保存そのものが止まる

Business Rule「Read only State」のスクリプトを読むと、直前の状態がon_hold=trueだったレコードは、on_holdをfalseへ戻す保存も含めて中断される実装でした。

名前からは state フィールドだけが読み取り専用になる動きを想像していましたが、実際にはsetAbortAction(true)でレコード全体の保存を止める作りでした。on_holdを多用する運用を設計するときは、担当者が自分で解除できるのか、それとも別の手順が要るのかを、このBusiness Ruleの中身を読んでから決める必要があります。

typeを守るACLはロールとスクリプトの二重構成

change_request.typeのwrite ACLを実測すると、isNew()でなければ拒否するスクリプトの行と、role=nobodyを指定した行が両方存在しました。admin_overridesもどちらもfalseです。

1つのフィールドに対して、スクリプトとロール制限という異なる方式のACLが重ねて置かれている例は、change_request以外ではあまり見かけません。自社でACLを追加するときは、既存の行を消さずに追加するのか、1本化するのかで挙動が変わります。追加する前に、対象フィールドに何行のACLが既に存在するかを確認する癖をつけておくと安全です。

一般利用者はChange Requestを直接作成できない

change_requestのcreate ACLに指定されているロールは、itilとsn_change_writeの2つだけでした。条件式は付いていません。

Incidentはセルフサービスポータルから一般利用者が起票できますが、Changeは同じ経路を持ちません。ロールを持たない利用者は、Change Requestの新規作成画面そのものにたどり着けない設計です。変更の申請を利用者に開放したい場合は、sn_change_writeを配るのではなく、Service CatalogやRecord Producer経由で間接的に起票させる設計を検討することになります。

• 参考：インシデント管理モジュールのロール … Incidentは同じ場面でどう違うかを比較できます

用語

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

• ACL：Access Control List。どのロールがどのテーブル・項目を読み書きできるかの規則

• query_range：一覧やクエリの絞り込み条件として、その項目を使えるかを判定するACL操作

• report_view：レポートやPerformance Analyticsの集計対象にできるかを判定するACL操作

• list_edit：一覧画面のセルを直接編集できるかを判定するACL操作

• nobody：どのユーザーにも割り当てられない予約ロール。人からの直接書き込みを防ぐために使う

• DYNAMIC：ACLの条件式で使う動的フィルタ。ここでは「ログイン中のユーザー」を指す

• admin_overrides：adminロールが条件を無視して通れるかどうかの設定

検証範囲とおことわり

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

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

• change_request側のスクリプトACLの2行目・change_task側のスクリプトACL1件の中身までは詳しく追っていません

• itil保持者89人とsn_change_write継承保持者82人の差7人の原因は特定していません

• ロールをユーザー・グループへ割り当てる運用は、本シリーズ第11巻「変更管理モジュールの運用設計書」で扱います

• 実際に別ユーザーでログインして拒否を再現する検証は行っていません

付録：ロール保有者数（監査用）

環境依存の実測値のため、本文から切り離して記録します。取得日時は2026-09-01で、sys_user_has_roleをGROUPBYinheritedで集計しました。

sn_change_writeとsn_change_readは、直接付与が0件でした。82人全員がitilなどの上位ロールからの継承です。sn_change_adminとsn_change_task_assigned_userは、本PDIでは保有者が0件でした。専用ロールとして定義はあっても、デモデータの範囲では誰にも割り当てられていません。

直接付与か継承かは、sys_user_has_roleのinherited列で判定します。trueなら上位ロール経由の継承、falseなら個人またはグループへの直接付与です。

不要な権限を検出する手順は次のとおりです。

1. 対象ロールでsys_user_has_roleを絞り込み、inherited=falseだけを抽出する

2. 直接付与されたユーザーの職務が、「職務ごとのロールセット」で示した6区分と一致するか確認する

3. 一致しない場合は、過去の異動で外し忘れたロールの可能性が高く、棚卸しの対象にする

itilを外す作業をすると、sn_change_write・sn_change_readの継承分も一緒に消えます。Change管理だけを外したい場合は、itilが含むsn_change_writeを個別に付け替える設計が必要です。

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

• 変更管理関連のロール：/sys_user_role_list.do?sysparm_query=nameLIKEchange^ORnameLIKEcab^ORnameLIKEchg

• itilが含む変更管理ロール：/sys_user_role_contains_list.do?sysparm_query=role.name=itil^contains.nameLIKEchange

• 保有者数（継承の内訳）：/sys_user_has_role_list.do?sysparm_query=role.name=sn_change_write^GROUPBYinherited

• ACLの操作別件数：/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHchange_request^active=true^GROUPBYoperation

• list_editのACL：/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHchange_request^active=true^operation=list_edit

• 条件式を持つACLの一覧：/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHchange_task^active=true^conditionISNOTEMPTY

• typeのACL：/sys_security_acl_list.do?sysparm_query=name=change_request.type

• 承認者の状態別集計：/sysapproval_approver_list.do?sysparm_query=sysapproval.sys_class_name=change_request^GROUPBYstate

• CAB出席者の一覧：/cab_attendee_list.do

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

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

• ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameLIKEchange^ORnameLIKEcab^ORnameLIKEchg

関連記事

• 変更管理モジュールの概要 … typeとChange Modelの全体像はここから

• ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACLの判定順序を扱っています

• インシデント管理モジュールのロール … 同じ切り口でIncidentを扱った回です