1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

生成AIで安全に作るServiceNowのバックグラウンドスクリプト用のプロンプト文

Posted at

1.はじめに

ServiceNowのバックグラウンドスクリプトは、調査や棚卸しを素早く進められる頼もしい手段です。一方で、少しの書き間違いが更新や登録につながり、意図しない変更を招くこともあります。
そこでおすすめしたいのが 「生成AIで安全に作るServiceNowのバックグラウンドスクリプト用のプロンプト文」 です。毎回の依頼文を整えるだけで、読み取り専用・見やすい出力・メンテしやすい構成のスクリプトを安定して作りやすくなります。

この記事では、バックグラウンドスクリプトを安全に扱うためのプロンプトと、3つのテーブルの関連を一覧で出す実行例を紹介します。


2.安全にバックグラウンドスクリプトを作るためのプロンプト

以下が、私がよく使う好きなプロンプトです。短いですがいろんな思いが組み込まれてます。

プロンプト(そのまま使えるテンプレ)

常に完全なコードを提供する
要件はコードの冒頭にコメントで箇条書きにする
ユーザーが変更可能なパラメータはコードの先頭に寄せること
ServiceNowのバックグラウンドスクリプトはかならず読み取り専用にする。レコードの更新や追加は一切行わないこと

結果は、列が揃うように字下げをして見やすくする
結果に、「*** Script: 」の文字を除外すること。
リスト表示は、|(パイプ)で区切ること。1列目の先頭の|も忘れず書くこと

インプット:
(次のチャットで指示をします。1行だけ返事をして待機してください。)
 

このプロンプトが好きな理由

1) 要件が常に上にある

コードの冒頭に要件が並ぶだけで、「何をするスクリプトか」が一目で分かります。
調査用スクリプトを複数作るほど、この差が大きくなります。

2) 変更点が上に集約される

こちらで修正可能な変数(テーブル名、フィールド名、出力数など)は上の方に集約しておくことで、アレンジをしやすくすることができます。

3) 出力が“あとで使える”形になる

| 区切りで列を揃えたリストは、そのまま貼って確認できます。
さらに、あとからExcelなどに取り込んで整形しやすいのも大きな利点です。

4) 読み取り専用が要件に残る

「読み取り専用であること」をコード内の要件として明文化しておくと、後日別のLLMで改修するときも安全性が維持されやすくなります。運用の安心感が増します。


3.実行例

ここでは例として、次の関連を1つの一覧にまとめます。

- Change Request に関連する Incident
- さらに Incident に関連する Child Incident

ServiceNowのレポートでは2、3テーブルを自然にまたぐのが難しく、データベースビューもそれなりに作り込みが必要になりがちです。 一方、バックグラウンドスクリプトなら、欲しい形に整えて出力できるのが魅力です。

このプロンプトで作ったコード(一部抜粋)

以下はプロンプトの後に出した、簡単な要件です。

Change Requestと関連しているIncidentとそのIncidentに関連しているChild incidentを
1つのリスト表示結果で表現してください。

その後、生成AIが出力したコードです。
心配な時は、このコードを別の生成AIに見せて「このコードで更新や作成が行われないかチェックしてください」と聞くといいです。

/*
- 要件:
  - (ここに目的を書く:例)Change Requestと関連するIncident、およびそのChild Incidentを調査して1つのリスト表示にする
  - IncidentとつながっていないChange Requestは出力しない
  - 表示はパイプ(|)区切りで、先頭にも「|」を付ける
  - 列が揃うように見やすく整形する
  - 出力に「*** Script: 」を含めない(gs.printのみを使用)
  - 読み取り専用(更新・追加・削除は一切行わない)
*/

// ===== ユーザーが変更可能なパラメータ =====
var PARAM = {
  changeEncodedQuery        : "",   // TODO: Changeの条件
  incidentEncodedQuery      : "",   // TODO: Incidentの条件
  childIncidentEncodedQuery : "",   // TODO: Child Incidentの条件
  limitChanges              : 0,    // 0=無制限
  limitIncidentsPerChange   : 0,    // 0=無制限
  limitChildrenPerIncident  : 0,    // 0=無制限
  showSysId                 : false // trueでsys_idも出す
};

// ===== ここにユーティリティ(pad/printなど)を置く =====
// TODO: 列幅、文字切り詰め、gs.printでの出力整形など

// ===== メイン処理 =====
(function main() {

  // TODO: ヘッダ出力(| 区切り、先頭 | 付き、列揃え)

  // TODO: change_request をクエリ
  // TODO: Changeに紐づく incident を収集(例: incident側の参照、関連テーブルなど環境に合わせる)
  // TODO: incidentごとに child incident(parent_incident 等)を収集
  // TODO: 1行=1レコードで出力(Change / Incident / Child Incident の列を揃える)

})();

ServiceNowのバックグラウンドスクリプトで実行すると以下のように表示されます。
この関係表が一瞬で出てくるのはとても生産性が高いです。
image.png

この例は「3テーブルの関連を一覧で出す」目的ですが、リスト出力に限らず障害調査の材料をまとめたり、設計情報を棚卸ししたり、運用で効く用途に広げやすいのも魅力です。


4.まとめ

バックグラウンドスクリプトは、使い方次第で運用の速度と精度を大きく引き上げられます。
その一方で、更新系の混入や出力のバラつきが不安要素になりやすいのも事実です。

プロンプト文を型として固定すると、

  • 目的がすぐ分かる(要件が冒頭に残る)
  • 修正が簡単(パラメータが先頭に集約)
  • 出力が使いやすい(| 区切りで整形)
  • 実行が安心(読み取り専用を要件に明記)

という形で、日々の調査を気持ちよく回せるようになります。
皆さまの業務効率が少しでも向上して頂けたらうれしいです。

以上です。ありがとうございました!

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?