ZurichのSLAは何を管理しているのかを最初に整理する
ServiceNowのSLA設定で混乱が起きやすい理由は、画面上の設定項目が「現象」に見えてしまい、裏側の仕組みが見えにくいからです。Zurichでも、SLAは基本的に Service Level Management（SLM）アプリケーションで管理され、タスクに紐づく Task SLA レコードが実体として動きます。まずはここを押さえるだけで、設定の読み間違いが減ります。
SLMは「約束」と「計測」と「報告」をまとめて扱う
SLMは、合意したサービスレベルを集め、監視し、レポートするための仕組みです。つまりSLAは「時間を測る機能」ではありますが、目的は“測ること”ではなく サービス品質や速度を可視化することにあります。
Zurichで意識したい更新点は「表示」と「選び方」
Zurichのリリースノートでは、SLMの特徴として SLAタイマー構成がFirst to BreachのSLAをサポートする点が触れられています。タイマーは「いま最も重要なSLA」をどう見せるかに関わるので、運用画面の見え方や認識ズレの原因になりがちです。
ここまでを前提にすると、SLA設定の“勘違いポイント”はだいたい次の3つに集約されます。
- 条件の名前から挙動を想像してしまい、開始・停止・一時停止を混同する
- 遡及開始を有効にして、突然「一気に進む」「即違反」「通知が飛ぶ」に驚く
- タイマー表示を“唯一の正解”だと思い込み、First to Breachや表示対象の選定を誤解する
以降は、この3つを順番にほどいていきます。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
開始・停止・一時停止を混同しないための考え方
SLA設定で一番やりがちなのが、Start condition、Pause condition、Stop conditionの“言葉の雰囲気”で判断してしまうことです。ここは暗記ではなく、Task SLAのライフサイクルとして理解すると楽になります。
Task SLAは「タスクに貼り付く計測レコード」
SLA定義（SLA Definition）がルールで、Task SLAが実行結果です。タスク側が更新されると、条件に応じてTask SLAの状態が変わります。
この「タスク更新に反応して状態遷移する」という見方ができると、次のように整理できます。
- 開始：Task SLAがタスクにアタッチされ、時間計測を始める
- 一時停止：計測を止めるが、SLA自体は生きている（再開し得る）
- 停止：計測を完了させる（達成・未達成の結果が確定する）
勘違いしやすい具体例
たとえばインシデントで「待ち（Awaiting user info）」の状態にしたとき、止めたいのは“計測”なのか“契約”なのかで設定が変わります。
- 返信待ちの間は 時間だけ止めたい → Pause条件
- その時点で SLAを終了扱いにしたい → Stop条件
実務でも学習でも、ここが曖昧だと「止めたはずなのに再開した」「再開してほしいのに終わった」といった事故が起きます。
条件は「状態名」ではなく「事実の定義」
もう一段だけ深掘りすると、条件は“状態名に反応するスイッチ”ではなく、タスク上の事実（フィールド値の組み合わせ）を定義するものです。
同じ「Resolved」でも、解決コードやクローズ理由、Assignment group、Priorityなどの変化が絡むと、SLAの意図は変わります。なので「ResolvedならStop」みたいな単純化は危険で、条件は“運用ルール”とセットで設計すべき、という結論になります。
CSA視点でも、ここは「用語を覚える」より、「なぜPauseとStopが分かれているのか」を理解しておくと、設問の意図を読み違えにくくなります。
遡及開始と遡及中断で起きる誤解と通知暴発の回避
Zurichの公式ドキュメントには、Configure SLA retroactive start and pause として、遡及開始と遡及中断の考え方がまとまっています。ここは“知らずにONにする”と体感が派手に変わるので、勘違いが起きやすい代表例です。
遡及開始は「貼り付いた時刻」ではなく「基準時刻から測る」
遡及開始を使うと、SLAがタスクに後からアタッチされた場合でも、指定した基準（タスクの特定時刻や条件）からの経過としてタイミング情報を保持できます。公式の説明でも、タスクの変化に対して“タイミング情報を保持する”目的が示されています。
ここで起きがちな勘違いはこれです。
- 勘違い：遡及開始 = 「過去に戻って勝手に違反扱いになる怖い機能」
- 実態：運用上“本来測りたかった開始点”が後から確定するケースに対応する機能
例えば、受付時点では優先度が低く、調査してからP1相当と判明した…のようなケースで、「実際は発生時点から計測したい」という要求に合わせるのが遡及開始の出番です（何でもONにするものではありません）。
遡及中断は「いきなり違反」と「いきなり通知」を抑える
公式ドキュメントでは、遡及開始を有効にした場合に、遡及中断が即時の違反や通知を防ぐために役立つことが書かれています。
遡及開始だけをONにすると、条件が整った瞬間に「すでに時間が経っていた」扱いになり、違反や通知が“まとめて発火”したように見えることがあります。これが現場でいう「通知暴発」パターンです。
初学者がやりがちな設定ミス
- 運用で遡及開始が必要な理由がないのに、チェックボックスの存在だけでONにしてしまう
- 遡及開始を使うのに、遡及中断の意味を理解しないまま通知を組み合わせてしまう
- 「Set start to」に相当する基準点が、運用の開始点とズレている
このあたりは、暗記よりも「なぜこの機能が必要になったのか」を想像すると腹落ちします。
タスクの事実が後から確定する運用（優先度の後上げ、Assignmentの後決め、受付経路の統合など）を採用しているほど、遡及の設計は難しくなります。
タイマー表示とFirst to Breachの勘違いを潰す
Zurichで「SLAタイマー表示が思っていたのと違う」という相談は増えがちです。原因の多くは、SLAが壊れたのではなく、どのTask SLAをタイマーとして見せるかのルールを誤解しているケースです。Zurichの公式ドキュメントには、タイマー構成とSLAタイムラインが用意されています。
タイマーはSLAそのものではなく「表示コンポーネント」
タイマーは「いま重要なSLAはどれか」を決めて表示する仕組みです。
公式の “Configure the SLA timer” は、タイマーコンポーネントに表示するTask SLAを決めるための設定であることを明確にしています。
つまり、タイマーが示しているのは“唯一の真実”ではなく、選ばれた代表のSLAです。ここを取り違えると、
- 「タイマーが止まってる＝SLAが全部止まってる」
- 「タイマーが違反した＝全部違反した」
のような誤読につながります。
First to Breachを「最初に違反したSLA」と誤解しない
Zurichのリリースノートには、SLAタイマー構成が First to Breach をサポートすることが書かれています。
ここでのポイントは、（言葉の印象は強いですが）First to Breachは“結果の説明”というより、複数SLAの中から、どれを優先表示・追跡するかの考え方とセットで使われる、ということです。
複数SLAが同時に付く設計は珍しくありません。たとえば「初動対応」と「解決」など、段階別のSLAを併用する場合です。
このときタイマーが“どれを見せるべきか”を決めるルールが曖昧だと、現場の認識がズレます。
「タイマーの設計」は運用設計の一部
初学者ほど、SLA定義だけを頑張って作りがちですが、運用で効くのは次です。
- どのSLAを現場に見せるか
- いつ、誰が、どの画面で判断するか
- 通知やエスカレーションのトリガーと、タイマー表示の整合が取れているか
ここまで含めて設計できると、「SLAは動いてるのに現場が混乱する」状態を減らせます。
動かない時の検証手順と移行観点の注意点
SLAが「付かない」「止まらない」「急に進む」と感じたら、闇雲に条件をいじる前に、公式が用意している確認手段で事実を見に行くのが近道です。
SLA Timelineで「何がトリガーになったか」を確認する
Zurichの公式ドキュメントでは、SLA Timelineで、Task SLAの進捗と、ステージ変化を引き起こしたタスク更新を確認できると説明されています。
これが本当に強力で、「いつStartになったか」「いつPauseになったか」「いつStopになったか」が、タスクの更新履歴と結びついて見えるため、原因の切り分けができます。
おすすめの見方はこの順番です。
- まずTimelineで、状態遷移の時刻を確定する
- その時刻にタスクのどのフィールドが変わったかを見る
- Start/Pause/Stop条件のフィルタに、その変化が合致しているかを確認する
“条件を先に疑う”ではなく、“事実を先に見る”です。
遡及を使っている場合は、ドキュメント通りに前提確認
遡及開始と遡及中断は、管理者向け設定であり、前提や目的が明確に書かれています。まずは公式の前提（ロール要件、目的、挙動）を確認し、「なぜONなのか」を説明できる状態に戻すのが安全です。
移行や古い仕組みを抱えていると、混乱が増える
公式には、SLA処理をエスカレーションエンジンからSLM機能へ移行する話もあります。
すべての環境で同じ事情があるわけではありませんが、もし過去の設計やプラグイン、移行途中の定義が混在していると、「昔の感覚」で作った条件が思わぬ挙動を起こします。
この手の環境では、次の方針が効きます。
- 新旧を混ぜて“理解で吸収”しようとしない
- まず現状のSLA定義とTask SLAの実データを見て、動いているルールを把握する
- その上で、タイマー表示や通知と整合するように段階的に整理する
学習を効率化するなら、体系的に触れる教材を一本用意する
SLAは「条件」と「運用」と「検証」が絡むので、断片知識だけで積むと混乱しやすい分野です。
CSAを狙う学習でも、用語暗記に寄せすぎず、SLA定義→Task SLA→Timelineで検証の流れを一通り回しておくと理解が安定します。公式ドキュメントを軸にしつつ、手を動かす時間を確保する意味で、UdemyのServiceNow基礎〜CSA対策講座のような体系教材を「学び方の一例」として併用するのも現実的です（理解の順番を整えてくれるのが利点です）。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ
ZurichのSLA設定で勘違いが起きるポイントは、「機能を知らない」よりも、「条件が表す意味を取り違える」ことにあります。
まずはSLMの目的とTask SLAという実体を押さえ、開始・停止・一時停止をライフサイクルとして整理すると、設定項目が読みやすくなります。
次に、遡及開始と遡及中断は“便利そうだからON”にすると事故りやすい領域です。必要な運用背景があるか、通知や違反の挙動と整合するかを、公式の説明に沿って確認すると混乱を避けられます。
そして、タイマー表示はSLAの真実ではなく「見せ方」です。First to Breachや表示対象の選び方を理解しておくと、「動いているのに現場が混乱する」問題を減らせます。
最後に、困ったらTimelineで事実を見る。これが一番の近道です。設定をいじる前に、何がトリガーで状態が変わったのかを追えるようになると、SLAは“怖い機能”ではなく“説明できる仕組み”になります。
