タスク管理モジュールのロール

2026年9月4日 17:18

「itil ロールを持っているのに、task テーブル自体には read も write も create の直接ACLが1件も無い」。実務でこの話を聞くと、多くの担当者は半信半疑になります。Incident・Problem・Change を含む63テーブルの共通基盤である task は、読み書きの権限のほとんどを子テーブル側に委ねる設計だからです。Australia の PDI をデフォルト設定のまま開き、task テーブル本体の4件のACLと、itil・task_editor という2つの独立したロールがどう役割分担しているかを確かめました。

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

調べる順序

task本体のACLが4件しかない理由
itil と task_editor、2つの独立ロールの役割分担
task.list（横断ビュー）を開いたときに何が見えるか

要点

task直接のACLは4件だけで、read・write・createは0件
フィールドレベルACL30件の書き込みは、itil と task_editor という2つの独立ロールで担われている
task_editor は5つの非ITSM系ロールに内包されるだけで、直接付与された実績は1件も無い

どの担当者に、どのロールが必要か

先に、実務の役割とロールの対応を1枚で示します。Incident・Problem・Change を担当する技術者には itil、PPMやカタログ申請など非ITSM系のプロセスを担当する人には、モジュール固有の業務ロールを渡します。task_editor は、その業務ロールに含まれる形で自動的に使われる仕組みです。

itil と task_editor は別系統のロールでありながら、task.* の同じフィールド群に書き込めます。この対応がなぜ成り立つのかを、ACLの実測で確かめていきます。

task テーブル本体のACLは4件だけ

sys_security_acl で名前が task に完全一致するものを数えると、有効なACLは4件でした。

read・write・createの直接ACLは1件もありません。63の子テーブル（incident・problem・change_request等）は、taskから受け継ぐものに加えて、自テーブル名のACLを個別に定義しています。基本的な読み書き権限は子テーブル側の責務になります。task自身が持つのは、レポートで参照できるかどうかの report_view 3件と、削除に関する delete 1件だけです。

report_view は通常の一覧表示や記録の閲覧を判定する read とは別物です。レポートやダッシュボードでの集計参照だけを制御する操作になります。付与先は3系統に分かれます。itil・sn_problem_read・sn_request_read・problem_task_analyst・sn_vdr_risk_asmt.vendor_assessment_reviewer・sn_change_read・sn_incident_read というITSM系の読み取りロール7つ、GRC向けの sn_grc.library_business_user・sn_grc.library_reader の2つ、そして admin です。task を継承する非ITSM系のモジュールのうち、レポート参照に専用ロールを持つのはGRCだけという構成になります。

参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACLの条件と評価順の基本

delete のロールは snc_internal なのに、実際には誰も消せない

delete ACL の中身を開くと、意外な作りになっていました。

付与ロールは snc_internal（内部ユーザー全員が持つ基本ロール）です。ロール欄だけを読むと、ログインユーザーなら誰でも task レコードを削除できるように見えます。ところが、このACLレコードの script フィールドを確認すると、1行だけスクリプトが設定されていました。この画面のレイアウトにはscript欄が表示されないため、sys_security_acl テーブルを直接読んで確認しています。

false;

スクリプトが常に false を返すため、snc_internal を持っていても削除は必ず拒否されます。素通りできるのは、admin_overrides=true によって判定自体をスキップできる admin ロールだけです。ロール名を見て権限範囲を判断すると、この1件では実態と逆の結論になります。taskレベルでの削除は、実質的にadmin専用の操作という設計です。

フィールドレベルACL30件は itil と task_editor の2系統

task.* という名前で始まるフィールドレベルACLを数えると30件でした。

内訳は write が24件、read が4件、query_range と save_as_template が各1件です。write24件の中心は assigned_to・description・due_date・escalation・impact・priority・short_description・state・urgency・work_notes といった、フォームでよく編集するフィールド群になります。

