Salesforceのガバナ制限完全ガイド：システム安定性を保つための実践的アプローチ

Salesforce

2025.04.10

1. ガバナ制限の基礎知識
2. 主要なガバナ制限とその影響
2.1 Apexコードの実行時間制限
2.2 データベースアクセスの制限
2.3 API制限とその影響
2.4 自動化プロセスの制限
3. 実践的な対処方法と設計のベストプラクティス
3.1 バルク処理による効率化
3.2 メモリ使用量の最適化
3.3 非同期処理の活用
3.4 予防的なモニタリング体制
3.5 開発時のベストプラクティス
4. まとめ：ガバナ制限との上手な付き合い方
4.1 日々の運用に活かすポイント
4.2 継続的な改善のために

日々のSalesforce運用の中で、突然「ガバナ制限に達しました」というエラーメッセージに遭遇した経験はありませんか？

データ量が増えるにつれて処理が遅くなったり、バッチ処理が途中で止まったりする問題に頭を悩ませているシステム管理者も多いのではないでしょうか。
この記事では、Salesforceのガバナ制限について、実務経験に基づいた具体的な説明と対処方法をお伝えします。システムの安定性を保ちながら、ユーザーの期待に応えるための実践的なアプローチを、順を追って解説していきます。

ガバナ制限の基礎知識

あるシステム管理者から相談を受けたことがあります。「データ量が増えてきたら、今まで問題なく動いていた処理が突然エラーになり始めました」。これは、多くのSalesforce管理者が経験する悩みの一つです。

この問題を理解するために、まずSalesforceのマルチテナント環境について見ていきましょう。Salesforceは、一つのサーバー環境を複数の企業で共有しています。たとえば、同じ建物の各フロアを異なる会社が使用しているようなものです。
このような環境で、ある企業が大量のデータ処理を行うと、建物のエレベーターを一社が長時間占有しているような状態が生まれます。そこで、Salesforceはガバナ制限という形でリソースの利用に一定のルールを設けています。

ガバナ制限が設定される主な対象は以下の三つです。
まず、データベースへのアクセスです。たとえば、商談データを一度に1万件以上取得しようとすると、制限にかかる場合があります。これは、図書館で一度に借りられる本の数に制限があるのと似ています。

次に、プログラムの実行時間です。Apexと呼ばれるプログラムが、10秒以上の処理を行おうとすると制限がかかります。これは、共有の会議室の使用時間に制限があるようなものです。

そして、API呼び出しの回数です。外部システムとのデータのやり取りには、1日あたりの回数制限があります。駐車場の1日の出入り回数に制限があるようなイメージです。

これらの制限は、一見すると不便に感じるかもしれません。しかし、この仕組みがあることで、一部のユーザーの過度な負荷がシステム全体に影響を与えることを防いでいます。たとえば、休日の大量データ更新作業が、平日の通常業務に影響を与えないようにする役割を果たしています。
また、これらの制限は、より効率的なプログラムの作成を促す指針にもなります。制限に配慮して設計されたプログラムは、結果として処理速度が速く、安定性の高いものになることが多いのです。

「ガバナ制限の基礎知識」のまとめとして、ガバナ制限は「制約」ではなく「ガイドライン」として捉えることが大切です。次章では、これらの制限に具体的にどう対応していくのか、実践的な方法を見ていきましょう。

主要なガバナ制限とその影響

前章では、ガバナ制限の基本的な考え方を見てきました。この章では、日々の運用で特に注意が必要な制限について、具体的な事例を交えながら詳しく見ていきましょう。

Apexコードの実行時間制限

開発者からよく聞く声に「テスト環境では問題なく動いていたのに、本番環境でタイムアウトが発生した」というものがあります。これは、Apexコードの実行時間制限に関係しています。

同期処理の場合、一つの処理に許される時間は10秒です。たとえば、取引先の住所を一括で更新するプログラムを考えてみましょう。


for(Account acc : accounts) {
    // 住所情報の更新処理
    // 外部サービスの呼び出しを含む
    // この処理が1レコードあたり0.1秒かかると仮定
}

このプログラムは100件程度のデータでは問題なく動作しますが、1,000件を超えると実行時間制限を超過する可能性が出てきます。

データベースアクセスの制限

次に目にする機会が多いのが、SOQLクエリの制限です。一回のトランザクションで実行できるSOQLクエリの数は100回までです。

以下のようなコードでよく問題が発生します。


for(Account acc : accounts) {
    // 各取引先に紐づく取引先責任者を取得
    List contacts = [SELECT Id FROM Contact WERΕ AccountId = :acc.Id];
    // この方法だと取引先の数だけクエリが実行される
}

このような処理は、取引先が50件であれば問題ありませんが、200件あると制限を超過してしまいます。

API制限とその影響

外部システムとの連携で注意が必要なのが、API制限です。たとえば、ECサイトとSalesforceを連携させている場合、注文データの同期で以下のような状況が発生することがあります。

24時間あたりのAPI呼び出し回数制限
1回あたりのペイロードサイズ制限
同時実行数の制限

特に月末の受注が集中する時期には、API制限に達してシステム連携が停止するというトラブルが起きやすくなります。

自動化プロセスの制限

フロー、プロセスビルダー、ワークフローなどの自動化ツールにも制限があります。一つのトランザクションで実行できるフローの数や、クロスオブジェクト参照の深さには上限があります。
たとえば、商談が成立したときに、以下の一連の自動処理を設定しているとします。

取引先の状況を更新
関連する案件の状況も更新
営業担当者にメール通知
売上データを集計

