ユーザー設定（sys_user_preference）の二層構造

ServiceNow を毎日触っていると、自分だけの細かい状態が勝手に保たれていることに気づきます。一覧の並び順が前回のまま開く、ナビゲーターのメニューが開いた状態を覚えている、最後に見たダッシュボードが再表示される、といった具合です。この個人の状態を1件ずつ保存しているのがユーザー設定（User Preference）、テーブル名で言うと sys_user_preference です。

この記事は、システムプロパティ（sys_properties）は知っている管理者・開発者を想定しています。「ユーザーごとの設定はどこに溜まるのか」「挙動が人によって違うのはなぜか」という疑問に答えます。PDI（Zurich / OOTB）で sys_user_preference を実際に開き、1行＝1つの設定（name=value）であることを確かめます。個人設定とシステム既定の二層になっていること、そして両者が同じ設定名でどう効き分けるかも、実データで追います。

この記事で分かること

• ユーザー設定は sys_user_preference の1行＝name=value で保存されること

• user（→ sys_user）が付けば個人設定、空かつ system=true なら全ユーザー共通の既定という二層構造

• PDI 実機で総数246件・うち system=true が177件・個人設定（user 付き）が69件であること

• 同じ name（change_request.db.order）が「既定＝number」「管理者だけ sys_updated_on」で共存し、個人設定が優先されること

• 一覧の並び順・メニューの開閉・最後に開いた画面など、個人の UI 状態がここに自動で溜まること

• インスタンス全体の sys_properties との違い（全体設定 vs ユーザー単位／UI状態）

ユーザー設定（User Preference）とは

ユーザー設定とは、ある設定を「名前（name）と値（value）」のペアで1件＝1レコードに残したものです。たとえば「Change の一覧を、番号順ではなく更新日時順で並べる」という個人の好みが、sys_user_preference の1行として保存されています。下の実画面は、その1行をフォームで開いたものです。

このレコードには、Name に change_request.db.order、Value に sys_updated_on が入っています。User は System Administrator です。つまり「System Administrator は Change 一覧を sys_updated_on（更新日時）で並べる」という、その人だけの設定です。

PDI（Zurich / OOTB）の sys_user_preference には、すでに 246件の設定が入っていました。

1レコードの構造：name=value に「誰の・既定か」が付く

sys_user_preference の固有フィールドはシンプルで、中心は name と value です。そこに「誰の設定か（user）」「全員向けの既定か（system）」「値の型（type）」が付きます。

ポイントは2つです。

• value は最大65,000文字まで入ります。だから単純な true だけでなく、JSON で UI 状態を丸ごと保存できます（例：最後に見たダッシュボードの sys_id と日時）。

• type は実測で string / boolean / integer / reference の4種でした。値を文字列として持ちつつ、型のヒントを添えています。

フィールド定義は次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

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

個人設定とシステム既定の二層

このテーブルの肝は、同じテーブルに「全員の既定」と「個人の上書き」が同居していることです。見分けるのは user と system の2フィールドです。

PDI 実機の内訳はこうでした。

• system=true・user 空（全ユーザー共通の既定）… 177件。

• system=false・user 付き（個人設定）… 69件。

• そして「user が入っている」レコードはちょうど69件で、個人設定の数と完全に一致しました。

つまり、user が空＝みんなの既定、user 付き＝その人の上書き、ときれいに二層に分かれています。一覧を system でグループ化すると、この二層がそのまま見えます。

同じ name で「既定」と「上書き」が効き分く

二層の効き方は、同じ設定名を両側から見ると一目で分かります。先ほどの change_request.db.order（Change 一覧の並び替え列）が、実機では2件存在していました。

• システム既定（system=true / user 空）… value=number（番号順）。

• 個人上書き（system=false / user=System Administrator）… value=sys_updated_on（更新日時順）。

設定が必要になると、ServiceNow はまずそのユーザーの個人設定を探します。あればそれを使い、無ければシステム既定にフォールバックします。だから管理者の画面だけ更新日時順になり、他の人は番号順のまま、という違いが生まれます。

なお、一覧の並び替え列を表す *.db.order 系だけで実機に 84件ありました。一覧を並べ替えるたび、ここに個人設定が積まれていくわけです。

何が溜まるのか：個人の UI 状態

個人設定（system=false）の中身を見ると、その多くが操作の足あと＝ UI 状態でした。ユーザーでグループ化すると、よく触る人ほど設定が多いことも分かります。実機では System Administrator に45件、Problem Coordinator A に5件、ITIL User に3件でした。

代表的なものは次の4系統です。

• 一覧の並び替え列は *.db.order に入ります。

• ナビゲーターのメニュー開閉は menu.<id>.expanded、ピン留めは glide.ui.menu.main.pinned.id です。

• 最後に開いたモジュールは module に残ります。

• 最後に見たダッシュボードは com.snc.pa.ui.preferences_dashboards で、値は JSON です。

「前回の続きから使える」体験は、この個人設定の積み重ねで成り立っています。

sys_properties との違い

名前も name=value 形式も似ているため混同しがちです。sys_properties（システムプロパティ）はインスタンス全体の設定、sys_user_preference はユーザー単位／UI 状態で、役割が違います。実機では sys_properties が 3,557件あり、glide.* の全体的な挙動はこちらに集中しています。一方 user preference は「誰の」「どの画面状態か」を持ちます。設定変更の案内で出てくる glide.〜 の多くは sys_properties 側です。全体の設定はシステムプロパティ sys_properties の記事で詳しく扱っています。

設定の考え方は ServiceNow 公式の User preferences（Zurich） でも説明されています。

まとめ

• ユーザー設定は sys_user_preference の1行＝name=value で保存される。

• user 付き＝個人設定、user 空かつ system=true ＝全ユーザー共通の既定という二層構造。PDI 実機では 総数246件・既定177件・個人69件だった。

• 同じ name（change_request.db.order）が「既定＝number」「管理者だけ sys_updated_on」で共存し、個人設定があればそれが優先される。

• 一覧の並び順・メニュー開閉・最後に開いた画面など、個人の UI 状態がここに自動で溜まる。

• インスタンス全体の設定は sys_properties（実機3,557件）が持ち、役割が違う。

ユーザー設定が分かると、「ユーザーまわりの設定・記録」がひとつにつながって見えてきます。「誰がなぜこの画面を開けるか」を決めるのがユーザー・グループ・ロールです。個人やグループで共有するのが保存フィルタ（sys_filter）です。同じく共有して使うテンプレート（sys_template）も近い位置にあります。操作の記録を追うなら監査と履歴です。