ガイドの概要

非同期処理では、コンテキストあたりの制限を引き上げることができるため、スケーラビリティが向上します。非同期要求はバックグラウンドで独自のスレッドで実行されるため、ユーザーは非同期 ToDo をバックグラウンドで実行しながらクライアント側で作業を続行できます。

Salesforce Lightning Platform には、特定の使用事例を解決するために使用できるさまざまな非同期テクノロジーが用意されています。各テクノロジーには、使用事例ごとにアプローチを選択するときに考慮する必要がある利点と制限があります。

実装するテクノロジーを選択するときには、次の 3 つの重要な考慮事項に留意してください。

1. 非同期処理は、すべての問題に最適なアプローチではありません。ユーザー操作を直接必要としないプロセスは、非同期処理の優れた候補と考えがちですが、いくつかの欠点があります。まず、非同期プロセスには SLA がありません。つまり、設定された時間内に非同期プロセスを完了できる保証はありません。次に、一貫した応答遅延の保証はありません。非同期プロセスが一定時間内に完了すると、後続のプロセスが完了するまでに異なる時間がかかる可能性があります。そのため、ユーザーが応答を直接待機していなくても、応答に依存する後続のプロセスがある場合や、応答時間が長すぎるとデータが外部システムのデータと同期しなくなる可能性がある場合、非同期処理はシナリオに適さない可能性があります。
2. Salesforce Platform では非同期要求を処理する方法が異なるため、最適な方法を選択してください。Salesforce Platform で非同期処理をサポートする技術は「内部では」動作が異なりますが、非常に具体的な使用事例に合わせて設計されたものもあります。
3. 技術がクライアント側で非同期の場合、すべてのエンドツーエンドの処理が並列で実行されるとは限りません。選択した内容によっては、クライアントのメッセージがサーバー側でシリアライズされることもあります。

ジョブで誤ったテクノロジーや誤ったテクノロジーの組み合わせを使用すると、非同期処理の利点が取り消される意図しない結果が生じる可能性があります。このガイドでは、さまざまな非同期使用事例の説明と推奨事項、潜在的な欠点とアンチパターン、および推奨事項の根拠について説明します。また、Salesforce Platform でさまざまな非同期実装技術がどのように動作し、規制されているかに関するインサイトも提供されます。

使用するテクノロジーについて意思決定を行う場合は、一般的な使用事例を最適なテクノロジーにすばやくマッピングできる、焦点を絞った非同期処理決定ガイドが用意されています。

このドキュメントでは、MuleSoft、Informatica、Commerce Cloud、Tableau、Marketing Cloud など、他のエコシステムのテクノロジーは扱っていません。

このガイドは、Salesforce Lightning Platform 内の非同期処理のみを対象としています。非同期インテグレーションパターンに関する情報を探している場合は、「イベント駆動型アーキテクチャ」を参照してください。

• **非同期処理を使用する前に、使用事例がパターンに適合していることを確認してください。**非同期パターンには SLA がなく、複数のガバナメカニズムが適用され、ライセンスに基づいて業務量制限が定義されている可能性があります。また、Salesforce Platform 内の非同期インフラストラクチャに割り当てられるリソースの有限性が原因で処理遅延が発生する可能性があります。ユーザーが作業を続行する前にシステムからの応答を必要とするシナリオで非同期処理を使用する場合は、次の制限事項を真剣に考慮してください。
• **Salesforceによる非同期処理は、無限の拡張性ニーズに対応するソリューションではありません。**Salesforce Platform は無限に拡張されず、非同期パターンにも制限が適用されます。非同期処理では、CPU が命令ストリームを実行するために必要なコンテキスト情報が含まれるスレッドが使用されます。スレッドは並列で実行できます。どの CPU でも使用可能なスレッド数は限られているため、プラットフォームには、使用可能なスレッドをできるだけ効率的に使用するためのメカニズムがあります。プラットフォームのフロー制御メカニズムにより、組織が大量のスレッドを消費して他の組織に悪影響が及ぶことを防ぎます。プラットフォームの適正使用アルゴリズムは、特定のメッセージ種別ごとに組織で使用できるスレッドの数を制御します。
• **トランザクションが真に非同期である場合を把握します。**一部のアーキテクチャパターンは、エンドツーエンドで非同期に動作します。ただし、他のプロセスはクライアント側またはブラウザー側で非同期に動作しますが、サーバー側の要求を逐次化し、同期ガバナ制限が適用されます。
• **Salesforce Platform から大規模な送信インテグレーションを構築するには、非同期 Apex を介したコールアウトではなく、プラットフォームイベントと堅牢なミドルウェアを使用します。**プラットフォームで使用できる非同期スレッドの数には限りがあるため、非同期 Apex を介した送信インテグレーションの拡張性は制限されます。組織に大量のメッセージが含まれる送信インテグレーションがあり、使用可能なスレッド数を超え、処理時間が長い場合、非同期 Apex を使用するとどうしても遅延が発生します。
• **非同期処理を使用する場合は、必ず監視を組み込みます。**モニタリングを使用すると、問題をできるだけ早く検出し、重大なパフォーマンスインシデントが発生する前に修正できます。
• **極端な負荷を引き起こす可能性のあるイベントを考慮します。**非同期プロセスを設計する際には、ワークロードの急増と低下を確実に管理できるようにしてください。実装で停電などの予期しないイベントをどのように処理するかを検討し、データの損失や機能の損失を軽減する保護策を設計します。

サーバー側非同期処理のアプローチを選択する場合、まず組織の要件と使用可能なリソースを評価します。目標は、拡張性を確保し、制限違反の可能性を最小限に抑えながら、実装コストとメンテナンスコストを最小限に抑える方法を選択することです。この目標は、次のセクションで説明する技術的な考慮事項と、チームの構成によって異なります。たとえば、チームにProコードソリューションを保守できるApex開発者がいるかどうかを検討してください。それ以外の場合、宣言型のアプローチの方が理にかなっています。また、ツールごとに異なる制限が適用される可能性があることにも注意してください。

Salesforce での非同期注文プロセスの使用事例を考えてみましょう。注文が保存されると、品目の梱包および配送方法に関する特別な指示を含むメッセージが外部倉庫管理システムにトリガーされます。注文を行ったユーザーは、倉庫管理システムからすぐに応答する必要がないため、要求を非同期で送信できます。非同期処理により、ユーザーは遅延なく作業を続行できます。

アーキテクチャに関する考慮事項:

• 必要な同時プロセス数は?
• 同時に実行される複数のプロセス同士がどのように連携するかを検討してください。
• 各プロセス内で実行される SOQL クエリの数は?
• 各プロセス内で実行される DML 操作の数は?
• 各プロセスの実行時間は?
• 各プロセスは、特定のタイミングにどの程度敏感かを検討してください。

Salesforce Platformのマルチテナント アーキテクチャは、多くのテナント(組織)のさまざまな要件を分離し、同時にサポートします。このガイドで説明するすべての非同期Apexメソッドは、Salesforce Platformの同じ非同期インフラストラクチャ内で実行されます。これらは、2 つの主要な制御メカニズム（フロー制御と適正使用）によって管理されるメッセージキューフレームワークを使用します。

フロー制御と公正な使用メカニズムにより、1 つのテナントが使用するサーバーリソースが多すぎて、残りのテナントに十分なリソースが残らないようにします。これらのメカニズムのしくみを理解することは役立ちますが、次のセクションで説明するような非同期処理のベストプラクティスに従うことで、問題が発生する可能性を大幅に減らすことができるという点が重要になります。

プラットフォームのフロー制御メカニズムにより、特定のメッセージ種別が 1 つの組織でフラッディングされるのを防ぎます。これにより、消費するスレッド数が多すぎて他の組織に悪影響が及びます。フレームワークは、メッセージ種別に関連付けられたキューに新しいエントリを追加する前に、キューの最初の数千の既存のエントリを確認します。既存のエントリの大多数が同じ組織に関連付けられていて、その組織にすでにワーカースレッドのエントリがある場合、新しく追加されたエントリはキューの最後尾に移動されます。このプロセスは、再キュー化と呼ばれます。通常、再キュー化は一括処理 Apex および一括 API プロセスで発生します。これは、多くの場合、大量のエントリが同時にキューに挿入されるためです。

プラットフォームの公正な使用メカニズムでは、階層ベースのシステムが実装されています。このシステムにより、Salesforce Platform の各組織は、Future、Queueable、Batch などのメッセージタイプの処理時間を公平に配分できます。特定のメッセージタイプで他の組織が作業の実行を待機している間に、ある組織がそのメッセージタイプを独占している場合、使用量の適正化アルゴリズムによって、その特定のメッセージタイプで使用可能なスレッド数が減少します。

