ServiceNowの設計書をバックグラウンドスクリプトを使用して作ったレポートの例

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

バックグラウンドスクリプトで設定を集めて、生成AIに渡す。この方法で設計書がどこまで書けるのかを、出来上がった実物でお見せします。

掲載するのは3本です。インシデント管理のモジュール設計書が全12ページ、Service Portal の画面設計書が全11ページ、カタログアイテムの設計書が全8ページ。いずれも全ページを画像で載せます。渡したのはスクリプト出力とレポート作成プロンプトだけです。

書けたのは、章立ても図表も揃った設計書でした。項目定義表・状態遷移図・画面構成表・優先度マトリクス。そして最終章には、次に着手すべき事項の一覧まで載ります。現状の記録と、これからやることが1冊にまとまります。

この記事で分かることは次のとおりです。

• インシデント管理のモジュール設計書 全12ページを、無料部分で全て載せます。

• Service Portal の画面設計書 全11ページのうち、7ページ目までを無料で載せます。

• カタログアイテムの設計書 全8ページも載せます。

• 対象の種類ごとに章立てがどう変わるかを、テーブル／ポータル／カタログアイテムの3例で示します。

• 設計書の最終章に載る「推奨する対応事項」の中身も紹介します。

3テーマを同じスクリプトで流す

変えたのは冒頭のパラメータだけです。スクリプト本体は3回とも同一です。

いずれも2秒以内に終わりました。メタデータへの問い合わせが中心で、業務データの全件走査をしていないためです。

例1：インシデント管理 モジュール設計書（全12ページ）

TARGET_MODE = 'table'、TABLE_NAME = 'incident' で実行した782行から起こした設計書です。全7章、表紙・目次を含めて12ページになりました。

表紙と目次

目次は章と節のレベルまでに留め、1ページに収めています。項まで入れると2ページに溢れ、全体像がつかみにくくなるためです。

第1章：対象範囲とテーブルの継承構造

incident が task を継承していること、同じ親を持つ problem と change_request があることを図にしました。「共通項目の変更は3テーブル全てに波及する」という、改修見積りの前提になる話です。

カスタムフィールドは0件でした。この環境は素の状態であり、設計書は標準機能の説明が中心になります。

第2章：データモデル

94フィールドのうち incident 由来が25件、task 由来が69件でした。項目の7割強が親テーブル由来という数字は、そのまま影響範囲の話につながります。

参照関係の表では、rfc（この障害を直すために起こした変更）と caused_by（この障害を引き起こした変更）を区別して書きました。方向が逆なので、集計時に混同すると意味が変わります。

第3章：画面設計

スクリプトはフォーム構成をアスキーアートで出します。

セクションの区切りと、左右2列のどちらに何が置かれているかがそのまま読み取れます。ラベルと物理名が対で出るので、設計書の画面定義表に起こすときに調べ直しが要りません。

これが設計書ではこうなりました。

画面制御について、設計書に書くべき事実がもう1つ取れました。

フォーム上で Priority は編集できません。 そしてその実装箇所は、テーブル定義ではありません。sys_dictionary の read_only は 0 です。編集不可にしているのは、「Priority is managed by Data Lookup - set as read-only」という名前のUIポリシーでした。

スクリプトはテーブル定義とUIポリシーの両方を集めるため、この対応関係がそのまま設計書に書けます。改修時に「どこを直せば編集可能になるか」を追う手間が省けます。

第4章：業務プロセス

状態は6種類（1・2・3・6・7・8）で、4と5は欠番です。Classic Workflow による自動遷移は 0件でした。状態は担当者の操作（UIアクション53件）で進みます。この事実を押さえずに「ワークフローで自動遷移します」と設計書に書いてしまう事故は、実際によく見ます。

優先度の算出方法も追いかけました。影響度と緊急度の組み合わせは Data Lookup という仕組みで管理されていて、対応表は dl_u_priority テーブルに9行として入っています。実測した9行がこれです。

• 影響度1 × 緊急度1 → 優先度1（Critical）。

• 影響度1 × 緊急度2 → 優先度2、影響度1 × 緊急度3 → 優先度3。

• 影響度2 × 緊急度1 → 優先度2、影響度2 × 緊急度2 → 優先度3、影響度2 × 緊急度3 → 優先度4。

• 影響度3 × 緊急度1 → 優先度3、影響度3 × 緊急度2 → 優先度4、影響度3 × 緊急度3 → 優先度5。

設計書ではこれを3×3のマトリクス表にしました。

第5章：自動処理と通知

incident をトリガーとする Flow は14件見つかりましたが、有効なのは1件だけでした。残り13件は JIRA連携・Teams通知・Zoom会議作成といった、初期状態で無効のまま同梱されているテンプレートです。「Flowが14件ある」と「14件の自動処理が動いている」は別の話なので、設計書には有効・無効を分けて書きます。

通知は26件。1つ注意が要る点があります。Comment left on incident と Incident commented for ITIL は、どちらも incident.commented を契機にしています。前者は申告者へ、後者は担当者へ。つまり1回のコメント追記で2通のメールが飛びます。

第6章：SLAとアクセス制御

ACLは内訳つきで出しています。

管理画面のタブに出る件数はワイルドカード（* と *.*）を含むため大きくなります。設計書に「このモジュールのアクセス制御」として書くべきは、固有分と継承分を合わせた141件のほうです。

SLAは14件を種別ごとに整理して載せました。優先度に紐づくものが9件、社内チーム間の取り決め（OLA）が2件、外部委託先との契約に基づくもの（Underpinning Contract）が1件、自動テスト用が2件です。

優先度別の目標時間は次のとおりでした。優先度1が初回応答15分・復旧1時間。優先度2が1時間・8時間。優先度3が4時間・1日。優先度4が8時間・2日。優先度5は初回応答40時間の定義のみで、復旧側は運用開始までに決める項目として最終章に送っています。

種別を分けて書くと後が楽になります。顧客と約束するSLAと、社内チーム間のOLAと、委託先との契約は、達成率の集計単位が違います。自動テスト用の2件も、集計から外すかどうかを運用側で決めておく対象になります。設計書で分類しておくと、後から「この数字は何を測っているのか」で揉めません。

第7章：参照

どのテーブルから取った情報かを章ごとに対応づけています。半年後に「この数字はどこから？」と聞かれて答えられる状態にしておくためです。

設計書に載る「決めるべきこと」

第7章の手前で、設定値から機械的に決まらない項目を洗い出しています。影響度と緊急度の判断基準、状態ごとの担当、滞留とみなす日数。どれも組織が決めることなので、設計書では【要決定】として枠を用意し、設定の写しと混ざらないようにしました。

通知についても同じ扱いです。26件の一覧に有効・無効の列を付けてあるので、運用開始までにどれを有効化するかを、この表を見ながら決められます。

例2：Service Portal 画面設計書（全11ページ）

TARGET_MODE = 'portal'、PORTAL_ID = 'sp' で実行した281行から起こした設計書です。

テーブルの設計書とは章立てが変わります。ポータルで必要なのは「どのページに何が載るか」と「どこからどこへ遷移するか」だからです。

1ページ目：表紙

2ページ目：目次

全9章です。ページ設計に3章（第3〜5章）を割いています。ポータルはページ数が多いため、1章に詰め込むと読みにくくなります。

3ページ目：対象範囲とポータル基本設定

ここで最初の発見がありました。この sp ポータルは有効フラグが N です。Zurich では Employee Center（esc）が主役になっているため、従来型の Service Portal は無効のまま残っています。設計書を書く前に、利用者が実際にどのポータルを開いているかを確認すべき、という話です。

図はページとウィジェットの格納構造です。sp_portal → sp_page → sp_container → sp_row → sp_column → sp_instance → sp_widget の6段。中央3つはレイアウト用の入れ物なので、設計上の関心は両端にあります。

4ページ目：サイト構成と画面遷移

メインメニューは6項目です。種別ごとにリンク先の格納場所が違いました。

• Knowledge（種別 kb）→ ナレッジトピック。

• Catalog（種別 sc）→ カタログ。

• Requests（種別 page）→ ページ my_requests。

• Approvals（種別 scripted）→ サーバスクリプトで動的生成。

• System Status（種別 url）→ ?id=services_status。

• My Favorites（種別 page）→ ページ favorites_list。

url sp_page kb_category sc_cat_item record_script と、種別ごとに別の列に入ります。1つの列だけ見ていると全行空欄になる箇所です。

表示順の値も表に入れました。System Status と My Favorites はどちらも500で、並び順が環境によって変わりうる状態です。メニューの順序を確定させたい場合に触る箇所として、最終章に送っています。

画面遷移図では、4系統（カタログ・ナレッジ・申請状況・承認）がいずれもポータル内で完結せず、最終的に管理画面側の処理へ渡ることを示しました。

5ページ目：ページ設計（入口）

ホームページ index には12種類のウィジェットが載っていました。検索窓が最上部にあり、承認待ちとサービス稼働状況が同じ画面に並びます。障害発生時の問い合わせ集中を抑える意図が読み取れます。

404ページには HTML と Breakout Game（ブロック崩しゲーム）が載っていました。初期状態で同梱されるサンプルウィジェットです。公開前に外すかどうかを判断する対象として、第6章の「不要候補」に挙げてあります。

6ページ目：ページ設計（カタログ）

カタログは3階層（分類一覧 → 分類の中身 → 申請フォーム）です。第3階層 sc_cat_item には、申請フォーム本体の隣に関連ナレッジが並びます。申請せずに自己解決できる利用者を手前で止める導線です。

7ページ目：ページ設計（ナレッジと申請管理）

申請管理の中心になるのが ticket ページの Ticket Conversations です。担当者が管理画面で記入したコメントがここに表示され、利用者からの返信もここから行われます。これが動かないと、問い合わせ対応は電話とメールに逆戻りします。