インシデント管理モジュールのロール

2026年8月31日 23:58

「itil ロールを付けたのに、この項目が編集できない」という相談は、ロールだけを見ても解けません。ServiceNow の権限判定は ACL が行い、ロールはその判定材料の1つにすぎないためです。Australia の PDI をデフォルト設定のまま開き、インシデント管理に関わる9つのロールと、incident に紐づく151件の ACL がどう権限を決めているかを確かめました。

検証環境：Australia PDI / OOTB / 2026-08-31 確認

調べる順序

ロールの階層と、それぞれの守備範囲
ACL が何を判定材料にしているか
クローズ済みのインシデントが編集できない理由

要点

インシデント管理のロールは9つあり、9つすべてに公式説明が付いている
有効な ACL 151件のうち、ロールが指定されているのは12件だけ
残りは条件式とスクリプトで判定しており、状態・担当・起票者で権限が変わる

どの役割に、どのロールを付与するか

先に、実務の役割とロールの対応を1枚で示します。利用者にはロールを付与せず、対応にあたる担当者には itil、管理側には incident_manager を足す構成が基本形です。

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

インシデント管理に関わるロール

sys_user_role で incident と itil を含むロールを検索すると9件でした。

9件すべてに公式説明（description）が入っています。守備範囲を整理します。

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

Can perform standard actions for an ITIL helpdesk technician. This is the out-of-box ''technician'' role

（訳: ITILヘルプデスク技術者の標準的な操作を行える。これは製品標準の「技術者」ロールである）

引用元: /sys_user_role_list.do?sysparm_query=name=itil

sn_incident_task_assigned_user の説明も具体的です。

Access to incident_task if the incident_task is assigned to the user.

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

ロール名だけでは分からない「割り当てられている場合に限る」という条件が、説明文に書かれています。

ロールの包含関係

ロール一覧の includes_roles 欄を見ると、itil には template_editor の1件しか表示されません。ところが実際の包含は別のテーブルに展開されています。

sys_user_role_contains を見ると、itil は27のロールを含んでいました。一覧画面の欄だけを見ると階層を読み違えます。

インシデント関連の9ロールを展開すると、4段の階層が現れます。

sn_incident_admin
  └ incident_manager
      └ itil （27ロールを含む）
          └ sn_incident_write
              └ sn_incident_read

sn_incident_admin を1つ付けると、下位の4ロールがすべて有効になります。管理者に個別のロールを積み上げる必要はありません。

一方で itil_admin は itil を含みません。含むのは assessment_admin / cmdb_read / sn_bm_client.benchmark_data_viewer の3つだけです。名前から上位互換に見えますが、別系統として定義されています。チームリードに itil_admin だけを付けると、担当者としての操作ができません。両方を付ける前提の設計です。

sn_incident_comments_write と sn_incident_task_assigned_user は、含むロールが0件の単独ロールでした。用途を1つに絞った補助的なロールになります。

elevated_privilege は9件すべて false でした。昇格が必要な特権ロールは含まれません。

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

itil が含むロールの範囲

itil の中身を見ると、インシデント管理だけでなく ITSM 全体に届いています。

主なものを挙げます。

sn_incident_write：インシデントの読み書き
sn_problem_write：問題管理の読み書き
sn_change_write：変更管理の読み書き
sn_request_write：申請の読み書き
cmdb_read / cmdb_query_builder：構成管理の参照
template_editor：テンプレートの編集
agent_workspace_user：エージェントワークスペースの利用
email_composer：メールの作成
viz_creator：可視化の作成
sn_sla_definition_query：SLA定義の参照

itil を1つ付けると、インシデント・問題・変更・申請の4プロセスすべてに書き込めます。「インシデントだけ触らせたい」という要件には itil が広すぎます。その場合は sn_incident_write を選びます。

逆に itil を含む上位ロールも12件ありました。application_owner / enterprise_architect / app_service_admin / business_relationship_manager などです。これらを付けたユーザーにも、意図せず ITSM の書き込み権限が渡ります。

誰が itil を持っているか

sys_user_has_role で itil の割り当てを数えると89件でした。

内訳は直接付与が54件、継承が35件です。継承分は、itil を含む上位ロールを持っているために自動で付いたものになります。

この違いは棚卸しで効きます。「itil を外したい」と考えたとき、直接付与の54件を消しても、継承の35件は残ります。上位ロールを外さなければ権限は消えません。

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

グループへのロール付与の状況

ロールはユーザーに直接付けるほか、グループ経由でも渡せます。

グループは97件ありましたが、ロールが設定されているのは4件だけでした。

グループ設定されているロールCatalog Request Approvers > $1000catalog, itilCatalog Request Approvers for Sale…catalog, itilField Servicescatalog, itilCIM Approversitil

デフォルトでは、グループ経由のロール付与をほとんど使っていません。ユーザーへ直接付ける形が基本になっています。

実務では逆の設計を採ることが多くなります。グループにロールを付け、人事異動ではグループの所属だけを変える方式です。デフォルトのままだと、異動のたびに個人のロールを付け替えることになります。

参考：担当割り当て運用手順書：グループを変えられないのはBusiness Ruleが止めている … グループ運用でつまずく箇所

ACL の操作別内訳

sys_security_acl で名前が incident で始まるものを数えると、全体154件・有効151件でした。

write が76件で全体の半数を占めます。read は19件。書き込みの制御に手をかけている構成です。

理由は業務の性質にあります。インシデントは多くの人が見る記録である一方、書き換えてよい人と場面は限られます。誰が閉じたか、いつ解決したかを後から書き換えられると、記録としての価値が失われるためです。読むことは広く許し、書くことは細かく分ける。この方針が76対19という比に表れています。

delete は3件だけでした。インシデントを消す操作は、ほぼ想定されていません。

query_range 24件と conditional_table_query_range 7件は、一覧で取得できる範囲を絞る操作です。「一覧に出てこない」という症状では、read ではなくこちらが効いている場合があります。

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

適用範囲はテーブル単位とフィールド単位に分かれる

151件の名前を見ると、適用範囲が3種類ありました。

単位件数例テーブル単位44incident writeフィールド単位107incident.close_notes writeうちワイルドカード8incident.* write

フィールド単位が107件と多数です。項目ごとに書き込み可否を分けています。ワイルドカード（incident.*）は、個別指定のない全項目に適用される既定の規則になります。

判定は「フィールド単位 → ワイルドカード → テーブル単位」の順で評価されます。個別の指定があればそれが優先されます。

自社でACLを足すときは、この順序を踏まえて位置を決めます。1項目だけ制限したいなら incident.<field>、全項目の既定を変えるなら incident.* を使います。

影響を調べる手順は3段階です。sys_security_acl_role でそのロールが指定されているACLを洗い出し、条件式を読んで状態や担当者による制限が重なっていないかを確認し、最後に Impersonate User で実際に操作します。

ロールが指定されているACL

ここが実機で最も意外だった点です。有効151件のうち、ロールが指定されているのは12件だけでした。残る139件はロール欄が空です。

12件の内訳を挙げます。

ACL操作ロールincidentreadsnc_internalincidentreadml_report_userincident.*readsnc_internalincident.hold_reasonwriteitilincident.close_noteswriteitilincident.close_codewritesnc_internalincident.assigned_towritesn_incident_writeincident.commentswritesn_incident_writeincident_taskwriteitilincident_task.work_notes_listreadsn_incident_task_assigned_userincident_task.work_notes_listwritesn_incident_writeincident_task.work_noteswritesn_incident_task_assigned_user

ロール別の登場回数は次のとおりです。

snc_internal：3
itil：3
sn_incident_write：3
sn_incident_task_assigned_user：2
ml_report_user：1

snc_internal は ServiceNow のログインユーザー全員が持つ基本ロールです。つまり incident の read は、実質すべてのログインユーザーに開かれています。

付与例

Abel Tuter（二次対応 / Network チーム）
  直接付与: itil
  継承で有効: sn_incident_write / sn_incident_read
              sn_problem_write / sn_change_write / cmdb_read ほか

itil を1つ付けると ITSM 全プロセスへ書き込めます。インシデントだけに絞るなら sn_incident_write を選ぶ形。直接付与と継承の区別は sys_user_has_role の inherited 列で確認できます。

ロール指定のないACLを制御している条件式

ロール指定のない139件は、条件式とスクリプトで判定しています。

条件式のパターンを集計しました。

この設計の意味は明確です。インシデント管理の権限は「誰か」よりも「どの状態のどのレコードか」で決まっています。同じ itil を持つ2人でも、担当していないレコードは触れません。

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

クローズ済みが編集できない仕組み

条件式で最も多いのが incident_state NOT IN 7,8 で、26件の ACL に入っています。

7 は Closed、8 は Canceled です。この条件が入っている ACL では、クローズ済みと取り消し済みのインシデントに書き込めません。

「クローズしたインシデントを直したい」という相談の答えは、ここにあります。ロールを足しても解決しません。ACL の条件式が状態を見ているためです。運用としては、クローズを取り消してから編集するか、Reopen の UI アクションを使います。

さらに incident_state=7（Closed のときだけ書ける）という ACL が1件あり、これは admin_overrides が false になっています。admin ロールでも条件を満たさなければ通りません。クローズ後にだけ触れる項目を、意図して分離した設計です。

自分が起票した1件だけ触れる条件

もう1つ多いのが、起票者と利用者を見る条件です。

caller_id=javascript:gs.getUserID()^ORopened_by=javascript:gs.getUserID()^incident_stateNOT IN7,8

6件の ACL に入っています。読み下すと「自分が利用者、または自分が起票者で、かつ未クローズなら書ける」です。

この条件があるおかげで、itil を持たない一般利用者でも、自分が出したインシデントに補足を追記できます。セルフサービスポータルの動作を支えている条件です。

incident.watch_list の write にもこの条件が入っています。自分の案件なら通知先を自分で追加できる形になります。

自分に割り当てられたタスクだけ触れる条件

incident_task 側では、担当者を見る条件が11件で使われています。

assigned_toDYNAMIC90d1921e5f510100a9ad2572f2b477fe

DYNAMIC は動的フィルタへの参照で、この場合は「ログイン中のユーザー」を指します。自分に割り当てられた incident_task だけを読み書きできる制御です。

ロール sn_incident_task_assigned_user の公式説明「Access to incident_task if the incident_task is assigned to the user.」と対応します。ロールと条件式が組み合わさって初めて意味を持つ設計になっています。

参考：ServiceNowで「このレコードが見えない」は本当にACL拒否？ Impersonate UserとSecurity Debugで実際に確かめる … 実際に別ユーザーで確認する

admin_overrides が false のACL

admin_overrides は、admin ロールを持つユーザーが条件を無視して通れるかどうかの設定です。

値件数挙動true106admin なら条件に関係なく通るfalse45admin でも条件を満たさなければ拒否される

false の45件には、query_range と conditional_table_query_range の31件がすべて含まれます。取得範囲の制限は admin でも外れません。

残る14件には、先述の incident_state=7 や active=false といった特殊な条件のものが入ります。「admin なら何でもできる」という前提で設計すると、この45件で想定と食い違います。

参考：ServiceNowでadminを配らずに開発させるには？ Delegated Developmentで権限を絞る … admin を配らない運用の考え方

スクリプトで判定しているACL

条件式ではなくスクリプトで判定している ACL が13件ありました。incident の read と create に含まれます。

スクリプトによる判定は、条件式で書けない複雑な判断に使われます。他テーブルの値を参照する、時間帯で分ける、といった処理です。

権限の調査でここに当たったときは、条件式を読むだけでは結論が出ません。スクリプトの中身まで見る必要があります。ACL の一覧で script 列が空でないものを先に洗い出しておくと、調査の手戻りが減ります。

incident_task 側のACL

インシデントの作業タスク（incident_task）にも、独自のACLが用意されています。テーブル単位44件のうち、およそ半数が incident_task 向けでした。

条件式は incident 側と少し違います。

stateNOT IN3,4,7

incident_task の状態のうち、3・4・7 を除いた場合に書き込めます。incident 側の incident_state NOT IN 7,8 と番号が異なる点に注意してください。同じ「終了状態は触らせない」という方針でも、テーブルごとに値が違います。

もう1つが担当者を見る条件です。

assigned_toDYNAMIC90d1921e5f510100a9ad2572f2b477fe

11件で使われており、sn_incident_task_assigned_user ロールと組み合わせて動きます。作業タスクは「自分の担当分だけ触る」という前提で設計されています。

incident 本体は担当していなくても itil があれば触れます。一方 incident_task は担当者に絞られる設計。この差が作業の切り出し方に効きます。複数チームで分担する障害対応では、incident_task を使うと担当範囲が自然に分かれます。

もう1つ、incident_task には独自の create ACL と delete ACL があります。本体のインシデントを消せなくても、作業タスクは消せる構成です。誤って作ったタスクを整理できる一方、記録が残らない点には注意が必要になります。

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

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

インシデントの93項目にもこの2つが含まれており、既定値はそれぞれ global と / でした。1社で使う環境では変わりません。

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

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

実機で気づいたこと

ロールを付けても編集できない件がある

itil を持っていても、Closed のインシデントは編集できません。ACL 151件のうち26件が incident_state NOT IN 7,8 を条件に持つためです。

権限の判定材料としてロールが使われているのは12件だけでした。残る139件は条件式とスクリプトで判定しています。インシデント管理の権限は「誰か」よりも「どの状態のどのレコードか」で決まる設計です。

権限の相談を受けたら、まずレコードの状態を確認します。ロールの調査は次の段階です。順序を逆にすると、ロールを足しても直らない対応を続けることになります。

ロール一覧の画面では階層が読み取れない

sys_user_role の includes_roles 欄を見ると、itil には template_editor の1件しか表示されません。ところが sys_user_role_contains を見ると、27ロールを含んでいました。

includes_roles は直接指定した分だけを保持し、展開後の包含関係は別テーブルに入る構造でした。両方を見ないと階層を読み違えることになります。

権限の棚卸しでは sys_user_role_contains を確認してください。一覧画面の欄だけで判断すると、itil が問題管理や変更管理まで届いていることを見落とします。「インシデントだけ触らせたい」という要件には itil が広すぎるため、sn_incident_write を選ぶ判断になります。

itil_admin は itil を含まない

名前から上位互換に見えますが、itil_admin が含むのは assessment_admin / cmdb_read / sn_bm_client.benchmark_data_viewer の3つだけでした。

一方 incident_manager は itil を含み、sn_incident_admin は incident_manager を含みます。4段の階層があるのは管理者側の系統で、itil_admin は別系統として定義されています。

チームリードには itil と itil_admin の両方を付けます。ロールの上下関係は名前ではなく includes_roles と sys_user_role_contains で確認します。

admin でも一覧に出ないレコードがある

ACL 151件のうち45件は admin_overrides が false です。query_range と conditional_table_query_range の31件はすべて false でした。

取得範囲の制限は admin でも外れない構成です。「admin なら何でも見える」という前提で検証すると、一般ユーザーでの挙動と食い違います。

一覧に出ない件は、read ではなく query_range を確認します。権限に関わる検証では、Impersonate User で対象のロールに切り替えてください。admin で通ったからといって、担当者でも通るとは限りません。

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

権限を設計するとき、確認する順序を決めておくと迷いません。

状態による制限：incident_state NOT IN 7,8 を自社の状態運用に合わせるか、そのまま使うか
ロールの割り当て：itil を基本とし、読み取りだけなら sn_incident_read を使う
itil_admin の扱い：itil と併用する前提で設計する
利用者の自己参照：caller_id=自分の条件を残すか、ポータル経由だけに絞るか
incident_task の担当限定：assigned_to DYNAMIC の条件を維持するか
admin_overrides：admin による強制上書きを許す範囲を決める
独自ACLの追加場所：フィールド単位で足すか、ワイルドカードを直すか
incident_task の担当限定：作業タスクを担当者だけに絞る設計を残すか
グループ経由の付与：異動に強い設計にするなら、グループへロールを移す
ドメイン分離：複数組織で共有するなら、ACL より前にドメインを設計する

用語

OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
ACL：Access Control List。どのロールがどのテーブル・項目を読み書きできるかの規則
snc_internal：ServiceNow にログインできるユーザー全員が持つ基本ロール
admin_overrides：admin ロールが条件を無視して通れるかどうかの設定
動的フィルタ（DYNAMIC）：「ログイン中のユーザー」などを実行時に解決する条件
includes_roles：sys_user_role の欄。直接指定した包含だけを持つ
sys_user_role_contains：展開後の包含関係を保持するテーブル。階層を調べるときはこちらを見る

検証範囲とおことわり

検証環境：Australia PDI（patch3）/ OOTB / 2026-08-31 確認
件数はすべて OOTB の定義の数です。本番環境やカスタマイズ済み環境では異なります
スクリプト付き ACL 13件の中身までは追っていません
DYNAMIC90d1921e... が指す動的フィルタの定義内容は確認していません
ロールをユーザー・グループへ割り当てる運用は、本シリーズ第11巻「インシデント管理モジュールの運用設計書」で扱います
実際に別ユーザーでログインして拒否を再現する検証は行っていません

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

インシデント関連のロール：/sys_user_role_list.do?sysparm_query=nameLIKEincident^ORnameLIKEitil
ACL の操作別件数：/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHincident^GROUPBYoperation
有効な ACL の一覧：/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHincident^active=true
ACL とロールの対応：/sys_security_acl_role_list.do?sysparm_query=sys_security_acl.nameSTARTSWITHincident
ロールの包含関係：/sys_user_role_contains_list.do?sysparm_query=role.nameLIKEitil
誰がロールを持っているか：/sys_user_has_role_list.do?sysparm_query=role.name=itil
グループの一覧：/sys_user_group_list.do

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

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

ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameLIKEincident^ORnameLIKEitil

ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACL の判定順序を扱っています
ServiceNowの権限は誰が持っている？ユーザー・グループ・ロールを中間表からたどる … 割り当ての実態はここで追える
ServiceNowで「このレコードが見えない」は本当にACL拒否？ Impersonate UserとSecurity Debugで実際に確かめる … 拒否の原因を実機で切り分ける