会社情報
採用情報
お問い合わせ
Article

ServiceNowで IT業務を自動化

高田晃太郎
ServiceNowで IT業務を自動化

統計や公開事例を俯瞰すると、IT運用の自動化はもはや局所的な効率化では終わらない。サービスデスク分野では、問い合わせ処理の迅速化や一次解決率（FCR: First Contact Resolution）の改善が報告されている¹。FCRやSLA（Service Level Agreement: 合意したサービス水準の達成状況）はITSMの主要KPIとして広く用いられる⁵。加えて、主要アナリストのレポートではServiceNowがITSM領域で長期にわたりリーダー評価を受けてきたと紹介されており（たとえばGartner Magic Quadrant for ITSMに関するベンダー紹介ページ）³、ESM領域でもForresterのレポートでリーダーに位置づけられている⁴。これらは、自動化を前提とした運用モデルが平均復旧時間（MTTR: Mean Time to Restore）の短縮や契約順守の安定化、運用の効率化に寄与し得ることを示唆している¹および⁵。本稿は、単なる宣伝ではなく実装と運用に踏み込む。プラットフォームの選択理由からアーキテクチャの勘所、エラーハンドリング、パフォーマンスの目安、そしてROIまで、コードと指標で「業務をコード化する」道筋を具体化する。

なぜServiceNowで自動化するのか

ServiceNowはタスクの標準化、ワークフローの見える化、統合データモデル（CMDB: 構成管理データベース、ユーザー、サービス）を核に、Flow Designer（ローコードのフロー作成機能）、IntegrationHub（外部SaaS連携の拡張）、Business Rule（サーバーサイドのレコード処理）、Scripted REST API（カスタムAPI定義）といった多層の自動化手段を提供する⁶。選択肢が多いことは複雑さの温床にも見えるが、実際には粒度の異なるユースケースに適材適所で適用できる柔軟性こそが価値になる。問い合わせ分類やルーティングの自動化、変更申請の標準化、リクエストフルフィルメントの直列・並列制御、外部SaaSとのプロビジョニング連携まで、「人が判断して手で動かす」工程を段階的にゼロへ近づける設計が可能だ。また、ガバナンス面ではレコードプロデューサやスコープドアプリ、ATF（Automated Test Framework: 自動テスト）を取り入れることで、変更の安全性とスピードを両立できる。

ビジネス効果とKPI設計

KPIを定義せずに自動化を始めると、効果の可視化ができずにプロジェクトが失速する。サービスデスクであれば平均処理時間、一次解決率（FCR）、チケット回避率、バックログ滞留日数、SLA違反件数などをまず測る。運用チームであればMTTR、検知から通報までの遅延、変更実行あたりの人手投入時間、リリースリードタイムが重要だ⁵。たとえば、インシデント対応のMTTR短縮や、パスワードリセット・ソフトウェア申請といった定型業務の自動実行による処理量のオフロードをターゲットに置く。自動化の価値は「短縮した時間」と「減らしたリスク」を通貨に換算して初めて経営判断に耐えるため、月次でのコホート比較やA/B運用で改善幅を継続計測することが肝心だ。

アーキテクチャの選択基準

判断の軸は同期か非同期か、トランザクション境界をまたぐか、そして責任の所在だ。レコード保存時に決まるロジックはBusiness RuleやServer Script、ユーザー操作に沿ったオーケストレーションはFlow Designer、外部SaaS・システム連携はIntegrationHubまたはMID Server、外部からのエントリポイントはScripted RESTや標準Table API（汎用CRUD API）が向く。高頻度かつ単純な処理はプラットフォーム内で完結させ、スパイクの激しいバッチはキューイングとリトライを備えた外部実行に逃がす。「どこで壊れて、誰が直すか」を先に決めると、エラーハンドリング、監視、権限、コスト配賦まで設計が素直に落ちる。

実装ガイドとコード例

ここからは、サーバーサイドの自動割当、API公開、外部連携、運用バッチ、SLA可視化という流れで実装の核心に触れたい。いずれも実運用で扱う前提で、エラーハンドリングと計測を組み込み、移行後の運用負債を減らす視点を通す。

サーバーサイド自動化（Business Rule）

インシデントの割当は自動化効果が出やすい。CIに紐づくサポートグループへ割り当てるビフォーインサートのBusiness Ruleは次のように書ける。

// Business Rule (before insert on incident)
(function executeRule(current /*, previous*/) {
  try {
    if (current.assignment_group.nil() && !current.cmdb_ci.nil()) {
      var ci = new GlideRecord('cmdb_ci');
      if (ci.get(current.cmdb_ci) && !ci.support_group.nil()) {
        current.assignment_group = ci.support_group;
        current.work_notes = 'Auto-assigned by CI support group';
      }
    }
  } catch (e) {
    gs.error('Auto-assign BR error: ' + e.message);
  }
})(current);

同一トランザクション内の軽い参照であればユーザー体験に与える影響は小さい。一方で、重いロジックは避け、必要ならば非同期のEvent-Actionへ逃がすことで、応答性を保てる。

API公開（Scripted REST API）

標準のTable APIで十分なことは多いが、ペイロードのバリデーションやドメイン制御を加えたい場合はScripted RESTが適する。標準変更を登録するエンドポイントの例は以下の通りだ。

// Scripted REST Resource (POST /api/x_company/changes)
(function process(request, response) {
  try {
    var body = request.body.data || {};
    if (!body.short_description) {
      response.setStatus(400);
      response.setBody({ error: 'bad_request', message: 'short_description is required' });
      return;
    }
    var gr = new GlideRecord('change_request');
    gr.initialize();
    gr.type = 'standard';
    gr.short_description = body.short_description;
    gr.description = body.description || '';
    if (body.assignment_group) gr.assignment_group = body.assignment_group;
    var sysId = gr.insert();
    response.setStatus(201);
    response.setBody({ result: { sys_id: sysId } });
  } catch (e) {
    gs.error('Scripted REST error: ' + e.message);
    response.setStatus(500);
    response.setBody({ error: 'internal_error', message: 'unexpected error' });
  }
})(request, response);

エラーパスでの詳細漏えいを避けつつ、インシデントIDなどの相関情報をログに残すと後追いが容易になる。スロットリングはAPI Gateway側で担保し、プラットフォーム側には適度な制限と監査を置くのが健全だ。

外部連携：Node.js クライアント（リトライと計測）

外部システムからインシデントを登録するNodeクライアントの実装では、指数バックオフと計測を組み込むと運用で強い。以下はAxiosベースの例だ。

import axios from 'axios';
import { performance } from 'node:perf_hooks';

const client = axios.create({
  baseURL: `https://${process.env.SN_INSTANCE}.service-now.com/api/now/table/incident`,
  auth: { username: process.env.SN_USER, password: process.env.SN_PASS },
  timeout: 5000,
});

async function createIncident(payload, attempt = 1) {
  const start = performance.now();
  try {
    const res = await client.post('', payload, { headers: { 'Content-Type': 'application/json' } });
    const ms = performance.now() - start;
    console.log(`createIncident ok in ${ms.toFixed(1)}ms`);
    return res.data;
  } catch (err) {
    const retriable = !err.response || err.response.status >= 500;
    if (retriable && attempt < 3) {
      const backoff = 2 ** attempt * 200;
      await new Promise(r => setTimeout(r, backoff));
      return createIncident(payload, attempt + 1);
    }
    console.error('createIncident failed', err?.response?.status, err?.message);
    throw err;
  }
}

// example
createIncident({ short_description: 'CPU alert', urgency: '2' }).catch(() => process.exit(1));

実環境の性能はインスタンス仕様やネットワーク、同時実行数に依存するため、代表的な本番想定の並列度でレイテンシのp95（95百分位）を監視し、SLO（Service Level Objective）とインスタンス容量を対で管理するのが現実的だ。

運用バッチ：Pythonによる一括処理

テクニカルサポートがクリーンアップで困るのは、解決済みだがクローズされないチケットの滞留だ。PythonのrequestsでTable APIに対しクエリし、パッチ更新を回すと定常運用が楽になる。

import os
import requests
from requests.auth import HTTPBasicAuth

base = f"https://{os.environ['SN_INSTANCE']}.service-now.com/api/now/table/incident"
auth = HTTPBasicAuth(os.environ['SN_USER'], os.environ['SN_PASS'])

def bulk_close(query: str) -> None:
    params = {
        'sysparm_query': query,
        'sysparm_fields': 'sys_id,number,state',
        'sysparm_limit': '100'
    }
    r = requests.get(base, params=params, auth=auth, timeout=10)
    r.raise_for_status()
    for rec in r.json().get('result', []):
        try:
            payload = {
                'state': '7',  # Closed
                'close_code': 'Solved Remotely',
                'close_notes': 'Bulk close via script'
            }
            u = requests.patch(f"{base}/{rec['sys_id']}", json=payload, auth=auth, timeout=10)
            u.raise_for_status()
        except requests.HTTPError as e:
            print(f"Failed to close {rec['number']}: {e}")
            continue

if __name__ == '__main__':
    bulk_close("state=6^resolved_atRELATIVELE@dayofweek@ago@7")

失敗はスキップして継続し、最後にサマリーを通知する設計にしておくと夜間バッチでも安心だ。繰り返し実行に耐えるよう、冪等性とフィルタ条件の慎重な設計が不可欠である。

運用ワークフロー連携：PowerShellでRITM更新

承認済みリクエストアイテムの状態遷移を外部の自動化基盤から叩く例を示す。PowerShellならWindows環境でも扱いやすい。

param(
  [Parameter(Mandatory=$true)] [string]$ritmId
)

$instance = $env:SN_INSTANCE
$uri = "https://$instance.service-now.com/api/now/table/sc_req_item/$ritmId"
$pair = "$env:SN_USER:$env:SN_PASS"
$bytes = [System.Text.Encoding]::ASCII.GetBytes($pair)
$basic = [Convert]::ToBase64String($bytes)
$headers = @{ Authorization = "Basic $basic"; "Content-Type"="application/json" }
$body = @{ state = "3"; stage = "Fulfillment"; work_notes = "Approved by workflow" } | ConvertTo-Json

try {
  $res = Invoke-RestMethod -Method Patch -Uri $uri -Headers $headers -Body $body -TimeoutSec 15
  Write-Host "RITM updated: $($res.result.sys_id)"
} catch {
  Write-Error "Failed to update RITM $_"
  exit 1
}

IntegrationHubのSpoke（主要SaaS向けコネクタ）を使えばMicrosoft 365やSlackともノーコードで連携できる⁶が、組織の標準言語であるPowerShellやPythonのスクリプト資産を並走させると、移行期間の摩擦が小さくなる。

SLAとパフォーマンスの可視化（集計スクリプト）

改善は可視化して初めて継続できる。SLA違反の月次件数をtask_slaから集計するサーバースクリプトを示す。

// Background Script
var ga = new GlideAggregate('task_sla');
ga.addAggregate('COUNT');
ga.addQuery('has_breached', true);
ga.addQuery('start_time', '>=', gs.daysAgoStart(30));
ga.addQuery('task.sys_class_name', 'incident');
ga.query();
if (ga.next()) {
  gs.info('Breached SLAs (incident, last 30d): ' + ga.getAggregate('COUNT'));
}

この集計をパイプラインに組み込み、前月比と自動化適用スコープを合わせてダッシュボード化すれば、自動化の投資効果を実数で語れるようになる。併せてATFで主要フローの回帰を日次で走らせ、壊れていないことを定量で保証する。なお、SLAの達成状況はITSMにおける標準的な評価指標であり、MTTRなどと併せて追跡するとよい⁵。

スケール、ガバナンス、ROI

自動化は実装よりも運用の設計が難しい。命名規約、スコープ分離、ACL、インテグレーションの所有権、レート制限、監査証跡、テストポリシーを合意し、変更は小さく頻繁に入れる。CoE（Center of Excellence）で「何をプラットフォーム内でやり、何を外でやるか」を決め、開発者ではない業務担当者が扱う領域はFlow Designerやカタログアイテムに閉じ込める。市民開発の自由度と運用の一貫性はトレードオフであり、テンプレートと承認プロセスでコントロールするのが現実解だ。関連するセキュリティ設計の論点も参考になる。

コストとROIの試算

以下は仮定を置いた試算例であり、実数ではなくモデルケースである。月間3,000件のチケットを平均12分で処理しているとし、自動化により30％を人手から解放できると仮定すると、節約時間は月間で約1,080時間となる。人件費を1時間あたり6,000円とすれば月間約648万円の変動費圧縮、年換算で約7,700万円が目安だ。初期導入費用を1,200万円、運用保守とライセンスで年間2,400万円と仮置きしても、ブレークイーブンは数ヶ月から一年以内に収まる計算になる。前提によって差は大きいため、削減時間×単価＋SLA罰則回避＋障害コスト低減という式で自組織のデータを当て込み、保守的に見積もることを推奨する¹。

90日ロードマップの描き方

最初の30日でAS-ISの可視化とKPIのベースラインを固め、クイックウィンとしてパスワードリセットや標準リクエストの自動化を投入する。次の30日で変更管理とルーティングの自動化、外部通知やチャットOpsの連携を拡張し、パフォーマンスとエラーのメトリクス収集を常時化する。最後の30日で統合テストと運用引き継ぎ、ダッシュボード公開、運用ガイドの版管理を整え、保守チケットを最小化する。価値の出る順に、壊れにくい順に、巻き戻し可能な順に適用範囲を広げるのが定石だ。

まとめ

IT業務の自動化は、単に早くなることより、ばらつきを減らして再現性を上げる営みだ。ServiceNowは業務の文脈とデータの一貫性を持ち込み、「人が疲れても品質が落ちない」仕組みを現場に根づかせる。今日示したコードは最短距離の一例に過ぎないが、KPIで効果を測り、エラーとパフォーマンスを設計し、スケールとガバナンスを先に決めるという原則さえ外さなければ、自動化は必ず資産になる。次の一手として、あなたの組織で最も手数の多い3つの業務を洗い出し、1つを今週中にプラットフォームへ載せてみてほしい。小さな自動化が、明日の標準になる。

参考文献

  1. ServiceNow. Automation statistics for IT Operations Management. https://www.servicenow.com/products/it-operations-management/automation-statistics.html
  2. TDCソフト. ServiceNowの導入で実現できること（コラム）. https://www.tdc.co.jp/servicenow/column/001/
  3. ServiceNow. Gartner Magic Quadrant for IT Service Management Platforms（日本語紹介ページ）. https://www.servicenow.com/jp/lpayr/gartner-mq-itsm.html
  4. ServiceNow. The Forrester Wave: Enterprise Service Management（日本語紹介ページ）. https://www.servicenow.com/jp/lpayr/forrester-wave-esm.html
  5. Zendesk. ITSM metrics: 18 KPIs to measure service desks. https://www.zendesk.hk/blog/itsm-metrics/
  6. ServiceNow. Flow Designer（製品ページ）. https://www.servicenow.com/jp/products/platform-flow-designer.html