サービスカタログのロール

「catalogロールを付けたのに、カタログの管理画面が編集できない」という相談は、ロールだけを見ても解けません。サービスカタログはACLのロール指定が主体です。一方でカタログ項目が「誰に見えるか」は、ACLとは別のUser Criteriaという仕組みが握っています。Australiaの PDI をデフォルト設定のまま開き、リクエスト管理とカタログに関わる17のロールを確かめました。あわせて sc_ 関連222件のACLと、カタログ項目の可視性を決めるUser Criteriaも実機で確認しています。

調べる順序

• ロールの種類と、それぞれの守備範囲

• ACL がロールと条件式のどちらを判定材料にしているか

• カタログ項目が見えない・申請できない理由

要点

• リクエスト管理とカタログに関わるロールは17件あり、15件に公式説明が付いている

• sc_request・sc_req_item・sc_task の ACL 106件のうち91件（86%）はロール指定で判定しており、条件式・スクリプトが主体だったIncidentとは判定方式が逆

• カタログ項目の可視性は ACL ではなく User Criteria（728件）が主に決めている

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

先に、実務の役割とロールの対応を1枚で示します。申請する利用者にはロールを付与せず、履行にあたる担当者には itil、カタログの作成・公開を担うカタログ管理者には catalog_admin 系のロールを足す構成が基本形です。

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

リクエスト管理とカタログに関わるロール

sys_user_role で catalog と sn_request を含むロールを検索すると17件でした。

17件中15件に公式説明（description）が入っています。説明が空欄なのは catalog_view_masked と sn_sow_req.sn_request_sow_admin の2件だけでした。守備範囲を整理します。

catalog系ロールの守備範囲

catalog系は12件あり、カタログの管理・編集・分析といった役割ごとに分かれています。

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

（訳: カタログのカテゴリや項目を含む、Service Catalogアプリケーションを管理できる）

catalog_manager の説明はもう少し具体的です。

（訳: 新しいサービスカテゴリを申請し、サービスの作成・更新を行う編集者を割り当て、カタログへの公開に向けてそれらのサービスを承認する、部門内の担当者）

catalog_admin が「管理」全般を担うのに対し、catalog_manager は新規カテゴリの申請と公開承認、catalog_editor は実際の項目編集という具合に、承認と実作業が別ロールに分かれています。1人にすべて集約する運用も、3ロールに分業する運用もどちらも成り立つ設計です。

catalog_builder_editor と catalog_builder_developer は、公式説明にどちらも「Catalog Builder」という語が入っています。旧来のカタログ設計画面とは別に、Catalog Builderという新しいUIの操作権限が独立したロールとして用意されている構造です。catalog_lookup_admin と catalog_lookup_manager も同様に、定義と運用を分ける名前の付け方になっています。

引用元: /sys_user_role_list.do?sysparm_query=nameLIKEcatalog^ORnameLIKEsn_request

Request Management系ロールの守備範囲

request系は sn_request_ で始まる4件に、SOW（Statement of Work）向けの拡張1件を加えた5件です。

sn_request_write の説明を引用します。

（訳: Request Managementアプリケーションおよび関連機能への書き込みアクセス）

sn_request_approver_read は範囲がさらに狭く定義されています。

（訳: Request Managementアプリケーションおよび関連機能への読み取りアクセス。そのリクエストレコードへの承認レコードを利用者が持つ場合のみアクセスを許可する）

承認者としての立場を持つ人だけに読み取りを絞る、目的が明確なロールです。

ロールの包含関係

itil は sn_request_write を自動的に含み、sn_request_write はさらに sn_request_read と sn_request_approver_read を含みます。ヘルプデスク担当者の標準ロール1つで、申請の履行に必要な権限が揃う構成です。

一方 catalog_admin は catalog・catalog_template_editor・catalog_builder_editor・catalog_lookup_admin・user_criteria_admin などカタログ側の設定系ロールを含みます。

この2系統には明確な境目があります。

itil はカタログ管理系ロールを含まない

role=itil^containsLIKEcatalog を実行すると0件でした。itil を持つ担当者は、sn_request_write の継承によってRITMやTaskの読み書きはできますが、カタログ項目・カテゴリの作成や編集はできません。「itilを持っているのにカタログの管理画面に何も出てこない」という相談の答えはここにあります。ヘルプデスク担当者としての権限と、カタログを設計・公開する権限は最初から別の系統として設計されています。

包含関係の一覧画面には直接指定した1件しか表示されず、実際の展開先は sys_user_role_contains を見る必要があります。この落とし穴はカタログに限りません。

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

• 参考：ServiceNowで付けたロールが想定外の権限を含んでいた理由 sys_user_role_containsで包含を実機でたどる … 包含関係の調べ方を扱っています

誰がこれらのロールを持っているか

sys_user_has_role でロールごとの割り当てを数えると、対照的な結果が出ました。

• catalog：34件（直接付与3件・継承31件）

• catalog_admin：30件

• catalog_manager：0件

• sn_request_write：79件（すべて itil からの継承、直接付与は0件）

sn_request_write を直接付与されている人は1人もいません。79人全員が itil を持つことで自動的に権限を得ています。担当者への権限付与は「sn_request_write を個別に配る」のではなく「itil を配る」運用が実態として定着していることを示す数字です。

catalog_manager は12件のロール定義の中に確かに存在しますが、本PDIでは誰にも付与されていません。役割としては用意されているものの、デモ環境の担当割り当てには反映されていない状態です。棚卸しでこの種の「定義はあるが誰も持っていない」ロールを見つけたら、運用開始時に付与漏れがないかを先に確認します。

catalog の直接付与3件は、いずれもデモデータの特定アカウント（購買・資産管理系の担当者）に限られていました。継承31件の多くは、カタログ承認関連のグループロールを経由しています。

admin を配らずにカタログの管理だけを任せたい場合は、catalog_admin を単独で付与すれば足ります。管理者権限をどこまで絞るかという判断は、カタログ以外のモジュールでも共通する考え方です。

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

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

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

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

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

4件のうち3件に catalog が含まれています。カタログの購入承認グループへは、承認業務に必要な itil に加えて catalog も一緒に配る設計です。デフォルトでは、グループ経由のロール付与をほとんど使っていません。人事異動のたびに個人のロールを付け替える前提の構成になっています。

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

ACLの内訳とロール指定の割合

sys_security_acl で sc_ 関連7テーブルの有効なACLを数えると、合計222件でした。

フィールド単位が115件とテーブル単位107件をわずかに上回ります。スクリプトで判定する高度なACLは28件で、全体の約13%にとどまります。

この222件のうち、業務の中心である sc_request・sc_req_item・sc_task の3テーブル（合計106件）に絞って、ロール指定と条件式判定の比率を数えました。

106件のうち91件（86%）にロールが指定されています。残る15件が条件式またはスクリプトによる判定です。

インシデント管理では逆の結果でした。有効151件のうち、ロールが指定されているのはわずか12件（8%）で、残る139件を条件式・スクリプトが判定していました。同じ「誰が何をできるか」を決める仕組みでも、Incidentは「どの状態のどのレコードか」で細かく判定するのに対し、Requestは「誰がそのロールを持っているか」で大づかみに判定します。担当者への権限相談を受けたとき、Incidentならまずレコードの状態を疑い、Requestならまずロールの有無を疑う。この違いが調査の初手を決めます。

履行担当が動くロール

sc_task のACLロール紐付けを見ると、itil・sn_request_write・sn_request_read・catalog・catalog_admin が登場します。

itil は sn_request_write を自動継承しているため、履行担当には itil を1つ付与すれば sc_task の読み書きに届きます。catalog ロールも sc_task のACLに個別に登場しますが、itil の包含関係には含まれていない別軸のロールです。カタログ項目の設定に直接触れる場面が多い担当者には、itil に加えて catalog 系のロールを検討します。

履行の実務では、RITMの承認からCatalog Taskの完了までロールだけでなく状態遷移も絡みます。承認とタスク完了が別段階で管理されている点は、ロールの範囲を決めるときの前提になります。

• 参考：サービスカタログの運用手順書 … 履行の実務手順を扱っています

カタログ項目の可視性はUser Criteriaが決める

カタログ項目が「誰に見えるか」は、ACLのロール指定とは別の仕組みで決まります。

含める条件を持つ sc_cat_item_user_criteria_mtom が256件、除外条件を持つ sc_cat_item_user_criteria_no_mtom が472件あり、合計728件のUser Criteriaがカタログ項目の可視性を制御しています。加えて sc_cat_item.roles フィールド自体も、204件中200件で何らかのロールを保持していました。

roles欄とUser Criteriaは併用される関係にあります。roles欄で大まかにロールを絞り込み、User Criteriaで部署・グループ・個別条件までさらに絞り込む、2段構えの制御です。「このカタログ項目がなぜ特定の利用者に見えないのか」を調べるときは、roles欄とUser Criteriaの両方を確認する必要があります。

同じ user_criteria の仕組みは、Employee Centerのトピックへのコンテンツ出し分けなど、カタログ以外の画面でも使われています。

• 参考：ServiceNowのEmployee Centerでコンテンツはどう出し分けられる？ トピックへの紐付けとUser Criteriaを実機で確認 … User Criteriaの基本的な使われ方

ナレッジ管理との共通構造

本シリーズと並行して調べたナレッジ管理モジュールでも、記事の閲覧・投稿可否を最初に左右するのはロールではなく user_criteria 経由の可視性制御でした。「見えない・できない」の一次容疑者をロールではなくUser Criteriaに置くという実務の順序は、カタログとナレッジで共通しています。

• 参考：ServiceNow ナレッジ管理（Knowledge）完全ガイド：記事はどこに置かれ、誰の承認で公開され、誰に見えるか … ナレッジ側の可視性制御を扱っています

申請者が自分の申請だけ見える仕組み

申請者にはロールを付与しないのが基本形です。それでも自分が出した申請だけは見えて、追記もできます。仕組みはACLの条件式にあります。

sc_request の read ACLには、この条件そのものを説明する公式の description が入っていました。

（訳: 自分が起票したリクエスト、または自分が申請対象者になっているリクエストは読める）

条件式の実体はこちらです。

opened_by=javascript:gs.getUserID()^ORrequested_for=javascript:gs.getUserID()

このACLには snc_internal（ログインユーザー全員が持つ基本ロール）も指定されています。つまり「ロールか条件式かのどちらか」ではなく、「ログイン済みであること」と「自分の申請であること」の両方を満たして初めて読めるという二重の判定です。106件のうちロール指定があると数えた91件には、こうしたsnc_internalのような誰でも満たせるロールと、個人を特定する条件式を組み合わせた例が含まれています。

sc_req_item 側にも end user can update their own sc_req_item records（訳: エンドユーザーは自分自身のsc_req_itemレコードを更新できる）という同種のACLがあり、こちらは request.requested_for や request.opened_by を辿って、親のRequestの申請者かどうかまで見ています。RITM単体では申請者が誰か分からなくても、親を辿って判定する作りです。

セルフサービスポータルで利用者が自分の申請一覧だけを見られるのは、ロールの絞り込みではなくこの条件式が支えています。ロールを持たない申請者に閲覧範囲を広げたい場合、sn_request_read を配るとロールを持たない他の利用者の申請まで見えるようになるため、まず条件式の対象を広げられないかを検討します。

「申請できない」ときの調べる順序

権限に関する相談を受けたとき、調べる順序を決めておくと迷いません。

1. User Criteriaを見る：対象のカタログ項目の user_criteria_mtom／user_criteria_no_mtom に利用者が含まれているか

2. roles欄を見る：sc_cat_item.roles で絞られていないか

3. 最後にACLとロールを見る：itil・catalog 等の付与有無

「見えないなら catalog ロールを足す」という対応から入ると、User Criteriaで除外されている場合に解決しません。反対に管理者ロールまで付ける過剰な対応も、User Criteriaの範囲を直せば不要な場合があります。

カタログアイテムの公開設定そのもの（下書き・レビュー・公開の状態管理）が原因になるケースもあります。可視性の切り分けとあわせて、公開状態の確認も調査の候補に入れます。

• 参考：サービスカタログのトラブル事例と解決 … 公開設定側の切り分けを扱っています

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

実機で気づいたこと

sn_request_write は誰も直接持っていない

79件の割り当てすべてが itil からの継承で、直接付与は0件でした。担当者への権限設計は「Requestの権限を個別に配る」のではなく「ヘルプデスク担当者の標準ロールを配り、その一部としてRequestの権限もついてくる」という発想で組まれています。

自社でリクエスト管理だけを分離して権限設計するときは、この前提が崩れます。itil を配らずに sn_request_write だけを直接付与する運用は、OOTBのデフォルト割り当てとは違う経路を自分で作ることになります。

catalog_manager は定義があるのに誰も持っていない

12件のロール定義の中に catalog_manager は確かに存在し、公式説明も「新しいサービスカテゴリを申請し…」と具体的です。それでも本PDIの割り当てはゼロでした。

ロールは定義されているだけでは機能しません。棚卸しをするときは、sys_user_role の定義一覧だけでなく sys_user_has_role の実際の割り当てまで見ないと、「用意されているのに誰も使っていないロール」を見落とします。導入プロジェクトでは、この種のロールに担当者を割り当てる作業が抜けやすい工程になります。

ACLの判定方式がIncidentと正反対

Incidentは条件式・スクリプトが主体（151件中139件）で、Requestはロール指定が主体（106件中91件）でした。同じServiceNowのITSMモジュールでも、権限判定の設計思想がテーブルごとに違います。

調査に入る前に「このテーブルはロール型か条件式型か」を先に確認すると、無駄な確認を減らせます。ロール型のテーブルで条件式ばかり探していると原因にたどり着けません。

フィールド単位とテーブル単位の比率もIncidentと違う

Requestのsc_関連7テーブルは、テーブル単位107件・フィールド単位115件とほぼ均衡していました。一方Incidentは、テーブル単位44件に対しフィールド単位107件と、フィールド単位が2倍以上を占めます。

Incidentは「レコード全体の書き込みは広く許し、特定フィールドだけを個別に絞る」設計に寄っており、Requestはテーブル単位の制御もフィールド単位と同程度に使っています。ACLを新設するとき、既存の配分を見てから位置を決めると、そのモジュールの設計方針に沿った置き方になります。

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

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

1. 申請者へのロール付与：既定のロールなしを維持するか、sn_request_read まで広げるか

2. 履行担当に渡すロール：他プロセスも触るなら itil、Request限定なら sn_request_write

3. カタログの作成・公開：catalog_admin に集約するか、catalog_manager と catalog_editor に分けるか

4. カタログ項目の可視性：roles 欄だけで足りるか、User Criteriaまで必要か

5. 除外条件の利用：user_criteria_no_mtom で明示的に外すユーザーがいるか

6. ロールの渡し方：ユーザー直接かグループ経由か

7. 自分の申請だけ見える設計：既定の条件式を残すか、対象フィールドを増やすか

8. 調査の入口：「申請できない」報告への確認順序をUser Criteria→roles欄→ACLに統一するか

用語

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

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

• User Criteria：user_criteria テーブルを使った、レコード単位・カタログ項目単位の可視性制御の仕組み

• mtom / no_mtom：それぞれ「含める条件」「除外条件」を保持する中間テーブルの接尾辞

• DYNAMIC：「ログイン中のユーザー」などを実行時に解決する動的フィルタ

• SOW：Statement of Work。委託契約に基づく作業範囲を管理する機能

検証範囲とおことわり

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

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

• User Criteria 728件の個別の条件内容までは追っていません

• スクリプト付きACL（3テーブルで10件）の中身までは追っていません

• sys_security_acl_role に見つかった壊れた参照2件の詳細は調査していません

• ロールをユーザー・グループへ割り当てる運用は、本シリーズ第11巻「サービスカタログの運用設計書」で扱います

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

• リクエスト管理・カタログ関連のロール：/sys_user_role_list.do?sysparm_query=nameLIKEcatalog^ORnameLIKEsn_request

• ロールの包含関係：/sys_user_role_contains_list.do?sysparm_query=role.nameLIKEcatalog^ORrole.nameLIKEsn_request

• 誰がロールを持っているか：/sys_user_has_role_list.do?sysparm_query=role.name=catalog

• 有効なACLの一覧：/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHsc_request^active=true

• User Criteria（含める条件）：/sc_cat_item_user_criteria_mtom_list.do

• User Criteria（除外条件）：/sc_cat_item_user_criteria_no_mtom_list.do

• グループの一覧：/sys_user_group_list.do?sysparm_query=rolesISNOTEMPTY

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

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

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

関連記事

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

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

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