ServiceNowの自動処理はどこに書く？ Business Rule / Client Script / Script Include / Flow の役割と判断基準
Critical になった Incident の割り当て先を自動で決めたい。Business Rule でも Flow Designer でも書けます。ただしこの4つは横並びの選択肢ではなく、役割の違う別々の層にあります。実行の起点、画面への応答、共通ロジック、手順のつなぎ役という違いです。4つの件数を Zurich PDI で数え、画面を開かずに Incident を2件作って動きを確かめました。
検証環境：Zurich PDI / OOTB / 2026-08-16 確認
要件の性質が決まれば、どの機能で実現するかはほぼ決まる
自動処理をどの機能で実現するべきかは、それぞれの優劣ではなく要件の性質で決まります。4つを要件の側から並べました。
その前に、標準機能の設定だけで解けないかを先に確かめます。今回の実測では、優先度と担当者の決定がその形でした（Priority Lookup と Assignment Lookup）。
Script Include だけは並びが違います。単独ではレコードの更新に反応せず、他から呼び出されて初めて動くためです。残りの3つが「いつ動くか」の層だとすれば、Script Include は「何度も使う判定をどこにまとめるか」の層になります。
この記事では「Critical になった Incident の割り当て先を決める」というデータ処理を軸に比べます。通知や承認は、後続の手順をどの機能に持たせるかという判断材料として扱います。
確認の水準も書き分けます。実機で動かして確かめたことは「実測」、製品内の定義や説明文から読めることは「仕様」、今回動かしていないことは「未検証」と書きます。
処理をどこに書くかという仕分けそのものは、ServiceNowで処理を書くならどこ？ Business Rule・Client Script・ACLの使い分けを実機の件数から考えるで整理しました。この記事はその先を扱います。候補が複数残ったとき、どれを選ぶと後で困らないかという話です。
作り込む前に、標準の設定だけで解ける要件がある
4つを比べる前に確かめることがあります。OOTB の設定で同じ結果になる要件なら、カスタム実装は作りません。1本作った時点で、レビューと移送と保守の対象がその分だけ増えるためです。
今回の要件でその役目を果たしていたのが Data Lookup でした。impact と urgency の組み合わせから優先度を決めるように、条件と結果を表で持つ標準の仕組みです。定義は Priority Lookup と Assignment Lookup の2つが最初から入っています。
Priority Lookup の定義は9行でした。impact と urgency がそれぞれ3値なので、全組み合わせに対して priority が1つずつ決まる形になっています。表に1行足すだけで結果が変わるため、スクリプトを読める人でなくても変更できます。
今回の「Critical になった Incident の割り当て先を決める」も同じです。担当者が category と subcategory から決まる範囲なら、Assignment Lookup だけで足ります。この確認で解けなかった要件だけが、次の4つの比較に進みます。
4つの機能は、それぞれ何のためにあるのか
4つはいずれもロジックを実装する側の仕組みです。動く場所と動くタイミングが違うため、要件のどこに効かせたいかで選び分けます。Business Rule から順に、どんな要求に応えるための仕組みかを整理します。
Business Rule は保存処理の中で値を確定させる
担当グループの決定を画面のフォーム側だけに書くと、夜間バッチが流し込んだ1万件には同じ規則が当たりません。画面で直した1件と一括で入った1万件で値の付き方が違えば、月次の集計はそのまま食い違います。画面からでも REST からでも、入ったデータを同じ規則で整えたい。これがここでの要求です。
Business Rule はサーバ側の保存処理そのものに割り込みます。新規作成フォームの案内文には、こう書かれています。
A business rule is a server-side script that runs when a record is displayed, inserted, deleted, or when a table is queried. Use business rules to automatically change values in form fields when the specified conditions are met.
（訳: ビジネスルールは、レコードが表示・挿入・削除されたとき、またはテーブルが照会されたときに動くサーバ側のスクリプトです。指定した条件が満たされたときに、フォーム項目の値を自動で変えるために使います）
引用元: /sys_script.do?sys_id=-1
今回の要件なら、Incident テーブルに Business Rule を1本作り、条件を Priority の変化に絞る形になります。PDI の実測では 6,202件、うち active が 6,101件でした。
いつ動くかで分けると、保存前の before が 3,730件で最多、after が 1,604件、display が 639件と続きます。このPDIでは before が最も多いという件数の事実であって、件数だけでは推奨方式までは判断できません。before と after の使い分けはServiceNowのBusiness Ruleはいつ動く？ before/after/asyncの違いを実機の件数で確認にまとめました。
Client Script は入力中の画面にその場で返す
サーバ側だけで入力チェックをすると、利用者は保存を押した後に10項目のエラーをまとめて受け取ります。入力している最中に、その欄のエラーメッセージや補完した値をその場で返したい。これが Client Script に期待する動きです。届く範囲は、ブラウザでフォームを開いている操作に限られます。
画面に出す文言そのものも判断材料の1つです。Client Script には messages 欄があり、ここに書いた文字列を getMessage で呼び出すと、翻訳が登録されている言語では利用者の設定に合わせた文言が返ります。多言語の案内やエラーを画面に出す要件では、この仕組みを使えることが Client Script を選ぶ理由になります。
ui_type の選択肢は Desktop・Mobile / Service Portal・All の3つでした。実行対象がどの画面かを選ぶ設定しか用意されていません。 REST や Import Set のような画面を持たない更新は、そもそも選択肢に入っていない作りです。件数は 2,829件で、種類別では onChange が 1,465本と最多でした。入力チェックをサーバ側とどう分担するかはServiceNowの入力チェックはClient ScriptとBusiness Ruleのどちらに書く？ 実機の件数と判断基準で扱いました。
Flow Designer は手順の並びをそのまま実行順序にする
Business Rule と Client Script の実行順序は order という数値で示されるため、順番を知るにはスクリプトを開いて数値を見比べることになります。Flow Designer は画面に並んだ手順がそのまま実行順序です。処理の順序を画面上で確認しやすく、スクリプトだけで組んだ処理よりレビューしやすい構成になります。ただし変更権限やテスト、内部アクションの実装によっては開発者の関与が要ります。
件数は 368件で、内訳は Flow が 99件、SubFlow が 267件でした。
SubFlow が Flow の 2.7倍あります。件数から言えるのはここまでで、標準の推奨構成までは読み取れません。内部が3テーブルでできていることは、Flow Designerの中身は3テーブル（sys_hub_flow）で確認済みです。トリガの種類は sys_hub_trigger_definition に16件登録されていました。
Record・Scheduled・Application の3カテゴリに分かれています。プラグインの説明は端的です。
Action plans that map a Trigger (Record, Email, REST) to an Action
（訳: トリガー（レコード・メール・REST）をアクションに対応付けるアクションプランです）
引用元: /v_plugin.do?sys_id=com.glide.hub.flow_trigger
ここは区別が要ります。この REST は、Flow を REST から直接起動するトリガ種別を指します。Table API でレコードを更新したときに Record トリガが検知するかどうかは別の仕組みで、今回は実行していません。この記事で REST 経由の実行を実測したのは、Business Rule と Data Lookup です。
Script Include は判定を1本にまとめて複数箇所から呼び出す
担当グループの決め方を Business Rule と Flow の両方に複製して書くと、ルールを見直すたびに2か所を直すことになります。Script Include に1本だけ実装して両方から同じ関数を呼び出せば、直す場所は常に1か所で済みます。単独では動かず、他から呼び出されたときだけ実行される部品です。PDI では 5,283件が登録されていました。
Glide AJAX enabled（client_callable）が true なのは 785件だけでした。残りはサーバ側からしか呼び出せません。 Client Script から呼び出したいなら、この設定を意識して作る必要があります。
切り出す合図は2つあります。呼び出し元が2か所目に増えたときと、Filter Conditions や Flow の条件ビルダーでは表現しきれない判定になったときです。2つ目は実務での判断で、件数では測っていません。
更新経路まで広げると、候補はさらに絞れる
要件の性質で第一候補が決まったら、次に更新経路を確かめます。画面からの保存だけで足りるのか、Table API の一括更新や Import Set の取り込みでも同じ結果にしたいのかで、残る候補が変わります。
経路Aが画面からの保存、経路Bが REST や Import Set からの更新です。Client Script は経路Aにしか現れません。Data Lookup と Business Rule は、経路Bでも動くことを今回実測しました。Flow Designer が経路Bで発火するかは未検証です。図の中で Data Lookup だけ角を丸くしてあるのは、作り込む4つとは層が違うからです。
11の軸で並べると、選んだ後に効いてくる違いも見えます。
移送の単位も違います。sys_script と sys_script_client と sys_script_include は、どれも Application File を継承した1レコードが定義本体です。Flow は定義と配置情報が複数テーブルに分かれます。どちらの場合も、依存する部品まで含めて移送できているかの確認が必要です。実行順序の全体像は、公式のExecution order of scripts and enginesに整理されています。
作らない判断を最初に済ませ、残りは4つの問いで決める
どの機能で実現するかは、優劣の順位ではなく問いの順序で決まります。上から順に当てはめると、必要な層だけが残ります。
最初に当てるのは「標準の設定だけで解けるか」です。解けるならカスタム実装を作らず、標準の設定で対応します。impact と urgency から priority を決める Priority Lookup が、この形の代表例です。ここで解けなかった要件だけが、次の4つの問いに進みます。
入力中の画面へ即時に返す必要があるか。あるなら Client Script で実現します。整合性の担保は別に用意します。選んだカテゴリに応じて次の項目の選択肢をその場で絞り込むような、保存を伴わない要件が該当します。
保存時に必ず守る不変条件か。そうなら Business Rule で実現します。見積金額が承認上限を超えたレコードを、画面からでも API の一括更新からでも同じ規則で弾きたい要件です。
通知や承認、待機や分岐が連なるプロセスか。そうなら Flow Designer で手順を並べます。承認待ちが3日を超えたら上長へエスカレーションし、却下されたら申請者へ差し戻すような手順を、非開発者が保守する場面に向きます。
同じ判定を複数の処理から使うか。使うなら Script Include に分離します。承認ルートを決めるロジックを、既存の Business Rule と新しく作る Flow の両方から呼び出したくなったときが切り出す合図です。
4つは重ねて使えます。層が違うためです。標準の設定で値を引き、Business Rule で不変条件を守り、Flow で後続の手順をつなぎ、共通判定を Script Include に置く構成が普通に成り立ちます。最初の判断で標準の設定に寄せた分だけ、作り込む範囲は小さくなります。
見送る合図も決めておくと、判断が属人的になりません。1つの Flow に複数の業務責務が混ざったら分割する、Business Rule の判定が条件欄で追えなくなったら Script Include へ分離する、といった線引きです。段数や行数で線を引くなら、チーム内の暫定基準だと明記しておきます。
画面を開かずに Incident を2件作って確かめた
Table API で Incident を2件作りました。ブラウザは開いていません。送った値は impact と urgency と subcategory だけです。
送っていない priority に 1 - Critical が入り、送っていない assigned_to にも値が入り、state が In Progress に変わりました。作成直後の sys_mod_count は 0 でした。少なくとも、別の明示的な更新としては記録されていません。2件目は subcategory を送らずに作ったところ、assigned_to は空のままでした。
priority を決めていたのは Priority Lookup、担当者を決めていたのは Assignment Lookup で、どちらも Data Lookup です。state を変えていたのは Incident State Active on Assignment という名前の Business Rule でした。
Advanced のチェックが外れています。このルールはスクリプトを1行も持っていません。 条件と Actions タブの設定値だけで動いていました。
この2件で確かめられたのは、フォームを開かない Table API 経由の作成でも Data Lookup と Business Rule が動くことです。Client Script はこの経路に現れません。Flow と Import Set は今回未検証です。
表の「仕様」は、製品内の定義や説明文から読める範囲を指します。実際に動かして確かめたのは1行目だけです。
実機を見て気づいたこと
ノーコードの Flow の内部は、63%がスクリプトだった
Flow Designer をノーコードの仕組みだと思って調べ始めました。アクションの内部ステップを保持する sys_hub_step_instance は 1,832件あり、うち Script が 1,159件で 63.3% でした。
さらに Script ステップの本文を読み取り、new で生成しているクラス名を Script Include 名と突き合わせると、649件が Script Include を呼び出していました。Script ステップの 56% です。専用のプラグインも用意されています。
Provides an action step to execute custom JavaScript within a reusable action.
（訳: 再利用可能なアクションの中でカスタムJavaScriptを実行するアクションステップを提供します）
引用元: /v_plugin.do?sys_id=com.glide.hub.action_step.script
件数はこのPDIでの事実であって、公式の推奨構成を示すものではありません。それでも、Flow は手順の可視化には向く一方で、内部の実装まで非開発者だけで保守できるとは限らないと分かります。どのクラスが多く呼ばれているかという分析は、この記事では扱いません。
Business Rule はスクリプト無しでも作れる
Business Rule はコードを書く仕組みだと思っていましたが、active な 38件はスクリプトを持たず、条件と設定値だけで動きます。実際に state を In Progress へ変えたのが、その1本でした。「Flow はノーコード、Business Rule はコード」という切り分けは、実機の姿とずれています。
標準は自動アサインを表引きで解いていた
今回作った1件目で担当者を決めていたのは Assignment Lookup でした。自動アサインという要件に対して、標準はスクリプトを書かずに対応表で答えを出しています。4つを比べる前に標準の設定で解けるかを確かめる順番にしたのは、この観察が理由です。
実務では何に使えるか
既存の自動処理を棚卸しする順番
「この値がどこで変わったか分からない」という調査は、画面からの保存にも REST からの更新にも動作する仕組みから順に見ると早く終わります。最初に Data Lookup と Business Rule をテーブルで絞り、次に Flow のトリガを確認し、最後に Client Script を開く。逆から始めると、その経路では動かない仕組みを延々と読むことになります。Script Include は単独で動かないので、呼び出し元を先に特定してから開きます。
101本目だけ別の仕組みにするかは、既存の並びで決める
同じテーブルに Business Rule が100本並んでいるところへ、101本目だけを Flow で作ると、次に調査する人は2つの場所を見ることになります。理論上の最適解を選ぶより、既存の並びに合わせたほうが探す手間は小さい。新しい仕組みへ寄せたいなら、1本だけ差し替えるのは避け、そのテーブルの処理をまとめて移す計画を先に立てます。
レビューで確認する6点
設計レビューで自動処理が出てきたら、次の6点を聞くと判断が早くなります。答えごとの進み先と、確認する画面のURLを並べました。
先頭の1問を独立させているのは、標準の設定で済む要件を4つの仕組みで作り込む事故を避けるためです。標準の Assignment Lookup がその実例になります。
用語
Business Rule：レコードの読み書きをきっかけにサーバ側で動く仕組み。実体は sys_script。
Client Script：ブラウザ側で動く JavaScript。onLoad / onChange / onSubmit / onCellEdit のタイミングがある。実体は sys_script_client。
Script Include：他のスクリプトから呼び出す再利用部品。単体では動かない。実体は sys_script_include。
Flow Designer：トリガとアクションの並びを画面で組み立てる仕組み。実体は sys_hub_flow で、部品は別テーブルに分かれる。
Data Lookup：条件の組み合わせから値を引く表。Priority Lookup と Assignment Lookup が標準で入っている。
client_callable：Script Include を Client Script から呼び出せるようにする設定。画面上の表示は Glide AJAX enabled。
自分の環境で確認するときのURL
管理者として開くと、この記事と同じ画面を確認できます。
Business Rule を実行タイミングで分ける：/sys_script_list.do?sysparm_query=GROUPBYwhen
スクリプトを持たない Business Rule：/sys_script_list.do?sysparm_query=active%3Dtrue%5EscriptISEMPTY
Client Script の実行対象画面の選択肢：/sys_choice_list.do?sysparm_query=name%3Dsys_script_client%5Eelement%3Dui_type
Script Include を Glide AJAX enabled で分ける：/sys_script_include_list.do?sysparm_query=GROUPBYclient_callable
Flow を種別で分ける：/sys_hub_flow_list.do?sysparm_query=GROUPBYtype
Flow のトリガ定義一覧：/sys_hub_trigger_definition_list.do?sysparm_query=ORDERBYname
アクション内部のステップを種別で分ける：/sys_hub_step_instance_list.do?sysparm_query=GROUPBYstep_type
条件と値の対応表の定義：/dl_definition_list.do
引用した公式説明を自分で開く
この記事で引用した英文は、ServiceNow が製品に同梱している説明です。次のURLを自分のインスタンスで開くと、同じ記述を確認できます。
プラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=idSTARTSWITHcom.glide.hub%5EdescriptionISNOTEMPTY
Business Rule の案内文（引用元）：/sys_script.do?sys_id=-1
Client Script の messages 欄の説明（引用元）：/sys_documentation_list.do?sysparm_query=name%3Dsys_script_client%5Eelement%3Dmessages
検証範囲とおことわり
件数と挙動は Zurich の PDI（OOTB）で 2026-08-16 に確認した値です。プラグインの導入状況で件数は変わるため、本番環境では別の数字になります。
実機で動かしたのは Incident の作成2件だけです。short_description に 記事検証: を付けたレコードで、設定は1つも変更していません。インスタンスの外への通信も行っていません。
「この要件ならこう書く」として示した実装は、製品内の定義と説明文から組み立てた設計です。4つの機能を実際に作って動かしたわけではありません。実行して確かめたのは、Table API 経由の作成で Data Lookup とスクリプト無しの Business Rule が動くことだけです。
Flow のトリガが REST 経由や Import Set 経由の更新で発火するかは、今回は実行していません。トリガ定義に Record と REST がある点は確認済みで、発火そのものは未検証です。
Script ステップの本文と Script Include 名の突き合わせは、new に続く識別子で判定しました。文字列で組み立てて呼び出す書き方は数えていないため、実際の呼び出しは 649件より多い可能性があります。
Business Rule と Flow が同じテーブルに同居したときの前後関係は測っていません。UI Policy・ACL・Scheduled Job といった他の仕組みも、この記事では扱っていません。
参考リンク
関連記事
ServiceNowで処理を書くならどこ？ Business Rule・Client Script・ACLの使い分けを実機の件数から考える — 前提知識として、そもそもどの仕組みの担当かを仕分ける
ServiceNowの入力チェックはClient ScriptとBusiness Ruleのどちらに書く？ 実機の件数と判断基準 — 次に読むなら、入力チェック1用途に絞った比較
Flow Designerの中身は3テーブル（sys_hub_flow） — 実務編として、Flow の内部構造をたどる
