参考
Apex はマルチテナント環境で実行するため、Apex ランタイムエンジンは、回避 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
- 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 コールアウトの待ち時間はカウントされません。
6この制限は、1 つのトランザクション内の future、キュー内、スケジュール済み、および一括処理のコールの組み合わせに適用されます。ただし、スケジュール済みジョブの合計数が 100 を超えることはできず、Flex キューの一括処理ジョブの合計数が 100 を超えることはできません。
トランザクション単位の認定管理パッケージの制限
認定管理パッケージ (AppExchange のセキュリティレビューに合格した管理パッケージ) には、ほとんどのトランザクション単位の制限に対して独自の制限セットが設けられます。認定管理パッケージは Salesforce ISV パートナーによって開発され、Force.com AppExchange から組織にインストールされ、固有の名前空間を持ちます。
ここでは、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 |
1 つの Apex トランザクション内の非同期コールの最大数 | 2,200 |
許可される sendEmail メソッドの合計数 | 110 |
- ヒープの合計サイズ
- 最大 CPU 時間
- 最大トランザクション実行時間
- 固有の名前空間の最大数
これらの制限は、同じトランザクションで実行されている認定管理パッケージの数に関係なく、トランザクション全体に対してカウントされます。
また、Salesforce ISV パートナー以外が作成した未認定の AppExchange からパッケージをインストールする場合、そのパッケージのコードには、別個に独自のガバナ制限はありません。使用するリソースは、組織の合計ガバナ制限数に含まれます。累積リソースメッセージと警告メールも、管理パッケージの名前空間に基づいて生成されます。
Salesforce ISV パートナーパッケージの詳細は、「Salesforce Partner Programs」を参照してください。
Force.com プラットフォームの Apex 制限
次の表の制限は、Apex トランザクションに固有ではなく、Force.com プラットフォームによって適用されます。
1 Apex 一括処理の場合、メソッド実行には、start、execute、および finish メソッドの実行が含まれます。これは組織全体の制限で、他のすべての非同期 Apex (Apex 一括処理、キュー可能 Apex、スケジュール済み Apex、および future メソッド) と共有されます。この制限のカウント対象となるライセンスは、Salesforce フルユーザライセンスまたは Force.com アプリケーションサブスクリプションのユーザライセンスです。Chatter Free、Chatter カスタマーユーザ、カスタマーポータルユーザ、およびパートナーポータルユーザライセンスは含まれません。
2 10 個の長時間の要求が実行されている間に追加の要求を行うと、要求は拒否されます。
3 一括処理ジョブが送信されると、処理用にシステムキューに移動されるまで、Flex キューに保持されます。
4 キュー内のまだ開始されていない一括処理ジョブは、開始されるまで保持されます。複数のジョブが実行されている場合は、この制限により一括処理ジョブが失敗することはなく、Apex の一括処理ジョブの execute メソッドが並行して実行されます。
5 この制限は、テストの非同期実行に適用されます。このテストグループには、開発者コンソールを含め、Salesforce ユーザインターフェースから開始するテストが含まれます。
6 たとえば、50 個のカーソルが開いていて、同じユーザとしてログインしたままのクライアントアプリケーションが新しいカーソルを開こうとすると、50 個のカーソルのうち最も古いカーソルが解放されます。異なる Force.com 機能のカーソル制限は個別に追跡されます。たとえば、50 個の Apex クエリカーソル、Apex 一括処理の start メソッドに 15 個のカーソル、Apex 一括処理の execute および finishメソッドにそれぞれ 5 個のカーソル、および 5 個の Visualforce カーソルを同時に開くことができます。
7 ホストは、URL の一意のサブドメインで定義されます。たとえば、www.mysite.com と extra.mysite.com は 2 つの異なるホストです。この制限は、同じホストにアクセスするすべての組織で計算されます。この制限を超過すると、CalloutException が発生します。
静的 Apex の制限
サイズ固有の Apex 制限
説明 | 制限 |
---|---|
クラスの最大文字数 | 100 万 |
トリガの最大文字数 | 100 万 |
組織内のすべての Apex コードで使用されるコードの最大量1 | 3 MB |
メソッドのサイズ制限 2 | コンパイル形式で 65,535 バイトコード命令 |
1 この制限は、AppExchange からインストールされた認定管理パッケージ (AppExchange Certified とマークされたアプリケーション) には適用されません。これらのパッケージタイプのコードは、組織のコードとは異なる独自の名前空間に属しています。AppExchange Certified パッケージについての詳細は、Force.com AppExchange オンラインヘルプを参照してください。この制限は、@isTest アノテーションで定義されたクラスに含まれるコードにも適用されません。
2 制限を超える大規模なメソッドはコードの実行中に例外が発生する場合があります。
その他の Apex の制限
-
SOQL クエリのパフォーマンス
- 最高のパフォーマンスを得るためには、特にトリガ内のクエリに対しては、セレクティブ SOQL クエリを使用する必要があります。実行時間が長くなるのを避けるために、システムはセレクティブ以外の SOQL クエリを終了できます。100,000 件を超えるレコードを含むオブジェクトに対してトリガでセレクティブではないクエリを使用すると、エラーメッセージが表示されます。このエラーを回避するには、必ずセレクティブクエリを使用します。「より効率的な SOQL クエリ」を参照してください。 Chatter in Apex
- ConnectApi 名前空間内のクラスの場合、各書き込み操作が Apex ガバナ制限で 1 回の DML 操作としてカウントされます。 ConnectApiメソッドコールも、レート制限の対象となります。 ConnectApi レート制限は、Chatter REST API レート制限と同じです。どちらにも、ユーザごと、名前空間ごと、時間ごとのレート制限があります。レート制限を超えると、 ConnectApi.RateLimitException が発生します。Apex コードで、この例外をキャッチして処理する必要があります。 イベントレポート
- システム管理者以外のユーザの場合、イベントレポートが返すレコードの最大数は 20,000 件です。システム管理者の場合、100,000 件です。 Data.com クリーンアップ
- Data.com クリーンアップ製品とその自動ジョブを使用していて、取引先、取引先責任者、またはリードレコードで SOQL クエリを実行する Apex トリガを設定している場合、それらのオブジェクトでクエリがクリーンアップジョブに干渉する可能性があります。Apex トリガ (合計) は、バッチあたり 200 個以下の SOQL クエリにしてください。この制限を超えると、そのオブジェクトに対するクリーンアップジョブが失敗します。また、トリガが future メソッドをコールする場合は、バッチあたり 10 個の future コールに制限されます。
転送通知の制限
モバイルアプリケーション種別 | アプリケーションごとの 1 日の最大通知数 |
---|---|
Salesforce により提供されたモバイルアプリケーション (Salesforce1 など) | 50,000 |
内部の社員向けに自社開発されたモバイルアプリケーション | 35,000 |
AppExchange からインストールされたモバイルアプリケーション | 5,000 |
配信可能な通知のみがこの制限にカウントされます。たとえば、通知が会社の 1,000 名の従業員に送信されるが、100 名の従業員はまだモバイルアプリケーションをインストールしていない場合を考えます。モバイルアプリケーションをインストールしている 900 名の従業員に送信された通知のみがこの制限にカウントされます。
[転送通知をテスト] ページで生成された各テスト転送通知の受信者は 1 名に制限されています。テスト転送通知は、アプリケーションの 1 日の転送通知制限にカウントされます。