JinJin48

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

July 18, 2026 · 18 min read

SAP Service Cloud サービスカテゴリ

サービスカテゴリは、SAP Service Cloudのカテゴリ構造における最下層の分類レコードです。「各サービスカテゴリは、サービスカタログに関連付けられている必要があります。」カテゴリは、親となるサービスカタログ（SC-A05-01）の参照なしには作成、インポート、表示することができません。また、最上位カテゴリの下に最大3階層のサブカテゴリをネストでき、合計で4階層までとなります。サービスカテゴリレコードが行わないことも同様に重要です。つまり、独自のオブジェクトタイプ/チャネルフィールドを持たず（そのスコープ設定は完全に親カタログに属します）、また、ケースタイプ設定画面でカタログ割り当てがカテゴリに隣接しているように見えても、ケースタイプが特定のカテゴリを保存したり選択したりすることはありません。この記事では、カテゴリ独自のフィールドセット、その階層とライフサイクルルールについて説明し、フィールドレベルの詳細に入る前に、そのケースタイプの疑問を明確に解決します。

パート 1: サービスカテゴリ — 基本概念（全モジュール共通）#

1.1 サービスカテゴリとは#

カテゴリは、ケース、電話、チャット、またはメールに対して一貫性のある構造化されたラベル（エージェントが手入力する自由テキストメモではなく、「エンジン > オイル交換」など）を付与するために存在します。これはコンテナそのものではなく、グループ化とチャネルスコープは1階層上のサービスカタログで管理されます。サービスカテゴリは、管理者が実際に名前、ステータス、および（オプションで）親カテゴリを入力して登録するレコードであり、エージェントがケースを分類する際に実際に選択するレコードです。

よくある誤解 — ケースタイプはサービスカテゴリを直接参照しません。 読者は、ケースタイプが最終的にエージェントが選択できるカテゴリを決定するため、ケースタイプレコード自体にカテゴリ参照が格納されていると想定するかもしれません。しかし、そうではありません。公式のセットアップガイドにおけるサービスカテゴリの「他のエンティティへの依存関係」テーブルには、外部依存関係としてサービスカタログのみが1つリストされており、ケースタイプ、ケース、ケースルーティング、またはサービスレベルに関するエントリはありません。独立して、ケースタイプの設定手順におけるカタログ割り当てのステップには、「(オプション) ケースタイプのサービスカタログを選択します」とだけ記載されており、カテゴリについては一切触れられていません。カテゴリがケースタイプに与える影響はすべて間接的であり、共有カタログを介して仲介されます。完全な関係テーブルについてはセクション1.4を参照してください。

1.2 カテゴリステータスと一方通行アクティベーションライフサイクル#

カテゴリのステータスは、そのカテゴリが選択可能かどうかを決定します。アクティベーションの順序を誤ると、それを単純に元に戻すことはできません。SAPはこの制限を明示的に文書化しており、UIの詳細ではなく設計上の制約として扱う価値があります。

設計原則: カテゴリIDは一度入力すると変更できません — 「カテゴリのIDを入力すると、後から変更することはできません」 — ただし、カテゴリ名と説明はいつでも編集可能です。一方向のアクティベート/非アクティブ化ルールと組み合わせると、カテゴリレコードの識別子とそのステータスは、一度決定すると事実上永続的な決定となります。本番稼働前にカテゴリIDと分類体系を慎重に計画してください。IDの名称変更や再アクティブ化のオプションは代替手段として存在しません。

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

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

Client (SAP Service Cloud Tenant)
   │
   └── Service Catalog "SVC-CATALOG-AUTO" — Catalog Display ID: SVC-CATALOG-AUTO; Object Types Supported: Case, Phone, Chat, Email
           │
           └── Service Category (Level 1, top-level) "Vehicle Service" — Category Display ID: VEHICLE-SERVICE; Catalog Display ID: SVC-CATALOG-AUTO; Category Status: Active
                   │
                   └── Service Category (Level 2) "Engine" — Category Display ID: ENGINE; Parent Category Display ID: VEHICLE-SERVICE
                           │
                           └── Service Category (Level 3) "Oil Change" — Category Display ID: OIL-CHANGE; Parent Category Display ID: ENGINE
                                   │
                                   └── Service Category (Level 4, maximum depth) "Synthetic Oil Change" — Category Display ID: SYNTHETIC-OIL-CHANGE; Parent Category Display ID: OIL-CHANGE

   Case Type "Vehicle Repair Case" ── assigned to (draft status only) ──> Service Catalog "SVC-CATALOG-AUTO"
                                                                            (never assigned directly to any Service Category level above)

