ServiceNowのフォーム下の関連リストはどこで決まる？ 一覧の列とは別のテーブルを実機で確認
一覧の列ヘッダで Configure > List Layout を開いて並びを直しても、フォーム下部の関連リストは変わりません。関連リストは、Child Incidents や Affected CIs のような、レコードを1件開いたときに出る別テーブルの一覧です。逆に、関連リストの並びを直したくて開いた画面が、実は列の設定画面だったという勘違いも起こります。どちらも「リストの設定」に見えますが、保存先のテーブルは別です。一覧の列は sys_ui_list と sys_ui_list_element、フォーム下部の関連リストは sys_ui_related_list が持ちます。Zurich PDI の incident で、実際の件数と中身を確認しました。
検証環境：Zurich PDI / OOTB / 2026-08-08 確認
結論：列と関連リストは別のテーブルに分かれる
先に全体像です。
一覧の列の並びは、sys_ui_list（テーブル×ビュー）と sys_ui_list_element（1列ずつ）の2テーブルに保存されます。フォーム下部の関連リストは、別系統の sys_ui_related_list が持ちます。
incidentで確認すると、列のレイアウトはビュー別に22件、Default viewの列は11、全ビュー合計の列は181でした。関連リストは6件で、並びを上書きしたレコードは0件です。
関連リストの並びを保持する related_list という項目は、確認した1,540件すべてで空でした。フォーム下部の関連リストは、リレーションシップや参照フィールドから自動で組み立てられていると読めます。
まず全体を図で見ます。
図の色は仕組みの系統を表します。濃紺はフォームを開いた起点、緑は列構成、紫は関連リストです。どちらもビュー（水色）を参照しますが、保存先のテーブルは分かれています。
総件数はPDI全体の規模で、incidentだけの数字ではありません。1つのテーブルに絞ったときの数は、この後の節で扱います。
なぜここまで区別するかというと、列と関連リストを混同したまま設定を直しても、変えたはずの画面が変わらず、原因調査に時間を取られるからです。テーブルの分かれ目を先に押さえておくと、この手戻りを避けられます。
一覧の「列」はどこに保存される？（sys_ui_list ＋ sys_ui_list_element）
レコードを1件も開かず、一覧画面だけを見ているときに触っているのがこちら側です。列ヘッダの Configure > List Layout で列を足したり並べ替えたりすると、その結果は画面ではなくテーブルのレコードとして保存されます。変わっているのは、裏側のデータベースです。
sys_ui_list は「テーブル×ビュー」を1件で表す
sys_ui_list（List）の1レコードは、あるテーブルを・あるビューで見たときの列構成をまとめて表します。主なフィールドは、対象テーブルを示す name と、どのビューかを示す view（sys_ui_view を参照）です。ほかに、親テーブル名を持つ parent、定義済みリレーションシップを指す relationship もあります。incidentに絞ると22件あり、Default view・Workspace・Major incidentsなど、ビューごとに1件ずつ存在します。viewフィールドが空のレコードは、Default viewを表す扱いでした。名前の付いた専用ビューだけがviewに値を持ち、既定のビューだけは空のままという状態です。地味な仕様です。
sys_ui_list_element がリストの1列を持つ
1つの列は sys_ui_list_element（List Element）の1レコードです。list_id で親の sys_ui_list を参照し、element に表示するフィールド名、position に並び順を持ちます。incidentのDefault viewは、上のスクリーンショットに写っている11列でした。全ビューの列を合計すると181です。列の並び順を1つずつ変えたいときは、この sys_ui_list_element の position を書き換えることになります。
sys_user が入っていれば、それは個人用のリスト
sys_ui_list には sys_user という参照フィールドもあります。列ヘッダの並びを自分だけ変えると、その人専用の sys_ui_list レコードが新しく作られる仕組みです。全体では sys_user がセットされたレコードが10件あり、これは誰かが個人的に列をカスタマイズした跡です。incidentに絞ると0件でした。今回のPDIでは、誰もincidentの列を個人用に変えていないことになります。「同じテーブルなのに自分だけ列の並びが違う」という相談を受けたときは、まずこのsys_user付きレコードの有無を確認すると早いです。
sys_ui_list と sys_ui_related_list は sys_metadata（Application File）を継承する設定メタデータです。sys_ui_list_element は super_class が空のルート基底テーブルで、フォーム側の項目配置を持つ sys_ui_element と同じ構図でした。
公式の Configure the list layout（Zurich） に、列の追加・削除・並べ替えの手順が説明されています。
列の並びを変更すると、その差分はsys_ui_listやsys_ui_list_elementのレコードとして残ります。管理者が直した列は、他の設定と同じようにUpdate Setで運用環境へ移送できる対象です。個人が並べ替えた分（sys_user付き）まで一緒に運用環境へ持っていくかどうかは、移送のたびに確認しておく価値があります。
フォーム下部の「関連リスト」はどこで決まる？（sys_ui_related_list）
ここからはフォームの中の話です。レコードを1件開いてフォームの下までスクロールすると、Child IncidentsやAffected CIsのような、別テーブルのレコード一覧が並びます。これが関連リストで、列構成とは別系統のsys_ui_related_listが担います。
sys_ui_related_list（Related List）が持つ主なフィールドは、対象テーブルを示すnameと、ビューを示すviewです。関連リストの並びを保持するrelated_listという文字列フィールドもあります。incidentに絞ると6件でした。内訳は次のビューで、1ビューにつき1件ずつです。
Default view
Major incidents
Metrics
Service Operations Workspace
SOW-Incident-Overview
Workspace
calculated_nameという項目もあり、こちらは「Incident - Default view」のように、テーブル名とビュー名を組み合わせた表示名が自動で入ります。並び順を指定するorder_byや、絞り込み条件を指定するfilterも持ちますが、incidentの6件ではどちらも空でした。related_listだけでなく、この2項目も未設定のままだったことになります。
related_list 文字列は、今回すべて空だった
確認したかったのはrelated_listの中身です。incidentの6件はすべて空でした。例外はありません。範囲を全テーブルに広げても、sys_ui_related_list全1,540件のうちrelated_listに値が入っているレコードは0件でした。
並びを保持する項目がどのレコードでも空なのに、フォーム下部にはChild Incidentsなどの関連リストが実際に表示されます。少なくとも今回のPDIでは、関連リストの並びはレコードに明示保存されていません。リレーションシップや参照フィールド、データベースビューから都度組み立てられていると読めます。sys_ui_related_listのレコードは、Configure > Related Listsで人が並びを変えたときに、その内容が書き込まれる場所として用意されているようです。
公式の List configuration（Zurich） に、リストと関連リストの構成の考え方がまとまっています。
関連リストの並びをConfigureで上書きすると、そのsys_ui_related_listレコードにrelated_list文字列が書き込まれます。OOTBのまま自動導出に任せている限り、このテーブルにはほとんど変更履歴が残らないことになります。
埋め込みの関連リストは、列だけ sys_ui_list 側に戻ってくる
ここでもう1つ、実機を見て気づいたことがあります。関連リストの並び自体はsys_ui_related_listが持ちますが、関連リストの箱の中に表示される列は、sys_ui_list側のレコードが持っていました。
sys_ui_listにはparentというフィールドがあり、親テーブル名をセットすると、そのテーブル配下に埋め込まれる関連リストの列構成を表せます。目立たない項目です。全体では1,681件のsys_ui_listにparentがセットされており、incidentに絞ると36件です。
中身を見ると、task_ci・task_sla・kb_knowledge・sysapproval_approverなどが並びます。フォームで見覚えのある関連リストの名前ばかりです。1つの関連リストにつき、ビューの数だけこのparent付きsys_ui_listが増える計算です。
Affected CIs（task_ci）は2列しか持っていなかった
incidentのフォームに出るAffected CIsという関連リストは、実体がtask_ciテーブルです。parent=incident・name=task_ciのsys_ui_listが1件あり、そのsys_ui_list_elementはci_itemとtaskの2列だけでした。箱の中は最小限でした。関連リストの箱に出す列を変えたいときは、このparent付きのsys_ui_listを探すことになります。sys_ui_related_list側には、列の情報は入っていません。
定義済みのリレーションシップを使う関連リストについては、公式の Create defined related lists（Zurich） に手順があります。
「列」と「関連リスト」、どちらを直すか
答えは単純です。直したい対象によって、開く画面も書き換わるテーブルも変わります。
列を変えるなら List Layout を開く
一覧画面の列ヘッダでConfigure > List Layoutを開きます。実体はsys_ui_listとsys_ui_list_element（テーブル×ビュー＋1列ずつ）です。
関連リストを変えるなら Related Lists を開く
フォームの下部でConfigure > Related Listsを開き、並びをドラッグして直します。実体はsys_ui_related_list（ビュー単位）で、上書きした並びはrelated_list文字列に保存される仕組みです。箱の中に表示される列を変えたいときは、前の節で見たparent付きのsys_ui_listを編集します。
一覧・フォームのどちらも右クリックからConfigureメニューを開けるため、List LayoutとRelated Listsを混同しやすいところです。開いた画面の見出しがどちらになっているかを確認してから操作すると、直したつもりの設定が違うテーブルに書き込まれる事態を避けられます。
incident の実測ひとめ表（実務で見るならここ）
問い合わせや設計の途中で数字を確認したいときは、この表に戻ると早いです。
これはsys_ui_list系とsys_ui_related_listが持つ「定義の件数」です。実際に一覧の何行が見えるか、関連リストに何件出るかは、ACLやドメイン区切り、関連リスト側のフィルタとも合わさって決まります。定義のテーブルだけを見て、表示の全体を判断しないようにしています。
incidentだけが特別というわけではありません。change_requestは23件と5件、problemは11件と4件でした。sc_req_itemは11件と4件、cmdb_ciは8件と2件です（リスト件数と関連リスト件数の順）。傾向は同じです。どのテーブルも、リストの件数が関連リストの件数の2倍以上あります。
現場で「列が変」「関連リストが変」と言われたときは、次の順で見ると迷いません。
一覧画面の話か、レコードを開いた下部の話かを聞き分けます。
一覧の話なら sys_ui_list（対象テーブル×ビュー）から sys_ui_list_element をたどります。
下部の話なら sys_ui_related_list（対象テーブル×ビュー）を確認します。
関連リストの箱の中身を変えたいなら、parent付きの sys_ui_list を追加で探します。
実機で気づいたこと
気づいたことは3つあります。
Default viewの列は11でしたが、ビューごとの列数を並べると差がかなりありました。ess・portalは3列、major_incidentsは10列、sowは20列、workspace向けは35列です。同じincidentというテーブルでも、誰向けの画面かによって列の役割がまったく違うことが数字に出ていました。エージェント向けの画面ほど列を増やし、利用者向けの画面ほど列を絞り込む設計が、そのまま件数として表れています。
incidentの22件のリストのうち、6件はRPTやRptで始まる名前のビュー向けでした。自分で作った覚えのないビューが混ざっていたので最初は戸惑いました。レポートを一覧形式で保存すると、専用のビューと列構成が自動で作られる仕組みではないかと考えています。ここは実際に再現操作をしたわけではないので、推測にとどめます。列の並びを調べるときは、業務で使うビューかどうかを先に見分けたほうが早そうです。
Affected CIsの列がci_itemとtaskの2つだけだったのも意外でした。一覧画面のDefault viewが11列、workspace向けが35列だったのに比べると、関連リストの箱の中はかなり絞られています。関連リストは一覧そのものというより、「このレコードに紐づく相手を最小限の情報で示す窓」として設計されているように見えました。
次に読むなら
ServiceNow 画面・フォーム完全ガイド：どこを直せば見た目が変わるのか — 関連リスト以外の画面要素も含めた、どこを直すかの全体地図です
一覧の列の並びは2テーブルで決まる（sys_ui_list） — 列構成の内部をさらに掘り下げた記事
定義リレーション（sys_relationship）：参照列なしの関連リスト — relationshipフィールドで作る関連リストの実務編
よくある質問
Q1. 列を直したのに、フォーム下部の関連リストの並びが変わりません
Configure > List Layout で直せるのは一覧の列（sys_ui_list側）だけです。フォーム下部の関連リストを直すには、フォームを開いて Configure > Related Lists を別に操作します。別画面です。列と関連リストは保存先のテーブルが違うため、片方を直してももう片方には影響しません。一覧画面とフォーム画面のどちらで作業しているかを、まず確認します。
Q2. 関連リストの箱の中に出る列を変えたいときはどこを見ますか
探す先は sys_ui_related_list ではありません。parentに親テーブル名がセットされたsys_ui_listを見ます。Affected CIsのように、関連リストの箱の中の列は、埋め込み用のsys_ui_listレコードが持っています。
Q3. 同じテーブルなのに、人によって列の並びが違うのはなぜですか
個人が列を並べ替えると、その人専用のsys_ui_listレコードが作られます。sys_userフィールドに担当者が入っているレコードがそれで、全体では10件ありました。少数派です。管理者が直した列と食い違って見えるときは、まずこの個人用レコードの有無を疑います。
Q4. calculated_nameやorder_by、filterは何に使うのですか
calculated_nameは、関連リストの表示名として使われる項目で、通常は「テーブル名 - ビュー名」の形で自動生成されます。order_byは並び順、filterは絞り込み条件を指定する項目です。incidentの6件では、どちらも空欄でした。値を入れれば、関連リストの並び順や表示範囲を個別に上書きできます。
用語
sys_ui_list … リストの列構成（テーブル×ビュー）を1件で表すレコード
sys_ui_list_element … リストの1列の配置（list_idで親を参照）
sys_ui_related_list … フォーム下部の関連リストの並び（ビュー単位）
sys_ui_view … フォーム／リストの表示パターンを定義するテーブル
sys_relationship … 定義済みリレーションシップ（参照フィールドを使わない関連の定義）
実機で調べるときに開いたURL
/sys_ui_list_list.do?sysparm_query=name=incident^ORDERBYview
/sys_ui_list_element_list.do?sysparm_query=list_id.name=incident^ORDERBYposition
/sys_ui_related_list_list.do?sysparm_query=name=incident^ORDERBYview
/sys_db_object_list.do?sysparm_query=name=sys_ui_list^ORname=sys_ui_list_element^ORname=sys_ui_related_list
参考リンク
検証環境と未検証範囲
件数はZurich PDI（OOTB）で確認したものです。一覧画面の件数表示と実レコードを突き合わせて数えており、推定やサンプリングではありません。個人用のsys_ui_list（sys_user付き）や、レポートから自動生成されたとみられるRPT系のビューも件数に含めています。本番環境やカスタマイズ済みの環境では、ビュー・列・関連リストの構成や件数が異なります。
確認していない範囲は次のとおりです。
related_list文字列を人が上書きしたときの保存フォーマットの詳細
関連リストが自動導出される内部ロジック
List Control（sys_ui_list_control）の挙動
Configurable Workspaceのリスト定義方式
List v2/v3の描画差
roleによる列の出し分けの実挙動
