ServiceNowの活用度を1本のスクリプトで棚卸しする：Adoption Assessment Profiler（解説編）
「うちの ServiceNow、ちゃんと使えているんだろうか」。この問いに答えようとすると、意外なほど手間がかかります。モジュールごとに画面を開いて件数を数え、CMDB の持ち主欄が埋まっているかをリストで眺め、カタログの注文実績をレポートで作る。1週間かけて Excel にまとめた頃には、最初に見た数字が古くなっています。
この記事で解説する Adoption Assessment Profiler v1.0 は、その棚卸しを1本の Background Script にまとめたものです。Scripts - Background に貼り付けて実行すると、26モジュールの導入状況・データ量・直近利用・重要フィールドの充填率を横断調査します。そしてモジュールごとに Lv0〜Lv5 のスコアを付けた一次レポートを出力します。実行は読み取り専用です。私の PDI（Zurich）では1,013行のレポートが出ました（所要は実測6〜17秒。負荷で変動します）。
本記事は3部作の解説編（無料）です。スクリプトが「何を・どう測るか」と「安全設計」を説明します。素の Zurich PDI に実際に掛けた結果の読み解きは実行レポート編（¥100）で、スクリプト全文とカスタマイズ解説は全文編（¥300）で扱います。
この記事で分かること
1回の実行で何が出るか（26モジュール×スコア、FINDING 91件、出力1,013行の実測）
スコアモデル Lv0〜5 と、過大評価を防ぐ「スコアキャップ」の考え方
読み取り専用・ES5互換・レコード非常駐という安全設計の中身
出力を生成AIに渡して、改善バックログと次の調査スクリプトを作らせる運用
テーブル・フィールド・state 値を実機の辞書で確認済みという「道具自身の正確さ」の担保
この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースで実機確認した個人メモです。スコアの条件・しきい値はスクリプト内で調整できます。本番環境での実行は、読み取り専用とはいえ集計クエリが走るため、業務時間外を推奨します。
何を解決したいのか
ServiceNow の活用度評価が難しいのは、「入っているもの」と「使われているもの」が別物だからです。テーブルにレコードが1万件あっても、最後の作成が2年前なら、それは資産ではなく在庫にすぎません。カタログアイテムが数百件定義されていても、直近半年の注文がほぼゼロなら、それは品揃えではなく死蔵です。
手作業の棚卸しは、この「定義と利用の区別」を人間の根気に頼ります。しかも評価者によって基準がぶれます。スクリプト化する価値はここです。同じ基準で、全モジュールを、数秒で、何度でも測れるようになります。
なぜ Background Script なのか
「それ、ダッシュボードでよくない？」という疑問はもっともです。使い分けの整理をしておきます。
レポートやダッシュボードは「決まった指標を継続監視する」道具です。一方このスクリプトは「何を監視すべきかを最初に見つける」道具です。ダッシュボードを作るには、まずどのテーブルのどのフィールドが問題かを知る必要があります。その初期調査を、画面を1つも作らずに済ませるのが狙いです。
もう1つの理由は移植性です。Background Script なら、顧客環境でも検証環境でも、貼り付けるだけで同じ調査ができます。Update Set の取り込みも、レポート定義の移送も要りません。環境に何も残さない、というのがアセスメント道具として大事な性質です。
1回の実行で出るもの
出力はパイプ区切りの表形式テキストです。行頭の Section 列で行の種類が分かれます。
読み方の要点は3つです。まず MODULE_SUMMARY がモジュールの最終スコアで、一覧の主役になります。次に FINDING が問題候補です。「半数超で重要フィールドが空」「業務データだが直近作成なし」のような、改善バックログの種がここに並びます。最後に SCORE_CAP が、スコアを強制的に下げた根拠の記録です。
PDI での実測では、DETAIL 862行・FINDING 91行・SCORE_CAP 8行・合計1,013行が出ました。実行画面はこの通りです。
スコアモデル：Lv0〜5
モジュールのスコアは6段階です。
加点の材料は「テーブルが存在するか」「レコードがあるか」「直近90日の作成・完了があるか」「重要フィールドの欠落が少ないか」です。ここまでは素直な積み上げ式ですが、このスクリプトの特徴は減点側にあります。
スコアキャップ：数字の水増しを防ぐ仕組み
積み上げ式の採点には弱点があります。デモデータや過去の遺産でも「レコードあり・完了あり」になり、スコアが伸びてしまう点です。そこで、次のような強制上限（キャップ）を別レイヤーでかぶせます。
Active カタログの直近注文なし率が80%超なら、Catalog は最大2点
cmdb_ci の owned_by / managed_by / support_group 充填率が10%未満なら、CMDB は最大2点
active ユーザーの last_login_time 充填率が30%未満なら、Adoption は最大2点
pa_scores が0件（指標定義だけ）なら、Analytics は最大2点
モジュールの中核テーブル（例: SAM の cmdb_sam_sw_install）が存在しないなら最大2点
キャップが発火すると SCORE_CAP 行に理由が残るので、「なぜ2点なのか」を報告書にそのまま書けます。数字だけが独り歩きしない、というのがこの設計の狙いです。
逆方向の調整もあります。Automation は Flow の定義数だけでは最大3点に抑えますが、実行コンテキスト（sys_flow_context）で直近の実行実績が確認できたときはキャップを外します。私の PDI では直近90日で5,843件の実行が確認でき、Automation は Lv5 になりました。定義だけなら抑える、実績があれば認める、という両面の設計です。
安全設計：本番に貼っても壊さないために
Background Script は何でも実行できてしまう反面、事故の温床でもあります。このスクリプトは次の制約で書かれています。
読み取り専用。update / insert / delete は一切呼びません。使うのは GlideRecord と GlideAggregate の参照系だけです
メモリ非常駐。巨大な配列やマップにレコードを溜めません。1件処理しては捨てる方式です
ES5 互換。var と function だけで書かれ、let / const / アロー関数 / テンプレートリテラルを使いません。古いインスタンスでもそのまま動きます
大規模テーブルの自動スキップ。20万件を超えるテーブルは空欄率チェックを省略し、その旨を出力に残します
保護スコープの事前回避。HR や Legal など Restricted Caller Access で警告が出るテーブルは、既定でクエリ前にスキップします
LIMIT / OFFSET 分割。どうしても重い環境では、処理する仕様行を分割して複数回に分けられます
「読み取り専用だから安全」で終わらせず、集計クエリの負荷そのものまで制御対象にしているのがポイントです。それでも本番での初回実行は業務時間外をおすすめします。
実行前チェックリスト
実環境で走らせる前に、次の3点だけ確認してください。
権限：admin 相当で実行します。権限が足りないテーブルはエラーではなく「読取不可」として記録されるので、途中で止まることはありません
タイミング：初回は業務時間外に。2回目以降は所要時間が読めるので、日中でも判断できます
合意：スコアは「改善の会話の出発点」として使う、と関係者に先に伝えておくこと。抜き打ちの成績表として使うと、数字より先に感情が動きます
使い方：3ステップ＋生成AI
使い方は単純です。
スクリプト全文を Scripts - Background（sys.scripts.do）に貼り付ける
「Run script」を押す（グローバルスコープで実行）
出力テキストをコピーして保存する
ここからが本領です。出力はそのまま生成AIに貼る前提の設計です。末尾には GENAI_INSTRUCTION 行が付きます。「MODULE_SUMMARY をスコア昇順で並べて優先度を作る」「SCORE_CAP を根拠として採用する」といった、読ませ方の指示です。さらに各モジュールの NEXT_ACTION 行に、次に作るべき調査スクリプトのヒント（deep_dive_hint）が出ます。
出力はテキストファイルとして日付付きで残しておくと、次回の実行結果と差分が取れます。スコアが動いた理由を後から追うには、生の出力が要ります。画面のスクリーンショットだけでは、どの行のどの数字が変わったのかを突き合わせられません。四半期ごとに1本ずつ溜めていく運用が扱いやすいはずです。
つまり運用サイクルはこうなります。全体を1本で測る → 生成AIが弱点を整理する → 弱点に絞った調査スクリプトを作らせる → 再測定で改善を確認する。1回目の実行が「地図」になり、2回目以降が「進捗」になります。
仕様は実機の辞書で確認してある
このスクリプトが調べるテーブル名・フィールド名・state 値は、机上の知識で書いたものではありません。Zurich PDI の sys_dictionary（辞書）と sys_choice（選択肢）を引いて、実機に存在することを確認しています。ServiceNow はこの層の「思い込み」が起きやすいプラットフォームだからです。
例を2つ挙げます。Problem の完了ステートは New York リリース以降 101〜107 の新モデルに変わっています。そのため完了判定は、旧モデルの値も含めた stateIN4,106,107 で数える設計です。もう1つ、cmdb_ci_service の重要度フィールドの物理名は busines_criticality（sが1つ）で、OOTB のスペルがそうなっています。正しい辞書名を使わない限り、このフィールドは永久に「存在しない」扱いになります。
さらに、存在しないフィールドを指定してもエラーで落ちない設計（存在チェック内蔵・スキップして記録）になっています。実測確認と実行時チェックの二段構えなので、リリースが違う環境でもそのまま動きます。
スコアの限界も知っておく
万能の道具ではありません。このスクリプトが測れないものを先に共有しておきます。
体験の質。カタログの注文件数は数えられても、注文フォームが使いやすいかは分かりません
プラットフォーム外の運用。Excel やメールで回っている業務は、データが無いので「未利用」に見えます
数字の理由。last_login が空である理由（休眠か、SSO 構成か）は、人へのヒアリングで確定させる領域です
スコアはあくまで「どこを見に行くべきか」を絞る一次評価です。この割り切りを共有してから使うと、数字への過剰反応を防げます。
26モジュールの対象範囲
調査対象は26モジュールあります。ITSM・Knowledge・Catalog・Portal・Service Portfolio・CMDB・ITOM・CSM・HRSD・ITAM・SAM・SPM・Agile。続けて SecOps・IRM・FSM・Workplace・Legal・App Engine・Automation・Integration・Analytics・Adoption。ここに Virtual Agent・ATF・Notification を加えた構成です。
Virtual Agent・ATF・Notification を入れた意図
この3つは「プラットフォームの健康状態」を測る意図で対象にしています。Virtual Agent はトピック定義と会話実績を突き合わせます。ATF が見るのはテスト定義と実行結果です。アップグレード前の回帰テスト体制の有無がそのまま出るため、活用度評価と相性の良い領域です。Notification は通知定義の数と実際の送信量を比べます。
CMDB は「一次健診」の位置づけ
CMDB の健全性を本格的に見るなら、CMDB のテーブル構造を踏まえた Identify and Reconcile や CMDB Health の仕組みが本命です。このスクリプトの CMDB 調査は、その手前の一次健診という位置づけになります。持ち主がいない CI が何割あるかを知ってから、本格的な健全化に進む順番です。
単一テーブルの解剖モード
パラメータ TABLE_NAME にテーブル名を入れると、横断レポートの代わりにそのテーブル専用の調査モードになります。汎用のデータ品質プロファイルに加えて、辞書（フィールド定義）・参照関係（どのテーブルを参照し、どこから参照されているか）・Choice 値・Relationship・M2M 候補を一括で出します。知らないテーブルをまず解剖する、という用途にも使えるということです。
スコアの伝え方：数字は「理由つき」で出す
スコアを組織に見せるときのコツを1つだけ。Lv の数字単体ではなく、必ず SCORE_CAP の理由とセットで見せてください。「CMDB は2点です」だけでは守りの反応を招きますが、「CI の持ち主欄が1%しか埋まっていないので、上限2点になっています」なら、次にやることの議論が始まります。このスクリプトの出力が理由の行を必ず残すのは、そのためです。
運用の型：四半期の定点観測
1回測って終わりにしないための、シンプルな運用の型を紹介します。
四半期の頭に同じパラメータで実行します。LOOKBACK_DAYS を変えると数字の意味が変わるので、定点観測では固定が原則です
出力を日付付きのテキストで保存します。INSTANCE 行に環境とバージョンが残るため、後から「どの環境の数字か」で揉めません
MODULE_SUMMARY のスコアだけを前回と比べ、動いたモジュールの FINDING を読みます。全行を毎回読む必要はありません
スコアが上がらないモジュールは、キャップの理由（SCORE_CAP 行）が解消されていないということです。バックログの優先度をそこに寄せます
改善活動の報告は「頑張りました」ではなく「Catalog の死蔵率が99%から60%に下がりました」と言えるようになります。数字の定点観測は、活動の言語を変える効果があります。
3部作の残り2本
実行レポート編（¥100）：素の Zurich PDI にこのスクリプトを掛けた結果を全て読み解きます。全体平均 1.8/5、導入済み17モジュール平均 2.8/5 という数字の内訳、8件のキャップ発火、デモデータ特有の癖まで扱います
スクリプト全文編（¥300）：v1.0 の全文（2,004行）をコピペできる形で掲載し、しきい値・対象モジュール・保護スコープ設定のカスタマイズポイントを解説します
過去に公開した Instance Scan：設定の「よくない状態」を機械に探させる は「設定の健全性」を標準機能で診る話でした。本シリーズは「活用度とデータ品質」をスクリプトで診る話で、対になる内容です。データ品質を運用プロセスで維持する話は CMDBデータ認証（cert_audit） も参考になります。
まとめ
活用度評価は「定義」と「利用」の区別が肝で、手作業では基準がぶれる
Profiler v1.0 は26モジュールを読み取り専用・十数秒で横断調査し、Lv0〜5 で採点する
スコアキャップが過大評価を防ぎ、SCORE_CAP 行が「なぜその点数か」の証跡になる
出力は生成AIに貼る前提の設計で、改善バックログと次の調査スクリプトまでつながる
テーブル・フィールド・state 値は Zurich PDI の辞書・choice 実測で存在確認済み
用語
Background Script … Scripts - Background 画面から手動実行するサーバサイド JavaScript
FINDING … 問題候補の出力行。半数超の空欄、直近利用なし、完了なしなど
SCORE_CAP … スコアの強制上限とその根拠を記録する出力行
CORE_TABLES … モジュールの中核テーブル定義。存在しなければ最大2点に抑える
LOOKBACK_DAYS … 「直近利用」と見なす日数。既定90日
busines_criticality … cmdb_ci_service の重要度フィールドの物理名（OOTB のスペル）
deep_dive_hint … NEXT_ACTION 行に出る、次に作る調査スクリプトのヒント
自分の環境で確認するときのURL
/sys.scripts.do（Scripts - Background。実行画面）
/sys_dictionary_list.do（辞書。フィールドの実在確認）
/sys_choice_list.do（Choice 値。state の実値確認）
参考リンク
検証範囲とおことわり
確認した範囲：本スクリプト（v1.0）を PDI（Zurich patch6 / 2026-07-28〜29）の Scripts - Background で複数回実行し、いずれもエラー0・出力1,013行で完走（所要は実測6〜17秒）を確認。仕様のテーブル・フィールド・state 値は sys_dictionary / sys_choice の REST 実測で存在確認しています
確認していない範囲（断定しません）：本番規模データでの実行時間、ドメイン分離環境での見え方、Zurich 以外のリリースでの動作、HR / Legal など保護スコープ内テーブルの実測値（既定で事前スキップ）。スコアのしきい値はこの記事の基準であり、組織の合意で調整する前提です
スコアは改善の会話を始めるための一次評価です。監査や契約遵守の判定には、各モジュールの正式な仕組みを使ってください
活用度の議論は「感覚」で始まると紛糾し、「数字」で始まると前に進みます。まず素の状態を測るところから始めてみてください。
