【解決】 Salesforce: Apex trigger too many DML rows の解決方法と原因 | Salesforce/Apex トラブルシューティング

Salesforceをご利用中の皆さん、Apex trigger too many DML rowsというエラーに遭遇し、不安な気持ちでこの記事にたどり着いたかもしれませんね。ご安心ください。このエラーはSalesforce開発においてよくある課題の一つであり、適切な対処法を知っていれば必ず解決できます。この記事では、Windowsユーザーの皆さんがこの問題を迅速かつ恒久的に解決するための具体的な手順を、シニアエンジニアのアシスタントとして、ロジカルかつ分かりやすく解説します。

1. Salesforce: Apex trigger too many DML rows とは？（概要と緊急度）

このエラーは、Salesforceのガバナ制限の一つである「単一トランザクション内でのDML操作（Insert、Update、Delete、Upsert）の行数制限（10,000行）」を超過したことを意味します。Salesforceはマルチテナント環境であり、すべてのユーザーが安定してサービスを利用できるよう、各トランザクションに厳しい制限を設けています。この制限を超えると、処理は中断され、このエラーが発生します。

緊急度: 高

このエラーが発生すると、期待されるビジネスプロセスが完了せず、データの不整合やユーザーの業務停止につながる可能性があります。そのため、迅速な対応が求められます。

2. 【最速】今すぐ試すべき解決策

このエラーの根本的な解決にはApexコードの修正が必要ですが、まずはWindows環境で開発作業を進めるための準備と、一時的な応急処置、そして恒久的な解決策の方向性を示します。

解決策1：[最も簡単な方法] 開発環境を整え、Batch Apexへの移行を検討する

Apex trigger too many DML rowsエラーは、コードの設計に起因するため、残念ながらWindowsのコマンドプロンプトやPowerShellから直接エラーを解消するコマンドは存在しません。しかし、Windows環境でSalesforceのApexコードを効率的に修正・デプロイするための「開発環境のセットアップ」が、解決への第一歩となります。

具体的なWindowsコマンドまたは手順：

以下の手順で開発環境を整え、既存のApexトリガーやクラスをBatch Apexに移行する準備を始めましょう。

1. 1. Salesforce CLIのインストール: Salesforce CLI (Command Line Interface) は、Salesforce組織とローカル環境の間でメタデータを操作するための強力なツールです。

# まずはSalesforce CLIのインストーラーをダウンロードします。
# 公式サイト: https://developer.salesforce.com/tools/salesforcecli
# ダウンロード後、インストーラーを実行し、指示に従ってインストールを完了します。
# インストールが完了したら、バージョン確認コマンドを実行します。
sf --version
        

1. 1. Visual Studio Code (VS Code) とSalesforce Extension Packのインストール: VS CodeはSalesforce開発で最も広く使われているエディタです。

# 1. VS Codeをダウンロードしてインストールします。
# 公式サイト: https://code.visualstudio.com/download

# 2. VS Codeを開き、拡張機能ビュー (Ctrl+Shift+X) を開きます。
# 検索バーに "Salesforce Extension Pack" と入力し、インストールします。
# このパックには、Apex、Lightning Web Components、Visualforceなどの開発に必要な拡張機能が含まれています。
        

1. 1. Salesforceプロジェクトの作成と組織への認証: ローカルにSalesforceプロジェクトを作成し、作業対象のSalesforce組織に接続します。

# VS Codeでコマンドパレット (Ctrl+Shift+P) を開き、「SFDX: Create Project with Manifest」を選択します。
# プロジェクト名を入力し、任意の場所に保存します。

# 次に、Salesforce組織への認証を行います。コマンドパレットで「SFDX: Authorize an Org」を選択します。
# プロジェクトのデフォルトとする組織タイプ（例: Production, Sandbox, Dev Hub）を選択し、別名を入力します。
# ブラウザが開き、Salesforceログインページにリダイレクトされるので、資格情報を入力してログインします。
        

1. 1. 既存のApexコードをローカルに取得: エラーの原因となっているApexトリガーやクラスをローカルプロジェクトに取得します。

# VS CodeのExplorerビューで「manifest/package.xml」を開き、
# <types>タグ内に問題のApexTriggerやApexClassの定義を追加します。
# 例:
# <types>
#     <members>MyProblematicTrigger</members>
#     <name>ApexTrigger</name>
# </types>
# <types>
#     <members>MyProblematicClass</members>
#     <name>ApexClass</name>
# </types>

# コマンドパレットで「SFDX: Retrieve Source from Org」を選択し、メタデータを取得します。
# これで、ローカルでコードの修正に取り掛かる準備ができました。
        