非同期 Apex メソッドを使用する利点は、SOQL クエリ制限やヒープサイズ制限などの一部のガバナ制限が高くなることです。ただし、これらのメソッドに過度に依存しないでください。非同期インフラストラクチャに割り当てられるリソースには限りがあるため、Future、Queueable、および Batch Apex を頻繁に使用すると、公正な使用とフロー制御に基づく制限が原因で処理の遅延が発生する可能性があります。

非同期 Apex を使用するアウトバウンドコールアウトは、非同期 Apex 制限に含まれます。現在の 1 日あたりの制限は、適用可能なユーザーライセンス数の 25 万倍または 200 倍のいずれか大きい方です。この制限は、大規模な使用事例で問題になる可能性があります。この制限を超えると、非同期 Apex ジョブおよび関連付けられたアウトバウンドコールアウトは失敗します。

また、プラットフォームで使用できる非同期スレッドの数には限りがあるため、非同期 Apex を介した送信インテグレーションの拡張性も制限されます。使用可能なスレッド数を超える大量の送信インテグレーションでは、処理時間が長くなり、遅延が発生する可能性があります。

大規模な使用事例では、次の代替方法を検討してください。これらのアプローチでの API コールは、1 日の API 要求制限に含まれます。これは、1 日の非同期 Apex 制限よりも大幅に高くなります。したがって、これらのアプローチは拡張性が高くなります。ただし、どの CPU でも処理できる同時要求数には物理的な制限があります。

• **Middleware Scheduled Pull.**大量の送信インテグレーション ジョブに関連する遅延を回避するには、ミドルウェアを使用して、非同期 Apex を介してデータをプッシュするのではなく、スケジュールに従ってデータをプルします。MuleSoft Anypoint Platform などのミドルウェアでは、ネイティブの SOAP API または REST API を同期して使用できるため、遅延が発生することはほとんどありません。ミドルウェアでは、大量のデータに対してネイティブの Bulk API を使用することもできます。

• **プラットフォームイベント通知を介したミドルウェアによるプル。**Future、Queueable、または Batch 非同期 Apex をキューに追加して送信インテグレーションを実行する代わりに、プラットフォーム イベントを使用できます。プラットフォームイベントは、アウトバウンド情報自体を配信することも、ネイティブ API を介して必要な情報を取得して最終的な目的地に配信するようにミドルウェアツールに指示することもできます。どちらのアプローチも、非同期 Apex で適用される遅延の影響を受けません。ただし、プラットフォームイベント制限は引き続き適用されます。

Queueable Apex を使用すると、広範なデータベース操作や外部 Web サービスのコールアウトを含む Apex プロセスを非同期で実行できます。Queueable Apex を使用するには、Queueable インターフェイスを実装してから、Apex ジョブ キューにジョブを追加します。この方法では、非同期 Apex ジョブが独自の分離されたスレッドでバックグラウンドで実行され、メイン Apex ロジックの実行が遅延することはありません。キューにある各ジョブは、システムリソースが使用可能になったときに実行されます。

Queueable Apex は、非同期 Apex の進化を表します。Apex future メソッドでは使用できない次のような機能があります。

• ジョブ ID: System.enqueueJob メソッドを呼び出してジョブを送信すると、メソッドは新しいジョブの ID を返します。この ID を使用してジョブを識別できます。進行状況を監視するには、Salesforce の [設定] で [Apex ジョブ] ページを表示するか、AsyncApexJob オブジェクトを照会します。
• 非プリミティブ タイプのサポート: キュー可能クラスには、sObject やカスタム Apex タイプなどの非プリミティブ データ型のメンバー変数を含めることができます。
• ジョブチェーンのサポート: 実行中のジョブから 2 番目のジョブを開始して、キュー可能ジョブをチェーニングできます。この手法は、プロセスの連動関係が含まれるシナリオに対処するのに役立ちます。
• 最大深度制御: キュー可能ジョブに最大スタック深度を設定して、ジョブのチェーンが予期しない再帰にならないようにできます。
• 重複除外シグニチャ: キュー可能ジョブには、重複ジョブを検出して削除するためのオプションのシグニチャがあります。
• 設定可能な遅延: Queueable ジョブが実行されるまでの遅延を最大10分まで定義できます。
• トランザクションファイナライザー: キュー可能ジョブにアクション後シーケンスを添付し、その結果に基づいて関連するアクションを実行できます。たとえば、トランザクション ファイナライザーは、未対応の例外が原因で失敗したキュー可能ジョブを最大 5 回再キューイングできます。

