ServiceNowで処理を書くならどこ？ Business Rule・Client Script・ACLの使い分けを実機の件数から考える
ServiceNowで新しい処理を作ろうとして、Business Rule・Client Script・ACLのどれに書くべきか迷うことはないでしょうか。答えは、権限を止めたいのか、画面を変えたいのか、保存のタイミングで動かしたいのかという処理の性質でほぼ決まります。Zurich PDIで8つの仕組みの件数を数え、選び方を整理しました。
検証環境：Zurich PDI / OOTB / 2026-08-08 確認
結論：処理を書く場所は6つ、選ぶ基準は「権限・画面・保存」の3層
先に全体像です。
ServiceNowで処理を書く場所は、大きく6つあります。権限を止めるACL、画面を出し分けるUI PolicyとClient Script、保存前後に動くBusiness Rule、処理を部品化するScript Include、1回きりの後始末をするFix Scriptです。
選ぶ順番は「まず権限か、次に画面か、最後に保存か」という3層で決まります。同じ「フォームの項目を制御したい」という依頼でも、権限の話ならACL、見た目の話ならUI PolicyかClient Scriptと答えが変わります。
件数を数えると、ACLが43,744件で断トツの最多でした。標準のServiceNowでいちばん多い設定は、処理そのものではなく権限の定義です。
上の図が判断の流れです。権限を制限したいか、画面の項目を出し分けたいか、保存前後にサーバ側で処理したいかという順に質問をたどると、6つの仕組みのどれを開けばよいかが決まります。迷いが減ります。
8つの仕組み全体の件数は、次の表のとおりです。
ACLが43,744件、Business Ruleが5,719件、Script Includeが4,828件と続きます。UI PolicyとClient Scriptは近い数字に見えますが、UI Policyのほうが324件多く登録されていました。UI ActionとScheduled Scriptもこの表に含めていますが、フォームまでは今回扱いません。ボタンの定義や定期実行の話は別記事の範囲です。
権限を制限するならACL：43,744件で最多の理由
ACL（sys_security_acl）は、どのロールがどのテーブル・どのフィールドに対して、読み書き・作成・削除・実行のどれをできるかを定義するテーブルです。件数は43,744件、Business Ruleの約7.6倍でした。桁が違います。
Operationでグループ化すると内訳が見えます。多いのはquery_range（9,235件）・write（8,095件）・read（8,029件）・create（6,089件）・delete（5,969件）です。同じテーブルの同じ操作に対して複数のACLが積み重なっている場合が多く、1テーブルにつき1レコードでは済みません。よく使われるテーブルほど、ACLの枚数も増える構造です。
一覧にはDecision Typeという列もありました。条件を満たすと許可するAllow if、満たさなければ拒否するDeny unlessの2種類があり、単純な許可・拒否だけでなく条件付きの判定を組み立てられる作りになっています。ACLの名前は、テーブル全体を守るならincidentのようにテーブル名だけ、特定の項目だけを守るならincident.work_notesのようにドット区切りで表されます。
処理を書く前に「これは権限の話かどうか」を最初に切り分けておくと、あとの選択肢で悩む時間が減ります。ボタンが押せない、項目が編集できないという相談は、まずACLを疑う癖をつけておくと早く解決に近づきます。
画面をノーコードで出し分けるならUI Policy
画面の項目を条件で表示・非表示・必須・読み取り専用に切り替えたいとき、最初に検討するのがUI Policy（sys_ui_policy）です。件数は2,909件でした。Client Scriptの2,585件より324件多く登録されています。
フォームにはConditions・On load・Reverse if falseという設定が並びます。条件が成立したときに何をするかをUI Policy Action側で登録する仕組みで、スクリプトを1行も書かずに項目の状態を切り替えられる点が特徴です。Reverse if falseにチェックが入っていると、条件が外れたときに元の状態へ自動で戻ります。Orderの初期値は100で、Globalにチェックが入っていれば全ビューに、Inheritにチェックが入っていれば拡張先のテーブルにも同じ設定が及びます。
UI PolicyがClient Scriptより多く登録されている実態は、画面の出し分けをスクリプトに頼らず設定で済ませる方向に寄っていることを示します。同じ「必須にする」という処理でも、条件式だけで足りるならUI Policy、もっと複雑な計算や外部呼び出しが必要になった時点でClient Scriptに切り替える。この順番が実務向きです。差は324件しかありませんが、ノーコードで足りる場面の多さを思うと、この僅差は感覚より小さいと感じました。
計算や検証が要るならClient Script
UI Policyでは表現できない処理、たとえば入力値から別の項目を計算する、外部データを見て警告を出すといった処理はClient Script（sys_script_client）の担当です。件数は2,585件でした。
Typeの欄でonLoad・onChange・onSubmit・onCellEditのどれかを選び、Script欄にJavaScriptを書きます。フォームを開いた瞬間に動かすのがonLoad、特定の項目が変わった瞬間に動くのがonChange、保存ボタンを押した瞬間に動くのがonSubmitです。UI Typeの欄ではDesktop・Mobile・Bothから実行対象の画面を選べます。
新規作成したClient Scriptは既定でstrict modeになっていました。DOMへの直接アクセスやjQuery・windowオブジェクトへのアクセスが制限されると、フォームの案内文に明記されています。制限を外したいときはIsolate scriptの欄を使う仕組みです。GlobalとInheritedのチェックボックスも並んでおり、どのスコープやテーブルまで効かせるかを個別に決められます。
保存の前後にサーバ側で動かすならBusiness Rule
画面の話ではなく、保存というタイミングでサーバ側の値を補正したり他のレコードと連携したりしたいときはBusiness Rule（sys_script）の出番です。件数は5,719件で、ACLに次いで多い仕組みでした。
When to runタブでは、Insert・Updateのどちらで動かすか、Filter Conditionsで対象をどう絞るかを設定します。Actionsタブに移ると、実際に動かすスクリプトを書く欄が用意されている作りです。ApplicationはGlobalが既定で、Advancedにチェックを入れるとActionsタブがスクリプト入力に切り替わり、細かい制御ができるようになります。
whenの内訳：before・after・async・displayで5,719件はどう分かれるか
Business Ruleにはwhenという設定があり、いつ動くかで種類が分かれます。
内訳はbeforeが3,441件、afterが1,456件、displayが601件、async（非推奨扱いの64件を含む）が212件でした。保存前にデータを直したり処理を止めたりするbeforeが全体の6割を占めています。飛び道具のように見えるasyncは、実際には全体の1割にも届かない少数派でした。
同じ処理を複数箇所から呼ぶならScript Include
複数のBusiness Ruleや複数のテーブルから同じ処理を呼びたいときがあります。その処理を毎回コピーするのではなく1か所にまとめる仕組みがScript Include（sys_script_include）です。件数は4,828件でした。
一覧を見ると、AbstractAjaxProcessorやAbstractDBObjectのように「Abstract」から始まる名前が並びます。他のScript Includeが継承して使う土台のクラスで、共通の処理を1か所に集める文化があらわれています。呼び出し側のBusiness RuleやClient Scriptが増えても、中身を直す場所は1つで済む設計です。無駄がありません。Applicationの列を見ると、Global以外のアプリ専用のScript Includeも見つかりました。Usage Insights Request ManagerやSchedule Pagesのように、特定アプリ名がそのまま入っている例です。
1回きりのはずが954件残るFix Script
アプリの導入やアップグレードのあとに、既存データを1回だけ直したいときに使うのがFix Script（sys_script_fix）です。件数は954件でした。
一覧には「Deduplicate Collection Items」や「Migrate Collection Items to M2M」のように、データの重複排除や移行を目的にした名前が並びます。Fix Scriptは繰り返し実行する仕組みではなく、手動またはアップグレード処理から1回呼び出す想定です。更新日の新しい順に並べると、直近まで新規のFix Scriptが作られ続けていることが分かります。
実機で気づいたこと：無効化して残す運用にはなっていない
954件のFix Scriptを確認して意外だったのは、全件がactiveのままだったことです。予想は外れました。1回きりの処理なら実行後に無効化されているだろうと考えていましたが、実機ではそうなっていませんでした。
ほかの仕組みも同じ傾向でした。ACLは43,744件中43,649件がactive、Business Ruleは5,719件中5,641件、Script Includeは4,828件中4,818件です。inactiveの割合はどれも数パーセント以下で、無効化して残すという運用は標準の状態では見当たりませんでした。
理由を考えると、Fix ScriptはUpdate Setで別環境へ運ぶ性質上、activeフラグを実行管理には使っていないのだと思います。実行済みかどうかはsys_created_onや実行履歴で判断する設計で、activeは配布対象に含めるかどうかの目印に近いと見ました。障害調査で「このFix Scriptは動いたのか」を知りたいときは、activeの値よりも実行ログを先に確認したほうが答えに近づきます。
実務では何に使えるか：依頼の言葉から書く場所を決める
依頼を受けたときに自分が最初に確認するのは、次の3点です。
誰かに見せたくない、操作させたくないという話か（権限）
画面の見た目や項目の状態を変えたいという話か（画面）
保存したタイミングで何かを起こしたいという話か（保存）
たとえば「承認欄を承認者以外には編集させないでほしい」という依頼が来たら、これは権限の話だと判断してACLを開きます。「金額が一定を超えたら承認欄を必須にしてほしい」なら画面の話で、条件と結果だけで足りるのでUI Policyから検討します。「承認時に関連する契約レコードの状態も自動で変えてほしい」なら保存の話で、Business Ruleの出番です。
権限の話ならACLです。画面の話であれば、条件と結果を組み合わせるだけで足りるかをまず確認します。足りるならUI Policy、計算や外部呼び出しが絡む場合はClient Scriptへ進みます。保存の話であればBusiness Ruleが基本形で、同じ処理を複数箇所から呼ぶ必要が出た時点でScript Includeに切り出す流れです。1回きりのデータ修正だけはFix Scriptという別枠になります。
この順番で考えると、いきなりスクリプトを書き始める前に、そもそもスクリプトが要る依頼なのかを確認できます。UI Policyで足りる依頼にClient Scriptを書いてしまうと、あとから見た人が条件を追うために毎回コードを読む羽目になりがちです。逆に複雑な計算をUI Policyだけで無理に表現しようとすると、条件の数が増えすぎて保守が難しくなります。
さらに詳しく知りたい人へ
保存の裏で動くサーバロジックとは（Business Rule） — sys_scriptのwhenとorderを詳しく見る前提知識
Client ScriptとUI Policyの違い（フォーム挙動） — 画面側2つの仕組みをさらに掘り下げた実例
ロールを付けたのに見えない理由：ACL（sys_security_acl） — ACLの構造とトラブル調査の手順
よくある質問
Q1. UI PolicyとClient Scriptはどちらを優先すべきですか
条件と結果の組み合わせだけで表現できるならUI Policyを優先します。表示・非表示・必須・読み取り専用の切り替えだけなら、スクリプトを書かずに済むUI Policyのほうが後から読む人にとって分かりやすい作りです。計算や外部データの参照が必要になった時点でClient Scriptに切り替えます。
Q2. Business RuleとScript Includeはどちらから書き始めればよいですか
最初はBusiness Ruleから書き始めて構いません。同じ処理を2つ目のBusiness Ruleや別のテーブルからも呼びたくなった時点で、その処理をScript Includeに切り出すという順番が自然です。最初から共通化を狙いすぎると、呼び出し元が1つしかない小さなScript Includeが増えてしまいます。
Q3. ACLとBusiness Ruleの前後関係はどうなっていますか
ACLは読み書きの可否そのものを判定する仕組みで、Business Ruleは値を書き換える処理です。役割が違います。ACLで書き込みが拒否されていれば、Business Ruleがどれだけ丁寧に値を設定してもレコードは保存されません。挙動がおかしいときは、まずACLで弾かれていないかを確認してからBusiness Ruleのロジックを疑う順番が効率的です。
Q4. Fix Scriptと定期実行のScheduled Scriptは何が違いますか
Fix Scriptは1回限りの実行を想定した仕組みで、Update Setに載せて他の環境へ運びます。Scheduled Script（sysauto_script）は逆に、決まった時刻や間隔で繰り返し動かす仕組みです。今回の実機ではFix Scriptが954件、Scheduled Scriptが386件登録されていました。1回で終わらせたい処理をScheduled Scriptに登録してしまうと、意図せず繰り返し実行される事故につながります。
Q5. これから新しくカスタマイズを始めるとき、まず何を確認すればよいですか
依頼が権限・画面・保存のどれに当てはまるかを最初に切り分けることです。この記事の判断フローに沿って当てはまる仕組みを1つ選び、既存の似た処理がすでにないかをその仕組みの一覧画面で検索してから書き始めると、同じ処理を二重に作る事故を防げます。
まとめ
ServiceNowで処理を書く場所は6つに整理できます。権限のACL・画面のUI PolicyとClient Script・保存のBusiness Rule・部品化のScript Include・そして1回きりのFix Scriptです。件数はACL 43,744件・Business Rule 5,719件・Script Include 4,828件でした。UI Policy 2,909件・Client Script 2,585件・Fix Script 954件も合わせて確認しています。
書く場所を選ぶときは、権限の話か、画面の話か、保存の話かという順に切り分けます。この順番さえ押さえておけば、いきなりスクリプトエディタを開く前に、そもそもスクリプトが要る依頼なのかを判断できます。
active率がどの仕組みも9割を大きく超えていた点も、実機で確認できた事実です。1回きりのはずのFix Scriptですら954件全てがactiveのままで、無効化して残すという運用は標準のServiceNowには見当たりませんでした。
用語
ACL（Access Control List） … テーブル・フィールド単位で読み書き・作成・削除・実行の可否を定義する権限ルール
UI Policy … フォーム上の項目を条件に応じて表示・非表示・必須・読み取り専用に切り替える、スクリプト不要の設定
Client Script … ブラウザ側で動くJavaScript。onLoad・onChange・onSubmitなどのタイミングで実行される
Business Rule … レコードの登録・更新・削除・照会をきっかけにサーバ側で動くJavaScript
Script Include … 複数のBusiness RuleやClient Scriptから呼び出せる、再利用可能なサーバ側の関数群
Fix Script … アプリ導入やアップグレード後にデータを1回だけ整える、使い捨て前提のサーバ側スクリプト
実機で調べるときに開いたURL
/sys_script.do?sys_id=-1 … Business Ruleの新規作成フォーム
/sys_script_client.do?sys_id=-1 … Client Scriptの新規作成フォーム
/sys_ui_policy.do?sys_id=-1 … UI Policyの新規作成フォーム
/sys_security_acl_list.do?sysparm_query=GROUPBYoperation … ACLをOperationでグループ化した一覧
/sys_script_include_list.do?sysparm_query=ORDERBYname … Script Includeの一覧
/sys_script_list.do?sysparm_query=GROUPBYwhen … Business Ruleをwhenでグループ化した一覧
/sys_script_fix_list.do?sysparm_query=ORDERBYDESCsys_created_on … Fix Scriptの一覧（更新日の新しい順）
参考リンク
公式ドキュメントの中でも、6つの仕組みの基本と実行順序に直結するものをまとめました。
検証環境と未検証範囲
件数はZurich PDI（OOTB）で確認したものです。一覧画面の件数表示を根拠にしており、推定やサンプリングではありません。本番環境やカスタマイズ済みの環境では数値が異なります。
各仕組みの実行順序や優先度の実挙動、ACLのうち何件が実際に評価されているかは確認していません。カスタム分とOOTB分の内訳も分けていません。UI Action（2,484件）とScheduled Script（386件）は件数のみ確認しました。フォームや一覧画面までは扱っておらず、この2つは別記事で取り上げる予定です。
