はじめに

ServiceNowの運用保守を続けていると、データベースビューの作り方がRDBの基礎知識に依存して属人化しやすい。加えて、GUIでデータ活用しようとしても、データ量が大きいと上限を超えてエクスポート自体が不可能になる場合があったり、リスト表示状態で取得カラムが変わったり、添付ファイルも各レコードに散在していて回収が手間になる。そこで、GUIで生データエクスポートとDatabase View定義を支援するPowerShell Utilityを作成した。

本記事は、背景・実装方針・設計・運用効果を、公開リポジトリの実装内容に基づいて整理する。

背景1: データエクスポートは「できる」が、運用は重い

ServiceNow標準UIでもデータエクスポートは可能である。しかし実運用では、次の課題が積み上がる。

  1. 毎回同じ列構成で出したいのに、リストビュー変更の影響を受けやすい。
  2. 「全カラム + 内部名称込み」での定型取得を求めると、手順説明コストが跳ね上がる。
  3. 大量データではGUIエクスポート自体が重くなり、実行と再実行の管理が難しくなる。

結果として、保守側は「データの使い方」ではなく「取り出し方サポート」に時間を取られる。そこで発想を変え、API経由で定型列を各部署に自走出力してもらう構造を用意した。

背景2: Database View作成はRDB知識ギャップが顕在化しやすい

Database Viewは便利だが、非エンジニアやRDB経験が薄い利用者にとってはハードルが高い。

  • sys_db_view と sys_db_view_table の操作文脈が分かれ、画面遷移が多い。
  • 内部カラム名を同じ画面で一覧確認しづらい。
  • Admin権限がない環境では、別環境で内部名称を調査して持ち込む必要がある。
  • Where句やJOIN定義を手打ちすると、スペルミスや参照間違いが起きやすい。

このため、候補を見ながらGUIで組み立てる支援が必要だと判断した。

作ったもの: PS1 SNOW Utilities

PS1 SNOW Utilitiesは、ServiceNow運用で頻出する作業を1つのGUIにまとめたPowerShellツールである。主要なタブ構成は次のとおりである。

1. Exportタブ

  • 対象テーブル選択（または手動入力）
  • フィルタ指定（全件 / sys_updated_on 期間）
  • 出力形式選択（CSV / JSON / Excel）
  • 大量件数向けのCSV分割エクスポート
  • 出力先フォルダ指定と実行ログ確認

運用上の狙いは、抽出手順を定型化して、担当者ごとの手順差を減らすことである。

2. Database View Editorタブ

  • View内部名・ラベル入力
  • ベーステーブルとPrefix設定
  • JOIN追加（左右カラム、Variable Prefix、LEFT JOIN指定）
  • カラム候補再取得と表示対象選択
  • View作成と結果リンク表示

候補を見ながら定義を組み立てられるため、ServiceNowの画面を往復しながらWhere句やJOIN条件を手入力する負荷を下げられる。

3. Attachment Harvesterタブ

  • 更新期間を条件に、関連添付ファイルを一括収集
  • ファイル名衝突時の連番回避
  • 取得処理ログの記録

監査対応や調査対応で発生しがちな添付回収を、再現可能な手順で実行しやすくする機能である。

4. Truncateタブ

  • 開発用途向けのテーブル全削除
  • 確認コード入力・対象情報表示・再試行設定

危険操作であるため本番利用は非推奨であり、検証環境でのデータ再投入テストを前提に使う機能である。

5. 設定タブ

  • インスタンス名
  • 認証方式（ユーザーID+パスワード / APIキー）
  • 言語設定（日本語/英語）
  • テーマ設定（Dark / Light）
  • 独自ドメイン接続設定（instanceDomain）

入力値は settings.json に保存し、機密値はWindows DPAPI（CurrentUser）で暗号化して保持する。

設計の要点

私がこの実装で重視したのは、運用時の保守負担を下げるための設計である。

  1. 通信処理を共通関数に集約
    Invoke-SnowRequest を軸に GET/POST/PATCH/DELETE/添付取得をラップし、認証・例外処理・ログ出力の分散を避けている。

  2. UI構築と表示制御を分離
    Build-* 系でUI要素を構築し、Apply-*Language と Set-Theme で表示切替を行う構成にしている。

  3. 設定保存の安定化
    Load-Settings / Save-Settings と Request-SaveSettings により、設定の保存漏れと過剰保存を抑える方針を取っている。

  4. 危険操作の多重確認
    Truncate処理は確認コードや対象表示を挟み、誤操作リスクを下げる設計になっている。

  5. ログ追跡を前提にした実装
    Logsタブと ConvertTo-LogCompactJson を通じて、実行結果を後から追跡しやすくしている。

実装上の割り切り

会社環境ではインストーラー配布や常駐アプリ導入のハードルが高い。そこで今回は、テキスト配布でも動作可能なPowerShellスクリプト形態を優先した。

この割り切りにより、導入障壁を抑えつつ、現場での利用開始までの時間を短縮できた。

導入効果

導入後に確認できた効果は次の4点である。

  1. Exportの手順が画面上で固定化され、抽出依頼ごとの説明負荷が下がった。
  2. Database View作成時に、ServiceNow UI上でWhere句を手入力する場面を減らせた。
  3. 添付ファイル回収を期間条件つきで一括実行できるため、調査時の反復作業を短縮できた。
  4. 設定保存により、インスタンス名や認証情報の再入力回数を減らせた。

効果は派手ではないが、運用担当者が毎回繰り返す作業時間を確実に圧縮できる点に実務的な価値がある。

制約と注意点

  • テーブル一覧は sys_db_object 参照のため、ACL次第で取得できない場合がある（手動入力で回避）。
  • 環境によってはWhere句/JOIN定義の自動保存に制約があり、ServiceNow側で手動補完が必要な場合がある。
  • 本ツールはServiceNow社とは無関係であり、同社の承認・保証・サポートを受けない。

まとめ

今回のPS1 SNOW Utilitiesは、データ抽出とDatabase View定義に関する実務上の詰まりを減らす目的で作成したものである。

個人的な所感として、PowerShellでGUIを作れること自体は以前から認識していたが、実際に自力で着手する発想は持てていなかった。生成AIに支援を受け、ほぼノーコードに近い指示ベースでここまで形にできた経験は、AIの進化の速さを強く実感させるものだった。同時に、従来のローコード／ノーコードツールは優位性の再定義を迫られ、陳腐化圧力を受ける局面が避けにくいとも考えている。