ServiceNowの設計書ネタ収集スクリプト

このシリーズは3本構成です
1. ServiceNowでバックグラウンドスクリプトを使用して設計書を作る方法（無料） … 調査セットの使い方を画面つきで解説
2. ServiceNowの設計書をバックグラウンドスクリプトを使用して作ったレポートの例（¥100） … 出来上がった設計書の実物
3. ServiceNowの設計書ネタ収集スクリプト（本記事・¥300）… 調査セット2ファイルの全文

このスクリプトを生成AIに添付して「カタログアイテム○○の設計書を作りたい」と伝えるだけで、要求に合わせた調査コードが返ってきます。それを Scripts - Background に貼って実行すれば、設計書の材料が数百行の表として揃います。

この記事は、その土台そのものです。Design Doc Collector v1.0 の全文（1,724行）と、集めた出力を Word 風の設計書に整えるレポート作成プロンプトを掲載します。この2つが「設計書調査セット」になります。

Update Set の取り込みも、プラグインの有効化も要りません。テキストファイルとして保存しておくだけです。

読み取り専用で作ってあります。update / insert / delete は1行も書いていません。PDI（Zurich）で3テーマ（インシデント・カタログアイテム・Service Portal）を実行し、いずれもエラー0で完走することを確認しています。

この記事に含まれるもの

• Design Doc Collector v1.0 全文（1,724行・ES5・読み取り専用）… 調査セットの①

• Word風設計書を起こすレポート作成プロンプト全文 … 調査セットの②

• 生成AIへの渡し方と、要求の伝え方

• テーマ別に設定されるパラメータ（テーブル / カタログアイテム / ポータル）

• 自分の要件に合わせて章を足すときの書き方

使い方：生成AIに添付して要求を伝える

このスクリプトは、パラメータを手で書き換えて使う道具ではありません。生成AIに読ませる土台として使います。

手順は4つです。

1. 本記事のスクリプトを 01.調査用ベーススクリプト.txt、プロンプトを 02.レポート作成プロンプト.txt として保存する

2. 生成AIに①を添付し、「ServiceNowで、カタログアイテム『Apple iPhone 13 pro』の設計書を作りたいです」のように伝える

3. 返ってきた専用版を Scripts - Background に貼って実行する

4. 出力と②を渡して「レポート作成プロンプトに従ってレポートにしてください」と指示する

②を渡す段では、AIが対象に合わせて次を行います。

• パラメータの設定 … TABLE_NAME / TARGET_MODE / 対象の識別子

• 不足している処理の追加 … 例えばカタログアイテムなら、sys_id を手で調べなくて済むよう「アイテム名から自動特定する」処理が足されます。完全一致を優先し、無ければ部分一致で候補を探し、同名が複数あれば候補一覧を出して停止する、という作りです

• ベースの制約の維持 … 読み取り専用であること、区切り表形式で出すこと、取得件数の上限を置くことは引き継がれます

実行時にエラーが出たら、その内容を生成AIに貼り付けてください。修正版が返ってきます。ServiceNow はリリースや導入済みプラグインによってテーブル構成が変わるため、環境固有の調整が要る場面もあります。その往復で吸収できます。

画面つきの手順は使い方編（無料）で解説しています。

コピペするとこれができます

まず、このスクリプトで何が手に入るかを見てください。

やることは、生成AIから受け取った専用版を Scripts - Background の入力欄に貼って実行するだけです。

数秒で結果が返ります。パイプ区切りで列が揃った表が、章ごとに並びます。

incident を対象に実行すると782行が3.3秒で出ます。その出力をレポート作成プロンプトと一緒に生成AIへ渡すと、表紙・目次つきで全7章12ページの設計書になりました。

上は第4章にあたるページです。状態遷移図・運用定義表・優先度マトリクスまで、スクリプトが集めた材料だけで組み上がっています。図の中の状態の値も、遷移の向きも、実際の設定から取ったものです。

全7章の構成はこうなりました。

• 第1章：対象範囲とテーブルの継承構造（図つき）

• 第2章：データモデル。94フィールドの定義表と参照関係

• 第3章：画面設計。フォームの4セクションを表で再現

• 第4章：業務プロセス。状態遷移図と優先度マトリクス

• 第5章：自動処理と通知。ビジネスルール76件・通知26件の内訳

• 第6章：SLAとアクセス制御。SLA14件、ACL内訳770件

• 第7章：根拠。どのテーブルから取った情報かの対応表

同じスクリプトのパラメータを変えるだけで、カタログアイテムの設計書も、Service Portal の画面設計書も作れます。出来上がった設計書の全ページはレポート例編（¥100）に載せています。

モードを変えると何が出るか

カタログアイテム（509行）では、申請画面と申請後の流れが揃います。変数の一覧は型と必須の別つきで出るため、項目定義表がそのまま起こせました。カタログクライアントスクリプトとカタログUIポリシーを見れば、どの入力に応じて何が出し分けられるかも分かります。フルフィルメントの担い手が Classic Workflow か Flow かも判別可能。ポータルでの見え方（検索非表示・カート無し・発注可否）まで拾うので、画面遷移の説明が具体的になります。

Service Portal（281行）では、ページとウィジェットの対応が取れます。基本設定から分かるのは、ホームページとログインページ、テーマ、紐づくカタログとナレッジベース。メインメニューは種別ごとにリンク先を解決するので、画面遷移図の起点になります。ページ一覧には載っているウィジェット名が畳んで並びます。ページ1つに節を割り当てる構成にすれば、そのまま画面設計書の骨格です。

どのモードでも、出力の形式は同じパイプ区切りの表です。生成AIへの渡し方を1度覚えれば、対象が変わっても手順は変わりません。3種類の設計書を別々の道具で作る必要がなくなる、というのがこの作りの利点です。

実務では、1つの案件で複数の設計書を求められることがよくあります。「インシデントの設計書と、そこから起票されるカタログアイテムの設計書を両方」といった依頼です。同じ道具で両方を集められると、章立てと用語の揺れが減ります。設計書どうしの整合が取りやすくなるのは、地味ですが効きます。

スクリプトの構造

冒頭にパラメータ、次に共通関数、そのあとに章ごとの収集処理という並びです。

生成AIが書き換えるのは、冒頭のパラメータ部だけです。以降の収集処理はそのまま引き継がれます。

共通関数のうち tableExists() と pickValidField() が、環境差を吸収します。ServiceNow はテーブルやフィールドの構成が環境ごとに変わるため、クエリを投げる前に存在を確かめてから使う作りにしました。

この設計のおかげで、導入していない機能がある環境でも最後まで完走します。今回の PDI には sys_ui_view_rule が存在しませんでしたが、該当章に「この環境に存在しません」と出力して先へ進みました。どの章が対象外だったかが出力に残るので、設計書の「扱わない範囲」がそのまま書けます。

安全側の設計

本番環境で走らせる可能性がある道具なので、次の方針で作っています。

読み取り専用。update / insert / delete / deleteRecord は一切書いていません。DRY_RUN パラメータは互換のために残していますが、更新処理そのものが存在しません。

メモリに溜め込まない。1件ずつ出力して捨てます。全件を配列に集めてから整形する書き方をしていません。重複排除用の小さなオブジェクトだけは使いますが、数百件規模で、使い終わったら null を代入して捨てます。

件数上限を全クエリに置く。setLimit を必ず付け、章ごとに MAX_* パラメータで上限を持たせています。上限に達したら出力にその旨が出るので、分割実行に切り替える判断ができます。

ES5互換。バックグラウンドスクリプトのスコープによっては新しい構文が通らないため、var と function と文字列連結だけで書いています。

0件でも黙らない。該当レコードが無い章では「（該当なし）」と明示します。出力に何も無いと、読む人は「調べていない」のか「調べた結果ゼロ」なのか区別できません。設計書のレビューで必ず突かれる部分なので、全ての章で0件時のメッセージを用意しました。

確度を明示する。テーブル名の文字列一致で拾っている章（スクリプトインクルード・スケジュールジョブ・REST連携）は、出力にその旨を書いています。確定情報と手掛かりを混ぜないためです。設計書に転記するとき、どこを個別確認すべきかが分かります。

内訳と有効フラグを添える。ACLは適用パターン別に分けて出し、Flowや通知には有効・無効の列を付けます。設計書に書くべき数字を、出力を見ただけで決められるようにするためです。合計値だけを渡すと、読む側が実態を過大に見積もります。