フォームの並びは4テーブルに保存される（sys_ui_form）

ServiceNow で Incident を開くと、番号や Caller、State といった項目が、いくつかのまとまり（セクション）に分かれて並びます。この「どの項目を・どの順で・どのセクションに置くか」という並びそのものが、テーブルのレコードとして保存されています。画面を見ているだけでは気づきにくい部分です。

フォームをデザインの話だけで終わらせず、実際の sys_ui_form（Form）を起点にして、フォームにセクションを割り当てる中間テーブル sys_ui_form_section、セクションそのものの sys_ui_section（Form Section）、セクション内の項目配置 sys_ui_element（Section Element）を、PDI（Zurich）の OOTB で確認した実測値とともに並べます。

想定読者は、ServiceNow の Incident は触ったことがあるが、フォームの並びがどのテーブルにどう保存されているのかをこれから把握したい管理者・開発者です。「Configure > Form Layout で変えた内容が裏で何のレコードになっているのか」を実機で確認するときに、管理者がどこを見ればよいかを示します。

この記事で分かること

• フォームの並びが画面ではなく 4つのテーブルのレコードとして保存されていること

• 「フォーム＝テーブル × ビュー」で、incident には今回の PDI で 8 ビューぶんのフォームがあること

• フォームとセクションは直接ではなく 中間テーブル sys_ui_form_section でつながること

• 各セクションの中身（項目の並び）が sys_ui_element に position 付きで入ること

• .split や formatter といった、項目以外の特殊要素も同じ sys_ui_element に並ぶこと

• 実機で確認するときに見るべき一覧URL

フォーム構成（Form Layout）とは

ServiceNow のフォーム構成は、あるテーブル（incident など）を、あるビュー（Default view など）で開いたときに、どの項目を・どのセクションに・どの順で表示するかを定義します。管理者が Configure > Form Layout で項目を足したり並べ替えたりすると、その結果がテーブルのレコードとして保存されます。

中心になるのは sys_ui_form（画面上のラベルは Form）です。1つの sys_ui_form レコードが「どのテーブルの・どのビューのフォームか」を表し、そこにセクションと項目が紐づきます。

フォームの並びは1枚の画面定義ファイルではなく、「フォーム」「中間」「セクション」「項目」の4テーブルに分かれて保存されています。並びを調べるときは、どのテーブルの何を見ているのかを意識します。

実際の Incident フォームは、上半分が2カラムのメイン領域、その下に Notes / Related Records / Resolution Information のタブ（セクション）が並びます。この見た目を、以降で扱う4テーブルの組み合わせが作ります。

フォーム構成の4テーブルと階層

フォーム構成に関係するテーブルは、大きく「フォーム」「中間」「セクション」「項目」の4つに分けて見ると整理できます。

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

• sys_ui_form（Form） … 「どのテーブルの・どのビューのフォームか」を表す。name（対象テーブル）と view（→ sys_ui_view）を持ちます。固有フィールドは 9。

• sys_ui_form_section（中間） … フォームにセクションを position 順で割り当てるつなぎ役。sys_ui_form と sys_ui_section の両方を参照します。固有フィールドは 12。

• sys_ui_section（Form Section） … セクション（見出しブロック）そのもの。caption（見出し）や header を持ちます。固有フィールドは 12。

• sys_ui_element（Section Element） … セクション内の1項目の配置。element（フィールド名）と position（並び順）、type を持ちます。固有フィールドは 12。

継承を見ると、sys_ui_form と sys_ui_section は Application File（sys_metadata）を継承する設定メタデータでした。sys_ui_element と sys_ui_form_section は super_class が空のルート基底テーブルでした。

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

4テーブルの規模感（件数）

• sys_ui_form … Extends：Application File（sys_metadata）／固有フィールド 9／総件数 966

• sys_ui_form_section … Extends：なし（ルート基底）／固有フィールド 12／総件数 2,833

• sys_ui_section … Extends：Application File（sys_metadata）／固有フィールド 12／総件数 6,380

• sys_ui_element … Extends：なし（ルート基底）／固有フィールド 12／総件数 66,621

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

https://<YourInstance>/sys_db_object_list.do?sysparm_query=nameSTARTSWITHsys_ui_form^ORname=sys_ui_section^ORname=sys_ui_element

フォーム＝テーブル × ビュー（sys_ui_form）

sys_ui_form の1レコードは「テーブル × ビュー」の組み合わせです。同じ incident テーブルでも、ビューが違えば別のフォーム（別の sys_ui_form レコード）になります。

今回確認した PDI（Zurich / OOTB）では、incident の sys_ui_form は 8 件ありました。incident に 8 ビューぶんのフォーム定義があるということです。内訳は次のとおりでした。

• Default view（クラシックなフォーム）

• Workspace / Service Operations Workspace / SOW Modal / SOW-Incident-Overview

• Cxs_popup / ITAM Workspace / Service Operations Workspace New Record

参考までに、他テーブルのフォーム数は change_request 6 / problem 7 でした。sc_req_item と task は sys_ui_form が 0 件で、テーブル固有のフォーム定義を持たず、より上位の既定フォームにフォールバックします。

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

フォーム一覧は、次のURLで確認できます。

https://<YourInstance>/sys_ui_form_list.do?sysparm_query=name=incident

公式の Form layout（Zurich） に、フォームレイアウトの構成方法（セクションの追加・項目の表示／非表示・埋め込みリストなど）が説明されています。

フォームとセクションをつなぐ中間テーブル（sys_ui_form_section）

フォームにセクションは直接ぶら下がりません。間に sys_ui_form_section という中間テーブルが入り、「このフォームに・このセクションを・この順（position）で割り当てる」という対応を1行ずつ持ちます。

今回確認した PDI（Zurich / OOTB）では、incident の sys_ui_form_section は全ビュー合計で 33 件ありました。このうち Default view のフォームに割り当てられているセクションは 4 件で、position 順に次のとおりでした。

• position 0 … （無題＝メインセクション）

• position 1 … Notes

• position 2 … Related Records

• position 3 … Resolution Information

この4件は、先ほどの Incident 実画面で見た「上のメイン領域＋3つのタブ」と一致します。フォーム側の見出しタブの並びは、この sys_ui_form_section の position が決めています。

フォームとセクションは多対多の関係で、その紐付けと順序を中間テーブルが引き受けます。同じセクションを複数のフォームから使い回すこともでき、その関係を sys_ui_form_section が表します。

中間テーブルの実体は、次のURLで一覧できます。

https://<YourInstance>/sys_ui_form_section_list.do?sysparm_query=sys_ui_form.name=incident^ORDERBYsys_ui_form^ORDERBYposition

セクションの中身（sys_ui_section と sys_ui_element）

セクションそのものは sys_ui_section に入ります。caption（見出し）や header、対象テーブル name、ビュー view を持ちます。今回確認した PDI（Zurich / OOTB）では、incident の sys_ui_section は全ビュー合計で 44 件ありました。

そして、セクションの中の「項目の並び」を持つのが sys_ui_element（Section Element） です。sys_ui_element は所属セクション（sys_ui_section）、配置するフィールド名（element）、並び順（position）、そして要素の種別（type）を持ちます。

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

incident の Default view・メインセクション（無題）の sys_ui_element を position 順に見ると、22 件ありました。並びは number → caller_id → category → subcategory → … と続き、途中に .split と .end_split、末尾に formatter が挟まります。

フォームの見た目の並びは、この sys_ui_element の position の昇順そのままです。管理者が Configure > Form Layout で項目を上下に動かすと、ここの position が書き換わります。

セクション一覧は、次のURLで確認できます。

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

項目以外の特殊要素（sys_ui_element.type）

sys_ui_element には、普通のフィールドだけでなく、レイアウトや埋め込みのための特殊要素も同じテーブルに position 付きで並びます。これを区別するのが type フィールドです。

今回確認した PDI（Zurich / OOTB）では、sys_ui_element.type の選択肢は 11 値ありました。

代表的なものは次のとおりです。

• element … 通常のフィールド配置。element にフィールド名が入ります。

• .split / .begin_split / .end_split … 2カラム表示の分割境界。先ほどのメインセクションでは position 9 に .split、position 18 に .end_split があり、その間が左右2列のレイアウトになります。

• formatter … 埋め込みUI。Incident の Default view では末尾（position 21）に cxs_table_search.xml（Related Search Results）が formatter として入っていました。

• list … 埋め込みリスト。annotation … 注記・区切り線・テキスト。chart / component … グラフやコンポーネント。

選択肢の一覧（11値）

.begin_split / element / annotation / .split / split / list / .end_split / end_split / chart / formatter / component

選択肢には .split とは別に接頭辞なしの split、.end_split とは別に end_split も定義されています。formatter 要素は sys_ui_formatter フィールド経由で埋め込みUIの実体を参照します。

「2カラムにする」「フォーマッタを差し込む」といった操作も、sys_ui_element の1行として保存されます。フォームの並びを最後まで読むには、フィールドだけでなく type 付きの特殊要素もあわせて見ます。

いま新しく項目を並べ替えるなら（設定例）

ここまでの構造を踏まえて、管理者が実際に項目を1つ動かすと、どのレコードが書き換わるかを追います。

例として、incident の Default view メインセクションで caller_id（position 1）を category（position 2）の後ろに移すとします。手順は incident フォームを開き、フォーム左上の「≡（追加メニュー）> Configure > Form Layout」を選ぶだけです。フォームデザイナで caller_id を category の下にドラッグして Save します。

このとき書き換わるのは、メインセクション（sys_id=bf1d96e3c0a801640190725e63f8ac80）配下の sys_ui_element の position です。caller_id と category の position が入れ替わり、保存後に同じセクションを sys_ui_element 一覧で見ると、並び順が更新されています。

https://<YourInstance>/sys_ui_element_list.do?sysparm_query=sys_ui_section=bf1d96e3c0a801640190725e63f8ac80^ORDERBYposition

新しいレコードは増えず、既存 22 件の position だけが更新されます。フォーム上の見た目（メインセクションの項目の縦並び）も、この position の昇順に従って変わります。Configure > Form Layout はこの sys_ui_element を書き換える画面だと分かると、設定後に「どこを見れば結果を確認できるか」が決まります。

incident のフォーム構成（実測まとめ）

ここまでの incident の実測値を、件数表にまとめます。

今回確認した PDI（Zurich / OOTB・2026-06-20 確認）では、次の構成でした。

• フォーム（ビュー）数：8、セクション数：44、フォーム×セクション割当：33、項目配置：355。

• Default view のフォームに限ると、セクション 4・項目合計 44（メイン22 / Notes 8 / Related Records 7 / Resolution Information 7）。

これは sys_ui_* テーブルが持つ「並びの定義」だけです。実際にフォーム上で項目が出る／隠れるは、UI Policy（incident で 15 件）やロール、データポリシーと合わさって決まります。フォーム構成テーブルだけで表示の全体を判断しないようにします。

実機を見て気づいたこと

• sc_req_item と task は sys_ui_form が 0 件でした。テーブルごとに専用フォームがあるものだと思っていましたが、固有の定義がなければ上位の既定フォームにフォールバックする作りでした。

• sys_ui_element.type の選択肢には .split と split、.end_split と end_split という、ドットの有無だけが違う値が両方定義されています。実際に使われていたのはドット付きのほうだけで、もう一方は選択肢として残っているだけの未使用値でした。

• sys_ui_form・sys_ui_section にはどちらも roles フィールドがあります。並びの定義だけでなく、レコード単位のロール制限もこの2テーブルが持てる作りです。

ServiceNow のフォーム構成のポイント

• フォームの並びは画面定義ファイルではなく、sys_ui_form / sys_ui_form_section / sys_ui_section / sys_ui_element の4テーブルのレコードとして保存されます。

• フォーム＝テーブル × ビュー。incident は今回の PDI で 8 ビューぶん（8 件）のフォームがありました。sc_req_item / task は固有フォーム 0 件で既定にフォールバックしていました。

• フォームとセクションは直接つながらず、中間テーブル sys_ui_form_section が position 順で割り当てます。incident は全ビュー合計 33 件、Default view は 4 セクションでした。

• セクションの中身は sys_ui_element が position 順で持ちます。Default view のメインセクションは 22 要素でした。

• .split / formatter などの特殊要素も同じ sys_ui_element（type で区別、11値）に並びます。2カラム化や埋め込みも1行として保存されます。

• 見た目の並びは sys_ui_element の position の昇順です。Configure > Form Layout の操作は、最終的にこれらのテーブルの書き換えになります。

フォーム構成を調べるときは、まず「どのテーブルの・どのビューか（sys_ui_form）」を決め、そこから中間（sys_ui_form_section）→ セクション（sys_ui_section）→ 項目（sys_ui_element）と1段ずつ下ります。

次に読むなら

フォーム構成だけでなく画面全体をどこで直すかは、ServiceNow 画面・フォーム完全ガイド：どこを直せば見た目が変わるのか にまとめています。

次は、ビューそのものを管理する sys_ui_view と、ビューを自動で切り替える View Rule、項目の表示／非表示・読み取り専用を動的に制御する UI Policy（sys_ui_policy）です。並びを決める sys_ui_*（静的な定義）と、表示を動かす UI Policy（動的な制御）を分けて押さえておくと、フォームの見え方が変わったときに、どちらを調べればよいか切り分けられます。これらのうちビューと View Rule は 同じレコードで見え方が変わる：ビュー（sys_ui_view） と View Rules（sysrule_view） で扱っています。UI Policy は別記事で扱う予定です。今回の PDI では、sys_ui_view 自体は全体で 704 件でした。

用語

• PDI：Personal Developer Instance（無料の検証用インスタンス）

• OOTB：Out of the Box（初期設定のまま）

• Form（sys_ui_form）：テーブル × ビューのフォーム定義（1レコード＝1フォーム）

• Form Section（sys_ui_section）：セクション（見出しブロック）

• Section Element（sys_ui_element）：セクション内の項目配置（1レコード＝1要素）

• sys_ui_form_section：フォームにセクションを割り当てる中間テーブル

• View（sys_ui_view）：フォーム／リストの見せ方の単位（Default view など）

自分の環境で確認するときのURL

先頭に自分のインスタンスを付けると、同じ画面が開けます。

テーブル定義       : sys_db_object_list.do?sysparm_query=nameSTARTSWITHsys_ui_form^ORname=sys_ui_section^ORname=sys_ui_element
フォーム一覧       : sys_ui_form_list.do?sysparm_query=name=incident
中間（割当）一覧   : sys_ui_form_section_list.do?sysparm_query=sys_ui_form.name=incident^ORDERBYsys_ui_form^ORDERBYposition
セクション一覧     : sys_ui_section_list.do?sysparm_query=name=incident^ORDERBYview
項目（要素）一覧   : sys_ui_element_list.do?sysparm_query=sys_ui_section.name=incident^ORDERBYposition
フィールド一覧     : sys_dictionary_list.do?sysparm_query=name=sys_ui_element^elementISNOTEMPTY

検証範囲とおことわり

• 確認した範囲：sys_ui_form / sys_ui_form_section / sys_ui_section / sys_ui_element の階層、固有フィールド数（順に 9 / 12 / 12 / 12）、主要フィールドと参照先、中間テーブルでの結びつき、type 選択肢（11値）、incident の Default view フォーム構造（4セクション・44項目・メインセクションの並び）、テーブル全体規模、周辺件数。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています。

• 確認していない範囲（断定しません）：Workspace 系ビュー（UI Builder / Configurable workspace）のフォーム定義方式、View Rule（sysrule_view）の挙動、Form Designer / Configure > Form Layout の保存処理の内部、role による項目出し分けの実挙動、caption の翻訳、本番のカスタムフォーム。これらは別記事で扱います。