全ページに読み込まれるUI Scriptは208件中11件だけ（sys_ui_script）

2026年6月27日 09:31

ServiceNow のフォームで入力チェックや表示の制御を書いていると、同じクライアント側 JavaScript をあちこちの Client Script で何度も書く場面が出てきます。そこで使うのが、共通のクライアント側 JavaScript（関数・クラス・ライブラリ）を1か所にまとめて複数の画面から読み込む仕組みです。それが UI Script（UI スクリプト）、テーブル名で言うと sys_ui_script です。

想定読者は、Client Script は書いたことがあるが UI Script という「共通JSの置き場」はまだ触っていない管理者・開発者です。どんなテーブルに、どんな形で保存され、どうやって画面に読み込まれるのかを確認します。PDI（Zurich / OOTB）で sys_ui_script を実際に開き、UI Script が Script Include（サーバ側）のクライアント版であることを確かめました。global と ui_type が「いつ・どこで読み込まれるか」を決める点と、実機の件数分布・代表例も扱います。

この記事で分かること

UI Script の実体が sys_ui_script に「1スクリプト＝1レコード」で保存され、中身はブラウザで動くクライアント側 JavaScript であること
sys_ui_script が sys_metadata（Application File）を継承するメタデータ系で、Script Include と同じ基底であること
主要フィールド（name（API名）/ script / active / global / ui_type）の役割
global（全ページ自動ロード）は実測 11件だけで、大多数（196件）は必要なときだけ読み込まれること
ui_type の分布（Desktop 145 / All 17 / Mobile・Service Portal 2 /（空）44、総数208）
Client Script・Service Portal などからの呼ばれ方と、Script Include（サーバ側）との違い

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

UI Script（UI スクリプト）とは

UI Script は、再利用できるクライアント側 JavaScript を1か所にまとめて登録しておく仕組みです。登録した関数・クラス・ライブラリは、Client Script や UI Page、Service Portal などから読み込んで使えます。同じコードを各 Client Script にコピペする代わりに、共通ロジックを UI Script に置いて呼び出す形です。

公式ドキュメントでも、UI Script は「クライアント側 JavaScript を再利用可能な形にまとめるもの」と説明されています。Script Include がサーバ側 JavaScript を格納するのと同じ位置づけです。つまり UI Script は Script Include のクライアント版にあたります。下の実画面は、その1件をフォームで開いたものです。

このレコードは OOTB の ValidateStartEndDates（説明：開始日より終了日が前になっていないか検証する）です。本体は function validateStartEndDate(startDateField, endDateField, processErrorMsg){ ... } という関数です。中では g_form.getValue() や g_form.getLabelOf() を使っています。これらはブラウザ側でしか使えないクライアント API なので、UI Script の中身がサーバではなくブラウザで動く共通関数だと本体からそのまま読み取れます。Client Script から validateStartEndDate('start_date','end_date', ...) のように呼んで使う、典型的な再利用部品です。

今回確認した PDI（Zurich / OOTB）では、sys_ui_script に 208件（うち active=true が 207件）の UI Script が入っていました。Script Include と同じく、UI Script は処理の置き場所であって、それ自体が自動で動くわけではありません（global を除く。後述）。だから UI Script を読むときは、「何が定義されているか」と「どこから・どう読み込まれるか」をセットで見る必要があります。

sys_ui_script はどこに位置するテーブルか

UI Script のまわりの継承関係を見ると、Script Include と兄弟のような位置にあることが分かります。

今回確認した PDI（Zurich / OOTB）では、sys_ui_script は sys_metadata（Application File＝アプリケーションファイルの基底）を継承していました。これは Script Include（サーバ側）とまったく同じ基底です。つまり UI Script も Script Include も、業務データではなく設定（メタデータ）の一種です。Update Set に乗る対象、つまり開発インスタンスで作って本番へ移送できるコード資産として管理されます。違いは実行場所で、Script Include はサーバ、UI Script はブラウザ（クライアント）で動きます。

固有フィールドは 10件で、UI Script の中身と読み込まれ方を決めるのは次のフィールドです。

name（API名）と script（本体）で「何という名前の・どんなクライアントJSか」が決まります。active / global / ui_type は「有効か・どこで読み込まれるか」を決めます。Script Include にあった access（スコープ可視性）や client_callable に相当するフィールドはありません。UI Script は最初からクライアント向けなので、代わりに global（全ページ自動ロード）と ui_type（対象プラットフォーム）が読み込まれ方を制御します。フィールド一覧は次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

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

global と ui_type：いつ・どこで読み込まれるか

UI Script でつまずきやすいのは、その共通JSがいつ・どこで読み込まれるかという点です。これを決めるのが global と ui_type の2つです。

global は「全ページに自動で読み込むか」のフラグです。global=true にすると、クラシックUIのどのフォームでも、その UI Script の関数がそのまま使えるようになります。実機の分布は次の通りでした。

global=true … 11件（全ページに自動ロード）
global=false … 196件（必要なときだけ読み込む）
global が空（未設定）… 1件（合計で総数 208 件）

つまり大多数（196件）は global=false で、全ページ常時ロードはごく一部（11件）です。すべての UI Script を全ページに読ませると重くなります。そのため、本当に共通で使うものだけを global にし、それ以外は使う画面でだけ読み込む設計になっています。global=false の UI Script は、呼び出し側が明示的に読み込みます。Client Script などが ScriptLoader.getScripts('<名前>.jsdbx', コールバック) や g_ui_scripts.getUIScript('<名前>') を呼ぶ形です。なお公式によると、スコープアプリでは global な UI Script は作れません。

