ガバナ制限に当たったときの調べ方（デバッグログ／Limitの見方）
※この記事にはアフィリエイトリンクを含みます。
Contents
はじめに：エラー文だけ見ても、だいたい直せない
UT（単体テスト）やST（結合テスト）で、突然こう言われた経験ありませんか。
- System.LimitException: Too many SOQL queries: 101
- System.LimitException: Too many DML statements: 151
- System.LimitException: Apex CPU time limit exceeded
で、問題はここです。
エラー文は“結果”であって、“原因の場所”は教えてくれません。
だから、現場でやることはシンプルです。
- デバッグログを取る
- CUMULATIVE_LIMIT_USAGE で「何が上限に近いか」を見る
- 例外の直前で「どの処理が食ってるか」を特定する
この記事は、その手順をコピペできる形にしておきます。
まず結論：見る場所は3か所だけ
ログは長いですが、最初はここだけ見ればOKです。
- ① 例外行：System.LimitException / FATAL_ERROR / EXCEPTION_THROWN
- ② 消費内訳：CUMULATIVE_LIMIT_USAGE
- ③ 犯人の処理単位：CODE_UNIT_STARTED（どのトリガ／クラス／フローか）
これで「何が足りないか」と「どこを直すか」が当たりやすくなります。
手順1：デバッグログを取る（最短ルート）
1-1. Setupから取る（おすすめ）
- 設定（Setup）で「デバッグログ」を検索
- 新規（New） を押す
- 対象ユーザ（問題が起きる操作をするユーザ）を選ぶ
- ログレベルを設定して保存
ログレベルは迷ったら、まずこれで始めてOKです（“取りすぎ”より“取れない”が最悪）。
- Apexコード：細かめ（例：FINE 以上）
- データベース：細かめ（例：FINE 以上）
- システム：標準（例：DEBUG）
- その他：標準（例：INFO）
※ログが巨大になって読めない場合は、後で落とします。
参考（公式）：
Monitor Debug Logs（公式）1-2. 再現してログを生成
- 実際にエラーが出る操作を 同じユーザ で実行
- もう一度「デバッグログ」を開き、最新のログをダウンロード（または開く）
手順2：ログの読み方（検索キーワード固定）
ログを開いたら、まずは“検索”でOKです。上から丁寧に読む必要はありません。
2-1. まず例外を探す（犯行声明）
検索キーワード：
- System.LimitException
- FATAL_ERROR
- EXCEPTION_THROWN
ここで「何の上限に当たったか」が確定します。
例：
- Too many SOQL queries → SOQL回数が犯人
- Too many DML statements → DML回数が犯人
- CPU time limit exceeded → CPU時間が犯人
2-2. 次に CUMULATIVE_LIMIT_USAGE を探す（消費の内訳）
検索キーワード：
- CUMULATIVE_LIMIT_USAGE
ここには、代表的な消費状況がまとまって出ます。
“上限に近い数字”が、そのトランザクションで一番危ない箇所です。
見方のコツ：
- SOQL回数が高い → 「ループ内SOQL」や「関係ない場所での追加クエリ」を疑う
- DML回数が高い → 「ループ内DML」や「フロー／プロセスが追加更新」を疑う
- CPUが高い → 「重いループ」「無駄な文字列連結」「大量データの逐次処理」を疑う
2-3. どの処理が食ってるかを特定する（現場で一番大事）
検索キーワード：
- CODE_UNIT_STARTED
- CODE_UNIT_FINISHED
これで「どの単位（トリガ／クラス／フロー）」が動いたかが追えます。
例外の直前に出ている CODE_UNIT_STARTED が“犯人候補”になりやすいです。
代表パターン別：ログでの当たりの付け方
パターンA：SOQL回数（101など）
ログで見る順番：
- System.LimitException: Too many SOQL queries を確認
- CUMULATIVE_LIMIT_USAGE でSOQL回数が高いのを確認
- 例外直前の CODE_UNIT_STARTED を確認
- さらに深掘りするなら SOQL_EXECUTE_BEGIN / SOQL_EXECUTE_END を見る
原因の“型”：
- ループ内でSOQL
- 画面操作1回の裏で、トリガ連鎖＋フロー連鎖でSOQLが積み上がる
パターンB：DML回数（151など）
ログで見る順番：
- Too many DML statements を確認
- CUMULATIVE_LIMIT_USAGE でDML回数が高いのを確認
- DML_BEGIN が大量に出ていないか確認
- 例外直前の CODE_UNIT_STARTED を確認
原因の“型”：
- ループ内でupdate/insert
- 更新が更新を呼ぶ（トリガ／フローの連鎖）
- 「不要な更新（値が変わっていないのにupdate）」が積み上がる
パターンC：CPU時間
ログで見る順番：
- Apex CPU time limit exceeded を確認
- CUMULATIVE_LIMIT_USAGE のCPUが高いことを確認
- 例外直前の CODE_UNIT_STARTED で処理単位を絞る
- METHOD_ENTRY / METHOD_EXIT で重いメソッドを探す（必要なら）
原因の“型”：
- 大量データを同期で逐次処理
- 無駄なループ（ネスト）や、同じ計算を何度もやる
- 文字列連結やMap/Listの作り直しが多い
最後に：ログが読めると、直す場所が迷子にならない
ガバナ制限は「ルール違反」じゃなくて、“資源を食いすぎた場所を特定して直すゲーム”です。
そのために、ログではこの順で見ればOKです。
- 例外 → CUMULATIVE_LIMIT_USAGE → CODE_UNIT_STARTED
ここまでできると、「とりあえずバッチに逃がす」みたいな雑な対処が減って、修正が早くなります。
問い（ここだけ自分に確認）
あなたのログでは、いま一番増えているのは SOQL / DML / CPU のどれでしたか？
