JinJin48

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

July 19, 2026 · 25 min read

SAP Service Cloud ケースルーティングルール

ケースルーティングは、従業員/チーム/キューを選択する単一の設定画面ではなく、2つの独立した決定テーブル（「ケースルーティング（従業員へ）」と「ケースルーティング（チームへ）」）であり、それぞれに独自の決定テーブルID、独自の行、独自の単一Result値があります。両方のテーブルは、サービスレベル決定（SC-A06-02）で文書化されている同じ汎用ルールテーブルエンジンを変更せずに再利用します。すなわち、列の適応（Adapt Columns）で設定可能な最大15列、行内はAND / 行間はORの評価、上から下への最初の一致で終了するショートサーキット、優先順位を示す唯一の信号としての行位置、明示的な有効化（Activate）ステップ、および一括メンテナンスのためのExcelエクスポート/インポートです。異なるのは出力のみです。「ケースルーティング（従業員へ）」のResult列はパーティロール40（「処理者」）を設定し、「ケースルーティング（チームへ）」のResult列はパーティロール28（「サービスおよびサポートチーム」）を設定します。また、この記事では2つのよくある混乱点を解消します。公式ドキュメントのどこにも正式な「キュー」オブジェクトは存在せず、AI駆動の「ケースタイプ決定」機能は、名前が似ているものの完全に無関係な機能であるということです。

パート1: ケースルーティングルール — 基本概念（全モジュール共通）#

1.1) ケースルーティング（従業員へ / チームへ）とは#

ケースルーティングは、ケースが作成または編集されるたびに、1つの運用上の質問に答えるために存在します。つまり、このケースのフィールド値に基づいて、どの従業員（またはどのチーム）がそれを担当すべきか、という質問です。SAP Service Cloudは、これを1つの統合オブジェクトではなく、2つの個別のルールテーブルで回答します。管理者は「ケースルーティング（従業員へ）」を設定して個々のエージェントを割り当て、独立して「ケースルーティング（チームへ）」を設定してサービスタイムを割り当てます。どちらのテーブルも、もう一方のルーティングロジックを格納しません。これらは対等な関係であり、共有画面の2つのモードではなく、それぞれ独自の決定テーブルIDを持ちます。

よくある誤解 — 正式な「キュー」ルーティングターゲットは存在しません。
「ケースの従業員へのルーティング」画面と「ケースのチームへのルーティング」画面のいずれも、Result値として「キュー」オブジェクトを公開しておらず、公式ソリューションガイドの全文検索でも、「queue」は無関係な統合/メッセージキュー（送信トピックキュー、メール再試行キュー）についてのみ使用されており、ケース割り当てのターゲットとしては決して使用されていません。一部のトレーニング資料で見られる非公式な表現「チームキュー」は、ワークフローの動作（マネージャーがレビューしたり、エージェントが自分で選択したりする、チームに割り当てられたケースのリスト）を説明するものであり、ルールテーブル内の個別の設定可能なオブジェクトではありません。「キュー」列、Result値、または画面をモデル化したり文書化したりしないでください。正式に存在するResultターゲットは、Processor（ケースの従業員へのルーティングによる）とService and Support Team（ケースのチームへのルーティングによる）の2つだけです。

明確化 — 「ケースタイプ判定」は別の無関係なAI機能です。 SAP Service Cloudのインテリジェントサービスには「ケースタイプ判定」と呼ばれる機能も含まれており、NLP/AIを使用してケースの件名と説明テキストからケースタイプフィールドを推測します。これは、すでにタイプ分けされたケースを担当者やチームにルーティングすることとは何の関係もありません。これら2つの機能は、日常会話で「判定」という一般的な単語を共有しているだけです。AIベースのケースタイプ推測と、この記事で扱う決定テーブルベースのケースルーティング（担当者/チームへの）を混同しないでください。

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

両方のルーティングテーブルは、サービスレベル決定（SC-A06-02）とまったく同じ評価ロジックで動作します。これを再利用しているのは偶然ではなく、文書化された共有エンジン設計であり、各記事が独立して成立するようにここに再掲しています。

設計原則 — 行の位置が優先順位フィールドであり、テーブルごとに独立しています。 サービスレベル決定と同様に、設定や監査のための数値の優先順位列はありません。ケースルーティング（従業員）とケースルーティング（チーム）は別々のテーブルであるため、それぞれに独立した行順序があります。一方のテーブルで行を並べ替えても、もう一方の評価順序にはまったく影響しません。

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

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

Client (SAP Service Cloud Tenant)
   │
   ├── Case Routing to Employee Rule Table (Status: Active)
   │        │
   │        ├── Row 1: Case Type = "Customer Service Case" AND Category = "Billing"
   │        │            ── Result ──> Processor "Agent: Jane Tanaka" (Party Role 40)
   │        │
   │        └── Evaluated top-to-bottom, independently of the Team table below
   │
   ├── Case Routing to Team Rule Table (Status: Active)
   │        │
   │        ├── Row 1: Case Type = "Customer Service Case" AND Source = "Email"
   │        │            ── Result ──> Service and Support Team "Billing Support EMEA" (Party Role 28)
   │        │
   │        └── Evaluated top-to-bottom, independently of the Employee table above
   │
   ├── Party Schema "Standard Case Party Schema" — governs both Party Role 40 (Processor)
   │        and Party Role 28 (Service and Support Team); with "Enforce consistency with
   │        source party" enabled, the system keeps the assigned Processor and the assigned
   │        Service and Support Team aligned, auto-clearing or updating one when the other
   │        is manually changed outside a valid team structure
   │
   ├── Case Type "Customer Service Case" ── read by both tables as a match column value
   │        (no field on either rule table pointing back to Case Type as an owned object)
   │
   └── Category "Billing" / Source "Email" ── read by their respective rows as match column
            values (same one-directional read, no reverse reference)

設計原則 — 2つのResult出力は、ルーティングテーブル自体ではなく、Party Schemaを介して運用上リンクされています。 ケースルーティング（担当者）とケースルーティング（チーム）は互いに直接参照することはなく、両者の間に共有の「マスタ」テーブルも存在しません。リンクは1階層上のParty Schema設定に存在します。Party Role 40と28に対して「ソースパーティとの整合性を強制」が有効化されている場合、システムは手動で割り当てられたエージェントが自身のチーム構造の範囲外にある場合に自動的に修正します。つまり、ケースは原則として、その処理担当者とサービス＆サポートチームを、たまたま一致する2つの完全に独立したルール評価から取得することも、一致しない場合にはこの整合性チェックによって調整が必要となることもあります。

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

ケースルーティングは他のいくつかのオブジェクトに影響を及ぼしますが、テーブルごとに常に同じ2つの方向で行われます。つまり、マッチ入力としてケースフィールド値を読み取り、その結果として単一のパーティロール値を書き込みます。以下の表は、どのリレーションシップがソース化され、どのリレーションシップが調査パスから未消込明細として残っているかを明確に示しています。

適用範囲に関する注記: (1) 両方のテーブルについて、選択可能なマッチ列の網羅的かつ最新の公式リストは存在しない。メカニズム（列の適応、利用可能な任意のケースフィールド、最大15列）は確認されているが、すべてのソースにわたって名前が挙げられている唯一の例示フィールドは、ケースタイプ、カテゴリ、ソース/チャネル、および（非公式に）アカウントである。(2) 各ルーティングテーブルがケースタイプ/ケーステンプレートごとにスコープ設定されているのか、それとも単一のグローバルテーブルであるのかは、決定的に確認されていない。トランスポートセクションにおける「ケーステンプレートバージョン内の…決定テーブルID」への言及は、テンプレートごとのスコープ設定を示唆しているが、コアとなる設定手順では、ルーティング方向ごとに1つの画面のみが説明されている。これは未解決の質問として扱うこと。(3) ケースがいずれかのテーブルで0行にマッチした場合の、文書化されたフォールバック/デフォルト動作は存在しない。セクション1.3の階層に関する注記および以下の設計原則を参照のこと。(4) 基礎となるルールエンジン技術は、ソリューションガイドのトランスポートセクションで正式に「決定テーブル」と呼ばれており、SC-A06-02からの、メカニズムの正式名称に関する以前の未解決の質問を解決するものである。これはBRFplusやその他の特定の技術として命名されてはいない。

設計原則 — 各テーブルの最終行に包括的な行を追加することは、文書化されたシステムデフォルトではなく、優れた実践方法です。 ケースが「ケースルーティングから従業員へ」または「ケースルーティングからチームへ」のいずれか、あるいはその両方で0行に一致した場合に何が起こるかについて、公式の情報源は何も述べていません。関連する唯一のデータポイントは、「未割当ケース数」が追跡対象の分析KPIであることです。これは、未割当状態が存在し監視されていることを確認しますが、その状態がルーティングルールの非一致によって特に引き起こされることを示すものではなく、他の原因による可能性もあります。記事や設定ガイダンスで特定のフォールバックメカニズムを記載しないでください。各テーブルに最終行としてワイルドカード行を追加することを推奨される安全対策として扱い、本番環境で特定のフォールバックが存在すると仮定する前に、サンドボックステナントで実際の非一致動作を確認してください。

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

2.0) SC所有権の範囲#

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

2.1) 従業員へのケースルーティング（ルールテーブル設定）#

これは、管理者が個々のケースを特定の人間のエージェントにルーティングするために開く画面であり、セクション2.2のチームテーブルとは別個で、完全に独立して設定されます。

2.2) ケースのチームへのルーティング（ルールテーブル設定）#

これは、ケースを個人ではなくサービスチームにルーティングするために使用される兄弟画面であり、従業員画面内にネストされるのではなく、独自のメニューエントリからアクセスします。

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

各行は、実際に個別に作成されたルールであり、ルーティングテーブル両方の基本単位であり、どちらのテーブルでも同じように機能します。

2.4) 行順序 / 優先順位#

これは、あるケースが理論上複数の行に一致する可能性がある場合に、実際にどのルールが優先されるかを決定する仕組みであり、従業員テーブルとチームテーブルで完全に別々に管理されます。

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

どちらのテーブルを編集しても、本番動作に対して意図的に非破壊的です。明示的なステップが完了するまでは何も有効にならず、2つのテーブルの有効化状態が互いに影響を与えることは決してありません。

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

ルールテーブルが大きくなった場合、UIで1行ずつ編集するのは実用的ではなくなります。SAPは、サービスレベル決定の場合と同様に、ルーティングテーブルに対しても同じオフラインパスを提供しています。

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

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction