本記事は連載「ServiceNow標準機能だけで作るPull型自動化連携」の第9回（最終回）です。
第8回では、E2Eテストスクリプトで依頼から完了までを通しで動かしました。
最終回では、この学習・検証用の最小構成を本番で使うときに検討すべきポイントを整理します。
本記事で挙げている検討ポイントと対策案は、連載の設計書・コードをもとに生成AIが指摘してきたものです。筆者が実機ですべてを検証したものではありません。参考情報として扱い、実際の適用にあたっては、ご自身の環境と要件に照らして判断してください。
この回で扱うこと
この連載のサンプルは、仕組みを理解しやすくするため、あえて最小構成にしています。ServiceNowのPersonal Developer Instanceで実行し明らかに問題があるところは直しています。ただし、本番で使うならば、少なくとも次の観点を検討してください。
| # | 観点 | サンプルでの扱い |
|---|---|---|
| 1 | 複数ポーラーでの排他制御 | 1つの自動化エンジンは単一ポーラーが前提 |
| 2 | 停止・放置されたSCTASKの検知と復旧 | 標準機能で検知する想定のみ |
| 3 | 結果登録が途中で失敗した場合 | 対策なし |
| 4 | 結果JSONのサイズと保持期間 | 制限なし |
| 5 | 依頼者に見せる情報の範囲 | Work Notesと同じ内容を表示 |
| 6 | 自動化エンジンの追加と判定ルールの統一 |
autoengine1 固定 |
| 7 | 認証と権限 | Basic認証、権限は実機確認 |
| 8 | Stateの内部値の管理 | 各所に値を直接記述 |
| 9 | 業務的な失敗・人による代替作業・リトライ | 運用手順で定義する前提 |
| 10 | Push型への変更 | Pull型での簡易な実装 |
1. 複数ポーラーでの排他制御
第4回のチケット確保は、Table APIでStateを2にする単純な更新です。ポーラー（ディスパッチャー）を複数動かすと、同じSCTASKを2つのポーラーが同時に確保することがあります。
実行開始の条件付き更新（第5回）があるため、作業そのものが二重に実行されることはありません。後から実行開始を呼んだほうが409を受け取るからです。ただし、409を受け取ったポーラーの処理が無駄になり、ログにエラーが残ります。
対策の例です。
| 対策 | 内容 | 考慮点 |
|---|---|---|
| 確保も条件付き更新にする | Scripted REST APIで「StateがOpenの場合だけIn Progressにする」 | ServiceNow側のAPIが1本増える |
| ポーラーごとに担当を分ける |
autoengine1、autoengine2 のように、ポーラーごとに異なる自動化ユーザーを割り当てる |
Task Templateで振り分けを決める必要がある |
| 409を正常な競合として扱う | 実行開始で409を受け取ったら、エラー終了せずに次のSCTASKへ進む | サンプルのスクリプトはエラー終了するため修正が必要 |
今回の実装では、SCTASKにアサインした状態でチケットを作っています。グループautoengine1groupのみにアサインし、「ポーラーごとに担当を分ける」方式で、autoengine1groupに属するautoengine1user1やautoengine1user2に早い物勝ちで処理を担わせることも可能でしょう。
2. 停止・放置されたSCTASKの検知と復旧
自動化エンジンが途中で止まると、SCTASKが次の状態のまま残ります。
| 残った状態 | 止まったタイミング | 復旧の考え方 |
|---|---|---|
In Progress + autoengine1 |
確保の後、実行開始の前 | 作業は始まっていない。担当を戻して再実行するか、人に引き継ぐ |
In Progress + autoengine1running |
実行開始の後、結果登録の前 | 作業がどこまで進んだか不明。自動化エンジン側のジョブ記録を確認し、人が判断する |
State × Assigned to で状態を表しているので、どこで止まったかがSCTASKの画面だけで分かります。これはこの設計の利点のひとつです。
本番では、次の点を決めておきます。
- 何分以上同じ状態のSCTASKを「放置」とみなすか
- 検知の方法（SLA、スケジュールされたレポート、通知など、ServiceNowの標準機能）
- 通知先とエスカレーションの方法
- 復旧の手順（誰が、どの状態に戻すか）
autoengine1running のまま残ったSCTASKを、機械的に Open + autoengine1 へ戻して再実行するのは危険です。作業が途中まで進んでいる可能性があります。再実行してよいかは、作業ごとに判断してください。
特にAnsibleはIaCツールとして有名な割には、冪等性の実現する実装よりも手続き型の実装がしやすい傾向があります。途中からの再実行で同じ結果になる保証がありません。
ServiceNowは人が扱うチケットツールの為、人がアクションを行わずチケットが放置された場合のエスカレーションの手段を標準で持っています。自動化エンジンの途中エラーや無応答は、同様にエスカレーションの対象として、管理者グループに通知することが望ましいでしょう。
3. 結果登録が途中で失敗した場合
第6回の結果登録APIは、次の順に書き込みます。
- RITMの
execution_result_jsonを保存 - RITMの
execution_result_displayを保存 - SCTASKのWork NotesとStateなどを更新
3の更新だけが失敗すると（500 TASK_UPDATE_FAILED）、履歴はRITMに記録されたのに、SCTASKは実行中のままになります。ここで自動化エンジンが同じ結果を再送すると、履歴が2回追記されます。
対策の例です。
-
同じ結果の重複登録を防ぐ：履歴に追記する前に、同じ
sctaskとjobidの組み合わせがすでにあるかを確認し、あればSCTASKの更新だけを行う - 書き込みの順番を見直す：先にSCTASKを更新するか、両方の更新が成功したことを確認してから応答する
- 再送の方針を決める：自動化エンジンが500を受け取ったときに、再送するのか、人に通知するのかを決めておく
4. 結果JSONのサイズと保持期間
execution_result_json には、RITMで実行したすべてのSCTASKの結果が追記されていきます。作業の数が多い依頼や、data が大きい結果では、変数に保存できる長さを超えるおそれがあります。
- 変数の型（サンプルではSingle Line Text）で保存できる最大長を、実機で確認する
-
dataには、後続の作業が本当に必要とする値だけを入れる - 大きなログやファイルは外部に保管し、
dataには保管先だけを入れる - 結果をどれくらいの期間保持するか、RITMのアーカイブ方針と合わせて決める
結果に、パスワード、トークン、秘密鍵などを含めないことも、あらためて確認してください。
5. 依頼者に見せる情報の範囲
第6回のサンプルでは、Work Notesと同じテキスト（Result Data を含む）を、依頼者向けの execution_result_display にも追記しています。
設計の段階では「依頼者向けの結果は result.message」としていました。本番では、次の点を決めてください。
- 依頼者に
Result Dataまで見せてよいか、messageだけにするか - 失敗したときに、依頼者に何を伝えるか（第7回のBusiness Ruleは、失敗時にコメントを出しません）
- 内部のホスト名やパスなど、依頼者に見せるべきでない情報が
dataに含まれないか
6. 自動化エンジンの追加と判定ルールの統一
サンプルでは、自動化ユーザーの名前を次の3か所で判定しています。
| 場所 | 判定 |
|---|---|
| 実行開始API（第5回） |
isAllowedAutomationUser()：autoengine1 で始まるユーザーにだけ変更を許可 |
| Business Rule（第7回） |
autoengine1 と autoengine1running を固定値で比較 |
| E2Eスクリプト（第8回） |
WAITING_ASSIGNEE、RUNNING_ASSIGNEE の設定値 |
自動化エンジンを追加する場合は、名前の規則（例：autoengine<番号> と autoengine<番号>running）を決め、3か所の判定を同じ規則にそろえてください。
あわせて、第7回のBusiness Ruleには、人が担当するSCTASKをClosed Completeにしたときも「Execution completed successfully.」が出るという挙動があります。自動化の作業だけに絞る場合は、完了の判定にも担当者の条件を加えてください。
このような固有値をスクリプト内に持つのは望ましくありません。ServiceNowの他の権限機能やグローバル・ユニークな変数で自動化のユーザーとして対象を絞る等、対象を制限するようにしてください。
7. 認証と権限
サンプルでは、APIサービスユーザーのBasic認証（ユーザー名とパスワード）を使っています。昨今、ServiceNow社はBasic認証を非推奨としており、使えなくなる勢いです。本番では、次の点を検討します。
- 組織のセキュリティ基準に合った認証方式を選ぶ
- 認証情報を、スクリプトや環境変数に直接書かず、自動化エンジンの認証情報管理機能などで管理する
- APIサービスユーザーの権限を、必要な操作だけに絞る（
itilロールは十分すぎます。必要以上を与えていないかを確認する） - 状態を表す自動化ユーザー（
autoengine1など）がログインできないようにする - APIの呼び出しを監査できるようにする
8. Stateの内部値の管理
Stateの内部値（Open=1、In Progress=2、Closed Complete=3）は、サンプルでは次の場所に直接書いています。
値がずれると、確保できない、Execution Planが先に進まない、進捗コメントが出ない、といった不具合になります。インスタンスで値を確認したうえで、どこに何を書いているかを一覧にして管理してください。ServiceNow側は、System Propertyなど1か所にまとめる方法も考えられます。
9. 業務的な失敗・人による代替作業・リトライ
サンプルの結果登録は、SUCCESS と FAILED の2値だけです。本番では、次の運用を決めておく必要があります。
| 論点 | 決めること |
|---|---|
| 入力不備などの業務的な失敗 | 技術的な失敗と同じく人に引き継ぐのか、依頼者へ差し戻すのか。そのときのSCTASKのStateと、依頼者への通知、再申請の手順 |
| 人による代替作業 | 引き継がれた担当者が手作業で完了させた後、SCTASKをClosed Completeにする手順と、結果の記録方法 |
| リトライ | 自動での再実行は原則として行わない。再実行する場合は、作業ごとに冪等かどうかを確認したうえで、人が判断する |
設計の段階では、将来の拡張用に autoengine1failed（失敗）や autoengine1retry（再実行待ち）といった自動化ユーザーも考えていました。リトライ機能を持つ自動化エンジンを使う場合は、これらを使って状態を表すことができます。
10. Push型への変更
Pull型のインテグレーションとして設計していますが、Push型への変更は大した違いではありません。ポーラー部分を自動化エンジン側で実装するのか、ServiceNow内部や自動化エンジンとの間のどこかで実装するかの決定の違いになります。 Push型のメリットは依頼に対する即応性や、連携エラー発生時の認識スピードです。Pull側ではポーリング待ちに数分かかりますし、自動化エンジン側の不具合発生時にServiceNow側で認識するには、ある程度のエスカレーション待ち時間が必要になります。
本番化チェックリスト
- ポーラーの数と、排他制御の方式を決めた
- 放置されたSCTASKの検知時間、通知先、復旧手順を決めた
- 結果登録の再送方針と、重複登録の防止策を決めた
-
execution_result_jsonの最大長と保持期間を確認した - 依頼者に見せる情報の範囲を決めた
- 自動化ユーザーの命名規則と、3か所の判定ルールをそろえた
- 認証方式と、APIサービスユーザーの最小権限を決めた
- Stateの内部値を確認し、記述箇所を一覧にした
- 業務的な失敗、人による代替作業、リトライの運用手順を決めた
連載のまとめ
この連載では、ServiceNowの標準機能に素直に乗り、外部の自動化エンジンが作業を取りに行くPull型の連携を、最小構成で作りました。
| 回 | 作ったもの・決めたこと |
|---|---|
| 第1回 | 必要性とビジネス価値。自動化2.0との関係 |
| 第2回 | 責任分界と、State × Assigned to による状態管理 |
| 第3回 | Catalog Item、Variable Set、Execution Plan、自動化ユーザー |
| 第4回 | Table APIによる取得と確保 |
| 第5回 | 詳細取得と、条件付き更新による実行開始 |
| 第6回 | 結果登録と、失敗時の人への引継ぎ |
| 第7回 | Business Ruleによる進捗の表示 |
| 第8回 | E2Eテストスクリプトによる通しの動作確認 |
| 第9回 | 本番化に向けた検討ポイント |
ServiceNow側で個別に作った開発物(Script)は、Scripted REST APIが2本とBusiness Ruleが1本だけです。依頼の受付と順序制御はCatalog ItemとExecution Planに、状態の管理はSCTASKの標準フィールドに任せました。
その結果、自動化の作業と人の作業を同じ依頼の中に並べ、できるところから少しずつ自動化に置き換えていく、という進め方ができるようになります。自動化は基盤を作って終わりではありません。運用の中で自動化のコンテンツを育てていけるシンプルな仕組みであることが重要です。今回の実装は設計概要を１，２時間ほど整理するだけで生成AIが殆ど作成できる程にシンプルな内容です。シンプルかつ発展性のある自動化の実現に役立つことは間違いないと考え紹介しておりますので、皆様の参考にしていただければ幸いです。
最後まで読んでいただき、ありがとうございました。
連載記事
- 第1回 なぜ今ServiceNow標準機能だけで作る自動化連携なのか
- 第2回 全体アーキテクチャと設計方針
- 第3回 Catalog Item・Variable Set・Execution Planの準備
- 第4回 Table APIで実行待ちタスクを取得・確保する
- 第5回 Scripted REST APIでタスク詳細取得と実行開始
- 第6回 Scripted REST APIで結果を登録する
- 第7回 Business Ruleで依頼者に進捗を見せる
- 第8回 E2Eテストスクリプトで通しで動かす
- 第9回 本番化に向けた検討ポイント
※ 本記事の内容は個人の見解であり、所属する組織の公式な見解ではありません。