未来を設計する：Salesforce Einstein 1 Platform のアーキテクチャ徹底解説

日付:

背景と応用シナリオ

Salesforce アーキテクトとして、私たちは常に断片化したテクノロジーランドスケープという課題に直面してきました。顧客データはサイロ化され、営業、サービス、マーケティングの各システムに散在し、一貫性のある顧客体験を提供することは困難を極めました。従来のアーキテクチャでは、これらのサイロを繋ぐために、複雑で壊れやすい ETL (Extract, Transform, Load) プロセスやポイント・ツー・ポイントの連携を構築する必要があり、多大な開発・維持コストと、データの鮮度の低下という問題を生み出してきました。

このような背景の中、Salesforce は Einstein 1 Platform を発表しました。これは単なる新機能の追加ではなく、Salesforce のアーキテクチャ思想そのものを根底から変革するものです。Einstein 1 Platform は、CRM アプリケーション、信頼性の高い AI、そしてハイパースケールデータエンジンである Data Cloud (データクラウド) を、Salesforce の中心にある Metadata Framework (メタデータフレームワーク) を通じて、単一の統合プラットフォームとして再定義します。

応用シナリオとして、あるグローバルな小売企業を想像してみてください。この企業は、以下の目標を掲げています。

  • ウェブサイトでの顧客の行動履歴（閲覧商品、カート追加）
  • 実店舗での購買履歴
  • マーケティングメールへの反応
  • カスタマーサービスへの問い合わせ履歴

Einstein 1 Platform のアーキテクチャを採用することで、これらの異なるソースからのデータを Data Cloud に統合・整理し、単一の顧客プロファイル（Unified Profile）を構築できます。そして、このプロファイルを直接参照する AI を活用した Einstein Copilot (アインシュタイン コパイロット) が、サービスエージェントに対して「この顧客は最近、特定の商品を閲覧し、過去に類似商品を購入しているため、このアップセル商品を提案するのが効果的です」といった具体的なアクションをリアルタイムで推奨します。この一連の流れは、データのコピーや複雑な連携を必要とせず、すべてが単一のプラットフォーム上で完結します。これが Einstein 1 Platform が実現する、アーキテクチャレベルでの変革なのです。

原理説明

Einstein 1 Platform のアーキテクチャを理解する上で、鍵となるのは「メタデータによる統合」です。従来の Salesforce プラットフォームの強みは、すべての標準・カスタムオブジェクト、項目、自動化ルール、UI がメタデータとして定義され、一貫性のある形で連携できる点にありました。Einstein 1 Platform は、この強力なメタデータフレームワークを Data Cloud にまで拡張します。

主要な構成要素

Einstein 1 Platform のアーキテクチャは、主に以下の3つの柱で構成されています。

  1. Data Cloud: AWS Hyperforce 上に構築された、ハイパースケールなデータプラットフォームです。数十億、数百億レコードという膨大な量のデータを取り込み、高速に処理する能力を持ちます。Data Cloud 内のデータは、Data Lake Object (DLO) として元の形式で格納され、その後、Data Model Object (DMO) へと整理・統合されます。DMO は、顧客や商品といったビジネスコンセプトを表す、正規化されたデータモデルです。
  2. Salesforce Platform (CRM): Sales Cloud や Service Cloud といった、私たちが慣れ親しんだ CRM アプリケーションの基盤です。Apex、Flow、Lightning Web Components (LWC) といったプロコード／ローコードの開発ツールが含まれます。
  3. Einstein AI: 予測分析から生成 AI まで、Salesforce の AI 機能群です。特に Einstein Copilot は、Data Cloud にある信頼性の高い顧客データを基盤（Grounding）として、文脈に応じた適切な応答やアクションを生成します。

メタデータフレームワークによる「Zero-ETL」

アーキテクチャ上、最も画期的な点は、Data Cloud の DMO が Salesforce のメタデータとして認識されることです。これにより、Zero-ETL (ゼロETL) と呼ばれるアプローチが実現します。

これは、Data Cloud にあるデータを、Salesforce のコアプラットフォーム（CRM）に物理的にコピーすることなく、あたかも標準オブジェクト（sObject）であるかのように、直接アクセスできることを意味します。アーキテクトの視点から見ると、これは以下の絶大なメリットをもたらします。

  • 連携の簡素化: 従来必要だった API コネクタやミドルウェアが不要になり、アーキテクチャが劇的にシンプルになります。
  • データの鮮度: データの同期やバッチ処理によるタイムラグがなくなり、常に最新のデータに基づいた意思決定が可能になります。
  • 開発者体験の向上: 開発者は、使い慣れた SOQL (Salesforce Object Query Language) や Apex を使って、DMO のデータに直接クエリを実行できます。新しい API やデータアクセス言語を学ぶ必要はありません。

信頼できる AI (Trusted AI) の実現

生成 AI をビジネスで活用する際の最大の懸念は、不正確な情報（ハルシネーション）や、機密データの漏洩です。Einstein 1 Platform は、Data Cloud Trust Layer (データクラウド トラストレイヤー) を通じてこの課題に対応します。Einstein Copilot がユーザーからのプロンプトを受け取ると、その内容を Data Cloud 内の構造化された顧客データで補強（Grounding）します。これにより、AI の応答は、一般的で抽象的なものではなく、具体的で信頼性の高い、自社のデータに基づいたものになります。アーキテクチャとして、AI の入力と出力が、自社のデータガバナンスとセキュリティモデルの範囲内に留まることが保証されるのです。

示例代码

Einstein 1 Platform のアーキテクチャがいかにシームレスであるかを示すため、Apex を使用して Data Cloud の Data Model Object (DMO) に直接クエリを実行するコード例を見てみましょう。このコードは、特別な API コールではなく、標準的な SOQL を使用している点が重要です。これは、DMO がプラットフォームのメタデータの一部として完全に統合されていることの証左です。

ここでは、`UnifiedIndividual__dlm` という名前の DMO（統合された個人プロファイルを表す）から、特定のメールアドレスを持つ個人の情報を取得するシナリオを想定します。

// UnifiedIndividual__dlm という DMO にアクセスする Apex クラス
// DMO の API 参照名は、末尾に __dlm が付きます。
public with sharing class DataCloudDmoReader {

    // 特定のメールアドレスを持つ DMO レコードを検索するメソッド
    // SOQL を使用して、あたかも標準 sObject をクエリするかのように DMO にアクセスできます。
    // これが Einstein 1 Platform の Zero-ETL アーキテクチャの強力な点です。
    public static List<UnifiedIndividual__dlm> getIndividualsByEmail(String email) {

        // DMO をクエリするための SOQL 文
        // FROM 句には DMO の API 参照名を指定します。
        // SELECT 句には、DMO の項目 API 参照名（__c の代わりに __c）を指定します。
        String soqlQuery = 'SELECT Id, FirstName__c, LastName__c, Email__c FROM UnifiedIndividual__dlm WHERE Email__c = :email';

        // クエリ結果を格納するリスト
        List<UnifiedIndividual__dlm> individuals = new List<UnifiedIndividual__dlm>();

        try {
            // Database.query を使用して動的 SOQL を実行します。
            // これにより、Data Cloud に格納されているデータに直接アクセスできます。
            // データの物理的な移動やコピーは発生していません。
            individuals = Database.query(soqlQuery);

            System.debug('取得した DMO レコード数: ' + individuals.size());
            for(UnifiedIndividual__dlm individual : individuals) {
                System.debug('ID: ' + individual.Id + ', Name: ' + individual.FirstName__c + ' ' + individual.LastName__c);
            }

        } catch (QueryException e) {
            // クエリエラーが発生した場合の例外処理
            System.debug('DMO のクエリ中にエラーが発生しました: ' + e.getMessage());
            // 実際のアプリケーションでは、より堅牢なエラーハンドリングを実装します。
            return null;
        }

        return individuals;
    }
}

このコード例は、`developer.salesforce.com` の公式ドキュメントにある「Query Data Cloud Data with SOQL」の概念に基づいています。アーキテクトとして注目すべきは、Data Cloud のデータを扱うために新しいフレームワークやライブラリを導入する必要がない点です。既存の Salesforce 開発スキルセットをそのまま活用し、ハイパースケールのデータにアクセスできる。これは、開発コストの削減と市場投入までの時間短縮に直結する、非常に重要なアーキテクチャ特性です。

