task_sla：1タスク1本のSLA時計の読み方

ServiceNow で Incident を開くと、画面のどこかに「あと◯時間で違反」「SLA 達成」といった SLA の表示が出ます。あの数字がどのテーブルに、何をきっかけに、どう積み上がっているのかは、フォームを眺めているだけだと意外と見えてきません。

この記事では、task_sla（Task SLA）と contract_sla（SLA Definition）という2つのテーブルを起点に SLA を読み解きます。「SLA の定義（ひな型）」と「SLA の実測値（1タスク1本のレコード）」がどう結びつくか、stage（段階）がどう変わり、どこで一時停止し、いつ達成・違反と判定されるのか。PDI（Zurich）の OOTB で確認した実測値で示します。

この記事は、ServiceNow の Incident は触ったことがあるが、SLA の裏側のテーブル構造をこれから理解したい人を想定しています。管理者・開発者が実機で見るべき順に、2テーブルの役割分担・主要フィールド・stage・開始/停止/一時停止の仕組みをたどります。

この記事で分かること

• SLA の「定義」は contract_sla、「実測値」は task_sla に分かれて保存されること

• task_sla はルート基底テーブルで、対象タスク（task）と SLA 定義（contract_sla）を参照でつなぐこと

• task_sla の stage（6値）と、過去違反フラグ has_breached が別概念であること

• SLA 定義の start / stop / pause 条件が、task_sla の生成・停止・一時停止を決めること

• 1つの Incident に複数の task_sla（SLA / OLA / Underpinning contract）が並走すること

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

SLA（Service Level Agreement）とは

ServiceNow の SLA とは、ある作業（Incident の解決など）を「いつまでに終えるべきか」という約束です。その約束をタスクごとに時計として持たせ、経過・残り時間・達成/違反を記録します。Incident フォームに出る「あと◯時間」や、SLA 一覧に並ぶ1件1件が、この記録にあたります。

SLA は「定義」と「実測値」の2枚に分かれています。「どんな条件で、何時間以内に」というルール（ひな型）が contract_sla（SLA Definition）です。そのルールが実際のタスクに当たって動き出した時計が task_sla（Task SLA）です。今回確認した PDI（Zurich / OOTB）では、contract_sla（定義）が 14 件、task_sla（実測レコード）が 16 件 ありました。

SLA まわりのテーブル関係（定義と実測）

SLA に関係するテーブルは、「定義（ひな型）」「実測（時計）」「対象（タスク）」の3つに分けて見ると整理できます。

今回確認した PDI（Zurich / OOTB）では、それぞれ次の構造でした。

• contract_sla（SLA Definition） … super_class が sys_metadata の設定メタデータです。固有フィールドは 35。collection（Table）で「どのテーブルに適用するか」を持ち、今回の 14 件はすべて collection=incident でした。

• task_sla（Task SLA） … super_class が 空のルート基底テーブルでした。task は継承していません。固有フィールドは 26。sla（→ contract_sla）でどの定義に基づくか、task（→ task）でどのタスクに紐づくかを参照で持ちます。

定義（contract_sla）は再利用される1枚のひな型、実測（task_sla）はタスク×定義ごとに1本ずつ作られる時計という役割分担です。task_sla が task を「継承」ではなく「参照」で持つ点が、承認や問題管理のテーブルと違うところでした。

テーブル定義は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=task_sla^ORname=contract_sla

SLA 定義（contract_sla）の中身

SLA がいつ生まれ・止まり・一時停止するかは、すべて contract_sla（SLA Definition）側の条件で決まります。実際の定義レコードを1件、実機で確認しました。

今回確認した「Priority 1 resolution (1 hour)」の定義は、次のようになっていました。

• collection（Table）= incident … Incident に適用される SLA

• type = SLA ／ target = Resolution ／ duration = 1 Hour … 解決を1時間以内に、という約束

• start_condition … Active = true かつ Priority = 1 - Critical（この条件が成立したタイミングで task_sla が生成される）

• stop_condition … Incident state = Closed（クローズで時計を止める）

• pause_condition … On Hold（Awaiting Caller）または Resolved のあいだは一時停止

• flow = SLA notification and escalation flow … 通知/エスカレーションは Flow 側が担当

ポイントは、SLA 定義が「条件 → 期間 → スケジュール」の組み合わせだという点です。start で生まれ、stop で止まり、pause で時計が止まる。今回の PDI（Zurich / OOTB）では、14 件すべての SLA 定義が flow を持ち（flow が設定済み）、レガシー Workflow を使う定義は 0 件でした。通知・エスカレーションは Flow Designer 側に寄っている構成です。

公式の SLA definitions（Zurich） に、SLA 定義が開始/停止/一時停止条件・期間・スケジュールでどう構成されるかが説明されています。

https://<YourInstance>/contract_sla_list.do

task_sla の主なフィールド

task_sla は、「どの定義の・どのタスクの・どこまで進んだ時計か」を表す項目を持ちます。役割で分けると、参照（定義/対象）・段階・時間（経過/残り/締切）・一時停止に整理できます。

主なフィールドの代表は次のとおりです。ラベルは画面上の表示名で、実機どおり記載します。

• sla（SLA definition → contract_sla） … どの SLA 定義に基づくか。

• task（Task → task） … どのタスク（Incident 等）の SLA か。

• stage（Stage） … SLA の段階（後述）。既定値は in_progress です。

• planned_end_time（Breach time） … この時刻を過ぎると違反、という締切。

• business_percentage（Business elapsed %）／ percentage（Actual elapsed %） … 稼働時間ベース／実時間ベースの経過率。

• time_left（Actual time left）／ business_time_left … 残り時間。

• pause_time / pause_duration … 一時停止した時刻と、止めていた時間の累計。

• has_breached（Has breached） … 過去に締切を超えたかのフラグ（stage とは別概念）。

1レコードには、次が揃っています。

• どの定義の（sla）

• どのタスクの（task）

• どこまで進んで（percentage）

• いつが締切で（planned_end_time）

• あとどれだけか（time_left）

だから SLA 一覧を見るだけで、対象・進捗・残り・締切が横並びで読み取れます。

全フィールドは、次のURLで一覧できます。

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

SLA の段階（stage）と達成・違反の判定

SLA の進み方は、stage で表されます。承認の state や task の state とは別の、SLA 専用の値です。

今回確認した PDI（Zurich / OOTB）の task_sla.stage は、次の6値でした（value = label, sequence順）。

中心になるのは in_progress（進行中）で、start_condition が成立した時点でこの段階の task_sla が生成されます。stop_condition が成立して締切（planned_end_time）内に止まれば achieved（達成）、締切を過ぎていれば breached（違反）です。pause_condition が成立しているあいだは paused（一時停止）になり、時計が止まります。条件が変わって不要になれば cancelled（取消）や completed（完了）です。

実際にどう生まれ、止まり、一時停止するかを並べると、次のようになります。

stage（段階）と has_breached（違反フラグ）は別物です。has_breached は「過去に一度でも締切を超えたか」を表すフラグで、今回の PDI では 16 件中 13 件が has_breached=true でした。一方、stage の内訳は in_progress 9 / breached 2 / cancelled 2 / achieved 1 / paused 1 / completed 1 です。「今 breached の段階か」と「過去に違反したか」は一致しないので、一覧で見るときはどちらを見ているか意識する必要があります。

stage の選択肢は、次のURLで一覧できます。

https://<YourInstance>/sys_choice_list.do?sysparm_query=name=task_sla^element=stage^inactive=false^ORDERBYsequence

遡及開始（Retroactive start）と遡及一時停止（Retroactive pause）は、一時停止時間と違反時刻の両方に効きます。設定手順は公式にあります。

• Configure SLA retroactive start and pause（Zurich）

1つのタスクに複数の SLA が並走する

SLA は「1タスク1本」ではありません。1つの Incident に対して、応答用・解決用、さらに OLA や Underpinning contract など、複数の task_sla が同時に走るのが普通です。

今回の PDI で、ある Incident（INC0000060）に紐づく task_sla を一覧で見ると、種別（Type）も段階（Stage）も違う SLA が同居しているのが分かります。

この一覧では、同じ INC0000060 に対して Type が SLA / OLA / Underpinning contract と異なる task_sla が並んでいました。Stage も Achieved / Breached / Cancelled が混在していました。Business elapsed percentage（稼働時間ベースの経過率）は、達成側が緑、超過側が赤のバーで表示されます。

ポイントは、「Incident が SLA 違反かどうか」は1本の数字では決まらないという点です。どの定義（target が Response か Resolution か、type が SLA か OLA か）を見ているかで結論が変わります。SLA を調べるときは、まず「どの task_sla（どの定義・どの target）を見ているか」を確かめる必要があります。

公式の Monitoring Service Level Agreement (SLA)（Zurich） に、タスクに紐づく SLA をエンドユーザーがどう確認するかが説明されています。

https://<YourInstance>/task_sla_list.do?sysparm_query=task.numberSTARTSWITHINC0000060

task_sla に関わる周辺機能

SLA の動きも、フィールド定義だけでは決まりません。段階の判定・違反イベントの生成・通知・権限など、複数の設定が組み合わさって動きます。大まかには、保存時の段階判定・イベント生成は Business Rule、SLA 違反などの通知は Notification が担います。

実測側（task_sla）の設定件数

今回確認した PDI（Zurich / OOTB・active 中心・2026-06-20 確認）では、task_sla に次のような設定が紐づいていました。

特徴的なのは Business Rules が 14 件 と多いことです。SLA は「時間の経過で状態が変わる」仕組みなので、段階（stage）の判定や違反イベントの生成といったサーバ側処理が厚くなっているのが分かります。

注意したいのは、ここで数えているのは task_sla（実測側）に直接紐づく設定だけという点です。実際の SLA の挙動は、定義側（contract_sla）の条件や Flow、対象テーブル（incident など）側の設定とも合わさって決まります。task_sla 単体だけを見て全体を判断しないようにします。

定義側（contract_sla）の設定件数（参考）

同様に contract_sla（定義側）を数えると、Business Rules 12 ／ Client Scripts 20 ／ UI Policy 11 ／ UI Actions 3 でした。Access Controls（テーブル）23 ／ Dictionary Entries 35 も数えています。task_sla（実測側）は Business Rules が厚くサーバ処理が中心です。一方 contract_sla（定義側）は Client Scripts と UI Policy が厚く、画面の入力支援が中心でした。効いている仕組みの種類が逆になっています。

自分のインスタンスでは、次のURLで各一覧を開けます（先頭の <YourInstance> は置き換えてください）。

Business Rules : https://<YourInstance>/sys_script_list.do?sysparm_query=collection=task_sla^active=true
UI Actions     : https://<YourInstance>/sys_ui_action_list.do?sysparm_query=table=task_sla
Notifications  : https://<YourInstance>/sysevent_email_action_list.do?sysparm_query=collection=task_sla

ServiceNow における SLA のポイント

• SLA は 定義（contract_sla）と実測（task_sla）の2枚に分かれます。今回の PDI では定義 14 件・実測 16 件でした。

• contract_sla は sys_metadata 継承の設定メタデータ（固有35）で、collection で対象テーブルを持ちます（今回は全件 incident）。task_sla は super_class が空のルート基底テーブル（固有26）で、task と sla を参照で持ちます。

• SLA の生成・停止・一時停止は、すべて定義側の start / stop / pause 条件で決まります。今回の PDI では 14 件すべてが flow を持ち、レガシー Workflow を使う定義は 0 件でした。

• stage は6値（in_progress / achieved / breached / cancelled / paused / completed）。過去違反フラグ has_breached（今回 16 件中 13 件 true）とは別物なので、どちらを見ているか意識します。

• 1つの Incident に SLA / OLA / Underpinning contract の task_sla が複数並走します。「SLA 違反か」は1本の数字では決まりません。

• task_sla の percentage（実時間）と business_percentage（稼働時間）は別の経過率です。スケジュール（cmn_schedule）次第で値が変わります。

SLA を調べるときは、まず「この task_sla は何（task）に対する、どの定義（sla / target）の、どの段階（stage）の時計か」を読みます。task_sla 単体ではなく、上の定義（contract_sla の条件・Flow）、対象の task をセットで見ることが重要です。

実機を見て気づいたこと

• task_sla には planned_end_time（現在の締切）とは別に original_breach_time（最初に計算された締切）というフィールドがあります。最初は締切は1つしか持たないと思っていましたが、実機には「最初の締切」と「今の締切」の両方が残る作りでした。Retroactive start / pause で締切が後から動くことがあるための設計だと読めます。

• task_sla 自身が schedule と timezone というフィールドを持っていることにも気づきました。稼働カレンダーは contract_sla（定義）側だけが持ち、task_sla は毎回そこを参照しにいくのだろうと思っていましたが、実際には生成時点の値が task_sla 側にもコピーされていました。定義を後から変更しても、すでに動いている時計には影響しない作りだと分かります。

次に読むなら

次に確認するなら、次の3つです。

• SLA Definition の条件設定（開始/停止/一時停止条件の書き方）

• 稼働カレンダー（cmn_schedule）と business 時間の計算

• 遡及開始（Retroactive start）・遡及一時停止（Retroactive pause）の挙動

特に「定義側の条件」と「実測側の時計」を分けて理解すると、SLA が止まらない・想定外に違反する、といった調査が一気に楽になります。これらは本記事の「SLA 定義」「stage と達成・違反の判定」で触れた仕組みの先にあたり、別記事で扱う予定です。

用語

• PDI：Personal Developer Instance（無料の検証用インスタンス）

• OOTB：Out of the Box（初期設定のまま）

• SLA Definition（contract_sla）：SLA の定義（ひな型）。条件・期間・スケジュールを持つ

• Task SLA（task_sla）：定義がタスクに当たって生成された実測レコード（時計）

• stage：task_sla の段階（in_progress / achieved / breached 等）

• breach time（planned_end_time）：これを過ぎると違反となる締切時刻

自分の環境で確認するときのURL

先頭に自分のインスタンスを付けると、同じ画面が開けます。

テーブル定義       : sys_db_object_list.do?sysparm_query=name=task_sla^ORname=contract_sla
固有フィールド一覧  : sys_dictionary_list.do?sysparm_query=name=task_sla^elementISNOTEMPTY
stage 選択肢        : sys_choice_list.do?sysparm_query=name=task_sla^element=stage^inactive=false^ORDERBYsequence
SLA 定義一覧        : contract_sla_list.do
Task SLA 一覧       : task_sla_list.do?sysparm_query=task.numberSTARTSWITHINC0000060

関連記事

• ServiceNowのSLAはいつ違反になる？ 時計が動く条件と止まる条件を実機で確認 — task_sla の stage がどんな条件で動くかを、全体像から俯瞰したいときに読むと理解がつながります。

検証範囲とおことわり

• 確認した範囲（すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得）

• task_sla / contract_sla の階層、固有フィールド数（task_sla 26 / contract_sla 35）

• stage / type / target 選択肢、主要フィールドと参照先

• SLA 定義の start/stop/pause 条件と flow/workflow 利用状況

• レコード件数と stage 分布、周辺設定件数

• 確認していない範囲（断定しません。これらは別記事で扱います）

• 各 SLA 定義の duration_type 詳細、SLA Repair / SLA Timeline の内部挙動

• 各 Business Rule / Flow の内部スクリプト

• business 時間（稼働時間）計算の正確な内訳

• Performance Analytics 連携、本番でのカスタム SLA 定義