ServiceNowのSLAはいつ違反になる？ 時計が動く条件と止まる条件を実機で確認

SLAの残り時間が急に減っていたり、担当をOn Holdにしたのに時計が止まっていなかったりすると、原因がどこにあるのか分かりにくいものです。ServiceNowのSLAは、条件を持つcontract_sla（SLA Definition）と、実際に動く時計であるtask_slaの2枚に分かれています。時計が動く・止まる・違反になるタイミングは、すべてcontract_sla側の条件式1つで決まります。Zurich PDIでPriority別のSLA定義とtask_slaを開き、時計がいつ動き、いつ止まり、いつ違反と判定されるのかを確認しました。

時計そのものを先に開く

定義の話に入る前に、動いている側を出しておきます。1件のインシデントに付いた Task SLA です。

上段が「どの約束か」。SLA definition が Network group resolution、対象の Task が INC0000039、Target は Resolution です。右に Stage と Has breached。この2つで、進行中なのか約束を破ったのかがすぐ読めます。

下の Timings が時計の中身です。Start time と Breach time があり、そのあいだに Actual と Business の2系統で経過が並びます。約束の何％を使ったかが percentage、残りが time left です。

注目してほしいのは、画面の中央に出ている2つの案内文です。

カレンダーを設定しなければ Business は Actual と同じ値になると、製品自身が画面で断っています。営業時間を効かせたつもりで効いていない、という取り違えはここで防げます。

なおこの記録は古いデモデータで、経過率が桁外れの値になっています。読むべきは数字そのものではなく、どの項目でいつ違反と判定されるかという構造のほうです。

SLAを見るとき、担当者が本当に知りたいこと

「この案件、あと何時間で違反ですか」と聞かれたとき、即答できないことがあります。

答えるには3つ分かっている必要があります。いつから数え始めたのか。途中で止まっていた時間があるのか。そして締切がいつなのか。

さらに厄介なのが、止まる条件です。担当者が「保留にしたから時計も止まったはず」と思っていても、実際は動き続けていた、ということが起きます。何をすれば止まるのかが、設定を見ないと分からないのがSLAの難しさです。

他のタスク管理機能との位置づけ

ServiceNowで「期限」を扱う仕組みはいくつかあります。混同しやすいので整理します。

タスク自体が持つ due_date は、単なる日時のフィールドです。誰かが手で入れるか、スクリプトで埋めます。過ぎても何も起きません。

SLAは違います。 条件に一致したら自動で時計が始まり、条件が変われば止まり、締切を過ぎれば違反として記録が残ります。測定と記録が自動で回るのがSLAの役割です。

エスカレーションの通知もSLAから出せます。「残り25%で担当者に通知」といった設定は、期限のフィールドだけでは作れません。

2つのテーブルの役割は継承元に出る

SLAは2枚のテーブルでできています。役割の違いは、テーブルの継承元を見ると分かります。

contract_sla（画面上の名前は SLA Definition）は Application File を継承していました。更新セットで他の環境へ運べる設定という位置づけです。開発環境で作ったSLA定義を本番へ持っていけます。

task_sla（Task SLA）は何も継承していない基底テーブルでした。その環境で実際に動いた記録なので、運ぶ性質のものではありません。

定義は移送できて、実績は移送できない。この非対称が、2枚に分けている理由になっています。

公式が書いている条件の意味

ServiceNow は各フィールドに説明を付けています。SLAの条件はここを読むと正確に理解できます。

start_condition の説明はこうです。

前半は「この条件に一致したタスクがSLAを引き込んで計測を始める」。後半が重要で、動いているSLAが条件に一致しなくなるとキャンセルされると書かれています。止まるのでも違反になるのでもなく、無かったことになります。

pause_condition はこうです。

一時停止する条件を決めるもので、条件を満たさなくなったら計測が再開するとあります。停止と再開が同じ条件式の裏表になっている、という設計です。

stop_condition はこうです。

止めて測定を確定する条件です。括弧書きで「一般にはタスクが Resolved になったとき」と、想定される使い方まで書かれています。

schedule は「The 'business calendar' that this SLA will measure against」。どの営業カレンダーで測るかの指定です。

duration_type の説明はこうです。

固定の長さか、相対的な長さかを選ぶという設計が、例つきで書かれています。

set_start_to は「Choose the field where the system will get the 'start time' for the SLA」。開始時刻をどのフィールドから取るかの指定です。

実績側にも公式の説明がある

task_sla の項目にも説明が付いていました。

planned_end_time は「Time the SLA will breach. Adjusted for pause duration.」。違反する時刻ですが、一時停止していた分だけ後ろにずれると明記されています。

original_breach_time は「Original time the SLA will breach. Set when the SLA is attached.」。SLAが付いたときに決まった、当初の違反時刻です。

この2つが別々にあることが答えになっています。当初の締切と、停止分を反映した実際の締切を、両方保持しているわけです。残り時間を計算するときに見るのは前者ではなく後者になります。

pause_duration と business_pause_duration も持っていて、止まっていた時間を通算と営業時間の2通りで記録します。

結論：時計を決めているのは3つの条件と1つのカレンダー

• 時計が動く・止まる・完全に停止するタイミングは、すべてcontract_sla（SLA Definition）が持つstart_condition・pause_condition・stop_conditionという3つの条件式で決まります

• 同じ「時計」でも、schedule（営業時間カレンダー）を持つ定義は平日の稼働時間だけ進み、持たない定義は24時間休みなく進みます。resolution系のうちPriority 1だけがこの扱いから外れる、非対称な構成でした

• 違反はstop_conditionの成立を待ちません。締切（planned_end_time）を過ぎた瞬間にhas_breachedがtrueになり、一覧のstageが「進行中」のままでも実質的には超過していることがあります

インシデントが起票されただけではSLAの対象になりません。start_conditionという条件式に一致した瞬間、初めてtask_slaが1本生成されて計測が始まります。そこから先、一時停止するか、達成するか、違反するかを分けているのも条件式です。stageという値がtask_sla側に記録されますが、その値を動かしているのはcontract_sla側の設定です。stageの値そのものの読み方は「task_sla：1タスク1本のSLA時計の読み方」で扱っているため、この記事では「何が条件をトリガーするか」に絞って進めます。

contract_slaとtask_sla、条件を持つのはどちらか

SLAを追いかけるとき、最初に迷うのが「どちらのテーブルを見ればいいか」です。役割は明確に分かれています。

実機のSLA Definitions一覧を開くと、Priorityごとのresponse・resolutionだけではありません。部署間の合意であるOLAや、外部ベンダーとの契約であるUnderpinning contractまで、種類の違うルールが同じテーブルに並んでいます。この一覧に並ぶ1件1件がcontract_slaのレコードです。

contract_slaは「ルール」です。start_condition・pause_condition・stop_conditionという3つの条件式と、duration（期間）・schedule（カレンダー）を持ちます。一方のtask_slaは「実測」で、いま何段階か（stage）・残り時間・経過率・違反したかどうか（has_breached）を持つ側です。contract_slaを1件直すと、以後そのルールから新しく生まれる時計すべての挙動が変わります。task_slaを直しても、その1本の時計にしか影響しません。

各フィールドの意味を1つずつ追うのはこの記事の役割ではありません。定義側の全フィールドは「SLA Definition（contract_sla）とは：時計を生むルール」、実測側は先に挙げたtask_slaの記事にまとまっています。ここから先は、この2枚のうち「時計が動く・止まる・違反になる」という3つの瞬間だけを掘り下げます。

時計が動き出す条件（start_condition）

時計はインシデントが起票された瞬間ではなく、start_conditionという条件式に一致した瞬間に生まれます。実機でPriority別のSLA定義を開くと、response系（応答）とresolution系（解決）でこの条件の作りが違いました。

resolution系はPriorityだけ、response系はグループ必須

Priority 1 resolution（1時間）のstart_conditionは「Active=true かつ Priority=1 - Critical」でした。Priorityが立った瞬間に時計が生まれます。ところがPriority 1 responseは条件が一段厳しく、同じPriority条件に加えてAssignment group（担当グループ）が未入力ではないことまで求められる作りです。担当グループが割り当たるまで、応答用の時計はそもそも生まれません。

起票直後に「なぜresolutionの時計だけ動いていて、responseの時計が見当たらないのか」と感じたら、担当グループの割り当てを確認する価値があります。resolution系はPriorityだけで動き出しますが、response系はグループが決まるまで待つ設計だからです。

時計は何を数えているか：24時間か、営業時間だけか

同じ「1時間」でも、定義によって中身が違います。Priority 2 resolution（8時間）のフォームを開くと、この違いがそのまま見えます。

scheduleを持たない定義は実時間をそのまま数える

Priority 1 resolution（1時間）はscheduleが空でした。空の場合、時計は24時間休みなく進みます。深夜に起票されても、土日をまたいでも、経過時間はカレンダー通りに積み上がります。

scheduleを持つ定義は稼働時間だけ進む

Priority 2〜4のresolutionはscheduleに「8-5 weekdays」が設定されています。この定義に基づく計算は、フォーム上部の情報バナーにも表れていました。duration 8時間の定義を今この瞬間に始めた場合、実際の暦の上では1日と23時間ほどかかるという試算が表示されます。土日や夜間を挟むぶん、暦の上での締切は先へ延びる計算です。

参照先の「8-5 weekdays」自体を開くと、Time zoneは「-- Floating --」でした。Schedule Entriesには「Monday-Friday 8-5」という1本のエントリだけがぶら下がっています。この1本が「平日だけ稼働」という定義の中身です。スケジュール自体がどんなテーブル構造で、どんな繰り返しルールを持つかは「SLAが土日を飛ばす理由：営業時間（cmn_schedule）」で扱った内容なので、ここでは深追いしません。

task_sla側の実測を見ると、schedule有無の差がpercentage（実時間ベースの経過率）とbusiness_percentage（稼働時間ベースの経過率）の2つの数値に表れます。

scheduleを持たない定義では、percentageとbusiness_percentageが常に同じ値でした。scheduleを持つ定義ではこの2つが分かれ、稼働時間だけを数えるbusiness_percentageのほうが暦通りのpercentageより小さい値になります。どちらを見て「あとどれくらいか」を判断するかで、担当者が受ける印象は変わってきます。

時計が止まる条件（pause_condition）：Awaiting Callerだけが止める

止めたつもりの時計が動き続けている、という相談でまず疑うべきなのがpause_conditionです。Priority 2 resolutionのPause conditionタブを開くと、条件の中身が読み取れます。

resolution系はhold_reasonの値まで見ている

条件は「Incident state=On Hold かつ On hold reason=Awaiting Caller」または「Incident state=Resolved」の2ブロックです。On Holdにするだけでは足りません。理由（hold_reason）までAwaiting Callerでないと一時停止しません。

hold_reasonにはAwaiting Caller・Awaiting Change・Awaiting Problem・Awaiting Vendorの4種類があります。pause_conditionが見ているのはこのうちAwaiting Callerだけです。ベンダー対応待ちや変更待ちでOn Holdにしても、resolution系の時計はそのまま動き続けます。

response系にはpause_conditionそのものが無い

response系（Priority 1〜5 response）を実機で確認すると、pause_condition自体が空でした。一時停止する設定が最初から存在しません。resolution系とresponse系の違いを比較すると、次のようになります。

response系の時計は、担当者がついて最初の応答をするまで、On Holdにしようと止まりません。設計として止める仕組みを持っていないためです。

実機で気づいたこと

hold_reasonの選択肢を最初に見たとき、Awaiting Callerだけが特別扱いされている理由が分かりにくく感じました。しかし考えてみると筋が通っています。ベンダーや変更を待っている間も、解決に向けた作業は組織側の管理下にあります。時計を止める必要があるのは「相手からの応答待ちで、こちらでは何もできない」場面に限られる、という設計判断です。

task_sla一覧でBusiness elapsed percentageが赤いバーで7000%を超えているのに、Stageは「In progress」のままだったのも意外でした。stageの選択肢自体は6つしかありません。

has_breachedというフラグと、この6つのうちどれが選ばれているかという表示は、別物として動いています。締切を過ぎた事実そのものはpercentageの数字にすぐ表れますが、stageが「Breached」という表示に変わるタイミングは、この画面から見えている情報だけでは特定できません。数値の変化と表示ラベルの変化には、ずれが生じる場面があると考えたほうが安全です。

Priority 2 resolutionのフォームで「Timezone source: The caller's time zone」という項目を見つけたのも収穫でした。SLA定義自体のtimezoneフィールドは空でも、フォーム側には「誰の時刻を基準にするか」という別の設定があります。既定は問い合わせた本人（Caller）のタイムゾーンです。REST APIの応答だけを見ていると、この解決ロジックの入口には気づきません。

実務での使い方

SLAの挙動を調査するとき、まず読むべきはtask_slaの数字より先にcontract_sla側の3条件です。「動かない」ならstart_condition、「止まらない」ならpause_condition、「終わらない」ならstop_conditionです。次にscheduleの有無を確認します。scheduleがあれば、平日夜間や土日をまたぐケースで暦上の締切が先に延びるため、担当者への説明はbusiness_percentage側の数字を使うと実感に合います。

On Holdへの運用ルールを作るときは、hold_reasonの選び方をチームで揃えておく価値があります。ベンダー対応待ちを一律Awaiting Callerで登録してしまうと、本来止まってほしくない時計まで止まり、違反が実態より少なく見える結果になりかねません。逆にAwaiting Callerで止めるべき場面を他の理由で登録すると、待ち時間がそのまま違反にカウントされます。窓口担当が最初に選ぶ理由1つで、あとから見返すSLAの数字がまるごと変わってしまう点は、運用設計の初期段階で共有しておく価値があります。

つまずきやすい点

On Holdへの切り替えとscheduleの組み合わせで、実際の挙動と担当者の直感がずれやすい場面を整理します。

• On Holdにしても止まらないと感じたら、hold_reasonがAwaiting Caller以外になっていないか確認します。resolution系の一時停止条件はAwaiting Caller限定です

• response系のSLAは一時停止の設計自体を持ちません。担当がつくまでOn Holdでも動き続けます

• has_breachedとstageは別の情報です。「表示は進行中でも、実は締切を超えている」ケースがあり得ます

• percentageとbusiness_percentageは計算基準が違います。scheduleを持つ定義では両者の値が大きくずれることがあります

• SLA定義のtimezoneフィールドが空でも、実際の基準時刻はTimezone sourceという別項目（既定はCallerのタイムゾーン）が決めています

よくある質問

Q1. SLAを一時停止したのに時計が動き続けているのはなぜですか

pause_conditionが成立していない可能性があります。resolution系ならhold_reasonがAwaiting Callerになっているか、response系ならそもそも一時停止条件を持っていないかを確認します。

Q2. 違反（Breached）と判定されるのはどの時点ですか

締切であるplanned_end_timeを過ぎた時点です。stop_conditionの成立を待つ必要はありません。has_breachedはこの瞬間にtrueへ切り替わりますが、一覧のstage表示が同じタイミングで切り替わるとは限りません。

Q3. percentageとbusiness_percentageはどちらを見ればいいですか

scheduleを持たない定義なら同じ値なので、どちらでも構いません。scheduleを持つ定義では、稼働時間だけを数えるbusiness_percentageのほうが「担当者から見た緊迫度」に近い数字になります。

Q4. 1件のインシデントに複数のSLAが同時に付くことはありますか

あります。response用とresolution用に加え、OLAやUnderpinning contractが同時に走ることも珍しくありません。この並走の実例は「task_sla：1タスク1本のSLA時計の読み方」で画面付きに確認できます。

Q5. scheduleを設定していないSLAは24時間休みなく数えるのですか

その通りです。実機で確認したPriority 1 resolutionはscheduleが空で、深夜や土日を含めて実時間のまま経過時間が積み上がっていました。

まとめ

SLAの時計は、task_sla単体を眺めていても動く理由が分かりません。動く・止まる・違反になるという3つの瞬間は、すべてcontract_sla側の条件式が握っている構造です。scheduleの有無で「24時間か、稼働時間だけか」が変わり、pause_conditionのhold_reason指定で「どのOn Holdなら止まるか」が変わります。違反はstop_conditionの成立を待たず、締切を過ぎた瞬間に確定します。

止まらない・違反した理由を追うときは、task_slaの数字だけでなく、その元になっているcontract_slaの条件式を必ず併せて読みます。

用語

• contract_sla（SLA Definition） … 時計を生むルール。start_condition・pause_condition・stop_condition・duration・scheduleを持つ

• task_sla（Task SLA） … contract_slaから生まれた実測の時計。stage・percentage・business_percentage・has_breachedを持つ

• start_condition / pause_condition / stop_condition … 時計が生まれる・一時停止する・止まる条件式

• schedule（cmn_schedule） … 稼働時間を定義するカレンダー。設定が無ければ24時間連続で計測する

• has_breached … 締切（planned_end_time）を過ぎたかどうかのフラグ

• business_percentage / percentage … 稼働時間ベース／実時間ベースの経過率

実機で確認したURL

SLA 定義一覧        : contract_sla_list.do
SLA 定義個票        : contract_sla.do?sys_id=（対象定義のsys_id）
スケジュール個票     : cmn_schedule.do?sys_id=（対象スケジュールのsys_id）
Task SLA 一覧       : task_sla_list.do?sysparm_query=sla.name=（対象定義名）
hold_reason 選択肢   : sys_choice_list.do?sysparm_query=name=incident^element=hold_reason^inactive=false^ORDERBYsequence
stage 選択肢         : sys_choice_list.do?sysparm_query=name=task_sla^element=stage^inactive=false^ORDERBYsequence

参考リンク

• SLA definitions（Zurich）

• Configure SLA retroactive start and pause（Zurich）

• Monitoring Service Level Agreement (SLA)（Zurich）

• Schedules within SLA（Zurich）

• SLA duration and schedules（Zurich）

• Domain support for schedules（Zurich）

関連記事

• SLA Definition（contract_sla）とは：時計を生むルール … contract_slaの全フィールドを1つずつ確認する定義編

• task_sla：1タスク1本のSLA時計の読み方 … stageの6段階、複数SLA並走の実画面を確認する実測編

• SLAが土日を飛ばす理由：営業時間（cmn_schedule） … スケジュールのテーブル構造・タイムゾーン・祝日除外の仕組み編

引用した公式説明を自分で開く

この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールド／プロパティのドキュメントです。次のURLを自分のインスタンスで開けば、引用元の原文にあたれます。

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINtask_sla,due_date,contract_sla^hintISNOTEMPTY

検証環境と未検証範囲

この記事の件数と設定値は Zurich PDI（2026-08-09 確認）の実測です。フィールドの公式説明は、製品が持つフィールドドキュメント（sys_documentation）から 2026-08-11 に引用しました。バージョンによって文言が変わる可能性はありますが、当たっているのは製品同梱の記述です。

事実です。SLA定義の条件式（start/pause/stop_condition）、schedule設定の有無、hold_reasonの選択肢は、Zurich PDI（OOTB）の画面とAPIで確認しました。task_sla一覧のstageとBusiness elapsed percentageの表示も、同じくZurich PDIの実機で確認したものです。カスタマイズしていないOOTB環境であれば、同じ条件式・同じ選択肢になります。

未検証の範囲もあります。実際にインシデントをOn Holdにして時計が本当に止まる・止まらないかをライブで動かす確認は行っていません（PDIへの書き込みをしない前提のため、条件式の読み取りにとどめています）。has_breachedがtrueに切り替わった瞬間にstage表示が同時に切り替わるか、次の再計算まで遅延するかという正確なタイミングも、今回のAPI・画面の実測だけでは特定できていません。scheduleのタイムゾーン解決順序（Timezone sourceが複数ある場合の優先順位）や、business時間の計算エンジンの内部実装にも踏み込んでいません。本番環境やカスタマイズ済みの環境では、SLA定義の条件式やschedule設定の内容が異なります。