これらのフィールドには itil と task_editor の両方が付与されており、どちらか一方を持っていれば書き込めます。一方 approval・approval_history は approval_admin のみ、closed_at・closed_by・number・opened_at・opened_by は admin のみと、フィールドごとに要求ロールが細かく分かれています。

30件のうち admin_overrides が false なのは4件だけでした。task.universal_request（write）・task.number（save_as_template）・task.sla_due（write）・task.*（query_range）です。残る26件は true で、adminロールを持つユーザーは条件やスクリプトを無視して通れます。false の4件は itil・task_editorとは別系統のロール（admin単独・snc_internal・maint・public）に集中する結果でした。範囲を絞る操作や特権的なフィールドは、adminでも外れない設計が踏襲されています。

task_editor というロールの正体

itil と並んで書き込みを許可している task_editor を調べます。

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

Can edit protected task fields

（訳: 保護されたtaskフィールドを編集できる）

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

elevated_privilege は false、includes_roles は空です。task_editor 自身は他のロールを一切含みません。「保護されたtaskフィールドを編集できる」という一点だけを持つ、単機能のロールになります。

この単機能さが設計上の利点になります。itil は27件のロールを一括で含む広いロールで、問題管理・変更管理・カタログ申請にまで書き込み権限が及ぶ設計です。PPMやSecurity Centerの担当者にitilを渡すと、意図しないITSM系の権限まで一緒に付いてしまいます。task_editorはtask.*のフィールド編集だけに絞られているため、モジュール固有ロールに組み込んでも影響範囲が広がりません。

task_editor を含む5つの上位ロール

task_editor を含む上位ロールを sys_user_role_contains で調べると5つでした。

内訳は PPM の project_user（96人）と Service Catalog Request の sn_request_write（79人）が中心です。CMDB Data Management の data_manager_admin は1人、Vendor Risk Assessment の sn_vdr_risk_asmt.vendor_assessment_reviewer と Security Center の sn_vsc.ext_sec_task_manager はいずれも0人でした。

いずれも itil という名前を持たない非ITSM系のロールです。「ITILヘルプデスク技術者」を意味する itil を、PPMのプロジェクトメンバーやカタログ申請の担当者に付けるのは不自然に映ります。そこで各モジュールは、taskの主要フィールドを編集する権限だけを task_editor という中立な名前のロールに切り出し、自分のモジュール固有ロールに埋め込む形を取っています。

task_editor 自体の保有者を数えると161人でした。全員が inherited=true、つまり継承です。直接付与は0人でした。itil（89人、直接54・継承35）とは対照的に、task_editor は一度も単独で配られたことがありません。5つの上位ロールのどれかを付けたときにだけ、自動でついてくる配管専用のロールという性格が数字にも表れています。

参考：ServiceNowの権限は誰が持っている？ユーザー・グループ・ロールを中間表からたどる … 割り当ての実態をたどる方法
参考：ユーザー（sys_user）は1行＝1人 … 保有者数の集計対象になるユーザーテーブル

read権限だけは itil 単独という非対称

read の4件（work_notes・comments_and_work_notes・approval_set・work_notes_list）を見ると、付与ロールは itil だけでした。task_editor は含まれません。

write側は「itilとtask_editorのどちらでも書ける」という対等な設計でしたが、read側は itil だけの単独設計です。PPMのプロジェクトメンバーが project_user を持ち、task_editor 経由で work_notes を書き込めても、work_notes を読むための明示的なACLは持っていないことになります。この非対称に気づかず「task_editor を持っているから work_notes も見えるはず」と考えると、読み取り側で想定と違う挙動に当たります。

読み取りが制限されているように見えても、実際にはキャッチオールACLや snc_internal 経由で読める場合があります。「itilを持たないから読めない」と決めつけず、フィールドごとのread ACLを個別に確認する必要があります。

task.list を開くと何が見えるか

task テーブル自体には read の直接ACLが無いことは先に確認しました。ではブラウザで task_list.do を開いたとき、何が表示されるのでしょうか。鍵になるのは、ACLが1件も無いときの既定動作を決めるプロパティです。

glide.sm.default_mode の公式説明を引用します。

Security manager default behavior in the absence of any ACLs on a table

（訳: テーブルにACLが一切無い場合の、セキュリティマネージャーの既定の振る舞い）

引用元: /sys_properties_list.do?sysparm_query=name=glide.sm.default_mode

値は deny でした。全テーブル共通のキャッチオールACL（name=*／type=record／operation=read）を確認すると、無条件で読めるのは admin ロールだけです。残る3件はスクリプト判定で、いずれも glide.sm.default_mode == 'allow' を条件に含んでいます。本PDIは deny のため、この3件は成立しません。

ここから帰結が見えます。task.list に並ぶ行は1行ずつ、その行が実際に属するテーブルのACLで判定されます。sys_class_name=incident の行は incident 自身のread ACLで、sys_class_name=problem の行は problem 自身のread ACLで判定される仕組みです。task直接のACLが使われるのは、どの子テーブルにも分類されない「素のtaskクラス」レコード（本PDIで246件）だけであり、そのレコードを読めるのは実質adminに限られます。task.list は1つの権限で開くビューではなく、レコードの数だけ判定が走る合成ビューという構造です。

参考：ServiceNowでadminを配らずに開発させるには？ Delegated Developmentで権限を絞る … admin以外に権限を絞る考え方

誰がどの権限を持っているかを個別に確認する

task.state の書き込みACLを例に、ロールの対応を実機で確認します。

task.state の write は itil と task_editor の2ロールに対応していました。フィールド名だけでなく、実際にどのロールが紐づいているかは sys_security_acl_role を1件ずつ確認するのが確実です。自社でフィールドの権限を調べるときも、この画面から辿ります。

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

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

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

task固有フィールド71件にもこの2つが含まれており、既定値はそれぞれ global と / でした。1社で使う環境では変わりません。

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

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

子テーブルへの波及：incident・problem・change・kbとの対比

task本体のACLはわずか4件でしたが、taskを継承する子テーブルはそれぞれ独自にACLを積み増しています。各シリーズの確定値を1行ずつ対比します。

incident は有効なACL151件のうちロール指定が12件だけで、残りは条件式とスクリプトが判定します。problem は146件の全てに何らかのロールが付き、判定はロール中心です。change は change_request・change_task を合わせて121件で、こちらもロール中心に条件式19件が加わります。

kb_knowledge だけは毛色が違います。kb_knowledge は task を継承しない独立テーブルで、ACL自体は create・write・delete が snc_internal、read が public という緩い設定です。実際の可否は User Criteria 10件とスクリプトACL183件（全体565件の32%）が握っており、ロールの有無では判断できません。

taskは器だけを用意し、実際の制御はほぼ全て子テーブル側が持つという設計です。100件を超えるACLを積む子テーブルが並ぶ中で、kbだけは「ロールではなくUser Criteriaで制御する」という別方式を採っています。継承した子テーブルが必ずロール中心になるわけではないことを示す、対照的な例です。

参考：Knowledge だけ task 系でない（kb_knowledge） … kb_knowledgeが独立テーブルである理由

実機で気づいたこと

task本体のACLが4件しかないのは、読み書きを子テーブルに委ねる設計だから

task直接のACLは4件で、そのうちread・write・createは0件でした。63の子テーブルを1つの器で束ねながら、実際の読み書き制御は個々の子テーブルに委ねる作りです。

権限の相談を受けたとき「taskのACLを見れば全体が分かる」という前提で調査を始めると空振りします。読み書きの制御を探すなら、最初からincidentやproblemなど対象テーブル自身のACLを見ます。taskのACLで確認できるのは、report_viewとdeleteの2種類だけです。

新しいテーブルをtask継承で作るときは、read・write・createのACLを自分で用意する必要があります。taskを継承しただけでは読み書きが動かないため、用意を怠ると誰も操作できないテーブルが出来上がります。

