【アーキテクチャ解説】AJO×CDP（AEP）連携の実践。BtoBマーケティングDXを成功に導くデータモデル設計

最終更新日：2026年4月6日

1. なぜBtoB企業が「AJO×CDP（AEP）」を求めるのか？（従来型MAの限界）

BtoBの購買プロセスは複雑で長期にわたり、複数の意思決定者が関与します。これまでBtoB企業は、Marketo EngageやAccount Engagement（旧Pardot）といったMAツールを用いてリードナーチャリングを行ってきました。

しかし、既存のMAツールは主に「RDB（リレーショナルデータベース）ベースのバッチ処理」をアーキテクチャの主軸としています。つまり、15分〜数時間ごとのバッチ処理でスコアを計算し、セグメントを評価する仕組みです。
これに対し、今日のBtoBバイヤーは「特定ソリューションの価格ページを3分間閲覧し、その後すぐにウェビナーのアーカイブ動画を視聴した」といった、ミリ秒単位で変化するデジタル上のシグナルを発しています。バッチ処理主体のMAでは、この「今、最も関心が高まっている瞬間（モーメント）」を捉えきれず、数時間後や翌日に的外れなアプローチをしてしまう機会損失が発生していました。

AJOとAEPの連携は、この課題を「ストリーミング・アーキテクチャ」によって解決します。Adobeのグローバルなエッジネットワークを活用し、顧客がWebやアプリで行動を起こした瞬間にデータがAEPに流入。即座に「リアルタイム顧客プロファイル」が更新され、AJOのジャーニー（イベントノード）が発火する「イベントドリブン」な基盤を提供します。

2. AEP最大の難所：BtoB特有の「データモデル（XDM）」とIDグラフ設計

AJOを稼働させるためには、基盤となるAEP上でデータを統合する必要があります。ここでBtoB企業が直面する最大の難所が、XDM（Experience Data Model）の設計とIDのステッチング（名寄せ）です。

Account（企業）とPerson（個人）の多対多モデル

BtoCであれば「1人の顧客＝1つのプロファイル」でシンプルですが、BtoBでは「1つの企業（Account）」に「複数の担当者（Person）」が紐付き、さらに「複数の商談（Opportunity）」が紐付くリレーショナルな構造を持ちます。
AEPでこれを表現するためには、標準のB2C向けスキーマではなく、「Real-Time CDP B2B Edition」等で提供されるBtoB専用のXDMクラス（XDM Business Account, XDM Business Contact等）を用いてデータモデルを厳密に設計する必要があります。

CRM連携におけるペイロードとIDグラフの壁

Salesforce等のCRMからAEPへデータを取り込む際、「リードID」「取引先責任者ID」「メールアドレス」など、どの識別子をプライマリキーとして「ID名前空間（Identity Namespace）」を定義するかが重要です。
この設計を誤ると、Webサイトを回遊している「匿名のCookie ID」と、フォーム入力後に付与される「CRMのリードID」がAEPの「IDグラフ」上で結合されず、「Webで活発に行動しているのに、AJOからは新規リードとして扱われてしまう」というセグメントの分断を引き起こします。

3. 【公式事例と一次情報】AJO連携によるパーソナライズの実現

ストリーミング・アーキテクチャがビジネスにどのようなインパクトをもたらすのか。アドビの公式事例と、コンサルティング現場での一次情報から、具体的なユースケースを読み解きます。

BtoBにおける一次情報：特定資料DLからウェビナー離脱までのリアルタイムフォロー

私たちが支援したBtoBのSaaS企業では、AJOを以下のように活用しています。
リードが「セキュリティに関するホワイトペーパー」をダウンロードした数日後、AJOが自動で「セキュリティ対策ウェビナー」の案内メールを送信。リードがウェビナーの登録ページにアクセスしたものの、フォームを入力せずに離脱した（直帰した）ことをAEPがイベントとして検知します。
AJOはこの「離脱イベント」をトリガーに、わずか30分後に「ウェビナーのダイジェスト版動画（登録不要）」を案内するフォローアップメールを送信。さらに、動画を70%以上視聴した時点で、SalesforceのToDoオブジェクトに対してAPI経由で「営業からの即時架電アラート」を自動起票するジャーニーを構築しました。これにより、インサイドセールスの商談化率が劇的に改善しました。

