Client ScriptとUI Policyの違い（フォーム挙動）
ServiceNow のフォームを開くと、ある項目が突然「必須」になったり、グレーアウトして「読み取り専用」になったり、条件によって項目そのものが消えたりします。この「フォームがブラウザ側で動く」挙動を作っているのが、主に Client Script と UI Policy です。
この記事では、フォーム挙動を機能論だけで説明しません。実際の sys_script_client（Client Script）と sys_ui_policy（UI Policy）を起点にします。UI Policy の動作1行ぶんを保存する sys_ui_policy_action（UI Policy Action）も含めて、両者が何を担い、どう違うのかを確認します。表示・必須・読み取りをどこで制御しているかも、PDI（Zurich）の OOTB で確認した実測値とともに示します。
この記事は、ServiceNow の Incident は触ったことがある人を対象にしています。想定しているのは、フォームの裏側（Client Script と UI Policy のテーブル構造）をこれから理解したい人です。管理者・開発者が実機で確認するときに見るべき点は、両テーブルの位置づけと使い分けです。あわせて UI Policy Action の動作項目、Client Script の種別も確認します。
この記事で分かること
フォームのブラウザ側挙動を担う2本柱が Client Script と UI Policy であること
UI Policy は「条件→動作」、Client Script は「JavaScript」という作り方の違い
UI Policy の動作が sys_ui_policy_action に1フィールド＝1レコードとして保存されること
表示／必須／読み取りが visible / mandatory / disabled で制御されること
Client Script の type（onLoad / onChange / onSubmit / onCellEdit）の違い
実機で確認するときに見るべき一覧URL
この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、スクリプト・ポリシー・件数の内容が異なる場合があります。
Client Script と UI Policy とは
ServiceNow のフォームは、サーバから返ってきた後、ブラウザ側でも挙動を変えられます。「入力中に他の項目を自動で埋める」「ある条件で項目を必須にする」「使わない項目を隠す」といった動きが、サーバへ保存する前にブラウザ上で起きます。これを担う代表が Client Script と UI Policy です。
Client Script（sys_script_client） … フォーム上で動く JavaScript。値の計算・入力検証・他項目の自動入力など、ロジックを自由に書けます。
UI Policy（sys_ui_policy） … 「この条件のときに、この項目を表示／必須／読み取りにする」を、基本ノーコードで設定する仕組みです。その具体的な動作は UI Policy Action（sys_ui_policy_action）に分けて保存されます。
どちらもブラウザ側（クライアントサイド）で動く点は共通ですが、「コードを書くか／条件と動作を設定するか」という作り方が違います。
3つのテーブルの位置づけ
Client Script・UI Policy・UI Policy Action は、いずれも業務データ（incident のようなレコード）ではありません。フォームの挙動を決める「設定（メタデータ）」を保存するテーブルです。
今回確認した PDI（Zurich / OOTB）では、3テーブルとも sys_metadata（ラベル: Application File）を直接継承していました。それぞれの固有フィールド数は、sys_script_client が19、sys_ui_policy が23、sys_ui_policy_action が12 でした。
UI Policy（sys_ui_policy）は「いつ動かすかの条件」を持ち、その「何をするか」は sys_ui_policy_action 側に ui_policy 参照でぶら下がります。 1つの UI Policy が複数フィールドを制御する場合、その数だけ UI Policy Action レコードが並びます。Client Script は逆に、動作を script 本文に直接書くため、別テーブルへは分かれません。
テーブル定義は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。
https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=sys_script_client^ORname=sys_ui_policy^ORname=sys_ui_policy_actionどう使い分けるか（Client Script vs UI Policy）
実機でフォームに手を入れるとき、まず迷うのが「Client Script と UI Policy のどちらでやるか」です。大まかな向き不向きは次のとおりです。
UI Policy が向くこと … 項目の表示・必須・読み取りを、条件に応じて切り替えること。スクリプトを書かずに設定でき、条件が false に戻ったときの「逆適用」も reverse_if_false で自動化できます。
Client Script が向くこと … 値の計算・入力検証・他項目の自動入力・複雑な分岐など、ロジックが必要な処理です。type で実行タイミングを選びます。
公式ドキュメントでも、表示・必須・読み取りのような単純な制御は UI Policy が推奨とされ、UI Policy はノーコードで多くの要件を満たせると説明されています。一方で、計算や検証のようなロジックは Client Script の領域です。なお UI Policy と Client Script は実行順序が関係する場面があり、公式に説明がありますが、本記事では実機での順序計測まではしていません（詳細は末尾の公式リンクを参照）。
UI Policy の「動作」は UI Policy Action に保存される
UI Policy の本体（sys_ui_policy）は「いつ動くか」を持ちます。「何をするか」は UI Policy Action（sys_ui_policy_action）に1フィールド＝1レコードで保存されます。
制御に使う3つの値
UI Policy Action の主なフィールドは次のとおりです。中心になるのは visible（表示）／mandatory（必須）／disabled（読み取り専用） の3つです。
visible / mandatory / disabled は3値（True / False / Leave alone）です。既定は「Leave alone（＝触らない）」で、1つの Action は指定した項目だけを制御に反映し、それ以外は触りません。ほかに cleared（値をクリアするか）と field_message（項目の下に出す注意書き）というフィールドもあります。次の実機画面は、incident の priority を読み取り専用にする UI Policy Action です。Read only が True、Mandatory と Visible は Leave alone になっています。
この Action の親 UI Policy が次の画面です。Table=Incident、Conditions（条件）と On load / Reverse if false などの設定を持ちます。「条件が成立したら priority を読み取り専用にする」という1つのまとまりです。
スクリプトと値の自動設定もできる
UI Policy 側には run_scripts（スクリプトを実行するか）、script_true / script_false（条件成立時／不成立時に実行するスクリプト）という項目もあります。UI Policy Action 側にも value / value_action（値を自動設定する）という項目があり、表示・必須・読み取りの切り替えだけでなく、値の設定やスクリプト実行までカバーできる作りです。
UI Policy の一覧は、次のURLで確認できます。
https://<YourInstance>/sys_ui_policy_list.do?sysparm_query=table=incident^active=true
公式の Create a UI policy（Zurich） に、UI Policy で項目を表示・非表示・必須・読み取りにする手順と、条件（Conditions）・On load・Reverse if false の意味が説明されています。
Client Script の種別（type）
Client Script は、いつ動くかを type で選びます。今回確認した PDI（Zurich / OOTB）では、type の選択肢は次の4種でした。
4つの type
onLoad … フォーム表示時に1回実行。初期表示の調整に使います。
onChange … 指定した field の値が変わったときに実行（フォーム読込時にも1回走ります）。対象フィールドを field で1つ指定します。
onSubmit … フォーム送信時に実行。保存前の入力検証などに使います。
onCellEdit … リストのセル編集時に実行。フォームではなくリスト用です。
次の実機画面は、incident の onChange Client Script です。Type が onChange、Field name が Caller、そして Script に実際の JavaScript（onChange 関数）が書かれています。UI Policy と違い、動作はこの script 本文に直接書く点が見て取れます。ほかに applies_extended（拡張テーブルにも適用するか）という設定もあり、対象テーブルの子テーブルまで動作範囲を広げられる仕組みです。
Client Script の一覧は、次のURLで確認できます。
https://<YourInstance>/sys_script_client_list.do?sysparm_query=table=incident^active=true^ORDERBYtype
公式の Client Scripts best practices（Zurich） に、Client Script の種別や書き方の注意点（重い処理を避ける等）がまとめられています。
incident に紐づくフォーム挙動の実測
実際に incident テーブルへ紐づく Client Script と UI Policy を数えると、フォーム挙動が複数の設定の積み重ねでできていることが分かります。
incident での件数
今回確認した PDI（Zurich / OOTB・active 中心・2026-06-21 確認）では、次の件数でした。
Client Script（incident）… 19件。内訳は onLoad 8 / onChange 10 / onSubmit 1 / onCellEdit 0 で、合計が19件と一致しました。うち global=true は15件です。
UI Policy（incident）… 15件。うち on_load=true が14件、reverse_if_false=true が13件でした。
UI Policy Action（incident の UI Policy に紐づくもの）… 38件（ui_policy.table=incident）。UI Policy 1件あたり平均で複数の Action を持つことが分かります。
インスタンス全体で見ると
参考として、インスタンス全体の件数も確認しました。Client Script（active）は約2,486件です。UI Policy（active）は約2,842件（うち global が2,791件）、UI Policy Action は全体で5,055件でした。UI Policy Action の内訳は、Read only（disabled=true）が940件です。Mandatory（mandatory=true）は785件、非表示（visible=false）は2,013件です。表示制御（隠す）が最も多く使われている傾向が見えます。
ここで数えているのは、incident（基底）に直接紐づく設定です。 フォームの挙動は、これらに加えて Business Rule（サーバ側）や ACL（権限）なども関係します。Client Script と UI Policy だけで全挙動が決まるわけではありません。
ServiceNow のフォーム挙動（Client Script / UI Policy）のポイント
フォームのブラウザ側挙動は、主に Client Script（JavaScript）と UI Policy（条件→動作） の2本柱でできています。どちらもクライアントサイドで動きますが、作り方が違います。
表示・必須・読み取りのような単純な制御は UI Policy が向きます。計算・検証・自動入力のようなロジックは Client Script が向きます（公式も単純制御は UI Policy 推奨です）。
UI Policy の「何をするか」は sys_ui_policy_action に1フィールド＝1レコードで保存されます。制御には visible / mandatory / disabled（既定は Leave alone）を使います。
Client Script は type（onLoad / onChange / onSubmit / onCellEdit）で実行タイミングを選びます。onChange は対象 field を1つ指定します。動作は script 本文に直接書きます。
今回の PDI では、incident に Client Script 19件（onLoad 8 / onChange 10 / onSubmit 1）が紐づいていました。UI Policy は15件、UI Policy Action は38件です。フォーム挙動は複数設定の積み重ねです。
フォームの挙動を調べるときは、まず「これは UI Policy の仕事か、Client Script の仕事か」を切り分けます。UI Policy なら sys_ui_policy → sys_ui_policy_action（visible/mandatory/disabled）を確認します。Client Script なら type と script を見ます。この順で確認すると整理しやすくなります。
実機で気づいたこと
気づいたことは3つあります。
UI Policy は表示・必須・読み取りをノーコードで切り替える仕組みだと思っていましたが、実機には run_scripts や script_true / script_false という項目もありました。条件が成立・不成立になったタイミングで JavaScript を実行できる作りで、UI Policy Action 側にも value / value_action という値を自動設定する項目があります。「UI Policy はノーコードで Client Script はコードを書く」という単純な線引きは、フィールド一覧を開くと崩れます。
sys_script_client のフィールド一覧に isolate_script という項目がありました。Client Script の実行環境を他の JavaScript から隔離するかどうかのフラグで、公式のベストプラクティスでもオンを推奨されている設定です。フォーム上は小さなチェックボックス1つですが、こういう重要な設定もフィールド一覧を見るまで気づきませんでした。
UI Policy Action の visible / mandatory / disabled が、どれも既定で Leave alone なのは理にかなっていると感じました。実機で priority を読み取り専用にする Action を見ると、Mandatory と Visible は触らず Read only だけを True にしています。複数の UI Policy が同じフィールドを触っても、指定していない制御まで巻き込まれない設計です。
sys_script_client のフィールドには messages（多言語対応のメッセージ定義）と sys_overrides（OOTBのどのレコードを上書きしているか）というものもありました。単なる JavaScript の置き場ではなく、国際化やカスタマイズ追跡まで意識したフィールドが用意されている点は、名前だけでは分かりませんでした。
次に読むなら
次回のテーマとして、次の3点を予定しています。
Client Script と UI Policy の実行順序（読込時・値変更時にどちらが先に走るか）
UI Policy の reverse_if_false が条件 false 時にどう逆適用するか
Catalog 側（Catalog Client Script / Catalog UI Policy）との違い
特に「同じ項目を UI Policy でも Client Script でも触っているときに、最終的にどちらの指定が効くか」は、実環境のトラブルで頻出します。これらは本記事の「使い分け」「UI Policy Action」で触れた仕組みの先にあたり、別記事で扱う予定です。
用語
主な用語は6つです。
PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
Client Script：フォーム上で動く JavaScript（sys_script_client）
UI Policy：条件に応じて項目の表示／必須／読み取りを切り替える設定（sys_ui_policy）
UI Policy Action：UI Policy の具体的な動作1行（sys_ui_policy_action）
Leave alone（ignore）：UI Policy Action で「その制御は触らない」を表す既定値
自分の環境で確認するときのURL
先頭に自分のインスタンスを付けると、同じ画面が開けます。
テーブル定義 : sys_db_object_list.do?sysparm_query=name=sys_script_client^ORname=sys_ui_policy^ORname=sys_ui_policy_action
Client Script : sys_script_client_list.do?sysparm_query=table=incident^active=true^ORDERBYtype
UI Policy : sys_ui_policy_list.do?sysparm_query=table=incident^active=true
UI Policy Action: sys_ui_policy_action_list.do?sysparm_query=ui_policy.table=incident
固有フィールド : sys_dictionary_list.do?sysparm_query=name=sys_ui_policy_action^elementISNOTEMPTY検証範囲とおことわり
確認した範囲は次のとおりです。すべて PDI（Zurich / 2026-06-21 確認）の OOTB で取得しています。
3テーブルの継承（いずれも sys_metadata=Application File 直下）
固有フィールド数（sys_script_client 19 / sys_ui_policy 23 / sys_ui_policy_action 12）
Client Script の type（4種）
UI Policy / UI Policy Action の主要フィールドと visible/mandatory/disabled の値
incident に紐づく件数（type別内訳・global比率含む）
インスタンス全体の参考件数
スクショ対象レコードの実値
確認していない範囲（断定しません）は次のとおりです。これらは別記事で扱います。
各スクリプト本文の挙動
Client Script と UI Policy の厳密な実行順序（公式ドキュメントの記載のみ参照し、実機計測はしていません）
Catalog Client Script / Catalog UI Policy（カタログ側）
UI Builder / Service Portal 側のクライアントスクリプト
ドメイン分離環境での適用範囲
今回は PDI の OOTB（初期設定）を前提に、フォーム挙動を担うテーブルの構造を確認しました。実環境では、既存のカスタマイズによってスクリプト・ポリシーの数・内容が変わります。
