実行ガバナと制限
このトピックでは、コア Apex ガバナ制限に加え、メール制限やプッシュ通知の制限も参照しやすいように、この後に含まれています。
トランザクション単位の Apex 制限
これらの制限は、Apex トランザクション単位でカウントされます。Apex 一括処理の場合、これらの制限は execute メソッドでレコードのバッチの実行ごとにリセットされます。
次の表では、同期 Apex と非同期 Apex (Apex 一括処理と future メソッド) が異なる場合、それぞれの制限を記載しています。制限が同じ場合、表には、同期および非同期 Apex の両方に適用される 1 つの制限のみが記載されます。
- Database.countQuery
- Database.getQueryLocator
- Database.query
- Approval.process
- Database.convertLead
- Database.emptyRecycleBin
- Database.rollback
- Database.setSavePoint
- delete と Database.delete
- insert と Database.insert
- merge および Database.merge
- undelete と Database.undelete
- update と Database.update
- upsert と Database.upsert
- コミット後に公開するように設定されたイベントに対する EventBus.publish
- System.runAs
3 insert、update、または delete ステートメントによってトリガを実行しない繰り返し Apex 処理は、1 つのスタックを使用する 1 つの呼び出し内に存在します。それに対し、トリガを実行した繰り返し Apex では、新しい Apex 呼び出しでトリガが発生します。この新しい呼び出しは、コードを実行した呼び出しとは独立しています。Apex の新しい呼び出しの実行は、1 つの呼び出しでの繰り返しコールよりも手間のかかる操作です。したがって、これらの種類の繰り返しコールのスタックの深さには、より厳しいトリガ制限があります。
5 CPU 時間は、1 つの Apex トランザクションで発生する Salesforce アプリケーションサーバ上でのすべての実行に対して計算されます。CPU 時間は、Apex コードや、このコードからコールされるすべてのプロセス (パッケージコードやワークフローなど) の実行に対して計算されます。CPU 時間は、1 つのトランザクション専用であり、他のトランザクションからは独立しています。アプリケーションサーバの CPU 時間を消費しない操作は、CPU 時間には加算されません。たとえば、実行時間のうち DML、SOQL、および SOSL 用のデータベースに費やされた時間や、Apex コールアウトの待ち時間はカウントされません。
トランザクション単位の認定管理パッケージの制限
認定管理パッケージ (AppExchange のセキュリティレビューに合格した管理パッケージ) には、ほとんどのトランザクション単位の制限に対して独自の制限セットが設けられます。AppExchange から組織にインストールされ、固有の名前空間を持つ認定管理パッケージを開発するのは、Salesforce ISV パートナーです。
ここでは、DML ステートメントについて、認定管理パッケージに別個に設定される制限の例を説明します。認定管理パッケージをインストールすると、そのパッケージ内のすべての Apex コードには、独自に 150 個の DML ステートメントの制限が設定されます。これらの DML ステートメントは、組織のネイティブコードが実行できる 150 個の DML ステートメントに追加されます。この制限の緩和によって、管理パッケージのコードとネイティブの組織のコードの両方が実行されると、1 つのトランザクションで 150 個を超える DML ステートメントが実行される可能性があります。同様に、同期 Apex については、認定管理パッケージには組織のネイティブコードの 100 個の SOQL クエリ制限に加え、独自に 100 個の SOQL クエリ制限が設定されます。
1 つのトランザクションで呼び出せる認定名前空間の数は無制限です。ただし、各名前空間で実行できる操作の数は、トランザクションあたりの制限を超えることはできません。トランザクション内の全名前空間で実行できる累積操作数にも制限があります。この累積制限は、名前空間あたりの制限の 11 倍です。たとえば、SOQL クエリの名前空間あたりの制限が 100 だとすると、1 つのトランザクションで実行できる SOQL クエリは最大 1,100 個です。この場合、累積制限は名前空間あたりの制限 100 の 11 倍です。これらのクエリは、いずれかの名前空間のクエリが 100 を超えない限り、無制限の数の名前空間で実行できます。累積制限は、すべての名前空間で共有される制限 (最大 CPU 時間の制限など) に影響しません。
| 説明 | 累積クロス名前空間制限 |
|---|---|
| 発行される SOQL クエリの合計数 | 1,100 |
| Database.getQueryLocator によって取得されるレコードの合計数 | 110,000 |
| 発行される SOSL クエリの合計数 | 220 |
| 発行される DML ステートメントの合計数 | 1,650 |
| トランザクション内のコールアウト (HTTP 要求または Web サービスコール) の合計数 | 1,100 |
| 許可される sendEmail メソッドの合計数 | 110 |
- ヒープの合計サイズ
- 最大 CPU 時間
- 最大トランザクション実行時間
- 固有の名前空間の最大数
これらの制限は、同じトランザクションで実行されている認定管理パッケージの数に関係なく、トランザクション全体に対してカウントされます。
AppExchange で提供されるパッケージのコードのうち、Salesforce ISV パートナー以外が作成した未認定のコードには、個別のガバナ制限はありません。パッケージで使用されるリソースはすべて、組織の合計ガバナ制限数に含まれます。累積リソースメッセージと警告メールも、管理パッケージの名前空間に基づいて生成されます。
Salesforce ISV パートナーパッケージの詳細は、「Salesforce パートナープログラム」を参照してください。
Lightning Platform フォームの Apex 制限
次の表の制限は、Apex トランザクションに固有ではなく、Lightning プラットフォームによって適用されます。
1 Apex 一括処理の場合、メソッド実行には、start、execute、および finish メソッドの実行が含まれます。
2 10 個の長時間のトランザクションが実行されている間に追加のトランザクションが開始されると、追加のトランザクションは拒否されます。この制限を計算する場合、HTTP コールアウトの処理時間は含まれません。
3 一括処理ジョブが送信されると、処理用にシステムキューに移動されるまで、Flex キューに保持されます。
4 キュー内のまだ開始されていない一括処理ジョブは、開始されるまで保持されます。複数のジョブが実行されている場合���、この制限により一括処理ジョブが失敗することはありません。Apex の一括処理ジョブの execute メソッドは、依然として並行して実行されます。
5 この制限は、テストの非同期実行に適用されます。このテストグループには、開発者コンソールを含め、Salesforce ユーザインターフェースから開始するテストが含まれます。
6 たとえば、開いているカーソルが 50 個あるとします。同じユーザとしてログインしているクライアントアプリケーションで新しいカーソルを開こうとすると、50 個のうち最も古いカーソルが解放されます。異なる Lightning Platform 機能のカーソル制限は個別に追跡されます。たとえば、50 個の Apex クエリカーソル、Apex 一括処理の start メソッドに 15 個のカーソル、Apex 一括処理の execute および finish メソッドにそれぞれ 5 個のカーソル、および 5 個の Visualforce カーソルを同時に開くことができます。
静的 Apex の制限
サイズ固有の Apex 制限
| 説明 | 制限 |
|---|---|
| クラスの最大文字数 | 100 万 |
| トリガの最大文字数 | 100 万 |
| 組織内のすべての Apex コードで使用されるコードの最大量1 | 6 MB |
| メソッドのサイズ制限 2 | コンパイル形式で 65,535 バイトコード命令 |
1 この制限は、第一世代 (1GP) または第二世代 (2GP) 管理パッケージの Apex コードには適用されません。これらのパッケージタイプのコードは、組織のコードとは異なる独自の名前空間に属しています。この制限は、@isTest アノテーションで定義されたクラスに含まれるコードにも適用されません。
その他の Apex の制限
- Apex の Connect
- ConnectApi 名前空間内のクラスの場合、各書き込み操作が Apex ガバナ制限で 1 回の DML 操作としてカウントされます。ConnectApi メソッドコールも、レート制限の対象となります。ConnectApi レート制限は、Connect REST API レート制限と同じです。どちらにも、ユーザごと、名前空間ごと、時間ごとのレート制限があります。レート制限を超えると、ConnectApi.RateLimitException が発生します。Apex コードで、この例外をキャッチして処理する必要があります。
- Data.com Clean
- Data.com Clean 製品とその自動ジョブを使用する場合は、Apex トリガの使用方法を検討してください。取引先、取引先責任者、またはリードレコードで SOQL クエリを実行する Apex トリガを使用する場合、それらのオブジェクトで SOQL クエリがクリーンアップジョブに干渉する可能性があります。Apex トリガ (合計) は、バッチあたり 200 個以下の SOQL クエリにしてください。この制限を超えると、そのオブジェクトに対するクリーンアップジョブが失敗します。また、トリガが future メソッドをコールする場合は、バッチあたり 10 個の future コールに制限されます。
- イベントレポート
- システム管理者以外のユーザの場合、イベントレポートが返すレコードの最大数は 20,000 件です。システム管理者の場合、100,000 件です。
- Apex テストでの MAX_DML_ROWS の制限
- 1 つの同期 Apex テストの実行コンテキストで挿入、更新、または削除できる行の最大数は 450,000 に制限されています。たとえば、Apex クラスでは 10,000 行を挿入するメソッドを 45 個使用できます。この制限に達すると、[Your runallTests is consuming too many DB resources (runallTests が消費する DB リソースが多すぎます)] のエラーが表示されます。
- SOQL クエリのパフォーマンス
- 最高のパフォーマンスを得るためには、特にトリガ内のクエリに対しては、セレクティブ SOQL クエリを使用する必要があります。実行時間が長くなるのを避けるために、システムはセレクティブ以外の SOQL クエリを終了できます。200,000 件を超えるレコードを含むオブジェクトに対してトリガでセレクティブではないクエリを使用すると、エラーメッセージが表示されます。このエラーを回避するには、必ずセレクティブクエリを使用します。「より効率的な SOQL クエリ」を参照してください。
メール制限
- 受信メール制限
-
1 メールサービスのメールメッセージの最大数は、ボディパートの文字セットと転送文字コードによって異なります。メールメッセージのサイズには、メールヘッダー、本文、添付ファイル、エンコードが含まれます。そのため、添付ファイルが 35 MB のメールは、ヘッダー、本文、エンコードを考慮すると、メールメッセージのサイズ制限 25 MB を超える可能性があります。メールサービスを定義するときには、次の点に注意してください。
- メールサービスは、そのアドレスの 1 つが受信したメッセージを処理するだけです。
- Salesforce は、[オンデマンドメール-to-ケース] など、すべてのメールサービスを合計した 1 日に処理できるメッセージの総数を制限します。この制限を超えたメッセージは、各メールサービスの失敗時のレスポンス設定に基づいて、戻される、破棄される、あるいは翌日処理するためのキューに入れられます。Salesforce では、制限値は、ユーザライセンス数 x 1,000 で算出され、最大値は 1,000,000 です。たとえば、ライセンス数が 10 の場合、1 日最大 10,000 件のメールメッセージを処理できます。
- Sandbox 内に作成したメールサービスアドレスは、本番組織にコピーできません。
- メールサービスごとに Salesforce に通知して、送信者のメールアドレスではなく、特定のアドレスにエラーメールメッセージを送信できます。
- メールが (本文テキスト、本文 HTML および添付ファイルを合わせて) 約 25 MB を超える場合 (言語や文字セットに応じて異なる)、メールサービスはメールメッセージを拒否し、送信者に通知します。
- 送信メール: Apex を使用して送信する単一メールおよび一括メールの制限
-
グリニッジ標準時 (GMT) に基づき、各ライセンス組織は 1 日に最大 5,000 個の外部メールアドレスに単一メールを送信できます。Spring '19 よりも前に作成された組織では、この日次制限は、Apex と Salesforce API (REST API を除く) を介して送信されたメールに対してのみ適用されます。Spring '19 以降に作成された組織では、この日次制限はメールアラート、単純なメールアクション、フロー内の [メールを送信] アクション、および REST API にも適用されます。組織がこの制限に達したため新しくカウントされたいずれかのメールを送信できない場合、通知のメールがユーザに送信され、エントリがデバッグログに追加されます。Salesforce の Email Author やコンポーザを使用して送信した単一メールは、この制限に含まれません。取引先、取引先責任者、リード、商談、ケース、キャンペーン、カスタムオブジェクトの各ページから、組織の取引先責任者、リード、個人取引先、ユーザに単一メールを直接送信する場合は、制限はありません。Developer Edition 組織とトライアル期間中に Salesforce を評価している組織では、1 日あたり最大 50 人の受信者にメールを送信でき、個々のメールには最大 15 人の受信者を含めることができます。
単一メールを送信する場合は、次の点に注意してください。グリニッジ標準時 (GMT) に基づいて、ライセンス許可を受けた 1 Salesforce 組織あたり 1 日に最大 5,000 個の外部メールアドレスに一括メール送信できます。
プッシュ通知の制限
配信可能な通知のみがこの制限にカウントされます。たとえば、通知が会社の 1,000 名の従業員に送信されるが、100 名の従業員はまだモバイルアプリケーションをインストールしていない場合を考えます。モバイルアプリケーションをインストールしている 900 名の従業員に送信された通知のみがこの制限にカウントされます。
[プッシュ通知をテスト] ページで生成された各テストプッシュ通知の受信者は 1 名に制限されています。テストプッシュ通知は、組織の 1 時間のプッシュ通知制限にカウントされます。
組織の 1 時間のプッシュ通知制限に達しても、アプリケーション内表示および REST API を介した取得の通知は引き続き作成されます。