ServiceNowのBusiness Rule・Script Include・Flowを一括棚卸しする読み取り専用スクリプト

引き継いだServiceNowのインスタンスに、Business Ruleが何本あるか、その場で即答できるでしょうか。担当者が変わるたびに全体量の把握が引き継がれず、感覚だけで「多い」「重い」と語られる状態が続きます。

Business Rule・Script Includeなど9種類のテーブルを、スコープ・更新日・稼働状況の3観点で横断集計すると、この不安は数字に置き換えられます。Zurich PDIで確認すると、Business Ruleは5,719件のうち88%がGlobalスコープに集中し、4,281件が2年以上更新されていませんでした。9種類を一度に数える読み取り専用スクリプトを有料部に収めています。

この記事で分かること

• スクリプト資産（Business Rule・Script Includeなど）の種類とスコープの基本

• 実機画面で確認した、Business Ruleのスコープ別内訳とFlow Designerへの移行状況

• 9種類のテーブルを横断集計する読み取り専用スクリプトの全文と使い方（有料部）

• 集計結果から棚卸しの優先順位を組み立てる考え方（有料部）

公式ドキュメントで押さえる基本

画面やスクリプトを見る前に、用語を公式ドキュメントで揃えておきます。

スクリプト資産にはどんな種類があるか

ServiceNowでカスタマイズを加えると、その内容はいくつかの種類のテーブルにレコードとして残ります。代表的なのは Business Rule です。レコードの登録・更新・削除をきっかけに動くサーバー側スクリプトです。もう1つの代表格が Script Include で、複数のBusiness RuleやFlowから呼び出せる再利用可能な関数群を指します。画面の見た目や項目の必須・読み取り専用を切り替える Client Script や UI Policy も、広い意味でのスクリプト資産です。ボタンを追加する UI Action、時刻になると自動実行される Scheduled Job も同様に含まれます。定義は公式ドキュメントに一次情報があります（Business Rules / Script Includes）。

スコープとは何か

スコープは、カスタマイズの置き場所を区切る単位です。ServiceNowには大きく Global スコープと、Scoped Application（アプリケーションスコープ）の2種類があります。Globalはアプリケーションの外側にある共通の置き場所で、スコープドアプリケーションを作らずに直接カスタマイズを足していくと、多くの場合ここに積み上がります。公式ドキュメントでは、アプリケーションスコープをレコードやコードを隔離し、他のアプリケーションへの影響を防ぐ仕組みとして説明しています（Application scope）。

Flow Designerは旧Workflowと何が違うか

自動化の仕組みにも歴史があります。旧世代の Workflow（wf_workflowテーブル）は、図形をつないで処理を組み立てるエディタで、ServiceNowの初期から使われてきました。後継として登場した Flow Designer は、トリガーとアクションを並べて自動化を組み立てる基盤です（Flow Designer Architecture Overview）。旧Workflowのエディタは、現在はレガシー扱いのドキュメントに置かれています（Workflowエディタ（レガシー））。

実機で確かめる

ここからは、公式ドキュメントで押さえた用語を実機の画面に当てはめて確かめます。

Business Ruleをスコープ別に見る：Globalが88%

Business Ruleの一覧画面をApplicationでグループ化すると、インスタンス全体の総数と、アプリケーションごとの内訳が同時に見えます。

総数は5,719件です。Advanced Approval Managementが26件、Change Management - CAB Workbenchが31件です。個別のスコープドアプリケーションは、このように数十件規模にとどまります。残りの大半は、アプリケーションの外側にあるGlobalスコープへの集約です。上位8スコープを数えると、次の内訳になります。

Globalが5,024件で全体の88%を占めます。2位のGoal Frameworkでも53件ですから、規模の差は一目瞭然です。GlobalスコープにはOOTB（標準機能）のBusiness Ruleも数多く含まれるため、この数字だけでカスタマイズの量を断定はできません。それでも、棚卸しをどこから始めるべきかは、この時点でかなり絞り込めます。

Flow Designerへの移行：旧Workflowは0件

自動化の仕組みも画面で数えられます。Flow Designerの一覧を開くと、定義済みのFlowが表示されます。

総数は345件です。一方で旧Workflowの一覧を開くと、様子が違います。

該当レコードが1件も無いという表示です。旧WorkflowからFlow Designerへの移行が完了していることを、画面だけで確認できました。

Flowは実際に動いているか

定義の件数だけでは、作っただけで使われていない機能を見逃します。Flowが呼び出されるたびに記録が残るのが Flow engine contexts（sys_flow_context）です。作成日時の新しい順に開くと、実行の様子が見えます。

send_notificationsというFlowが、数分おきに繰り返し実行されている記録が並びます。ログに残っている件数を数えると、次のようになりました。

Flow Designerは345件（active 310件）、旧Workflowは0件、そしてログに残っている実行コンテキストの合計は8,110件でした。定義されているだけでなく、実際に日常的に呼び出されている基盤だと確認できます。

購入すると何が手に入るか

ここまでは、画面を1つずつ開いて確かめた内容です。ですが確認できた観点は、Business Ruleのスコープ・Flowの定義・旧Workflowの3つにとどまります。スクリプト資産は全部で9種類あり、同じ「2年以上更新されていない」という基準ですべてを横断するには、画面のフィルタだけでは手が足りません。

有料部には、次を収録しています。

• 9種類のテーブルを1回のScripts-Background実行で横断集計する、読み取り専用スクリプトの全文（update・insert・delete は一行もありません）

• 実行結果のスクリーンショットと、資産の種類ごとに未更新率が大きく異なる実測データの読み解き

• wf_workflowで実際に出た警告と、GlideAggregateが存在しないフィールドでも止まらない理由

• 実機で気づいたこと3点、集計結果から棚卸しの優先順位を組み立てる考え方、よくある質問6問

コピーしてそのまま自分のインスタンスで実行できる分量です。