JinJin48

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

July 19, 2026 · 20 min read

SAP Service Cloud サービスレベル決定

サービスレベル決定は、SLA時間が保存される別の場所ではありません。これは、すでに有効化されているサービスレベル（SC-A06-01）のうち、どのサービスレベルが特定のケースに適用されるかを決定する判断テーブルであり、ケースタイプや優先度コードなどの入力を照合し、結果として単一のサービスレベルを出力します。管理者は、最大15列のルールテーブルとしてこれを設定し、上から下に評価され、最初に完全一致した行が優先されます。優先順位を決定するのは、数値の優先度フィールドではなく、行の位置です。まったく同じメカニズム（列の適応、行内のAND/行間のOR、上から下への最初の一致、明示的な有効化ステップ）は、ケース管理のケースルーティング（従業員およびチームへのルーティング）でも再利用されているため、この記事では、サービスレベル決定が、専用のSLAエンジンではなく、共有された汎用パターンの特定のインスタンスであることも示しています。また、この機能と、製品内の別の場所にある、無関係でありながら似た名前を持つ汎用的な「決定」設定フレームワークとの間に明確な線引きをしており、両者は単に単語を共有しているだけで、メカニズムは共有していません。

第1部: サービスレベル決定 — 中核概念（全モジュール共通）#

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

決定ルールは、ケースが作成または編集されるたびに、常に1つの質問に答えるために存在します。すなわち、「このケースのフィールド値に基づいて、複数の可能性のあるサービスレベルレコードのうち、どれがそのSLAタイマーを管理すべきか」という質問です。このルールは、管理者が定義した行のテーブルをケースに対して評価し、最初に一致した行に指定されたサービスレベルを適用することで機能します。ルール自体は、SLA時間、マイルストーン、営業時間を一切保存しません。これらはすべて、ルールが選択するサービスレベルレコード（SC-A06-01）に存在します。

よくある誤解 — これはSAP Service Cloudの他の場所にある汎用的なDeterminationフレームワークと同じ「Determination」ではありません。 SAP Service Cloudには、文字通り「Determination」と呼ばれる別の汎用設定フレームワークも存在します。これは、ヘッダ（名前、トリガーイベント）＋条件ブロック＋割当ブロックとして構成され、Pre Hook（フィールドをデフォルト設定、上書き可能）とPost Hook（フィールドを強制設定、上書き不可）の実行ポイントを持ち、通常、ケースタイプと発信元に基づいてケースの優先度をデフォルト設定または強制設定します。サービスレベル割当をこのヘッダ/条件/割当フレームワークに結びつけるソースはありません。代わりに、サービスレベル決定は、ケースルーティング（従業員/チームへ）と共有するプレーンな決定テーブルメカニズムを使用します。この2つの機能は名前の一部を共有しているだけです — サービスレベル決定がPre/Post Hookで動作するものとして説明したり、汎用的なDeterminationフレームワークをSLA関連として説明したりしないでください。

1.2) ルールロジック：照合列、評価順序、有効化#

AND/ORの方向を逆にしてしまうことは、このテーブルを誤設定する最も一般的な原因です。1行内のすべての値はすべて同時に真である必要があり、一方、別々の行は互いに代替関係にあり、発動した最初の代替のみが実際に適用されます。

設計原則 — 行の位置が優先順位フィールドです。 ルールテーブルに明示的な数値の「優先順位」列があるツールから移行してきたビジネス関係者は、ここではその期待を捨てる必要があります。サービスレベル決定では、テーブル内の行の物理的な位置がそのまま優先順位であり、上から下への評価、最初に一致したルールが優先されるという仕組みによって純粋に強制されます。行の順序自体とは別に、独立した優先順位番号を設定したり監査したりすることはありません。

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

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

