ユーザー（sys_user）は1行＝1人

2026年6月28日 10:31

ServiceNow で「このインシデントの担当者」「この申請の承認者」「このレコードを更新した人」といったとき、その“人”は必ずどこかのテーブルの1行として存在します。その器になっているのが sys_user（画面ラベルは User） です。割り当て先（assigned_to）も申請者（caller_id）も、グループの所属もロールの保有も、すべて sys_user の1レコードを起点につながっています。

この記事は、ServiceNow の画面操作には慣れたが、ユーザー情報がどのテーブルに、どんな形で持たれているのかをこれから確認したい管理者・開発者を想定しています。PDI（Zurich / OOTB）で sys_user を実際に開きます。1行＝1人（1アカウント）であることを確かめます。そのうえで、アカウントの状態を表す active / locked_out / vip と、組織情報につながる department / location / manager などの参照を見ます。あわせてグループとロールが中間表でどうつながるのかも見ます。

この記事で分かること

ユーザー情報が sys_user（User）の1行＝1人（1アカウント）として持たれること
sys_user が独立したルート基底テーブルで、人（アイデンティティ）の基底であること
アカウント状態の active / locked_out / vip（と連携用フラグ）の意味と、PDI 実機の内訳
department / location / manager / company などの参照で組織情報につながること
グループ・ロールが多対多で、中間表 sys_user_grmember / sys_user_has_role を介すること
代表的な OOTB ユーザ（admin / guest）と、「system」は sys_user に存在しないこと

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、ユーザー数・フラグの内訳・参照先の規模が異なります。

ユーザーテーブル（sys_user）とは

sys_user は、ServiceNow における“人”を1件＝1レコードで持つテーブルです。アプリナビで「User Administration > Users」を開くと見えるのが、この sys_user です。社員・外部委託・連携用のアカウントまで、ServiceNow を使う（あるいは ServiceNow に登場する）すべての人がここに並びます。

下の画面は、PDI（Zurich / OOTB）の sys_user 一覧です。User ID・Name・Email・Active といった列が並び、1行が1人を表します。

PDI（Zurich / OOTB）の sys_user には 634件のユーザが登録されていました。assigned_to や caller_id などレコード上の“人”は、すべてこの1行への参照です。つまり sys_user は、ServiceNow 全体の「人」を一手に引き受ける基底テーブルです。

sys_user はどんなテーブルか

名前に sys_ が付くので特別に見えますが、継承元を確認するとシンプルでした。今回の PDI（Zurich / OOTB）では、sys_user の super_class（継承元）は空でした。task も cmdb も継承しない 独立したルート基底テーブルです。人というアイデンティティを専門に受け止める器として、業務テーブルとは独立して用意されています（固有フィールドは66要素ありました）。

1行のユーザが持つ主なフィールドは次のとおりです。

中心になるのは user_name（ログインID）・name（表示名）・email の本人情報と、状態を表すフラグ、そして組織につながる参照フィールドです。フィールド定義は次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_user^elementISNOTEMPTY

active / locked_out / vip：アカウントの状態

ユーザの“今の状態”は、いくつかの boolean フラグで表されます。PDI 実機で件数を数えると、それぞれの位置づけがはっきりしました。

active（既定 true） … 有効フラグ。ログインの可否や、割り当て候補に出るかを左右します。退職などで使わなくなったユーザは、削除せず active=false にして無効化するのが定石です（履歴上の“誰が”を残すため）。
locked_out（既定 false） … アカウントロック。ログイン失敗が続くなどで true になると、認証そのものが拒否されます。
vip（既定 false） … 要人フラグ。フォームなどで強調表示され、優先度や SLA の判断材料になることがあります。

PDI 実機での内訳は次のとおりです。

OOTB の634件はほぼ全員が active=true（633件、無効は1件だけ）で、locked_out も vip も各1件でした。さらに、人ではない特別なユーザもいます。internal_integration_user（連携用の内部ユーザ）が3件、web_service_access_only（API専用・対話ログイン不可）が8件です。下の画面は、その連携用ユーザだけを絞ったものです。

https://<YourInstance>/sys_user_list.do?sysparm_query=internal_integration_user=true

このように sys_user には、生身の人だけでなく連携・自動処理のためのアカウントも同居しています。だからユーザ数を数えるときは、フラグで“人”と“システム”を区別する必要があります。

department / location / manager：組織につながる参照

sys_user は本人情報だけでなく、所属組織への参照を多く持ちます。代表的なのは次の参照フィールドです。

department → cmn_department（部署）
location → cmn_location（拠点）
company → core_company（会社）
manager → sys_user（自己参照＝上長もまた1人のユーザ）

manager が同じ sys_user を指す自己参照になっています。これによって「上長の上長」という組織のツリーを、テーブルだけで表現できます。PDI 実機での設定状況と参照先の規模は次のとおりです。

PDI では department が569件のユーザにセットされていた一方、manager が入っているのは13件だけでした。OOTB のサンプルデータは部署までは埋まっていても、上長まではあまり設定されていない、という実態が数字から見えます。なお1人のユーザのフォームを開くと、これらの情報がまとまって表示されます。

グループとロールは中間表でつながる（多対多）

ユーザは1人で複数のグループに所属でき、複数のロールを持てます。逆に1つのグループ・ロールにも多数のユーザがぶら下がります。この多対多の関係は、sys_user に列で持つことができません。そこで間に中間表（行で関係を表す表）を挟みます。

sys_user_grmember … ユーザ ↔ グループ（sys_user_group）の所属。PDI で193行。
sys_user_has_role … ユーザ ↔ ロール（sys_user_role）の付与。PDI で4,013行。

sys_user フォームに見える「Roles」関連リストは、この sys_user_has_role を表示しているだけで、実体は中間表側にあります。たとえば admin（System Administrator）は、sys_user_has_role に72行、sys_user_grmember に2行を持っていました。下の画面は、ユーザとロールの中間表そのものです。

この「人 → 中間表 → グループ/ロール」のつながりは、ServiceNow の権限の根っこです。グループ・ロールそのものの構造は「ServiceNow のユーザー・グループ・ロールを実機で読み解く」で、付与されたロールがどう権限になるかは「権限を決める ACL（sys_security_acl）」で詳しく扱っています。あわせて読むと、人から権限までが一本の線でつながって見えます。

代表的な OOTB ユーザと「system」の話

PDI には、最初から入っているユーザがいます。よく出てくるのが admin（System Administrator）と guest（Guest）です。どちらも active=true で、admin は管理用、guest は未ログイン時などに使われる匿名相当のユーザです。

ここで一つ注意したいのが、ログや監査ログで頻繁に見かける 「system」は sys_user に存在しない ことです。PDI で user_name=system を数えると0件でした。「System」は ServiceNow 内部の実行アイデンティティ（プラットフォーム自身が処理する主体）であって、sys_user の1行ではありません。システムログや監査ログで「system が更新した」と見えても、それを sys_user で探しても見つかりません。この感覚を持っておくと、ユーザ調査で迷いません。

実機で確認するときに見るべきURL

最後に、今回見た画面を自分のインスタンスで開くためのURLをまとめます（<YourInstance> は置き換えてください）。

# ユーザ一覧
https://<YourInstance>/sys_user_list.do

# 連携用の内部ユーザだけ絞る
https://<YourInstance>/sys_user_list.do?sysparm_query=internal_integration_user=true

# ユーザとロールの中間表
https://<YourInstance>/sys_user_has_role_list.do

# ユーザとグループの中間表
https://<YourInstance>/sys_user_grmember_list.do

# sys_user のフィールド定義
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_user^elementISNOTEMPTY

まとめ

ユーザー情報は sys_user（User）の1行＝1人（1アカウント）として持たれる。PDI では634件。
sys_user は独立したルート基底テーブルで、ServiceNow における人（アイデンティティ）の基底。
状態は active（既定 true・無効化は false）/ locked_out / vip で表す。PDI では active=false・locked_out・vip が各1件。
連携用の internal_integration_user（3件）/ web_service_access_only（8件）など、人でないアカウントも同居する。
department / location / company / manager（自己参照）で組織情報につながる。manager 設定は13件と少なかった。
グループ・ロールは多対多で、中間表 sys_user_grmember（193行）/ sys_user_has_role（4,013行）を介す。
admin / guest は OOTB ユーザ。一方 「system」は sys_user に存在しない内部アイデンティティ。

sys_user が分かると、ユーザー・グループ・ロール・ACL（権限）・ドメイン分離・ユーザー設定 sys_user_preferenceが、「人がいる → グループ/ロールが付く → 権限が決まる → 個人設定を持つ」という流れでつながって見えてきます。