ADVERTISEMENT

【Salesforce】メール-to-ケースで困った時の監査ログと履歴で追う方法

【Salesforce】メール-to-ケースで困った時の監査ログと履歴で追う方法
🛡️ 超解決

メール-to-ケースは、顧客からの問い合わせメールを自動的にSalesforceのケースとして取り込み、業務効率化に大きく貢献する機能です。しかし、メールがケース化されない、誤ったキューに割り当てられる、重複作成される、添付ファイルが欠落するなどのトラブルが発生することがあります。こうした問題の原因を突き止めるには、設定の確認だけでなく、監査ログ(Setup Audit Trail)やメールログ(Email Log)、ケースのActivity Timelineを活用した調査が欠かせません。本記事では、これらのログ・履歴を体系的に使い、問題の発生箇所を切り分け、次の行動を明確にする方法を詳しく解説します。

【要点】この記事で確認すること

  • 最初に見る場所: Salesforceの設定画面(メール-to-ケース設定)、Email Logファイル(メールログ)、監査ログ(Setup Audit Trail)、対象ケースのActivity Timeline。
  • 切り分けの軸: メールがSalesforceに届いていない(メールサーバー・配送経路の問題)、届いているがケース化されない(ルーティングルール・トリガーの問題)、ケースは作成されるが期待通り動作しない(キュー割り当て・自動化ルールの問題)。
  • 注意点: メール-to-ケースの設定変更にはシステム管理者権限が必要であり、誤った変更は他のケース作成に影響を及ぼす可能性があります。必ずSandbox環境でテストしてから本番に適用してください。

ADVERTISEMENT

メール-to-ケースの基本構造と確認すべき3種類のログ

メールログ(Email Log)

Email Logは、Salesforceが受信したメールの処理結果を記録したファイルです。メール-to-ケースが有効な組織では、受信メールごとに「成功」「失敗」「スキップ」などのステータスが記録されます。このログは、メールがSalesforceに届いているかどうか、またどのような理由で処理されなかったかを確認する第一歩です。Email Logは設定画面からCSVファイルとしてダウンロードでき、管理者のみアクセス可能です。

監査ログ(Setup Audit Trail)

監査ログは、Salesforce組織内の設定変更履歴を時系列で記録したものです。メール-to-ケースのルーティングアドレス追加・変更、キュー割り当てルールの編集、Apexトリガーの更新など、誰がいつ何を変更したかを追跡できます。問題発生時期と設定変更のタイミングが一致するかを調べるのに有用です。

ケースのActivity Timeline

ケースレコードのActivity Timeline(活動履歴)には、メール-to-ケースによって作成されたケースの場合、メールの元メッセージ(EmailMessageレコード)や関連するイベントが表示されます。タイムラインを確認することで、メールがどのようなタイミングで取り込まれ、どのような自動処理(メール返信、ワークフロー、プロセス)が実行されたかを把握できます。

メールログ(Email Log)を使った調査手順

メール-to-ケースの問題で最初に行うべきは、メールログのダウンロードと分析です。以下の手順で実施してください。

  1. Salesforceにシステム管理者としてログインし、右上の歯車アイコンから「設定(Setup)」を開きます。
  2. 左側のメニューから「メール」→「メールログのダウンロード」を選択します。ページ上部に表示される「ファイルを生成」ボタンをクリックすると、Email Logファイル(CSV形式)が生成されます。生成には数分かかる場合があります。
  3. 生成されたファイルをダウンロードし、Excelやテキストエディタで開きます。CSVファイルには「CreatedDate」「FromAddress」「ToAddress」「Subject」「Status」「ErrorCode」「ErrorMessage」などの列があります。
  4. 問題のメールを特定するため、送信元アドレス、宛先アドレス、日時などでフィルタリングします。Status列で「Success」以外のレコードを探します。
  5. 失敗レコードがある場合、ErrorCodeとErrorMessageを確認します。よくあるエラーコード「INVALID_ROUTING_ADDRESS」「UNAUTHORIZED_SENDER」「MALFORMED_EMAIL」などから原因を推測できます。
  6. メールログにレコードが存在しない場合は、メールがSalesforceに到達していない可能性が高いです。メールサーバーのログやSPF/DKIM設定、ネットワーク経路を調査する必要があります。

監査ログ(Setup Audit Trail)で設定変更を特定する

監査ログの確認手順

  1. 設定画面で「監査ログ(Audit Trail)」を検索して開きます。監査ログは過去180日間の変更が記録されています。
  2. 表示された一覧で、問題発生時期の前後に「メール-to-ケース」関連の変更がないかを探します。「変更項目」列に「ルーティングアドレス」「メールサービス」「ケースへの自動返信」などのキーワードが含まれていないか確認します。
  3. 変更があった場合、誰が変更したか(変更者)、どのような変更内容かをクリックして詳細を確認します。変更内容の差分がポップアップで表示されます。
  4. もし監査ログに記録されない設定変更がある場合(例:API経由の変更)、別途APIイベントログやログファイル(Login Historyなど)を確認する必要があります。

ケースのActivity TimelineとEmailMessageレコードの確認

タイムラインでメール関連付けを確認する

  1. 問題のメールから作成されたと思われるケース(または作成されるべきだったケース)を開きます。
  2. ケースのページでActivity Timeline(活動履歴)セクションを表示します。デフォルトで表示されていない場合は、ページレイアウトの編集が必要な場合があります。
  3. タイムラインに「メール」タイプの活動が表示されていれば、そのメールがケースに関連付けられています。活動をクリックするとメールの内容(件名、本文、添付ファイル)を確認できます。
  4. メール活動が表示されない場合、メール-to-ケースがケースを作成した後に、メールメッセージレコードが作成されなかった可能性があります。この場合、ルーティングルールやトリガーに問題があるかもしれません。
  5. また、タイムラインに「ケース作成」などのイベントが記録される設定になっている場合は、自動化ルール(ワークフロー、プロセス、フロー)の実行状況も確認できます。

EmailMessageオブジェクトを直接参照する

Activity Timelineに加えて、EmailMessageオブジェクトを直接SOQLで検索する方法もあります。Salesforceの開発者コンソールやデータエクスポートツールを使い、関連するケースIDでEmailMessageを検索します。問題のメールがケースに関連付けられているか、またはParentIdが空のまま孤立していないかを確認できます。

失敗パターン別人気の調査ルート比較表

現象 最初に見るログ 主な原因 次のアクション
メールログにレコードがない メールサーバー側ログ、SPF/DKIM設定 メールがSalesforceに届いていない(DNS、フィルタ、サーバー障害) メール配信経路を確認、SPFレコードにSalesforceのIPを含める
メールログにFailureステータス Email Log(ErrorCode) ルーティングアドレス未登録、送信者未承認、サイズ超過など ErrorCodeに応じて設定を修正(アドレス追加、許可リスト追加など)
メールログはSuccessだがケース未作成 監査ログ、自動化ルールのアクティビティ ルーティングルールの条件不一致、トリガー・ワークフローによる削除 ルーティングルールの条件を確認、Apexトリガーのログを追加
ケース作成済みだがキューが異なる ケースのOwnerフィールド、Activity Timeline ルーティングルールのキュー割り当てミス、ワークフローの上書き ルーティングルールの優先順位を確認、ワークフローの順序を見直す
メールに返信しても同じケースに追加されない Email Log、ケースのEmailMessage スレッドID(Thread ID)の不一致、返信用アドレスの設定ミス メールのIn-Reply-ToヘッダーやThread-Indexを確認、設定の再確認

管理者へ伝えるべき情報まとめ

問題をSalesforce管理者やベンダーにエスカレーションする場合、以下の情報を整理して伝えると解決がスムーズです。

  • 問題のメールの送信元アドレス、送信日時、件名、本文(個人情報はマスク)。
  • 該当するメールログのレコード(CSVの該当行)とスクリーンショット。
  • 問題が発生した前後24時間の監査ログの抜粋(メール-to-ケース関連の変更)。
  • 該当ケースが存在する場合はそのケースID、存在しない場合はその旨。
  • メール-to-ケースのルーティングアドレスとキュー設定のスクリーンショット。
  • すでに試した調査手順とその結果(例:「メールログを確認したがレコードなし」「ルーティングアドレスは正しい」など)。
  • テナントID(組織ID)と問題発生時刻のタイムゾーン。

よくある質問(FAQ)

メール-to-ケースで作成されたケースがすぐにクローズされてしまうのはなぜですか?

自動返信設定が有効で、返信メールの内容によってケースがクローズされる場合があります。また、ワークフロールールやプロセスビルダーが自動的にクローズしている可能性もあります。Activity Timelineでクローズの原因となったイベントを確認し、関連する自動化ルールを見直してください。

特定のドメインからのメールだけが処理されないのはなぜですか?

送信者許可リスト(Accepted Email Addresses)が設定されている場合、そのドメインが許可されていない可能性があります。また、メールサーバー側でSalesforceへの送信がブロックされていないか確認します。メールログで「UNAUTHORIZED_SENDER」エラーが出ていないか確認しましょう。

メールに返信しても同じケースに追加されない場合はどうすればよいですか?

通常、メール-to-ケースはメールヘッダーのIn-Reply-ToやReferencesを使用してスレッドを識別します。返信時のメールクライアントが正しいヘッダーを維持していない可能性があります。また、ケースに紐づくEmailMessageのThreadIdが正しく設定されているか確認します。設定画面で「返信時にケースを更新」オプションが有効になっていることも確認してください。

まとめ

メール-to-ケースのトラブルシューティングでは、メールログ、監査ログ、Activity Timelineという3つの情報源を段階的に活用することで、原因を効率的に特定できます。まずメールログでメールの到達状況とエラーを確認し、次に監査ログで設定変更の有無を調べ、最後にタイムラインでケースとメールの関連付けを検証してください。これらのログを使いこなすことで、管理者やサポートチームと的確に連携でき、問題解決までの時間を大幅に短縮できます。日頃からログの定期確認と設定変更の記録を習慣づけることが、安定運用の鍵です。


ADVERTISEMENT

この記事の監修者
✍️

超解決 第一編集部

疑問解決ポータル「超解決」の編集チーム。正確な検証と、現場視点での伝わりやすい解説を心がけています。

ADVERTISEMENT