Salesforce Apexを活用したカスタムロイヤルティプログラムの構築：開発者向けガイド

背景と応用シナリオ

現代のビジネス環境において、顧客との長期的な関係を築き、そのエンゲージメントを高めることは成功の鍵です。Loyalty Program (ロイヤルティプログラム) は、顧客の継続的な購買や利用を促進し、ブランドへの忠誠心を高めるための強力なマーケティング戦略です。Salesforceをプラットフォームとして活用することで、顧客情報、購買履歴、サポートケースなど、あらゆる顧客接点を一元管理し、それらのデータに基づいたパーソナライズされたロイヤルティプログラムを設計・実行することが可能になります。

例えば、以下のような応用シナリオが考えられます：

小売業： 購買金額に応じてポイントを付与し、貯まったポイントを割引や特典商品と交換できるようにする。
B2Bサービス業： 契約更新やアップセル、紹介など特定のアクションに対してリワードを提供し、顧客とのパートナーシップを強化する。
サブスクリプションビジネス： 継続利用期間に応じて会員ランクを設け、上位ランクの顧客には特別なコンテンツへのアクセス権や先行サービス利用権を提供する。

Salesforce上でカスタムのロイヤルティプログラムを構築することにより、標準のCRMデータとロイヤルティデータをシームレスに連携させ、Customer 360 (顧客360度ビュー) の実現をさらに推し進めることができます。本記事では、Salesforce 開発者の視点から、Apex (エイペックス) を用いてスケーラブルで柔軟なカスタムロイヤルティプログラムの根幹となるロジックを実装する方法について解説します。

原理説明

カスタムロイヤルティプログラムを構築する際、その中核となるのは「いつ、誰に、どれくらいのポイントを付与するか」というビジネスロジックです。Salesforceプラットフォームでは、このロジックを実装するために宣言的なツール（Flowなど）とプログラム的なツール（Apex）を組み合わせるのが一般的です。

データモデルの設計

まず、ロイヤルティプログラムの情報を格納するためのData Model (データモデル) を設計します。最低限、以下の3つのカスタムオブジェクトが必要になるでしょう。

Loyalty_Member__c: ロイヤルティプログラムの会員情報を格納するオブジェクト。取引先責任者(Contact)や個人取引先(Person Account)への参照関係を持つことで、既存の顧客データと紐付けます。会員ランクや総保有ポイントなどのサマリー情報を保持します。
Loyalty_Transaction__c: ポイントの獲得や利用といった個々のトランザクションを記録するオブジェクト。Loyalty_Member__cへの主従関係とし、ポイント数（増減）、トランザクション種別（獲得、利用など）、関連するレコード（注文など）のIDを保持します。
Loyalty_Tier__c: 会員ランク（例：ブロンズ, シルバー, ゴールド）の定義を管理するオブジェクト。ランク名、昇格に必要なポイント数、ランクごとの特典などを管理します。

ビジネスロジックの実装

ポイント付与のロジックは、多くの場合、特定のイベントをトリガーとして実行されます。例えば、「注文(Order)が有効化された時」というイベントです。このトリガーとして、現在ではRecord-Triggered Flow (レコードトリガーフロー) を利用するのがベストプラクティスです。

しかし、ポイント計算ロジックが複雑な場合（例：キャンペーンによるポイント倍率の変動、会員ランクに応じたボーナスポイントの計算、関連オブジェクトの複数クエリなど）、Flowだけで完結させるのは困難、あるいはパフォーマンス上の問題を引き起こす可能性があります。そこで、FlowからApexを呼び出すことで、宣言的ツールのシンプルさとプログラム的ツールの強力さを両立させます。この連携を実現するのがInvocable Method (呼び出し可能なメソッド) です。

このアーキテクチャでは、Flowが「いつ」ロジックを実行するかを制御し、Apexが「何をするか」という具体的な処理を担当します。これにより、ビジネスプロセスの変更に強く、メンテナンス性の高いシステムを構築できます。

示例代码

ここでは、注文(Order)レコードが作成または更新された際に、注文金額に基づいてロイヤルティポイントを付与するApexクラスのサンプルコードを提示します。このApexクラスは@InvocableMethodアノテーションを使用しており、Flowから「Apexアクション」として呼び出すことができます。

このコードは、Salesforceの公式ドキュメントで紹介されているInvocable Methodの基本構造をベースに、ロイヤルティプログラムのシナリオに合わせて具体化したものです。

public class LoyaltyService {

    // Flowから呼び出されるためのInvocableMethodアノテーションを付与
    @InvocableMethod(label='Award Loyalty Points' description='Calculates and awards loyalty points based on Order amount.' category='Loyalty')
    public static void awardPoints(List<Request> requests) {

        // 受け取ったリクエストから注文IDのリストを抽出
        Set<Id> orderIds = new Set<Id>();
        for (Request req : requests) {
            orderIds.add(req.orderId);
        }

        // ポイント計算に必要な情報を格納するMapを準備
        Map<Id, Loyalty_Member__c> membersToUpdate = new Map<Id, Loyalty_Member__c>();
        List<Loyalty_Transaction__c> newTransactions = new List<Loyalty_Transaction__c>();

        // 関連する注文とロイヤルティ会員情報を一括で取得 (SOQLのバルク化)
        // 注文(Order)には、取引先責任者(Contact)への参照(BillToContactId)と、
        // その取引先責任者に紐づくロイヤルティ会員(Loyalty_Member__c)への参照があると仮定
        List<Order> orders = [
            SELECT Id, TotalAmount, BillToContactId, BillToContact.Loyalty_Member__r.Id, BillToContact.Loyalty_Member__r.Total_Points__c
            FROM Order
            WHERE Id IN :orderIds AND BillToContact.Loyalty_Member__r.Id != null
        ];

        // 1ドルあたりの獲得ポイント数を定義（本来はカスタムメタデータ等で管理すべき）
        Decimal pointsPerDollar = 1.0;

        for (Order ord : orders) {
            // ポイント計算
            Decimal pointsAwarded = ord.TotalAmount * pointsPerDollar;
            // 小数点以下を切り捨て
            Long pointsAsLong = pointsAwarded.longValue();

            if (pointsAsLong > 0) {
                // 新しいロイヤルティトランザクションレコードを作成
                Loyalty_Transaction__c transaction = new Loyalty_Transaction__c();
                transaction.Loyalty_Member__c = ord.BillToContact.Loyalty_Member__r.Id;
                transaction.Points__c = pointsAsLong;
                transaction.Transaction_Date__c = Date.today();
                transaction.Type__c = 'Earned';
                transaction.Related_Order__c = ord.Id;
                newTransactions.add(transaction);

                // 会員の合計ポイントを更新するためにMapに格納
                // すでにMapに存在するかチェック
                if (!membersToUpdate.containsKey(ord.BillToContact.Loyalty_Member__r.Id)) {
                    // 存在しない場合は、クエリ結果から新しい会員オブジェクトを作成してMapに追加
                    membersToUpdate.put(ord.BillToContact.Loyalty_Member__r.Id, new Loyalty_Member__c(
                        Id = ord.BillToContact.Loyalty_Member__r.Id,
                        Total_Points__c = ord.BillToContact.Loyalty_Member__r.Total_Points__c == null ? 0 : ord.BillToContact.Loyalty_Member__r.Total_Points__c
                    ));
                }
                // Map内の会員の合計ポイントに獲得ポイントを加算
                membersToUpdate.get(ord.BillToContact.Loyalty_Member__r.Id).Total_Points__c += pointsAsLong;
            }
        }

        // DML操作はループの外で一括実行（ガバナ制限対策）
        try {
            if (!newTransactions.isEmpty()) {
                insert newTransactions;
            }
            if (!membersToUpdate.isEmpty()) {
                update membersToUpdate.values();
            }
        } catch (DmlException e) {
            // エラーハンドリング：実際にはカスタムロギング等を実装する
            System.debug('An error occurred during loyalty DML operation: ' + e.getMessage());
            // Flowにエラーを返すために例外を再スローすることも検討
            throw e;
        }
    }

    // InvocableMethodに渡すパラメータを定義する内部クラス
    public class Request {
        @InvocableVariable(label='Order ID' description='The ID of the Order to process.' required=true)
        public Id orderId;
    }
}

注意事項

Apexを使用してロジックを実装する際には、Salesforceプラットフォームの制約とベストプラクティスを遵守する必要があります。

ガバナ制限 (Governor Limits)

Salesforceはマルチテナント環境であるため、1つのトランザクション内で使用できるリソースには厳格な制限（ガバナ制限）が設けられています。開発者は常にこれらの制限を意識する必要があります。

SOQLクエリ： 1トランザクションあたりの発行回数は100回までです。上記のサンプルコードのように、ループ内でSOQLを発行するのではなく、最初に必要なIDを収集し、一度のクエリでまとめてデータを取得するbulkification (バルク化) が不可欠です。
DML操作： 1トランザクションあたりの実行回数は150回までです。これも同様に、ループ内でinsertやupdateを行うのではなく、リストにレコードを追加していき、ループの最後にまとめて実行します。
CPU時間： 複雑な計算処理はCPU使用時間制限に抵触する可能性があります。コードのアルゴリズムを効率化し、不要な処理を避けることが重要です。

エラーハンドリング (Error Handling)

DML操作は、検証ルール、必須項目の欠落、レコードロックなど、様々な理由で失敗する可能性があります。try-catchブロックを使用してDML例外を捕捉し、適切なエラー処理を行うことが重要です。エラーが発生したことをログに記録したり、管理者に通知したり、あるいはFlowにエラーを伝えてユーザーにフィードバックするなどの対応が考えられます。

セキュリティと権限 (Security and Permissions)

Apexクラスは、デフォルトではシステムコンテキストで実行される（オブジェクトや項目の権限を無視する）場合があります。ユーザーの権限設定を尊重する必要がある場合は、クラス定義にwith sharingキーワードを明示的に指定します。これにより、コードを実行するユーザーがアクセスできないレコードを意図せず操作してしまうことを防ぎます。また、Field-Level Security (項目レベルセキュリティ) も考慮し、ユーザープロファイルに基づいて項目へのアクセス権が適切に設定されているか確認が必要です。

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

Salesforce Apexを活用することで、標準機能や宣言的ツールだけでは実現が難しい、複雑でスケーラブルなカスタムロイヤルティプログラムを構築することが可能です。FlowとInvocable Apexを組み合わせるアプローチは、今日のSalesforce開発における強力なパターンです。

以下に、開発におけるベストプラクティスをまとめます。

ロジックとトリガーの分離： トリガー（この例ではFlow）はイベントの発生を検知する役割に徹し、複雑なビジネスロジックはApexクラス（サービスクラス）に実装します。これにより、コードの再利用性とメンテナンス性が向上します。
設定値のハードコーディングを避ける： サンプルコード内の「1ドルあたりの獲得ポイント数」のような設定値は、コード内に直接書き込む（ハードコーディングする）べきではありません。Custom Metadata Type (カスタムメタデータ型) やカスタム設定を利用して外部から設定できるようにすることで、管理者があとから容易に変更できるようになります。
徹底したテスト： すべてのApexコードには、そのロジックを検証するためのTest Class (テストクラス) を作成する必要があります。本番環境へのデプロイには、最低75%のコードカバレッジが要求されます。ポジティブケース、ネガティブケース、そしてバルク処理のテストを網羅的に行うことが、システムの品質を保証します。
将来のスケーラビリティを考慮する： プログラムの設計段階から、将来のデータ量増加を想定することが重要です。特にLarge Data Volumes (LDV) (大量データ) を扱う可能性がある場合、SOQLクエリの選択性を高める（インデックス付き項目をWHERE句で使用する）など、パフォーマンスを意識したコーディングが求められます。

これらの原則に従うことで、ビジネスの成長に合わせて拡張可能な、堅牢で効果的なロイヤルティプログラムをSalesforceプラットフォーム上に構築できるでしょう。

にゃんこのSalesforce日記

このブログを検索