UIポリシーとクライアントスクリプトが「同じに見える」理由
ServiceNowを触り始めた頃、フォームの見た目や入力ルールを変えたい場面が一気に増えます。たとえば「この状態のときは必須にしたい」「この選択肢なら別の項目を表示したい」など。ここで候補に上がるのが UIポリシー と クライアントスクリプト です。
この2つが混乱しやすいのは、どちらも「画面上の入力体験」を変えられて、しかも結果が似て見えるからです。極端に言えば、同じ見た目の制御をどちらでも実現できるケースがあります。
ただ、実務でも学習でも大事なのは「動いたかどうか」より “なぜその手段を選ぶのか”。境界線を意識しないと、次のような落とし穴にハマります。
- 後から修正が難しくなる（どこで制御しているか追えない）
- 想定外の画面では効かない（フォームの種類やUIで差が出る）
- パフォーマンスや保守性が悪化する（不要なスクリプト増殖）
- サーバ側の整合性とズレる（UIで必須にしたのに保存は通る等）
ここでまず押さえておきたい前提があります。
UIポリシーもクライアントスクリプトも“クライアント側（画面側）”の仕組みで、基本的に「ユーザーが今見ている画面での振る舞い」を扱います。
一方で、本当に守るべき業務ルール（保存の可否、権限、必須チェックなど）をサーバ側で担保する仕組み（ACL、Business Rule、Data Policy など）も別に存在します。
この記事では、クライアント側の2つに焦点を当てつつ、「境界線」と「選び方」を具体例込みで整理していきます。CSA学習者が前提として理解しておくと混乱しにくいポイントを中心に書きますが、暗記ではなく“判断できる状態”を目指します。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
UIポリシーでやるべきこと、やらない方がいいこと
UIポリシーは「宣言的にフォームを整える」仕組み
UIポリシーの強みは、コードを書かずに（または最小限で）フォーム項目の状態を切り替えられる点です。典型的には次の3つ。
- 表示／非表示
- 必須／任意
- 読み取り専用／編集可
そして条件（Condition）に合致したときに、対象フィールドの状態を変えます。ここがいわゆる「宣言的（こうしたい、を設定で表す）」な気持ちよさで、学習初期に相性がいい理由でもあります。
UIポリシーが向いている具体例
たとえばインシデントで、
- カテゴリが「ネットワーク」のときだけ「回線ID」を表示する
- 状態が「Resolved」になったら「解決方法」を必須にする
- 重要度が高いときは「影響範囲」を読み取り専用にする（入力変更を防ぐ）
こういった “フォーム項目の状態” に閉じる制御は、UIポリシーが第一候補になりやすいです。
UIポリシーの落とし穴：「できそう」に見えてもやりすぎない
UIポリシーは便利ですが、やりすぎると次のような不具合や保守問題につながります。
- 複雑な条件を積み上げすぎて、どのポリシーが効いているか分からなくなる
- “例外ルール”の追加が続いて、結果としてロジックが迷路になる
- UIポリシーが効く画面／効かない画面を理解せず、期待と結果がズレる
特に「条件の重なり」が増えると、後から入った人（未来の自分も含む）が読み解くのが大変です。UIポリシーはスクリプトより読みやすい反面、増えすぎると逆に追えません。
UIポリシーで“やらない方がいい”領域
UIポリシーは基本的に「項目の見た目・入力状態」の制御が得意です。逆に次のような「振る舞い」寄りの要求は、UIポリシーだけで片付けようとすると無理が出ます。
- 入力値を加工して自動セットしたい（例：文字列整形、計算）
- 別フィールドの値に応じて、選択肢や参照先を動的に変えたい
- 画面表示時にサーバへ問い合わせて結果を反映したい
- メッセージ表示や確認ダイアログなど、ユーザー操作を誘導したい
このあたりから、自然に クライアントスクリプトの出番になっていきます。
クライアントスクリプトの得意領域：UIポリシーでは届かない“振る舞い”
クライアントスクリプトは「イベント駆動で動くコード」
クライアントスクリプトは、フォーム上のイベントに合わせて JavaScript で制御します。代表的なタイミングは次のとおりです。
- onLoad：フォームが開いたとき
- onChange：フィールド値が変わったとき
- onSubmit：保存（送信）しようとしたとき
- onCellEdit：リストのセル編集時（使う場面は限定的）
UIポリシーと違って、できることの幅が広い分、設計の良し悪しが出やすいのが特徴です。
クライアントスクリプトが向いている具体例
値の自動補完や計算
例：開始日時と終了日時から作業時間を計算して入れる、電話番号のハイフンを除去する、入力を正規化する…など。
動的な制御（条件が“値そのもの”に依存）
例：
「カテゴリ＝Aのときは必須、カテゴリ＝Bのときは読み取り専用」程度ならUIポリシーでもできますが、
「カテゴリがA/B/Cのときはこの計算ロジックを適用し、結果によって別フィールドを更新する」みたいに、ロジックが“処理”に寄るとクライアントスクリプトが適します。
サーバ問い合わせが必要な判断
たとえば「選択したユーザーが特定のグループに所属しているか」を見て制御したい場合、画面側だけでは判断できません。こういうときは GlideAjax などの仕組みを使ってサーバから情報を取り、画面に反映させるケースがあります（学習段階では“そういう設計がある”くらい把握できていれば十分です）。
クライアントスクリプトの注意点：自由度が高い＝乱れやすい
クライアントスクリプトは便利ですが、次の失敗が起こりがちです。
- 似たようなスクリプトが量産され、重複が増える
- onChange の連鎖で意図せずループする（値変更→onChange発火→また値変更…）
- 画面が重くなる（不要な処理や問い合わせの多用）
- “この画面では動くが別UIでは動かない”を招く
だからこそ、UIポリシーで済むならUIポリシー、スクリプトは必要なときに最小限、が基本姿勢になります。
迷ったらこれで決める：判断基準チェックリストと設計パターン
ここがこの記事の中心です。「境界線」は一言で割り切れないので、迷ったときの判断軸を持つのが一番ラクです。
判断基準チェックリスト
次の質問に「はい」が多いほどUIポリシー寄り、「いいえ」や別方向が多いほどクライアントスクリプト寄りになります。
- やりたいことは 表示／必須／読み取り専用 の切り替えだけ？
- 条件は フォーム上にある値 だけで完結する？
- ロジックはシンプルで、例外が少ない？
- 将来、似た制御が増えても “設定” で追える形にしたい？
逆に、次に当てはまるならクライアントスクリプトを検討します。
- 値を加工したり計算したり、処理そのものが必要
- 条件が複雑で、UIポリシーの条件設定だけでは破綻しそう
- ユーザーへのガイダンス（メッセージ、警告、入力補助）が必要
- サーバ情報を見ないと判断できない（参照、権限、集計など）
よくある設計パターン（現場で迷いが減る考え方）
パターンA：UIポリシーを“ベース”にして、足りない部分だけスクリプト
例：
「状態がResolvedなら解決方法を必須」→ UIポリシー
「解決方法の文字数が短すぎる場合は警告メッセージを出す」→ クライアントスクリプト（onSubmit など）
“見た目のルール”はUIポリシー、“入力体験の補助”はスクリプト、という分け方は自然です。
パターンB：クライアントスクリプトで制御する場合も、やりたいことを“絞る”
スクリプトで何でもできるからといって、UIポリシーの代わりに全部書くのはおすすめしません。
たとえば「フィールドを非表示にする」だけのために長い onLoad を書くより、UIポリシーで済ませた方が読みやすいことが多いです。
パターンC：クライアント側は“補助”、整合性の担保は別レイヤ
CSAの学習で混乱しやすいのがここです。
UIポリシーやクライアントスクリプトで「必須にした」つもりでも、別経路（インポート、API、別UI）で登録できる設計は現実に起こりえます。
だから、ビジネス的に守るべき制約（必須条件、保存不可など）は、Data Policy や Business Rule、ACL といったサーバ側も絡めて考えるのが自然です。
この記事の主題は境界線なので深掘りはしませんが、「クライアント側は“ユーザー体験のため”」という位置づけを持っておくと、理解が安定します。
よくある失敗と、学習を伸ばすコツ
失敗例：UIポリシーを増やしすぎて“誰も触れない”状態
最初はUIポリシーが手軽なので、要件が出るたびに追加しがちです。結果として、
- 似た条件のUIポリシーが乱立
- 例外対応が例外を呼ぶ
- どれを直せばいいか分からない
こうなると、スクリプトより保守が難しくなることがあります。
対策としては、UIポリシーを作る前に「その制御は本当に必要？」「条件は整理できてる？」を一呼吸置くこと。学習段階でも、要件を言葉で説明できるかを試すだけで整理が進みます。
失敗例：クライアントスクリプトで“できるからやる”
onChange でフィールド値を変更し、さらに別の onChange が走って…という連鎖でバグるのはありがちです。
また、同じような処理が別テーブル／別フォームにも増殖しやすい。
対策はシンプルで、スクリプトは短く、責務を限定すること。
「入力補助」「メッセージ表示」「値の軽い整形」など、目的が一言で言える範囲に収めると事故りにくいです。
失敗例：“画面で必須”と“保存で必須”をごっちゃにする
UIポリシーで必須にしたのに、別ルートで登録できてしまう。これをバグと感じる人もいますが、設計のレイヤが違うだけです。
「ユーザーに入力を促す」仕組みと、「データとして許可しない」仕組みは役割が違う、と理解しておくと混乱が減ります。
学習を伸ばすコツ：自分で「境界線クイズ」を作る
おすすめは、学習中に次の形で自問することです。
- この要件はUIポリシーで足りる？足りないなら何が足りない？
- もしスクリプトを書くなら、イベントは onLoad / onChange / onSubmit のどれ？
- そもそもサーバ側で担保が必要なルールでは？
この“問い”を回すだけで、暗記に偏らず理解が積み上がります。
体系的に学ぶ教材の一例として：Udemy講座を活用する
UIポリシーとクライアントスクリプトは、文章で読んだだけだと「わかった気になる」一方で、実際に手を動かすと詰まりやすい分野です。
フォーム上で条件を変えたときに何が起きるか、onChange がどのタイミングで走るか、エラーをどう切り分けるかは、画面操作とセットで覚える方が早いことが多いです。
そのため、学習の補助として ServiceNow基礎〜フォーム制御を扱うUdemy講座を一本持っておくのは現実的です。
“これだけでOK”という話ではなく、体系立てて触る順番が用意されている教材を一つ挟むと、独学の迷子になりにくい、という意味でおすすめできます。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ：境界線は「機能の差」より「設計の意図」で決める
UIポリシーとクライアントスクリプトは、どちらもフォームの入力体験を変えられます。でも境界線をスッキリさせるコツは、「できる／できない」で戦うことではなく、何を目的に、どのレイヤで、どれだけの複雑さを許容するかを基準にすることです。
- UIポリシー：表示・必須・読み取り専用など、“フォーム状態”の切り替えに強い。まず検討する。
- クライアントスクリプト：値の加工、動的な振る舞い、イベント駆動の制御に強い。必要なときに最小限で使う。
- そして、どちらもクライアント側の仕組みなので、データとして守るべき制約は別レイヤ（サーバ側）も視野に入れると理解が安定する。
この考え方が身につくと、CSAの学習でも実務でも「なぜその実装にするのか」を説明できるようになります。暗記よりずっと強いです。
もし手を動かしながら体系的に整理したいなら、Udemyなどの講座を“学習の地図”として一つ使うのも手です。動画で一連の流れをなぞるだけでも、UIポリシーとクライアントスクリプトの境界線が体感として掴みやすくなります。
