ServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表からたどる
「この人はなぜこの画面を開けるのか分からない」「ロールを外したのに権限が残っている」。ServiceNowの権限調査でよく出くわす場面です。原因はユーザー・グループ・ロールという3つのテーブルではなく、それらをつなぐ中間表（sys_user_grmember・sys_user_has_role）にあります。Zurich PDIで636人のユーザーと4,111件のロール付与を実機で確認しました。
検証環境：Zurich PDI / OOTB / 2026-08-08 確認
結論：権限は3テーブルと2つの中間表で決まる
先に全体像です。
ServiceNowの権限は、ユーザー（sys_user・636件）、グループ（sys_user_group・51件）、ロール（sys_user_role・623件）という3つのテーブルに分かれています。
「所属」と「ロール付与」は、ユーザー側にもグループ側にも保存されません。所属は中間表 sys_user_grmember（193件）、付与は中間表 sys_user_has_role（4,111件）に1行ずつ保存されます。
ロールは623種類しかないのに、付与レコードは4,111件あります。差の大部分は「ロール包含」による自動付与で、人が直接付けたロールはわずか153件でした。
図の色は役割の違いを示します。濃紺はこの記事の起点になるユーザー、水色はユーザーから参照される側のグループとロール、紫は所属を記録する中間表、橙は件数が他よりはるかに多いロール付与の中間表です。この後の節で、5つのテーブルを1つずつ見ていきます。
なぜ「人」「集まり」「権限」が別テーブルになっているのか
ロールはユーザーに直接付けることも、グループにまとめて付けてメンバー全員へ配ることもできます。1人が複数のグループに入り、1つのグループに複数の人が入るという多対多の関係は1つのテーブルの中に書き込めないため、「人」「集まり」「権限」が別テーブルに分かれ、それらをつなぐ中間表が必要になります。理由はシンプルです。
5テーブルの継承関係と件数は次のとおりです。
sys_user・sys_user_group・sys_user_grmember・sys_user_has_roleの4つはExtends tableが空のルート基底テーブルでした。sys_user_roleだけがApplication File（sys_metadata）を継承しています。ロールはアプリケーションの更新セットで運ばれる「メタデータ」として扱われるため、他の4つとは性格が違います。
固有フィールド数はsys_userが66と最も多く、sys_user_group19、sys_user_role11と続きます。中間表はgrmember8・has_role15で、2テーブルの中では最小です。中間表の役割が「2つのレコードを結びつける」ことに絞られているからです。
ロール一覧には、access_analyzer_adminのような特定機能に絞られたロールから、admin（ほぼ全機能に届く）まで623件が並びます。このうちGrantable（管理者以外にも付与できる）がtrueのものは614件でした。多くのロールが、通常のユーザーにも配れる設計になっています。
公式のExploring user administration（Zurich）に、ユーザー・グループ・ロールがどう連携してアクセスを制御するかの全体像が説明されています。ロールを新規に作る手順は、公式のCreate a role（Zurich）に説明されています。
ロールレコード自体にはどんな設定が書けるか
sys_user_roleという1件のレコードにも、権限の性質を決めるフィールドがいくつも用意されています。
grantable … 管理者以外にも付与してよいロールかどうか
elevated_privilege … 通常のセッションでは有効にならない、昇格が必要な強いロールかどうか
can_delegate … このロールを持つ人が、他のユーザーへロールを委任できるかどうか
scoped_admin（Application Administrator） … スコープアプリ内だけの管理者権限かどうか
includes_roles … このロールが内包する子ロールの一覧（sys_user_role_containsの元データ）
assignable_by（→sys_user_role） … このロールを付与するために、逆に必要になる別のロール
今回のPDIで実際にtrueの件数を数えると、elevated_privilegeは623件中わずか4件でした。can_delegateは618件と、ほとんどのロールで委任が許可されています。scoped_adminは6件だけです。強い権限や特別な扱いを必要とするロールは少数で、大半のロールは通常のセッションでそのまま有効になり、委任も制限されていない設計だと分かります。
assignable_byが設定されているロールは、623件中13件だけでした。特定のロールを付与するために、さらに別のロールが要るという二段構えの設計は、ごく限られた場面でだけ使われています。
所属はどこに保存されている？ sys_user_grmemberを見る
「Aさんはこのグループに所属している」という情報は、ユーザーのレコードにもグループのレコードにも直接は入りません。所属は1件ずつsys_user_grmember（Group Member）テーブルに保存されます。
sys_user_grmemberの固有フィールドはわずか8で、本質はuser（→sys_user）とgroup（→sys_user_group）という2つの参照だけです。この「1所属＝1レコード」という形が多対多を成立させます。1人が複数のグループに入れば、その数だけレコードが並びます。仕組みは単純です。
今回のPDIではgrmemberは193件でした。ユーザーフォームの「Groups」タブも、グループフォームの「Group Members」関連リストも、この同じテーブルを別の角度から表示しているだけです。
公式のCreate a group（Zurich）に、グループの作成とメンバー追加の手順が説明されています。
ロールの付与はどこに保存されている？ sys_user_has_roleを見る
ロールの付与も考え方は所属と同じです。ただし、こちらはgrmemberより一段複雑です。ロール包含（1つのロールが別のロールを内包する仕組み。定義はsys_user_role_contains）という機能があり、親ロールを1つ付けると、含まれる子ロールが自動的に展開されるからです。
sys_user_has_roleの主なフィールドは次のとおりです。
user（→sys_user） … どのユーザーに付与されたか
role（→sys_user_role） … どのロールが付与されたか
granted_by（→sys_user_group） … どのグループ経由で付与されたか
inherited（boolean） … ロール包含によって自動的に付いた行かどうか
今回のPDIでは、sys_user_has_role全体が4,111件、うちinherited=false（直接付与）が153件、inherited=true（包含による自動付与）が3,958件でした。差は歴然です。実際に人が手で付けたロールは153件だけで、残り3,958件はロール包含が展開した結果ということになります。ロールが623種類しかないのに付与レコードが4,111件もあるのは、この継承のためです。ロール包含の定義そのものはsys_user_role_containsにあり、713件登録されていました。
公式のUser Role Inheritance API（Zurich）に、ロール継承（inheritedなロール）をAPIの観点でどう扱うかが説明されています。
2つの中間表を並べて見ると何が分かるか
どちらの中間表も「userへの参照」を必ず持ち、相手側（groupまたはrole）への参照とセットで1行を作ります。これが多対多の基本形です。sys_user_has_roleには、grmemberにはないgranted_byとinheritedという2つのフィールドが追加されました。granted_byはどのグループ経由かを示し、inheritedは包含か直接かを示す仕組みです。この2つがあるおかげで、「なぜこの人がこのロールを持っているのか」を1行で説明できます。
グループにロールを付けると、そのメンバーへロールが配られます。その経路はgranted_byに記録され、グループ脱退でロールが外れるといった連動もこの中間表の上で起きます。
ユーザーフォームを見るだけで権限量は分かるか
ここまでのテーブルは、ユーザーフォームを開くとタブとして集約されて見えます。
adminユーザーのフォームには「Roles (71)」「Groups (2)」というタブが並びます。この数字はそれぞれsys_user_has_role・sys_user_grmemberの行数そのものです。Rolesタブの中身を数えると、71件のうち66件がinherited=true（包含による自動付与）、5件がinherited=false（直接付与）でした。adminロール1つに、これだけの数の管理系ロールがぶら下がっている計算です。
フォーム上では「ユーザーが直接ロール・グループを持っている」ように見えても、保存場所は中間表です。付与の経路（直接か・グループ経由か・継承か）まで知りたいときは、タブの件数だけでなく、その裏にあるgrmember / has_roleの行を確認します。
これがACL（権限判定）の前提になる
ユーザー・グループ・ロールの構造が分かると、ACL（アクセス制御）の読み方が一段わかりやすくなります。ACLは「このテーブル／フィールドを操作するには、どのロールが必要か」を定義するもので、判定対象は常に「そのユーザーが結局どのロールを持っているか」です。
ユーザーがあるロールを持っているように見えても、経路は直接・グループ経由・ロール継承の3通りあります。それによって外し方や調査の入口が変わります。権限がおかしいときに、最初に見るのはACLではありません。sys_user_has_role / sys_user_grmemberの行です。「ACLの手前に、人・グループ・ロールという土台がある」という位置づけを押さえておくと、調査がぶれません。ACLのルールそのものの読み方は、公式のAccess Control List Rules（Zurich）にまとまっています。
sys_userにはどんな周辺設定がついているか
ユーザーの動きは、フィールド定義だけでは決まりません。保存時の処理はBusiness Rule、操作はUI Action、権限はACLが関係します。
特徴的なのはフィールド単位のACLが89件と多いことです。ユーザーレコードはパスワードやメール、各種個人情報を含むため、項目ごとにきめ細かく読み書きを制御しています。ここで数えているのはsys_userに直接紐づく設定だけで、実際の挙動はロール・グループ側の設定やACLの評価順序とも合わさって決まります。
実機で気づいたこと
OOTB（初期設定のまま）という言葉から、件数は固定値だと思い込んでいました。実際は違います。同じPDIを1ヶ月半ほどあけて数え直すと、sys_user_roleは597件から623件、sys_user_has_roleは4,013件から4,111件に増えていました。パッチ更新のたびに、ロールと権限のOOTBデータそのものが増えていくようです。「OOTBだから確認済み」と思っていても、確認した時期が古ければ数字は当てになりません。
adminフォームの「Roles (71)」というタブ表示も意外でした。以前はhas_role一覧を開いて件数を数える必要がありましたが、今のユーザーフォームはタブの見出しに件数バッジが表示されるので、related listを開かなくても大まかな権限量が分かります。ロールが多いユーザーを探すときは、まずこのタブの数字を横に並べて比べるのが早いはずです。
直接付与とロール継承の比率にも差がありました。全ユーザー分の直接付与は153件しかないのに、admin1人だけで直接付与が5件あります。adminは一般ユーザーより直接ロールを積み増しされているアカウントだと分かります。ロール包含だけに頼らず、必要な権限を直接足しているケースが管理者アカウントには残っているようです。
実務では何に使えるか：権限を調べるときの見る順番
「この人になぜこの権限があるのか」を調べるときは、次の順で見ると迷いません。
ユーザーフォームのRoles / Groupsタブで件数を確認する
sys_user_has_roleでそのユーザーのロールを開き、inheritedがtrueかfalseかを見る
inherited=trueならgranted_by（グループ経由か）とsys_user_role_contains（どの親ロールの包含か）をたどる
inherited=falseなら直接付与なので、そのレコードの作成日・作成者を確認する
ここまでで実効ロールが分かってから、初めてACL（sys_security_acl）の条件を見る
直接付与をできるだけ減らし、ロールの包含とグループ経由で権限を配る設計にすると、棚卸しや退職処理が楽になります。sys_user単体を見るだけで終わらせず、横のgrmember / has_role、上のrole_contains（包含）もセットで見る習慣をつけておくと、権限調査で迷いません。
退職者のアカウントを無効化したのに、まだ一部の画面が開けると相談されることがあります。この場合もまずsys_user.activeを見ますが、activeをfalseにしただけでは、has_roleやgrmemberの行は自動的には消えません。行が残っていれば、ロールや所属はそのまま生きています。棚卸しの際は、無効化と合わせてこれらの行を確認する運用にしておくと安全です。
用語
中間表（junction table）：2テーブルの多対多を「1関係＝1レコード」で表す表
sys_user_grmember（Group Member）：ユーザー⇔グループの所属レコード
sys_user_has_role（User Role）：ユーザー⇔ロールの付与レコード
ロール包含：1つのロールが別のロールを内包する仕組み（定義はsys_user_role_contains）
inherited：包含によって自動付与されたhas_role行かどうかのフラグ
実機で調べるときに開いたURL
/sys_db_object_list.do?sysparm_query=name=sys_user^ORname=sys_user_group^ORname=sys_user_role^ORname=sys_user_grmember^ORname=sys_user_has_role … 5テーブルの定義
/sys_user_grmember_list.do … 所属一覧
/sys_user_has_role_list.do?sysparm_query=inherited=true … 継承ロールだけ
/sys_user_role_list.do … ロール一覧
/sys_user.do?sys_id=<対象ユーザー> … ユーザーフォーム（Roles / Groupsタブ）
よくある質問
Q1. 直接付与と継承ロール、どちらを先に確認すればいいですか
Rolesタブの件数を見てから、sys_user_has_roleを開いてinherited列を確認します。継承（inherited=true）の方が件数として圧倒的に多いので、まず継承経路を疑うのが近道です。直接付与（inherited=false）は全体で153件しかなく、意図して付けられた例外的な設定である可能性が高いといえます。
Q2. グループ経由のロールと直接付与のロールは、どちらが優先されますか
両方とも同じsys_user_has_roleの行として保存されるため、優先順位という概念自体がありません。あるロールを持っているかどうかは、直接付与・グループ経由・ロール継承のいずれかの行が1つでも存在すれば真になります。そのロールを外すには、原因になっているすべての経路を1つずつ止める必要があります。
Q3. sys_user_group_typeとは何ですか
グループを分類するための選択肢で、4件（itil・survey・Knowledge・catalog）登録されていました。sys_user_groupのtypeフィールドはglide_list型なので、1つのグループに複数の種別を同時に付けられます。この種別自体は権限判定には使われず、Notificationの宛先選定など別の用途で参照されます。
Q4. adminロールを外せば、権限は全てなくなりますか
adminの71件のロールのうち66件は、adminロールの包含によって自動展開されたものです。ただしadminには、それとは別に直接付与のロールも5件あります。adminロールだけを外しても、この5件の直接付与ロールによる権限が残る点に注意が必要です。権限を完全に外すには、has_roleの行を個別に確認します。
さらに詳しく知りたい人へ
ユーザー（sys_user）は1行＝1人 — sys_user単体のフィールド構造を詳しく見る
ロールを付けたのに見えない理由：ACL（sys_security_acl） — 実効ロールをACLがどう判定するかを追う
Access Analyzer：「見えない」の理由を層で切り分ける — 権限調査を1画面で行うツールの実務編
参考リンク
検証環境と未検証範囲
件数はZurich PDI（OOTB）で2026-08-08に確認したものです。本番環境やカスタマイズ済み環境では、ユーザー数・グループ構成・ロール設計・件数が異なります。
確認した範囲は次のとおりです。
5テーブルの継承関係、固有フィールド数、レコード件数
中間表（grmember / has_role）のキー参照、has_roleのinherited内訳
sys_user_role_contains件数、ロールレコード自体のフィールド（grantable / elevated_privilege / can_delegate / scoped_admin）の実測
adminユーザーのロール・グループ内訳、sys_user周辺設定件数
確認していない範囲は次のとおりです。
ACL（sys_security_acl）自体の構造・評価順序
各ACL / Business Ruleの内部スクリプトの挙動
グループのロールがメンバーへ展開される詳細フロー（sys_group_has_role経由の連動）
SSO / LDAP連携、条件付きロール付与、Delegated Developmentの権限
Service Portal上の見え方、本番でのカスタムロール設計
