Salesforce と MCP｜Data Cloud／API 前提のカスタムMCP設計の論点（標準MCP有無は要調査）

Salesforceのエコシステムにおいて、リアルタイムパーソナライゼーションを担う「Marketing Cloud Personalization（以下、MCP／旧Interaction Studio）」の立ち位置が、Data Cloudの台頭によって劇的に変化しています。かつてのMCPは、WebサイトにJavaScriptのビーコンを埋め込み、その中だけで完結するパーソナライゼーションツールとして機能していました。

しかし、現在のエンタープライズ設計では、Data Cloudを「信頼できる唯一の情報源（SSOT）」とし、MCPを「実行エンジン」として切り分けるアーキテクチャが主流です。ここで問題となるのが、「標準機能でどこまで繋がるのか、どこからがAPIによるカスタム開発なのか」という境界線です。本記事では、実務者が直面するData CloudとMCPの設計論点を、API活用を前提としたテクニカルな視点で深く掘り下げます。

Salesforce Data CloudとMCP連携の現在地

まず前提として、MCPにおける「Data Cloud標準コネクタ」の現状を整理します。Salesforceは現在、Data Cloudとのネイティブな統合を強化していますが、すべてのユースケースがGUI上の設定だけで完結するわけではありません。

Data CloudからMCPへの標準連携

現時点において、Data Cloudで作成した「計算済みインサイト」や「セグメント」をMCPへ送信する機能は、標準のアクティベーション（Activation）機能として提供されています。これにより、Data Cloudで分析した「離脱リスクの高い顧客」や「特定カテゴリへの関心が強い顧客」というセグメント情報をMCPに渡し、Webサイト上でのレコメンドに反映させることが可能です。

MCPからData Cloudへの標準連携

逆に、MCPで収集したリアルタイムの行動ログ（クリックや閲覧）をData Cloudへ流し込む場合、MCPの「Data Cloud Connector」を利用します。これはMCPからData CloudのインジェクションAPIを叩く設定をパッケージ化したもので、スキーマのマッピングを行うことで、MCP側のイベントをData Cloudのデータストリームとして取り込めます。

なぜ「カスタム設計」が必要になるのか

標準コネクタがあるにもかかわらず、なぜAPI前提のカスタム設計が議論されるのでしょうか。理由は主に3つあります。

1. ID解決の不整合: MCP独自のIdentity Strategyと、Data CloudのIdentity Resolutionを完全に同期させるには、API経由でのID注入が必要になる。
2. 超低遅延の要求: 標準のアクティベーションによるセグメント同期には数時間のラグが発生する場合があり、数秒前の行動をトリガーにするにはAPIベースの「Interaction」設計が不可欠。
3. マルチチャネル連携: LINEや独自アプリなど、Web以外の接点でData Cloudのプロファイルに基づいたMCPのオファーを出したい場合、サーバーサイドAPI（Interaction API）の作り込みが避けられない。

このような高度なデータ連携については、高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定と公式事例でも触れている通り、コスト対効果を考慮したアーキテクチャの取捨選択が重要になります。

Data Cloud ⇔ MCP 連携の主要な3つの論点

論点1：セグメント同期の「鮮度」と「トリガー」

Data CloudのセグメントをMCPで利用する場合、その更新頻度がパーソナライゼーションの精度を左右します。標準の「アクティベーション」はバッチ処理に近い挙動を示すため、昨日の行動に基づいたセグメント分けには適していますが、「たった今、商品をカートに入れた」という状態を即座にMCP側に反映させるには、Data Cloudの「データグラフ」や「ストリーミングインサイト」を活用し、API経由でMCPへイベントを発火させる設計が必要です。

論点2：スキーマの整合性とID解決（Identity Resolution）

MCPは独自のユーザーデータベースを持っており、Cookieやメールアドレスをキーにユーザーを管理します。一方でData Cloudは、複数のソース（Salesforce CRM、Web、モバイル）からデータを集約し、統合された「Unified Individual ID」を発行します。この「MCP側のユーザーID」と「Data Cloud側の統合ID」をどう紐付けるかが最大の論点です。