このような連鎖的な処理は、制限値に達しやすく、途中で処理が止まってしまうことがあります。
これらの制限は、一見すると厳しく感じるかもしれません。しかし、次章で説明する適切な設計と実装方法を採用することで、ほとんどの場合、制限に抵触することなく必要な処理を実現できます。
それでは、次章では具体的な対処方法とベストプラクティスについて見ていきましょう。

実践的な対処方法と設計のベストプラクティス

前章では具体的なガバナ制限とその影響について見てきました。この章では、実際の開発や運用で活用できる対処方法について、具体的な実装例を交えながら説明していきます。

バルク処理による効率化

まず、最も重要な対策の一つが、バルク処理の実装です。先ほどの取引先責任者を取得する例を、バルク処理で書き直してみましょう。


// 非効率な方法
for(Account acc : accounts) {
    List contacts = [SELECT Id FROM Contact 
                            WHERΕ AccountId = :acc.Id];
}

// バルク処理による効率的な方法
List contacts = [SELECT Id, AccountId 
                         FROM Contact 
                         WHERΕ AccountId IN :accounts];

この改善により、クエリ回数を大幅に削減でき、処理速度も向上します。

メモリ使用量の最適化

大量のレコードを処理する際は、メモリ使用量にも注意が必要です。以下のような方法で、メモリ使用を効率化できます。


public void processLargeData() {
    // 一度に処理するレコード数を制限
    Integer batchSize = 200;
    
    for (List batch : [SELECT Id, Name 
                               FROM Account 
                               WHERΕ LastModifiedDate = TODAY]) {
        // バッチ単位で処理
        updateAccounts(batch);
    }
}

非同期処理の活用

処理時間が長くなる可能性がある場合は、非同期処理の実装を検討します。特に、以下のような場合に効果的です。

大量データの一括更新
外部システムとの連携処理
レポートデータの集計処理

public class AccountUpdateBatch implements Database.Batchable {
public Database.QueryLocator start(Database.BatchableContext bc) {
return Database.getQueryLocator(
‘SELECT Id, Name FROM Account WHERΕ LastModifiedDate = TODAY’
);
}
public void execute(Database.BatchableContext bc, List scope) {
// バッチサイズ単位での処理
updateAccounts(scope);
}

public void finish(Database.BatchableContext bc) {
// 処理完了時の通知など
}
}

予防的なモニタリング体制

問題が発生してからの対応ではなく、予防的な監視体制を整えることも重要です。以下のような項目を定期的に確認します。

API使用状況の監視
クエリ実行時間のトレンド分析
バッチ処理の実行時間推移

開発時のベストプラクティス

最後に、開発時に心がけるべきポイントをまとめます。

テストデータの準備

　　● 本番環境に近い量のテストデータを用意
　　● 極端なケースも含めた検証

コードレビューのポイント

　　● ループ内のクエリの有無
　　● バルク処理の実装確認
　　● 例外処理の確認

パフォーマンステスト

　　● 大量データでの動作確認
　　● 制限値への近接度チェック
　　● 実行時間の測定

これらの対策は、個別に実施するのではなく、総合的に組み合わせることで最大の効果を発揮します。
また、新機能の追加や既存機能の改修時には、必ずガバナ制限の観点からのレビューを行うことをお勧めします。

まとめ：ガバナ制限との上手な付き合い方

これまで見てきたように、ガバナ制限は制約ではなく、より良いシステム開発への指針として捉えることができます。ここで、本記事の重要なポイントを整理しておきましょう。

日々の運用に活かすポイント

ガバナ制限への対応は、決して難しいものではありません。むしろ、以下のような考え方で日々の運用に組み込んでいくことで、自然とシステムの質を高めることができます。
まず、新しい機能を実装する際は、小規模なデータでテストするだけでなく、将来的なデータ量の増加を見据えた設計を心がけましょう。たとえば、毎月1,000件ずつデータが増えていく環境であれば、1年後には12,000件のデータに対して処理が実行されることになります。

次に、定期的なシステムの健康診断を実施することをお勧めします。特に以下の点に注目して確認を行います。

バッチ処理の実行時間推移
API使用量の傾向
エラーログの発生パターン

これらの情報は、将来的な問題を予測し、事前に対策を講じる重要な指標となります。

継続的な改善のために

システムは生き物のように日々変化していきます。そのため、定期的な見直しと改善のサイクルを確立することが大切です。
特に気をつけたいのは、次のような状況です。

処理時間が徐々に長くなってきている
特定の時間帯にエラーが増える
ユーザーから「遅くなった」という声が出始めている

これらの兆候は、ガバナ制限に関連する問題が潜んでいるシグナルかもしれません。早めの対応が、大きなトラブルを防ぐことにつながります。

ガバナ制限は、Salesforceシステムを安定的に運用するための重要な要素です。制限に対する正しい理解と適切な対応により、より信頼性の高いシステムを構築することができます。

本記事で紹介した方法は、あくまでも基本的なアプローチです。実際の現場では、それぞれの環境や要件に応じて、適切なアプローチを選択していく必要があります。
システムの成長に合わせて、継続的に見直しと改善を行っていくことで、ユーザーにとって使いやすく、管理者にとって運用しやすいシステムを維持することができるでしょう。

＜Salesforce＞
弊社ではSalesforceをはじめとするさまざまな無料オンラインセミナーを実施しています！
＞＞セミナー一覧はこちら

また、弊社ではSalesforceの導入支援のサポートも行っています。ぜひお気軽にお問い合わせください。
＞＞Salesforceについての詳細はこちら
＞＞Salesforceの導入支援実績はこちらからご覧いただけます！

医療業界に特化した営業支援、顧客管理(SFA/CRM)のコンサルティングも提供しております。こちらもぜひお気軽にお問い合わせください。
＞＞顧客管理(SFA/CRM)のコンサルティングの詳細はこちら

ブログ