Salesforce では、キューベースのフレームワークを使用して非同期プロセスを処理します。このキューは、組織間で要求ワークロードのバランスを取るために使用されます。組織でこのキューをできるだけ効率的に使用する手順は、次のとおりです。

• future メソッドや Queueable メソッドを大量のエンドユーザー活動やインテグレーション API コールによって生成されたアクションから直接キューに入れないようにします。この方法では、1日あたりの非同期Apexの制限がすぐに使い果たされ、ビジネスに重大な影響を及ぼす可能性があります。
• 同期アクションごとに複数の非同期アクションをキューに追加しないでください。1つの同期アクションから複数の非同期アクティビティがキューに追加されると、非同期アクティビティが同時に実行されることが多く、行ロック競合や行ロックタイムアウトエラーの原因になります。
• future メソッドや Queueable メソッドを非同期キューに大量に追加しないでください。
• future メソッドと Queueable メソッドができるだけ迅速に実行されるようにします。future メソッドの実行時間が長いほど、キューの背後にある要求が遅延する可能性が高くなります。一括処理ジョブを迅速に実行するには、Webサービスのコールアウト時間を最小限に抑え、将来のメソッドで使用するクエリを調整し、プロセス・ビルダーのプロセス、ワークフロー・ルール、フロー、Apexトリガーなどの他のオブジェクトの自動化を最適化します。
• 非同期メソッドを大規模にテストします。処理するメソッドの最大数を生成する環境を使用します。このテストは、本番環境でパフォーマンスや制限の問題が発生するかどうかを判断するのに役立ちます。また、1 日の累積制限への影響も考慮します。
• future メソッドや Queueable メソッドの代わりに Batch Apex を使用して、大量のレコードを処理します。一括処理 Apex は、数千件のレコードに対して実行される複雑で実行時間の長いプロセスを処理でき、より多くのリソースが使用可能な営業時間外に実行するようにスケジュールできます。

スケジュール済み Apex を使用して、cron 式で定義された指定された時刻と繰り返しの頻度で実行します。cron 式を使用して Apex をスケジュールする動作は非同期プロセスですが、基盤となるコードはジョブの開始時に同期して実行されます。スケジュール済み Apex は、毎日または毎週のメンテナンス作業に最適です。

• スケジュール済み Apex ジョブは、一度に 100 個のみ設定できます。この制限を回避するには、スケジュール済み Apex を使用する代わりに、Apex コードを呼び出すスケジュールトリガーフローを使用することを検討してください。
• トリガーからApexクラスをスケジュールする場合は、細心の注意を払ってください。トリガーで制限を超えるスケジュール済みクラスが追加されないことを保証できる必要があります。特に、API 一括更新、インポートウィザード、ユーザーインターフェースを使用したレコードの一括変更、および一度に複数のレコードを更新できるすべてのケースを検討してください。
• 今後10分以内にスケジュールする必要がある一回限りのタスクの場合は、遅延キュー可能ジョブを使用します。この方法では、100 件のスケジュール済みジョブの制限に含まれません。
• スケジュール済み Apex は、同期制限のある同期コンテキストで実行されます。
• スケジュール済みジョブが実行される期間を検討します。実行時間の長いジョブは、次のスケジュール済みジョブの開始と重複する可能性があります。
• Salesforce は、指定された時間に実行されるようにクラスをスケジュール設定します。実際の実行は、サービスの使用可能状態に応じて遅れる場合があります。サービスメンテナンスのダウンタイム中にスケジュールされたジョブは、サービスが復旧した後に実行するようにスケジュールされます。
• 一括処理ジョブをキューに入れることのみを目的としてジョブをスケジュールするのではなく、一括処理ジョブをスケジュールする場合は System.scheduleBatch を使用します。

これまで、VisualforceコントローラやLightningコンポーネントコントローラなど、同期Apexトランザクションコンテキストで実行されているApexメソッドから実行される同期コールアウトには、実行時間が長い要求に関するApex同時実行制限が適用されていました。Winter ‘19 以降、同期コールアウトは長時間実行扱いにならなくなりました。Apex 継続は、最初は要求の実行時間が長くなる同期コールアウトのソリューションとして作成されましたが、さらにいくつかの利点もあります。

• 1 つの同期アクションで最大 3 つの継続アクションを実行できます。新しい継続アクションを実行する前に、以前の継続を完了する必要があります。
• 各継続アクションでは、最大 3 つのコールアウトを実行できます。コールアウトは並列で実行されます。
• 継続アクションによって実行されるすべてのコールアウトが完了すると、プラットフォームは結果を処理するために継続コールバックメソッドを呼び出します。

継続は、元の同期アクションに関して非同期に実行されますが、Apex 継続と他の非同期 Apex 技法 (future メソッド、Queueable、Batch など) との間には重要な相違点があります。主な違いは次のとおりです。

• 続行はキューに入れられません。
• 継続は、1 日の非同期 Apex 実行の制限にはカウントされません。
• 継続により、アプリケーション サーバー上のスレッド コンテキストが、重い Apex プラットフォーム スレッドからコールアウトのみを実行する軽量スレッドに切り替えられます。最大120秒の実行が可能なコールアウトを実行する目的で、継続はアプリケーションサーバーのメモリ使用量を大幅に節約する効果があります。
• 以前は、継続は Visualforce JavaScript リモート コールからのみ実行できました。ただし、Summer ‘19 では、Lightning コンポーネント フレームワークに継続が正式に追加され、Visualforce が不要になりました。

プラットフォームイベントは、Salesforce Platform の純粋なイベント駆動型アーキテクチャの実装です。このタイプのアーキテクチャに関連するコンポーネントについての詳細は、『Architect’s Guide to Event-Driven Architecture (イベント駆動型アーキテクチャのアーキテクトガイド)』を参照してください。

多くの場合、プラットフォーム イベントとプラットフォーム イベントのトリガー/フローは、非同期 Apex の実行に代わる優れた方法です。また、プラットフォーム外の処理を呼び出す優れた方法でもあります。たとえば、AWS(Amazon Web Services)イベント リレーとプラットフォーム イベントを組み合わせて使用し、AWS Lambdaでサーバーレス コンピューティング機能を呼び出すことができます。コールアウトを伴わず、比較的迅速に実行される作業（プラットフォームイベントのトリガーまたはフローからは実行できない）は、プラットフォームイベント / トリガーまたはイベント / フローの組み合わせとして最適です。

Publish after commit を介してバスに公開されたイベントは順番に配信され、トリガーまたはフローによって個別の同期コンテキストで一括処理できます。コンテキストは同期であり、すべての同期ガバナー制限が強制されます。制限に達しないように、プラットフォームイベントトリガー/フローの一括処理サイズ（バッチサイズ）を慎重に選択します。

• イベントはイベントバスで公開されるため、コンシューマーが入手可能です。イベント トリガー（Apex またはフロー）の場合、これらのイベントはアプリケーション層で使用可能な同期スレッド（イベント トリガー/フローごとに 1 つのスレッド）に送信されます。このプロセスには SLA がありません。
• 公開操作がキューに追加されると、キュープロセスの結果は Database.SaveResult オブジェクトに保存されます。これらのエントリは、キュー操作が成功したかどうかを示すだけです。イベント バスを介して公開されたイベントの最終結果を取得するには、Apex publish コールバックを実装します。この追加情報を使用して、失敗したイベントの再公開の試行など、今後のアクションに関する意思決定を行うことができます。
• プラットフォーム イベントには非同期 Apex と同じ制限が適用されませんが、独自の都道府県制限セットがあります。制限の問題が発生した場合は、拡張イベント使用総計値をイネーブルにして、特定のイベントで意図した以上の割り当てが消費されていないかどうかを確認できます。イベントトリガーのスループットを向上させる必要がある場合は、イベントを 1 つのストリームではなく、並列登録を使用して同時に処理することを検討してください。並列サブスクリプションでは、Apexプラットフォームイベントトリガーをスケールして大量のイベントを処理できます。並列登録は、カスタム大規模プラットフォームイベントで使用できますが、標準イベントや変更イベントでは使用できません。
• プラットフォームイベントの公開動作には 2 つのオプションがあります。
  • すぐに公開: イベントはトランザクション中に、データベースの最終確定前にすぐに公開されます。この方法で公開されるイベントは、順序どおりに公開されるとは限りません。
  • コミット後に公開: イベントは、データベーストランザクションが正常にコミットされた時点で公開されます。この方法で公開されるイベントは、順番に公開されます。

[すぐに公開] は、トランザクションの成功と確定、失敗とロールバックに関係なくログイベントを公開する必要があるログ記録などの使用事例で役立ちます。プラットフォームイベントトリガーによって消費されたプラットフォームイベントをすぐに公開できます。次に、プラットフォームイベントトリガーは、データベース行ロックを、その行を公開したトランザクションと競合します。プラットフォームイベントをすぐに公開する前に、すべての設計を徹底的に確認し、このシナリオを回避してください。

非同期フローは、非同期 Apex に代わるローコードの代替手段を提供します。他の形式の非同期処理と同様に、リソースが使用可能なときにバックグラウンドで実行されます。非同期フローにも SLA がなく、予測できない待機時間が発生する可能性があります。

スケジュール済みパスは、cronトリガーに基づいて特定の時間に実行されます。レコードが作成、更新、削除されたときに実行され、レコードの変更に対して自動化を実行するタイミングを詳細に制御できます。(例: ToDo の期日の 1 時間前にユーザーにメールを送信)。Apex future メソッドが同期トランザクションでキューに入れられるメソッドの最大数は 50 個に制限されていますが、スケジュール済みフロー アクションには現在、トランザクションあたりの最大エンキュー制限はありません。ただし、スケジュール済みパスの定義内にバッチサイズ設定があり、スケジュール済みパスフローの実行で処理するレコード数をある程度制御できます。

非同期パスは、レコードトリガーフローに追加できます。これらはバックグラウンドで実行され、最初にフローをトリガーしたトランザクションの実行が遅延することはありません。非同期パスを使用して、実行時間の長い操作や、独自の時間に実行する操作を実行できます。非同期パスは、フローをトリガーしたレコードに含まれていない関連レコードの値を更新する必要がある場合に発生する混在 DML エラーを回避するのに役立ちます。

注意: アウトバウンドメッセージングは従来の機能であり、プラットフォームイベント (前のセクションで説明) はより最新のアプローチで柔軟性に優れています。プラットフォームイベントは、イベント駆動型インテグレーションで Salesforce が推奨するパターンです。

送信メッセージは、SOAP API を介した非同期の送信通信の手段を提供します。Salesforce で設定すると、送信メッセージ定義で外部 Web サービスプロバイダーが使用できる SOAP WSDL が生成されます。送信メッセージは、ワークフロールール、プロセスビルダープロセス、または Lightning 保存後フロートリガーからトリガーできます。送信 SOAP メッセージには、最大 100 件の通知を含めることができます。各通知には、オブジェクト ID と、関連付けられた sObject データへの参照が含まれます。通知がキューに入れられた後、送信される前に基礎となるオブジェクトの情報が変更された場合、最新のデータのみが配信され、中間の変更は配信されません。

アウトバウンド メッセージ リスナー(生成された WSDL を使用して設定した Web サービス)がメッセージを受信すると、含まれているセッション ID 情報を使用して Lightning Platform API をコールし、アウトバウンド メッセージをトリガーした Salesforce のレコードを更新します。

• 送信メッセージは、Future メソッド、Queueable Apex、Batch Apex、Bulk API などのアクティビティを実行する Salesforce のキューベースの非同期インフラストラクチャでは処理されません。代わりに、レコードは OutboundMessage オブジェクトにローカルに保存されます。メッセージは、ローカルのスケジュール済みバックグラウンドプロセスを介して送信および再試行されます。
• 送信メッセージアクションが開始自動化 (保存後フロートリガーなど) によって実行される場合、メッセージは同期して送信されません。代わりに、正常に送信されるまで、または配信に失敗した 24 時間後に削除されるまで、OutboundMessage オブジェクトに残ります。
• 送信メッセージの無限ループを回避するには、オブジェクトを更新するユーザーに「送信メッセージを送信」権限がないことを確認します。

通常、メール-to-ケースは同期方式で機能します。受信メール-to-ケース要求を処理する同期スレッドは 4 つに制限されています。ハンドラーの同期形式では、メールを受信する受信 Salesforce メールサーバー (MTA) への接続が維持されます。ただし、メール-to-ケースを非同期で処理できる理由があります。

• メール-to-ケースにはスレッド制限が適用され、具体的にはアプリサーバーあたり合計10スレッドのハンドラーが使用されます（同期処理用に4スレッド、非同期処理用に6スレッド）。
• 同期メールハンドラーの実行時間が 15 秒を超える場合、その特定のメールサービスアドレスは 30 分間非同期としてマークされます。そのサービスアドレスに対する後続のハンドラー要求では、MessageTypeName = MAILCATcher_EMAIL_TO_CASE のメッセージがメールコンテンツへの参照と共にキューに追加されます。
• 特定の組織およびサービスアドレスで同期スレッドがすでに使用されている場合、そのサービスアドレスに対する追加の要求は非同期でキューに追加されます。
• 同期処理されたメールで行ロックタイムアウトなどのエラーが発生すると、要求が保存され、非同期でキューに追加されます。
• 使用可能な同期ハンドラースレッドがない場合、要求は非同期でキューに入れられます。

• メール-to-ケースを設定するときに重複排除オプションがありますが、メールが処理されるまで添付ファイルは重複排除されません。この重複排除により、データベースの容量は節約されますが、メール処理時間は短縮されません。ただし、メッセージ処理用のカスタム Apex メール-to-ケース ハンドラーを実装することで、パフォーマンスを向上させることができます。この実装はガバナ制限には影響しませんが、データベースにコミットする前にメールメッセージとそのすべての添付ファイルへのアクセス権をハンドラーに付与します。このアクセス権により、含まれているすべての添付ファイルのチェックサムを計算し、重複、有名な署名写真、不要なファイルの種類など、不要と判断した添付ファイルを破棄できます。
• メールの処理時間の大部分は、メールの添付ファイルを Salesforce Files にコミットすることで決まります。取引先責任者との間の返信応答が増加し、メールチェーンが大きくなると、各メールの処理時間も長くなります。[新しいコンテンツのみを含む返信] メールオプションが選択されていない場合、返信のたびにメールチェーンが増加します。そのため、処理時に添付ファイルの重複排除を実装するロジックが含まれる Apex メール-to-ケース ハンドラーを使用することをお勧めします。
• 処理の一環として Apex トリガーが呼び出された場合でも、メール-to-ケース ハンドラーは同時 Apex 制限から除外されます。

大量のレコードを非同期で処理するには、次のいずれかの方法を検討してください。

一括処理 Apex を使用して、数千件のレコードが含まれる複雑で実行時間の長いプロセスを作成できます。バッチ Apex は、レコードセットを分割して管理可能なチャンクで処理することで動作します。たとえば、夜間に実行され、特定の日付より古いレコードをアーカイブに追加するアーカイブソリューションを作成できます。または、すべての取引先と商談を夜間に確認し、定義済みの条件セットに基づいて必要な更新を実行するデータ消去操作を作成できます。

• バッチApexは、非同期Apexの制限が同期Apexよりも大きいため、大量のデータの処理に適しています。また、バッチApexは、キュー管理のオーバーヘッドが少ない一括処理を使用するため、バッチあたりの処理項目数が多くなると、パフォーマンスも向上します。そのため、キューのフラッディングによってフロー制御メカニズムがトリガーされ、1日の非同期Apex制限を使い果たしてしまうのを防ぐため、スコープの小さいバッチや処理時間が短いバッチを作成しないでください。
• 大量のエンドユーザー活動やインテグレーション API コールによって生成されたアクションから直接一括処理ジョブをキューに入れないようにします。この方法では、Flexキューがすぐに使い尽くされる可能性があります。トリガーから一括処理ジョブを呼び出す場合は、トリガーで制限を超える一括処理ジョブが追加されないようにする必要があります。
• バッチ Apex の同時スレッド数は最大 5 つに制限され、Future メソッドや Queueable Apex よりもスループットが大幅に制限されます。
• 大量のデータを扱う一括処理ジョブは、リアルタイムまたはほぼリアルタイムの応答を必要とするプロセスにリソースを解放するため、ピーク時間外に実行するようスケジュールすることをお勧めします。
• System.scheduleBatch をコールすると、指定した時間にジョブが実行されるようにプラットフォームでスケジュールされます。実際の実行は、サービスの対応可能状況に応じて、その時間以降に実行されます。
• スケジューラーはシステムコンテキストで実行されます。実行をスケジュールしたユーザーにクラスを実行する権限があるかどうかに関係なく、すべてのクラスが実行されます。
• スケジュール済みApex制限はすべて、System.scheduleBatchを使用してスケジュールされた一括処理ジョブに適用されます。一括処理ジョブがキューに入れられると（ステータスが［保留中］または［キュー］）、すべての一括処理ジョブの制限が適用され、ジョブはスケジュール済み Apex 制限に含まれなくなります。
• 定期的なスケジュールがある一括処理ジョブの場合、新しいジョブの実行が開始されたときに前のジョブがまだ実行中であれば、正しい動作を考慮してください。
• 同期Apexトランザクションからキューに入れられた一括処理ジョブでは、Flexキューが使用されます。Flex キューは、常に最大 100 個の項目に制限されます。トランザクションでエントリを追加しようとすると、プラットフォームでエラーが生成され、一括処理ジョブは送信されません。
• 一括処理ジョブからのコールアウトやその他の非トランザクション操作は、冪等性を考慮した設計に沿って実装する必要があります。Salesforce サービスメンテナンスのダウンタイム前にキューに入れられた一括処理ジョブはキューに残ります。サービスダウンタイムが終了し、システムリソースが使用可能になると、キュー内の一括処理ジョブが実行されます。ダウンタイムが発生したときに一括処理ジョブが実行中の場合、一括処理の実行はロールバックされ、サービスが復元された後に再開されます。そのため、execute メソッドは複数回実行される可能性があるため、コールアウトなどの非トランザクション操作を再試行できます。
• エラーと例外のシナリオを処理するために BatchApexErrorEvent イベントを発生させるように一括処理ジョブを設定することを検討してください。

スケジュールトリガーフローは、レコードのバッチに対してアクションを実行するために、指定された時間および繰り返し頻度 (毎日、毎週、または 1 回) で実行されるようにスケジュールされたフローです。(例: 毎晩午前 2 時に状況が「オープン」のすべてのケースの項目を更新します)。スケジュール済みフローは cron トリガーメカニズムを介して実行され、一括処理されます。

• スケジュールトリガーフローでは、呼び出しごとに 200 件のレコードが実行されますが、200 件を超えるレコードが存在する場合は複数の同時スレッドで実行されます。
• スケジュールトリガーフローは、同期制限のある同期コンテキストで実行されます。
• 現在、スケジュール済みフローの呼び出しごとに処理されるレコード数を制御する方法はありません。200 件を超えるレコードに対して実行する場合は、同時 Apex エラーになる危険があります。

Bulk API は REST の原則に基づいており、大規模なデータセットを操作するために最適化されています。これを使用して、多数のレコードを非同期で挿入、更新、アップサート、クエリ、または削除し、後で結果を処理できます。Salesforce Platform はバックグラウンドで要求を処理します。一方、SOAP API と REST API は同期要求を使用し、一度に数件のレコードを更新するリアルタイムクライアントアプリケーション向けに最適化されています。これらの両方の API を使用して多くのレコードを処理できますが、データセットに数十万件のレコードが含まれている場合、実用的ではありません。Bulk API の非同期フレームワークは、数千から数百万のレコードのデータを簡単かつ効率的に処理できるように設計されています。

Bulk API を使用する最も簡単な方法は、CSV ファイルを使用してデータローダーでレコードを処理できるように Bulk API を有効にすることです。データローダーを使用すると、独自のクライアントアプリケーションを作成する必要はありません。ただし、ユニークな要件により、カスタムアプリの作成が必要になる場合があります。

Salesforce Platform 内では 2 つの Bulk API を使用できます。

• Bulk API 2.0 は新しい API です。合理化された使いやすいワークフローが提供され、機能強化の焦点となっています。
• 元の Bulk API は引き続き完全にサポートされますが、拡張されなくなりました。可能な場合は Bulk API 2.0 を使用することをお勧めします。

API 制限についての詳細は、「Bulk API 制限」および「Bulk API 2.0 制限」を参照してください。

Salesforce Platform で非同期処理を構築または検討する場合は、このガイドを参照してください。使用可能なオプションの全容と、特定の使用事例にどのように適合するかを把握することをお勧めします。既存のアーキテクチャを変更する前に、現在の状況を徹底的に評価してください。特に、現在のソリューションが適切に機能している場合は注意が必要です。