注意事項

Einstein 1 Platform のアーキテクチャを設計・導入する際には、以下の点に注意する必要があります。

権限とデータガバナンス

DMO はメタデータとして統合されますが、そのデータ自体は Data Cloud に存在します。したがって、アクセス制御は Salesforce の標準的な権限セットと、Data Cloud 固有の権限設定の両方を考慮する必要があります。誰がどの DMO のどの項目にアクセスできるのか、厳密なデータガバナンスポリシーを設計の初期段階で策定することが不可欠です。

API 制限とガバナンス

Data Cloud へのデータ取り込み、セグメンテーション、クエリなどには、それぞれ API 制限やガバナリミットが存在します。大規模なデータを扱うソリューションを設計する際には、これらの制限を十分に理解し、バッチ処理のサイズ、実行頻度、クエリの複雑さなどを最適化する必要があります。特に、リアルタイム性が求められるユースケースでは、制限に抵触しないようなアーキテクチャの工夫が求められます。

データモデリングの重要性

Data Cloud のパフォーマンスと価値は、DMO のデータモデル設計に大きく依存します。ソースとなる様々なシステムから取り込んだデータを、いかに適切にマッピングし、統合された顧客プロファイルを構築するかが鍵となります。アーキテクトは、ビジネス要件を深く理解し、将来の拡張性も見据えた、スケーラブルなデータモデルを設計する責任を負います。

トランザクションと一貫性

SOQL でクエリできるとはいえ、DMO は Salesforce コアプラットフォームのトランザクションデータベース内にあるわけではありません。そのため、標準 sObject と同じレベルのリアルタイムなトランザクション整合性が保証されるわけではありません。例えば、Apexトリガー内で DMO を更新し、即座にその結果を別のクエリで参照するような設計は、データのレイテンシーを考慮する必要があるかもしれません。アーキテクチャ設計時には、データの特性（分析系か、トランザクション系か）を理解し、適切なデータ配置とアクセスパターンを選択することが重要です。

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

Einstein 1 Platform は、Salesforce の歴史における大きなパラダイムシフトです。これは、個別のクラウド製品（Sales, Service, Marketing...）を連携させるアーキテクチャから、単一の統合されたプラットフォーム上でアプリケーションを構築するアーキテクチャへの移行を意味します。Data Cloud というハイパースケールなデータ基盤が、メタデータを通じてネイティブに統合されたことで、これまで不可能だったレベルのリアルタイム性とインテリジェンスが実現可能になりました。

Salesforce アーキテクトとして、この新しいプラットフォームを最大限に活用するためのベストプラクティスは以下の通りです。

  1. データファーストのアプローチを取る: ソリューション設計の出発点を、UI やプロセスではなく、データに置きます。どのようなデータを、どこから、どのように集め、どう統合すればビジネス価値が最大化されるかを最初に定義します。
  2. メタデータ統合を積極的に活用する: 可能な限り Zero-ETL のアプローチを採用し、カスタムの連携処理を構築するのを避けます。Flow、Apex、LWC から DMO への直接アクセスを標準的な設計パターンとします。
  3. 信頼とガバナンスを設計に組み込む: AI を活用する前提で、データセキュリティ、プライバシー、権限管理のフレームワークを初期段階で構築します。Trusted AI は、堅牢なガバナンスの上に成り立ちます。
  4. スケーラビリティを常に意識する: Data Cloud は膨大なデータを扱えますが、その性能を引き出すには適切な設計が不可欠です。データモデル、クエリ、自動化プロセスが、将来のデータ量増加に対応できるかを常に検証します。

Einstein 1 Platform は、私達アーキテクトに、よりシンプルで、よりパワフルで、よりインテリジェントなソリューションを構築するための新しいツールキットを提供してくれます。このアーキテクチャの本質を理解し、その能力を最大限に引き出すことが、これからの Salesforce プロジェクトを成功に導く鍵となるでしょう。

コメント

コメントを投稿