SLA運用手順書

確認した環境：ServiceNow の PDI（Personal Developer Instance）、Zurich リリースの OOTB（初期設定）。2026-07-08 確認。

1. 目的・背景

この記事は、ServiceNow の SLA がインシデント対応の操作でどう動くかを、実機で1件走らせて確認した運用手順書です。P1（Priority 1 - Critical）のインシデントを実際に起票し、起票 → 担当アサイン → 保留 → 再開 → 解決と操作を進めました。それぞれの時点で SLA の計測レコード（task_sla）がどう変わったかを記録しています。

SLA は画面上では「残り時間」や「経過率」として見えます。ただ、どの操作で計測が始まり、どの操作で止まるのかは、対応する側からは意外に見えません。今回の実走でいちばん確かめたかったのは、Resolved（解決済み）にしても resolution SLA は止まらないという動きです。今回確認した PDI（Zurich / OOTB）では、resolution SLA の停止条件は Closed だけで、Resolved は一時停止の条件に含まれていました。この点はステップ5で実測値とあわせて扱います。

今回実走したインシデントが次の画面です。Impact と Urgency をどちらも 1 にすると、Priority が 1 - Critical に自動算出されました。

想定読者は、ServiceNow でインシデント対応を担当していて SLA の見方を身につけたい人です。SLA を含めた対応手順を手順書に整えたい立場の人にも向いています。前提となるテーブルは2つあります。実測側（task_sla）の構造は「ServiceNow の SLA を実機で読み解く：task_sla（実績）と contract_sla（定義）の関係・Stage・一時停止」で扱っています。定義側（contract_sla）の条件の読み方は「ServiceNow の SLA Definition（contract_sla）を実機で読み解く」です。インシデント対応そのものの操作手順は「ServiceNowのPDIをもとにしたOOTBインシデント運用手順書」をご覧ください。

2. 操作フロー・概要

前提を短く押さえます。SLA の「ルール」を保存するのが contract_sla（画面ラベルは SLA Definition）です。ルールの条件に一致したタスクへ自動で付く「実測レコード」が task_sla です。運用中に操作するのはインシデントだけで、task_sla を手で作ったり止めたりすることはありません。インシデント側の操作が条件に当たると、SLA 側が勝手に動きます。

今回確認した PDI には、active な SLA 定義が14件あり、対象テーブルはすべて Incident でした。一覧は Service Level Management > SLA > SLA Definitions で開けます。

14件のうち、通常のインシデント運用で発動するのは Priority 別の9件です。内訳は次のとおりです。

P5 の resolution 定義は存在しませんでした（response のみ）。残る5件は OLA が2件、Underpinning contract が1件、テストフレームワーク用が2件で、今回の起票では発動していません。SLA 機能全体の公式の説明は Service Level Management（Zurich） にあります。

P1 のインシデントを起票すると、response（応答・15分）と resolution（解決・1時間）の2本の task_sla が同時に付きます。この2本が操作でどう動くかをまとめたのが次の図です。

この記事（無料部）で分かること

• SLA 定義（ルール）と task_sla（実測）の役割分担と、OOTB で incident に付く定義9件の一覧

• P1 インシデントを起票して、response / resolution の2本の SLA が自動で付くことを確認する手順

• response SLA が付与されるための条件（Assignment group が空だと付かない）

3. 操作手順

ここからは操作を番号付きで並べます。各ステップは、実施者／画面への行き方／入力項目と値／押すボタン／成功条件／注意点の順です。値は今回実際に PDI へ登録したものでそろえました。

1) P1 インシデントの起票と SLA 付与の確認

• 実施者：サービスデスク（起票者）。

• 画面への行き方：アプリケーションナビゲーターで Incident > Create New を開く。

• 入力項目と値：

• Caller=Abel Tuter（申告者。実在のユーザーを選ぶ）

• Channel=Phone（受付経路）

• Impact=1 - High ／ Urgency=1 - High（Priority は 1 - Critical に自動算出される）

• Assignment group=Service Desk

• Short description=メールサーバに接続できない（SLA運用の実機確認）

• 押すボタン：右上の「Submit」。

• 成功条件：番号（INC で始まる）が採番されること。フォーム下部の関連リスト「Task SLAs」に2行が Stage=In progress で並ぶこと。2行は Priority 1 response (15 minutes) と Priority 1 resolution (1 hour) です。Start time は2本ともインシデントの作成時刻と同じになる（遡及開始＝Retroactive start が有効なため）。

• 注意点：P1 response の開始条件には「Assignment group が空でない」が含まれる。Assignment group を入れずに起票すると response SLA は付与されない（resolution SLA の開始条件は Active かつ Priority=1 のみ）。

response 側の定義を実機で開くと、開始条件に Assignment group の条件が入っていることを確認できます。フォーム項目そのものの意味は「ServiceNow Incidentテーブルの構造を実機で読み解く」で扱っています。

今回のインシデントに付いた Task SLAs の一覧が次です。撮影は一連の操作を終えた後のため、response は Completed、resolution は Paused まで進んでいます。起票直後の時点では、この2行が両方とも In progress で並びました。

SLA は「1インシデントに1本」ではありません。P1 では応答用と解決用の2本が同時に走り、止まる条件もそれぞれ違います。応答の時計は担当が決まれば止まり、解決の時計はインシデントが閉じるまで残る。この2本立てを前提にすると、この後の各操作での変化が読みやすくなります。

無料部はここまでです。有料部では、同じインシデントを対応の流れに沿って進め、次を実測値つきの手順として確認します。

• 担当アサイン（In Progress）で response SLA が止まる瞬間の実測値（経過率 12.67%）

• On Hold（Awaiting Caller）での一時停止と、再開時に期限が後ろへシフトする動き

• Resolved にしても resolution SLA が Completed にならない実測と、その OOTB の停止条件

• 日常運用での SLA の見方、よくあるミスとリカバリ表