★を1つ押すと1行増える（sys_ui_bookmark）
ServiceNow の画面左に並ぶメニュー、アプリケーションナビゲータには、星のマークがあります。よく開く画面に星を付けておくと、次からワンクリックで戻れる。この「お気に入り」機能を、多くの人が毎日使っています。ただ、その星を付けた瞬間、裏側で何が起きているかは、あまり知られていません。
答えはシンプルです。星ひとつが、sys_ui_bookmark というテーブルの1レコードになります。1行の中に、名前（title）と飛び先（url）が入ります。さらに持ち主（user）と並び順（order）、色（color）も同じ行に収まる。こうして、あなた専用のショートカットが1件のデータとして保存されます。
今回は、この小さなテーブルを PDI の実機で開きます。たった8件のレコードから、「UIの個人化がどうデータになるか」を読み解きます。件数は少ないですが、ユーザーごとの設定がテーブルに落ちる好例として、とても分かりやすい題材です。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-20）。本番環境では設定が異なります。
まずは、実際の星を見てください。ナビゲータ上部の「Favorites（お気に入り）」を開くと、星を付けた画面がリンクで並びます。ここに出ている「Scripts - Background」「ATF Tests」「Properties」などが、これから読む sys_ui_bookmark の1レコードずつです。
お気に入りとは：ナビの星が1行になる
まず全体像から。ナビゲータで画面に星を付けると、ServiceNow は sys_ui_bookmark に1行を追加します。その1行が、あなたの星1つに対応する。星を消せば、その行も消えます。星とレコードは1対1の関係です。
図の流れは単純です。ユーザーが星を押す。テーブルに1レコードができる。そのレコードを読んで、ナビに星が描かれる。この往復が、お気に入りの正体です。だから「お気に入りを増やす」とは、言い換えれば「このテーブルに行を足す」ことに等しい。
星が出る場所も押さえておきます。お気に入りは、ナビゲータ上部の星アイコンを開いたときに一覧で並びます。よく使う画面をここに集めておけば、メニューをたどらずに直接ジャンプできる。フィルタや検索を毎回打ち込む手間が省けるので、日々の操作がぐっと速くなります。
お気に入りは完全に個人ごとのデータです。誰かが付けた星は、その人のナビにしか出ません。同じ画面を10人が星に登録すれば、sys_ui_bookmark には10行が並びます。見た目は同じ星でも、データとしては人ごとに別の行として保存されます。
星はデータ。1つが1行。持ち主は user。飛び先は url。たったこれだけの約束で、個人ごとのショートカットが成り立っています。難しい仕掛けはありません。
1レコードの中身：4つの役割
1レコードには項目がいくつもありますが、役割で束ねると4つに整理できます。「誰の」「どこへ」「並び順」「見た目」。この4つを押さえれば、お気に入りの仕組みはほぼ理解できます。
誰の … user 項目。sys_user への参照で、そのお気に入りの持ち主を指す
どこへ … title と url。title は星に出す名前、url は開く先
並び順 … order 項目。数値が小さいほどナビの上に来る
見た目 … color と icon。星の色とアイコンを決める
この分け方で見ると、後の項目もすっと頭に入ります。たとえば「同じ画面を2人が登録すると、user だけ違う2行になる」と分かる。「並び順を変えたい」なら order をいじればいい、と見当がつく。項目の役割を先に掴んでおくと、実データを読むときに迷いません。
逆に言えば、この4つ以外は補助的な項目です。区切り線にする separator や固定表示の pinned、グループ分けの group などは、使う場面が限られます。まずは4つの役割だけ覚えれば十分で、細かい項目は必要になったときに調べれば足ります。全体像を大づかみにするのが、テーブルを読む近道です。
主要項目を一覧で見る
dict sys_ui_bookmark で項目定義を引くと、主要な列はこうなっていました。
title と url は最大1000文字の文字列で、長いURLも収まります。user は sys_user への参照なので、レコードから持ち主のユーザー情報へたどれる。order は小数（decimal）なので、整数だけでなく 2.5 のような値も置けます。並びの間に1つ差し込みたいとき、小数だと調整が楽です。
色を決める color は、選択肢リストを持たない自由な文字列でした（既定値は normal）。実データでは green や orange など、色名がそのまま入っています。icon はアイコン名を持つ文字列で、既定は icon-view color-green。ほかに、区切り線にする separator や固定表示の pinned、対象UIを新旧で分ける ui_type（all / polaris）といった項目もありました。
項目はまだあります。フライアウト表示の flyout、開き方を変える open_in_form、別ウィンドウ名の window_name など。ただ、OOTBの8件ではどれも使われていませんでした。普段のお気に入りは、ごく一部の項目だけで成り立っている。これが実測から見えてきた素直な姿です。
実機の8件を読む
前置きはここまで。実際の sys_ui_bookmark を一覧で開くと、OOTBのPDIには8件だけ入っていました。件数が少ないぶん、1件ずつ中身をじっくり追えます。
一覧の既定列は Updated / Title / Image / Order / User / URL。この6列を眺めるだけで、「誰が・どの画面を・どの順番で」お気に入りにしているかが読み取れます。8件を表に整理すると、こうなります。
表にすると、傾向がひと目で分かります。Home は全員の共通。残りは管理者の個人色が強い。件数はたった8件ですが、「共通の入り口」と「個人の作業画面」という2種類のお気に入りが、きれいに見て取れます。数が少ないからこそ、パターンが素直に浮かび上がる、いい実例です。
5人にまたがる「Home」
まず目に付くのが、Home の多さです。8件のうち5件が Home（url は home.do）でした。ATF Developer、ITIL User、Problem Coordinator A といったユーザーが、それぞれ自分の Home をお気に入りに持っています。加えて、持ち主のいない Home が1件（2014年更新の古いレコード）ありました。
なぜ Home がこう並ぶのか。多くのユーザーが、最初からトップ画面をお気に入りに持っているためと読めます。持ち主ごとに1行ずつなので、5人ぶんで5件。同じ home.do でも、user が違えば別レコード、という先ほどの原則がそのまま現れています。
この Home の並びは、お気に入りの性質をよく表しています。トップ画面は誰にとっても出発点なので、多くの人が自然と星を付ける。結果として、同じ home.do が人数ぶんの行として増えます。共通してよく使う画面ほど、テーブルの中では重複したように見える、という特徴があります。
System Administrator の3件
残りの3件は、すべて System Administrator のものでした。管理者が普段よく開く画面を、自分のお気に入りに登録している様子が見えます。中身は次の3つでした。
System Definition - Scripts - Background（スクリプトを実行する画面）。
Automated Test Framework (ATF) - Tests（テストの一覧画面）。
Administration - Properties（システムプロパティの設定画面）。
面白いのは、この3件で color がバラけている点です。Scripts は orange、ATF Tests は blue、Properties は yellow。色を変えて、ナビ上で見分けやすくしている、と読めます。order も 3・4・5 と振られていて、並ぶ順番まで管理者が自分で決めていました。
user 項目が「個人化」を担う
8件を通して見えるのは、user 項目がこの仕組みを支えているという事実です。お気に入りが「誰のものか」を決めるのは user 一択で、ここが空でなければ、その人のナビにだけ星が出ます。
実データでも、System Administrator の3件と、各ユーザーの Home が、user の値できれいに分かれていました。ユーザーを軸に並べ替えれば、「この人は何をお気に入りにしているか」が一望できる。運用でユーザーごとの使い方を調べたいとき、この user 列が手がかりになります。
この「1人1セット」という作りには、実務上の利点もあります。誰かがお気に入りを増やしても、他の人のナビには一切影響しません。管理者が大量の星を並べても、一般ユーザーの画面はすっきりしたまま。個人化のデータが人ごとに独立しているから、他人の設定に振り回されずに済みます。
セキュリティの面から見ても、この分離は理にかなっています。お気に入りは、あくまで画面へのリンクにすぎません。星があるからといって、その画面を開ける権限まで付くわけではない。実際に開けるかどうかは、別途アクセス制御（ACL）が判断する仕組みです。だから、お気に入りを他人にコピーして配っても、権限のないユーザーには中身が見えません。星はリンク、権限は別。この切り分けを知っておくと、配布のときも落ち着いて対応できます。
1件だけ、user が空のレコードがありました。これは特定の誰かのものではなく、全体向けの既定として置かれた古いレコードだと読めます。新しく入ったユーザーに共通のお気に入りを配りたいときは、auto_add という項目を使う手もある。実際、コミュニティでも「auto_add で新規ユーザーに自動で付く」と紹介されていました。
order と color：並び順と見た目
お気に入りは、並び順と見た目も1レコードの中に持っています。並びを決めるのが order、見た目を決めるのが color と icon です。
order は数値で、小さいほどナビの上に来ます。実データの System Administrator は 3・4・5、各ユーザーの Home は 0。この数値を書き換えれば、ナビ内の星の順番が変わる。小数を許すので、3 と 4 の間に 3.5 を差し込むような細かい調整もできます。
color は星の色を表す文字列でした。実データにも green・orange・blue・yellow と複数の色が入っています。選択肢が固定されていない自由文字列なので、値そのものは柔軟です。ただし、どの文字列が画面上でどの色になるかは、今回の実測では追っていません。値が存在することと、管理者が色を使い分けていた事実までを確認しました。
並び順と色を1レコードに持たせている点は、地味に効いています。ナビの星は、ただのリンク集ではありません。どの順番で、どんな色で見せるかまで、持ち主が自分好みに整えられる。この細かな作り込みが、毎日の使い勝手に効いています。
url には何が入るか
url 項目には、思ったより幅があります。単純なものは home.do のような短いパス。一方で、条件付きのリスト画面を登録すると、かなり長いURLが入ります。
たとえば ATF Tests のお気に入りには、sys_atf_test_list.do?sysparm_query=... という形が入っていました。絞り込み条件（クエリ）まで、丸ごと url に収まっています。Properties のお気に入りも同様で、system_properties_ui.do?sysparm_title=... と、開くべきプロパティ画面のパラメータを抱えていました。つまりお気に入りは、単なる画面へのリンクにとどまりません。「この条件で絞り込んだ状態」ごと保存できる、という点が便利です。
url が最大1000文字まで許されているのは、こうした長いクエリ付きURLを収めるためだと分かります。よく使う検索条件を星にしておけば、次からは1クリックでその絞り込み結果へ飛べる。これがお気に入りの、地味だけれど効く使い方です。
この仕組みは、リスト画面の絞り込みと相性がいいです。たとえば「自分の担当ぶんだけ」「今日更新されたぶんだけ」といった条件付きの一覧を、そのまま星にできる。次に開くときは、条件が効いた状態でいきなり表示されます。毎回フィルタを組み直す必要がないので、定型の確認作業がとても楽になります。
ひとつ注意もあります。url は絞り込み条件を丸ごと抱えるので、画面の構造が大きく変わると、古いお気に入りが空振りする場合があります。メニューの再編やモジュールの入れ替えがあった後は、少し気にかけておくと安心です。とはいえ、そう頻繁には起きません。多くの星は長く使えます。困ったら、開いて確かめる。それで十分です。
なぜテーブルに保存するのか
お気に入りのような「見た目の設定」を、わざわざテーブルに保存するのはなぜか。ブラウザのブックマークのように、手元の端末に持たせる手もあったはずです。
理由は、ServiceNow が「どの端末からでも同じ環境」を目指しているからだと考えられます。設定をサーバ側のテーブルに置けば、会社のPCでも自宅のPCでも、同じ星が並びます。端末を乗り換えても、お気に入りは消えません。個人化をデータとして持つことで、環境の持ち運びが自然にできる、という設計です。
仕組み自体はシンプルです。設定はサーバにある。端末は関係ない。だから、どこから入っても同じ星が並びます。この当たり前に見える動きを、テーブルへの保存という設計が支えています。
この考え方は、ServiceNow の他の個人設定にも通じています。並び順も、開いていたメニューも、最後に見た画面も、すべてサーバ側に記録される。だからこそ、ログインすればどこでも「いつもの画面」が再現されます。お気に入りは、その大きな仕組みの、分かりやすい入り口の1つです。
関連する仕組み：ユーザー設定との対比
UIの個人化を担うテーブルは、sys_ui_bookmark だけではありません。近い役割のものに、ユーザー設定を保存する sys_user_preference があります。両者を並べると、役割の違いがはっきりします。
sys_ui_bookmark は「星というショートカット」を保存する場所です。一方 sys_user_preference は、もっと細かいUIの状態を覚えておく場所になります。一覧の並び順や、開いていたメニューの状態、最後に見た画面などが、その対象です。前者は明示的に星を付けた操作の結果、後者は普段の操作で自動的にたまる記録、という違いがあります。
この対比を押さえると、「個人ごとのUI」がどこに保存されるかが整理できます。目に見えるショートカットは sys_ui_bookmark、裏で覚えている細かな状態は sys_user_preference。二層構造そのものは、ユーザー設定の二層構造（別記事）で詳しく扱っています。
お気に入りを扱うときの実務メモ
最後に、実務で sys_ui_bookmark に触れるときの勘どころを、いくつか挙げておきます。
まず、お気に入りは個人データだという意識が欠かせません。あるユーザーの星を消したいなら、user でそのユーザーに絞ってからレコードを操作します。全体を無条件でいじると、他人のお気に入りまで消しかねない。次に、共通のお気に入りを配るなら、auto_add や、スクリプトで user を差し替えたレコードを一括作成する方法があります。コミュニティでも、この種の配布手法がよく共有されていました。
もう1つ、インスタンスをクローンすると、お気に入りが引き継がれずに消えることがあります。移行や検証環境の作り直しの前に、sys_ui_bookmark をエクスポートしておくと安心です。小さなテーブルですが、日々の使い勝手に直結するので、消える前に控えておく価値があります。
お気に入りは、ユーザー教育の場でも役立ちます。新しく入った人に「まずこの画面を星に入れておくと楽ですよ」と伝えるだけで、日々の操作がずいぶん変わる。小さな機能ですが、慣れの差を縮める効果は大きい。仕組みを知っておくと、こうした案内も自信を持って渡せます。
その他、実機で確認した記録
用語
お気に入り（ブックマーク） … ナビの星。実体は sys_ui_bookmark の1レコード。
user … お気に入りの持ち主（sys_user 参照）。個人化の要。
order … ナビ内の並び順。数値が小さいほど上（小数可）。
color / icon … 星の色とアイコン。color は自由文字列で既定 normal。
auto_add … 新規ユーザーに自動で付けるための項目。
調べるときの入口URL（先頭に自分のインスタンスを付ける）
/sys_ui_bookmark_list.do（お気に入りの一覧）。
/sys_ui_bookmark_list.do?sysparm_query=ORDERBYuser（持ち主ごとに並べる）。
/sys_ui_bookmark_group_list.do（お気に入りのグループ）。
実測の要点（再掲）
全8件。うち Home が5件、System Administrator の個人お気に入りが3件。
1レコード = 1つの星。title / url / user / order / color を1行に持つ。
color は選択肢なしの自由文字列（実データは green / orange / blue / yellow）。
url にはクエリ付きの長いパスも入る（最大1000文字）。
検証範囲とおことわり
件数・項目・実データは PDI（Zurich / OOTB）の実測です。
星をクリックしてレコードが増える様子や、ナビへの反映はクリック追跡の範囲外です。
color の文字列が画面上でどの色になるか（パレット）は今回の実測範囲外です。
group / module / flyout などは定義のみ確認し、OOTBの8件では未使用でした。
本番環境では件数も登録内容も大きく異なります。
参考リンク
How do you push a Bookmark / Favorite to all users（ServiceNow Community）
ServiceNow 画面・フォーム完全ガイド：どこを直せば見た目が変わるのか — お気に入り以外の画面要素（フォームや一覧）をどこで直すかをまとめた記事です
