【Salesforce】ガバナ制限が厄介すぎるので、現場で困るポイントごとにまとめた
※この記事にはアフィリエイトリンクを含みます。
Contents
はじめに：UT/STで突然死するやつ
Salesforce開発で避けて通れないのが『ガバナ制限』です。
これに引っかかると、UT（単体テスト）やST（結合テスト）で突然こうなります。
- 途中まで処理したのに、例外で止まって全部ロールバック
- ユーザーはエラー画面で作業中断、手戻り発生
- 直しは「設計からやり直し」になりがち（地味に痛い）
で、問題はここです。
開発中は「ルール守ればいい」になりやすいけど、なぜルールがあるかを腹落ちしてないと、いざ詰んだ時に対処が遅れます。
この記事は「ガバナ制限って何？」「どこで事故る？」「どう直す？」を、現場の事故ポイント順に整理します。
ガバナ制限とは？
ガバナ制限は、Salesforceがプラットフォーム全体の安定性を保つために設けている
『1トランザクションあたりの資源使用上限』です。
要は、みんなで使う大きな遊び場で、一人が使いすぎて全体を止めないためのお約束です。
（ブランコを1人で独占したら、他の人が遊べないのと同じ）
まず押さえる：よく事故る代表3つ
ここだけ先に覚えておけば、事故の8割は避けられます。
1) SOQL（検索）の回数・件数
- 1トランザクションで実行できるSOQL回数に上限がある
- 1回のSOQLで返せる件数にも上限がある（大量データで事故）
2) DML（登録・更新・削除）の回数・件数
- insert / update / delete の実行回数に上限がある
- 1回で処理できるレコード数にも上限がある
3) CPU時間（Apexの実行時間）
- 1トランザクション内でのApex実行時間に上限がある
- 「処理が重い」「ループが多い」「無駄が多い」で刺さる
※上限値は実行条件（同期／非同期など）で変わるので、数字は“暗記”よりも「どれが危ないか」を優先してください。
典型的にやらかす：ループの中でSOQL/DML
▼ガバナ制限に抵触しやすいコード（悪い例）
for (Account a : [SELECT Id, Industry FROM Account LIMIT 150]) {
if (a.Industry == 'Technology') {
a.Is_Tech__c = true;
}
// ループ内でDML
update a;
}
これ、見た目はシンプルなんですが、「ループ＝回数が増える場所」にDMLを置いているのがアウトです。
データが増えた瞬間に上限へ一直線になります。
直し方：まとめて取る／まとめて更新する（基本形）
▼ガバナ制限に抵触しにくいコード（良い例）
List<Account> accountList = [
SELECT Id, Industry, Is_Tech__c
FROM Account
LIMIT 150
];
List<Account> accountsToUpdate = new List<Account>();
for (Account a : accountList) {
if (a.Industry == 'Technology') {
a.Is_Tech__c = true;
accountsToUpdate.add(a);
}
}
if (!accountsToUpdate.isEmpty()) {
update accountsToUpdate;
}
ポイントは2つだけです。
- 検索（SOQL）は1回でまとめる
- 更新（DML）は1回でまとめる
これがいわゆる「一括処理（バルク処理）」の基本です。
「じゃあ何が問題なの？」を現場目線で整理
ガバナ制限に抵触すると、単にエラーになるだけじゃなく、周りに被害が出ます。
1) トランザクションが失敗してロールバック
例外が出た瞬間に処理が止まり、そのトランザクション内の更新が全部なかったことになります。
結果として「更新されたはずがされてない」事故が起きます。
2) ユーザー体験が悪化する
ユーザーはエラー画面で止まり、業務が中断します。
「何回もやり直す」「別の人に依頼し直す」みたいな手戻りが出ます。
3) パフォーマンスと運用コストが上がる
制限に当たらないように処理を分割したり、非同期に逃がしたりで、設計が複雑になります。
テストと障害調査も難しくなります。
4) スケールしない
少量データでは動くのに、データが増えると死ぬ。
このタイプは、後から直すほど痛いです。
事故を減らす「現場のチェックリスト」
実装レビューや自分のセルフチェックにそのまま使えます。
- ループの中で SOQL / DML / callout をしていないか
- 取得対象は本当に必要な項目だけか（不要項目の取りすぎで重くなる）
- 更新はまとめて1回でできないか
- 大量データが来た時の動き（件数増加）を想像できているか
- 重い処理を同期でやっていないか（必要なら非同期へ）
まとめ：ガバナ制限は「チーム全体の事故」を防ぐためのルール
ガバナ制限に抵触すると、トランザクション失敗・ロールバック・ユーザー停止が起きます。
だからこそ、開発では「ループの中に危険物（SOQL/DML）を置かない」「まとめて処理する」を基本にして、事故を未然に防ぐのが大事です。
昔の自分は「守ればいいルール」くらいの理解でしたが、立場が変わって見直すと、これって“自分だけの問題じゃなくて、チーム全体に迷惑が波及する”ルールなんですよね。
学び直し、大事です。
では、また次の記事で。
