共通ロジックをまとめて呼ぶ（Script Include）

2026年6月22日 20:14

ServiceNow で Business Rule や Flow を書いていると、同じようなサーバサイド処理を何度も書きたくなる場面があります。そのとき「共通ロジックを1か所にまとめて、あちこちから呼びたい」という置き場所になるのが Script Include（sys_script_include） です。

この記事では、Script Include を機能論だけで説明しません。実際の sys_script_include テーブルを起点に、再利用ロジックがどのフィールドで定義され、どこから呼ばれるかを確認します。スコープの可視性（access）やクライアント呼び出し可否（client_callable）がどう決まるのかも、PDI（Zurich）の OOTB で確認した実測値とともに示します。

この記事は、ServiceNow の Incident や Business Rule は触ったことがあるが、Script Include の裏側のテーブル構造をこれから理解したい人を想定しています。管理者・開発者が実機で確認するときに見るべきポイントは、sys_script_include の継承と主要フィールド、client_callable と access（スコープ）です。あわせて、呼び出し関係も順に確認します。

この記事で分かること

Script Include の実体が sys_script_include（1クラス＝1レコード）に保存されること
sys_script_include が sys_metadata（Application File）を継承する「メタデータ系」であること
主要フィールド（name / api_name / script / access / client_callable）の役割
client_callable と access の実測分布（client_callable=true 729件、public 1,837件など）
Business Rule / Flow からの「サーバ呼び出し」と、Client Script からの「GlideAjax 呼び出し」の違い
実機で確認するときに見るべき一覧URL

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

Script Include とは

Script Include とは、再利用できるサーバサイド JavaScript（関数・クラス）を1か所にまとめて登録しておく仕組みです。Business Rule・Flow・別の Script Include などから呼び出せます。同じコードを各所にコピペする代わりに、共通ロジックを Script Include に置いて呼び出します。

その共通ロジックを格納する中心テーブルが sys_script_include（画面上のラベルは Script Include）です。1つのクラス（ユーティリティ）に対して1レコードが作られ、クラス名・呼び出し名・スクリプト本体・可視性などを保持します。今回確認した PDI（Zurich / OOTB）では、sys_script_include には 4,683 件の Script Include がありました。うち active=true が 4,673 件（inactive は10件）でした。

呼ばれて初めて動くライブラリ

ポイントは、Script Include は処理の「置き場所」であって、それ自体が自動で動くわけではないという点です。Business Rule のように保存をきっかけに走るのではなく、誰か（別のサーバコードやクライアント）が呼んで初めて実行されるライブラリ的な存在です。だから Script Include を読むときは、「何が定義されているか」と「どこから呼ばれるか」をセットで見る必要があります。

sys_script_include の継承（メタデータ系の基底）

sys_script_include のまわりの継承関係を見ると、task 系（incident など）とはまったく別の系統に属していることが分かります。

今回確認した PDI（Zurich / OOTB）では、sys_script_include は sys_metadata を継承していました。sys_metadata は Application File（アプリケーションファイルの基底）です。sys_metadata は super_class が空のルート基底です。Business Rule（sys_script）や Client Script（sys_script_client）も同じ sys_metadata 系に属します。Script Include は「業務データ」ではなく「設定（メタデータ）」の一種として管理されます。

この点は実務で効いてきます。sys_metadata 系のレコードは Update Set に乗る対象であり、開発インスタンスで作った Script Include を本番へ移送できます。Incident のような業務データとは扱いが違う、という前提を押さえておくと、Script Include を「コード資産」として管理する感覚がつかめます。

テーブル定義は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=sys_script_include

sys_script_include の主なフィールド

sys_script_include は、「何という名前で・どんなロジックを・誰がどう呼べるか」を表す項目を持ちます。役割で分けると、識別・ロジック・呼び出し可否・可視性／制御・説明に整理できます。今回の PDI では 固有フィールドは11 でした。

主なフィールドの代表は次のとおりです。ラベルは画面上の表示名で、実機どおり記載します。

「呼び出し名（api_name）」「ロジック本体（script）」「呼べる範囲（access / client_callable）」が1レコードに揃っています。特に api_name は、実測では <scope>.<name> の形式（例 global.IncidentUtils）です。どのスコープのどのクラスを呼ぶかを一意に表します。Script Include を呼ぶ側のコードは、この名前で new してメソッドを呼びます。

代表例：IncidentUtils

代表例として、Incident 関連の共通処理をまとめた IncidentUtils の実画面を見ます。Name・API Name・Accessible from・Active・Description・Script 本体が1フォームに並んでいます。

この IncidentUtils は var IncidentUtils = Class.create(); から始まります。prototype にメソッドを定義する、ServiceNow で典型的な Script Include の書き方です。Description には「IncidentUtilsSNC を継承した、顧客が上書き可能なクラス」と書かれています。OOTB のロジックをそのまま使いつつ、必要なら上書きできる設計であることが読み取れます。

全フィールドは、次のURLで一覧できます。

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

公式の Script includes（Zurich）に、Script Include が再利用サーバサイドスクリプトであること、client callable や accessible from の意味が説明されています。

どこから呼ばれるか（サーバ呼び出しと GlideAjax）

Script Include はライブラリなので、呼び出し元がいて初めて意味を持ちます。呼び出し元は大きく「サーバ側」と「クライアント側」の2系統に分かれます。

サーバ側とクライアント側、2つの経路

サーバ側から … Business Rule（sys_script）・Flow Designer のアクション・Scheduled Job が対象です。ほか、別の Script Include などのサーバコードも含みます。new <Class>() でインスタンス化してメソッドを呼びます。参考までに、今回の PDI では Business Rule（sys_script）が active で 5,422 件 存在します。これらサーバコードの一部が Script Include を呼びます。
クライアント側から … Client Script は、client_callable=true の Script Include を GlideAjax で非同期に呼びます。クライアントから直接サーバ DB を触る代わりに、サーバの Script Include に処理を任せて結果だけ受け取る、という使い方です。

注意したいのは、Script Include 単体を見ても「誰が呼んでいるか」はテーブルからは分からない点です。呼び出し関係は各 Business Rule / Flow / Client Script のスクリプト本文に書かれているため、本記事ではその紐付け件数は数えていません（検証範囲外）。実機で追うときは、対象クラス名で全スクリプトを検索するのが基本になります。

公式の GlideAjax - Client（Zurich）に、クライアントから client callable な Script Include を呼び出す GlideAjax API が説明されています。

クライアントから呼べるか（client_callable）

クライアント（ブラウザ）から呼べるかどうかは、client_callable フラグ（画面ラベル: Glide AJAX enabled）で決まります。

今回確認した PDI（Zurich / OOTB）の分布は次のとおりでした。

client_callable=true … 729 件（GlideAjax でクライアントから呼べる）
client_callable=false … 3,923 件（サーバ内専用。残り約31件は値未設定）

つまり大多数（約8割）はサーバ内専用で、クライアントから直接呼べるのは一部です。これはセキュリティ上の理由で、チェックを入れていない Script Include はブラウザの開発者ツールから勝手に呼べないようにしているためです。GlideAjax で呼びたい Script Include だけ、明示的に client_callable を有効にします。

似た性質のフラグとして mobile_callable（モバイルアプリからの呼び出し）と sandbox_callable（スクリプトサンドボックスからの呼び出し）もあります。今回の PDI では mobile_callable=true が2件、sandbox_callable=true が298件でした。

client_callable な Script Include には実例があります。代表が AbstractAjaxProcessor（GlideAjax 用 Script Include の基底クラス）です。GlideAjax で呼ばれる Script Include は、この AbstractAjaxProcessor を継承します。クライアントから渡されたパラメータを受け取って結果を返す、という形です。

client_callable な一覧は、次のURLで確認できます。

https://<YourInstance>/sys_script_include_list.do?sysparm_query=client_callable=true^ORDERBYname

どこから呼べるか（access＝スコープ可視性）

クライアントからの呼び出し可否とは別に、どのアプリケーションスコープから呼べるかを決めるのが access（画面ラベル: Accessible from）です。

今回確認した PDI（Zurich / OOTB）の access は、次の2値でした（value = label）。

public（All application scopes）… 1,837 件 … 他のアプリスコープからも呼べる
package_private（This application scope only）… 2,843 件 … 自分のアプリスコープ内からのみ呼べる（既定値）

package_private が既定、他スコープには一手間

ポイントは、access の既定が package_private（自スコープのみ）だという点です。スコープアプリで新規作成した Script Include は、何もしなければそのアプリの中だけで使えるロジックになります。別スコープから呼びたい場合は public にするか、Cross Scope Privilege（sys_scope_privilege）で許可を与える必要があります。global スコープの Script Include は実測で 2,865 件あり、OOTB の多くは global に置かれていました。

なお、public かつ client_callable でもあった Script Include は269件でした。GlideAjax 越しに複数スコープから広く呼ばれることを想定したユーティリティは、スコープをまたいで公開されているケースが一定数あります。

なお、access は最初の保存時に決めると後から変えにくくなる（読み取り専用になりやすい）ため、作成時にスコープ可視性を意識しておくのが実務上のコツです。

自分のインスタンスでは、次のURLで access ごとに絞り込めます。

public        : https://<YourInstance>/sys_script_include_list.do?sysparm_query=access=public
package_private: https://<YourInstance>/sys_script_include_list.do?sysparm_query=access=package_private

別スコープから Script Include を呼ぶには Cross Scope Access の許可が要ります。設定方法は公式にまとまっています。

Define cross-scope access to an application resource（Zurich）

Script Include まわりの件数（実測サマリ）

ここまでに見た分布を、ひとつの表にまとめます。すべて今回の PDI（Zurich / OOTB・2026-06-20 確認）の実測値です。

注意したいのは、ここで数えているのは PDI の OOTB に最初から入っている Script Include が中心だという点です。実環境では、各社が作った業務ロジックや、インストールしたアプリ由来の Script Include が大量に加わります。件数そのものより、「public は少なめ・package_private が既定」「client_callable はごく一部」という比率の傾向を押さえるのが役立ちます。

ServiceNow における Script Include のポイント

Script Include の実体は sys_script_include（Script Include） に「1クラス＝1レコード」で保存されます。今回の PDI では 4,683 件、うち active 4,673 件でした。
sys_script_include は sys_metadata（Application File）を継承するメタデータ系です。Incident のような業務データではなく、設定（Update Set 対象のコード資産）として扱われます。固有フィールドは11でした。
中心フィールドは name / api_name（例 global.IncidentUtils）/ script / access / client_callable。api_name は <scope>.<name> 形式で呼び出し名を一意に表します。
呼び出し元は2系統です。1つはサーバ側（Business Rule / Flow / 別の Script Include）が new で呼ぶ場合です。もう1つはクライアント側が GlideAjax で client_callable な Script Include を呼ぶ場合です。
client_callable は実測で true 729 / false 3,923。大多数はサーバ内専用で、クライアントから呼べるのは一部だけ（セキュリティのため明示有効化）。
access は public 1,837 / package_private 2,843。既定は package_private（自スコープのみ）で、別スコープから使うには public 化か Cross Scope Privilege が必要です。

Script Include を調べるときは、まず「このクラスは何（api_name）で、どこから呼べる（access / client_callable）ロジックか」を読みます。そのうえで、sys_script_include 単体ではなく、呼び出し元の Business Rule / Flow / Client Script をセットで見ます。

実機を見て気づいたこと

description（説明欄）が入っていた Script Include は 2,398件で、全体の半数程度にとどまっていました。呼ばれて初めて動くライブラリ的な存在だからこそ、呼び出す側は名前（api_name）だけを頼りに中身を探すことになりやすい、と実感しました。
client_callable のほかに mobile_callable・sandbox_callable・caller_access という、呼び出し元を限定する細かいフラグが複数用意されていました。ただし実際に設定されていたのは mobile_callable が2件、caller_access が60件とごくわずかで、大半は client_callable の有無だけで運用されているとわかりました。
IncidentUtils のようなアプリ固有のユーティリティだけでなく、JSUtil・ArrayUtil のような汎用ユーティリティも global スコープに置かれていました。共通処理をどこに置くか迷ったら、まず global 公開のユーティリティ系 Script Include を探すのが実務では早道だと感じました。

次に読むなら

次に確認するなら3つあります。1つ目は、client_callable な Script Include と Client Script を結ぶ GlideAjax の呼び出し方です。実装は getParameter / AbstractAjaxProcessor です。2つ目は、Cross Scope Privilege（sys_scope_privilege）によるスコープ越えアクセスです。3つ目は、Zurich で導入された Script Writer 権限（admin でもスクリプトを書くには別権限が要る）です。特に「サーバに置いたロジックを、誰が・どこから安全に呼べるか」を access / client_callable / cross-scope の3点で押さえると効果的です。スコープアプリの設計が一気に見通せます。これらは本記事の「どこから呼ばれるか」「access」で触れた仕組みの先にあたり、別記事で解説する予定です。

用語

PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
Script Include（sys_script_include）：再利用サーバサイドロジックのレコード（1クラス＝1件）
api_name：スコープ付き呼び出し名（<scope>.<name>、例 global.IncidentUtils）
client_callable（Glide AJAX enabled）：GlideAjax でクライアントから呼べるか
access（Accessible from）：呼べるスコープ範囲（public / package_private）
GlideAjax：Client Script から client_callable な Script Include を非同期に呼ぶ仕組み
sys_metadata（Application File）：Script Include を含むメタデータの基底（Update Set 対象）

自分の環境で確認するときのURL

先頭に自分のインスタンスを付けると、同じ画面が開けます。

テーブル定義     : sys_db_object_list.do?sysparm_query=name=sys_script_include
Script Include 一覧: sys_script_include_list.do?sysparm_query=active=true^ORDERBYname
フィールド一覧    : sys_dictionary_list.do?sysparm_query=name=sys_script_include^elementISNOTEMPTY
client_callable   : sys_script_include_list.do?sysparm_query=client_callable=true^ORDERBYname
public 一覧       : sys_script_include_list.do?sysparm_query=access=public

検証範囲とおことわり

確認した範囲：sys_script_include の階層（→sys_metadata）、固有フィールド数（11）と一覧、access / caller_access の選択肢です。加えて、client_callable / access / scope / active の件数分布、api_name の形式も確認しました。実レコード例（IncidentUtils / AbstractAjaxProcessor 等）も確認しています。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています。
確認していない範囲（断定しません）：個々の Script Include の内部スクリプトの挙動です。ほかに、どの Business Rule / Flow / Client Script がどの Script Include を呼ぶかの紐付け件数、Cross Scope Privilege（sys_scope_privilege）の実レコードも確認していません。ほかに、Zurich の Script Writer 権限の運用、各スコープアプリ固有の Script Include も確認していません。これらは別記事で扱います。

今回は PDI の OOTB（初期設定）を前提に、Script Include の構造を確認しました。実環境では、既存のカスタマイズや導入アプリによって Script Include の数・内容が大きく変わります。