deleteのロールはsnc_internalなのに、スクリプトが常に拒否する

task本体のdelete ACLはsnc_internalという広いロールに割り当てられていました。ロール名だけを見ると内部ユーザー全員が削除できそうですが、スクリプトがfalse;で固定されており、admin以外は必ず拒否されます。

ACLの棚卸しでロール欄だけを読むと、この1件は権限が広すぎるように誤認します。スクリプトの有無まで確認しないと、実際の挙動を読み違えます。フィールドやテーブルのACLを監査するときは、ロール列に加えてscript列が空かどうかを必ず確認します。

task_editorは、直接付与された実績が1件も無い

task_editorの保有者161人は全員が継承でした。直接付与はゼロです。上に挙げた5つの上位ロールのいずれかを持つと自動で付きます。単独では機能しない、完全な配管役のロールです。

新しく非ITSM系のモジュールをtask継承で作るとき、taskの主要フィールドを編集させたいなら、task_editorを直接割り当てるのではなく、自モジュールの業務ロールにincludes_rolesで組み込みます。itilという名前を持たない独立ロールとして用意されている理由が、この割り当てパターンから読み取れます。

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

権限を設計するとき、確認する順序を決めておくと迷いません。task本体の4件だけを見て安心せず、実際に読み書きを許可しているフィールドレベルACLと、子テーブル側の個別ACLまで辿ってから結論を出します。

ITSM担当者に渡すロール：itilを基本とする
非ITSM系の担当者：project_userなど個別モジュールの業務ロールを渡す。task_editorは自動で付くため単独指定は不要
taskレコードを直接消したい場合：adminロールが必要（delete ACLはスクリプトで一律拒否される設計）
task.listの設計：横断ビューを機能させたいなら、子テーブルごとにread ACLを個別に用意する
work_notesの閲覧だけ許可したい場合：itilを渡す。task_editorにはread権限が無い
新しい子テーブルを追加する場合：taskの4件だけに頼らず、自テーブル名のACLを個別に定義する

用語

OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
ACL：Access Control List。どのロールがどのテーブル・項目を読み書きできるかの規則
admin_overrides：adminロールが条件やスクリプトを無視して通れるかどうかの設定
task_editor：「保護されたtaskフィールドを編集できる」という単一機能のロール。他ロールに内包されて使われる
glide.sm.default_mode：テーブルにACLが一切無い場合の既定動作を決めるシステムプロパティ
User Criteria：ロールとは別に、レコード単位の可視性を決める仕組み。kb_knowledge等で使われる

検証範囲とおことわり

検証環境：Australia PDI / OOTB / 2026-09-01 確認
件数はすべてOOTBの定義の数です。本番環境やカスタマイズ済み環境では異なります
incident・problem・change・kbの件数は各シリーズの確定値を引用したもので、本記事で再測定はしていません
キャッチオールACL4件のうち、承認者向けスクリプト（ApproverUtils）の詳細ロジックまでは追っていません
実際に非admin・非itilユーザーでImpersonateしてtask_list.doを開く検証は行っていません

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

taskテーブル本体のACL：/sys_security_acl_list.do?sysparm_query=name=task
フィールドレベルACL：/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHtask.^active=true
task_editorの定義：/sys_user_role_list.do?sysparm_query=name=task_editor
task_editorを含む上位ロール：/sys_user_role_contains_list.do?sysparm_query=contains.name=task_editor
既定動作のプロパティ：/sys_properties_list.do?sysparm_query=name=glide.sm.default_mode
キャッチオールの読み取りACL：/sys_security_acl_list.do?sysparm_query=name=*^type=record^operation=read

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

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

ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=name=task_editor
プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=name=glide.sm.default_mode

taskテーブル：ITSM全プロセスの共通の親 … taskが担う役割全体の整理
インシデント管理モジュールのロール … 子テーブル側で151件のACLがどう権限を決めるか
ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACLの条件と評価順の基本