4. 実装現場で頻発する「3つの技術的な壁」とアーキテクトの回避策

AJOとCDP（AEP）の導入プロジェクトにおいて、ツール自体のバグではなく、要件定義やアーキテクチャ設計の甘さから炎上するケースが散見されます。実務現場で頻発する3つの落とし穴と回避策を公開します。

1. XDMスキーマとWeb SDKペイロードの不一致（イベントが発火しない）
   AJOのキャンバスで「特定ページの閲覧」をトリガーに設定したのに、ジャーニーが開始されないケース。原因の大半は、Webサイト側の計測タグ（AEP Web SDK）が送信するペイロードと、AEP側で定義したXDMスキーマのフィールドマッピングがズレており、データストリームのエラーとして弾かれていることです。
   実装フェーズにおいて、AEPの「データストリームモニタリング機能」とブラウザのデベロッパーツール（Networkタブ）を用いて、ペイロードが欠損なくAEPに到達し、プロファイルにパースされているかをエンドツーエンドで徹底的に結合テストする。
2. 同意管理（Consent）スキーマの設計漏れによるガバナンス違反
   「オプトアウト（配信停止）」を希望した顧客に対し、AJOから自動メールが送信されてしまう法的なインシデント。AEP上に同意フラグ（Consent）を保持するスキーマが存在しない、またはAdobeのデータガバナンス機能（DULEポリシー）が正しく配信アクションに適用（エンフォース）されていないことが原因です。
   個人情報保護法やGDPRに対応するため、必ず標準の「Consentスキーマ」を利用して同意データをAEPに格納し、AJOのジャーニー設定時に「マーケティング許可フラグがTrueのプロファイルのみ」をフィルタリングするビジネスポリシーをシステムレベルで強制する。
3. カスタムアクションのペイロード肥大化によるタイムアウト
   ジャーニー内で外部のAPI（自社のレコメンドエンジン等）をCustom Actionで叩き、製品情報を取得してメールに埋め込む際、外部APIのレスポンスが遅い、または返却されるJSONペイロードがAJOの制限を超えて重すぎるために、アクションがタイムアウト（失敗）するケースです。
   AJOから叩く外部APIは、ミリ秒単位の高速なレスポンスが求められます。必要なデータのみを最小限のペイロードで返すよう、中間API（BFF: Backend For Frontend）層を設けるか、事前にAEPのプロファイル属性として必要なデータをバッチで格納しておくアーキテクチャを検討する。

5. Marketo・SFMC等、従来型MAとの技術的な違いと棲み分け

「すでにAdobe Marketo EngageやSalesforce Marketing Cloud（SFMC）を導入しているが、AJOへのリプレイスが必要か？」という技術的な議論に対する結論です。

【アーキテクトの視点】 エンタープライズ領域では、既存のMAを完全に捨てるのではなく「役割の分離（コンポーザブル・アーキテクチャ）」がトレンドです。
新規リードの獲得からスコアリングを通じた営業パスまでの「BtoBの王道プロセス」は引き続きMarketoで処理しつつ、契約後の既存顧客に対する「モバイルアプリを起点としたリアルタイムなアップセル体験」や「解約リスク検知時の即時フォロー」といった領域にAJO（とAEP）を適用する、という棲み分けが現実的な最適解となります。

6. まとめ：データドリブンDXは「アーキテクチャ設計」から始まる

Adobe Journey Optimizer（AJO）とCDP（AEP）の連携は、貴社のマーケティング活動を「バッチ処理ベースの一括配信」から「顧客のモーメントを捉えたリアルタイムなオムニチャネル体験」へと進化させる強力なインフラです。

しかし、その導入の成否は「AJOの画面設定」ではなく、「AEPのXDMスキーマ設計」「BtoB特有のIDグラフの統合」「APIのペイロード要件」といった、見えないデータエンジニアリングの領域にかかっています。

「自社の実現したいBtoBのユースケースが、現在のAEPのデータモデルで実現可能か診断してほしい」「既存のMarketoとAJOをどう連携・移行させるべきか、アーキテクチャのセカンドオピニオンが欲しい」といった技術的な課題をお持ちであれば、ぜひ一度ご相談ください。