Client (SAP Service Cloud Tenant)
   │
   ├── Service Level Determination Rule Table "Case SLA Assignment" (Status: Active)
   │        │
   │        ├── Row 1: Case Type = "Customer Service Case" AND Priority Code = "01 - Immediate"
   │        │            ── Result ──> Service Level "GOLD - Premium Support"
   │        │
   │        ├── Row 2 (catch-all, recommended practice — not a documented system default):
   │        │            Case Type = "*" AND Priority Code = "*"
   │        │            ── Result ──> Service Level "SILVER - Standard Support"
   │        │
   │        └── Evaluated top-to-bottom: Row 1 short-circuits the table for any matching Case;
   │             Row 2 is only reached when Row 1's conditions are not met
   │
   ├── Service Level "GOLD - Premium Support" (Status: Active) ── referenced as Row 1's Result value
   │
   ├── Service Level "SILVER - Standard Support" (Status: Active) ── referenced as Row 2's Result value
   │
   ├── Case Type "Customer Service Case" ── read by Row 1 as a match column value (no field on the
   │        rule pointing back to Case Type as an owned object — the rule only reads its current value)
   │
   └── Priority Code "01 - Immediate" (one of a fixed set of four priority codes) ── read by Row 1
            as a match column value (same one-directional read, no reverse reference)

設計原則 — 最終行をキャッチオールとして設けることは、文書化されたシステムデフォルトではなく、優れた実践方法です。 ケースがテーブルのどの行にも一致しない場合に何が起こるか — サービスレベルが割り当てられず（したがってSLA期日も設定されない）、暗黙のデフォルトが適用されるのか、あるいは管理者が防止すべき未定義の動作であるのか — について、公式ソースは何も述べていません。上記の行2のように最終行にワイルドカード行を追加することを推奨される安全策として扱い、本番環境で特定のフォールバックが存在すると仮定する前に、サンドボックステナントで実際の不一致動作を確認してください。

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

サービスレベル決定は、他のいくつかのオブジェクトに関係しますが、常に同じ2つの方向性を持ちます。つまり、マッチング入力としてケースフィールド値を読み取り、その結果として単一のサービスレベルを書き込みます。この表は、どの関係がソース（情報源）であり、どの関係が調査パスからの未解決項目のままであるかを明確に示しています。

適用範囲に関する注記: (1) 現時点で、V2ルールテーブルにおいてケースタイプと優先度コード以外に選択可能なすべての照合列を網羅した公式の完全なフィールドリストは存在しません。公式ガイドでは、その仕組み（列の適応、利用可能な任意のケースフィールド、最大15列）について説明されていますが、固定されたデフォルトセットは列挙されていません。コミュニティ資料や従来製品の公式ガイドに記載されている、より広範なフィールドリスト（サービスタイプ、製品カテゴリ、サービスカテゴリ、国/地域、顧客グループ）は、あくまで参考例として扱うべきであり、現在のV2リストとして確定したものではありません。(2) 基盤となるルールエンジンの技術（BRFplusで実装されているか、独自のビジネスルールサービスであるかなど）は、現在のSAP Service Cloud Version 2のドキュメントには記載されておらず、断言すべきではありません。(3) 一致する行がゼロの場合のフォールバック動作は文書化されていません。セクション1.3の設計原則を参照してください。

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

2.0) SC所有権の範囲#

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

2.1) ルールテーブル設定（列の適応）#

任意の行を入力する前に、テーブル独自の列構造を設定する必要があります。これは一度だけ（ただし再訪問可能な）ステップであり、照合対象として利用可能なケースフィールドを決定します。

2.2) ルール行（照合列 + 結果列）#

各行は、実際に個別に作成されたルールであり、機能全体の最小単位です。

2.3) 行順序 / 優先順位#

これは、あるケースが理論上複数の行に一致する可能性がある場合に、実際にどのルールが優先されるかを決定する仕組みです。

2.4) アクティベーション状態#

このテーブルの編集は、本番動作に対して意図的に非破壊的です — 明示的なステップが完了するまで、何も有効になりません。

2.5) 一括メンテナンス (Excel エクスポート/インポート)#

ルールテーブルが大きくなった場合、UIで1行ずつ編集するのは現実的ではなくなります。SAPはまさにこのケースのためにオフラインでの方法を提供しています。

前提条件: まずカラム構造が存在している必要があります。エクスポート/インポートは行値のメンテナンスツールであり、カラム設計ツールではありません。UIで「カラムの適応」を最初に実行せずに、インポートファイルを介してまったく新しいマッチフィールドを導入することは、文書化されたワークフローではありません。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction