【ServiceNow】「ServiceNow」におけるAIとの付き合い方

最近のServiceNow開発プロジェクトには、新しいメンバーが参加しています。
その名もAI。

彼は配属初日から異常なやる気を見せています。
AI： 「設計書作ります！」
AI： 「Client Script書きます！」
AI： 「テストケースも作ります！」
AI： 「説明資料も作れます！」
僕： 「すごいな君」
AI： 「はい！ちなみに全部3分でできます！」

すごく優秀そうです。
しかし、この新人には特徴があります。
知識量は無限。作業速度は最速。
でも、実務経験はたまに怪しい。

つまりベテランのような顔をした新人なのです。
ここでは、彼がどのような点に優れ、どのようなサポートが必要なのか
私の触った限りでの機能について紹介していきます。

第一章　Client Script職人としてのAI 

言わずもがな、ServiceNow開発ではClient Scriptを書く機会が非常に多くあります。
例えば、
・特定の選択肢でフィールドを表示する
・入力チェックを行う
・参照項目を制御する
・動的に必須項目を切り替える
といった実装ですね。

さて、ここでAIに相談します。

「カテゴリがPCなら型番を表示。スマホならIMEIを表示するClient Script作って」

すると数秒でコードを生成します。
この時点で開発者はかなり楽になります。
特に便利なのは、自分が「何を書くべきか分からない」状態を脱出できること
つまり、ゼロから考える時間を削減できるということなのです。

ただしここで問題がありまして。。。
AIが作るコードは、だいたい60～80点であるということです。
「赤点回避できてるし、だいじょーぶだいじょーぶ」なんて思ってはいけません。学生気分は捨てなさい。
80点のコードは致命的な事故を起こしかねません。
例えば

AIあるある① isLoadingを忘れる

これは一見正しいコードに見えますね。
しかし画面初期表示で意図しない動作を起こす可能性があります。
経験者なら反射的に書く

が無いのです。
AIは「動くコード」を作ることは容易にできますが
「運用で困らないコード」は人間が作る必要があるのです。

AIあるある② フィールド名を創造する

ServiceNow開発者なら誰でも経験があるのではないでしょうか。
AIが突然、

みたいなフィールドを使い始めます。
そのフィールド、どこの世界線のServiceNowですか？
という状態です。
AIはときどき自信満々に架空のフィールドを生成します。

攻略法

ではどうすれば100点に近いコードを生成できるのでしょうか
例えば以下は悪い指示です

Client Script作って

これだとAIは要件を推測してしまいます。
要件に対し「推測の余地」があるのは指示として不十分であり
押さえておきたい部分については正確な情報を与えるのが「良い指示」といえるのです。
(実はこれ対人間でも同じではないでしょうか)
以下はその例です

ServiceNowのonChange Client Scriptを作成してください。
また、以下の要点を必ず網羅したコードであってほしいです。

・isLoadingを考慮
・Client Scriptの種別はonChange
・カテゴリがPCの場合のみmodel表示
・カテゴリ変更時に不要な値はクリア
・既存フィールドのみ利用
・コメント付き
・ServiceNowベストプラクティス準拠

ここまで指定すると品質が大きく変わります。
AIはプログラマーではありません。
要件定義なしでも超高速で動作してしまうコード生成器であり
要件が曖昧であればあるほど、機能や運用曖昧なコードが出てきてしまうのです。

---

第二章　Script Includeの優秀な製作者

Script Includeについても同様です
例えば、
・GlideAjaxの雛形
・Script Includeの骨組み
・JSONの組み立て
・GlideRecord検索処理
などの定型コードに対し、開発者が

「ユーザIDを受け取って所属部門を返すGlideAjax作って」

と依頼すると、かなり高い確率で使えるレベルのコードが返ってきます。
特に若手の開発者に向けた学習教材としては非常に優秀です。
「なぜこの構成になるのか」
を質問すると説明までしてくれます。
まるで24時間対応の家庭教師です。ただし油断してはいけません。
AIは

のような「存在すればたぶん動く」コードを書くことがあります。
nullチェック？権限制御？例外処理？
そんなものは未来のあなたが頑張ってください。というスタンスです。

攻略法

ここでも単に

GlideAjax作って

ではなく、

ServiceNow Script Includeを作成してください。

以下を考慮してください。

・GlideAjax利用 ・Accessible fromはThis application scope only ・入力値のnullチェック ・エラーハンドリング実装 ・処理件数1000件以上を想定 ・パフォーマンス上の懸念点も説明

ここまで指定すると、
コード生成だけではなくレビューコメントまで返してくれるようになります。
特に「懸念点も説明してください」はかなり強力です。
時にAIは作るよりレビューさせた方が優秀なことがあります。

---

第三章　設計レビュー担当として雇うと強い

これまでの自分の経験則上、コード生成よりもさらに有効なのがこちらの使い方です。
AIに作らせるのも良いけど、AIにレビューさせる。これが非常に強いです。

例えば、
「この実装のリスクを洗い出して」
と依頼すると
・パフォーマンス問題
・不要な同期通信
・再帰発生リスク
・権限制御の不足
・テーブルロックの懸念
などを指摘します。
もちろん全て正しいとは限りません。
しかし人間1人のレビューより多くの観点でものを考えてくれます。
(少なくとも自分なんかのレベルよりかは広い視野で考えてくれますね)

AIは開発者の側面も持っていますが
良い意味での文句を言うレビュアー
として使用すると恩恵が大きい印象です。

攻略法

レビュー依頼でも聞き方にコツがあります。

悪い例

この設計どう？

良い例

ServiceNow ITSM設計レビューをしてください。

以下の観点で確認してください。

・拡張性 ・運用保守性 ・性能 ・アップグレード影響 ・CMDB整合性 ・権限制御 ・将来的な機能追加リスク

AIは観点を与えるほど賢くなります。
逆に観点を与えないと、「特に問題ありません」で終わることがあります。

人間のレビューでも同じですね。

第四章　データ移行で突然本気を出す

ServiceNow案件で地味につらいのがデータ移行です。
お客様： 「Excelは53ファイルあります」
開発者： 「53？」
お客様： 「とりあえず53です」
開発者： 「とりあえず？」
そんな世界です。

ここでAIは意外な活躍をします。
例えばインシデント移行を考えてみましょう。
旧システムには、

のようなマッピング定義があります。
人間が見ると「まあ移行できそうですね」で終わることがあります。
しかしAIに

このマッピング定義から移行リスクを洗い出してください

と依頼すると、

・状態コードとStateの値体系が異なる可能性
・参照ユーザがServiceNow側に存在しない可能性
・運用組織変更によるAssignment Group不整合
・文字列型と参照型の変換漏れ
・日付形式の違い
・必須項目不足

などを一気に洗い出してくれます。
さらに、インシデントだけでなく、
・ユーザマスタ
・組織マスタ
・CMDB
・ナレッジ
・変更履歴
などが絡み始めると人間の頭だけでは追いきれなくなります。
そんな時に、

CMDB移行時の参照整合性リスクを洗い出してください

cmdb_ci_serverからcmdb_ci_computerへ再編します

関連テーブルへの影響も確認してください

と依頼すると、想像以上に良い観点が返ってくることがあります。
人間が見落としがちな
・親子CIの整合性
・関係データの欠損
・インシデントとの関連切れ
・変更履歴との紐付け切れ
といった点を挙げてくれることもあります。
ただし、「リスクを洗い出して」だけではまだ曖昧さが残っているとも言えます。
例えば次のように依頼すると精度が大きく変わります。

ServiceNow ITSMへの移行を前提としています。

Incidentテーブルへ投入します。

Data Source→Import Set→Transform Mapで移行します。

以下の観点でレビューしてください。

・参照整合性 ・必須項目不足 ・データ型不一致 ・コード変換漏れ ・性能影響 ・運用変更影響

すると急にServiceNow案件経験者のような回答を始めます。
AIは優秀な人材ですが、「何か気になるところある？」と聞かれると困ります。
逆に、「どの観点で見ればいいか」を与えると突然優秀になります。

これは人間の新人教育と驚くほど似ているような気がします。

---

第五章　テスト工程の救世主

個人的にテスト工程でもAIの恩恵は大きいです。
開発者は実装が終わると疲れています。
しかしテストケースは作らなければなりません。
ここでAIに

このCatalog Itemのテスト観点を出して

と依頼すると、
・正常系
・異常系
・境界値
・権限差
・入力パターン
などを一気に列挙してくれます。
人間が考えた20ケースに対し、AIが追加で15ケース出してくることもあります。
「よくそんなこと思いついたな」というケースもあります。
たまに「宇宙人が申請した場合」くらいの無茶な観点も出しますが、そこはご愛嬌です。

攻略法

AIはテストケース作成も得意です。
しかしそのまま依頼すると、正常系だらけになります。
良い依頼はこちらです。

Catalog Itemのテストケースを作成してください。

以下を必ず含めてください。

・正常系 ・異常系 ・境界値 ・権限制御 ・参照データ欠損 ・既存運用との競合 ・並列申請 ・Flowエラー

こう依頼すると、

思った以上に実践的なケースが出ます。

---

最終章　ServiceNow開発でAIを本当に使いこなすコツ

ここまで様々な活用方法を紹介してきました。

・Client Scriptを書かせる。

・Script Includeを書かせる。

・Flow Designerを考えさせる。

・データ移行をレビューさせる。

・テストケースを作らせる。

どれも効果があります。
ただし全てに共通する法則があります。
AIをうまく使えている人は、プロンプトエンジニアではありません。

ServiceNowをよく知っている人です。
例えば、Client Scriptなら
・isLoading
・onChange
・g_form
・対象テーブル
・対象フィールド
を伝える。

Script Includeなら
・スコープ
・ACL
・例外処理
・パフォーマンス要件
を伝える。

設計レビューなら…といった具合です。

つまりAI活用とは、難しいプロンプトテクニックではありません。

「ServiceNowの知見を整理して伝える技術」

なのです。

実際、AIが期待外れな回答を返す原因の多くは、AIが悪いのではなく、AIが判断するための材料が不足していることにあります。

新人に

「設計レビューしておいて」

とだけ伝えるより、

「性能・保守性・権限制御・CMDB整合性の観点で見ておいて」

と伝えた方が良いレビューになるのと同じです。

結局のところ、ServiceNow開発におけるAI活用の本質は、
「AIに答えを出させること」ではなく、 「ServiceNow開発者の知識と経験を最大限に引き出すこと」
なのかもしれません。

優秀なServiceNow技術者ほどAIを使いこなし、
優秀なAIほどServiceNowを理解した技術者を必要とする。
なかなか不思議な関係です。

ただし、最後に一つだけ。AIはこれからもきっと、
存在しないフィールド名を作り続けます。
存在しないScript Includeを呼び出します。
存在しないAPIを提案します。
そして時々、見たことのない世界線のServiceNowについて語り始めます。

そこに対して人の目からのレビューだけは忘れないでください。
彼は優秀な新人ですが、
本番障害が起きた時に謝罪会へ出席する機能は、まだ実装されていないのです。