Service Cloud のメール-to-ケース|用語と初期設定の流れ
目次 クリックで開く
カスタマーサポートの現場において、日々届く大量の問い合わせメールを、個人のメーラーや共有アカウントだけで管理することには限界があります。対応漏れや二重対応、過去の経緯が不透明になるといった課題を解決する強力なソリューションが、Salesforce Service Cloudの「メール-to-ケース(Email-to-Case)」です。
本記事では、Service Cloudの実務担当者が直面する「メール-to-ケース」の仕組み、2つの方式の選定基準、そして具体的な初期設定の手順を、公式ドキュメントの仕様に基づき徹底的に解説します。
Service Cloud メール-to-ケースの基本概要と仕組み
メール-to-ケースとは?カスタマーサポートを自動化する中核機能
メール-to-ケースは、指定したメールアドレス(例:support@company.com)に届いたメールを、Salesforce上の「ケース」レコードとして自動生成する機能です。これにより、メール本文がケースの説明に、件名がケースの件名に、そして送信者が取引先責任者に自動的にマッピングされます。
この機能の真価は、単なるデータ化だけではありません。Salesforceの標準機能である「オムニチャネル」や「割り当てルール」と組み合わせることで、適切なエージェントへの自動配分や、SLA(サービス品質保証)に基づいた期限管理が可能になります。もし、既存のシステムがExcelや紙での管理に依存している場合は、Excelと紙の限界を突破する業務DXの考え方と同様、データの一元管理へ踏み出す第一歩となります。
メールが「ケース」に変換されるまでのロジック
メール-to-ケースが作動すると、Salesforceは以下の順序で処理を行います。
- メールの受信:Salesforceが生成した特殊な「サービスアドレス」にメールが到達。
- 送信者の特定:送信元メールアドレスと一致する「取引先責任者」を検索。
- ケースの作成:マッチする連絡先があれば紐付け、なければ新規ケースのみ作成(設定により挙動は変更可能)。
- 自動割り当て:定義された「ケース割り当てルール」に基づき、所有者を決定。
取引先責任者との自動紐付け(マッチング)の仕様
標準仕様では、メールの「From」アドレスが、Salesforce内の「取引先責任者」のメール項目と一致するかを照合します。一致した場合、その取引先責任者および関連する「取引先」がケースに自動でセットされます。もし複数の取引先責任者が同じメールアドレスを持っている場合は、マッチングが正しく行われない可能性があるため、データクレンジングが重要です。
2つの方式「オンデマンド」と「エージェント」の比較
Salesforceには、メールを取り込む方法として「オンデマンドメール-to-ケース」と「メール-to-ケースエージェント」の2種類が存在します。現在、ほとんどの企業にとって推奨されるのは「オンデマンド型」です。
オンデマンドメール-to-ケース(推奨)
Salesforceのインフラ内で直接メールを処理する方式です。自社でメールサーバーを管理したり、ファイアウォールの背後にソフトウェアをインストールしたりする必要がありません。設定が容易で、メンテナンスコストが低いのが特徴です。
メール-to-ケースエージェント
自社のネットワーク内に専用のJavaアプリケーション(エージェント)をインストールする方式です。メールのペイロードが非常に大きい場合や、セキュリティポリシーによりメールを一度自社サーバー内に留めておく必要がある場合に使用されます。しかし、サーバーの運用保守が必要になるため、特別な理由がない限り選択されません。
【比較表】オンデマンド vs エージェントの機能・仕様差
| 比較項目 | オンデマンド方式(推奨) | エージェント方式 |
|---|---|---|
| 設置場所 | Salesforce クラウド内 | 自社サーバー(ファイアウォール内) |
| 最大添付ファイルサイズ | 25 MB | 最大 25 MB(※設定により拡張可だが非推奨) |
| 1日の処理上限 | ユーザライセンス数 × 1,000 件(最大 100万件) | 制限なし(ハードウェア依存) |
| ネットワーク設定 | 不要(メール転送のみ) | ファイアウォール・プロキシ設定が必要 |
| 公式リファレンス | 公式ヘルプ | 公式ヘルプ |
メール-to-ケース導入前の準備チェックリスト
設定を開始する前に、以下の項目が整っているか確認してください。ここを怠ると、本番環境でのトラブルに直結します。
- 権限の確認:「アプリケーションのカスタマイズ」権限を持つシステム管理者ユーザーであること。
- ルーティング用アドレスの確保:顧客がメールを送信する先のアドレス(例:info@domain.jp)が、既にメールサーバー側で作成されていること。
- メール転送(フォワーディング)の許可:自社のメールサーバー(Microsoft 365, Google Workspace等)から、外部のSalesforceドメインへメールを転送することがセキュリティポリシー上許可されていること。
また、カスタマーサポート部門だけでなく、経理やバックオフィス業務とも連携させる場合は、バックオフィスSaaSの責務分解の考え方を応用し、どの情報をSalesforceに集約し、どの情報を会計・精算ツールに流すべきかを整理しておくのが実務的です。
【実務ガイド】メール-to-ケースの初期設定ステップ
ここでは、最も一般的な「オンデマンド方式」での設定手順を解説します。
ステップ1:メール-to-ケースの有効化
- Salesforceの[設定]から、クイック検索で「メール-to-ケース」を選択します。
- [編集]をクリックし、[メール-to-ケースの有効化]と[オンデマンドサービスの有効化]にチェックを入れます。
- [保存]をクリックします。
ステップ2:ルーティングアドレスの作成と検証
- [ルーティングアドレス]セクションの[新規]をクリックします。
- ルーティング名(例:テクニカルサポート)と、メールアドレス(例:support@example.com)を入力します。
- [保存]を押すと、入力したアドレス宛に確認メールが届きます。メール内のリンクをクリックして「検証」を完了させてください。
- 検証完了後、Salesforce側で「メールサービスアドレス」が生成されます。これは「support@randomstring.ext.salesforce.com」のような長いアドレスです。これをコピーしておきます。
ステップ3:メールサーバー側での転送設定
自社のメールサーバー(Google Workspace や Outlook 等)の設定画面を開き、ステップ2で取得した「メールサービスアドレス」への転送設定を行います。
注意: 転送設定時に「自動返信」などのループが発生しないよう、メールサーバー側のフィルタリング設定に注意してください。
ステップ4:SPF/DKIM設定(送信ドメイン認証)による到達率向上
Salesforceから顧客へメールを返信する場合、自社のドメインを騙って送信することになります。このままでは受信側サーバーから「なりすましメール」と判定されるリスクがあります。
これを防ぐため、自社DNSにSalesforceのSPFレコードを追加し、DKIM(DomainKeys Identified Mail)鍵を作成・公開してください。これは、SaaSコスト削減とID管理でも重要となるセキュリティ基盤の一部です。
運用を安定させるための応用設定と注意点
スレッド識別(Email-to-Case Threading)の最新仕様
以前のSalesforceでは「Ref ID」と呼ばれる文字列を件名や本文に含める必要がありましたが、現在は「ヘッダーベースのスレッド識別」が推奨されています。これは、メールヘッダー内の「Message-ID」「In-Reply-To」「References」を利用して、既存のケースとの紐付けを行う仕組みです。これにより、件名が書き換えられても正しく同じスレッドに集約されます。
自動レスポンスルール(受付完了メール)の構築
顧客がメールを送った直後に「お問い合わせを承りました(ケース番号:XXXX)」というメールを自動で返す設定です。[設定] > [ケース自動レスポンスルール] から、ルーティングアドレスごとに送信するテンプレートを選択できます。ここで、顧客への安心感を提供することがCX向上の鍵となります。
スパムメール・ループメール対策のベストプラクティス
自動応答同士が反応し合う「ループメール」を防ぐため、Salesforceには標準で特定の送信者やキーワードをフィルタリングする機能があります。また、Salesforceの「組織全体のメールアドレス」設定で、特定のドメインからの受信を拒否する設定も併用してください。
よくあるエラーとトラブルシューティング
ケースが作成されない場合の原因切り分け
- メールサイズオーバー:25MBを超えていないか。
- 自動応答ループのブロック:Salesforce側が「自動返信」と検知して破棄していないか。
- ルーティングアドレスの検証未完了:Salesforce内での検証プロセスが完了しているか。
Salesforceからの返信が届かない(迷惑メール判定)の対策
前述のSPF/DKIM設定が正しく行われているかを確認してください。また、SalesforceのIPアドレス範囲が受信側のファイアウォールやスパムフィルタで許可されているか(IPホワイトリスト)も、大手企業のインフラ担当者と連携すべきポイントです。
社内のシステムが多岐にわたり、アカウント管理が煩雑になっている場合は、退職者のアカウント削除漏れを防ぐ自動化アーキテクチャを参考に、アイデンティティ管理の整備も並行して検討することをお勧めします。
まとめ:Service Cloudによる顧客体験(CX)の最大化に向けて
メール-to-ケースは、Service Cloud導入における「クイックウィン(早期の成功)」を実現しやすい機能です。しかし、単に設定するだけでなく、その背後にあるスレッド紐付けのロジックや、セキュリティ設定を正しく理解しておくことが、安定した運用の土台となります。
設定が完了したら、必ず実際のメールアドレスからテスト送信を行い、ケースの作成、取引先責任者との紐付け、自動返信の挙動、そしてSalesforceからの返信が顧客側のメーラーでどう見えるかを、実務者の視点で徹底的に検証してください。
※仕様および制限事項は、Salesforceのリリースサイクルに基づき変更される可能性があります。導入の際は必ず最新の公式ヘルプドキュメントをご参照ください。
実務担当者が陥りやすい「見落としがちな制約」と解決策
設定完了後に「なぜかうまく動かない」「運用が回らない」という事態を防ぐため、以下の3つのポイントを再確認してください。
1. 「メールサービスアドレス」の外部露出厳禁
ステップ2で発行された「support@…salesforce.com」という長いアドレスは、Salesforceがメールを直接受け取るための窓口です。このアドレスが外部に漏れると、認証なしでケースが作成されてしまうリスクがあります。顧客には必ず自社ドメインのアドレス(support@company.com等)を公開し、内部的な転送設定のみに使用してください。
2. 取引先責任者が重複している場合の挙動
「From」アドレスが複数の取引先責任者に登録されている場合、Salesforceはどのレコードに紐付けるべきか判断できず、取引先責任者欄が空欄のままケースが作成されることがあります。これを防ぐには、事前にデータの名寄せを行うか、フロー(Flow Builder)を用いて独自の紐付けロジックを実装する必要があります。全体的なデータ連携の考え方については、SFA・CRM・MA・Webの違いを解説したデータ連携の全体設計図が参考になります。
3. 一般的なメール制限事項(2026年時点の要確認事項)
| 項目 | 詳細・注意点 |
|---|---|
| 添付ファイルの数 | 1メールあたりの合計サイズが25MB以内であれば複数可。 |
| リッチテキスト形式 | HTMLメールはサポートされますが、インライン画像は設定により「添付ファイル」として扱われる場合があります。 |
| スパム判定 | Salesforce側でスパムと判定されたメールは「メール本文」に特定のフラグが立つか、破棄される設定が可能です(要確認)。 |
公式ドキュメント・関連リソース
- メール-to-ケースの制限事項(公式ヘルプ)
- 新しいスレッド ID 形式への移行に関する FAQ
- SaaSアカウント管理の自動化アーキテクチャ(管理ユーザーの増減に伴う権限チェックに有効)
ご相談・お問い合わせ
本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。