JinJin48

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

July 17, 2026 · 11 min read

SAP Service Cloud メールチャネル

Email Channelは、SAP Service Cloudにおける技術的なメール受信ボックスのマスタレコードです。support@example.com のようなアドレスで、テナントが監視し、受信メッセージが自動的にケースになります。これはフェーズ2（チャネル）の最初のオブジェクトであり、それ自体には前提条件がありません。組織単位やビジネスロールがフェーズ1のエントリポイントとして単独で存在していたのと同じように、テナント内で単独で存在します。この直接の下流依存関係は、メールテンプレート（SC-A03-02）であり、メールチャネルが存在してアタッチされるまで作成できません。この記事では、メールチャネルの範囲、テナントの他のマスタデータとの関係（および関係の欠如）、管理者がメール受信ポイントを設定する際に構成するすべてのフィールドについて説明します。

パート 1: メールチャネル — 基本概念（全モジュール共通）#

1.1 メールチャネルとは#

Emailチャネルは、監視対象となる技術的なメールボックスを表すものであり、個人や組織図のノードではありません。これは、テナントに対してどのメールアドレスを監視するか、またそのアドレスへの受信メッセージをどのようにケースに変換するかを指示する設定レコードです。これは、メールの受信を名前付きチャネルとして一度定義し、その後、任意の数のメールテンプレートや、受信メールを処理するケース作成ロジックから参照できるようにするために存在します。

1.2 メールチャネル設定パターン#

Service Cloudは、Email Channelオブジェクト自体に固定の「チャネルタイプ」フィールドを提供しません。以下の実践的なパターンは、チャネルレコードが実際にどのように設定され、存在した後に使用されるかを説明しています。これを誤ると、すべての受信メールが誰も効率的に仕分けできない1つの未分化な受信箱に流れ込むか、または多くの重複するチャネルにわたって受付が断片化され、顧客がどのアドレスを使用すべきかわからなくなります。

設計原則: メールチャネルは、部門の組織図ではなく、実際の運用上のニーズ（製品ライン、言語、エスカレーションレベル）に沿って分割します。部門が「自分たち専用の受信箱」を欲しがったためだけに存在するチャネルは、通常、顧客が実際に連絡してくる方法ではなく、内部構造を反映した分割であることを意味します。

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

データ階層と具体例（ゾーンE · コミュニケーション＆ナレッジ — テナントレベル；SAP Service Cloudには、この上位に会社コード/プラントのスコーピングはありません）

Client (SAP Service Cloud Tenant)
   │
   ├── Email Channel "CH-EMAIL-01" — Technical Support Intake, Address "support@example.com"
   │
   └── Knowledge Base Provider "KB-01" — MindTouch integration (Zone E sibling; no relationship to Email Channel)

Email Channel "CH-EMAIL-01" ── referenced by ──> Email Template "TMPL-01" — Case Receipt Confirmation
   (forward reference; Phase 2 downstream dependency, SC-A03-02, not yet a real record described in this article)

設計原則: メールチャネルはチャネルフェーズのエントリポイントです。これは、組織単位とビジネスロールがフェーズ1のエントリポイントであったのと同様に、前提条件がなく、フェーズ内の他の何よりも先に作成できます。その唯一の下流依存関係であるメールテンプレートは、包含関係ではなく参照関係です。メールテンプレートは、それが属するメールチャネルを指定しますが、チャネル自体はそのテンプレートを子レコードとして一覧表示したり所有したりすることはありません。

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

Email Channel は意図的に範囲を狭く設計されています — 実際の下流コンシューマは正確に1つだけであり、ソースドキュメントで「ルーティング」という表現が使われていると過大解釈されやすいため、このチャネルが直接接続しないオブジェクトについて正確に述べておく価値があります。

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

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

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

2.1 コア識別子とステータス#

これらのフィールドは、これがどのEメールチャネルであるか、および現在インバウンドメールを受け付けるかどうかを確立します。以下のすべての設定およびルーティングフィールドは、これらが設定されて初めて意味を持ちます。

2.2 メール設定#

これがチャネルを実際に機能させるフィールドです。レコード上の他のすべては、この1つの技術アドレスを説明または管理するものです。

2.3 作業手順の関連付け#

このフィールドは、このチャネルに届いたメールからケースがどのように初期生成されるかを設定します。これは、ケースルーティングルールマスタオブジェクト（SC-A07-01）とは意図的に分離されています。ケースルーティングルールはフェーズ6の設定であり、ケースが既に存在した後にのみチームまたは従業員を対象とします。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction