Batch ApexによるSalesforce一括取引先管理のマスター

背景と応用シナリオ

Salesforce 開発者として、私たちは日々、データの操作とプロセスの自動化に取り組んでいます。特に、企業の根幹をなす「取引先 (Account)」オブジェクトの管理は、ビジネスの成功に直結する重要なタスクです。しかし、組織が成長し、データが蓄積されるにつれて、何万、何百万もの取引先レコードを一括で処理する必要性に迫られることがあります。

例えば、以下のようなシナリオを考えてみましょう。

データクレンジング： 全ての取引先レコードの「請求先住所（都道府県）」を標準化する。
データのエンリッチメント： 外部の企業情報データベースと連携し、全取引先の業種や従業員数データを更新する。
アーカイブ： 過去3年間、関連する商談や活動がない非アクティブな取引先を特定し、「アーカイブ済み」フラグを立てる。
複雑な再計算： 取引先に関連する全てのカスタムオブジェクトの数値を集計し、取引先レコードのカスタム項目に反映させる。これは標準の積み上げ集計項目では対応できないロジックです。

これらのタスクを、データローダを使った手動操作や、同期的な Apex (同期Apex) トリガー、あるいは単一のトランザクションで実行しようとすると、Salesforce の Governor Limits (ガバナ制限) に直面します。特に、一度にクエリできるレコード数 (SOQL Query Rows: 50,000) や DML 操作ができるレコード数 (DML Rows: 10,000)、CPU 処理時間 (CPU Time: 10,000ms) などの制限は、大規模データ処理において大きな障壁となります。

この課題を解決するために Salesforce が提供しているのが、Asynchronous Apex (非同期Apex) の一つである Batch Apex (バッチApex) です。Batch Apex を利用することで、開発者は大量のレコードを小さなチャンク（バッチ）に分割し、ガバナ制限を回避しながら効率的かつ確実に処理する堅牢なソリューションを構築できます。この記事では、Salesforce 開発者の視点から、Batch Apex を用いた取引先管理の原理と実践的な手法を解説します。

原理説明

Batch Apex は、`Database.Batchable` インターフェースを実装することで機能します。このインターフェースには、バッチ処理のライフサイクルを定義する3つの主要なメソッドが含まれています。

1. `start` メソッド

バッチジョブの最初に一度だけ呼び出されます。このメソッドの役割は、処理対象となる全てのレコードを特定し、その集合を返すことです。戻り値は `Database.QueryLocator` または `Iterable` オブジェクトです。
`Database.QueryLocator` を使用するのが一般的で、最大5,000万件のレコードを取得できる SOQL クエリの結果を保持します。これは、`start` メソッド自体のヒープサイズ制限を気にすることなく、非常に大きなデータセットを効率的に処理するための最良の方法です。

2. `execute` メソッド

`start` メソッドが返したレコードの集合を、指定されたサイズのチャンク（デフォルトは200件）に分割し、チャンクごとにこのメソッドが呼び出されます。実際のデータ処理ロジック（取引先項目の更新、関連レコードの作成など）は、このメソッド内に記述します。
重要なのは、`execute` メソッドが実行されるたびに、ガバナ制限がリセットされるという点です。これにより、トランザクション全体でガバナ制限に達することなく、膨大な数のレコードを処理できます。

3. `finish` メソッド

全てのバッチ（チャンク）の処理が完了した後に、一度だけ呼び出されます。このメソッドは、後処理タスクを実行するのに適しています。例えば、処理結果をまとめたメールを管理者に送信したり、別のバッチジョブをチェーン（連鎖）させて起動したりするなどの処理をここで行います。

また、`execute` メソッドをまたいで情報を保持したい場合（例えば、処理したレコードの総数をカウントするなど）は、`Database.Stateful` インターフェースをクラス宣言に追加で実装します。これにより、クラスのメンバー変数の値が各トランザクション間で維持されるようになります。

示例代码

ここでは、Salesforce の公式ドキュメントにある例を基に、特定の条件に合致する全ての取引先レコードの項目を更新する Batch Apex クラスを作成します。この例では、`Description` 項目を更新し、関連する納入商品を更新する、というシナリオを想定しています。

global class UpdateAccountFields implements Database.Batchable<sObject> {

    // バッチジョブ全体で共有したい情報（この例ではSOQLクエリ）を保持するメンバー変数
    global final String query;

    // コンストラクタ: バッチクラスのインスタンス化時にSOQLクエリを受け取る
    global UpdateAccountFields(String q) {
        query = q;
    }

    // 1. startメソッド: 処理対象のレコードを返す
    // Database.BatchableContext は、ジョブIDなどのコンテキスト情報を提供
    global Database.QueryLocator start(Database.BatchableContext BC) {
        // コンストラクタで受け取ったクエリを実行し、QueryLocatorを返す
        // これにより、大量のデータを効率的に処理できる
        return Database.getQueryLocator(query);
    }

    // 2. executeメソッド: 各バッチのレコードを処理する
    // Database.BatchableContext と、処理対象レコードのリスト(scope)を引数として受け取る
    global void execute(Database.BatchableContext BC, List<Account> scope) {
        // 更新対象の取引先を格納するリストを初期化
        List<Account> accountsToUpdate = new List<Account>();
        
        // scope内の各取引先をループ処理
        for (Account acc : scope) {
            // Description項目を更新
            acc.Description = 'Batch processed on ' + System.now();
            accountsToUpdate.add(acc);
        }

        // DML操作はループの外で一括実行するのがベストプラクティス
        // allOrNoneがfalseに設定されているため、一部のレコードでエラーが発生しても
        // 他の成功したレコードはコミットされる（部分成功）
        Database.SaveResult[] srList = Database.update(accountsToUpdate, false);

        // エラー処理の例: DML操作の結果をチェック
        for (Database.SaveResult sr : srList) {
            if (!sr.isSuccess()) {
                // Get the first error
                Database.Error err = sr.getErrors()[0];
                System.debug('The following error has occurred.');
                System.debug(err.getStatusCode() + ': ' + err.getMessage());
                System.debug('Account fields that affected this error: ' + err.getFields());
            }
        }
    }

    // 3. finishメソッド: 全てのバッチ処理完了後に実行される
    // Database.BatchableContext を引数として受け取る
    global void finish(Database.BatchableContext BC) {
        // ジョブのステータスを確認するために非同期Apexジョブの情報を取得
        AsyncApexJob a = [SELECT Id, Status, NumberOfErrors, JobItemsProcessed,
                          TotalJobItems, CreatedBy.Email
                          FROM AsyncApexJob WHERE Id = :BC.getJobId()];

        // ここで処理完了の通知メールを送信するなどの後処理を実装できる
        System.debug('Batch Job Finished. Status: ' + a.Status + ', Processed: ' + a.JobItemsProcessed + ', Errors: ' + a.NumberOfErrors);
    }
}

この Batch Apex を実行するには、開発者コンソールの匿名実行ウィンドウなどで以下のコードを実行します。

// バッチクラスのインスタンスを作成し、処理対象を定義するSOQLクエリを渡す
// ここでは全ての取引先を対象としているが、実際にはWHERE句で絞り込むことが推奨される
String soqlQuery = 'SELECT Id, Name, Description FROM Account';

// Database.executeBatchを呼び出してジョブを開始
// 第2引数はオプションで、executeメソッドに渡されるバッチサイズを指定する
// 指定しない場合のデフォルトは200
// ロジックが複雑でCPU時間制限に抵触しやすい場合は、この値を小さく設定する
Id batchJobId = Database.executeBatch(new UpdateAccountFields(soqlQuery), 100);

// batchJobId を使って、[設定] > [ジョブ] > [Apex ジョブ] から進捗を確認できる
System.debug('Batch job started with Id: ' + batchJobId);

注意事項

権限と共有設定

Batch Apex は、ジョブを開始したユーザーのコンテキストで実行されます。つまり、そのユーザーがアクセスできないレコードや項目は、バッチジョブ内でもアクセスできません。Field-Level Security (項目レベルセキュリティ) や共有ルールが適用されるため、意図したレコードが正しく処理されるよう、適切な権限を持つユーザーで実行するか、`without sharing` キーワードをクラス宣言に追加して共有設定を無視するかを慎重に判断する必要があります。

ガバナ制限

前述の通り、`execute` メソッドごとにガバナ制限はリセットされますが、無制限ではありません。1回の `execute` トランザクション内で、SOQLクエリの発行回数（100回）やヒープサイズ（6MB）などの制限は依然として存在します。`execute` メソッド内のロジックが複雑になりすぎないように注意が必要です。また、組織全体で同時に実行できるアクティブなバッチジョブの数には上限（通常は5つ）があるため、ジョブのスケジューリングには注意が必要です。

エラー処理

大量のデータを扱う際、一部のレコードで予期せぬエラー（入力規則違反、必須項目がnullなど）が発生する可能性があります。`execute` メソッド内で `try-catch` ブロックを使用し、エラーが発生してもジョブ全体が停止しないように設計することが不可欠です。`Database.update(records, false)` のように、DML操作の第2引数を `false` に設定することで、部分的な成功を許容できます。`Database.SaveResult` オブジェクトをループ処理し、失敗したレコードのIDとエラーメッセージをカスタムオブジェクトやログに記録することで、後の追跡調査が容易になります。

テスト

Asynchronous Apex のテストは必須であり、少し特殊なアプローチが必要です。テストメソッド内で `Test.startTest()` と `Test.stopTest()` を使用します。この2つのメソッドの間に Batch Apex の実行コード (`Database.executeBatch`) を記述します。`Test.stopTest()` が呼び出されると、システムは非同期プロセスが完了するのを待ち、同期的に実行します。これにより、`Test.stopTest()` の後で、バッチ処理の結果（レコードが正しく更新されたかなど）を `System.assertEquals()` を使って検証できます。

まとめとベストプラクティス

Batch Apex は、Salesforce プラットフォーム上で大規模な取引先データを管理するための、開発者にとって最も強力なツールの一つです。ガバナ制限の制約をインテリジェントに回避し、信頼性の高いデータ処理を実現します。

取引先管理で Batch Apex を最大限に活用するためのベストプラクティスを以下にまとめます。

セレクティブな SOQL クエリ： `start` メソッドで使用するクエリには、必ずインデックスが設定された項目（ID、Name、外部IDなど）を `WHERE` 句に含め、処理対象をできるだけ絞り込みます。これにより、クエリのパフォーマンスが向上します。
適切なバッチサイズ： `execute` メソッドのロジックが複雑で、CPU 時間やヒープメモリを多く消費する場合は、`Database.executeBatch` の第2引数でバッチサイズをデフォルトの200より小さく設定します。逆に、ロジックが単純な場合はサイズを大きくすることで、全体の処理時間を短縮できる可能性があります。
状態の管理は慎重に： `Database.Stateful` は便利ですが、バッチジョブの実行状態をシリアライズおよびデシリアライズする必要があるため、パフォーマンスに若干の影響を与えます。合計値のカウントなど、本当に必要な場合にのみ使用してください。
べき等性（Idempotency）の確保： ネットワークの問題などでジョブが中断し、再実行が必要になるケースを想定します。バッチロジックは、同じデータに対して複数回実行されても、常に同じ結果になるように（べき等に）設計することが理想です。例えば、既に処理済みのフラグが立っているレコードはスキップするなどの制御を入れます。
堅牢なロギングと通知： `finish` メソッドやエラー処理ブロックを活用し、ジョブの成功・失敗、処理件数、エラー内容などをカスタムオブジェクトやメール通知で記録します。これにより、運用開始後のモニタリングとトラブルシューティングが格段に容易になります。

Salesforce 開発者として Batch Apex を習得することは、スケーラブルで保守性の高いソリューションを構築するための重要なスキルです。本記事で解説した原理とベストプラクティスを参考に、日々の取引先データ管理業務をより効率的かつ自動化されたものにしていきましょう。

にゃんこのSalesforce日記

このブログを検索