一覧の列の並びは2テーブルで決まる（sys_ui_list）

2026年6月29日 23:26

ServiceNow で Incident の一覧を開くと、列が横に並びます。列には Number・Opened・Short description・Caller・Priority・State などが並び、この並びそのものは画面ではなくテーブルのレコードとして保存されています。レコードを開いたときの縦の項目配置（フォーム構成）とちょうど対になる仕組みです。

この記事は、ServiceNow の Incident は触ったことがあるが、一覧の列の並びがどのテーブルにどう保存されているのかをこれから把握したい管理者・開発者を想定しています。列ヘッダで「Configure > List Layout」を変えた内容が裏で何のレコードになるのかを、PDI（Zurich）の OOTB で確認した実測値とともに並べます。あわせて、フォーム構成の記事で見た「縦の項目」も引き合いに出します。本記事の「横の列」が、同じビューの下でどう対応するかを対比します。

この記事で分かること

一覧の列の並びが画面ではなく sys_ui_list ＋ sys_ui_list_element の2テーブルのレコードとして保存されること
「リスト＝テーブル × ビュー（×ユーザー）」で、incident には今回の PDI で21ビューぶんのリスト列構成があること
incident の Default view のリストは 11 列で、それが実際の一覧画面の列と一致すること
リストは sys_user で個人別に持てて、今回の PDI では 10 件の個人用リストがあったこと
フォーム構成（4テーブル）に対し、リストは2テーブルの素直な親子だという対比
列を1本足すと sys_ui_list_element がどう増えるか、実機で確認するときに見るべきURL

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、ビュー・列・件数の内容が異なる場合があります。

リスト列レイアウトとは

リスト列レイアウトとは、あるテーブルをあるビューで一覧表示したときに、どのフィールドを・どの順で列に出すかを定義する仕組みです。一覧の列ヘッダを右クリックして「Configure > List Layout」を開き、列を足したり並べ替えたりすると、その結果がテーブルのレコードとして保存されます。

中心になるのは sys_ui_list（画面ラベルは List）です。1つの sys_ui_list レコードが「どのテーブルの・どのビューの・誰のリストか」を表し、そこに列が1本ずつ紐づきます。

実際の Incident 一覧を見ると、Number から Updated by まで列が横に並んでいます。この列の並びを、以降で扱う2テーブルの組み合わせが作ります。

リスト列レイアウトの2テーブルと構造

リストの列構成に関係するテーブルは、sys_ui_list（親）と sys_ui_list_element（1列ずつ）の2つだけです。フォーム構成が4テーブルに分かれていたのに比べると、ずっと素直な親子構造です。

今回確認した PDI（Zurich / OOTB）では、それぞれ次の役割でした。

sys_ui_list（List） … 「どのテーブルの・どのビューの・誰のリスト（列構成）か」を表す。name（対象テーブル）と view（→ sys_ui_view）に加え、sys_user（個人用リストの所有者）を持ちます。固有フィールドは15。
sys_ui_list_element（List Element） … リストの1列。list_id（→ sys_ui_list）で親のリストを参照し、element（フィールド名）と position（並び順）を持ちます。固有フィールドは13。

継承を見ると、sys_ui_list は Application File（sys_metadata）を継承する設定メタデータで、フォーム側の sys_ui_form と同じ位置づけでした。一方、sys_ui_list_element は super_class が空のルート基底テーブルです。これはフォーム側の sys_ui_element と同じ構図です（親＝設定メタ、子＝ルート基底）。

2テーブルの基本を一覧にすると次のとおりです。総件数は PDI 全体の規模感です。

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

https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=sys_ui_list^ORname=sys_ui_list_element

リスト＝テーブル × ビュー（sys_ui_list）

sys_ui_list の1レコードは「テーブル × ビュー」の組み合わせです。同じ incident テーブルでも、ビューが違えば別のリスト（別の sys_ui_list レコード）になります。これはフォーム構成の sys_ui_form とまったく同じ考え方です。ビューを軸に画面の見せ方が分かれます。

今回確認した PDI（Zurich / OOTB）では、incident の sys_ui_list は 21 件ありました。incident に21ビューぶんのリスト列構成がある、ということです。内訳は次のとおりです。

人が作るビュー：Default view / Major incidents / Mobile / Portal / Self Service / Service Operations Workspace / Workspace
レポート用に自動生成された Rpt… ビュー

参考までに、他テーブルのリスト数は change_request 23 / alm_asset 16 です。cert_audit_result のように332 件ものリスト定義を持つテーブルもありました。

リストの列を直したいときは、まず対象テーブルと対象ビューの組を特定します。Workspace で見えている列と Default view の列は別レコードなので、片方を直してももう片方は変わりません。

リスト一覧は、次のURLで確認できます。

https://<YourInstance>/sys_ui_list_list.do?sysparm_query=name=incident^ORDERBYview

列の追加・削除・並べ替えの操作方法は、公式ドキュメントにまとまっています。

参考: Configure the list layout（Zurich）

リストの中身は1列ずつのレコード（sys_ui_list_element）

リストの「列の並び」を1列ずつ持つのが sys_ui_list_element（List Element） です。所属するリスト（list_id → sys_ui_list）、表示するフィールド名（element）、並び順（position）を持ちます。1つの sys_ui_list に、列の数だけ sys_ui_list_element がぶら下がる1対多の関係です。

各テーブルの主な固有フィールドと参照先を整理すると次のとおりです。

今回確認した PDI（Zurich / OOTB）では、incident の Default view のリストは 11 列でした。position 順に並べると次のとおりで、これは冒頭の一覧画面の列と一致します。

position 0 … number
position 1 … opened_at
position 2 … short_description
position 3 … caller_id
position 4 … priority
position 5 … state
position 6 … category
position 7 … assignment_group
position 8 … assigned_to
position 9 … sys_updated_on
position 10 … sys_updated_by

incident の全ビュー合計のリスト列（sys_ui_list_element）は176件でした。Default view の 11 列はそのうちの一部です。一覧の列の並びは、sys_ui_list_element の position を昇順に並べたものと一致します。列ヘッダで Configure > List Layout を開いて列を左右に動かすと、ここの position が書き換わります。これは、フォーム側で項目配置を sys_ui_element が position 順で持つのと対になっています。

なお sys_ui_list_element は sys_updated_on / sys_mod_count を持つ更新可能な設定レコードです。並べ替えのたびに既存レコードの position が更新され、列を外せばレコードが削除されます。

リストの列（要素）一覧は、次のURLで確認できます。

https://<YourInstance>/sys_ui_list_element_list.do?sysparm_query=list_id.name=incident^ORDERBYposition

列を1本足すとレコードはどう増えるか（設定例）

いま Default view の incident 一覧に、Assigned to の後ろへ「Opened by」列を1本足す場合を考えます。一覧の列ヘッダで Configure > List Layout を開きます。Available の一覧から Opened by を選んで Selected 側へ移し、Assigned to の直後に並べて保存します。

このとき裏では、incident の Default view リスト（sys_id=fae4e36d9f3302000391b89a442e70d7）が更新されます。そこに list_id でぶら下がる sys_ui_list_element が1レコード増えます。element は opened_by、position は Assigned to の 8 と sys_updated_on の 9 のあいだに入る値です。元の列は12列になり、後続の position が1つずつ繰り下がります。Configure > List Layout の操作は、この sys_ui_list_element の追加・削除・position 更新そのものです。設定後に「どこを見れば結果を確認できるか」が、これで決まります。

https://<YourInstance>/sys_ui_list.do?sys_id=fae4e36d9f3302000391b89a442e70d7

リストは個人別に持てる（sys_user）

フォーム構成にはなくて、リストにあるのが sys_user フィールドです。これは「そのリスト列構成が誰のものか」を表します。空なら全員共通（global）、セットされていればその人だけの個人用リストになります。ユーザーが自分の一覧で「Personalize List Columns」から列を変えると、global を上書きする個人用の sys_ui_list レコードが作られます。

今回確認した PDI（Zurich / OOTB）では、sys_ui_list は全4,557 件でした。内訳は sys_user が空（全員共通）＝4,547 件、sys_user がセット（個人用）＝10 件です。この個人用 10 件はすべて System Administrator（admin）の所有でした。change_request や kb_knowledge_base などの一覧を、admin が自分用に並べ替えた跡です。

つまり一覧の見た目がユーザーごとに違って見えるとき、その差は ACL ではなく個人用 sys_ui_list の有無で説明できることがあります。リストを調べるときは「global の定義か、その人の個人用か」を切り分けると迷いません。

個人用リストは、次のURLで一覧できます。

https://<YourInstance>/sys_ui_list_list.do?sysparm_query=sys_userISNOTEMPTY^ORDERBYname

フォーム構成（縦の項目）との対比

ここまでの「横の列」を、フォーム構成の記事で見た「縦の項目」と並べると、両者の設計の違いがはっきりします。

リスト＝横の列：sys_ui_list ＋ sys_ui_list_element の2テーブル。中間もセクションもなく、list_id で直接の親子。1レコード＝1列。編集UIは列ヘッダ > Configure > List Layout。
フォーム＝縦の項目：sys_ui_form → sys_ui_form_section（中間）→ sys_ui_section（セクション）→ sys_ui_element の4テーブル。1レコード＝1項目（.split や formatter などの特殊要素も含む）。編集UIはフォーム ≡ > Configure > Form Layout。

両者が共有するのが sys_ui_view（View）です。同じ Default view というビューの下に、リスト用の sys_ui_list と、フォーム用の sys_ui_form が別々に存在します。だから「一覧の列を直したい」のか「フォームの項目を直したい」のかで、開く画面も書き換わるテーブルもまったく別になります。

incident の実測値で対比すると次のとおりです。

リストは 21 リスト / Default view 11 列 / 全 176 列でした。フォームは 8 フォーム / Default view メイン 22 項目 / 全 355 項目でした。フォーム側の数値はフォーム構成の記事の実測です。列はテーブル×ビュー×ユーザーで2テーブル、項目はテーブル×ビューで4テーブルという非対称を押さえておくと、画面の見え方が変わったときにどちらを調べればよいか切り分けられます。

フィールド定義で確かめる

最後に、sys_ui_list が持つフィールドを実機の辞書（sys_dictionary）で確認します。name（Table）・view・sys_user・parent・relationship のほか、いくつかのフラグも見えます。列フッターの集計に使うのは sum / average_value / max_value / min_value です。今回の PDI では、sum=true の列が全体で27件ありました。

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

なお、parent がセットされた sys_ui_list は PDI 全体で 1,664 件あり、これらはフォーム下部などに関連リストとして埋め込まれるリストの列構成です。関連リスト（sys_ui_related_list）そのものの仕組みは、別記事で詳しく扱っています。本記事は単独の一覧の列構成に集中しました。

詳細: リストレイアウトと関連リストの記事（sys_ui_related_list の見方）

ServiceNow のリスト列レイアウトのポイント

一覧の列の並びは画面ではなく、sys_ui_list（テーブル×ビュー×ユーザー）＋ sys_ui_list_element（1列ずつ）の2テーブルのレコードとして保存されます。
リスト＝テーブル × ビュー。incident は今回の PDI で21ビューぶんのリストがありました。Workspace と Default view は別レコードです。
列の中身は sys_ui_list_element が position 順で持ちます。incident の Default view は11列で、実際の一覧画面の列と一致しました。
リストは sys_user で個人別に持てます。PDI では個人用が 10 件（すべて admin）で、見た目の差は個人用リストの有無で説明できることがあります。
フォーム構成（4テーブル・縦の項目）に対し、リストは2テーブル・横の列です。両者は sys_ui_view を共有しつつ別系統です。
Configure > List Layout の操作は、最終的に sys_ui_list_element の追加・削除・position 更新になります。

リストの列を調べるときは、まず「どのテーブルの・どのビューの・誰のリストか（sys_ui_list）」を決めます。そこから list_id で sys_ui_list_element の position を見れば、一覧の列の並びがそのまま読み解けます。

次に読むなら

検証範囲とおことわり

確認した範囲（すべて PDI（Zurich / 2026-06-29 確認）の OOTB で取得）
sys_ui_list / sys_ui_list_element の階層（Application File／ルート基底）、固有フィールド数（15 / 13）
主要フィールドと参照先、list_id でのつながり（1対多）
テーブル全体規模（4,557 / 23,475）、global／個人別の内訳（4,547 / 10、個人用はすべて admin）
parent 傾向（1,664）、集計フラグ（sum=27）、テーブル別リスト数
incident の Default view リスト列（11列）と全ビュー合計（176）
確認していない範囲（断定しません。別記事で扱います）
Configure > List Layout の保存処理の内部、個人用リスト（sys_user）が global を上書きする優先順位の実挙動
List v2/v3 や Configurable Workspace のリスト描画方式、role による列の出し分け
列フッター集計（sum 等）の表示挙動、関連リスト（sys_ui_related_list）と埋め込みリスト列の詳細
各ラベルの翻訳、本番のカスタム環境

今回は PDI の OOTB（初期設定）を前提に、リスト列レイアウトの構造を確認しました。実環境では、既存のカスタマイズによってビュー・列・件数が変わります。