global=true の実機一覧（11件）はこのようになっていました。

もう一方の ui_type は、どのプラットフォームで動く UI Script かを表す選択肢です。

選択肢は Desktop（0）/ Mobile・Service Portal（1）/ All（10）の3つです。global と ui_type の件数分布は次の通りでした。

ui_type は Desktop（クラシックUI）が145件で大多数、両方で動く All が17件、Service Portal 向けが2件でした。残り44件は ui_type が空欄で、これは古いライブラリ系のレコード（後述）です。一覧を ui_type でグループ化すると、この内訳がそのまま見えます。

実機ではどんな UI Script があるか

UI Script の一覧を眺めると、用途は大きく3つに分かれていました。

再利用する共通関数・クラス … 先ほどの ValidateStartEndDates（日付の前後チェック）や AJAXProgress のように、複数の画面から呼ぶ部品で、UI Script の最も素直な使い方です。AJAXProgress の説明文は "Use AJAX to determine the progress of something" でした。
外部 JavaScript ライブラリの取り込み … angular-ellipsis.min.js のように、外部ライブラリの中身をそのまま UI Script として登録しているもの。ui_type が空欄の44件には、こうしたライブラリ系が含まれます。
Service Portal 向けモジュール … app_com や app_com.aisa（AI Search Assist）系のように、Service Portal のウィジェットから使う JS モジュール。app_com の説明は "Definition for the Common Application Components for Service Portal" です。

このように UI Script は「小さな共通関数」から「丸ごとのライブラリ」「ポータル用モジュール」まで、クライアント側 JS の汎用的な置き場として使われています。公式の UI scripts（Zurich）にも、管理者が作成した UI Script を Client Script や他のクライアント側オブジェクト、HTML から実行できると書かれています。

どこから呼ばれるか（Client Script / Service Portal）

UI Script はライブラリなので、呼び出し元がいて初めて意味を持ちます（global=true で全ページに読み込ませる場合を除く）。クライアント側のさまざまな仕組みから読み込まれます。

Client Script / UI Policy … フォームの onLoad / onChange などから、UI Script の共通関数を呼びます。
Catalog Client Script … サービスカタログのフォーム挙動でも、同じ UI Script を読み込んで使えます。
UI Page / UI Macro … 独自画面の HTML から UI Script を読み込みます。
Service Portal のウィジェット … ウィジェットの依存（JS Includes）として UI Script を読み込みます。

ここで Script Include との役割分担がはっきりします。クライアント側で完結する処理、たとえばフォームの値チェックや表示制御は UI Script に置きます。サーバの DB を触る処理は Script Include に置き、GlideAjax 経由で呼びます。なお、どの Client Script / UI Page がどの UI Script を読み込んでいるかは、各スクリプト本文に書かれています。テーブルからは件数を追えませんでした（今回は検証範囲外）。

Script Include（サーバ側）との違い

UI Script とサーバ側の Script Include は、名前も役割もよく似た仕組みです。

両者は「再利用JSの置き場」という点は同じで、基底もどちらも sys_metadata（Application File）です。違うのは実行場所で、UI Script はブラウザ、Script Include はサーバで動きます。だから使える API も分かれます。UI Script は g_form / g_user などのクライアント API、Script Include は GlideRecord / gs などのサーバ API です。件数も、クライアント側の UI Script が 208件なのに対しサーバ側の Script Include は 4,683件でした。OOTB のロジックの多くはサーバ側に置かれています。

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

今回見た画面を自分のインスタンスで開くためのURLです（<YourInstance> は置き換えてください）。

# UI Script の一覧（名前順）
https://<YourInstance>/sys_ui_script_list.do?sysparm_query=active=true^ORDERBYname

# UI Script を ui_type でグループ化
https://<YourInstance>/sys_ui_script_list.do?sysparm_query=GROUPBYui_type

# 全ページ自動ロード（global=true）の一覧
https://<YourInstance>/sys_ui_script_list.do?sysparm_query=global=true^ORDERBYname

# sys_ui_script のフィールド定義
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_ui_script^elementISNOTEMPTY

まとめ

UI Script は sys_ui_script の1行＝1スクリプトで保存され、中身はブラウザで動くクライアント側 JavaScript（g_form などが使える）。PDI 実機は 208件（active 207）。
sys_ui_script は sys_metadata（Application File） を継承するメタデータ系で、Script Include と同じ基底。Update Set で移送できるコード資産。
中心フィールドは name（API名）/ script / active / global / ui_type。Script Include の access / client_callable に当たるものは無く、代わりに global と ui_type で読み込まれ方が決まる。
global=true（全ページ自動ロード）は実測 11件だけで、大多数（196件）は global=false＝必要なときだけ読み込む。ui_type は Desktop 145 / All 17 / Mobile・Service Portal 2 /（空）44。
呼び出し元は Client Script / Catalog Client Script / UI Page / Service Portal など。クライアントは UI Script、サーバは Script Include（GlideAjax 経由）という使い分け。

UI Script が分かると、Script Include（サーバ側の再利用ロジック）・Client Script と UI Policy（フォーム挙動）・UI Page（独自画面）・Service Portal（ポータル）という ServiceNow のスクリプト/画面まわりがひとつにつながって見えてきます。クライアントとサーバ、共通部品と画面という軸で並べ直せる状態です。

ServiceNow 画面・フォーム完全ガイド：どこを直せば見た目が変わるのか — UI Scriptは画面に読み込まれる共通JSです。画面そのものの構成をどこで直せるかは、こちらの完全ガイドにまとまっています。