本記事は連載「ServiceNow標準機能だけで作るPull型自動化連携」の第1回です。
今回はコードを書く前に、なぜこの仕組みが必要なのか／誰に役立つのか／連載で何を作るのかを整理します。
はじめに
「ServiceNowで依頼を受けて、Ansibleで自動実行したい」という話は、多くの現場で出てきます。
ところが実際に作ろうとすると、次のような壁にぶつかりがちです。
- ServiceNowから社内ネットワークの自動化基盤を呼び出すには、通信経路やMID Serverなどの準備が必要になる
- Flow DesignerやIntegrationHubで連携を組むと、ワークフローが個別最適になり、依頼種別が増えるたびに作り込みが増える
- 自動化の状態を管理するために、カスタムテーブルやカスタムフィールドを追加してしまい、保守やバージョンアップの負担が増える
- 自動化が失敗したとき、誰がどう引き継ぐのかが曖昧になる
- 依頼者からは「今どうなっているのか」が見えない
この連載では、こうした課題に対して、ServiceNowの標準的な要求実現機能（Service Catalog / Execution Plan / Catalog Task）を最大限活かし、外部の自動化エンジンが作業を「取りに行く」Pull型連携を、最小構成で実装します。
この連載で作るもの
ポイントは次のとおりです。
| 観点 | 採用した方式 |
|---|---|
| 連携方向 | 自動化エンジンからServiceNowへのPull（ServiceNowからのPushは使わない） |
| 依頼受付・順序制御 | Catalog Item ＋ Execution Plan（OOTB） |
| 状態管理 | SCTASK標準の State × Assigned to の組み合わせで表現。専用フィールドは作らない |
| 処理の振り分け | SCTASKの Short description（例: REQTYPE_LINUXLOG_ACTION1）を処理キーにする |
| ServiceNow側の個別開発 | Scripted REST API（詳細取得／結果登録）と、進捗表示用Business Rule 1本のみ |
| 使わないもの | Flow Designer、IntegrationHub、カスタムテーブル、状態管理用カスタムフィールド |
なぜ必要なのか ― ビジネス価値
1. 「受付・統制」と「実行」をきれいに分けられる
ServiceNowは依頼受付、承認、順序制御、チケット状態、監査証跡を担い、自動化エンジンは「取得・実行・結果返却」だけに専念します。
責任分界が明確なので、ITSMチームと自動化チームがそれぞれの得意領域で独立して改善を進められます。
2. 標準機能中心だから、作って終わりにならない
状態管理をSCTASKの標準フィールドで表現し、カスタムテーブルや独自ワークフローを持たないため、
- ServiceNowのバージョンアップ時に影響を受ける範囲が小さい
- 運用担当者がいつものSCTASK画面のまま自動化の状態を把握できる
- 引き継ぎや属人化のリスクが下がる
という、長く使い続けるうえで効いてくるメリットがあります。
3. 依頼種別を増やすコストが小さい
新しい自動化メニューを追加するときに必要なのは、基本的に次の3つだけです。
- Catalog Itemと個別Variable Setを作る
- Execution PlanのTask TemplateのShort descriptionに処理キーを設定する
- 自動化エンジン側にそのキーに対応する処理（Playbook等）を追加する
APIやBusiness Ruleは共通のまま再利用できます。
4. 「自動化2.0」をそのまま形にできる ― 人と自動化を1本の依頼の中で組み合わせる
レッドハットは「自動化2.0」という考え方を提唱しています12。Red Hat Ansible Automates 2021 Japanの基調講演では、同社の中島倫明氏が、多くの企業でインフラ業務の工数の大半が実作業ではなく調整・準備（人と人のやり取り）に費やされているため、手順をツールやスクリプトに置き換える自動化1.0だけでは大きな効果が出にくいと解説しています1。自動化2.0では、自動化した作業を作業チーム外の人も使えるサービスにし、さらにサービスを連結・API化して、業務プロセス全体を効率化します23。
ただ現実の業務では、すべての作業を一度に自動化できるわけではありません。承認、目視確認、まだ自動化していない作業など、人の手が必要な工程が途中に挟まります。ここで効いてくるのが Execution Plan です。
Execution Planでは、作業ごとにTask Templateを並べ、それぞれに担当（Assignment group / Assigned to）を設定できます。本連載の仕組みでは、自動化エンジンは「自分宛てのSCTASK」だけを取りに行くので、どの作業を誰がやるかは担当の設定だけで決まります。
たとえば次のような組み合わせが、ワークフローを作らずに実現できます。
| 作業 | 担当 | 動き |
|---|---|---|
| 作業1: ログ取得 | 自動化エンジン1（autoengine1） |
SCTASKをPullして実行し、結果を返却して完了 |
| 作業2: 取得結果の確認 | 人（運用チームのグループ） | 通常のSCTASKとして作業し、手動で完了 |
| 作業3: ログのアーカイブ | 自動化エンジン2（autoengine2） |
SCTASKをPullして実行し、結果を返却して完了 |
この仕組みのポイントは次のとおりです。
- 順序制御はExecution Planに任せる: 前のSCTASKが正常完了すると次のSCTASKが開始されます。作業者が人か自動化かを意識した分岐は不要です。
- 人と自動化を同じ「SCTASK」として扱う: 人の作業も自動化の作業も同じチケットの形なので、進捗や証跡を同じ画面で追えます。
- 自動化エンジンを用途ごとに分けられる: 担当ユーザー／グループを変えれば、別の自動化エンジン（例: ネットワーク用とサーバー用）にも振り分けられます。
-
段階的に人を自動化へ置き換えられる: 今は人が担当している作業2も、自動化できた時点でTask Templateの担当を
autoengine系に変えるだけで切り替えられます。依頼者から見たサービス（Catalog Item）は変わりません。 - 作業結果を後続の作業に引き継げる: 各作業の結果はRITMにJSONの履歴として蓄積されるので、作業3が作業1の結果を参照することもできます。
つまり、自動化2.0の「サービス化」をCatalog Itemで、「連結」をExecution Planで実現し、その途中に人の作業も自然に組み込めます。ServiceNowの標準機能に素直に乗るだけで、自動化2.0を実装できるのが、この仕組みの大きな特長です。
5. 自動化と人手運用が自然に共存する
自動化が失敗した場合、SCTASKは In Progressのまま、依頼ごとに指定した引継ぎグループ（failure_assignment_group）へ移ります。
「自動化できなかった作業」がそのまま通常の運用キューに乗るため、自動化率が100%でなくても業務が止まりません。段階的に自動化範囲を広げていく運用に向いています。
6. 依頼者・運用者の双方に「見える」
- 依頼者: RITMのActivityに「確保済み → 実行開始 → 完了」の進捗が表示される
- 運用者: SCTASKのWork Notesに、Status / Job ID / Message / 結果データが読みやすい形で残る
- 後続処理: 結果はRITMの隠し変数にJSON配列の履歴として蓄積され、次のタスクからも参照できる
7. 自動化エンジンを選ばない
ServiceNow側のインターフェースはREST APIだけなので、Ansible Automation Platformでも、シェルスクリプトでも、別の自動化基盤でも同じ仕組みで接続できます。
また外部インターフェースではSCTASK番号やuser_nameを使い、インスタンス固有のsys_idを公開しない設計にしているため、環境間の移行もしやすくなります。
想定読者
| 読者 | この連載で得られること |
|---|---|
| ServiceNow管理者・開発者 | 標準機能を崩さずに外部自動化とつなぐための、Scripted REST API／Business Ruleの実装例 |
| 自動化エンジニア（Ansible / AAP等） | ServiceNowのチケットを「キュー」として使い、Pullで処理する実装パターン |
| 運用設計者・ITアーキテクト | 状態遷移、失敗時の引継ぎ、二重実行防止を含めた連携設計の考え方 |
| 運用改善・自動化推進のリーダー | 小さく始めて段階的に自動化範囲を広げるための、現実的なアーキテクチャの選択肢 |
前提知識
- ServiceNowの基本用語（Catalog Item、RITM、SCTASK、Variable Set）がわかる
- REST APIと
curl/jqを触ったことがある - 検証用のServiceNowインスタンス（PDIなど）を用意できる
この連載で扱わないこと
- ServiceNowから自動化エンジンを起動するPush型連携
- Flow Designer / IntegrationHubによる連携
- 自動化エンジン内部の詳細なジョブ設計
本連載のサンプルは学習・検証用の最小構成です。単一ポーラーを前提としており、本番利用時は認証方式、ACL・最小権限、監査、複数ポーラー時の排他制御、放置タスクの監視などを追加で設計してください。また、記事作成時点のServiceNow OOTB動作に依存するため、利用するバージョンで動作を確認してください。
連載の目次（予定）
| 回 | タイトル | 主な内容 |
|---|---|---|
| 第1回 | なぜ今Pull型連携なのか（本記事） | 課題、ビジネス価値、想定読者、全体像 |
| 第2回 | 全体アーキテクチャと設計方針 | 責任分界、自動化2.0との対応、State × Assigned toによる状態表現、状態遷移、カスタムを作らない理由 |
| 第3回 | Catalog Item・Variable Set・Execution Planの準備 | 共通／個別Variable Set、Short descriptionを処理キーにする命名規則、自動化ユーザーとグループ、人の作業と複数の自動化エンジンを組み合わせるExecution Plan |
| 第4回 | Table APIで実行待ちタスクを取得・確保する |
Open + autoengine1 の取得クエリ、State=2 更新による確保、サービスユーザーの権限 |
| 第5回 | Scripted REST API ① タスク詳細取得と実行開始 | SCTASK番号での詳細取得、変数の返却、expected_current_assigned_to によるCompare-and-set、400/409のエラー設計 |
| 第6回 | Scripted REST API ② 結果登録 | SUCCESS/FAILEDの分岐、RITMへのJSON履歴追記、Work Notes整形、失敗時の引継ぎ |
| 第7回 | Business Ruleで依頼者に進捗を見せる | SCTASKの状態変化をRITMのActivityへ転記する |
| 第8回 | E2Eテストスクリプトで通しで動かす | シェルスクリプトによる取得→確保→実行→結果返却、動作確認のチェックリスト |
| 第9回 | 本番化に向けた検討ポイント | 二重実行防止、複数ポーラー、放置監視、結果JSONのサイズ、セキュリティ |
※ 内容は執筆状況に応じて変更する場合があります。
おわりに
自動化は「作ること」よりも「運用の中で使い続けること」のほうが難しいものです。
この連載では、派手な仕組みではなく、ServiceNowの標準機能に素直に乗り、小さく始めて広げていける連携を目指します。
次回は、この仕組みの全体アーキテクチャと、SCTASKの State × Assigned to で自動化の状態を表現する設計について解説します。
参考文献
※ 本記事の内容は個人の見解であり、所属する組織の公式な見解ではありません。
-
Qiita Zine「ITインフラ自動化の未来、「自動化2.0」とは何か – Ansible Automates 2021 Japanレポート」（2021年11月17日） https://qiita.com/official-columns/event/202111-red-hat/ ↩ ↩2
-
日立ソリューションズ「第11回 Automation 2.0 with Ansible Automation Platform」（2024年3月28日） https://www.hitachi-solutions.co.jp/redhat/column/vol11/ ↩ ↩2
-
レッドハット株式会社「業務プロセス全体に自動化を利かせて効果を最大化、「自動化2.0」の実現法」（TechTargetジャパン ホワイトペーパー、2022年11月7日） https://wp.techtarget.itmedia.co.jp/contents/68418 ↩