Apexはマルチテナント環境で実行されるため、Apexランタイムエンジンは共有リソースを独占しないように、いくつかの制限を厳しく実施します。
これらの制限またはガバナは、以下の表であらわされる数値に基づいてトラッキングされ、実施されます。
Apexコードが制限を超えた場合は、関連するガバナはハンドリング不可の実行時例外を出します。
ガバナ制限は、全組織、ならびに特定のnamespaceに適用されます。
たとえば、Salesforce.com ISV パートナーによって作成された管理パッケージをForce.com AppExchangeからインストールした場合、パッケージに含まれるコンポーネントは組織中の他のコンポーネントから独立したnamespaceに属しています。したがって、そのパッケージ中のApexコードは150回までDML文を実行できます。さらに、組織中に既に存在するApexコードも最大で150回のDML文を実行できます。それは、管理パッケージと既存の組織中コードの両方が実行された場合は、1回のリクエストで150回以上のDML文が実行されるかもしれないということを意味します。
一方で、Salesforce.com ISVパートナーによって作成されていないAppExchangeからパッケージをインストールした場合は、そのパッケージに含まれるコードは別のガバナ制限としてカウントされません。
累積的なリソースメッセージおよび警告電子メールも管理パッケージnamespaceに基づいて生成されます。
Salesforce.com ISVパートナーパッケージの詳細については、salesforce.com パートナープログラムを参照してください。
| 1回のトランザクションで実行できるSOQLクエリの合計回数1 |
100
|
| 1回のトランザクションでSOQLクエリにより取得できるレコード数 |
50,000
|
| 1回のトランザクションで実行できるSOSLクエリの合計回数 |
20
|
| 1回のトランザクションでSOSLクエリにより取得できるレコード数 |
200
|
| 1回のトランザクションで実行できるDML文の合計回数2 |
150
|
| 1回のトランザクションでDML文、またはApproval.process、またはdatabase.emptyRecycleBinにより処理できるレコード数 |
10,000
|
| 1回のトランザクションで実行可能なステートメント数 |
200,000
|
| 1回のトランザクションで消費できるメモリヒープサイズ3
|
3 MB3
|
| ApexからのDML文(insert, update, delete)呼び出しで再帰的に起動されるトリガの呼び出し階層の深さ4 |
16
|
| ForループListのバッチサイズ |
200
|
| 1回のリクエストで呼び出せるコールアウト処理 (HTTPリクエスト または Web services コール) |
10
|
| 1回のリクエスト中のすべてのコールアウト処理のタイムアウト (HTTPリクエスト または Web services コール) |
120 秒
|
| 1回のリクエスト中のコールアウト処理のデフォルトタイムアウト (HTTPリクエスト または Web services コール) |
10 秒
|
| 1回のApex起動で実行できる@futureアノテーションがついたメソッド数5 |
10
|
| コールアウトリクエストまたはレスポンスの最大サイズ (HTTPリクエスト または Web services コール) 6 |
3 MB
|
| 1回のトランザクションで実行できるsendEmailメソッドの数 |
10
|
| 1回のトランザクションで実行できるdescribeメソッドの回数7 |
100
|
1
親-子リレーションシップサブクエリのあるSOQL文では、各親-子リレーションシップは追加のクエリとしてカウントされます。このような形のクエリは制限値がトップレベルクエリの3倍となります。リレーションシップクエリ結果の行数はスクリプト実行全体の行数に含めてカウントされます。
2次のメソッドはリクエスト中のDML文の実行としてカウントされます。:
- Approval.process
- database.emptyRecycleBin
- delete and database.delete
- findSimilar
- insert and database.insert
- merge
- rollback
- runAs
- setSavePoint
- update and database.update
- upsert and database.upsert
3 Batch Apex のメモリヒープサイズは 6 MB です。電子メールサービスのメモリヒープサイズは 18 MB です。
4 insert, update,
または delete文によるトリガの実行を伴わない、再帰的なApex呼び出しは同一の処理階層で扱われます。
一方、トリガにより起動された再帰的なApex呼び出しは、トリガを起動した呼び出しとは別の呼び出しとして扱われます。
なぜならば、新しいApex呼び出しはコストの高い処理であるため、このタイプの深い階層の呼び出しにはより厳しい制約が課せられるためです。
5Salesforceは、futureアノテーションに対する制限を課しています。24時間に、フルSalesforceユーザーライセンス数毎に200回のメソッド呼び出しが可能です。これは組織単位での制限です。たとえば、ある組織が5つのフルSalesforceユーザーライセンスと100のカスタマポータルユーザーライセンスを持っているとしましょう。組織全体では24時間に1,000回のメソッド呼び出しが可能です。（5*200です。105ではありません。）
6HTTPリクエストおよびレスポンスのサイズは合計メモリヒープサイズの一部として計算されます。 この制限に関係なく、3MBの合計メモリヒープサイズを超えないようにしてください。
7 Describes は、次のメソッドおよびオブジェクトを含みます。:
- ChildRelationship objects
- RecordTypeInfo objects
- PicklistEntry objects
- fields calls
制限は、各 testMethodに対して独立して適用されます。
実行中のコードのスクリプト実行制限を判断するために、Limitsメソッドを使用してください。
たとえば、プログラムによって既にコールされたDML文の数を判断するためのgetDMLStatementsメソッドや、またはそのコンテキストでのDML文実行可能な回数を判断するための getLimitDMLStatementsメソッドを使用できます。
より効率的なSOQLクエリのために、特にトリガ中でのクエリでは、より絞り込み効果の高い、インデックスを利用したクエリを使用しください。絞り込み効果の高いクエリとは、プライマリキー（Id）、外部キー、Name項目、監査日付（例:
LastModifiedDate）、外部ID項目でフィルタリングするクエリです。
大きな組織では、実行時間が非常に長くなるのを防止するために性能の低いクエリは停止させることができます。停止させたい場合は、Salesforce.comの担当者に連絡してください。
static変数の値はAPIバッチごとにリセットされますが、ガバナ制限はリセットされません。APIバッチの状態のトラッキングにstatic変数を使わないでください。なぜならば、Salesforceはユーザーが指定したバッチサイズよりもより細かい単位にバッチを分割している可能性があるためです。
実行時のガバナ制限に加え、
Apexには次の制限があります:
電子メールサービスを定義する際は次の点にも注意してください:
- 電子メールサービスは、単一のアドレスのメッセージのみを処理します。
- Salesforceは、オンデマンド電子メールtoケースを含む、統合された電子メールサービスメッセージの合計数で日次での制限をかけています。メッセージがこの制限を超えた場合は、電子メールサービス失敗時の設定次第で、バウンスされるか、破棄されるか、その翌日処理のためにキューイングされます。Salesforceはユーザーライセンス数に1,000をかけた値で制限値を計算します。もし10ライセンスであればその組織は1日に10,000メッセージを処理できます。
- Sandbox組織で作成した電子メールサービスアドレスは、本番組織へコピーできません。
- 各電子メールサービスに、エラーメールを、送信者のアドレスの代わりの特定のアドレスへ送信するようにSalesforceへ指定できます。
- 電子メール(テキスト本文、HTML本文および添付ファイルを含む)が約10MB(言語や文字セットにより異なります)を超えた場合、電子メールサービスは送信者に通知することなく電子メールを拒否します。