この環境を整えた上で、次の「恒久的に再発を防ぐには」の章を参考に、Batch Apexへの移行を計画・実行してください。これが最も堅牢な解決策となります。

3. Salesforce: Apex trigger too many DML rows が発生する主要な原因（複数）

このエラーは通常、以下の原因によって引き起こされます。

1. 1. • ガバナ制限の超過: Salesforceが設定しているDML操作の行数制限（10,000行）を、単一のトランザクション内で超えてしまうことが直接的な原因です。
      • 非効率なApexコード:
        • ループ内でのDML操作: forループやwhileループの中でinsert, update, deleteなどのDMLステートメントを実行している場合、ループの繰り返し回数が増えると容易に制限を超過します。これは「N+1問題」とも呼ばれます。
        • トリガーの連鎖と再帰: あるオブジェクトのトリガーが別のオブジェクトのレコードを更新し、それがさらに別のトリガーを呼び出す、といった連鎖的な処理が発生している場合。また、意図しないトリガーの再帰呼び出しも原因となり得ます。
        • 同期処理での大量データ処理: 大量のレコード（例: データインポート、一括更新）を同期的に処理しようとするApexクラスやトリガーが実行された場合。
      • 未最適化なSOQLクエリ: DML操作の前に大量のレコードを不必要に取得している場合、メモリ制限やCPU時間制限にも影響を及ぼし、結果的にDML操作の対象行数を増やすことにつながります。
      • 大量のテストデータ: テストクラスの実行時に、過剰なテストデータがDML操作の対象となり、エラーを引き起こす場合があります。

4. Salesforce/Apexで恒久的に再発を防ぐには

Apex trigger too many DML rowsエラーの再発を防ぎ、安定したSalesforce運用を実現するためには、以下の設計原則とベストプラクティスを遵守することが不可欠です。

4.1. 大量データ処理はBatch Apexに移行する

これが最も重要かつ直接的な解決策です。Batch Apexは、大量のレコードを小さなチャンク（バッチ）に分割し、それぞれ独立したトランザクションとして処理することで、ガバナ制限の超過を防ぎます。特に10,000行を超える可能性のあるDML操作には必須のパターンです。

1. 1. • Database.Batchable<SObject>インターフェースを実装し、start, execute, finishメソッドで処理を定義します。
      • executeメソッド内で、各バッチ（デフォルト200レコード）ごとにDML操作を実行します。

4.2. Apexコードのバルク化（Bulkification）

DML操作は必ずループの外で行うようにコードをリファクタリングします。

1. 1. • リストの活用: 変更対象のレコードをリストに収集し、ループ終了後に一度のDMLステートメントでリスト全体を処理します。
      • マップの活用: 関連レコードの取得や更新には、SOQLのIN句やマップを効果的に使用し、クエリやDML操作の数を最小限に抑えます。

// 悪い例: ループ内でDML
for (Account acc : newAccounts) {
    insert acc; // DMLが発生するたびにガバナ制限を消費
}

// 良い例: バルク化されたDML
List<Account> accountsToInsert = new List<Account>();
for (Account acc : newAccounts) {
    accountsToInsert.add(acc);
}
if (!accountsToInsert.isEmpty()) {
    insert accountsToInsert; // 一度のDMLでリスト全体を処理
}
    

4.3. 非同期処理の活用（@future, Queueable Apex）

即時性を要求されない複雑な処理や、外部システムとの連携など、時間のかかる処理は非同期的に実行することを検討します。

1. 1. • @futureメソッド: 別のトランザクションで処理を実行します。コールアウトや異なるガバナ制限で処理を行いたい場合に有用です。
      • Queueable Apex: @futureメソッドよりも柔軟性が高く、ジョブのチェインやSObject以外の型を渡すことができます。

4.4. トリガーハンドラーパターンの採用

トリガーロジックをApexクラスに分離（トリガーハンドラーパターン）することで、コードの可読性、保守性、テスト容易性が向上し、トリガーの複雑さを管理しやすくなります。これにより、意図しないDMLの連鎖や再帰を防ぎやすくなります。

4.5. ガバナ制限の意識とデバッグ

常にSalesforceのガバナ制限を意識したコーディングを心がけましょう。開発中はデバッグログを積極的に活用し、処理されるDML行数やSOQLクエリ数などを監視します。

1. 1. • Limitsクラス: Apexの現在のガバナ制限の使用状況をプログラム的に確認できます。
      • デバッグログの確認: デバッグログの「LIMITS」セクションで、DMLステートメントの回数や行数を確認できます。

これらの対策を講じることで、Apex trigger too many DML rowsエラーの発生を大幅に減らし、より堅牢でスケーラブルなSalesforceアプリケーションを構築することができます。