JinJin48

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

July 18, 2026 · 22 min read

SAP Service Cloud ケースタイプ

ケースタイプは、管理者がリストから選択する単純なカテゴリや分類値ではありません。独自のフェーズ、ステップ、承認、自動化フロー、スキーマ、機能トグルを持ち、ケース作成時にインスタンス化される、コピー可能なプロセステンプレートです。ケースタイプに「新規作成」アクションは存在せず、新しいケースタイプは常に既存のケースタイプのコピーとして作成されます（SAPはこの目的のためにスターターテンプレート「SMPL - サンプルケースタイプ」を提供しています）。また、管理者が設定を完了し「アクティブ」に切り替えるまで、ドラフトステータスで保持されます。この記事では、ケースタイプレコードが実際に所有するもの、ほとんどの設定がドラフト中にのみ編集可能な理由、サービスカテゴリに直接リンクするという一般的な誤解の解消、およびケースルーティングルールやサービスレベル決定などの下流オブジェクトがケースタイプをどのように消費するかの方向性について説明します。

パート1: ケースタイプ — 基本概念（全モジュール共通）#

1.1) ケースタイプとは#

ケースタイプは、製品クレーム、保証請求、一般的なサービスリクエストといった個別のサービスプロセスを、毎回個別に設定するのではなく、再利用可能なテンプレートとしてモデル化するために存在します。これは、管理者が組織にいくつ必要かを決定するオブジェクトです。「1つまたは複数のケースタイプが必要かどうかを判断するのは管理者の責任です。」インスタンス化されると、ケースは、そのケースタイプで定義されたフェーズ、ステップ、承認、自動化フローを実行するリクエストのライブレコードとなり、エージェントが処理を進める際に視覚的にガイドします。

設計原則 — ケースタイプはテンプレートであり、カテゴリではありません。 新しいケースタイプコードは、顧客（Z）名前空間で作成する必要があり（最大4文字、スペースや特殊文字なし）、常に既存のケースタイプを 「新規ケースタイプにコピー」 でコピーして生成され、空の「作成」フォームからは生成されません。コピー後、管理者がケースタイプIDと説明を設定すると、レコードは 「ドラフト」 ステータスで開始されます。このコピー優先、テンプレートベースの作成パターン自体が、ケースタイプがサービスカテゴリのような軽量なルックアップ値ではなく、構造的なプロセス定義（フロー＋スキーマ＋機能トグル）であることの証拠です。

よくある誤解 — ケースタイプはサービスカテゴリを直接参照しません。 ケースタイプはオプションでサービスカタログを選択するだけであり、それ以上のものではありません。サービスカテゴリやカテゴリレベルを指すフィールド、設定、依存関係エントリは一切ありません。そのタイプのケースを作成する際にエージェントが表示するカテゴリは、単に割り当てられたカタログに属するカテゴリにすぎません。ケース上のカテゴリフィールドを編集可能にするためのSAP自身のガイダンスは、「使用するケースタイプにカタログが割り当てられていることを確認する」ことであり、ケースタイプ自体にカテゴリを割り当てることではありません。ケースタイプにカタログがない場合、テナントの他の場所にどれだけ多くのカテゴリが存在していても、新しいケースのカテゴリフィールドは編集不可のままです。完全な関係表についてはセクション1.4、またカテゴリ側から独立して同じ結論に達したものについてはSC-A05-02（サービスカテゴリ）を参照してください。

1.2) ケースタイプライフサイクル：ドラフト、アクティブ、新バージョン作成#

ケースタイプのステータスを誤って設定することは、単なる見た目の問題ではありません。そのプロセスを定義するフィールドが編集可能かどうかを直接決定するものであり、SAPはこれを回避すべき制限ではなく、意図された動作として文書化しています。

設計原則 — 既存のケースはバージョン固定であり、ライブリンクされていません。「ケースが特定のケースタイプで作成されると、そのタイプにバインドされるだけでなく、そのタイプの現在のアクティブバージョンにもバインドされます」— これはシステム設計上の動作として明示的に文書化されており、欠陥ではありません。実際には、ケースタイプの新しいバージョン2を作成し、その割り当てられたサービスカタログを変更した場合、バージョン1で作成されたすべてのケースはバージョン1のカタログ（したがって元のカテゴリツリー）を保持します。変更は遡及的に適用されません。ケースタイプのバージョン変更はこれを考慮して計画してください。新しいバージョンでカタログを再割り当てしても、進行中のケースの分類は移行されません。

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

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

Client (SAP Service Cloud Tenant)
   │
   ├── Case Type "ZVRC - Vehicle Repair Case" (copied from "SMPL - Sample Case Type"; Status: Active, Version 2)
   │        │
   │        └── assigned to (Draft status only) ──> Service Catalog "SVC-CATALOG-AUTO"
   │                                                    (never assigned directly to any Service Category level)
   │
   └── Service Catalog "SVC-CATALOG-AUTO" — Catalog Display ID: SVC-CATALOG-AUTO; Object Types Supported: Case, Phone, Chat, Email
            │
            └── Service Category (Level 1) "Vehicle Service" — Category Display ID: VEHICLE-SERVICE
                    │
                    └── Service Category (Level 2) "Engine" — Category Display ID: ENGINE
                            │
                            └── Service Category (Level 3) "Oil Change" — Category Display ID: OIL-CHANGE
                                    │
                                    └── Service Category (Level 4) "Synthetic Oil Change" — Category Display ID: SYNTHETIC-OIL-CHANGE

   Email Channel "Support Inbox" ── determines (via Case Type Determination Rules) ──> Case Type "ZVRC - Vehicle Repair Case"

   Case Routing Rule "Route Vehicle Repair to Field Team" ── matches on (mandatory) ──> Case Type "ZVRC - Vehicle Repair Case"

   Service Level Determination Rule "Auto SLA - Urgent Repair" ── matches on (input) ──> Case Type "ZVRC - Vehicle Repair Case"

設計原則: ケースタイプは、テナントレベルでサービスカタログと並んで配置され、カテゴリツリーの上位または下位には位置しません。カタログ/カテゴリ構造への唯一の出力矢印はサービスカタログで終わります。サービスカタログより下位（4つのサービスカテゴリレベル）には、ケースタイプが参照するカタログを介して、かつその参照が存在する間のみ、推移的に到達します。逆方向では、ケースタイプ自体が上図に示す2つの別個の矢印のターゲットとなります。メールチャネルのケースタイプ決定ルールは、ケース作成時に自動的にケースタイプを選択できます（これは下流のコンシューマとは異なる上流の決定ステップです）。一方、ケースルーティングルールとサービスレベル決定ルールは、両方とも、すでに割り当てられたケースタイプを自身の照合条件の1つとして扱います。ケースタイプがこれら2つのオブジェクトのいずれかに逆方向にアクセスすることはありません。依存関係は一方向であり、入力としてケースタイプに入ります。

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

ケースタイプは、他のいくつかのマスタデータおよびコンフィギュレーションオブジェクトに関係しますが、明確に異なる2つの方向性があります。すなわち、オプションで1つのリンク（サービスカタログへの）のソースとなることと、下流の複数のオブジェクトが入力として参照するターゲットとなることです。以下の表は、各関係がどの方向で機能するかを明確に示し、ソース資料が完全に確認できなかった項目にフラグを立てています。

適用範囲に関する注記: (1) ケースタイプIDが作成後に不変であると直接明記したソースは存在しないが、間接的な証拠（Z名前空間プレフィックスルール、およびすべてのフィールド変更がID編集アクションではなく「新規バージョンの作成」を経由するという事実）から、実務上は永続的なキーとして扱うことが支持される。ただし、本記事は文書化された不変性ルールを主張するものではない。(2) ケースタイプレコードに「デフォルトチーム/キュー」フィールドがネイティブに存在するかどうかは、使用したソースからは確認できなかった。チームまたは従業員へのルーティングは、ケースタイプ自体に保存されたフィールドではなく、ケースタイプを入力として使用する個別のケースルーティングルールによって完全に管理されているように見える。これは確認された欠落ではなく、作業仮定として扱うこと。

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

2.0) SC所有権の範囲#

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

2.1) ケースタイプヘッダ（基本属性）#

これは、すべてのケースタイプが持つIDレコードであり、そのフローや設定がどのようなものであっても変わりません。これらのフィールドを正しく設定すれば、ケースタイプは正しく命名され、正しいステータスが付与され、コピー元のテンプレートまで追跡可能になります。

2.2) 基本設定#

一般設定は、ケースタイプに番号体系、ステータスフロー、およびパーティモデルを付与する構造設定であり、パート1全体で説明されているオプションのカタログリンクも含まれます。4つのフィールドすべてに、セクション1.2のドラフト専用変更ルールが適用されます。

2.3) 機能設定#

フィーチャー設定は、コアケースフローに重ねて適用できるトグル式の機能です。各設定は、上記の一般設定とは独立して、このケースタイプのケースに対して、エージェント向けまたは自動化の個別機能を有効にします。

2.4) ケースフロー（フェーズ、ステップ、承認、自動フロー）#

ケースフローは、ケースタイプの背後にある実際のプロセス定義であり、分類値ではなくテンプレートとして説明される理由です。これは、フェーズ、ステップ、承認、および自動化フローで構成され、エージェントがケースを処理する際に視覚的にガイドします。また、上記の一般設定と同様に、ケースタイプがドラフトステータスの場合にのみ編集できます。

前提条件: ケースフローはドラフトでのみ編集可能であるため、アクティブなケースタイプのフェーズ、ステップ、承認、または自動フローを変更するには、まず新バージョンの作成（セクション1.2）が必要です。ライブのケースタイプのフローをその場で編集するパスはありません。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction