Salesforce Loyalty Management：API主導のアーキテクチャと実装ガイド

背景と応用シナリオ

現代のビジネス環境において、顧客ロイヤルティの獲得と維持は、企業の持続的な成長に不可欠な要素となっています。新規顧客の獲得コストが増加し続ける中、既存顧客との関係を深め、Life Time Value (LTV) を最大化する戦略として、Loyalty Program（ロイヤルティプログラム）の重要性はますます高まっています。Salesforceは、この課題に対応するため、ネイティブなソリューションとして Salesforce Loyalty Management を提供しています。

Salesforce Loyalty Managementは、ポイントの付与・交換、会員ランク制度、特典管理、プロモーションの実行といった、ロイヤルティプログラムの運営に必要な機能を包括的に提供するプラットフォームです。その応用シナリオは多岐にわたります。

小売業界： 購入金額に応じたポイント付与、特定商品の購入によるボーナスポイント、会員ランクに応じた限定セールへの招待など。
旅行・ホスピタリティ業界： 宿泊日数や利用金額に基づくマイルやポイントの蓄積、上級会員向けの客室アップグレードやレイトチェックアウトなどの特典提供。
B2B（企業間取引）： 継続的な取引や製品のアップセルに対するリワード、パートナー企業へのインセンティブプログラムなど。

これらのシナリオを成功させるためには、POSシステム、Eコマースサイト、モバイルアプリといった外部システムとのシームレスな連携が鍵となります。本稿では、Salesforce技術アーキテクトの視点から、Loyalty Managementの技術的な原理を解説し、APIを活用した実装方法について具体的なコードを交えながら詳説します。

原理説明

Salesforce Loyalty Managementのアーキテクチャは、柔軟性と拡張性を重視した「APIファースト」のアプローチで設計されています。その中核をなすのは、標準オブジェクトと強力な処理エンジン、そして外部連携を容易にするためのConnect REST APIです。

主要な標準オブジェクト

Loyalty Managementは、プログラムの構成要素を管理するために、いくつかの主要な標準オブジェクトを利用します。

LoyaltyProgram: ロイヤルティプログラム全体の定義を格納します。プログラム名、ポイントの通貨単位、有効期限のルールなどが含まれます。
LoyaltyProgramMember: プログラムに参加する顧客（会員）情報を管理するオブジェクトです。取引先(Account)や個人取引先(Person Account)、取引先責任者(Contact)と関連付けられます。
LoyaltyTierGroup / LoyaltyTier: 会員ランク制度（例：シルバー、ゴールド、プラチナ）を定義します。TierGroupがランク制度全体を、Tierが個々のランクを表します。
TransactionJournal: ポイントの付与（Accrual）、交換（Redemption）、調整（Adjustment）といったすべての取引履歴を記録する非常に重要なオブジェクトです。一度作成されると変更不可能な、監査証跡としての役割を果たします。
LoyaltyLedger: TransactionJournalの集計結果として、会員の現在のポイント残高を保持します。パフォーマンス向上のために非正規化されたデータです。

処理エンジンと自動化

ポイントの計算やランクの更新といったロジックは、主にFlowやLoyalty Managementに組み込まれたルールエンジンによって実行されます。例えば、「購入金額100円ごとに1ポイントを付与する」といったルールは、Flowや設定を通じて定義され、TransactionJournalが作成された際に自動的にトリガーされます。これにより、複雑なビジネスロジックをコードを書かずに実装できる一方、より高度な要件にはApexによるカスタマイズが可能です。

APIによる外部連携

Loyalty Managementの真価は、その強力なAPIにあります。Connect REST APIを通じて、外部システムはSalesforceのUIを介さずに、会員登録、ポイントの操作、会員情報の照会などを安全かつ効率的に実行できます。例えば、Eコマースサイトで顧客が商品を購入した際、バックエンドシステムがConnect REST APIを呼び出して、該当する会員にポイントを付与する、といった連携が典型的なユースケースです。これにより、Salesforceをロイヤルティの中核ハブとして、あらゆる顧客接点で一貫した体験を提供することが可能になります。

示例代码

ここでは、外部システムがConnect REST APIを利用してLoyalty Managementと連携する際の具体的なコード例を、Salesforce公式ドキュメントに基づいて紹介します。APIエンドポイントへのリクエストは、通常、認証されたHTTPクライアントから行います。

会員登録 (Member Enrollment)

新しい顧客をロイヤルティプログラムに登録します。この例では、既存の取引先責任者(Contact)を「Cloudy Loyalty Program」というプログラムに参加させています。

エンドポイント: POST /connect/loyalty/programs/{programName}/members

{
  "enrollmentDate": "2024-05-20T10:00:00Z",
  "memberType": "Individual",
  "relatedContactId": "003xx000003D87bAAC",
  "canReceivePromotions": "true",
  "canReceivePartnerPromotions": "false",
  "preferredLanguage": "ja-JP"
}

詳細な解説:

enrollmentDate: 会員がプログラムに登録された日時です。
memberType: 会員の種別を指定します。個人顧客の場合は「Individual」です。
relatedContactId: 関連付けるSalesforceの取引先責任者IDです。このIDをキーに顧客情報が紐づけられます。

ポイントの付与 (Point Accrual)

会員の行動（例：商品購入）に対してポイントを付与します。TransactionJournalを作成することでこれを実現します。

エンドポイント: POST /connect/loyalty/programs/{programName}/members/{memberId}/journals

{
  "journalEntries": [
    {
      "journalSubType": "Purchase",
      "activityDate": "2024-05-21T14:30:00Z",
      "transactionDate": "2024-05-21T14:30:00Z",
      "loyaltyProgramCurrency": "Points",
      "quantity": 150,
      "additionalContext": {
        "orderId": "ORD-0012345"
      }
    }
  ],
  "journalType": "Accrual"
}

詳細な解説:

journalType: トランザクションの種類です。ポイント付与の場合は「Accrual」を指定します。
journalSubType: 付与の理由をより詳細に分類するためのサブタイプです（例：「Purchase」「Welcome Bonus」など）。
activityDate: ポイント付与の対象となった顧客の行動が発生した日時です。
loyaltyProgramCurrency: ポイントの種類を指定します。プログラムで定義された通貨名（API参照名）を入力します。
quantity: 付与するポイント数です。
additionalContext: 注文IDなど、関連する外部システムの情報を格納するためのフィールドです。後々の追跡やデバッグに役立ちます。

ポイントの交換 (Point Redemption)

会員が貯めたポイントを特典などに交換します。これもTransactionJournalを作成しますが、journalTypeが異なります。

エンドポイント: POST /connect/loyalty/programs/{programName}/members/{memberId}/journals

{
  "journalEntries": [
    {
      "journalSubType": "Product Discount",
      "activityDate": "2024-05-22T11:00:00Z",
      "transactionDate": "2024-05-22T11:00:00Z",
      "loyaltyProgramCurrency": "Points",
      "quantity": -2000,
      "additionalContext": {
        "voucherCode": "DISCOUNT-ABCDE"
      }
    }
  ],
  "journalType": "Redemption"
}

詳細な解説:

journalType: ポイント交換の場合は「Redemption」を指定します。
quantity: 交換するポイント数を負の値で指定します。これにより、会員のポイント残高が減少します。APIは残高が不足している場合、エラーを返却します。

注意事項

Loyalty Managementを実装・運用する際には、以下の点に注意が必要です。

権限 (Permissions)

APIを呼び出すインテグレーションユーザーには、適切なPermission Set（権限セット）を割り当てる必要があります。「Loyalty Management User」や「Loyalty Management Manager」といった標準の権限セットが存在しますが、最小権限の原則に基づき、APIアクセスに必要なオブジェクトや項目へのアクセス権のみを持つカスタム権限セットを作成・付与することが推奨されます。

API制限 (API Limits)

Loyalty Management APIの呼び出しは、Salesforce組織全体のAPIガバナ制限（24時間あたりのAPIコール数など）の対象となります。特に、POSシステムからのリアルタイム連携など、トランザクション量が多いシナリオでは、APIコールの消費量に注意が必要です。必要に応じて、リクエストをキューイングして一括で処理する（Bulkification）、またはSalesforce Platform Eventsを活用して非同期に処理するといったアーキテクチャを検討してください。

TransactionJournalの不変性

TransactionJournalレコードは、一度作成されると変更も削除もできません。これは会計台帳のようなもので、すべての取引履歴の完全性を保証するためです。もし誤ったポイント付与が発生した場合は、元のトランザクションを修正するのではなく、その影響を相殺するための新しい調整（Adjustment）トランザクションを作成する必要があります。この設計思想を理解することは、エラー処理や修正プロセスを構築する上で非常に重要です。

非同期処理 (Asynchronous Processing)

ポイントの付与やランクアップの判定は、ルールエンジンによって処理されます。トランザクション量が多い場合、これらの処理は即時ではなく非同期で実行されることがあります。そのため、APIを呼び出した直後に会員のポイント残高やランクが更新されているとは限りません。フロントエンドのUIでは、この遅延を考慮し、「処理中です」といったメッセージを表示したり、ポーリングやPush通知で最新の状態を反映したりする工夫が求められます。

エラー処理 (Error Handling)

API連携においては、堅牢なエラーハンドリングが不可欠です。例えば、ポイント交換時に残高が不足している、存在しない会員IDを指定した、といった場合にはAPIはエラーレスポンスを返します。クライアント側では、これらのエラーコードを適切に解釈し、ユーザーへのフィードバックや、リトライ処理、管理者への通知といったロジックを実装する必要があります。

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

Salesforce Loyalty Managementは、単なるポイント管理ツールではなく、顧客エンゲージメントを向上させるための強力なプラットフォームです。その中心にあるのは、柔軟なデータモデルと、外部システムとの連携を前提としたAPIファーストのアーキテクチャです。

成功裏に導入するためのベストプラクティスを以下に示します。

APIファーストでの連携設計: 外部システムとの連携は、可能な限りConnect REST APIを通じて行います。特別な理由がない限り、Apex DMLで直接Loyalty関連オブジェクトを操作することは避けるべきです。APIを利用することで、Salesforceが提供する標準のビジネスロジックや検証、将来の機能拡張の恩恵を最大限に受けることができます。
冪等性の確保 (Idempotency): ネットワークの問題などでAPIリクエストが重複して送信された場合でも、ポイントが二重に付与されないように、冪等性を確保する仕組みを導入します。TransactionJournalのadditionalContextフィールドに外部システムのユニークなトランザクションIDを格納し、Apexトリガーなどで重複チェックを行うことが一般的なパターンです。
スケーラビリティを考慮した設計: 大量のトランザクションが予想される場合は、Platform Eventsの活用を検討します。外部システムは軽量なイベントを発行するだけでよく、Salesforce側でイベントをサブスクライブして非同期にポイント処理を実行することで、システム全体の応答性と耐障害性を高めることができます。
責務の分離: ポイント計算などのルールベースのロジックは可能な限りFlowで実装し、メンテナンス性を高めます。Flowでは実現不可能な複雑な計算ロジックや、外部システムとの双方向連携などが必要な場合にのみApexを使用し、責務を明確に分離します。
徹底したテスト: ポイントの計算ロジック、プロモーションルール、ランクアップ・ダウンのシナリオは複雑になりがちです。本番稼働前に、Sandbox環境であらゆるシナリオを網羅した単体テスト、結合テスト、UAT（ユーザー受け入れテスト）を徹底的に実施してください。

これらの原理とベストプラクティスを理解し、計画的にアーキテクチャを設計することで、Salesforce Loyalty Managementのポテンシャルを最大限に引き出し、ビジネスの成長に貢献する優れた顧客ロイヤルティプログラムを構築することができるでしょう。

にゃんこのSalesforce日記

このブログを検索

Salesforce パーミッションセットの活用：管理者と開発者のためのきめ細かいアクセス制御