実務的には、MCPのWeb SDKが発行する anonymousId をData Cloudに送り、Data Cloud側で名寄せされた結果の UnifiedId をMCPのプロファイル属性に書き戻すといった、APIによる双方向の同期設計が推奨されます。

論点3：リアルタイム性の要求レベルとAPIの使い分け

全てのデータをリアルタイムで同期しようとすると、APIのコール数上限やパフォーマンス劣化を招きます。
以下の表に、実装パターンの比較をまとめました。

カスタムMCP設計におけるAPI活用手順

Data Cloudを前提としたMCPのカスタム設計では、MCPを単なる「JavaScript配信ツール」としてではなく、「意思決定API」として利用します。

ステップ1：Data Cloudでの「Data Graphs」構築

まず、Data Cloud側でMCPが必要とする属性（過去の購入履歴、最新のLTV、好みのカテゴリなど）を「Data Graphs」として定義します。Data Graphsを使用することで、複雑な関連オブジェクトを1つのJSON形式で高速に取得可能になります。

ステップ2：Interaction APIによるオファーの取得

フロントエンド（React/Next.jsなど）またはサーバーサイドから、MCPの Interaction API を呼び出します。この際、リクエストパラメータにData Cloudの統合IDを含めることで、MCPはData Cloud側の最新ステータスを参照して最適なアクション（コンテンツIDやクーポンコード）をレスポンスします。

公式ドキュメント参照: MCPのAPI仕様については、Salesforce Developerドキュメントの「Personalization Interaction API」を参照してください。認証にはOAuth 2.0が必要であり、アクセス元のIP制限設定も実務上必須となります。

ステップ3：イベントのフィードバックループ

MCPが提示したオファーに対してユーザーがどう反応したか（クリックしたか、無視したか）を、再びMCP経由でData Cloudへ送信します。このループを回すことで、Data Cloud上の機械学習モデル（Einstein）が洗練され、次回のMCPによるパーソナライゼーション精度が向上します。

このデータ循環の重要性は、広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャで解説している広告最適化の仕組みとも共通する思想です。

実務上の注意点とエラー対策

カスタム設計を進める上で、現場で必ず遭遇するトラブルと対策を挙げます。

1. APIレスポンス遅延（Latency）

MCPのAPIレスポンスが遅れると、Webサイトの表示がガタつく「フリッカー現象」が発生します。これを防ぐために、サーバーサイドで事前にMCPのオファーを取得しておく「プレフェッチ」設計や、タイムアウト時のフォールバック（デフォルトコンテンツの表示）を必ず実装してください。

2. IDの不一致によるプロファイルの断片化

Webサイトでログイン前（匿名）とログイン後（既知）でIDが変わる際、MCP側で正しくマージ処理が行われないと、Data Cloud側に「同一人物の別人データ」が大量に送られることになります。MCPの Identity Strategy 設定において、どの属性を「主キー」とするかをData CloudのID解決ルールと完全に一致させてください。

3. 計測タグの重複

Data Cloud Web SDKとMCP SDK（Web SDK）を両方導入する場合、ページビューイベントが重複してカウントされる「二重計測」のリスクがあります。現在は、Data Cloud Web SDKからMCPへイベントを転送する構成、またはその逆の構成を選択し、シングルタグでの運用を目指すのがベストプラクティスです。

このようなタグマネジメントやID連携の基礎については、WebトラッキングとID連携の実践ガイド。ITP対策・LINEログインを用いたセキュアな名寄せアーキテクチャが参考になります。

まとめ：次世代パーソナライゼーションの構築に向けて

Salesforce MCPとData Cloudの連携は、「標準機能で繋いで終わり」というフェーズを過ぎ、APIを活用した「いかにビジネスロジックをデータ基盤へ統合するか」という設計能力が問われるフェーズに入っています。標準コネクタはあくまで補助輪であり、真に顧客体験を最大化するためには、以下の方針で設計を進めるべきです。

• データはData Cloudに集約し、MCPは「出し分け」の実行に専念させる。
• ID解決のロジックを両者で同期させ、プロファイルの断片化を防ぐ。
• リアルタイム性が求められる接点にはInteraction APIによるカスタム実装を検討する。

ツールの機能を追うのではなく、データの流動性を設計の起点に置くことで、Salesforce投資のROIを最大化することが可能になります。