広告枠を募集中 ご相談ください

Salesforce Data Cloud で Agentforce をグラウンディングする:データ複製を排除したリアルタイム推論アーキテクチャ設計ガイド

365Finds Editorial
Wiki 記事 11,430 本収録

あなたの AI で 365 Wiki を使う

下のプロンプトをコピーして、普段使っている AI に貼り付け、そのまま質問してください。

完全版 Skill をダウンロード

まずはプロンプトでお試しください。よく使う場合は完全版 365Wiki Skill をインストールすると、毎回貼り付ける必要がありません。普段使う AI がなければ、Gemini や Microsoft Copilot のウェブ版でも使えます。

エンタープライズ生成 AI は、単なる質問応答ボットから、自律的にマルチステップの計画・推論・アクションを実行する「自律型エージェント」へと進化を遂げました。Salesforce Agentforce では、自律型 AI エージェントが従業員や顧客に代わって複雑な業務プロセスを担います。しかし、エージェントの判断精度は、その推論を支えるエンタープライズデータの鮮度と網羅性に完全に依存します。断片化された古い CRM キャッシュに基づいて推論を行えば、ハルシネーション(幻覚)の発生、不適切な業務トリガーの実行、コンプライアンス違反のリスクに直結します。

従来、業務アプリケーションに統合コンテキストを提供するには、大規模な ETL(抽出・変換・ロード)パイプラインを構築し、外部データレイクやデータウェアハウスからペタバイト規模のデータを Salesforce へ複製する必要がありました。この旧来の手法は、データ同期の遅延、二重ストレージによるコスト高騰、データガバナンスの崩壊、顧客プロファイルの不整合という深刻な課題を抱えていました。

Salesforce データアーキテクトは、Agentforce、Atlas 推論エンジン(Atlas Reasoning Engine)、そして Salesforce Data Cloud(現 Data 360) のゼロコピー(Zero-Copy)アーキテクチャを組み合わせることで、このトレードオフを解消します。Snowflake、Google BigQuery、Databricks、Amazon Redshift に存在する企業データを一切移動・複製することなく、リアルタイムに直接参照し、ミリ秒単位で安全な推論コンテキストをエージェントに提供する設計手法を解説します。


1. 自律型エージェントのデータ課題:従来の ETL では Atlas を支えられない理由

固定的なプロンプト応答を行う従来のチャットボットとは異なり、Agentforce は Atlas 推論エンジン によって駆動され、高度な ReAct(Reason + Act:推論と行動) ループを実行します。Atlas は単にキーワードを正規表現で拾うのではなく、以下のサイクルを自律的に繰り返します。

  1. 顧客の意図やシステムイベントのトリガーを分析し、企業のビジネス目標と照合する。
  2. 設定された専門領域(トピック:Topics)に基づいて動的な実行計画を立案する。
  3. 必要な構造化・非構造化データを外部リポジトリやナレッジベースから動的に取得する。
  4. Salesforce Flow、Apex、MuleSoft API などの確定的なツールを呼び出してアクションを実行する。
  5. 中間結果を評価し、目標が達成されるまで計画を再評価・ループ修正する。

この自律推論サイクルでは、旧来の ETL パイプラインは以下のような致命的なボトルネックとなります。

したがって、アーキテクトは Salesforce Data Cloud を単なるデータの受け皿ではなく、「全社リアルタイムセマンティッククエリファブリック」として再定義する必要があります。


2. ゼロコピー(Zero-Copy)連携のアーキテクチャ基盤

ゼロコピー統合の本質は、「データは元の保管場所に置いたまま、計算レイヤーをフェデレーション(統合連携)する」点にあります。Data Cloud は主に以下の 3 つのフェデレーションパターンを提供します。

[ 外部データレイクハウス / データウェアハウス ]
  Snowflake | Databricks | BigQuery | Amazon Redshift
           |                        |
     (直接ファイル連携 / Iceberg)  (プッシュダウン SQL / JDBC)
           |                        |
           v                        v
+-------------------------------------------------------+
|             Salesforce Data Cloud (Data 360)          |
|  - データレイクオブジェクト (DLOs)                    |
|  - データモデルオブジェクト (DMOs / CIM 標準)         |
|  - リアルタイムアイデンティティ解決 (Unified Individual) |
|  - 事前実体化データグラフ (Data Graphs / 階層型 JSON) |
|  - ハイブリッド検索インデックス (ベクトル + BM25)     |
+-------------------------------------------------------+
                           |
                           v
+-------------------------------------------------------+
|             Einstein トラストレイヤー                 |
|  - PII (個人識別情報) の動的マスキング / 復元         |
|  - ゼロデータ保持保証 (Zero Data Retention)           |
|  - ハルシネーション・有害性検出                       |
+-------------------------------------------------------+
                           |
                           v
