SLA Definition（contract_sla）とは：時計を生むルール

2026年6月28日 10:36

ServiceNow で Incident を開くと「あと◯時間で違反」「SLA 達成」といった時計が動いています。あの時計の1本1本（task_sla）は、誰かが手で作っているわけではありません。「Priority 1 の Incident がアクティブになったら、解決まで1時間の時計を始める」というルールがあらかじめ定義されているから、自動で生まれます。そのルールを保存しているのが contract_sla（画面ラベルは SLA Definition） です。

この記事は、ServiceNow の SLA 表示は見たことがあるが、その元になる定義（ルール）側をこれから理解したい管理者・開発者を想定しています。PDI（Zurich / OOTB）で contract_sla を実際に開き、1件＝1つの SLA ルールであることを確かめます。あわせて対象テーブル（collection）・種別（type）・測定対象（target）・期間（duration）と、いつ始まり・止まり・一時停止するかを決める条件（start / pause / stop）を見ていきます。すでに公開済みの「ServiceNow の SLA を実機で読み解く：task_sla（実績）と contract_sla（定義）の関係」が実測（時計）側の記事なので、本記事はその対になる定義（ルール）側を扱います。

この記事で分かること

SLA の「ルール」は contract_sla（SLA Definition）に、1件＝1ルールで保存されること
contract_sla が sys_metadata 継承の設定メタデータで、PDI 実機に 14件あること
種別 type（SLA / OLA / Underpinning contract）と測定対象 target（Response / Resolution）の選択肢
SLA を生む・止める・一時停止する start / pause / stop 条件の実際の中身
期間 duration・カレンダー schedule・通知 flow・遡及 retroactive など主要フィールド
定義（contract_sla）と実測（task_sla）の役割分担

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、SLA 定義の件数・条件・フィールドの内容が異なります。

SLA Definition（contract_sla）とは

SLA Definition とは、「どのテーブルの・どんな条件のレコードに・何時間以内という時計を・どう動かすか」を1件にまとめたルール（ひな型）です。アプリナビで「Service Level Management > SLA > SLA Definitions」を開くと見えるのが、この contract_sla です。

下の画面は、PDI（Zurich / OOTB）の SLA Definition 一覧です。Priority 1〜5 の response / resolution を中心に、14件のルールが並んでいました。

この14件は「ルール（定義）」であって「時計（実測）」ではありません。ルールが実際の Incident に当たって初めて、計測レコード（task_sla）が1本ずつ生まれます。下の図のように、定義 → 条件一致 → task_sla 生成 → 計測という流れで動きます。

contract_sla は設計図、task_sla は設計図から組み立てられた1台ごとの時計です。今回の PDI（Zurich / OOTB）では、定義（contract_sla）が 14件、実測（task_sla）が 16件ありました。

contract_sla はどんなテーブルか

contract_sla の継承元（super_class）は sys_metadata でした。Incident や task_sla のような業務データではなく、設定メタデータ（プラットフォームの構成情報）として管理されるテーブルです。だから Update Set やアプリに含めて他インスタンスへ運べます。

固有フィールドは 35件ありました。SLA の挙動を細かく制御するため、条件・期間・スケジュール・通知・遡及など多くの設定項目を持っています。1件の SLA ルールは、大きく次の5つの部品でできています。

主なフィールドを役割で整理すると次のとおりです。

中心になるのは collection（対象テーブル）・type（種別）・target（測定対象）・duration（期間）・各 condition（条件）です。今回の PDI（Zurich / OOTB）では、14件すべてが collection=incident（全件 Incident 対象）・全件 active=true でした。全フィールドは次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。フィールド定義そのものの読み方は「ServiceNow のテーブルとフィールドを実機で確認する（sys_db_object と sys_dictionary）」も参考になります。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=contract_sla^elementISNOTEMPTY

type と target：何の SLA なのか

SLA ルールには、type（種別） と target（測定対象） という2つの分類軸があります。これは選択肢（choice）で決まっていて、その仕組みは「ServiceNow の選択肢（Choice）を実機で確認する」で扱ったとおり、sys_choice に値が保存されています。

実機で type の選択肢を開くと、内部値（value）と表示名（label）が確認できます。

type = SLA … 顧客との合意（Service Level Agreement）。今回は 11件で最多。
type = OLA … 社内グループ間の合意（Operational Level Agreement）。Network / Database group の 2件。
type = Underpinning contract … 外部ベンダとの契約。SAN 001 contract の 1件。

target は「何の時間を測るか」です。

target = Response（応答） … 最初の応答までの時間。今回 6件。
target = Resolution（解決） … 解決（クローズ）までの時間。今回 8件。

同じ Incident でも、type と target の組み合わせの数だけ別々のルールがあります。だから1件の Incident に「P1 の応答」「P1 の解決」「OLA の解決」…と複数の時計が並走します（この並走はtask_sla の記事で実画面とともに確認しています）。

start / pause / stop：SLA が動く・止まる条件

SLA がいつ生まれ・止まり・一時停止するかは、すべて contract_sla 側の条件フィールド（conditions 型）で決まります。代表として「Priority 1 resolution (1 hour)」のフォームを実機で開きました。

この定義の条件を実測すると、次のようになっていました。

start_condition（生成条件） … Active = true AND Priority = 1 - Critical

→ この条件が成立した瞬間に task_sla が生成され、時計が動き出します。

pause_condition（一時停止条件） … (State = On Hold かつ On hold reason = Awaiting Caller) または State = Resolved

→ この間は時計が止まります（待ち時間を SLA に含めないため）。

stop_condition（停止条件） … Incident state = Closed

→ クローズで時計を止め、締切（duration）内なら達成、超過なら違反です。

条件で使っている state の値（On Hold / Resolved / Closed など）の意味は「ServiceNowメニューから読む Incident運用設計 ①：状態(State)をPDIで読む」で確認できます。条件式は内部的に incident_state=7（Closed）のようなエンコード文字列で保存されており、画面では条件ビルダーで表示されます。

このほか resume_condition（再開）・reset_condition（リセット）・cancel_condition（取消）もあり、SLA のライフサイクルを細かく制御できます。SLA Definition とは、「start で生まれ、pause で止まり、stop で終わる」を条件式で書いたものです。

duration・schedule・flow：期間とカレンダーと通知

条件で「いつ」を決めたら、次は「どれだけの長さか」と「どう測るか」です。

duration（期間） … 締切までの長さ。Priority 1 resolution は 1 Hour。Priority 別に 15 Minutes 〜 2 Days まで様々でした。
schedule（稼働カレンダー） … 営業時間だけで測るかどうか。今回の14件のうち 7件が「8-5 weekdays」（平日8〜17時のみ計測）、7件が「No schedule」（24時間連続で計測） でした。同じ「1日」でも、稼働時間ベースか実時間ベースかで締切が変わります。
flow（通知/エスカレーション） … SLA が違反しそうなときの通知や上申を担当する Flow。今回は14件すべてに flow が設定済みでした。

代表的な OOTB の SLA 定義を一覧にすると、type・target・duration・schedule の組み合わせが見えてきます。

flow と workflow の使い分けも見ておきます。今回の PDI では、14件すべてが flow（Flow Designer）を使い、レガシー Workflow を使う定義は 0件でした。通知・エスカレーションは Flow Designer 側に寄っています（レガシー Workflow は移行対象として残っているだけで、新規定義では使われていません）。

また retroactive（遡及開始）／ retroactive_pause（遡及一時停止）というブール値もあります。「条件成立より前にさかのぼって時計を始める／止める」挙動を制御するフィールドです（既定は retroactive=false、retroactive_pause=true）。詳しい挙動は公式の Configure SLA retroactive start and pause（Zurich）を参照してください。

https://<YourInstance>/contract_sla_list.do?sysparm_query=GROUPBYtype

定義（contract_sla）と実測（task_sla）の役割分担

本記事の contract_sla と、対になる task_sla は混同しやすいですが、持っているものがまったく違います。

contract_sla（SLA Definition） … ルール（ひな型）。super_class は sys_metadata、固有35フィールド。条件・期間・スケジュールを持ち、再利用される。今回 14件。
task_sla（Task SLA） … 実測（時計）。super_class は空のルート基底、固有26フィールド。stage・残り時間・経過率を持ち、タスク×定義ごとに1本ずつ作られる。今回 16件。

task_sla は sla フィールドで「どの定義に基づくか」を contract_sla に向けて参照し、task フィールドで「どのタスクの時計か」を参照します。contract_sla を直すと、これから生まれる task_sla の挙動が変わります。「SLA が想定どおり動かない」という調査は、まず定義側（contract_sla の条件）を疑うのが近道です。

実機で確認するときに見るべきURL

今回見た画面を自分のインスタンスで開くためのURLです（<YourInstance> は置き換えてください）。

# SLA 定義の一覧
https://<YourInstance>/contract_sla_list.do

# 種別でグループ化
https://<YourInstance>/contract_sla_list.do?sysparm_query=GROUPBYtype

# type / target の選択肢
https://<YourInstance>/sys_choice_list.do?sysparm_query=name=contract_sla^element=type^inactive=false^ORDERBYsequence

# contract_sla の固有フィールド
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=contract_sla^elementISNOTEMPTY

まとめ

SLA のルールは contract_sla（SLA Definition）に 1件＝1ルールで保存される。PDI では 14件、全件 active・全件 incident 対象。
contract_sla は sys_metadata 継承の設定メタデータで、固有 35フィールド。中心は collection / type / target / duration / 各 condition。
type は SLA 11 / OLA 2 / Underpinning contract 1、target は Response 6 / Resolution 8。
SLA の生成・停止・一時停止は start / pause / stop 条件で決まる。Priority 1 resolution は Active+Priority=1 で生成、Closed で停止、On Hold/Resolved で一時停止。
duration（期間）・schedule（7件が 8-5 weekdays、7件が No schedule）・flow（14件すべて設定）・retroactive で挙動を細かく制御する。レガシー Workflow を使う定義は 0件。
contract_sla はルール、task_sla は時計。SLA の不調はまず定義側の条件を疑う。

SLA を調べるときは、まず「この定義は、どのテーブルの・どんな条件で・何時間の・どう測る時計を生むルールなのか」を読みます。次に読むなら、対になる実測側の「ServiceNow の SLA を実機で読み解く：task_sla（実績）と contract_sla（定義）の関係・Stage・一時停止」です。生成された時計（stage・残り時間・違反判定）の側を確認すると、SLA の全体像がつながって見えてきます。

ServiceNowのSLAはいつ違反になる？時計が動く条件と止まる条件を実機で確認 — SLA全体で「いつ違反になるか」を俯瞰したいときは、時計が動く条件・止まる条件をまとめたガイド記事も参考になります。