Salesforce で制限超過のエラーが出たときの調べ方

ガバナ制限とは

Salesforce は、多くの組織が同じ基盤を共有するマルチテナントの環境で動いています。1 つの処理が共有の資源を使い切らないように、Apex の実行には回数や時間の上限が決められています。これをガバナ制限と呼びます。[1]

処理が上限を超えると、実行時の例外が出ます。この例外はコードの中で受け止めて処理を続けることができず、その処理は失敗します。画面に「制限を超えました」という趣旨のエラーが出るのは、このためです。[1]

上限は、1 回のトランザクションごとに数えます。Apex の一括処理では、レコードのまとまりを 1 つ処理するたびに数え直します。[1]

主な制限の値（2026年10月時点）

• 制限 1SOQL の発行回数1 回のトランザクションで発行できる検索（SOQL クエリ）は、同期の処理で 100 回、非同期の処理で 200 回までです。[8][3]
• 制限 2取得レコード数SOQL で取得できるレコードは、1 回のトランザクションで合わせて 50,000 件までです。[1]
• 制限 3DML の発行回数レコードの作成・更新・削除の命令（DML ステートメント）は 150 回までです。処理できるレコードは合わせて 10,000 件までです。[3]
• 制限 4CPU 時間Salesforce のサーバーで処理に使える時間は、同期の処理で 10,000 ミリ秒（10 秒）、非同期の処理で 60,000 ミリ秒です。[1][4]

フローも同じ制限に数えられる

フローにも、トランザクション単位の同じ制限がかかります。[レコードを取得] は SOQL の発行に、[レコードの作成]・[レコードを更新]・[レコードの削除] は DML の発行に数えます。[3]

CPU 時間の枠も共有です。同じトランザクションで動く Apex トリガー、フロー、ワークフロールールなどは、同じ 10 秒の枠を使います。ほかの自動化が先に枠を使っていると、フローそのものに問題がなくても失敗することがあります。[4]

制限を超えると、トランザクション全体が取り消されます。フローに障害パスを用意していても、取り消しは止まりません。[3]

画面フローは、利用者が [次へ] を押すたびに新しいトランザクションになります。制限は、その区切りごとに数えます。[3]

エラーの読み方とデバッグログ

最初に、どの制限を超えたのかを確かめます。たとえば CPU 時間を超えたときは、APEX_CPU_TIME_LIMIT_EXCEEDED というエラーになります。[4]

原因を探すには、デバッグログを使います。管理者が問題の出た利用者に追跡フラグを設定し、同じ操作をもう一度してもらうと、その処理の詳しい記録が残ります。ログが作られるのは、追跡フラグを設定した後に動いた処理だけです。[6]

設定は、[設定] の [クイック検索] に「デバッグログ」と入力して開きます。エラーが出た利用者のログを設定するか、フローをデバッグモードで実行して、エラーを再現します。[4]

ログの CUMULATIVE_LIMIT_USAGE には、「Number of SOQL queries: 0 out of 100」のように、制限ごとに使った量と上限が並びます。フローでは、FLOW_ELEMENT_LIMIT_USAGE で要素ごとの CPU 時間を見られます。[7][4]

システムのデバッグログは、2026年10月時点で 24 時間保持されます。再現したら、早めにログを開いて確かめます。[6]

Apex の中では、Limits のメソッドで、使った回数と上限を実行中に確かめられます。[2]

ループの中の検索・更新と一括処理

公式の資料で原因として挙げられているのが、ループの中で検索や更新をする作りです。100 件の商談をループで回し、その中でレコードを作成すると、DML が 100 回発行されます。ループの中の [レコードを取得] も、回した数だけ検索を発行します。[4]

直し方は、一括処理（バルク化）です。ループの中では、作るレコードを割り当て要素でコレクション変数にためておき、ループが終わってから 1 つの要素でまとめて作成・更新します。必要なデータは、ループに入る前に 1 回の [レコードを取得] で集めておきます。[4]

Apex でも考え方は同じです。検索はループの外で 1 回にまとめ、更新は 1 件ずつではなく、レコードの集まり（コレクション）に対して行います。[8]

フローでは、同じ要素で止まったインタビューの処理を、Salesforce がまとめて実行します。ただし、1 つでも制限を超えると、同じトランザクションのインタビューはすべて失敗します。[5]

画面から 1 件保存したときは問題が出なくても、データの一括読み込みでは、トリガーが 200 件ずつのまとまりで動きます。フローのデバッグは 1 件で試すのが通常なので、本番に出す前に、実際に近い件数で試します。[8][4]

非同期処理の選択肢

• 方法 1キュー可能 Apex時間のかかる処理を別に始めて、ジョブの ID を受け取りたいときや、ジョブを順につなげたいときに使います。非同期の処理なので、SOQL の発行回数や CPU 時間の上限が同期より大きくなります。[9][8][1]
• 方法 2Apex の一括処理大量のデータを、いくつかのまとまりに分けて処理します。まとまりごとに制限を数え直します。[9][1]
• 方法 3future メソッド時間のかかる処理や外部のサービスの呼び出しを、元のトランザクションから切り離して動かします。[9]
• 方法 4スケジュール済み Apex決まった日時に Apex を動かします。非同期の機能ですが、制限は同期の値が使われます。[9][1]
• 方法 5フローでの分け方作業を複数のスケジュール済みフローに分ける、プラットフォームイベントで別のトランザクションに分ける、大量のデータは Apex の一括処理に任せる、といった方法が案内されています。[4]