+-------------------------------------------------------+
|             Atlas 推論エンジン                        |
|  - 意図分類・トピック選択                             |
|  - コンテキストグラウンディング & ReAct プランニング  |
|  - 確定ツール実行 (Apex / Flow / MuleSoft API)         |
+-------------------------------------------------------+

Apache Iceberg によるファイルフェデレーション(File Federation)

Amazon S3 や Google Cloud Storage などのオブジェクトストレージ上に配置された Apache Iceberg や Delta Lake 形式のテーブルを、ストレージレベルで直接マウントします。Data Cloud の Hyper クエリエンジンがメタデータと Parquet ファイルを直接読み取るため、外部データウェアハウスのコンピュートリソースを消費しません。クリックストリーム、IoT ログ、大規模トランザクション履歴などの大容量データに最適です。

クエリフェデレーション(Query Federation / プッシュダウン)

外部ウェアハウス(Snowflake や BigQuery など)に既に存在する高度な分析モデル(顧客生涯価値 LTV、解約リスク予測、クレジットスコアなど)を参照する場合、Data Cloud は SQL クエリを外部エンジン側へプッシュダウン実行します。リモート側で計算された最終結果セットのみが Data Cloud に返却されるため、軽量なコンテキスト取得が可能です。

双方向データ共有(Bidirectional Data Sharing)

ゼロコピーは双方向で機能します。Snowflake Secure Data Sharing や Databricks Delta Sharing プロトコルを通じて、Data Cloud は CRM 側の顧客エンゲージメントシグナルやサポート履歴を、外部ウェアハウス側へゼロコピーでセキュアに公開できます。


3. セマンティック正規化とリアルタイムアイデンティティ解決

ゼロコピーで接続された外部テーブルは、そのままでは推論エンジンが解釈できません。企業システムごとにバラバラな命名規則やスキーマを統一するため、Data Cloud 上でセマンティック正規化を実施します。

ステップ 1:DLO から DMO へのマッピング

外部テーブルを接続すると、Data Cloud 内に**データレイクオブジェクト(DLO)として登録されます。アーキテクトは標準のクラウド情報モデル(CIM)に準拠したデータモデルオブジェクト(DMO)**へこれらをマッピングします。

ステップ 2:リアルタイムアイデンティティ解決(Identity Resolution)

顧客は、Web の未認証 Cookie、アプリのアカウント ID、コールセンターの電話番号など、多種多様なタッチポイントで企業と接点を持ちます。

Data Cloud のアイデンティティ解決機能は、決定論的ルールおよび曖昧一致ルール(メールアドレス、ハッシュ化された電話番号、顧客 ID など)を適用し、異種システム間のレコードを統合します。その結果、全社共通の Unified Individual(統合個客プロファイル) がリアルタイムに生成されます。Agentforce は、単一チャネルの断片的な情報ではなく、顧客の全ライフサイクルを把握した状態で推論を開始できます。


4. 推論遅延の解消:データグラフ(Data Graphs)による超高速取得

自律型 AI エージェントの実装において、最大の技術的ハードルとなるのがクエリレイテンシです。Atlas 推論エンジンが 1 回の意思決定を行うたびに、外部テーブルや複数 DMO に対する複雑なリレーショナル SQL JOIN を実行していては、応答に 5〜15 秒を要し、チャットセッションのタイムアウトや離脱を招きます。

アーキテクトは、Data Cloud の データグラフ(Data Graphs) を活用してこの課題を解決します。

データグラフとは何か?

データグラフとは、関連する複数の DMO のリレーションシップを事前に走査し、単一の階層型 JSON 構造として実体化(マテリアライズ)しておくデータモデル機能です。

典型的な構成例:

データグラフが Agentforce を加速する理由

  1. 実行時 JOIN の完全排除: 複雑なリレーショナル結合処理が事前計算されているため、推論実行時に負荷がかかりません。
  2. サブセカンド(ミリ秒級)の単一キー検索: Atlas は UnifiedIndividualId などのプライマリキーを 1 回照会するだけで、顧客の 360 度コンテキストツリー全体を数十ミリ秒で一括取得できます。
  3. Prompt Builder とのネイティブ連動: Salesforce の Prompt Builder では、データグラフを構造化マージフィールドとして直接プロンプトテンプレートに挿入できます。Apex による独自シリアライズ処理を記述する必要はありません。

5. 非構造化ナレッジのグラウンディング:ベクトル検索とハイブリッド検索

企業の重要ナレッジは、構造化テーブルだけでなく、製品マニュアル、保証規定 PDF、FAQ ドキュメント、過去の対応ログといった非構造化データにも大量に存在します。

Agentforce をこれらドキュメントにグラウンディングするため、アーキテクトは Data Cloud の検索インデックスを活用します。

  1. ドキュメントの登録とゼロコピー連携: SharePoint、Amazon S3、Salesforce Knowledge などのリポジトリを非構造化 DLO として接続。
  2. チャンク分割とベクトル埋め込み: ドキュメントを適切なセマンティックチャンクに分割し、組み込みの埋め込みモデルを用いてベクトル化して Data Cloud 内のベクトル DB に格納。
  3. ハイブリッド検索(Hybrid Search): ユーザーが「屋外に設置した場合、ポンプの保証交換は適用されますか?」といった質問をした際、Atlas は BM25 キーワード検索(型番やパーツ番号の完全一致)と高密度ベクトル類似度検索(文脈・意味の一致)を並行実行し、最適なドキュメントスニペットをプロンプトに注入します。

6. Atlas 推論エンジンの実行ループとセキュリティ保護

ゼロコピー連携、DMO マッピング、データグラフ、検索インデックスが整うと、Agentforce は以下のループで自律動作します。

[顧客からの問い合わせ / イベント発生]
       │
       ▼
[Atlas 推理エンジン] ────────► 意図解析を行い、担当トピック(Topic)を決定
       │
       ▼
[Data Cloud グラウンディング] ──► データグラフ取得(顧客 360 度構造化 JSON)
                             ──► ハイブリッド検索(該当する非構造化ドキュメント)
                             ──► ゼロコピー照会(外部 ERP から最新在庫・請求取得)
       │
       ▼
[Einstein トラストレイヤー] ──► PII 動的マスキング / アクセス権限の検証
       │
       ▼
[LLM 自律推論] ──────────────► ReAct ループにより、実行すべきツールを決定
       │
       ▼
[アクション実行] ────────────► Salesforce Flow / Apex / MuleSoft API の実行
       │
       ▼
[結果検証と完了] ────────────► 実行結果が目標を満たしているか評価し回答完了

Einstein トラストレイヤーの役割

グラウンディングされたコンテキストが LLM(Salesforce 独自基盤、OpenAI、Anthropic、Azure など)に送信される際、トラストレイヤーが不可欠な防壁となります。


7. アーキテクチャ比較:従来の ETL 手法 vs. Data Cloud ゼロコピーグラウンディング

比較項目従来の ETL 複製アプローチData Cloud ゼロコピーグラウンディング
データ移動定期バッチによる物理的な抽出・変換・CRM への複製データ移動なし;Apache Iceberg ファイル連携またはクエリプッシュダウン
データ鮮度同期間隔に依存(数時間〜1 日単位の遅延が発生)リアルタイム;外部データウェアハウスの最新状態を即時参照
ストレージ・ライセンス費用高額;CRM ストレージ容量を圧迫し二重の保管コストが発生最小限;高価な CRM ストレージを消費せず外部レイクハウスを活用
コンテキスト取得遅延低速;実行時に多数の関連 SOQL クエリを実行し遅延が発生ミリ秒単位;階層型データグラフにより単一 JSON として瞬時にロード
セキュリティ・ガバナンス分断;複数システム間で権限同期が必要となりリスクが増大一元化;データソース側のアクセス制御を尊重し Trust Layer で保護
推論コンテキストの網羅性CRM 内の限定された項目のみに制限され盲点が生じやすい全社網羅;ERP、レイクハウス、IoT ログ、文書ナレッジを包含

8. エンタープライズアーキテクトのための設計原則とベストプラクティス

本アーキテクチャを本番稼働させるにあたり、アーキテクトが遵守すべきベストプラクティスを整理します。

1. ファイルフェデレーションとクエリフェデレーションの使い分け

2. 外部データウェアハウスのコンピュートコスト急増防止

インタラクティブなチャットセッション中にフルテーブルスキャンなどの重いクエリがプッシュダウンされると、外部ウェアハウスのクレジット消費が跳ね上がります。

3. データグラフの適切な粒度設計

何百ものフィールドを含む単一の巨大データグラフを設計してはなりません。過度に巨大な JSON は LLM のコンテキストウィンドウを浪費し、推論コストを跳ね上げるだけでなく、無関係なノイズによって Atlas の推論精度を低下させます。エージェントの「トピック(Topic)」ごとに特化した軽量なデータグラフを設計してください。

4. マルチエージェントによるガバナンス分離

単一の巨大な汎用エージェントを構築するのではなく、業務ドメインごとに専門化されたサブエージェント(カスタマーサポート用、契約更新用、技術サポート用など)を設計します。更新系アクション(返金処理や契約更新など)には、Flow や Apex 側で厳格な権限チェックや人手による承認(Human-in-the-Loop)フローを組み込みます。


まとめ

ゼロコピーアーキテクチャを活用して Agentforce を Salesforce Data Cloud にグラウンディングすることは、エンタープライズデータ戦略の決定的な転換点です。データの複製負債や同期遅延を完全に排除しながら、全社規模のリアルタイムコンテキストを自律型 AI エージェントに供給することが可能になります。Apache Iceberg 連携、CIM セマンティックモデル、階層型データグラフ、そして Einstein トラストレイヤーの組み合わせにより、企業は安全性と高い投資対効果を両立させた「自律型デジタル労働力」を本格展開できます。


参考資料