トランザクションの分け方
メール-to-ケース の後続処理が失敗して、ケース自体が消えてしまった...。
そんなヒヤリとした経験はありませんか？
Salesforce では、トランザクションの分け方が 設計の成否を大きく左右します。
本記事では、トランザクションと非同期処理の設計判断について、私の経験から考えた指針をまとめました。
「その処理は、失敗してもリカバリ可能か？」
これを、トランザクションを分けるべきかどうかを検討する際の一つの目安にすると良いと思っています。
たとえば Web-to-リード や メール-to-ケース、公開サイトでの問い合わせフォームなど、顧客が入力した情報は絶対に失いたくないデータ（= リカバリ不可な処理）です。
本記事では、こういった "失敗できない処理" と同じトランザクション内に後続処理を含めるべきかどうか、その判断のための目安となる考え方を解説します。
非同期処理のすゝめ
Salesforce における非同期処理とは、メイン処理から呼び出され、メイン処理とは別トランザクションとして後から実行される処理を指します。
例：Web-to-リード + メール通知
Web-to-リード でリードが作成されたタイミングで、Apex トリガやレコードトリガフローを使って、社内の営業担当者にメールアラートを送る。
こういった処理は、Salesforceではよくある構成です。
ですが、このメール送信が、何らかの理由で失敗したらどうなるでしょう？
Salesforce では、トランザクション内で 1 つでもエラーが発生すると、全体がロールバックされます。
つまり、メール送信処理を同期的に実行していた場合、リードの作成自体がロールバックされ、顧客が入力したリード情報が失われてしまう可能性があります。
データが残らない。 これが最悪です。
こういった事態を避けるための１つの手段として、上記の例の場合では、メール送信処理を非同期実行にする、という方法があります。
また、非同期処理にはもう一つ大きな利点があります。
Salesforce の非同期処理では、同期処理よりも緩和されたガバナ制限（同時クエリ数、DML回数など）が適用されます。
そのため、処理が複雑になるケースでも、非同期に分けることでガバナ制限に引っかかりにくくなり、 安定した実行が期待できます。
非同期処理の実装方法（手段の比較）
Salesforceでは、以下のような非同期処理の手段があります
| 手段 | 特徴 | 主な用途 |
|---|---|---|
| フロー（非同期パス） | ノーコードで記述可能 | 通知・簡易な更新 |
| @future メソッド | 簡易で軽量（ただし制約多い） | 小規模な非同期処理 |
| Queueable Apex | 柔軟な設計が可能 | データ変換や外部連携など複雑な処理 |
| Batch Apex | 大量データ処理に特化 | 定期処理、大量レコードの更新や集計など |
| プラットフォームイベント | 疎結合なPub/Sub構成に適する | 他システム連携、リアルタイム連携基盤構築 |
※ ユースケースによって、どれが適しているのかは異なるため、ここでは詳細な説明は割愛します。
詳しくは、Salesforce 公式ドキュメントや Trailhead にもまとまっているので、用途に応じて選択してみてください。
"すべてを非同期にすべき" ではない
もちろん、すべての処理を非同期にすればいいという話ではありません。
たとえば「件名に“キャンセル”と書かれたメールなら、ケースのステータスを“キャンセル済”にする」といった処理であれば、ケースのトランザクション内で完結させて問題ないと考えます。
なぜなら、ケースレコードが正常に作成・更新されなければ、ステータスを変える意味もなく、外部への通知なども行われない構成であれば、ロールバックのリスクも低くなるからです。
また、単純にメール送付や外部システムへの連携のみを非同期にすれば良いという話でもなく、
複雑な変換ロジックなど、エラーになる可能性が少しでもある場合は、非同期処理への移行を検討すると良いと思います。
重要なのは、「その処理が失敗したとき、何が失われるのか？」を考えることです。
トランザクション設計の視点
「この処理、本当に “今すぐ・同期で” やる必要があるか？」
この問いから始めると、自分の目指す設計に繋がるかもしれません。
まとめ 何を守るための設計か
すべての処理を非同期にすれば正解、ということではありません。
「何を優先的に守りたいか」 を明確にし、処理の責任範囲を整理することで、
安定したトランザクション設計が可能になります。
- 顧客が入力したデータは絶対に失われないようにする
- 外部連携や通知は、失敗してもリカバリできるように切り出す
- 「この処理は本当に今やるべきか？」という問いを忘れない
これらの視点が、Salesforce における設計の安定性・拡張性に繋がると私は思っています。