ServiceNowのService Offeringを廃止したらSLAはどうなる？ 仕掛中と新規適用を実機で確認
サービス統廃合で Service Offering を廃止するとき、その Offering を条件に動いている SLA をどう片付けるかは意外と資料がありません。実機で確かめた結論は「リタイアしても SLA は走り続ける」です。仕掛中の時計は止まらず、新規のインシデントにも SLA は付き続けます。Australia PDI に Offering と SLA 定義を作り、リタイア・削除・定義の無効化まで一通り動かして task_sla の変化を確認しました。
検証環境：Australia PDI / OOTB / 2026-08-21 確認
Offering をリタイアしても SLA の時計は走り続ける
確認できた事実を先にまとめます。
仕掛中の task_sla は、Offering をリタイアした瞬間には何も変わりません。SLA の再評価はタスクが更新されたときに走り、そのときも「Service offering がこの値か」という条件は成立したままなので、時計は継続します
リタイア済みの Offering は新規インシデントでも選択でき、SLA も普通に適用されて4時間の時計が走り出します
止まったのは、条件に「Offering が稼働中であること」というガードを足した定義だけでした。それもタスクに更新が来た後です
つまり「Offering を廃止したから SLA も勝手に終わる」という動きは存在せず、SLA の後片付けは自分で設計する必要があります。この記事では、その根拠になる実測結果と、廃止時に踏む手順を順に見ていきます。
サービスを廃止するとき、SLA はどう片付くべきか
先に期待値を言葉にしておきます。Offering ごとに解決時間の約束を定義している組織が Offering を廃止するとき、望ましい姿は3つに整理できます。新しい約束は結ばれないこと。仕掛中の対応は決着まで測り切ること。そして過去の達成記録はレポートのために残ることです。
問題は、ServiceNow がこれを自動でやってくれるのかどうかです。答えを先に言うと、3つのうち自動なのは「記録が残る」だけで、残り2つは運用側の操作が必要でした。
Service Offering は SLA 条件の起点で、SLA 本体とは別のテーブルにある
Service Offering（service_offering）は、CMDB のサービステーブル（cmdb_ci_service）の子テーブルです。「メール」というサービスを、Standard／Premium のような提供条件の単位に分けて持つための箱で、サービスカタログの「提供メニュー」に相当します。
SLA との関係は参照だけです。SLA Definition（contract_sla）の開始条件が、インシデントの service_offering フィールドを見る形でつながります。「Service offering が Email - Standard Support であること」のような条件行が1本入るだけです。Offering 単位で SLA を分けると、同じメールサービスでも Standard は8時間・Premium は4時間のように、提供条件ごとの約束を1つの定義体系で表現できます。CSDM（Common Service Data Model）でサービス構造を整備している組織ほど、この分け方が SLA 設計の標準形になります。
ここで大事なのは、2つのテーブルのライフサイクルが独立していることです。Offering は CMDB 側のライフサイクル（Operational status や Life cycle stage）で管理されます。SLA Definition の側は Active フラグ1つで管理される、別の世界の住人です。Offering をリタイアしても SLA Definition は Active のまま残るため、廃止時の挙動はすべて「SLA の条件式が今も成立するか」だけで決まります。
公式の説明に「条件から外れた実行中の SLA はキャンセルされる」と書いてある
その条件式の挙動は、製品に同梱されたフィールドドキュメントが正確に説明しています。contract_sla の Start condition の公式説明です。
A task matching this condition will pull in this SLA and begin running it. A running SLA no longer matching this condition will be cancelled.
（訳: この条件に一致したタスクはこの SLA を取り込み、実行を開始します。実行中の SLA がこの条件に一致しなくなった場合、その SLA はキャンセルされます）
引用元: /sys_documentation_list.do?sysparm_query=name=contract_sla^element=start_condition
ここに「Offering がリタイアされたら」という特別扱いは出てきません。あるのは条件の成立・不成立だけです。キャンセルの発動タイミングは When to cancel フィールドで選びます。今回の定義は「Start conditions are not met（開始条件が満たされなくなったとき）」です。条件を画面のビルダー（Simple）で作った定義では他の選択肢は保存時に拒否されるため、実質この動きになります。実際、このインスタンスの SLA 定義16本のうち15本がこの値でした。
もう1つ、挙動を左右する公式設定があります。インシデントの Service offering フィールドの選択肢を絞る参照修飾子です。incident には辞書オーバーライド（sys_dictionary_override）があり、次の式が効いています。
javascript:(!gs.nil(current.business_service)? 'parent='+current.business_service: '');親サービスが一致する Offering を出す、という絞り込みだけで、稼働状態の条件を持っていません。リタイア済みの Offering が選択肢に残り続けるのは、この設定によるものです。
稼働中の起票では、自作2本を含む4本の SLA が同時に走り出した
検証データは次の構成で作りました。既存のデモサービス「Email」の下に Offering「Email - Standard Support」を作成し、これを条件にした解決4時間の SLA Definition を2本用意します。
SLA-A（値だけの条件）: Service offering is Email - Standard Support
SLA-B（稼働中ガード付き）: 上記 AND Service offering.Operational status is Operational
Offering が稼働中の状態で優先度3のインシデントを起票すると、task_sla は4本付きました。OOTB の Priority 3 resolution／response の2本と、自作の SLA-A・SLA-B です。4本とも In progress で、自作2本の締切はちょうど4時間後を指しています。ここまでは期待どおりの通常動作です。
リタイアしただけでは、仕掛中の SLA は1本も変化しなかった
このインシデントを仕掛中のまま、Offering をリタイアします。どのフィールドを変えたときに何が起きるかを切り分けるため、2段階に分けました。
まず Life cycle stage を End of Life、Life cycle stage status を Retired に変更します。task_sla は4本とも In progress のまま、更新日時すら動きません。SLA エンジンはタスク側のテーブルで動く仕組みなので、CMDB 側のレコードをいくら変えても反応しないわけです。
次にインシデントに作業メモを1件足して、SLA の再評価を意図的に発火させます。それでも4本とも継続でした。ガード付きの SLA-B まで生き残っています。ガードが見ているのは Operational status（operational_status）で、ライフサイクル系のフィールドとは別物だからです。「リタイアした」という運用上の認識と、条件式が見ているフィールドが食い違うと、ガードは機能しません。
そこで Operational status を Retired に変えてから、もう一度作業メモを足しました。ここで初めて SLA-B が Cancelled になり、終了時刻が記録されました。SLA-A と OOTB の2本は変わらず In progress です。
一連の結果をまとめたのがこの表です。太字が「値だけの条件との差が出た」箇所です。
リタイア済みの Offering でも、新規の SLA は普通に動き出す
次に、リタイアが終わった状態で新しいインシデントを起票し、同じ Offering を設定しました。
まず、選択肢からは消えません。参照修飾子が親サービスでしか絞っていないため、リタイア済みでも Offering は一覧に出続けます。
そして SLA-A は新規にも適用され、In progress で4時間の時計が走り出しました。適用されなかったのはガード付きの SLA-B だけです。
さらに、Offering の Support group（Service Desk）を Assignment group へ自動コピーする動きも、リタイア後のまま生きていました。タスクの標準ビジネスルール「Populate Assignment Group based on CI/SO」によるものです。このルールの条件にも Offering の稼働状態は含まれていません。Resolver Group（解決担当グループ）の紐付けを Offering の Support group で管理しているケースは注意が必要です。廃止済みの Offering が選ばれると、廃止済みのグループ運用のままインシデントが割り当てられ続けます。
なお、リタイア後も仕掛中だった最初のインシデントを解決にすると、SLA-A は Completed になり、達成として記録が残りました。期待値のうち「記録は残る」は、リタイアと関係なく自動で満たされます。このインシデントの Task SLA 一覧を見ると、ガードで止まった Cancelled と、解決まで走り切った Completed が同じ画面に並んでいて、今回の検証の縮図になっています。
OOTB の Priority 3 resolution が Paused になっているのは、その定義の一時停止条件に Resolved 状態が含まれているためです。停止条件は Closed なので、解決の時点では停止まで進みません。
削除は別物で、参照ごと消えて次の更新でキャンセルされた
「リタイアではなく消してしまえばいいのでは」という選択肢も対比で確かめました。別の Offering（Email - Legacy Support）とそれを条件にした SLA を作り、インシデントで SLA が走っている状態で Offering のレコードを物理削除します。
結果、インシデントの Service offering フィールドは空にクリアされました。参照値そのものが消えるため、次にタスクが更新された時点で条件不成立となり、SLA は Cancelled になります。動きとしてはガード付き条件と似ていますが、こちらはインシデント側のデータが書き換わってしまう点が決定的に違います。過去のインシデントを「どの Offering の案件だったか」で集計する分析が根こそぎ壊れるため、廃止の手段として削除は選ばない方針が安全です。
新規適用を止める正しい操作は SLA Definition の Inactive だった
では新規適用は何で止まるのか。SLA-A を Inactive にしてから同じ条件でインシデントを起票すると、SLA-A は付かず、OOTB の Priority SLA 2本だけが走りました。SLA Definition の Active フラグが、新規適用を止める最も確実なスイッチです。Inactive はあくまで新規適用を止める操作なので、仕掛中の扱いは次の設計手順で別途決めることになります。
廃止の実務は「定義を止めてから、仕掛中を見届けて、本体をリタイア」の順で設計する
ここからは実測を踏まえた設計の提案です。
SLA Definition を Inactive にする。これで新しい約束は結ばれなくなります
仕掛中の task_sla を決着まで見届ける。対応を完了させれば Completed で達成記録が残ります。業務上もう測る意味がない案件は、関係者と合意のうえタスク側をクローズします
Offering 本体をリタイアする。条件ガードを使っている場合は、ガードが見ているフィールド（Operational status など）を確実に変えます
選択肢に残る問題に対処する。参照修飾子は親サービスでしか絞らないため、リタイア済みでも選べます。運用周知でカバーするか、稼働状態で絞る参照修飾子を検討します
task_sla の集計で Cancelled／Completed を確認し、廃止後に In progress が増えていないことを見届けます
リタイアに使うフィールドが3系統あることも、ガード設計とセットで押さえておくと迷いません。
条件ガードを入れるかどうかは、キャンセル運用とセットで判断する
条件ガードを最初から入れておく設計（SLA-B 方式）は、リタイア後の最初のタスク更新で仕掛中も自動キャンセルされるのが利点です。一方で、キャンセルの発動がタスク更新任せになる点と、リタイア操作のフィールドと条件式のフィールドを揃え続ける運用負担がセットになります。実測でも、ライフサイクルだけを変えた段階ではガードは反応せず、Operational status を変えて初めて効きました。達成率レポートからキャンセル分を除外する集計設計と、リタイア手順書に「どのフィールドを変えるか」を明記する運用をそろえられるなら、ガードは有効な選択肢になります。
実機を見て気づいたこと
ライフサイクルの組み合わせは保存時に検証されます。 最初、Life cycle stage に Operational を設定し、status を空のまま Offering を保存しようとしました。すると「Invalid Life Cycle Stage and Stage Status combination」で保存自体が拒否されました。有効な組み合わせは life_cycle_control テーブルで管理されていて、Configuration Item では End of Life + Retired が正規のリタイア表現です。画面で普通に操作しているだけでは気づけない足回りでした。
親サービスをリタイアすると、配下の Offering に連鎖する標準ビジネスルールがあります。 cmdb_ci_service の「Retire Offerings if service is retired」で、親のライフサイクル値を配下の全 Offering にコピーします。サービスごと廃止する場合は Offering を1つずつ操作せずに済む一方、意図せず巻き込む可能性もあるので、存在は知っておきたい仕組みです。注意点もあります。このルールがコピーするのはライフサイクル系のフィールドだけで、Operational status には触れません。つまり Operational status を見るガード条件は、親サービス経由の連鎖リタイアでは発動しないことになります。
Cancelled になった task_sla は消えずに残ります。 キャンセルは「レコードの削除」ではなく「stage の遷移」でした。廃止の前後で何が起きたかは、後から一覧で全部追えます（全景は次の節の画像のとおりです）。
SLA Definition の名前は40文字で切り詰められました。 43文字の名前を付けたところ、保存後は40文字になっていました。Offering 名を含む命名規則にすると上限に当たりやすいので、短めの規則が安全です。
Offering の Support group には、CSDM のデータ同期に関する公式説明が付いています。 インシデントの Assignment group への自動コピーは前述のビジネスルールの働きです。それとは別に、service_offering.support_group のフィールドドキュメントは次のことを述べています。
In a technical service offering, data sync will be activated for this attribute
（訳: テクニカルサービスオファリングでは、この属性についてデータ同期が有効になります）
グループの紐付けは、インシデントへのコピーと CI 側への同期という2系統で使われる属性だと分かります。
引用元: /sys_documentation_list.do?sysparm_query=name=service_offering^hintISNOTEMPTY
用語の整理
Service Offering（service_offering）: サービスを提供条件の単位に分けた CMDB レコード。この記事の廃止対象
SLA Definition（contract_sla）: SLA のルール。開始・停止・キャンセルの条件と目標時間を持つ
Task SLA（task_sla）: タスク1件に付いた実際の時計。stage が In progress → Completed／Cancelled と遷移する
リタイア: CMDB レコードの稼働状態を Retired にする操作。レコード自体は残る
Operational status／Life cycle stage: どちらも稼働状態を表すフィールド。SLA のガード条件に効くのは条件式が見ている側だけ
検証環境と未検証範囲
検証が終わった時点で、今回作成した SLA 定義に紐づく Task SLA を1画面に集めた全景です（OOTB の Priority SLA は含めていません）。
この記事の挙動は、すべて Australia PDI（OOTB、2026-08-21 確認）での実測です。検証用に作成した Offering・SLA Definition・インシデントを実際に動かして確認しました。SLA Definition は4時間・スケジュールなし・Retroactive なし・When to cancel は Start conditions are not met で作成しました。検証のため PDI には検証データを追加しています。内訳は Offering 2件（うち1件は削除検証で削除済み）・SLA Definition 3本・インシデント4件（ほかに検証準備の不備で1件を作成後すぐ削除）です。既存レコードの変更や削除は行わず、デモデータの「Email」サービスは親として参照しただけです。
未検証の範囲もあります。SLA の一括再計算（Repair SLAs）を廃止後に実行した場合の挙動は確認していません。Advanced condition（スクリプト条件）を使った定義、スケジュール付き SLA でのキャンセル時刻の扱い、ドメイン分離環境での挙動も今回の範囲外です。When to cancel を Never にした場合の仕掛中 SLA の残り方も確認していません。本番環境やカスタマイズ済み環境では、ビジネスルールや参照修飾子が変更されている可能性があるため、同じ操作でも結果が変わり得ます。
自分の環境で確認するときのURL
Offering の一覧：/service_offering_list.do?sysparm_query=parent.name=Email
SLA Definition の一覧：/contract_sla_list.do?sysparm_query=collection=incident
特定インシデントの Task SLA：/task_sla_list.do?sysparm_query=task.number=INC0000001
ライフサイクルの有効な組み合わせ：/life_cycle_control_list.do
Service offering の参照修飾子（incident のオーバーライド）：/sys_dictionary_override_list.do?sysparm_query=name=incident^element=service_offering
Service offering の参照修飾子（task の元定義）：/sys_dictionary_list.do?sysparm_query=name=task^element=service_offering
引用した公式説明を自分で開く
この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開けば、引用元の原文にあたれます。
Start condition の公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=contract_sla^hintISNOTEMPTY
Service offering フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=service_offering^hintISNOTEMPTY
参考リンク
関連記事
SLA Definition（contract_sla）とは：時計を生むルール … 前提知識。開始・停止・一時停止の条件をフィールド単位で確認する定義編
ServiceNowのSLAはいつ違反になる？ 時計が動く条件と止まる条件を実機で確認 … 次に読む。時計の動き全般を実機で追う編
ServiceNowのSLAが付かない・すぐ止まる原因は？ Start/Stop条件の競合を実機で再現する … 実務編。条件設計の失敗パターンを再現する
