Salesforceのガバナ制限とは？概要とフローでエラーを回避する5つの設計ルール 2026年08月14日
Salesforceの構築を担当する人が一度は経験するのが「ガバナ制限」のエラーです。このガバナ制限は、エラーの仕組みを理解していないと厄介に思えるかもしれませんが、Salesforceの環境下で安定した処理を行うために非常に重要なルールとなっています。
本記事では、Salesforceにおけるガバナ制限の基礎知識から、特にトラブルが発生しやすい「フロー」での具体的なガバナ制限回避ルール（5つの設計テクニック）までを分かりやすく解説します。
-
Salesforceの「ガバナ制限」とは？
salesforceのガバナ制限とは、salesforceのサーバー処理が高負荷になる（なりそう）な時に、制限する上限ルールのことを言います。ガバナ制限の上限を超えるとエラーになってしまい、基本的にロールバック（処理前の状態に戻る）されることになります。
salesforceのサーバーはマルチテナント（他の会社も同じサーバーを利用する）環境のため、どこかの会社の処理による高負荷によって、他の会社の処理が遅くならないようにガバナ制限が設けられています。
例えば、夜間にデータを自動更新するフローの処理対象データ数が多すぎてガバナ制限になることがあります。このようなガバナ制限になる場合は、処理方法を見直す必要が出てきます。
-
ガバナ制限の種類
ガバナ制限には様々な種類があります。それは、様々な処理や処理方法に対して安定した処理を供給するためのガバナ制限が求められるためです。以下に主なガバナ制限を3つ紹介しますので、ガバナ制限からどんな処理が制限に該当するのかを理解しましょう。詳細なガバナ制限を把握したい場合は、公式「ガバナ制限の一覧」の確認が推奨です。
① DML制限（データの追加・更新・削除の制限）
DML（Data Manipulation Language）とは、Salesforce上のレコードを作成・更新・削除する操作のことです。 データに何らかの変更が発生するDMLに対してガバナ制限が存在します。
主なトランザクションあたりの制限は以下が該当します。
- DMLステートメント発行回数：150回まで
- 処理対象のレコード総件数：10,000件まで
例えば1回の処理で「レコード更新」が150回を超えて実行されるとエラーの処理になってしまいます。繰り返しのループ処理でレコード更新をしてしまうと、しばしばDML制限に該当しがちです。1回毎にレコード更新するのではなく、一括処理を心がけることで回避できることがあります。
② SOQL制限（データの取得・検索の制限）
SOQL（Salesforce Object Query Language）とは、salesforceのデータを検索・取得するためのクエリ操作のことです。 例えば、所有者が同じ商談を検索するといった操作がクエリ操作になります。
主な制限は以下が該当します。
- SOQLクエリ発行回数：100回まで
- （同期処理の場合）取得レコード件数：50,000件まで
このSOQLでよく頻発するエラーの1つである「Too many SOQL queries: 101」は、SOQL制限の100回を超えたことで発生します。 DML制限と同様に、フローのループ内で「レコードを取得」要素をしてしまうと発生します。クエリをループに入れる前に取得レコードの条件を指定することで回避できる場合があります。
③ API呼び出し制限（外部システム連携の制限）
SOQLやDML制限が1回のトランザクションの制限であるのに対し、API制限は「組織全体で24時間以内に実行できる外部システムとの通信回数」の制限です。 なので複数の処理でAPIが使われている場合は、制限に注意が必要です。
主な制限は以下が該当します。
- 組織のライセンス数や契約プランに応じた上限（24時間のローリング形式）
Salesforceと外部システム連携をした上で、データのやり取りを大量にしている場合にガバナ制限に引っかかるケースが多いです。上限を超えると外部システムからのデータ連携が停止するため、複数の処理にわたって影響する場合もあります。
レコード単位でAPIを叩くリアルタイム連携をやめて、まとめてデータを送信するバッチ処理への変更や差分のみを更新することで回避できる場合があります。
-
フローでよく起きるガバナ制限エラーと回避方法
自動化を推進できるフローにおいてよく頻発するガバナ制限の例と回避方法を説明します。DML制限とSOQL制限で回避方法に少し触れましたが、どちらもループ内で処理をすると制限にかかりがちです。そこで、ループ内処理のどこが悪いのか理解できるようにフローを見ながら解説したいと思います。
以下は、ガバナ制限にかかりやすい悪い例と良い例を並べたフローの画像です。どちらが悪い方かわかるでしょうか？ガバナ制限にかかりやすいのは画像左の例です。
上記の画像でコメントしていますが、左のフローは「レコードを取得」と「レコードを更新」の要素がループ内に配置されています。改めてですが、ループ内に配置されているということはループが繰り返される数だけ「レコードを取得」と「レコードを更新」が行われます。ループが200回繰り返されれば200回処理がなされますので、ガバナ制限に引っかかります。
一方で画像右のフローを見てみましょう。右のフローは「レコードを取得」と「レコードを更新」の要素がループの外にありますので、処理は1回だけのためガバナ制限を回避しやすい構造になっています。
このように自動化の処理を取っても構築内容によってガバナ制限になりやすい場合とがバナ制限になりづらい場合が出てきます。これを理解した上で構築できるようになるのがおすすめです。
ガバナ制限の仕組みを理解したと思いますので次は構築の設計時に注意して欲しいポイントを説明します。
-
フローでガバナ制限を回避するための5つの設計ルール
①ループ内処理の排除（バルク化）
ループ内での「レコードの取得・作成・更新・削除」をやめましょう。ガバナ制限エラーになりやすいのが、ループ内の繰り返しにデータベースの変更要素（更新・削除・新規）を配置することなので、ループ内処理をやめましょう。
必要なデータ取得はループの外で行い、ループ内では割り当て要素を使って一時保存を行い、最終的にループ外で更新処理を行うのが鉄則です。
②起動条件を厳しく設定する
フローのような自動化処理が必要以上に起動するとガバナ制限になりがちです。そもそもフローの自動化処理が起動する回数を少なくしましょう。そのためには、起動化する前提の起動（エントリ）条件を設定（特定の値が項目された場合にのみ起動するなど）することが重要です。そもそもの起動回数を抑えれば、ガバナ制限に引っかかりづらくなります。
③「非同期パス」や「スケジュール済みパス」でトランザクションを分割する
1つのフロー内で実行する処理のステップが多すぎる場合、1トランザクション内の処理上限（CPU時間10,000ミリ秒やSOQL 100回）を超えてしまうことがあります。
非同期パスを設定した上で「レコード保存」や「重い処理（外部API連携や大量のレコード作成）」を切り離し、バックグラウンドで非同期に実行させます。非同期処理にすることで、ガバナ制限のカウント枠が新しくリセットされます。
他にもスケジュール済みパスを設定して実行タイミングを分散させることで、ガバナ制限を回避できる場合もあります。
④プラットフォームイベントトリガーフローを活用する
数千・数万規模のレコードが対象になった場合は、大量データに適した処理を行う必要があります。対象レコードが大規模の場合は、処理を小分けにした上で処理を行うのが推奨です。
親のフローで「プラットフォームイベント」を発行して、親からのイベントを受信した子フローで、データを数件ずつ小分けにして並列・連続で処理すると回避できる場合があります。この構造にすることでイベントが発行されるたびにガバナ制限の枠がもらえるため制限にかからずに処理を行うことも可能になっています。
⑤処理件数が多すぎる場合はApexバッチへの切り替えを検討する
これまでに説明した設計ルールでガバナ制限の回避を狙っても、ノーコードのフローでは限界に行き着く場合があります。その場合はApexバッチの切り替えが推奨です。Apexであれば200件のデータを小分けにしながら非同期処理を行えるため、大量のデータ処理を行うことができます。
-
まとめ
本記事では、Salesforceのガバナ制限の基礎知識から、特にトラブルが起きやすい「フロー」でのガバナ制限回避方法まで解説しました。
エラーの回避は大変なように思えますが、まずは仕組みを理解することが大事です。本記事で説明した設計ルールを参考の上で構築しましょう。
ガバナ制限に対する回避方法や構築方法で不安な点があれば、当社の「Salesforce運用・保守支援サポート」までご相談ください。
