問題管理モジュールのロール
「問題コーディネーターの役割を誰にも割り当てていないのに、サービスデスクの担当者が Problem を起票・更新できる」。この状態は設定ミスではありません。Incidentのロールと ACL を実測すると、9ロール・151件のACLのうち、ロールが指定されているのは12件だけで、残りは条件式で判定されていました。Problem管理は6ロール・146件と数こそ近いものの、ACLの判定方法がまるで違います。Australia の PDI をデフォルト設定のまま開き、問題管理に関わる6つのロールと、problem／problem_task に紐づく146件の ACL がどう権限を決めているかを確かめました。
検証環境：Australia PDI / OOTB / 2026-08-31 確認
調べる順序
ロールの一覧と、それぞれの守備範囲
itil がなぜ Problem の書き込み権限を自動で持つか
ACL 146件が何を判定材料にしているか
状態（state）を人が直接書き換えられない理由
要点
問題管理のロールは6つで、6つすべてに公式説明が付いている
itil は sn_problem_write を自動的に含み、専用ロールなしで Problem を書き込める
有効な ACL 146件は、72種類のACL名すべてに何らかのロールが指定されている
条件式（condition）を持つ ACL は0件。Incidentの「クローズ後は編集不可」のような条件式はない
どの役割に、どのロールを付与するか
先に、実務の役割とロールの対応を1枚で示します。利用者には何も付与せず、対応にあたる担当者には itil だけを渡し、調整役には problem_coordinator を足す構成が基本形です。
この対応がなぜ成り立つのかを、ロールの定義と ACL の実測で確かめていきます。
問題管理に関わるロール
sys_user_role で名前に problem を含むロールを検索すると6件でした。
6件すべてに公式説明（description）が入っています。守備範囲を整理します。
problem_admin の公式説明を引用します。
A Problem Manager who can also delete Problems and Problem Tasks
（訳: Problem Manager の権限に加えて、Problem と Problem Task を削除できる）
problem_coordinator の説明も具体的です。
Works on a Problem or Problem Task and manages it through its lifecycle
（訳: Problem または Problem Task を担当し、そのライフサイクル全体を管理する）
「ライフサイクルを管理する」という表現が、状態遷移を扱う権限を指している点は後段の ACL 実測と対応します。
引用元: /sys_user_role_list.do?sysparm_query=nameLIKEproblem
ロールの包含関係は2つの階層が合流する構造
sys_user_role_contains を実測すると、問題管理の6ロールは1本の鎖ではなく、2つの階層が途中で合流する形をしていました。
管理系の階層はここまで一直線です。
problem_admin
└ problem_manager
└ problem_coordinatorここで problem_coordinator が problem_task_analyst に加えて itil を含みます。itil はさらに sn_problem_write を含み、sn_problem_write が sn_problem_read を含みます。
problem_coordinator
├ problem_task_analyst
└ itil
└ sn_problem_write
└ sn_problem_readproblem_admin を1つ付けると、下位5ロールがすべて有効になります。管理者に個別のロールを積み上げる必要はありません。
参考：ServiceNowで付けたロールが想定外の権限を含んでいた理由 sys_user_role_containsで包含を実機でたどる … 包含関係のたどり方はここで詳しく扱っています
itil が sn_problem_write を自動的に含む理由
ここが本記事でいちばん実務に効く実測です。誰が problem 系ロールを含んでいるかを逆方向から見ると、itil が sn_problem_write を含む行が出てきます。
逆方向の包含をまとめます。
business_stakeholder は sn_problem_read を含む
instance_operator は sn_problem_read を含む
itil は sn_problem_write を含む（sn_problem_read も連鎖して継承する）
sn_service_desk_agent も sn_problem_write を含む
つまり problem_coordinator のような専用ロールを一切付与しなくても、itil を持つ担当者は最初から Problem の作成・更新ができます。ヘルプデスクの標準ロールである itil が、Incident だけでなく Problem の書き込み権限まで運んでいる構造です。
問題管理の専用ロール群（problem_coordinator 〜 problem_admin）は、この土台の上に担当割当・状態遷移の管理・削除といった追加の権限を積み増すための階層であって、Problem機能を使うこと自体には itil だけで足ります。
sn_problem_writeとsn_problem_readがさらに含む9ロール
itil が運んでいる sn_problem_write は、単独のロールではありません。sn_nb_action.next_best_action_user・email_composer・template_editor と、sn_problem_read の4つを含みます。email_composer はメール作成、template_editor はテンプレート編集の権限で、Problem起票時の通知やテンプレート適用に対応します。
sn_problem_read はさらに5ロールを含みます。cmdb_read・cmdb_query_builder_read・view_changer・dependency_views・agent_workspace_user です。cmdb_read と dependency_views が入っているのは、ProblemがCI（構成アイテム）を起点に調査する機能だからです。Problemを読む権限には、関連するCIとその依存関係を読む権限が自動でついてきます。
itil を1つ付けるだけで、Problemの読み書きに加えて構成管理の参照・メール作成・テンプレート編集まで9ロール分の権限が連鎖して付与される計算になります。
誰が実際に問題管理ロールを持っているか
役割の定義だけでなく、実際の割り当て数を確認しました。sys_user_has_role を数えると、次のようになります。
ロール保持者数直接付与継承sn_problem_write79079sn_problem_read79079problem_task_analyst826problem_coordinator633problem_manager321problem_admin110
sn_problem_write と sn_problem_read は、直接付与が1件もありません。79人全員が itil などの上位ロールからの継承です。管理者がこの2つを個別に配った形跡がなく、itil 経由の自動付与だけで運用されている実態が数字に表れています。
一方で problem_coordinator 以上の専用ロールは、少人数へ直接付与されています。担当割当や再分析といった調整業務は、itil だけでは足りず、意図して選ばれた担当者にだけ渡す設計です。
itil 全体の保持者は89人でした。sn_problem_write の継承保持者79人との間に10人の差がありますが、原因はこの調査では特定していません。
保持者の実体は sys_user の1レコードずつです。誰がどのロールを持つかを名前で確認したいときは、ユーザーテーブル側から逆にたどります。
sys_security_acl_role の179件の中で、problem_coordinator という名前が直接登場するのは1件だけでした。しかもその1件はIncident側の incident.problem_id（write）で、Problem本体のものではありません。Problem・Problem Task本体146件のACLに、problem_coordinator が単独でロール指定されている行は1つもありません。専用ロールという名前を持ちながら、Problem本体への実際の書き込み権限は itil を含むことで得ているという構造が、ここでも裏付けられます。
参考：ServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表からたどる … 割り当ての実態はここで追える
参考：ユーザー（sys_user）は1行＝1人 … 割り当て先となるユーザーテーブル
ACLの操作別内訳
sys_security_acl で名前が problem を含む有効なACLを数えると146件でした。
write が67件で全体の半数近くを占めます。read は23件で、write の3分の1程度です。
書き込み側のACLが読み取り側の3倍近くあるのは、誰が状態を進めるか・誰が担当を変えるかに業務判断が伴うためです。書き込みはフィールド単位まで分けて制御されています。
delete は5件だけでした。テーブル単位で2件（problem・problem_task）に加え、更新セット基盤の自動生成分が3件含まれます。Problem・Problem Taskを消す操作は、業務上ほとんど想定されていません。
残る操作にも役割があります。report_view の14件はレポート機能から参照するときの権限で、フォームでの読み取りとは別に判定されます。create の8件は新規作成、execute の4件は ProblemState などのScript Includeを呼び出す権限です。list_edit の2件は一覧画面でセルを直接編集する操作で、フォームを開かずに更新する経路に限って判定されます。
テーブル単位とフィールド単位、Problem固有ではない自動生成分
有効146件の一覧を見ると、テーブル単位のACLとフィールド単位のACLが混在しています。
146件の内訳を、対象ごとに整理します。
対象件数備考problem（テーブル＋フィールド）59Problem本体の業務ACLproblem_task（テーブル＋フィールド）57Problem Taskの業務ACLsys_update_preview_problem17更新セット・プレビュー機構の自動生成sys_backout_problem5更新セット・バックアウト機構の自動生成incident.problem_id3Incident側からProblem Coordinatorが書ける経路Script Includeのexecute権限4ProblemState等の実行権chat_queue.confirm_problem1Virtual Agentの問題確認画面向け
sys_update_preview_problem と sys_backout_problem を合わせた22件は、"problem" という名前を持つテーブルに自動付与される汎用ACLで、Problem固有の業務ロジックではありません。実質的な業務ACLは116件（59＋57）に絞り込めます。
ACLの判定はロールだけで行われている
有効146件のうち、condition を持つACLを検索すると0件でした。空のACL一覧は撮っても伝わりにくいため、代わりに script を持つACL13件の一覧を載せます。
sys_security_acl_role を実測すると、146件のACLに対応するACL名は72種類あり、その72種類すべてに最低1つのロールが指定されています。
ロール別の登場回数をまとめます。
判定の全体像を図にします。
「誰か」で判定するか「どの状態か」で判定するかという観点では、Problemは前者に寄っています。itil / sn_problem_write / problem_task_analyst / nobody の4つで、179件のロール指定のうち126件を占めます。
public の18件はすべて query_range（取得できる範囲の既定値）で、読み書きそのものの権限ではありません。取得範囲を全ユーザーに開いているという意味にとどまります。
delete権限はproblem_adminとitil_adminだけ
削除できるロールを絞り込むと、意外な組み合わせが出てきます。
operation=delete を持つのは problem_admin（problem・problem_taskの2件）と itil_admin（同2件）の合計4件だけでした。problem_manager や sn_problem_write に delete は付いていません。
itil_admin は sys_user_role_contains の包含関係では itil を含まない別系統のロールです。それでも delete のACLロールとしては直接指定されています。包含関係を持たないロールに、個別のACLで権限を足すという、包含だけでは読み切れないパターンがここにありました。
参考：ServiceNowでadminを配らずに開発させるには？ Delegated Developmentで権限を絞る … 強い権限を配らない運用の考え方
stateは条件式ではなくrole=nobodyと読み取り専用で守られている
Incidentの記事では、incident_state NOT IN 7,8 という条件式が26件のACLに入っており、これがクローズ済みレコードを守っていました。Problemには条件式を持つACLが1件もありません。ではクローズ済みのProblemは、どうやって守られているのでしょうか。
答えは辞書とACLロールの組み合わせにありました。
state フィールドは sys_dictionary_override で read_only=true が設定されています。値が101（New）でも107（Closed）でも、常に読み取り専用です。フォーム上で人が直接書き換える経路自体がありません。
もう1つの状態管理フィールドである problem_state（整数、旧方式）は、write ACLのロールが nobody でした。どのロールを持っていても、人はこのフィールドを直接更新できません。
状態を進めるのは Assess・Confirm・Fix・Resolve・Complete という UI Action です。それぞれが ProblemStateUtils という Script Include の canAssess() や canResolve() を呼び出して表示可否を判定し、ボタンを押すと Business Rule が state と problem_state を同期させます。条件式で弾くのではなく、そもそも直接編集する経路を用意しない設計です。
problem_task側は担当者ロールが直接stateを書ける
Problem Task側のACLを見ると、Problem本体とは違う設計が見えます。
problem.state を名指ししたフィールドACLは存在せず、problem.* ワイルドカードの下で判定されています。一方 problem_task.state には専用のwrite ACLがあり、ロールは itil と problem_task_analyst でした。
Problem本体のstateは誰も直接書けない設計、Problem Taskのstateは担当者ロールが直接書ける設計という違いがあります。Problem Taskは個々の調査・復旧作業を1件ずつ進める単位なので、担当者が状態を細かく更新する運用に合わせているとみられます。
参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACLの基本的な読み方
ドメイン分離を使う場合の注意
ACLとは別に、レコードの見える範囲を分ける仕組みがあります。sys_domain と sys_domain_path の2項目です。
Problemのレコードにもこの2つが含まれており、既定値はそれぞれ global と / でした。1社で使う環境では意識する場面はありません。
複数の会社や部門で1つのインスタンスを共有する場合、ドメイン分離を有効にすると、ACLの判定より前にドメインで絞り込まれます。ここまで見てきたロールとACLを正しく設定しても見えないときは、ドメインの設定を先に確認します。
参考：ドメイン分離は2つのフィールドで決まる（sys_domain） … 分離の仕組み
実機で気づいたこと
itilを外しても専用ロールを付けない限りProblemは書けたまま
sn_problem_write の保持者79人は全員が継承でした。直接付与は0件です。
この事実は、itil を外すという棚卸し作業の結果を左右します。sn_problem_write を個別に付け直した記録がないため、itil を外せば Problem の書き込み権限も一緒に消えます。逆に言えば、itil を残したまま「Problemだけ触らせない」という制限は、ロールの付け外しでは実現できません。ACLの条件式やスクリプトでの追加制御が必要になります。
棚卸しをするときは、sys_user_has_role の inherited 列を先に確認します。継承分がどのロールから来ているかを sys_user_role_contains でたどらないと、意図しない権限剥奪が起きます。
同じことは監査でも問題になります。「誰が Problem を書き込めるか」という監査質問への正しい答えは、sn_problem_write の保持者一覧ではなく itil の保持者一覧です。ロール名だけを見て監査すると、実際の権限範囲を見落とします。
itil_adminはitilを含まないのに削除権限だけを持つ
itil_admin は sys_user_role_contains 上で itil を含みません。名前からは itil の上位互換に見えますが、通常の書き込み操作は itil や sn_problem_write を経由するため、itil_admin だけでは Problem を更新できません。
ところが sys_security_acl_role を見ると、itil_admin は problem と problem_task の delete ACLに直接ロールとして指定されています。包含関係では権限が届いていないのに、個別のACLでは削除権限だけが届いている状態です。
チームリードに itil_admin を付ける設計をするときは、包含関係の図だけを見て判断すると見落とします。ACLロールの一覧を合わせて確認し、実際に対象ユーザーへなりすまして削除ボタンが出るかまで確かめるのが確実です。
参考：ServiceNowで「このレコードが見えない」は本当にACL拒否？ Impersonate UserとSecurity Debugで実際に確かめる … 実際に別ユーザーで確認する
条件式が0件でも、Problemの権限が単純とは限らない
条件式（condition）が0件と聞くと、Incidentより単純な設計に見えます。実際には、判定の重心が条件式からロールの数へ移っただけでした。
72種類のACL名すべてに個別のロールが指定されており、itil / sn_problem_write / problem_task_analyst / nobody / public という5つの顔ぶれが、操作の種類ごとに使い分けられています。状態を条件式で判定しない代わりに、フィールドごとにロールを細かく割り当てる形で複雑さを吸収している設計です。
権限の相談を受けたときは、条件式を探して「見つからないから単純」と判断しないことです。sys_security_acl_role でロールの指定先を確認するところから始めます。フィールド・UI Policy・ACLのどの層が原因かを1つずつ切り分ける道具を使うと、条件式に頼らない設計でも迷わずに追えます。
参考：Access Analyzer：「見えない」の理由を層で切り分ける … 判定の層を順に確認する道具
実務で順番に検討する箇所
権限を設計するとき、確認する順序を決めておくと迷いません。ここまでの実測を踏まえると、Problemの権限設計は「まず itil で足りるかを確認し、足りない部分だけ専用ロールで積み増す」という順番が合理的です。条件式に頼らない分、ロールの組み合わせを最初に固めておく重みが増します。
担当者に渡すロール：Incidentも触るなら itil、Problemだけなら sn_problem_write
調整役の追加権限：担当割当や再分析が必要なら problem_coordinator を足す
削除権限の範囲：problem_admin と itil_admin のどちらに絞るか
読み取りだけの関係者：business_stakeholder・instance_operatorは自動でsn_problem_readが付く
Problem Taskの担当限定：problem_task_analystで自分の担当分だけに絞るか
stateの直接編集：既定どおり禁止し、UI Actionでの遷移に統一するか
ロールの渡し方：sn_problem_writeは直接付与せず、itil経由に統一するか
itil_adminの扱い：削除権限だけが単独で届く点を運用に反映するか
用語
OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
ACL：Access Control List。どのロールがどのテーブル・項目を読み書きできるかの規則
nobody：どのユーザーにも割り当てられない予約ロール。人からの直接書き込みを防ぐために使う
sys_user_role_contains：展開後の包含関係を保持するテーブル。階層を調べるときはこちらを見る
query_range：一覧やクエリで取得できるレコードの範囲を絞るACLの操作種別
admin_overrides：adminロールが条件を無視して通れるかどうかの設定
inherited：sys_user_has_role の列。上位ロールの包含によって自動で付いたロールかどうかを示す
Script Include：サーバ側で再利用する関数群。ProblemStateUtils は状態遷移の可否判定に使われる
検証範囲とおことわり
検証環境：Australia PDI / OOTB / 2026-08-31 確認
件数はすべてOOTBの定義の数です。本番環境やカスタマイズ済み環境では異なります
スクリプト付きACL13件の中身までは追っていません
itil 保持者89人と sn_problem_write 継承保持者79人の差10人の原因は特定していません
ロールをユーザー・グループへ割り当てる運用は、本シリーズ第11巻「問題管理モジュールの運用設計書」で扱います
実際に別ユーザーでログインして拒否を再現する検証は行っていません
付録：自分の環境で確認するときのURL
問題管理関連のロール：/sys_user_role_list.do?sysparm_query=nameLIKEproblem
itilが含む問題管理ロール：/sys_user_role_contains_list.do?sysparm_query=role.name=itil^contains.nameLIKEproblem
保持者数（継承の内訳）：/sys_user_has_role_list.do?sysparm_query=role.name=sn_problem_write^GROUPBYinherited
ACLの操作別件数：/sys_security_acl_list.do?sysparm_query=nameLIKEproblem^active=true^GROUPBYoperation
有効なACLの一覧：/sys_security_acl_list.do?sysparm_query=nameLIKEproblem^active=true
ACLとロールの対応：/sys_security_acl_role_list.do?sysparm_query=sys_security_acl.nameLIKEproblem
削除ロールの絞り込み：/sys_security_acl_role_list.do?sysparm_query=sys_security_acl.nameLIKEproblem^sys_security_acl.operation=delete
引用した公式説明を実機で確認する方法
この記事で引用した説明文は、ServiceNowが製品に同梱しているロールの説明です。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。
ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameLIKEproblem
関連記事
ServiceNow 問題管理（Problem）完全ガイド：Incidentとの違いとKnown Errorまでの流れ … Problem全体の位置づけはここから
ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACLの判定順序を扱っています
ServiceNowで付けたロールが想定外の権限を含んでいた理由 sys_user_role_containsで包含を実機でたどる … 包含関係の読み方を扱っています