設計原則: 「最上位カテゴリの下に最大3レベルのサブカテゴリを設定でき、カテゴリカタログ全体で合計4階層レベルを提供できます」 — これはカテゴリ自体の管理用チャプターに直接記載されており、ケースエンティティの「カテゴリレベル1～4」フィールドおよびケース分類FAQ（「ケース分類は最大4レベルまでサポートします」）によっても独立して裏付けられています。SAP独自のデータインポートツールも、第4の角度からこれを補強しています。すなわち、サービスカテゴリは、サービスカタログとは異なり、インポート機能マトリックスで「階層エンティティ」としてフラグ付けされており、この指定はテーブル全体でわずか2つの他のエンティティ（組織単位と製品グループ）と共有されています。カテゴリのparent_external_key / 親カテゴリ表示IDフィールドは、最上位カテゴリの場合のみ空白のままにされます。レベル1より下のすべてのサブカテゴリは、カタログではなく、直接の親カテゴリを宣言する必要があります。

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

サービスカテゴリには、真にソースされた構造上の依存関係が1つだけ存在します。それは親であるサービスカタログであり、他にはありません。以下のいくつかのオブジェクトは、名前、目的の記述、または共有された階層パターンによって関連していると推定される可能性がありますが、表は、それらの推定のうち、ドキュメントが実際にサポートしているものを明示しています。

適用範囲: (1) 文書化された親変更メカニズムは存在しない — 管理UIの章では「親カテゴリの追加」(新しいトップレベルカテゴリの作成)と「サブカテゴリの追加」(新しい子カテゴリの作成)のみが説明されており、使用されたソースのどこにも、サービスカテゴリを別の親カテゴリやカタログに「移動」するアクションは記載されていない。(2) カテゴリのみのコピー機能は存在しない — 「サービスカタログのコピー」手順はカタログ範囲であり、カタログをコピーするとそのカテゴリが副次的に複製されるが、カテゴリレベルの独立したコピーアクションはない。(3) カタログとカテゴリの両方に対する管理ナビゲーションパスは同じ単一画面である: ユーザメニュー > システム設定 > 全設定 > サービスカタログ > カタログ定義 — カテゴリのみの設定ページは存在しない。

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

2.0 SCオーナーシップの範囲#

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

2.1 カテゴリヘッダ（基本属性）#

これはすべてのサービスカテゴリの背後にある単一のルートレコードです。これらのフィールドを正しく設定すれば、カテゴリが存在し、正しく親子関係が設定され（カタログに対して、またサブカテゴリの場合は親カテゴリに対しても）、ステータスも正しく設定されます。

注記（欠落であり、見落としではない）: サービスカテゴリには、サービスカタログとは異なり、独自の「サポート対象オブジェクトタイプ」フィールドはありません（サービスカタログのフィールドテンプレートには、この配列（ケース/電話/チャット/メール）が明示的に含まれています。SC-A05-01、セクション2.1を参照）。カテゴリで利用可能なチャネルは、その親カタログによって完全に範囲が定められます。カテゴリは、カタログが宣言するオブジェクトタイプを単に継承するのみであり、カテゴリレベルでの上書きは行われません。

2.2 カテゴリ名 / カテゴリ説明（翻訳サブファイル）#

ルートカテゴリヘッダレコードには、名前と説明が英語でのみ保存されます。追加言語は、同じ3フィールド構造を共有する2つの並列サブファイルを通じて追加されるか、または一度に1つのレコードに対しては、管理画面のカテゴリごとのトグルを通じて追加されます。

前提条件: この一括パターンは、サービスカタログ独自のカタログ名/カタログ説明サブファイル（SC-A05-01、セクション2.2）と同一です。同じ parent_external_key / content / languageCode 構造が両方のレベルで繰り返されます。もう1つのUIベースの代替方法も存在しますが、これは一括ファイルメカニズムではありません。カタログ定義画面で、カテゴリごとに 翻訳 トグルを有効にし、対象言語を選択して、そのカテゴリの翻訳名と説明を直接入力します。初期ロードや大規模な更新には一括サブファイルを使用し、単一カテゴリの翻訳に対する1回限りの修正には翻訳トグルを使用します。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction