ServiceNowで権限はどこ
「この人はなぜこの画面を開けるのか」「逆になぜ開けないのか」。ServiceNowで権限の問い合わせを受けたとき、この疑問にすぐ答えられる人は多くありません。権限はロールという1つの設定だけでは決まりません。ユーザー・グループ・ロール・ロールの入れ子・ACL・ドメイン・UI Policyという7つの層が積み重なって、最終的な見え方を作っています。Zurich PDIで各層の件数を実測し、どこから調べればよいかを1本にまとめました。
検証環境：Zurich PDI / OOTB / 2026-08-09 確認
結論：権限は1か所ではなく7つの層で決まる
先に全体像です。
権限を決める仕組みは、ユーザー（sys_user）からACL（sys_security_acl）、ドメイン（sys_domain）まで7つの層に分かれています。1つの層だけを直しても、他の層で止まっていれば見える状態にはなりません。
実測した件数を並べると、ACLが43,744件と圧倒的に多く、ロールの定義そのものは623件しかありませんでした。少数のロールが、桁違いに多いACLの可否を左右する構造です。
「見えない・触れない」という相談は、どの層で止まっているかを順番にたどれば、たいてい数分で切り分けられます。手順は記事の後半にまとめました。
図の色にはそれぞれ役割があります。紺は出発点のユーザー、水色はユーザーをまとめる参照先のグループ、緑は実際に多くのユーザーへ効いている付与経路のロールです。紫はロール本体とは別系統で自動展開される入れ子、橙は件数が最も多く最終判定を担うACLを示します。グレーは今回のPDIでは使われていないドメイン、赤は見た目だけを変えて実データは止めないUI Policy・Data Policyです。以下、層ごとに実測値を見ていきます。
①ユーザー：sys_userがいなければ何も始まらない
すべての層の出発点はsys_userです。今回のPDIには636人が登録されており、そのうちactiveな状態は635人でした。権限を語るとき見落としがちですが、そもそもレコードが存在しない、あるいはactiveがfalseになっているユーザーは、どんなロールを持っていてもログインそのものができません。問い合わせの入口として、まずこの層を疑う価値があります。
sys_userの構造そのものは奥が深く、部署・場所・上司といった参照フィールドが多数あります。1テーブルの全体像をまとめた記事がユーザー（sys_user）は1行＝1人です。ログインできない人を、ログインさせずに助ける仕組みはPassword Reset：ログインできない人を、ログインさせずに助けるで扱っています。
②グループ：人をまとめて扱う入れ物
sys_user_group（グループ）は51件、ユーザーとグループを結ぶ中間表のsys_user_grmember（所属）は193件でした。1人のユーザーが複数のグループに属することも普通にあり、ロールをグループ単位でまとめて配る運用でよく使われます。
グループそのものは業務データではなく、あくまで「まとめる箱」です。箱自体に権限はなく、箱に紐づいたロールがメンバー全員へ展開される仕組みになっています。この展開の詳細な流れは、ユーザー・グループ・ロールの中間表を1つずつたどったServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表からたどるで確認できます。
③ロール：権限の単位をどう持つか
sys_user_role（ロールの定義）は623件でした。そして「誰が実際にどのロールを持っているか」を記録するsys_user_has_roleは4,111件です。ここが今回いちばん意外だった数字でした。
直接付与はわずか153件、残りはすべて自動付与
4,111件のうち、人やグループへ直接付与したものはinherited=falseの153件だけです。残る3,958件はinherited=true、つまりロールの入れ子（次の層）によって自動的に付いた分でした。全体の96%以上が自動展開の結果ということになります。
手作業はごくわずかです。
管理者が意識して付けているのは153件分だけで、残りのほとんどは次の層で自動的に決まっているという実態です。「このユーザーにロールを1つ付けた」という操作の裏側で、実際には何十件もの権限が同時に付与されている場合があります。
④ロールの入れ子：1つのロールに何がぶら下がるか
ロールが別のロールを内包する関係を記録するsys_user_role_containsは713件でした。623件のロール定義に対して713件の包含関係があるので、平均すれば1ロールあたり1件強です。ただし実際の分布は大きく偏っています。
代表的なロールで実際にたどると、この偏りがよく見えます。itilロールは1階層目だけで24件のロールを直接含み、adminロールは13件しか直接は含んでいませんでした。数だけ見るとitilの方が広く見えますが、そこからさらに2階層目・3階層目とたどると順位が入れ替わります。itilは4階層で止まり合計42件でしたが、adminは5階層まで続き合計60件に達しました。1階層目の件数だけで「このロールは狭い」と判断すると、痛い目に遭います。
⑤ACL：データを実際に渡すかどうかを最終的に決める層
sys_security_aclは43,744件です。7つの層のなかで、この層だけ桁が2つ違います。ユーザーが636人、ロールが623件であるのに対して、ACLは4万件を超えています。細かさが段違いです。テーブル単位・フィールド単位のあらゆる操作に、1つずつルールが定義されているためです。
このうちtype=recordが41,497件で全体の94.8%を占めます。条件式（Condition）を使うACLは984件、スクリプトを使うACLは3,236件で、合わせても全体の1割に届きません。つまりACLの約9割は、条件式もスクリプトも使わず「必要なロールを持っているかどうか」だけで判定するシンプルな作りでした。
admin_overridesが約半数のACLに設定されている
sys_security_aclにはadmin_overridesという真偽値のフィールドがあります。43,744件のうち21,637件（約49.5%）がtrueでした。このフィールドがtrueのACLでは、adminロールを持つユーザーは条件を評価せずに通過できます。逆にfalseのACLでは、adminであっても通常の条件判定を経る必要があります。「管理者ならなんでも見える」という感覚は、正確には「約半数のACLで管理者は条件をスキップできる」という状態です。
ACLの構造そのもの、テーブル単位・フィールド単位の違いはロールを付けたのに見えない理由：ACL（sys_security_acl）で扱っています。
⑥ドメイン：組織ごとにデータを分ける仕組み（本PDIでは未有効）
sys_domain・sys_domain_pathは、複数の組織や部門のデータを1つのインスタンスで分けるための列です。今回のPDIではドメイン分離のプラグインがすべて無効になっていました。
Domain Tracking・Performance Analytics – Domain Support・sn-pa-domain-filterなど、ドメイン分離に関わるプラグインは複数あります。実機で確認した限り、そのすべてがInactiveでした。名前が似ている「Reliability Metrics for Data Management Domain」だけActiveですが、これはドメイン分離本体とは無関係な機能です。
未有効だからといって、この層が空というわけではありません。sys_domain列はディクショナリに1,781件定義されており、テーブル総数6,317件のうち約28%にはすでに列そのものが組み込まれています。有効化されていなくても「分離するための器」は最初からプラットフォームに用意されている、というのがこの層の実態でした。分離の仕組みそのものはドメイン分離は2つのフィールドで決まる（sys_domain）で詳しく確認できます。
⑦UI Policy・Data Policy：見た目を変えるだけの層
sys_ui_policyは2,909件、その動作を定義するsys_ui_policy_actionは5,102件でした。
Visible（表示・非表示を操作する設定）の内訳は、True 1,967件・False 2,036件・既定のまま（Leave alone）1,096件・空3件です。項目を「隠す」設定と「見せる」設定はほぼ同数で、意図的に隠す運用が特別なものではないと分かります。API連携用に必須制約をかけるData Policy（sys_data_policy2）も130件ありました。
この層で気をつけたい点があります。UI PolicyはあくまでUI側の表示制御であり、サーバー側のデータ取得そのものは止めません。ACLのreadが通っていれば、画面上は隠れていてもAPIやレポート経由では値を取得できてしまいます。項目だけが消える原因は、ビュー・レイアウト・UI Policy・ACL・辞書の上書きの6段階で切り分けられます。詳しい手順はServiceNowで項目が画面に出ないのはなぜ？ ビュー・UI Policy・ACLを順番に切り分けるにまとめました。フィールド単位の細かい切り分けは、そちらに譲ります。
「見えない・触れない」をどの順番で切り分けるか
7つの層の役割が分かったところで、実務でいちばん使う場面に移ります。「あの画面が開けない」という相談を受けたとき、どの順番で確認すれば早いかという手順です。
第1段階：そもそもロールを持っているか
sys_user_has_roleに該当ロールがあるかを確認します。直接付与153件・継承3,958件のどちらにも当てはまらなければ、権限そのものが付いていません。この場合はグループ経由で付くはずだったのか、個別に付ける想定だったのかを、まず切り分けます。
第2段階：同じロールを持つ別のユーザーでも見えないか
ロールはある、という前提で次に確認するのがこの1問です。自分だけ見えないのであれば、個人差分（グループ限定のACLやドメインの割り当て差）を疑います。誰が試しても見えないのであれば、全体設定側の問題です。この1問だけで、確認範囲がおおよそ半分に絞れます。
第3段階：該当ACLのreadが通っているか
誰も見えない場合は、ACLの出番です。sys_security_aclを開き、対象のテーブル・フィールドに対するread操作のACLを探します。止まっている原因は、admin_overridesの値か、条件式か、Requires roleのどれかです。43,744件という規模でも、対象のテーブル名で絞り込めば数件から数十件に収まります。
第4段階：レコードのドメインが自分と一致しているか
ACLは通るのに見えない場合、残る候補はドメインです。今回のPDIは未有効でしたが、有効化された本番環境ではここで止まっているケースが起こり得ます。ここまで通れば、たいていの相談は解決済みです。それでも項目だけが見えないのであれば、UI Policyやフィールド単位のACLへ話が移ります。
この4段階を1画面でまとめて確認できるツールもあります。Access Analyzer：「見えない」の理由を層で切り分けるは、ロール・ACL・フィールド権限をまとめて診断する専用ツールです。急いでいるときは、こちらから試す方が早い場合もあります。
どの記事から読めばいいか
7つの層それぞれに、実機でさらに詳しく調べた記事があります。困りごとに応じて読む記事を選べるよう、一覧にしました。
ロールの入れ子（④の層）は単独で1本にまとめています。itilとadminを6階層までたどると、直接の包含数では上だったitilが逆転される結果になりました。詳しくはServiceNowで付けたロールが想定外の権限を含んでいた理由 sys_user_role_containsで包含を実機でたどるをご覧ください。
実機で気づいたこと
adminロールのフォームを開いて、いちばん驚いたのは「強さを示すフラグが一切無い」ことでした。拍子抜けしました。
Elevated privilege（昇格が必要な強いロールかどうか）はオフ、Scoped adminもオフです。「最強のロールなのだから特別なフラグが立っているはず」という予想は外れました。Descriptionには公式の注意書きがそのまま書かれています。「このロールはセキュリティ制約に関係なくすべてのシステム機能・機能・データにアクセスできる。この権限は慎重に付与すること。HR記録のような機密情報を守る必要がある場合は、その領域専用のカスタムadminロールを作り、そのレコードを見る権限を持つ人を管理者として教育すること」という趣旨です。adminの強さの正体は、⑤の層で見たACL側のadmin_overridesでした。ロール自身の設定には、その強さは表れていません。
もう1つ意外だったのが、elevated_privilege=trueのロールを数えたときの結果です。集計API（stats）は4件と返しましたが、実際に一覧を開くと3件しか表示されませんでした。
表示された3件はais_high_security_admin・ai_security_admin・workspace_list_adminです。集計と一覧で件数が1件ずれるという経験は今回が初めてで、原因はこのPDIの読み取りだけでは特定できませんでした。件数を扱うときは、集計APIの数字を鵜呑みにせず、実際の一覧やレコードでも裏を取った方が安全だと実感した場面です。
UI Policy Actionの内訳（True 1,967・False 2,036・Leave alone 1,096）を見たときも、当初は「隠す設定の方が圧倒的に多いはず」と思い込んでいました。実際には見せる設定とほぼ同数です。項目の表示制御は、隠すためだけでなく、条件が成立したときに初めて見せるという使い方でも広く使われているようでした。
実務では何に使えるか
権限の設計や見直しをするとき、この7層構造はそのままチェックの下敷きになります。新しいロールを作る前には、④の層で「このロールを付けたら何が一緒に付いてくるか」をsys_user_role_containsで確認してから配ると安全です。ACLを新設するときは、admin_overridesを本当にtrueのままでよいか1件ずつ判断する価値があります。約半数がtrueという既定の比率は、意図して選んだ値ではなく単なる既定である場合が多いためです。
問い合わせ対応では、今回まとめた4段階の切り分け手順をそのままチームの一次対応チェックリストにできます。ロールの有無・他ユーザーとの比較・ACL・ドメインという順に潰していけば、多くの相談は最初の2段階で片付きます。
よくある質問
Q1. どの層から確認するのが一番早いですか
ロールの有無（sys_user_has_role）です。付与自体が無ければ、他の層をいくら調べても答えは出ません。次に「他のユーザーでも同じ現象が起きるか」を確認すると、個人差分か全体設定かで調査範囲が半分に絞れます。
Q2. adminロールなら必ずすべて見えますか
いいえ。admin_overridesがfalseのACLでは、adminロールを持っていても通常の条件判定が必要です。今回のPDIでも約半数のACLはfalseでした。「管理者だから見えるはず」という前提で調査を止めると、この半数を見落とします。
Q3. ドメイン分離を使っていない環境でも、この記事の内容は関係ありますか
はい。sys_domain列は多くのテーブルに既に組み込まれており、将来ドメイン分離を有効化したときにいきなり効き始めます。未有効の状態でも、列自体は存在するという事実は知っておく価値があります。
Q4. グループに付けたロールと、個人に直接付けたロールで扱いは変わりますか
最終的にsys_user_has_roleへ展開される点は同じです。ただしgranted_byというフィールドで、どのグループ経由の付与かを追跡できます。個人へ直接付けた場合はこの値が空になります。
用語
sys_user_has_role：誰にどのロールが実際に付いているかを記録するテーブル。inherited列で直接付与か自動展開かが分かる
sys_user_role_contains：ロールが別のロールを内包する関係を記録する中間表
admin_overrides（sys_security_acl）：trueの場合、adminロールを持つユーザーはそのACLの条件を評価せず通過できる
ドメイン分離：複数の組織・部門のデータを1つのインスタンスで論理的に分ける仕組み。sys_domain / sys_domain_pathの2列が基点
UI Policy：フォーム上で項目の表示・必須・読み取り専用を条件に応じて切り替える設定。サーバー側のデータ取得は止めない
実機で調べるときに開いたURL
/sys_user_has_role_list.do?sysparm_query=GROUPBYinherited … ロール付与の直接・継承内訳
/sys_security_acl_list.do?sysparm_query=GROUPBYadmin_overrides … ACLのAdmin overrides内訳
/sys_ui_policy_action_list.do?sysparm_query=GROUPBYvisible … UI Policy ActionのVisible内訳
/sys_user_role_list.do?sysparm_query=elevated_privilege=true … 昇格が必要なロールの一覧
/sys_user_role.do?sys_id=<adminのsys_id> … adminロールのフォーム（Contains Rolesタブ）
/v_plugin_list.do?sysparm_query=nameLIKEDomain … ドメイン分離関連プラグインの状態
参考リンク
さらに詳しく知りたい人へ
ServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表からたどる — ①〜③の層をさらに詳しくたどる基礎編
ロールを付けたのに見えない理由：ACL（sys_security_acl） — ⑤の層の構造と評価の仕組みを詳しく解説
Access Analyzer：「見えない」の理由を層で切り分ける — この記事の切り分け手順を1画面で行う実務ツール編
検証環境と未検証範囲
数値はZurich PDI（OOTB）で2026-08-09に確認したものです。本番環境やカスタマイズ済みの環境では、ロール構成・ACL設定・件数が異なります。
確認した範囲は次のとおりです。
7層それぞれの主要テーブルの件数（sys_user、sys_user_group、sys_user_grmember、sys_user_role、sys_user_has_role の inherited内訳、sys_user_role_contains、sys_security_acl の type・admin_overrides・条件式・スクリプトの内訳、sys_security_acl_role、ドメイン分離プラグインの有効状態、sys_dictionary の sys_domain 列定義数、sys_ui_policy、sys_ui_policy_action の visible内訳、sys_data_policy2）
adminロール・elevated_privilegeロールのフラグと件数（集計APIと一覧・レコードAPIで1件差が生じた点を含む）
確認していない範囲は次のとおりです。
ACLエンジンの内部評価順序、複数のACL・UI Policyが競合したときの最終的な優先順位の詳細
ドメイン分離を実際に有効化した場合の挙動（本PDIは未有効のため測定不可）
Access Analyzer・Access Simulatorの内部ロジック
本番環境・カスタマイズ済み環境での件数
集計API（stats）と一覧・レコードAPIで件数が1件ずれた原因
