JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 19, 2026 · 20 min read

SAP Service Cloud サービスレベル

サービスレベルは、ケースにどのSLAが適用されるかを決定するルールではありません。それ自体がSLA目標です。すなわち、組み込まれた営業時間定義に対して測定される一連のマイルストーン期日（応答、初回レビュー、完了、解決）であり、それ以上でもそれ以下でもありません。このレコードには優先度フィールドはなく、ケースタイプや判定ルールへの参照もありません。この記事では、サービスレベルレコードが実際に保持するもの、時間ベースと日ベースの所要時間が営業時間に対してどのように異なる動作をするか、単一のサービスレベルが内部で優先度によって目標を変えられるという一般的な誤解を解消し、サービスレベル決定（SC-A06-02）がサービスレベルを消費するという一方向の関係（逆は決してない）を確立します。また、注意すべき命名の衝突についても触れます。「サービスレベル」/「SLA」という用語は、SAPポートフォリオ内の他の少なくとも3つの無関係な概念にも使用されています。

パート 1: サービスレベル — 基本概念（全モジュール共通）#

1.1) サービスレベルとは#

サービスレベルは、再利用可能な1つのレコードとして、ケースをどの程度の速さで処理すべきか、またその速度が実際に計測される時間帯を定義するために存在します。これには4つのマイルストーン（応答期限、初回レビュー期限、完了期限、解決期限）が含まれており、それぞれに独自の計算基準、期間、オプションの延長が設定され、さらに組み込みの営業時間ブロックによって、営業時間外に時計を停止するか、それとも暦日を通じて継続してカウントするかが決定されます。一度有効化されると、サービスレベルは、別個のルールエンジン（サービスレベル決定）内でのターゲット値としてのみ選択可能になります。サービスレベル自体がケースに対して自動的に選択されることは決してありません。

命名の衝突 — 「Service Level」/「SLA」は、SAPポートフォリオ全体で4重にオーバーロードされた用語です。 少なくとも4つの異なるものがこの名前を共有しています。(a) SAP自身の契約上のクラウド稼働時間サービスレベル契約文書（sap.com → About → SAP Agreements → SAP Cloud Services Customers）で、プラットフォームの可用性保証をカバーし、アプリ内のケースデータとは無関係です。(b) 従来のSAP Cloud for Customer / Service Cloud V1「SLAセットアップ」（管理者 → サービスとソーシャル → SLAセットアップ — 応答時間/解決時間/可用性メトリクスを使用するスコーピングおよびメトリクスプロセス）。(c) SAP Solution ManagerのITSM/ChaRM SLA（サービスプロファイル、IRT/MPT/OLA、SOLMAN_SETUPで設定 — オンプレミスのABAPスタックチケット管理コンセプト）。(d) 本記事で扱うSAP Service Cloud V2サービスレベルオブジェクト（マイルストーン + 組み込み営業時間、設定 → ケース管理 → サービスレベルで設定）。これら4つはすべて応答時間/解決時間の用語を共有しており、このフレームワークの他の箇所で扱われるほとんどの命名の衝突よりも、混同するリスクが高くなっています — ここに適用する前に、ドキュメント、サポートチケット、または同僚のコメントのうち、どれが実際に説明しているのかを確認してください。

よくある誤解 — サービスレベルはサービスレベル決定ではありません。 サービスレベル（本記事）はSLA目標定義そのものです — マイルストーン、期間、および埋め込まれた営業時間ブロックで構成されます。サービスレベル決定（SC-A06-02）は、ケースタイプや優先度コードなどの入力に基づいて、特定のケースにどのサービスレベルを適用するかを決定する独立したルールエンジンであり、作成後に独自の設定ステップとしてアクティベーションが必要です。サービスレベルには、ケースタイプ、優先度、または決定ルールを参照するフィールドはありません — 依存関係は一方向であり、サービスレベル決定はサービスレベルを出力/目標値として消費しますが、その逆は決してありません。

1.2) マイルストーン、期間タイプ、営業時間#

時間単位と日単位のDurationの違いを誤ることは、表面的なミスではありません。SLAのクロックが営業時間外に停止するか、夜間、週末、祝日も進み続けるかが変わり、SAPではこの2つの動作を丸めのニュアンスではなく、真に異なる計算パスとして文書化しています。

設計原則 — 時間単位の期間は営業時間を考慮し、日単位の期間は暦日をカウントします。 マイルストーンの期間が時間（または分/秒）で入力された場合、システムはサービスレベルの営業時間内に該当する時間のみをカウントします。つまり、SLAクロックは営業時間外では実質的に停止し、「24時間」は24暦時間ではなく、24稼働時間を意味します。期間が日（または月）で入力された場合、システムは稼働日カレンダーを使用してカウントする日を決定しますが、勤務設定の特定の時間帯は適用されません。該当する各日は、実際に作業が行われる時間に関係なく、1暦日としてカウントされます。サポートされている期間単位は、日、月、時間、分、秒です。表示される数値だけでなく計算方法も変わるため、単位は意図的に選択してください。

よくある誤解 — サービスレベルレコードには優先度フィールド（V2）がありません。 従来のV1「SLA設定」とは異なり、単一のV2サービスレベルレコードでは、内部で優先度に応じてマイルストーン目標を変えることはできません。ゴールド層のケースに2時間の応答期限、シルバー層のケースに8時間の応答期限が必要な場合、それには2つの個別のサービスレベルレコード（層ごとに1つ）が必要であり、優先度依存のフィールドを持つ1つのレコードでは不十分です。優先度コードが意味を持つのは、1階層上の、特定のケースに2つのレコードのどちらを適用するかを選択するサービスレベル決定ルール（SC-A06-02）内の一致パラメータとしてのみです。

1.3) 組織レベルとデータ階層#

データ階層の具体例（テナントレベル；SAP Service Cloudには、この上位に会社コード/プラントのスコープ設定はありません）

Client (SAP Service Cloud Tenant)
   │
   ├── Service Level "GOLD - Premium Support" (Status: Active)
   │        │
   │        ├── Milestones: Response Due (2 Hours), Initial Review Due (4 Hours),
   │        │               Completion Due (1 Day), Resolution Due (3 Days)
   │        │
   │        └── Operating Hours (embedded) ── references ──> Working Day Calendar "APAC-STANDARD"
   │                                                              │
   │                                                              └── linked Holiday Calendar "JP-HOLIDAYS-2026"
   │             Time Zone: Asia/Tokyo
   │             Working Configuration: Mon–Fri 09:00–18:00 (single slot)
   │
   ├── Service Level "SILVER - Standard Support" (Status: Active)
   │        │
   │        ├── Milestones: Response Due (8 Hours), Initial Review Due (1 Day),
   │        │               Completion Due (3 Days), Resolution Due (5 Days)
   │        │
   │        └── Operating Hours (embedded) ── references ──> Working Day Calendar "APAC-STANDARD" (shared)
   │
   └── Working Day Calendar "APAC-STANDARD" — shared master object, maintained under
            Settings → Calendar → Working Day Calendar (not created fresh per Service Level)

   Service Level Determination Rule "Auto SLA - Gold Tier"
      ── matches on (Case Type = "Customer Service Case" AND Priority Code = "01 - Immediate") ──>
      selects Service Level "GOLD - Premium Support"

設計原則 — 稼働日カレンダーは共有され、個別に管理されるマスタであり、サービスレベルごとに新たに入力される値ではない。 稼働日カレンダー（およびそれにリンクされる休日カレンダー）は、独自のフィールド（稼働カレンダー名/コード、有効期間（From/To）、該当国/地域、日ごとのトグル、週の開始日）を持つ独立した設定オブジェクトであり、サービスレベルの営業時間ブロックはそれを参照するのみである。同じ地域の2つのサービスレベル（例：ゴールド層とシルバー層）は、通常、同じ稼働日カレンダーを参照し、マイルストン期間のみが異なる。このカレンダーオブジェクトは、プラットフォームの他の場所でも使用される（同等のSAP Sales Cloud V2設定画面で確認済み。Service Cloud V2専用オブジェクトではなく、Sales Cloud V2とService Cloud V2で共有されるインフラストラクチャとして中程度の確信度で扱うこと）。対照的に、タイムゾーンと稼働設定は、サービスレベル自身の営業時間ブロックに直接設定され、他の場所から参照されることはない。

1.4) 他のマスタデータオブジェクトとの統合#

サービスレベルは他の複数のオブジェクトに影響を及ぼしますが、その方向性は明確に2つに分かれます。オプションで1つのマスタ（稼働日カレンダ）をソースとして参照し、下流のルールエンジンが選択するターゲットとなります。以下の表は、各リレーションシップがどの方向で機能するかを明示し、ソース資料で完全に確認できなかった項目にフラグを立てています。

適用範囲に関する注記: (1) ソース資料により、サービスレベルは、このフレームワークの他の場所（サービスカタログ、サービスカテゴリ、ケースタイプ）で見られるものと同じドラフト→アクティブのライフサイクルパターンに従うことが確認されているが、すでにアクティブなサービスレベルに対する正確な再編集メカニズム（例えば、ケースタイプのように「新規バージョン作成」アクションが存在するかどうか）については、今回の調査パスでは独立して確認されなかった — 可能性は高いが未確認として扱うこと。(2) 上記で「ケースエスカレーションメトリクス」ビューに起因するとされたケース側のフィールドグループは、検索インデックスの要約のみに基づいている。調査中に一次的なSAPヘルプポータルのページがレンダリングできなかったため、これらの特定のフィールド名は、確定した画面レイアウトではなく、中程度の信頼度として扱うこと。(3) SAP Service Cloud V2が専用の「SLA違反」イベントタイプをSAPイベントメッシュに公開するかどうかは、一次ソースに対して確認できなかった — ケースライフサイクルイベントは一般的にイベントメッシュに公開されるが、特定のSLA違反イベントタイプについてはここでは主張しない。

パート 2: SC固有のフィールド詳細#

2.0) SC所有権の範囲#

凡例: ◎ = オーナー / クリティカル、○ = 直接関与

2.1) サービスレベルヘッダ（基本属性）#

これは、定義するマイルストーンや営業時間に関係なく、すべてのサービスレベルが持つ識別レコードです。これらのフィールドを正しく設定すれば、サービスレベルは適切に命名され、正しいステータスが付与され、決定対象として選択できる状態になります。

2.2) マイルストーン#

マイルストーンは、サービスレベルが実際にSLAとして約束するものです。応答、レビュー、完了、解決の4つの期日がそれぞれ独立して設定され、これらが連携してケースがどの程度の速さで各段階を通過すべきかを定義します。

2.3) 稼働時間#

稼働時間は、サービスレベルレコードに直接埋め込まれたブロックであり、時間ベースの所要時間のクロックが営業時間外に停止するかどうかを決定します。その基礎となる計算ロジックについては、セクション1.2を参照してください。

2.4) ケース側のマイルストーンフィールド#

以下は、各サービスレベルマイルストーンが完了するたびに、割り当てられたケースに書き戻される読み取り専用属性です。これらはサービスレベルレコード自体に設定された項目ではなく、その観測可能な結果です。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction