ServiceNowのNow Assist AdminやApp Managerは何で作られている？ sys_ux_page_registryを実機で確認する
Now Assist AdminやApplication Managerを開くたびに、以前とは雰囲気の違う新しい画面になっていると感じたことはないでしょうか。ServiceNowの管理画面は近年、共通の見た目を持つ画面へと入れ替わってきています。これらの画面はすべて sys_ux_page_registry という1つのテーブルにURLパスとして登録されており、UI Builderで自作する画面も同じ入口を通ります。このテーブルを実機で開き、131件の中身を分類し、関連テーブルとの結びつきまで確認しました。
検証環境：Zurich PDI / OOTB / 2026-08-09 確認
結論：新しい管理画面は1つの入口テーブルに集まっている
新しい管理画面・ワークスペース・ビルダー系ツールのURLは、すべて sys_ux_page_registry という1つのテーブルに登録されています。件数は131件（active=true 128件、active=false 3件）でした
内訳を機械的に分類すると、画面や部品を作るための「Builder・Studio系」が39件と最も多く、全体の3割を占めます。管理系コンソールやダッシュボードより、作るための道具のほうが数が多いという結果でした
1件のpage_registryレコードは、admin_panel 経由で sys_ux_app_config（アプリの実体）とつながり、そこから sys_ux_app_route（画面内の個々の操作・遷移、全体1,768件）へと枝分かれします。ただしpage_registryとapp_routeの間に直接の参照列は無く、app_configを介した間接的な橋渡しでした
Now Assist Adminを開くと、案内ダイアログ付きのモダンな管理コンソールが表示されます。Application Managerも同じ系統の見た目です。偶然ではありません。この2つの画面がどちらも同じsys_ux_page_registryという物理テーブルの1行として登録されている、というのが今回の出発点です。
131件はsys_ux_page_registryという1つのテーブルに集まっている
sys_ux_page_registryの項目は、実機のdictionary確認では次のようになっていました。
title・path（URLパス本体、必須項目）
active（既定値true）
admin_panel（document_id＝多態参照。どのテーブルを指すかはadmin_panel_tableで分かる）
parent_app（参照先はsys_ux_app）
root_macroponent（column_labelは「App Shell UI」、参照先はsys_ux_macroponent）
page（参照先はsys_ux_page）
つまりこのテーブルは、画面そのものの中身を持つのではなく「このURLパスを開いたら、どのアプリ・どの外枠で描画するか」を示す入口の役割です。一覧画面を見ると、それぞれの行にURL path・Page・App Shell UI・Admin panel・Parent Appの列が並び、131件のレコードが登録されていることが分かります。
active=falseは3件だけで、127件は今も使われている計算です。個別に見ていくと、Agent Workspace（workspace/agent）がactive=falseになっていました。Service Operations Workspaceへの移行にともない、旧世代のワークスペースが無効化されたと考えられます。
131件を分類すると、3割がビルダー系だった
131件のtitleをキーワードで機械的に分類すると、次のような内訳になりました。この分類軸はServiceNow公式のものではありません。今回の記事のために筆者が独自に付けた区分です。
最も多いのは「Builder・Studio系」の39件で、全体の3割にあたります。UI Builder・Mobile App Builder・Role Builder・Workflow Studioなどが並びます。ほかにもCatalog Builder・Table Builder・Notification Builderなど、画面や設定そのものを作るためのツールが、ひとまとまりで登録されていました。管理コンソール（Admin・Config系12件）やダッシュボード（Dashboard・Analytics系14件）よりも、作るための道具のほうが数のうえでは多いという結果です。
「Workspace系」は7件と、思ったより少数派でした。CMDB Workspace・Request App Workspace・Service Operations Workspaceなど、業務で使う統合作業画面はここに含まれます。ただし131件全体からすればごく一部です。残りの47件は「その他」でした。Application Manager・Knowledge Center・IntegrationHub Designerのような個別ツールが目立ちます。Visual Board Demoのようなデモ画面も混在していました。
Service Portal（sp_portal・sp_page）に相当するレコードがあるかも確認しましたが、titleやpathに「portal」を含むのはPlaybook Experience Portalという別機能の1件だけでした。従来型のService Portalは、今回のsys_ux_page_registryとは別系列で管理されていると考えられます。
1件の管理画面の裏に何件のsys_ux_app_routeがあるか
131件のうち117件はadmin_panel列でsys_ux_app_config（全体で120件、アプリそのものの設定レコード）を参照しています。残り1件はsys_aw_master_config（旧Agent Workspaceの設定テーブル）、13件はadmin_panelが空でした。
ここで気になったのが、sys_ux_app_route（全体1,768件）との関係です。dictionaryを確認すると、sys_ux_app_routeはpage_registryではなくapp_config列でsys_ux_app_configを参照していました。つまりpage_registryとapp_routeは直接つながっていません。app_configを仲立ちにした間接的な橋渡しでした。
実際にNow Assist Adminのレコードを開くと、この構造がそのままフォームに表れていました。
このレコードのadmin_panelが指すUX App Configuration: Now Assist Adminのsys_idでsys_ux_app_routeを絞り込むと、37件がヒットしました。
同じ手順で他のアプリも確認すると、紐づく件数はアプリごとにかなり違いました。
Now Assist AdminやPlatform Analyticsのように画面の中に複数のタブ・パネル・操作を持つアプリは、30件を超えるapp_routeを抱えていました。一方でRole Builderのようにシンプルな画面は1件だけです。app_routeの件数は、その画面がどれだけ細かく機能分割されているかの目安になりそうです。
sys_ux_app_route全体1,768件のうち、app_configが設定されているのは1,613件で、残り155件は空でした。空の155件がどう使われるかは今回未確認です。
似ているが紛らわしいテーブル：sys_ux_page・sys_ux_appとの違い
sys_ux_page_registryのdictionaryにはpageという列もあり、参照先はsys_ux_pageです。名前がよく似ているため最初は同じものかと思いましたが、実際には規模も役割も別でした。page列を持つレコードはpage_registry全131件中22件だけで、参照先のsys_ux_page自体も全体21件という小さなテーブルです。今回の記事の主役であるsys_ux_app_config（120件）・sys_ux_app_route（1,768件）に比べると、桁が1〜2つ小さい脇役の関係だと分かります。
もう1つ紛らわしいのがparent_app（参照先sys_ux_app）です。こちらはpage_registryの66件が「Unified Navigation app shell」という単一の親アプリに属しており、個々のワークスペース名を持つsys_ux_app_configとは別の、もう一段上の括りでした。似た名前のテーブルが複数階層に渡って存在するため、フィールド名だけで判断せず、参照先テーブルまで確認したほうが安全です。
App Shell（root_macroponent）という共通の外枠
root_macroponent（App Shell UI）の分布を見ると、53件がUXR Base Experience Shellという同じ外枠を使っていました。次に多いのがWorkspace App Shell（21件）、ACE Unified Nav App Shell（17件）です。個別の専用シェルを持つのは131件中18件ほどで、大半は数種類の共通シェルを使い回している計算になります。
この結果から見えてくるのは、ServiceNowの新しい画面が「画面ごとに枠から作る」のではなく「共通の外枠に、中身だけを差し込む」という組み立て方をしているという構造です。従来のフォーム（sys_ui_form）が1テーブルにつき1レコードで完結していたのに比べると、外枠と中身を分けて使い回す発想の違いが分かります。
従来のフォーム・リスト・Service Portalとどう違うのか
以前、Service Operations Workspaceをsys_ux_app_configからsys_ux_macroponentまで追った記事では、従来UIのsys_ui_form系列とワークスペースのsys_ux_*系列が別のテーブル系列であることを確認しました。今回のsys_ux_page_registryは、そのワークスペースを含めた「Next Experience全体のURL入口」にあたる、もう一段上の階層です。
従来のフォームやリスト画面（.doで終わるURL）は、テーブルのレコード1件ごとにsys_ui_formが組み立てます。Service Portal（sp_portal・sp_page）は、利用者向けのポータル画面を別のレンダリングエンジンで組み立てる、また別の系列です。今回確認した範囲では、Service Portalに相当するレコードはsys_ux_page_registryには出てきませんでした。新しい管理画面・ワークスペース・ビルダー系ツールは、この3系統とは別に、sys_ux_page_registryを共通の入口にしていると整理できます。
実務での使い方：自分でUI Builderの画面を作るとどこに登録されるのか
自分でUI Builderの画面（Experience）を作った場合、その画面もsys_ux_page_registryに1行として登録されます。実際にUI Builderを開くと、Experience・Page collection・Controller・Presetという4種類の作成メニューが並んでいました。
ここで作った1つの「Experience」が、sys_ux_page_registryの1レコード（title・path・admin_panel・root_macroponent）に対応する構造です。先ほどのNow Assist Adminのフォーム画面にも「Open in UI Builder」というボタンがありました。管理者はレジストリのレコードから直接UI Builder側の編集画面へ飛べるようになっています。
Application Managerのように既存のOOTBアプリも同じ仕組みに乗っています。
つまり「新しい見た目の管理画面をどう作るか」という問いへの実務的な答えは、UI Builderでpage_registryに1行を追加する、という一点に集約されます。独自の管理画面を作りたい場合、フォームやポータルを個別に組むのではなく、UI Builderでexperienceを作成します。必要であればsys_ux_app_configで管理パネルも持たせる、という手順です。
実機で気づいたこと
同じ「UI Builder」というタイトルが、pathの違う2つのレコードとして登録されていた点が意外でした。build/ui（admin_panel空・root_macroponent空）とbuilder/ui（admin_panelがUI Builder App Configを参照・app_route18件）です。titleが同じでも、中身は別レコードです。新旧のパス体系が並存しているように見えます。どちらが現行の正規パスかは今回の検証範囲では判断できませんでした。
もう一つ発見だったのが、admin_panelが空の13件の顔ぶれです。UI Builder・Mobile App Builder・Mobile Card Builderの各種派生・Component Builder・Flow関連などです。ほぼすべてがビルダーツールそのものでした。ビルダーは自分自身が管理対象になる別アプリを持ちません。そのためadmin_panelという橋渡しの列を使わない構造なのだと考えられます。管理画面には管理対象があります。一方でビルダーには管理対象がなく、それ自体が道具です。この違いが、列の空欄という形で表れていました。
sys_ux_page_registryとsys_ux_app_routeが直接つながっていなかった点も、事前の予想とは違います。同じ「UX」の名を持つ以上、直接参照だと思い込んでいました。実際にはsys_ux_app_configを介した間接の橋渡しです。dictionaryで参照列を確認するまで気づけない構造でした。
Now Assist Adminのフォームには「UX Page Properties」という関連リストが5件ぶら下がっていました。chrome_header・chrome_footer・side_nav_page_reloadのような、画面のヘッダーやフッターの見た目に関わる設定値を持つ様子でした。ここは踏み込んでいません。
実務でつまずきやすい点
新しく作った管理画面がどこにも見当たらないときは、まずsys_ux_page_registryをpath列で検索します。Experienceの作成自体は成功していても、URLパスの綴りやactiveフラグの見落としで開けないケースが考えられます
「このアプリのapp_routeが何件あるか知りたい」という場合、page_registryのadmin_panel列からapp_configのsys_idを取得してから絞り込む必要があります。page_registry側から直接app_routeを検索条件にすることはできません
同じタイトルの画面が2つ登録されている可能性があるため、pathも合わせて確認したほうが安全です。今回のUI Builderのように、新旧のレコードが両方activeなまま残っている場合があります
admin_panelが空だからといって設定不備とは限りません。ビルダー系ツールのように、仕組みとして管理パネルを持たない画面もあります
よくある質問
Q1. sys_ux_page_registryに登録すれば、どんな画面でも同じ見た目になりますか
見た目そのものを決めるのはroot_macroponentが指すApp Shellと、その中の部品ツリーです。page_registryへの登録は入口の作成にあたり、見た目を揃えるかどうかはどのApp Shellや部品を選ぶか次第になります。同じUXR Base Experience Shellを選べば、雰囲気は近くなります。
Q2. Application Managerのように既存のOOTB画面も、自分でUI Builderから編集できますか
Now Assist Adminのフォームには「Open in UI Builder」ボタンがあり、レジストリのレコードからUI Builder側の編集画面へ遷移できる作りになっていました。ただしOOTBアプリの中身を実際に編集し保存する検証は、今回は行っていません。
Q3. 従来のワークスペース記事（sys_ux_app_config起点）と何が違いますか
以前の記事はService Operations Workspace 1本をsys_ux_app_configからsys_ux_macroponentまで、順を追って確認したものです。今回はその手前にある入口テーブルsys_ux_page_registryを起点に、131件全体を横断して分類しました。個別のワークスペースの中身より、Next Experience全体にどれだけの画面が登録されているかを俯瞰する内容です。
Q4. 131件やapp_routeの件数は、自分のインスタンスでも同じ数字になりますか
なりません。インストール済みプラグインやカスタマイズによって件数は変わります。今回の数字はZurichのOOTB PDIで確認したものです。構造（page_registry→app_config→app_routeという間接の橋渡し）は共通ですが、件数はご自身の環境で確認するのが確実です。
まとめ
Now Assist AdminやApplication Managerのような新しい管理画面は、sys_ux_page_registryという131件のテーブルにURLパスとして登録されていました。分類すると3割がビルダー・スタジオ系で、画面を作るための道具そのものが最大勢力です。1件のレジストリレコードはadmin_panel経由でsys_ux_app_configとつながり、そこからsys_ux_app_route（画面内の操作単位、全体1,768件）へと間接的に枝分かれし、あわせてroot_macroponentという共通の外枠を複数の画面で使い回す構成も確認できました。自分で新しい画面を作りたい場合は、UI Builderでexperienceを作ることが、このテーブルに行を追加することと同じ意味になります。従来のフォーム・リスト・Service Portalとは別の、Next Experience全体の入口として、このテーブルを覚えておくと管理画面の見え方が変わってきます。
用語
sys_ux_page_registry … URLパスと、そのパスが開くアプリ・外枠を結び付ける入口テーブル（131件）
sys_ux_app_config … アプリ（ワークスペース・管理コンソール・ビルダー等）そのものの実体（全体120件）
sys_ux_app_route … 1つのアプリの中にある個々の画面内操作・遷移の単位（全体1,768件）
root_macroponent（App Shell UI） … 画面の共通の外枠となる部品ツリーの定義
admin_panel … page_registryが管理パネル（多くはsys_ux_app_config）を指す多態参照列
自分の環境で確認するときのURL
/sys_ux_page_registry_list.do … page_registry一覧（131件）
/sys_ux_page_registry.do?sysparm_query=admin_panelISEMPTY … admin_panelが空のレコードだけを絞り込む
/sys_ux_app_route_list.do?sysparm_query=app_config=<sys_ux_app_configのsys_id> … 特定アプリのapp_route一覧
/sys_ux_app_config_list.do … sys_ux_app_config一覧（120件）
参考リンク
関連記事
検証環境と未検証範囲
件数はZurich PDI（OOTB）で確認したものです。分類の7区分は筆者がtitleのキーワードから機械的に付けたもので、ServiceNow公式の分類ではありません。
未検証の範囲もあります。sys_ux_app_routeのうちapp_configが空の155件がどう使われるかは確認していません。page列（22件が設定、参照先のsys_ux_pageは全体21件）の詳しい役割は未展開です。sys_ux_macroponentのcomposition/layoutJSON列の中身、Now Assist Adminフォームに表示された「UX Page Properties」関連リストの詳細構造も、今回は展開していません。UI Builderで新しいExperienceを実際に作成し、sys_ux_page_registryへの登録を書き込みで検証する作業は、PDIへの書き込みを伴うため今回は行っていません。本番環境やカスタマイズ済みの環境では件数や分類の内訳が変わりますが、共通の入口テーブルに画面が集約されるという構造そのものは変わらないと考えられます。
