【第553回】Salesforce 認定 Marketing Cloud Next コンサルタント 資格試験 が正式発表

待望の Salesforce 認定 Marketing Cloud Next コンサルタント 認定資格がついに登場しました。

認定 Marketing Cloud Next Consultant 試験ガイドは こちら

📝 試験概要

Salesforce 認定 Marketing Cloud Next コンサルタントは、コンサルティングまたは導入業務において Marketing Cloud Next を実際に操作する仕事です。Marketing Cloud Next コンサルタント認定資格は、Marketing Cloud Next ソリューションの導入、構成、最適化に必要な知識、スキル、経験を持つことを証明します。Marketing Cloud Next コンサルタント認定資格に合格するには、コンサルティングまたは顧客対応業務において、Marketing Cloud Next の導入または管理に関する 6 ～ 12 ヶ月以上の実務経験レベルを有している必要があります。

• 2026 年 8 月 21 日（金）から 試験開始  ※英語提供のみ

• 選択式 60 問（加えて採点対象外の問題が最大 5 問）

• 試験時間：105 分

• 合格ライン：72 %（43 問以上で合格）

• Summer '26 リリースの内容に準拠

• 受験資格（前提資格）：なし

📚 試験範囲

1.  プラットフォーム設定とガバナンス（13%）… 8 問

2.  同意管理（13%）… 8 問

3.  データモデリング、ID 解決、セグメント（25%）… 15 問

4.  キャンペーン、フロー、コンテンツ（30%）… 18 問

5.  Agentforce と AI イノベーション（11%）… 6 問

6.  分析とパフォーマンスインサイト（8%）… 5 問

試験ガイドに掲載されている以下の内容は、試験勉強を行う上での重要なヒントになっています。

• ディスカバリーセッションを実施し、Marketing Cloud Next の導入戦略を設計できる。

• Marketing Cloud Next のガバナンスについて顧客へアドバイスできる。

• ビジネスユニットとデータスペースの 1:1 の関係を活用し、業務要件に応じたデータ分離戦略を設計・実装できる。

• DKIM や SPF を利用したドメイン認証を設定し、専用 IP の自動スケーリングを適切に管理できる。

• 同意管理およびコンプライアンス要件を理解し、顧客エンゲージメントに適用できる。

• データモデルオブジェクト（DMO）、ID 解決、セグメントなど、Data 360 の主要な概念を理解し活用できる。

• DMO 間のデータ連携を確認しながら、マーケティングデータパイプラインの問題を分析・解決できる。

• Handlebars などのパーソナライズ機能を利用して、クロスチャネルコンテンツを最適化できる。

• フローを利用したキャンペーンオーケストレーションやマルチチャネルメッセージングを設計・構成できる。

• Agentforce を利用して、キャンペーン作成や会話型メッセージングなどのマーケティングユースケースを実装できる。

• Agentforce Marketing Agents を活用し、キャンペーン作成やオーディエンス生成を安全に自動化できる。

• Salesforce 標準のレポートや分析機能を活用・拡張できる。

一方で、以下の分野は試験の対象範囲外です。

• 独自の大規模言語モデル（LLM）の開発や外部 AI モデルの管理

• AMPscript や SQL の高度なプログラミング

• MuleSoft を利用した複雑な API 連携や、大規模な Apex 開発（高スループットなトランザクションメール送信に必要な基本的なデータプロバイダーの実装を除く）

• Data 360 の Zero Copy や Data Share の範囲外で実施する、外部データレイクにおけるデータベース管理作業

試験対策 Trailhead も公開

さらに、公式の試験対策 Trailhead も公開されています。

Prepare for Your Marketing Cloud Next Consultant Certification

模擬試験

以下は、私が作成した模擬試験です。試験前に力試しでお試しください。

「難易度：高」は、ガチで難しいです。心してかかってください！🔥

私の学習メモ

Data 360 コンサルタントの時同様、私の試験勉強で使っているメモをここに記載していきます。これらは実際の運用においても 最低限知っておくべき知識 です。実際はもっと高度であることは言うまでもありませんが、これらが運用をしていくための基礎になってきますので、資格学習を通じてしっかりと学んで行きましょう。

一つひとつの機能を念入りに確認したい場合は、以下の記事を参照してください。Marketing Cloud Next の記事のまとめサイトになっています。

それでは、以下、各セクションごとに確認していきましょう。

プラットフォーム設定とガバナンス

（割合：13%）… 8 問想定

このセクションでは、Marketing Cloud Next の初期構成やガバナンスに関する知識が問われます。ガバナンスとは、平たく言えば、ユーザー権限や共有設定、ビジネスユニットやデータスペース設定のことです。

• ディスカバリーセッションを実施し、Marketing Cloud Next の導入戦略を設計できる。

• Marketing Cloud Next の環境構築について説明できる（コア組織のエディション要件、Data 360 のプロビジョニング、データキットのインストール、権限セットなど）。

• ビジネスユニットとデータスペースの 1:1 の関係を活用し、業務要件に応じたデータ分離戦略を設計・実装できる。

• シナリオに応じて、ビジネスユニットが必要となるケースを判断し、ロールや 拡張 CMS ワークスペースを利用した適切なコンテンツおよびユーザーガバナンスモデルを構成できる。

• シナリオに応じて、ブランド化された認証済みメール送信のために、セルフサービスのドメイン認証またはドメイン認可を構成できる。

• 専用 IP の自動スケーリングを適切に管理できる。

ディスカバリーと導入戦略

Marketing Cloud Next の導入では、最初から製品や機能を決めるのではなく、ディスカバリーセッション（Discovery Session）を実施して、顧客の現状や要件を把握します。

ディスカバリーで確認すること

主に次のような内容を確認します。

• ビジネス目標とユースケース：何を実現したいのか、どの KPI で成果を測るのか

• 現在の環境：Marketing Cloud Engagement / Account Engagement など、現在利用している製品や課題

• データ：顧客データがどこに存在し、どのデータを Data 360 で利用するのか

• チャネルと同意：Email / SMS / WhatsApp など、利用するチャネルと同意管理

• 組織とガバナンス：ブランドや地域の分離、ユーザー、権限など

導入戦略を設計する

ディスカバリーで確認した内容から、ビジネス要件を Marketing Cloud Next の具体的な構成へ落とし込みます。

例えば、

複数ブランドを分離したい
→ ビジネスユニット / データスペースを検討

複数システムの顧客を統合したい
→ Data 360 / ID 解決を検討

既存の Marketing Cloud Engagement を利用している
→ 既存環境を活用しながら Marketing Cloud Next を段階的に導入

すべてを一度に導入する必要はありません。優先度が高く、効果を測定しやすいユースケースから開始し、段階的に拡張することも重要です。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• 機能から考えるのではなく、まずビジネス目標とユースケースを理解する

•  現在の システム・データ・チャネル・同意・組織構造を把握する

• 要件を Data 360、ID 解決、ビジネスユニット、チャネルなどの設計に落とし込む

• 既存環境を必ず置き換える必要はなく、Quick Win / Pilot Use Case から段階的に導入することも検討する

試験で「コンサルタントが最初に何をすべきか？」と問われた場合は、いきなり設定を始めるのではなく、まず顧客のビジネス要件と現在の環境を理解するという考え方を意識しましょう。

Marketing Cloud Next のセットアップを開始する

Marketing Cloud Next のセットアップを開始する前に、設定を行うユーザーに必要な権限が付与されていることを確認します。

必要なのは、次の 3 つです。

• システム管理者（System Administrator）プロファイル

• データクラウドアーキテクト（Data Cloud Architect）権限セット

• マーケティングクラウド管理者（Marketing Cloud Admin）権限セット

Marketing Cloud Next におけるユーザー権限

標準のマーケティング権限セットとして、以下が用意されています。

• マーケティングクラウド管理者
  Salesforce の設定、Agentforce 管理画面、プロンプトテンプレートマネージャーへのアクセス、およびキャンペーン、セグメント、フローに対する完全な制御権限

• マーケティングクラウドマネージャー
  キャンペーン、セグメント、キャンペーン（管理者以外）フローを完全に管理する権限、および Agentforce とプロンプトテンプレートを使用するためのアクセス権

初期セットアップの流れ

Marketing Cloud Next の初期セットアップでは、主に次のステップを実行します。

1. Data 360 を有効化する

2. Salesforce CRM コネクタを作成する

3. デフォルトのメールチャネルを追加する

4. レコードにデータ保護の詳細を追加する

5. データスペースを選択する

Salesforce Go 画面でのセットアップ

Marketing Cloud Next のセットアップでは、Salesforce Go も利用できます。

Salesforce Go は、Marketing Cloud Next の機能を一元化された画面から発見・設定・構成するためのセットアップ画面です。

最初は Initial Setup カードを利用することで、Marketing Cloud Next のインストールやデータストリームの設定など、利用開始に必要な基盤構築を進めることができます。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• セットアップには、System Administrator、Data Cloud Architect、Marketing Cloud Admin の 3 つの権限が必要

• 初期セットアップでは、Data 360 の有効化 → CRM コネクタ → メールチャネル → データ保護 → データスペースという大まかな流れを理解する

• 初期セットアップはガイドに沿ってほぼ半自動的に進められるため、細かなクリック手順を暗記する必要はない

• Salesforce Go は、Marketing Cloud Next の機能を一元的に発見・設定・構成するために利用する

Marketing Cloud Next で必要なデータキット

Marketing Cloud Next は Data 360 を基盤としているため、利用開始時に必要な データキットをインストール・デプロイ して、マーケティングで使用する DMO やデータストリームを準備します。

このインストール・デプロイは、「インストール」の開始ボタンをクリックして開始されますが、初回はすべてのデータキットが強制的にインストール対象となります。実行でエラーが発生した場合は、再実行することが可能です。それでも解決しない場合は、サポートへ連絡します。

主なデータキットは、以下の通りです。

• Marketing Setup Objects Data Kit：マーケティング設定・同意関連

• Consent Objects Data Kit：同意データ

• Flows Integration Data Kit：フロー実行データ

• Email Channel Data Kit：メールエンゲージメントデータ

• SMS Channel Data Kit：SMS エンゲージメントデータ

• WhatsApp Channel Data Kit：WhatsApp エンゲージメントデータ

• Sales：取引先、リード、取引先責任者などの CRM データ

※ SMS と WhatsApp のデータキットは、それぞれのアドオンを利用する場合のみ必要です。

データキットは、年に数回「更新」が必要です。更新待ちになっている場合は必ず更新を実行してください。

Marketing Cloud Next セットアップにおける ID 解決

後に「ID 解決」については、テーマとして扱いますが、Marketing Cloud Next セットアップでは、データキットのインストールの後に、ID 解決を行うステップが用意されています。

ID 解決を行う目的は、Data 360 内の各人物について、一貫性のある単一の顧客プロファイルが作成し、チームが顧客に重複メールを送信することを避け、同意を正しく適用し、各顧客を同一人物として認識するためです。

このセットアップ段階で、ID 解決を実行した場合のルールセットは以下になります。

1. Normalized Email（正規化されたメール）
   重複するメールアドレスをマッチングします。

2. Lead to Contact（リードから取引先責任者へ）
   リードが取引先責任者へ変換される際の重複を防止します。

3. Device to Known（デバイスと既知のプロファイル）
   Web 訪問者を既知のプロファイルと照合します。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• Marketing Cloud Next は Data 360 を基盤としている

• すべてのデータキットは、インストールボタンを押下後は、自動的にインストールされ、デプロイされる

• SMS / WhatsApp のデータキット → 各アドオン利用時のみ必要

• Marketing Cloud Next の初期セットアップでは、データキットのインストール後に ID 解決の設定が用意されている ことを覚えておきましょう。

ここで作成されるルールセットに含まれる次の 3 つのマッチングルールは、名称と目的をセットで押さえてください。

• Normalized Email：メールアドレスによる照合

• Lead to Contact：変換前のリードと変換後の取引先責任者を照合

• Device to Known：匿名の Web 訪問者を既知のプロファイルと照合

ビジネスユニットの基本

Marketing Cloud Next では、ビジネスユニットを利用して、地域、ブランド、製品ラインなどの単位でマーケティング活動を分離して管理できます。

※ ビジネスユニットは Marketing Cloud Next Advanced Edition でのみ利用できます。

ビジネスユニットとデータスペースの関係

ビジネスユニットを作成するときは、1 つのビジネスユニットに対して 1 つのデータスペースを関連付けます。

ビジネスユニット ↔ データスペース = 1 対 1

1 つのデータスペースを複数のビジネスユニットで使用することはできません。

これにより、データスペースでデータを分離しながら、ビジネスユニット単位でキャンペーン、コンテンツ、ユーザーなどのマーケティング活動を管理できます。

ビジネスユニットの有効化

初めてビジネスユニットを有効化するときは、最初に 2 つのビジネスユニットを作成する必要があります。そのため、事前に 2 つ以上のデータスペースを準備しておく必要があります。

既存のマーケティング設定は最初のビジネスユニットへ引き継がれ、組織のデフォルトのマーケティングワークスペースも、最初のビジネスユニットのデフォルトワークスペースとして割り当てられます。

また、ビジネスユニットを作成した後は、関連付けたデータスペースや CMS ワークスペースを変更または削除できません。

キャンペーンでのビジネスユニット

キャンペーンのすべての要素は、選択したビジネスユニットの範囲内で動作します。

キャンペーンページにビジネスユニットのドロップダウンが表示されていない場合は、キャンペーンオブジェクトのページレイアウトの「キャンペーン情報」セクションにビジネスユニット項目を追加します。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• ビジネスユニットは Advanced Edition で利用可能

• ビジネスユニット ↔ データスペースは 1 対 1

• 1 つのデータスペースを複数のビジネスユニットで使用することはできない

• 初回有効化には 2 つのビジネスユニットと 2 つ以上のデータスペースが必要

• ビジネスユニット作成後は、関連付けたデータスペースや CMS ワークスペースを変更・削除できない

ビジネスユニットのメンバー

ビジネスユニットのメンバーになるには、Marketing Cloud Admin または Marketing Cloud Manager のいずれかの権限セットが必要です。

これらの権限セットを持つ既存ユーザーは、ビジネスユニットを初めて有効化した際に、最初のビジネスユニットのメンバーとして追加されます。

ユーザーをビジネスユニットへ追加するときは、主に次の 2 つのロールを使用します。

① Marketer-Standard

キャンペーンのフローを有効化できます。

また、マーケティングワークスペースではコンテンツマネージャーとして、コンテンツの作成、編集、表示、公開が可能です。

② Marketer-ReadOnly

キャンペーンのフローを有効化することはできず、ビジネスユニットのマーケティングワークスペースにもアクセスできません。

一方で、プロモーションメッセージの送信やパフォーマンスダッシュボードの閲覧は可能です。

マーケティングワークスペースへのアクセス

Marketer-Standard は、ビジネスユニットのマーケティングワークスペースでコンテンツマネージャーロールを取得します。

Marketer-ReadOnly のユーザーにワークスペースへのアクセスを追加したい場合は、そのユーザーをワークスペースの投稿者として追加し、コンテンツ管理者ロールを割り当てることで調整できます。

ただし、メンバーの CMS ワークスペースへのアクセス権を減らすことはできません。

DLO のデータをビジネスユニットごとに分離する

DLO のデータスペースフィルターにビジネスユニット用のフィルターを追加することで、各ビジネスユニットで利用するデータを分離できます。

フィルターには BusinessUnitId または DataSpaceId を使用します。

既存の DLO にデータスペースフィルターがない場合、または OR 条件で作成されている場合は、ビジネスユニット用のフィルターが自動的に追加されます。

一方、既存フィルターが AND 条件の場合は、自動追加されません。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• ビジネスユニットのメンバーには Marketing Cloud Admin または Marketing Cloud Manager 権限セットが必要

• Marketer-Standard → キャンペーンでフローを有効化できる

• Marketer-ReadOnly → キャンペーンでフローを有効化できない

• DLO のデータは、BusinessUnitId または DataSpaceId を使用してビジネスユニットごとに分離できる

• 既存フィルターがない、または OR 条件 → ビジネスユニットフィルターを自動追加

• 既存フィルターが AND 条件 → 自動追加されない

Summer ’26 でのビジネスユニットの強化

Summer ’26 では、ビジネスユニットの運用機能が大きく強化されました。

主な変更点は、次の通りです。

• 最大 150 ビジネスユニットを作成可能

• 不要になったビジネスユニットを非アクティブ化可能

• ビジネスユニットごとに Web カスタムフォントを割り当て可能

• 共通アセットライブラリ（Common Asset Library）を利用して、ビジネスユニット間でコンテンツを共有可能

Spring ’26 のリリース当初は最大 50 ビジネスユニットでしたが、Summer ’26 では 150 に拡張されています。

ビジネスユニットの非アクティブ化

Summer ’26 から、不要になったビジネスユニットを非アクティブ化できるようになりました。

ただし、非アクティブ化は元に戻すことができない永続的な操作です。

非アクティブ化する前には、キャンペーンに関連するアクティブなフローを無効化し、そのビジネスユニットの Marketing Performance Intelligence をアンインストールする必要があります。

また、組織には最低 1 つのアクティブなビジネスユニットが必要なため、最後のビジネスユニットは非アクティブ化できません。

非アクティブ化したビジネスユニットに関連付けられていたデータスペースを、別のビジネスユニットで再利用することもできません。

ビジネスユニット間でコンテンツを共有する

Summer ’26 から、コンテンツを共通アセットライブラリへ公開し、別のビジネスユニットが自分のワークスペースへコピーして利用できるようになりました。

これにより、マーケティング活動はビジネスユニットごとに分離しながら、必要なコンテンツは組織全体で共有できます。

共有したアセットを削除できるのは、Marketing Cloud Admin と、そのコンテンツを投稿したユーザーです。

コミュニケーション登録をビジネスユニットに割り当てる

コミュニケーション登録（Communication Subscription）は、作成時に利用範囲を指定できます。

• All Business Units：すべてのビジネスユニットで利用

• Single Business Unit：特定の 1 つのビジネスユニットのみで利用

既存のコミュニケーション登録は、自動的に All Business Units に割り当てられます。

Single Business Unit を選択した場合は、そのビジネスユニットに割り当てられているチャネルのみ追加できます。

また、コミュニケーション登録を作成した後に、利用範囲を変更することはできません。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• Summer ’26 では最大 150 ビジネスユニットを作成可能

• ビジネスユニットは非アクティブ化できるが、元に戻せない

• 非アクティブ化したビジネスユニットのデータスペースは再利用できない

• 共通アセットライブラリを利用して、ビジネスユニット間でコンテンツを共有できる

• Einstein Metrics Guard はビジネスユニットではサポートされていない

• コミュニケーション登録は All Business Units / Single Business Unit から利用範囲を選択する

• 既存のコミュニケーション登録 → All Business Units

• Single Business Unit → そのビジネスユニットに割り当てられたチャネルのみ追加可能

• コミュニケーション登録の利用範囲は作成後に変更できない

送信者アイデンティティーを確立する

Marketing Cloud Next から信頼性が高く、コンプライアンスに準拠したメールを送信するためには、信頼できる送信者アイデンティティーを確立することが重要です。

まず、商用メールには組織の有効な物理住所を表示する必要があります。これは CAN-SPAM、CASL、GDPR などの法令遵守だけでなく、受信者やメールプロバイダーに対して正当な送信者であることを示し、送信者としての信頼性を高めるためにも重要です。

次に、メール送信に使用する送信ドメインを認証します。Salesforce に 送信用サブドメイン を登録すると、DNS レコード がページに生成されます。これらを DNS に公開して、Salesforce が検証することで、ステータスが「アクティブ」に変更され、そのドメインから正当にメールを送信できることが証明されます。

どのような DNS レコードを登録しているかの中身が出題されるとは考えずらいですが、念のため。

s1-e360-[DKIM Key]._domainkey.sub-domain （メールの正当性証明用）
s2-e360--[DKIM Key]._domainkey.sub-domain
s3-e360--[DKIM Key]._domainkey.sub-domain

• この 3 レコードは、DKIM です

• メールが「改ざんされていない」ことを証明

• 送信元ドメインの信頼性を上げる（到達率に影響）

anonymous.sub-domain（匿名返信用）

• 誰か分からない返信（識別できない返信）を処理

• 稀なケースのフォールバック

bounce.sub-domain（バウンス処理用）

• 配信失敗（Hard / Soft Bounce）を検知

• 自動的に購読停止やステータス更新に使われる

fbl.sub-domain（フィードバックループの受信用）

• ユーザーが迷惑メールとして報告した情報を受信

• ISP（Gmail や Yahoo など）からの苦情通知を処理

reply.sub-domain（通常の返信メールの受信用）

• ユーザーがメールに返信した内容を受信

• 問い合わせ対応や自動応答処理に利用

• Conversational Email 機能でも使用

leave.sub-domain（購読取り消しに関する処理用）

• 配信停止を希望する返信を検知

• 自動的にオプトアウト処理へ連携

ドメイン認証が完了すると、最初の 認証済み送信元アドレス（Verified From Address）も利用開始となります。同じ認証済みドメインを使用して、追加の送信元アドレス（複数作れる）を作成することもできます。

メール内のリンクにはブランドトラッキングドメインを設定できます。一般的なリダイレクトドメインではなく、自社ブランドを反映したドメインを利用することで、クリック時にも一貫した信頼性を提供できます。

ブランドトラッキングドメインの設定には、自社で用意した SSL 証明書と DNS の構成が必要であり、設定する前に送信ドメインが完全に認証されている必要があります。

また、Marketing Cloud Next では、Marketing Landing Pages に対してカスタムランディングページドメインを設定できます。

デフォルトでは Salesforce が提供するドメイン（My Domain）を利用できますが、カスタムドメインを設定することで、ランディングページの URL にも自社ブランドのドメインを使用できます。

つまり、ブランドに関連するドメイン設定は、大きく次のように整理できます。

• 送信ドメイン：メールを「どのドメインから送るか」

• ブランドトラッキングドメイン：メール内のリンクを「どのドメインで表示・追跡するか」

• カスタムランディングページドメイン：ランディングページを「どのドメインで公開するか」

この 3 つは、用途が異なるので区別して覚えておきましょう。

さらに、信頼できるメール送信では、送信者だけでなく誰に送信するかも重要です。Marketing Cloud Next では、コミュニケーション購読を利用して同意を管理し、明示的にオプトインした顧客にのみメールを送信します。既存システムですでに取得している同意については、CSV からインポートすることも可能です。（※ 次の「同意管理」セクションで解説します。）

顧客からの返信については、Reply Mail Management（返信メール管理）を利用できます。不在通知などの自動返信を除外したり、実際の顧客からの返信を指定した受信トレイへ転送（ルーティング）したり、本文の最初の 200文字に、以下の文字列が含まれている場合は自動的に購読取り消し処理を実行します。

• unsub

• unsubscribe

• opt-out

• remove

• stop

ここで重要なのは、Reply Mail Management はキャンペーン単位ではなく、認証済みドメイン単位であり、そこから送信されるすべてのメッセージに適用されることです。また、認証済みドメインが有効になっていなければ設定自体できませんので、そこを問われる可能性もあります。

最後に、Einstein Metrics Guard を有効にすることで、ボットや自動セキュリティスキャンなどによる開封やクリックを識別・除外し、実際の顧客行動に近いエンゲージメント指標を確認できます。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• プロモーショナルメールには、有効な物理住所が必要

• 送信用サブドメインの認証では DNS レコード を設定する必要がある

• Salesforce が検証を完了すると、そのサブドメインから送信可能になる

• 1 つの認証済みドメインから複数の送信元アドレスを作成できる

• 送信ドメイン、ブランドトラッキングドメイン、カスタムランディングページドメインの違いを理解する

• Reply Mail Management は返信や購読解除キーワードを処理し、認証済みドメイン全体に適用される

• 追加の送信元アドレスの設定 や、Reply Mail Management は、認証済みドメインの設定後に初めて行える

• Einstein Metrics Guard はボットなどの非人間的なアクティビティを除外し、エンゲージメント指標の信頼性を高める

専用 IP アドレスの管理

Marketing Cloud Next では、メールの送信量に応じて、共有 IP から専用 IP へ自動的に移行する Managed Dedicated IP Addresses の仕組みが提供されています。

最初は Salesforce の共有 IP プールからメールが送信されます。

その後、送信量があらかじめ定められた閾値に達すると、Salesforce が専用 IP プールを自動的に作成・割り当て、専用 IP への移行を開始します。

つまり、ユーザーが専用 IP を購入したり、手動で IP アドレスを追加したりするのではなく、送信量に応じて Salesforce が必要な送信インフラを自動的に管理する仕組みです。

送信量に応じて IP アドレスを自動管理

Salesforce は、直近 30 日間の送信履歴パターンを基に、必要な IP アドレスを動的に割り当てたり、回収したりします。

そのため、送信量が増加して追加の IP アドレスが必要になった場合でも、ユーザーが追加購入や手動リクエストを行う必要はありません。

送信量に合わせて、適切な送信インフラが自動的に維持されます。

専用 IP への移行は 30 日間

専用 IP プールが割り当てられても、すべてのメールがすぐに専用 IP から送信されるわけではありません。

専用 IP への移行が開始されると、Salesforce は30 日間かけて、共有 IP プールから専用 IP プールへメールトラフィックを段階的に移行します。

General（共有 IP）
↓
Transition（移行中）
↓
Dedicated（専用 IP）

追加の IP アドレスが必要になった場合も、同じプロセスを使用して新しい IP アドレスが追加されます。

IP 管理種別（IP Management Type）

現在どのような送信インフラを利用しているかは、IP Management Type で確認できます。

• General
  デフォルトの状態です。Salesforce が管理する共有 IP プールからメールが送信されます。

• Transition
  専用 IP プールが作成・割り当てられ、共有 IP から専用 IP へメールトラフィックを段階的に移行している状態です。

• Dedicated
  専用 IP への移行が完了した状態です。

すべての送信メールが、そのアカウントに割り当てられた専用 IP プールから送信されます。

プールタイプ

IP アドレスが所属するプールには、次の 2 種類があります。

• General（共有 IP）
  同じデプロイメントリージョン内の複数のアカウントで利用される共有 IP プールです。

• Dedicated（専用 IP）
  1 つの顧客専用に割り当てられる、1 つ以上の IP アドレスで構成された独立した IP プールです。

IP Status

個々の IP アドレスについては、IP Status から現在の状態を確認できます。

• In Progress
  共有 IP プールから新しく割り当てられた専用 IP プールへ、トラフィックを移行している途中の状態です。

• Active
  IP アドレスのプロビジョニングが完了し、実際のメール送信に利用されている状態です。

Sending IP Addresses の確認

• 現在利用している IP アドレスや送信インフラの状態は、Marketing Cloud Next の設定画面から確認できます。

• Setup → Unified Messaging → Email → Settings → Sending IP Addresses

Sending IP Addresses の一覧から、現在の構成、Pool Type、割り当てられている IP アドレスなどを確認できます。

試験のポイント

試験対策として、特に次の点を押さえておきましょう。

• Marketing Cloud Next は、デフォルトでは共有 IP プールからメールを送信する

• 送信量が一定の閾値に達すると、専用 IP プールが自動的に割り当てられる

• Salesforce は直近 30 日間の送信履歴パターンを基に、IP アドレスを動的に割り当て・回収する

• 専用 IP への移行は、30 日間かけて段階的に行われる

• IP Management Type は General → Transition → Dedicated

• General は共有 IP から送信している状態

• Transition は共有 IP から専用 IP へ移行している状態

• Dedicated はすべてのメールを専用 IP プールから送信している状態

• Pool Type は General / Dedicated

• IP Status は In Progress / Active

• 現在の状態は Sending IP Addresses から確認できる

同意管理

（割合：13%）… 8 問想定

このセクションでは、同意管理に関する知識が問われます。

以下を意識して学習を進めてください。

• 同意管理の概念と、顧客エンゲージメントおよびコンプライアンスにおける同意の役割を説明できる。

• 同意情報を管理するための標準オブジェクトの目的と相互関係を理解している。

• ビジネス要件に応じて、同意レコードの作成・管理・更新方法を選択できる。

• シナリオに応じて、マーケティングランディングページや外部ページに ウェブトラッキング用の同意バナーを設定し、同意を収集できる。

同意管理の基礎

Marketing Cloud Next の同意管理は、単純なオプトイン／オプトアウトではなく、サブスクリプション（購読）単位で管理する高度なモデルを採用しています。

例えば、「製品アップデート」に登録したとしても、自動的に「ニュースレター」へ登録されることはありません。それぞれの購読プランごとに、個別に同意を管理します。

初期状態では 「Marketing」 というデフォルトの購読プランが用意されていますが、それ以外の購読プランは必要に応じて追加して利用します。

また、同意は顧客 ID や Individual ではなく、メールアドレスや電話番号などの連絡先（Contact Point）単位で管理されます。

そのため、1 人の顧客が複数のメールアドレスを持っている場合は、それぞれのメールアドレスごとに同意が管理されます。つまり、顧客がメールアドレスを変更した場合でも、過去の同意情報は自動的に引き継がれません。

同意管理では、明示的な「はい（オプトイン）」の記録が必要です。一方で、明示的な「いいえ（オプトアウト）」を記録する必要はありません。何も同意されていない状態は、送信不可として扱われます。この考え方を Implicit Opt-Out（暗黙のオプトアウト） と呼びます。

プリファレンスセンターでは、「すべて購読解除（Unsubscribe All）」 による一括オプトアウトにも対応しています。ただし、これは永久的な配信停止を意味するものではありません。現在登録されている購読プランを一括でオプトアウトするだけであり、その後ユーザーが再度オプトインすれば、再び配信対象となります。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• 同意管理のデフォルトは「Implicit Opt-Out（暗黙のオプトアウト）」

• 明示的なオプトインがなければ送信できない

• 同意は顧客 ID ではなく、メールアドレスや電話番号などの Contact Point（連絡先）単位で管理される

• 「Unsubscribe All」は永久的な配信拒否ではなく、既存の購読を一括解除する機能

• 同意管理の対象チャネルは以下の 3 つ

  • メール

  • SMS

  • WhatsApp

同意情報の記録方法

同意管理は、CRM のチェックボックス項目で管理するものではありません。同意情報は、Data 360 のデータモデルオブジェクト（DMO）である Communication Subscription Consent に記録されます。

その後、メールなどの送信処理が開始されると、受信者のメールアドレスや電話番号などの Contact Point（連絡先） をキーとして同意レコードが参照されます。送信対象のサブスクリプションに対してオプトインが確認できた場合のみ、メッセージが送信されます。

試験では、同意管理に関連する DMO が問われる可能性があります。特に重要なのは Communication Subscription Consent ですが、念のためその他も説明しておきます。

• ① Communication Subscription
  ニュースレターや製品アップデートなど、購読プラン自体を管理します

• ② Engagement Channel Type
  メール、SMS、WhatsApp などのコミュニケーションチャネルを管理・定義します。

• ③ Communication Subscription Channel Type
  購読プランとコミュニケーションチャネルを関連付けて管理しています。

• ④ Communication Subscription Consent
  各 Contact Point（連絡先）の同意情報（オプトイン／オプトアウト）を管理します。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• 同意は Data 360 の データモデルオブジェクト（DMO）で管理される。

• 最も重要な DMO は Communication Subscription Consent 。

この Communication Subscription Consent には、主に次の情報が保存されます。

• Contact Point（メールアドレスや電話番号など）

• 同意ステータス（オプトイン／オプトアウト）

• Communication Subscription Channel Type の ID

• 同意を取得した日時

• 同意の取得ソース（API、フロー、CSV インポートなど）

同意同意管理で利用できるツール

同意管理に関連するツールとしては以下のようなものがあります。

プリファレンスセンター

ユーザー自身が購読内容を管理するための画面です。「コンテンツ」タブ（Content Builder）から作成・編集でき、企業のブランドデザインを反映した画面を作成できます。

Privacy Consent Status（※ Trailhead では Consent Status）

CRM のレコードページに配置できる Lightning Web Component（LWC）です。営業担当者やカスタマーサービス担当者は、顧客の同意状況を確認したり、必要に応じて手動で更新したりできます。

同意の手動インポート

初期導入時など、大量の同意データを CSV ファイルから一括で取り込む機能です。既存システムからの移行時によく利用されます。

A 列「メールアドレス（電話番号）」と B 列「同意日」の 2 列が必要です。同意日は DateTime 型である必要があります。また、不完全がメールアドレスはインポート時で自動的に除外されます。

フロー

同意がサポートされているフローを利用して、同意レコードの作成や更新を自動化できます。

データエクスプローラー

データエクスプローラーは、Data 360 標準のレコード検索ツールです。これを用いて、Communication Subscription Consent（DMO）を検索してください。また,、変更履歴は ConsentAuditTrail-ConsentAuditTrail（DLO）で確認でき、オプトイン・オプトアウトがいつ行われたかを年月日時分単位で確認できるため、監査用途でも利用できます。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• 手動インポート時の注意点

  • インポートに利用するファイル形式は「CSV」です。

  • メールと SMS を同時にインポートできません。

  • オプトインとオプトアウトを同時にインポートできません。

  • 複数のコミュニケーション登録を同時にインポートできません。

  • 同じコミュニケーション登録の同じメールアドレスが既に存在する場合、現在登録されている日付より未来の日付でインポートした場合のみ更新され、それ以外はインポートが無視されます。

• Privacy Consent Status は CRM レコードページに配置できる LWC（Lightning Web Component）です。

• 現在、同意がサポートされているフローは、次の 3 種類です。

  • Data Cloud トリガーフロー（※「Create Consent」アクション）

  • イベントトリガーフロー（※「Consent Request」アクション）

  • オンデマンドフロー（※「Consent Request」アクション）

チャネルごとの固有の同意要件

※ SMS と WhatsApp は有償アドオンのため、詳細を問われる可能性は低いのですが、以下のレベルでは把握しておいても良いと思われます。

Marketing Cloud Next の同意管理は、チャネルごとに同意が独立して管理されます。そのため、あるチャネルでオプトインまたはオプトアウトしても、その状態が他のチャネルへ影響することはありません。例えば、メールをオプトアウトしたとしても SMS や WhatsApp の同意状態は変わりません。

SMS は他のチャネルとは異なる管理方式を採用しています。

SMS の同意は、送信者コード（Sender Code）単位で管理されます。そのため、ある送信者コードをオプトアウトしても、別の送信者コードからの SMS には影響しません。

メールのガイドライン

メールマーケティングでは、各国・地域の法規制を遵守する必要があります。代表的な規制には次のようなものがあります。

• CAN-SPAM（米国）

• CASL（カナダ）

• GDPR（欧州）

プロモーションメールには、次の要素を含める必要があります。

• ワンクリック購読解除（One-Click Unsubscribe）リンク

• プリファレンスセンターへのリンク

• その会社の物理住所

ワンクリック購読解除を実行した場合は、そのメール送信時に利用されたコミュニケーションサブスクリプションのみが自動的にオプトアウトされます。すべての購読が解除されるわけではありません。

一方、トランザクションメールは、通常はプロモーションメールのような明示的なオプトインを必要としません。ただし、組織の設定によってはトランザクションメールにもオプトインを必須とすることが可能です。

SMS のガイドライン

SMS を送信するには、利用者から積極的かつ明示的なオプトインを取得する必要があります。

暗黙の同意（Implicit Consent）や、あらかじめチェックされたチェックボックスによる同意は認められません。

Marketing Cloud Next では、SMS コンプライアンスを支援するため、オプトアウトキーワードを自動処理 します。

利用者が次のようなキーワードで返信すると、

• STOP

• CANCEL

• UNSUBSCRIBE

システムは自動的に検知し、その送信者コードに対する SMS の同意ステータスを OPT_OUT に更新します。

また、SMS 登録フォームには次の内容を明確に記載する必要があります。

• 配信されるメッセージの内容

• 月間のおおよその配信頻度

• オプトアウト方法

WhatsApp のガイドライン

WhatsApp は、Meta の企業向けビジネスメッセージングポリシーに従って運用されます。

企業は、利用者から積極的かつ明示的なオプトインを取得してから、WhatsApp メッセージを送信する必要があります。

オプトインを取得していない利用者へテンプレートメッセージを継続的に送信したり、不要なコンテンツを大量に配信したりすると、Meta によりビジネスアカウントが制限または停止される可能性があります。

利用者は次の方法でオプトアウトできます。

• WhatsApp アプリから企業をブロックする

• あらかじめ設定されたオプトアウトキーワードを送信する

試験のポイント

試験では、次のポイントを押さえておきましょう。

• チャネルごとに同意は独立して管理される。

• メールマーケティングでは、各国・地域の法規制を遵守する必要がある。
  代表的な規制として、CAN-SPAM（米国）、CASL（カナダ）、GDPR（欧州）を覚えておく。

• プロモーションメールには、必要なコンプライアンス要素を含める。

  • ワンクリック購読解除（One-Click Unsubscribe）リンク

  • プリファレンスセンターへのリンク

  • 企業の物理住所（Physical Address）

• SMS の同意は送信者コード（Sender Code）単位で管理される。

  • Email → Subscription × Channel

  • WhatsApp → Subscription × Channel

  • SMS → Sender Code

• SMS と WhatsApp は常に明示的なオプトインが必要。

  • Email（Promotional）→ Yes（必須）

  • Email（Transactional）→ Configurable（設定可能）

  • SMS → Always（プロモーション／トランザクション問わず必須）

  • WhatsApp → Always（プロモーション／トランザクション問わず必須）

同意管理のベストプラクティス

Salesforce では、同意管理を適切に運用するために、いくつかのベストプラクティスを推奨しています。このような問題は、試験でも問われる可能性があるため、それぞれの考え方を理解しておきましょう。

① データの正確性を維持する

まず、同意は、個人ではなく Contact Point（メールアドレスや電話番号）単位で管理されます。そのため、顧客がメールアドレスを変更した場合でも、以前のメールアドレスに紐づく同意情報が新しいメールアドレスへ自動的に引き継がれることはありません。

新しいメールアドレスを利用する場合は、その Contact Point に対して新しい同意レコードを取得・作成する必要があります。メールアドレスが変わったからといって、以前オプトアウトだった利用者を自動的にオプトインへ変更してはいけません。これが正確性です。

② 同意管理をサイロ化せずに一元化する

同意情報をシステムごとに分散管理するのではなく、Data 360 を唯一の信頼できる情報源（Single Source of Truth）として管理することが推奨されています。

例えば、顧客が Service Cloud のセルフサービス画面で購読設定を変更した場合、その変更はフローなどを利用して Data 360 / Marketing Cloud Next にも速やかに反映される必要があります。

これにより、他システムでは購読解除されているにもかかわらず、Marketing Cloud Next からメールが配信され続けるといったコンプライアンス上の問題を防ぐことができます。

③ 同意取得日を正確に維持する

既存のマーケティングシステムから同意データを移行する場合は、同意取得日（Consent Date）を正確に引き継ぐことが重要です。

同意取得日が正確であることで、監査時に「いつ」「どこで」利用者がオプトインしたのかを証明できます。

④ コミュニケーションサブスクリプションを削除しない

Communication Subscription は削除しないことが推奨されています。

Communication Subscription を削除してしまうと、それに紐づく同意履歴のレコードもすべて完全に失われてしまいます。

そのため、不要になったコミュニケーションサブスクリプションであっても削除せず、プリファレンスセンターから非表示にして利用者が選択できないようにすることがベストプラクティスです。

⑤ ダブルオプトインを採用する

より確実な同意取得方法として、ダブルオプトイン（Double Opt-In） の採用が推奨されています。

ダブルオプトインでは、利用者が登録フォームを送信した後に、プロモーションメールの購読を必要としない、特別なトランザクションメールを送信し、そのメール内のリンクをクリックして初めて正式なオプトインが完了します。これにより、誤入力や第三者による不正登録を防止できます。

⑥ 同意状況を継続的に監視する

マーケティング担当者は、同意状況を定期的に分析・監視することが推奨されています。標準レポートや Data 360 のセグメントを利用することで、各コミュニケーションサブスクリプションの増減やオプトアウト率を把握できます。

例えば、新しいキャンペーン配信後にオプトアウトが急増した場合は、メッセージ内容や配信頻度に問題があった可能性を早期に発見できます。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• 同意は Contact Point 単位で管理されるため、メールアドレス変更時は新しい同意レコードが必要であり、ステータスを継続する必要がある。

• Data 360 を同意管理の Single Source of Truth として利用する。

• レガシーデータ移行時は同意取得日を正確に引き継ぐ。

• Communication Subscription は削除せず、不要な場合はプリファレンスセンターから非表示にする。

• ダブルオプトインは推奨される同意取得方法である。

• 同意状況を継続的に分析・監視し、オプトアウト率などを確認する。

ウェブトラッキング用の同意について

これまでのチャネルベースの同意の内容とは異なりますが、ランディングページや外部サイトでトラッキングを開始するための同意も必要です。

Marketing Cloud Next ではこの同意バナーについても、Content Builder からカスタムで作成できるようになっています。

バナーに変更を加えた場合は、必ず Experience Cloud でマーケティングランディングページサイトを再公開してください。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• 同意バナーを設定するか、設定しないかは企業側に任せられます。バナーを設定せずに、同意を取得する手段も提供されています。

• マーケティングランディングページでは同じ同意バナーを使用することになりますが、外部ウェブサイトでは、それぞれ異なる同意バナーを使用することも可能です。

• 同意バナーに変更を加えた場合は、Experience Cloud でマーケティングランディングページサイトを再度公開する必要があります。例えば、変更したはずの同意バナーが変更されない理由を試験で問われたら、「再公開していないため」が回答になります。

• ウェブサイトでデータ収集を有効にするには、埋め込みコードをコピーして、ウェブサイトの「<head> タグ」内に追加してください。

• ウェブトラッキングを設定すると、以下のアクティビティが追跡されますが、個人の名前やメールアドレスなど、個人を特定できる情報は保存されません。アクティビティは匿名 ID に紐づきます。

  • ページビュー

  • フォーム送信

  • リンククリック

  • ボタンクリック

• 後にこの匿名 ID に紐づいたアクティビティとリードや取引先責任者などの既知の人物とを紐づける技術を「アイデンティティ・ステッチング」と呼びます。

データモデリング、ID 解決、セグメント

（25%）… 15 問想定

このセクションでは、Data 360 を中心としたデータモデリングや ID 解決、セグメントについて問われます。

以下を意識して学習を進めてください。

• データストリーム、データレイクオブジェクト（DLO）、データモデルオブジェクト（DMO）、データマッピング、ID 解決、セグメント、コンテンツパーソナライゼーションなど、Data 360 の主要な概念を理解し活用できる。

• DMO 間のデータ連携を確認しながら、マーケティングデータパイプラインの問題を分析・解決できる。

• ビジネス要件に応じて、CRM オブジェクトやレコード、アクショナブルリストを取り込み、セグメント、コンテンツパーソナライゼーションに利用する方法を選択できる。

• ビジネス要件に応じて、複数のデータソースを統合プロファイルに統合するための ID 解決を構成できる。

• Data 360 の従量課金の仕組みを理解し、マーケティングオートメーションの設計が利用量やコストに与える影響を評価できる。

Data 360 アーキテクチャの理解

このセクションでは、Data 360 の各機能の特徴だけでなく、取り込んだデータが Marketing Cloud Next で実際に活用できるようになるまでの一連の処理を理解していることが重要です。

Marketing Cloud Next コンサルタントには、単に「データを Data 360 に取り込める」だけでなく、次の点を理解し、問題が発生した工程を切り分ける能力が求められます。

• データがどこに格納されるのか

• どのように標準化・統合されるのか

• いつセグメントやパーソナライゼーションで利用可能になるのか

基本的なデータ処理の流れ

① データストリームによる DLO への取り込み

CRM や外部システムなどのソースデータは、データストリームを通じて Data 360 に取り込まれ、まず DLO（データレイクオブジェクト） に格納されます。

DLO は、ソースデータを取り込むための領域と思ってください。

② DLO から DMO へのマッピング

DLO に取り込まれたデータは、DMO（データモデルオブジェクト） にマッピングされます。

DLO がソースシステムから取り込んだデータを保持するのに対し、DMO はそのデータを Data 360 の標準化されたデータモデルとして利用するためのレイヤーです。

DMO へマッピングする、セグメント、ID 解決、データグラフなど Data 360 のさまざまな機能でデータを利用できるようになります。※但し、セグメントやデータグラフで利用するには、その DMO がリレーションされている必要があります。

③ ID 解決による Unified Individual の作成・更新

複数のデータソースに存在する顧客レコードを、ID 解決 によって統合します。

例えば、CRM、EC サイト、ロイヤルティシステムに同じ顧客のデータが存在していたとしても、それぞれが別々のレコードとして管理されている場合があります。

ID 解決では、設定された一致ルールや調整ルールに基づいてこれらを統合し、Unified Individual（統合個人）を作成・更新します。

④ 計算済みインサイトの更新

これは必要に応じてになりますが、Calculated Insight（計算済みインサイト）を作成します。

例えば、

• 過去 12 か月の購入金額

• 購入回数

• 平均注文金額

• 最終購入日

など、複数のデータを集計・計算して新しい指標を作成できます。

作成された計算済みインサイトは、セグメントやフロー（決定要素や終了条件）などで活用できます。

⑤ セグメントの更新

Unified Individual や関連する DMO、計算済みインサイトなどのデータを利用して、対象となるオーディエンスを抽出します。

例えば、

「過去 12 か月の購入金額が 10 万円以上の顧客」

という条件を設定した場合、セグメントの更新時に条件が評価され、該当する顧客がオーディエンスに追加されます。

⑥ データグラフの更新

Marketing Cloud Next のパーソナライゼーションなどで利用するデータは、データグラフ（Data Graph）を通じて利用される場合があります。

例えば、

• 顧客ランク

• ロイヤルティランク

• 購入情報

• 顧客属性（氏名や所属）

などをデータグラフに含めることで、メールの差し込み項目や動的コンテンツ、フローの決定要素などから利用できるようになります。

処理の順番を理解する

Data 360 の各処理は完全に独立しているわけではありません。前段階の処理結果を、後続の処理が利用する場合があります。

基本的な流れは次のとおりです。

1. DLO への取り込み

2. DMO へのマッピング

3. DMO 間のリレーションシップ

4. ID 解決

5. 計算済みインサイト

6. セグメント

7. データグラフ

前段階の処理が完了する前に後続処理が実行されると、古いデータが評価されたり、期待するデータが含まれなかったりする可能性があります。

そのため、トラブルシューティングでは最終結果だけを見るのではなく、「どの処理が、いつ開始され、いつ完了したのか」を順番に確認することが重要です。

例えば、CRM で顧客ランクを変更したのに、翌日のメールで古いランクが使用された場合は、次の順番で最新データの到達状況を確認します。

CRM → DLO → DMO → ID 解決 → データグラフ

Unified Individual が重要な理由

Data 360 では、ユースケースに応じてさまざまな DMO を起点にセグメントやデータグラフを構成できます。

一方、Marketing Cloud Next で顧客データをマーケティング用途に利用する場合は、Unified Individual が主要な起点となります。

Unified Individual は、複数のデータソースに存在する顧客情報を ID 解決によって統合した顧客プロファイルです。

そのため、Marketing Cloud Next で使用するセグメントとデータグラフは、Unified Individual を中心に設計し、両者で利用するデータ構造を整合させておくことが重要です。

試験のポイント

このセクションでは、データが利用可能になるまでの処理順序を理解しておくことがあることを学びました。

• データストリームはソースデータを Data 360 に取り込み、DLO に格納する。

• DLO は取り込んだデータを保持するレイヤーであり、DMO は Data 360 で利用するために標準化されたデータモデル。

• DLO にデータが存在するだけでは、すべての Marketing Cloud Next 機能から利用できるわけではない。

• セグメントやデータグラフで項目を利用するには、DMO マッピングを済ませ、さらに DMO 間のリレーションシップを行う必要がある。

• ID 解決では、複数ソースの顧客レコードを照合し、Unified Individual を作成・更新する。

• Calculated Insight は、購入金額や購入回数など、既存データから計算・集計した指標を作成する。

• セグメントは、その時点で利用可能な顧客プロファイルや関連データを条件に基づいて評価する。

• パーソナライゼーションなどで利用するデータは、データグラフの更新状況も確認する。

• 前段階の処理が完了していなければ、後続処理で古いデータや不完全なデータが利用される可能性がある。

• トラブルシューティングでは、最終結果だけを見るのではなく、DLO → DMO → ID 解決 → Calculated Insight → Segment → Data Graph のどこまで最新データが反映されているかを確認する。

• Marketing Cloud Next の顧客マーケティングでは Unified Individual が重要な起点となる。

想定されるシナリオ問題

① CRM のデータを更新したのに、セグメントの設定画面に項目が表示されない。どこを確認するべきか？

DMO への項目マッピングに加えて、その DMO が最終的に Individual へつながるリレーションシップを持っているか確認します。項目をマッピングしただけでは不十分です。

② Data 360 にデータを取り込み、DMO へのマッピングも完了したが、メールの差し込み項目として選択できない。どこを確認するべきか？

DMO が最終的に Individual へつながるリレーションシップを持っているか確認し、さらに必要な項目がデータグラフへ追加されているかを確認します。

データストリーム、DLO、DMO の役割

DLO は、さまざまなデータソースから取り込んだデータを保持するレイヤーです。一方、DMO は、Data 360 で利用するためにデータを標準化したデータモデルです。

Data 360 では複数ソースのデータを ID 解決で統合します。標準化された DMO が存在しなければ、各ソースの異なる形式のままでは、顧客レコードを適切に照合することが難しくなります。

この データストリーム、DLO、DMO に関しては、正直問題にしずらいと思っています。そこで以下のようなことを最低限押さえましょう。

基本は標準 DMO を利用する

Data 360 ではカスタム DMO を作成することもできますが、基本的には標準 DMO の利用が推奨されています。

標準 DMO には多くの項目が用意されているため、それぞれの意味を理解して適切にマッピングするのは簡単ではありません。しかし、Salesforce の一部の機能は、指定された標準 DMO・項目にデータがマッピングされていることを前提に動作します。

代表的な例が、放棄カートなどの リテイルトリガーです。

そのため、「自由にカスタム DMO を作る」のではなく、まず標準 DMO で表現できないかを考える という考え方を覚えておきましょう。

• カスタム DMO は作成可能

• 基本的には標準 DMO の利用を優先する

• 一部の高度な機能は、指定された標準 DMO へのマッピングが前提

データエクスプローラーを使ってデータを検索する

Data 360 に取り込まれたデータを確認・検索する場合は、データエクスプローラー（Data Explorer）を利用できます。

データエクスプローラーでは、次の 4 種類を検索できます。

• データレイクオブジェクト（DLO）

• データモデルオブジェクト（DMO）

• 計算済みインサイト（Calculated Insights）

• データグラフ（Data Graphs）

この 4 種類は試験対策として覚えておきましょう。

また、条件を指定してデータを検索できますが、その検索条件や検索結果を保存することはできません。

Value Suggestions は DMO で設定する

セグメントを作成するとき「テキスト型の項目」限定で、項目に含まれる値を候補として表示してくれる機能が Value Suggestions（値の提案）です。

例えば、CRM の「選択リスト項目」のように、あらかじめ決まった値から条件を選びたい場合に便利です。

Value Suggestions の有効化はセグメント側で設定するのではなく、DMO 側で設定します。

設定できるタイミングは次のとおりです。

• DMO の新規項目作成時

• 既存 DMO の項目の編集時

セグメント作成時に利用する機能ですが、有効化の設定場所はセグメントではなく DMOである点を押さえておきましょう。

Data Space Filter は DLO に設定する

Data Space Filter（データスペースフィルター）は、取り込まれたレコードのうち、どのレコードを特定のデータスペースに格納するかを制御する機能です。

Data Space Filter は、DLO ごとに設定します。

ここで重要なのは、Data Space Filter は、データストリームに取り込まれるレコード自体を減らす機能ではないという点です。

ソースデータは最初にデータストリームによって取り込まれ、その後、フィルター条件に基づいて対象のデータスペースへ格納されます。

位置関係は、次のように考えると分かりやすいでしょう。

データソース → データストリーム →［Data Space Filter］→ DLO → DMO

試験のポイント

試験では、次のポイントを押さえておきましょう。

• 基本的には標準 DMO を利用することを考える

• Value Suggestions（値の提案） は DMO 側で設定する

• データエクスプローラーの検索対象は、データレイクオブジェクト（DLO）、データモデルオブジェクト（DMO）、計算済みインサイト（Calculated Insights）、データグラフ（Data Graphs）の 4 種類のみ

• Data Space Filter（データスペースフィルター） は DLO ごとに設定する

• Data Space Filter は、データストリームへの取り込み自体をフィルターするものではない

ID 解決とは

ID 解決は、複数のソースから取り込まれた顧客レコードを照合し、同一人物と判断されたレコードを Unified Individual（統合個人）として統合する仕組みです。

ID 解決は、次の方法で実行できます。

• 60 分～24 時間間隔での自動実行（自動化を有効にした場合）

• 「ルールセットを実行」ボタンによる手動実行

• フローまたは API をトリガーとした実行

差分更新

通常のデータ更新では、すべてのレコードを毎回処理するのではなく、変更されたレコードを対象とした差分処理が行われます。

大まかな流れは次のとおりです。

1. CRM 側でレコードが更新される

2. 更新をトリガーとして DSO／DLO 側で差分更新が行われる

3. 変更が検知されたレコードが ID 解決の対象となる

変更の判定で重要なのが、SystemModStampです。

• LastModifiedDate：主にユーザーによる変更日時

• SystemModStamp：ユーザーとシステムの変更を含む、システム上の更新日時

ID 解決の差分処理を理解するうえでは、項目値の見た目だけでなく、SystemModStamp が変更されるかどうかが重要です。

変更検知の対象となる項目

ID 解決における DLO の変更検知では、DMO にマッピングされている項目のみが対象となります。

したがって、DMO にマッピングされていない項目だけが変更されても、その変更は ID 解決の対象にはなりません。

すべての項目変更が ID 解決につながるわけではない点に注意してください。

フル更新が発生する代表的な原因

通常は差分処理が行われますが、設定変更の内容によっては、次回の ID 解決でデータスペース内のソースプロファイルが全件再処理される場合があります。

代表的な原因は次のとおりです。

• マッチルールで使用する DMO の追加または削除

• DMO に接続されている項目のマッピング変更

例えば、Contact や Lead などのソースプロファイルから、新しい項目を Individual DMO に追加でマッピングした場合、全件再処理が発生します。

新しい項目をマッピングしただけでは、Unified Individual 側に項目が用意されても、既存レコードの値までは反映されません。既存レコードを再処理し、実際の値を Unified Individual へ反映するために ID 解決が必要になります。

トラブルシューティング

例えば試験で、次のように問われる可能性があります。

「運用開始前の初期構築中に、ID 解決によって毎日大量のクレジットが消費されていることが判明した。最初に何をするべきか？」

この場合、最初に検討するのは、ID 解決の自動実行を停止することです。

運用開始前であれば、原因を調査している間にも不要な ID 解決が繰り返され、クレジットを消費し続ける可能性があります。

まず自動化を停止して追加消費を防ぎ、その後、マッピング変更、マッチルール、データ更新状況など、何が再処理を発生させているのかを調査します。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• ID 解決は、自動、手動、フロー、API から実行できる。

• 変更がないレコードは再処理されない。

• 通常の更新では、変更されたレコードを対象とした差分処理が行われる。

• CRM レコードの変更検知では SystemModStamp が重要である。

• DMO にマッピングされていない項目の変更は、ID 解決の変更検知対象にならない。

• DMO や項目マッピングの変更によって、全件再処理が発生する場合がある。

• 構築中に不要なクレジット消費が続いている場合は、まず自動実行を停止し、その後で原因を調査する。

一致ルールと調整ルール

ID 解決は、次の 2 つのプロセスで構成されます。

1. 一致ルール
   共通の基準に基づいてプロファイルをグループ化します。

2. 調整ルール
   統合されたデータの主要な属性を要約し、どの値を優先するかを決定します。

ID 解決の流れ

ID 解決は、まず一致ルールでマッチングを行い、その後、調整ルールを適用するという連続したプロセスで進行します。このプロセスは以下の方法で実行可能です。

• 手動実行：任意のタイミングで実行できます

• スケジュール実行：設定に基づいて自動的に実行します。なお、設定内容に変更がない場合はジョブがスキップされる場合があります

統合の成果物

ID 解決の結果、以下の成果物が生成されます。

1. 統合プロファイル（Unified Profile）
   統合されたデータを表します。ただし、直接的にIndividual ID を含みません。そこで 2 の統合リンクがあります。

2. 統合リンク（Unified Link）
   統合プロファイル ID と個人 ID の両方を保持し、これらをつなぐ橋渡し（ブリッジ）として機能します。統合プロファイルを他のオブジェクトと連携させる際は、この統合リンクを使用します。

ルールとルールセット

ルールとルールセットを使用して、マッチングの基準を設定します。

• ルール：基準は AND 条件として評価されるため、基準を追加すると統合率が低下する。

• ルールセット：複数のルールは OR 条件として評価されるため、ルールを追加すると統合率が向上する。

アカウント内では、次の 4 つのルールセットを作成できます。

1. 統合個人用（現在のルール）

2. 統合個人用（改善用）

3. 統合アカウント用（現在のルール）

4. 統合アカウント用（改善用）

Marketing Cloud Next セットアップのルールセット

Marketing Cloud Next では、次の 3 つの ID 解決ルールセットが標準で用意されています。

1. Normalized Email（正規化されたメール）
   重複するメールアドレスをマッチングします。

2. Lead to Contact（リードから取引先責任者へ）
   リードが取引先責任者へ変換される際の重複を防止します。

3. Device to Known（デバイスと既知のプロファイル）
   Web 訪問者を既知のプロファイルと照合します。

調整ルール

調整ルールは、以下の基準に基づいてどの情報を優先するかを判断します。

1. 最終更新（デフォルト）
   最新のデータを優先します。例：住所情報：引っ越しを考慮し、一番最新の情報を正としておきたい

2. 最も頻繁
   最も多く出現したデータを優先します。例：名前：誤表記や表記ゆれがあるので一番頻度の高い値を正としておきたい

3. ソース優先度
   あらかじめ設定されたデータソースの優先順位に従います。例：年齢：マイページよりコールセンターの情報が信頼できるので優先的に設定したい

また、「空の値を無視する」オプションを使用することで、調整ルールで空のフィールドを無視することが可能です。

ID 解決のタイミングとスケジュール

• スケジュール実行：
  24 時間に 1 回自動実行されます。（タイミングは UI 上で設定不可）

• 手動実行：
  任意のタイミングで実行可能です。

Party Identification に基づくマッチングルール

Party Identification DMO を使用することで、独自の会員番号や運転免許証番号などのメールアドレスや電話番号以外の識別子でマッチすることができます。

Party Identification DMO では、個人やアカウントを識別するための以下の要素を持ちます。

1. Party Identification ID（関係者 ID）
   レコードの主キーです

2. Party（関係者）
   個人 ID またはアカウント ID に紐づく外部キーです

3. Party Identification Type（関係者 ID 種別）
   識別子の用途を表します。例：自動車ナンバープレート、会員 ID、社会保障番号

4. Identification Name（識別名）
   識別子に名前を付けます。例：運転免許証、マイナンバーカード

5. Identification Number（識別番号）
   実際に比較に使用される ID 値です

注意点：
Party Identification DMO を使用してマッチルールを作成する場合は、以下の要素がすべて一致している必要があります。

1. 関係者 ID 種別（Party Identification Type）
   種類：パスポート・・・数式などで"Passport"と固定値を打つなど

2. 識別名（Identification Name）
   具体名：パスポート・・・数式などで"Passport"と固定値を打つなど

3. 識別番号（Identification Number）
   ID：パスポート番号

例えば、もし、CRM ID を識別番号として使用している場合でも、識別名が異なっている場合はマッチングは行われません。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• 1 つのルール内では、基準の追加は AND 条件となり、統合率が低下する。

• ルールセット内では、ルールの追加は OR 条件となり、統合率が向上する。

• 調整ルールには、最終更新、最も頻繁、ソース優先度がある。デフォルトは「最終更新」です。

• 「空の値を無視する」オプションを利用できる。

• Unified Link は、Unified Profile とソースの個人 ID をつなぐブリッジである。

• Party Identification を使用する場合は、Type、Name、Number のすべてが一致する必要がある。

セグメントとは

セグメントでは、条件に基づいて対象となるオーディエンスを抽出します。

セグメントで利用できる属性は次のとおりです。

• 直接属性

• 関連属性

• 計算済みインサイト

Waterfall セグメント

• Waterfall セグメントは、複数のセグメントリストに優先順位を設定し、上位のセグメントから順番に顧客を割り当てることで、セグメント間の重複を除外する機能です。

関連属性とコンテナ

関連属性を使用して条件を設定する場合は、同じコンテナに条件を置く場合と、別々のコンテナに条件を置く場合の違いを理解する必要があります。

次の条件を例に考えてみましょう。

• 色：黄色

• 商品：靴

1 つのコンテナで条件を設定する場合

同じコンテナ内に「色＝黄色」と「商品＝靴」を設定すると、同じ購入履歴の中で両方の条件を満たす人が抽出されます。

つまり、対象となるのは「黄色の靴」を購入した人です。

別々のコンテナで条件を設定する場合

「色＝黄色」と「商品＝靴」を異なるコンテナに配置し、コンテナ同士を AND で結ぶと、次の両方を満たす人が抽出されます。

• 何らかの黄色い商品を購入したことがある

• 何らかの靴を購入したことがある

違いのまとめ

• 1 つのコンテナ：同じ関連レコード内で、すべての条件を満たす必要がある。

• 別々のコンテナ：異なる関連レコードで、それぞれの条件を満たしてもよい。

「黄色の靴を購入した顧客」を抽出したい場合は 1 つのコンテナを使用し、「黄色の商品と靴の両方を購入した経験がある顧客」を広く抽出したい場合は、別々のコンテナを使用します。

セグメントの種類と公開

リアルタイムセグメント

• リアルタイムセグメントは、リアルタイムデータグラフを基に作成され、イベントトリガーフローで利用します。

動的セグメント

• 動的セグメントを利用できるのは、ブロードキャストフローのみです。

標準セグメントの公開

標準セグメントは、条件を設定して保存しただけでは仮の状態です。フローの送信対象として利用するには、セグメントを公開する必要があります。

公開方法は次のとおりです。

• 手動で公開する

• スケジュールに基づいて公開する

• フローを実行する直前に公開（← これは押さえておく）

キャンペーンページでのセグメント作成

キャンペーンページには、セグメント作成を効率化するための機能 が用意されています。

• クイックフィルターを使用する
  「誕生日が今日」「未解決のケースがない」など、一般的な条件で対象者を絞り込みます。＝ テンプレートが用意されている。

• キャンペーンメンバーに送信
  既存の Salesforce キャンペーンメンバーシップに基づいてセグメントを作成します。

• セグメントビルダーに移動する
  完全なエディターを開き、DMO 属性を使用してカスタムロジックを定義します。

• 既存のセグメントを選択する
  作成済みのセグメントを再利用します。

実務ではあまり利用しないものの、Salesforce はクリックフィルターを推しているように思います。念のためどのようなものがあるかを頭にいれておきましょう。

• Birthday This Month：今月が誕生日

• Birthday Today：今日が誕生日

• Campaign Members：キャンペーンメンバー

• Clicked Any Link In Any Email：いずれかのメール内のリンクをクリック

• Contacts：取引先責任者

• Leads：リード

• New Contacts (created today)：今日作成された取引先責任者

• New Leads (created today)：今日作成されたリード

• No Email Engagement (last 30 days)：過去 30 日間メールエンゲージメントなし

• No Open Cases：未完了のケースなし
  ※ Case データストリームが必要

• Opened Any Email：いずれかのメールを開封

• People Score: 80+：People Score が 80 以上

• Prospects：プロスペクト

• Related to Recent Won Opportunity (last 24 hours)：過去 24 時間以内の成立商談に関連

• Submitted Any Form：いずれかのフォームを送信
  ※ Behavioral Events データストリームが必要

• Viewed Any Landing Page：いずれかのランディングページを閲覧
  ※ Behavioral Events データストリームが必要

試験のポイント

試験では、次のポイントを押さえておきましょう。

• セグメントでは、「直接属性」、「関連属性」、「計算済みインサイト」を利用できる。「ストリーミングインサイト」はセグメントでは利用できないので覚えておいてください。

• セグメントを保存した後は、他のセグメントでも、そのセグメントを条件として設定できるようになります。

• 直接属性（統合個別の項目）では、集計とネストは利用できません。

• セグメントには、[含める] と [除外する] それぞれ最大 50 個のフィルター条件を設定できる。

• 関連レコードの条件では、対象とする期間を指定できる。
  標準公開ではデフォルト 90 日、最大 24 か月のデータを対象にできる。※ この日付項目は、データストリーム設定時に定めた イベント時刻項目（Event Time Field）を使用します。

• 高速公開 で利用できるのは、過去 7 日分のデータのみである。

• 標準セグメントは、保存しただけではフローで利用できず、「公開」が必要である。

• 標準セグメントの公開スケジュールには、「更新しない」「標準公開」「高速公開」がある。

  • 更新しない： 静的なセグメントとして利用する。

  • 標準公開： 12 時間または 24 時間ごとに更新する。

  • 高速公開： 直近 1 週間のデータを使用し、1 時間または 4 時間ごとに更新する。

• Rapid Publish は、時間的制約のあるキャンペーンや自動化に適している。但し、通常より高い頻度で更新できる一方、利用量とコストへの影響を考慮する必要がある。

• マルチタッチキャンペーンでは、フロー実行直前にセグメントを更新できる。フロービルダーで 「このフローを実行する直前に公開」 を選択すると、通常の公開スケジュールに加えて、フロー開始前にもセグメントが更新される。

• セグメントの鮮度は、公開スケジュールだけで決まるわけではない。
  ID 解決などの前段の処理が完了していなければ、最新データがセグメントに反映されない場合がある。

• Waterfall セグメントは「優先順位」に基づいて顧客の重複を除外する。

• リアルタイムセグメントは、リアルタイムデータグラフを基に作成し、イベントトリガーフローで利用する。

• 動的セグメントを利用できるのはブロードキャストフローのみで、公開は不要である。

• アインシュタインセグメントは、セグメント内のバイアスと外れ値を減らすため、母集団における結果数が 10 件未満となる人口統計情報と属性を除外します。

データグラフとは

データグラフは、Marketing Cloud Next で Data 360 のデータを活用するための重要な仕組みです。

特に、次の機能で利用されます。この 4 つは覚えておきましょう。

• メールの差し込みフィールド

• 動的コンテンツ

• フローの決定要素（判断分岐）

• フォームの事前入力

Data 360 にデータが存在することと、Marketing Cloud Next の各機能からそのデータを利用できることは別の話です。

DMO にデータが存在していても、必要なデータグラフが用意されていなければ、Marketing Cloud Next から利用できない場合があります。

データグラフの基本的な作成手順

データグラフは、次の流れで作成します。

1. 主要オブジェクトを選択する
   Marketing Cloud Next のユースケースでは、Unified Individual を選択します。

2. 関連オブジェクトを追加する
   注文や商品など、パーソナライゼーションに必要な関連 DMO を追加します。

3. 必要なフィールドを選択する
   メールやフローなどで実際に利用する属性を選択します。

4. 更新スケジュールを設定する
   データグラフの更新スケジュールを設定します。

5. データグラフをビルドする
   設定した構造をビルドし、利用可能な状態にします。

Unified Individual と Individual の接続

Unified Individual を Individual に接続するには、Unified Link Individualを経由する必要があります。

Unified Individual → Unified Link Individual → Individual

また、Einstein 関連の DMO はメールアドレスを基準に生成されるため、Individual ではなく、Contact Point Email とのリレーションシップを確認する必要がある点も押さえておいてください。

ビルド後の変更に関する制約

• データグラフは、一度ビルドすると、後からオブジェクトや属性を取り外すことができません。

• 不要なオブジェクトや属性を除外したい場合は、データグラフを削除し、最初から作り直す必要があります。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• Data 360 にデータが存在するだけでは、Marketing Cloud Next のすべての機能から利用できるわけではない。

• メールの差し込みフィールド、動的コンテンツ、フローの決定要素、フォームの事前入力では、データグラフが重要である。

• Marketing Cloud Next では、基本的に Unified Individualを主要オブジェクトとしてデータグラフを構築する。

• Unified Individual と Individual の間は、Unified Link Individual を経由する。

• Einstein 関連の DMO では、データの生成キーに応じて Contact Point Emailとのリレーションシップを確認する。

• 一度ビルドしたデータグラフから、後でオブジェクトや属性を取り外すことはできない。

• シンプルに、「顧客の名前」だけを使用したようなシナリオには、データグラフは必要ありません。この場合は Unified Individual Data Provider を利用できます。ここはひっかけ問題として出題される可能性もあります。

見込み客（プロスペクト）とは

Marketing Cloud Next では、通常の「取引先責任者」や「リード」の他に、 「見込み客（プロスペクト）」を活用することで、マーケターはより確度の高いリードだけを営業担当者に引き渡すことが可能になります。

「見込み客（プロスペクト）」とは、まだ商談化前ではあるものの、サインアップフォームなどを通じ、メールアドレスなど何らかの連絡手段（チャネル）を取得済みで、営業担当者にはまだ割り当てられていない状態の見込み客を指します。

一方「リード」は、潜在的な見込み客の中から、マーケティングの結果、スコアリング等の基準を満たし、営業担当者に割り当てられた段階です。さらに「取引先責任者」は、そのリードが進展し、商談化して、具体的な取引に進んでいる状態を表します。

人の状態

• 見込み客（プロスペクト）：営業担当者に割り当てられる前の状態

• リード：営業担当者に割り当てられた後の状態

• 取引先責任者：商談化して取引が開始している状態

商談化の可能性

• 見込み客（プロスペクト）：低～中（担当者：マーケター）

• リード：中～高（担当：営業担当者＆マーケター）

試験ポイント

試験では、次のポイントを押さえておきましょう。

• 変換済みの見込み客はリストビューに表示されない
  リードに変換された見込み客（Prospect）は、Converted = True を指定してもリストビューには表示されません。ただし、データエクスプローラーでは確認できます。

• セグメントでは変換済みの見込み客を明示的に除外する
  見込み客のセグメントを作成する場合、Prospect Status != Converted などの条件を指定しないと、変換済みの見込み客も含まれます。

• 見込み客はキャンペーンに直接追加できない
  キャンペーンメンバーとして追加できるのは、リードまたは取引先責任者です。

• 見込み客はデータインポートウィザードからインポートできない

• 見込み客はコピーや一括削除ができない

• 変換後のリードとの関連情報は保持される
  見込み客オブジェクトの「Converted Lead」項目に変換先のリード ID が格納されるほか、Identity Match データモデルオブジェクトにも関連レコードが作成されます。

• エンゲージメント情報は変換後も引き継がれる
  統合 ID が共通である限り、エンゲージメントスコアや Email、Web などのエンゲージメント履歴は、ID 解決や計算済みインサイトの更新後も引き続き利用できます。

アクション可能リストとは

アクション可能リスト（Actionable List）は、特定の既知のオーディエンスを静的なリストとして管理し、すばやくマーケティング施策の対象にできる機能です。

例えば、展示会でマーケティングへのサインアップを行った人のリストなどを、すぐにメール配信の対象として利用できます。

従来の Marketing Cloud Next では、データを取り込んでから実際に送信できるようになるまでに、Data 360 への連携や ID 解決、データグラフの更新などを待つ必要がありました。

アクション可能リストでは、このプロセスを待たずに、CSV からリードをインポートして、すぐに Marketing Cloud Next から送信できることが大きな特徴です。

アクション可能リストの管理

アクション可能リストは、一度だけ利用するアドホックなリストとして利用できるだけでなく、作成後にメンバーを追加・削除して管理することもできます。

リストメンバーは、フローまたはアクション可能リストのレコードページから削除できます。ただし、レコードページからメンバーを削除できるのは、そのリストの作成者のみです。

アクション可能リスト利用時のデータグラフの扱い

ここで重要なのが、アクション可能リストを利用したフローにおけるデータグラフの扱いです。

通常、Marketing Cloud Next ではデータグラフの属性をメールの差し込み項目などに利用できます。しかし、アクション可能リストを利用する場合は動作が異なります。

メールコンテンツにデータグラフ由来の差し込み項目を設定していても、データグラフの値は取得されません。

代わりに、差し込み項目に設定されているデフォルト値が表示されます。

これは、対象となるオーディエンスについてデータグラフ上に参照可能な値が存在している場合でも同様です。

一方、フローの「決定」要素では、データグラフの値を利用して条件を評価できます。

つまり、次の違いを覚えておきましょう。

• コンテンツの差し込み項目 → データグラフの値は利用できず、デフォルト値になる

• フローの「決定」要素 → データグラフの値を条件評価に利用できる

パーソナライズする場合

アクション可能リストを利用したメールでパーソナライズを行いたい場合は、データグラフの差し込み項目を直接利用するのではなく、コンテンツ変数を利用してフローから値を渡します。

試験ポイント

試験では、次のポイントを押さえておきましょう。

• アクション可能リストは、既知のオーディエンスを静的なリストとしてすばやく利用するための機能。

• CSV からリードをインポートし、Data 360 のデータ処理を待たずに送信を開始できる。

• リストメンバーは追加・削除できる。

• レコードページからメンバーを削除できるのは、リストの作成者のみ。

• コンテンツの差し込み項目では、データグラフの値は取得されず、デフォルト値が使用される。

• フローの「決定」要素では、データグラフの値を条件評価に利用できる。

• パーソナライズには、コンテンツ変数を利用してフローから値を渡す。

マーケティングオブジェクトとは

マーケティングオブジェクト（Marketing Object）とは、マーケティング施策で利用するデータを保存するためのデータストアです。

Marketing Cloud Engagement（MCE）の データエクステンション（Data Extension）に近い役割を持ち、CSV ファイルをインポートすることでデータを取り込めます。

現時点では、CSV ファイルの手動インポートのみがサポートされています。

取り込んだデータは、AMPscript の Lookup 関数を通じて、メールのパーソナライゼーションに利用できます。

サポートされるデータ型

マーケティングオブジェクトで利用できるデータ型は、次の 3 種類です。

• Text：最大 255 文字の文字列

• Number：最大 18 桁の正または負の整数

• Decimal：最大 18 桁の正または負の小数

作成後に、これらのデータの長さを拡張・縮小することはできません。

エディションごとのリソース上限

Growth Edition と Advanced Edition では、利用できるリソース量が異なります。

マーケティングオブジェクト全体のストレージ容量

• Growth Edition：10 GB

• Advanced Edition：40 GB

作成できるマーケティングオブジェクト数

• Growth Edition：25 個

• Advanced Edition：100 個

各マーケティングオブジェクトの項目数

• Growth Edition：100 項目

• Advanced Edition：100 項目

項目数については、どちらのエディションでも同じ 100 項目です。

リリース当初、マーケティングオブジェクトには以下の制約がありましたが、現在はその制約は解消されています。よってこれらの制約はそのまま覚えないでください。

• レコードの追加ができない

• レコードの更新ができない

2026 年 8 月の改修で、以下が可能になっています。

• フィールドの新規追加

• 同じマーケティングオブジェクトに対する CSV ファイルによる全件上書き（フルリフレッシュのみ）

• データエクスプローラー UI による各値の編集（← まだ？🤔）

そのため、以前はマーケティングオブジェクト自体を削除し、CSV を修正してからの再インポートが必要でしたが、少数のレコードを入力する場合は、より簡単に編集できるようになっています。

試験ポイント

試験では、次のポイントを押さえておきましょう。

• 現時点のデータ取り込み方法は、CSV ファイルの手動インポートのみ

• データは AMPscript の Lookup 関数から参照できる

• データ型は Text / Number / Decimal の 3 種類

• データの長さは、作成後に拡張・縮小できない

• Growth Edition は 10 GB / 25 オブジェクト

• Advanced Edition は 40 GB / 100 オブジェクト

• 1 オブジェクトあたりの項目数は、どちらも 100 項目

キャンペーン、フロー、コンテンツ

（割合：30%）… 18 問想定

このセクションは試験全体で最も配点が高く、Marketing Cloud Next のキャンペーン設計やフロー構築に関する知識が問われます。Marketing Cloud Next 独自の機能や設定も多いため、まさにこの試験の本丸とも言えるセクションです。

一方で、「画面のどこに何があるか」といったツールのデザインや UI に関する問題は、それほど多くないのではないかと考えています。

というのも、Marketing Cloud Next は現在も発展を続けており、画面構成や操作方法が頻繁に変更されています。そのため、「この機能は画面のどこから設定するか」といった内容は、試験問題として扱いにくいはずです。

それよりも、「この要件ではどの機能を使うべきか」「このシナリオではどの設定を選択すべきか」といった、機能の役割や使い分けを理解しておくことが重要だと考えています。

• Handlebars、AMPscript、差し込み項目、繰り返しコンポーネント、コンテンツバリエーションなどを利用したパーソナライズ手法を選択できる。

• シナリオに応じて、目的に適したフローの種類、トリガー条件、設定を選択できる。

• シナリオに応じて、メッセージへパーソナライズデータを追加するための適切なデータソースを選択できる。

• シナリオに応じて、業務プロセスやメッセージングを自動化するために必要なフロー要素、ロジック、設定を選択できる。

• Activation Template を構成し、適切な連絡先を選択できる。

• ビジネス要件に応じて、ランディングページを構築するために必要なコンポーネントや設定を選択できる。

このセクションは、大きく分けて以下の 2 つに分かれます。

• Campaigns and Flows（キャンペーンとフロー）

• Content（コンテンツ）

キャンペーンとフローの関係

Marketing Cloud Next における キャンペーンは、オーディエンス（セグメント）、フロー、コンテンツ、目標、結果などをまとめて管理するための「箱」のようなものです。

キャンペーンがマーケティング施策全体の方向性を管理するのに対して、実際に顧客へメッセージを届けたり、マーケティング処理を実行したりするのがフローです。

ここで重要なのが、キャンペーンとフローの関係です。

キャンペーンレコードとフロービルダーでは、確認・設定できる内容が完全に同じではありません。キャンペーンレコードだけでは設定できない内容については、フロービルダーを開いて編集する必要があります。

キャンペーンレコードからフローを作成する場合は、主に次の 3 つの方法があります。

① Build Your Own

• セグメント、リスト、イベントから開始要素のトリガーを選択して、一から独自にフローを構築します。

② フローテンプレート

• あらかじめ主要な要素が設定された、目的別のテンプレートを利用します。サインアップフォームはこちらから作ります。

③ クイックスタート

• 一般的なキャンペーンのユースケースから、コンテンツなども含めて事前設定されたフローを利用します。

また、フローの基本的な構成要素として、開始、アクション、待機、決定、パス試験 などがあります。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• キャンペーンは、オーディエンス、フロー、コンテンツ、目標、結果などをまとめて管理するもの

• 実際のマーケティング処理やメッセージ送信は、フローが実行する

• 1 キャンペーン → 複数フローは可能

• 1 フロー → 複数キャンペーンは不可

• キャンペーンレコードで設定できないほど複雑なものは、フロービルダーで設定する

• フロー作成では、Build Your Own、フローテンプレート、クイックスタート などを利用できます。

セグメントフローと自動化イベントトリガーフロー

Marketing Cloud Next では、目的に応じてさまざまなマーケティングフローを利用できます。

試験対策として特に押さえておきたいのが、セグメントフローと自動化イベントトリガーフローです。

セグメントフロー

セグメントフローは、Data 360 のセグメントなどを対象として、フローの有効化時やスケジュールされたタイミングで処理を実行するフローです。

「開始」要素には、主に次の2つを使用できます。

• リスト（アクション可能リスト）

• セグメント

セグメントを利用する場合は、公開済みの最新データを使用することが重要です。

特にキャンペーンレコード上のセグメントプレビューには、最後に公開された時点のデータが表示されます。

そのため、

という場合は、セグメントを再公開して最新化する必要があります。

フローを実行する直前にセグメントを再公開するオプションも利用できます。

自動化イベントトリガーフロー

自動化イベントトリガーフローは、スケジュールではなく、顧客の行動やデータの変更などのイベントをきっかけとして開始するフローです。

例えば、次のようなイベントを利用できます。

• コマース系

  • カート放棄、B2Cカート放棄など

• レコード／データ変更

  • Prospect、Lead、Contactや関連レコードの作成・更新

  • リアルタイムデータグラフのレコード変更

• Email

  • 開封、リンククリック、バウンス、購読など

• SMS／WhatsApp／RCS

  • リンククリック、返信、配信、既読、配信失敗、購読など

• フォーム

  • フォーム送信、ファイル添付など

つまり、Marketing Cloud Next のフローは、単に「毎日○時に実行する」といったスケジュール型だけではなく、顧客が何かをした瞬間やデータが変化したタイミングからマーケティングを開始できるということです。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• セグメントフローはセグメントやアクション可能リストを開始要素として利用できる

• キャンペーンのセグメントプレビューは、公開済みのデータを表示する

• プレビューが古い場合は、セグメントを再公開する

• 自動化イベントトリガーフローは顧客行動やデータ変更を起点に開始できる

• Email、SMS、WhatsAppなどのエンゲージメントイベントをトリガーにできる

• リアルタイムデータグラフの変更もトリガーとして利用できる

• 「スケジュールだけではなく、リアルタイムのイベントからフローを開始できる」ことを覚えておく

フローのバージョン管理とキャンペーンとの共有設定

Marketing Cloud Next のフローには、複数のバージョンを作成できます。

ただし、複数のバージョンが存在していても、同時にアクティブにできるバージョンは1つだけです。

ここで注意したいのが、一時停止中のフローもアクティブとして扱われることです。

また、キャンペーンレコードには、関連するフローの最後に有効化されたバージョンが表示されます。

そのため、キャンペーンレコードに古いフローが表示されている場合は、最新バージョンを有効化してからキャンペーンを確認します。

キャンペーンとフローの共有設定

フローをキャンペーンに関連付けると、フローはキャンペーンの共有設定を継承します。

その後キャンペーンを削除すると、フロー自体が削除されるわけではありません。フローの共有設定は、フローレコード側で定義されている共有ルールに戻ります。

共有ルールが設定されていない場合、そのフローは非公開になります。

この場合、フローへアクセスできるのは、所有者、Salesforce管理者、および必要な権限を持つユーザーなどに限定されます。

また、キャンペーンまたはフローのどちらかを削除しても、関連するもう一方のレコードまで自動的に削除されるわけではありません。

削除されるのは両者の関連付けです。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• フローには複数のバージョンを作成できる

• アクティブにできるバージョンは1つだけ

• 一時停止中のフローもアクティブとして扱われる

• キャンペーンには、フローの最後に有効化されたバージョンが表示される

• キャンペーンに関連付けられたフローは、キャンペーンの共有設定を継承する

• キャンペーンを削除すると、フローは自身の共有ルールへ戻る

• 共有ルールがなければ、フローは非公開になる

• キャンペーンまたはフローを削除しても、もう一方まで削除されるわけではない

• 削除されるのはキャンペーンとフローの関連付け

この3つなら、①基本関係 → ②どう開始するか → ③運用・管理上のルールという流れになるので、試験対策としてかなり覚えやすくなります。

マーケティングで利用するフローの種類

Marketing Cloud Next では、マーケティング施策に応じて複数の種類のフローを利用できます。

Activation-Triggered Flow

Activation（アクティベーション）が公開されたことをきっかけに実行されるフローです。

主に Data 360 のセグメントを外部サービスへ連携するようなユースケースで利用します。

例えば、

といった使い方ができます。

対象レコードが追加されるタイミングは、セグメントの公開スケジュールに依存します。セグメントの設定によって、増分更新では最短 10 分ごと、標準更新では 24 時間ごとに更新されます。また、手動で更新することもできます。

Automation Event-Triggered Flow

特定のイベントが発生したことをきっかけに実行されるフローです。

例えば、

といった、顧客の行動に反応するマーケティングに利用できます。

標準で用意されている Automation Event のほか、Engagement Signals を使用してカスタムイベントを定義することもできます。

標準イベント・カスタムイベントともに、イベント発生後、約 15 分以内にフローが実行されます。この 15 分は公式の情報ですので、覚えておく必要があります。

Broadcast Flow

Dynamic Segment を使用して対象者を決定し、プログラムから実行するフローです。

特徴的なのは、フローを開始した後にセグメントメンバーシップが判定されることです。

例えば、

といった用途があります。

Broadcast Flow は、以下の方法から実行できます。

• API

• Apex

• 別の Flow

On-Demand Flow

必要なタイミングで即座に呼び出すためのフローです。

特に、優先度が高く、イベント発生に応じて処理したいユースケースに向いています。

例えば、

といった用途です。

API からフローを呼び出す際には、注文 ID や購入金額などの情報を一緒に渡すこともできます。

実行方法は、

• API

• Apex

です。

Audience Flow

特定のオーディエンスを対象として実行する、マーケティングで基本となるフローです。

対象には、以下を利用できます。

• Segment Members

• List Members

• Campaign Members

• レコード条件によって絞り込んだサブグループ

例えば、

といった施策に利用できます。

Audience Flow は、即時実行またはスケジュール実行が可能です。

スケジュールは一度だけ実行することも、定期実行することもでき、定期実行の場合は最短 1 時間ごとに実行できます。

また、Segment を対象とするスケジュールフローでは、フロー実行直前に対象セグメントを再公開するよう設定できます。これによって、できるだけ最新のセグメントメンバーを対象にできます。

フロー実行直前に再公開しない場合は、通常のセグメント公開スケジュールに基づいたメンバーシップが使用されます。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• Activation-Triggered Flow：Activation の公開をきっかけに実行される

• Automation Event-Triggered Flow：フォーム送信などのイベント発生をきっかけに実行される

• Broadcast Flow：Dynamic Segment を利用し、API、Apex、別の Flow などから実行する

• On-Demand Flow：注文確認など、必要なタイミングで API や Apex から実行する

• Audience Flow：Segment、List、Campaign Members などのオーディエンスを対象に、即時またはスケジュールで実行する

特に混同しやすいのが、Broadcast Flow と Audience Flowです。

Audience Flow は、特定のオーディエンスを対象として、即時またはスケジュールに基づいて実行します。一方、Broadcast Flow は Dynamic Segment を使用し、フロー開始後に対象となるセグメントメンバーが決定される点が特徴です。

また、時間に関する以下の数字も押さえておくとよいでしょう。

• Activation-Triggered Flow：セグメントの増分更新は最短 10 分ごと

• Automation Event-Triggered Flow：イベント発生から 約 15 分以内

• Audience Flow：定期実行は最短 1 時間ごと

この 3 つは、試験問題でフローの種類を判断する材料になりやすいポイントです。

マーケティングフローの要素

Marketing Cloud Next のフローでは、通常の Flow Builder の要素に加えて、マーケティング専用の要素を利用できます。

試験対策として、すべての細かな設定を覚える必要はないと思います。「どの要素を使えば、何ができるのか」を判断できるようにしておきましょう。

同意を更新する

Create Consent は、Unified Individual に関連するコンタクトポイントの同意ステータスを更新する要素です。

特定の チャネル × コミュニケーション登録（Communication Subscription）の組み合わせについて、Opt In / Opt Out を設定できます。

CRM レコードを判定する

Determine CRM Record for Individual は、対象者に紐づく CRM レコードが Contact / Lead / Prospect のどれなのかを判定します。

判定結果によってフローを分岐し、例えば Lead と Prospect で異なるメールを送信するといった処理が可能です。

Einstein でエンゲージメントを判定する

Einstein Decision は、Einstein Engagement Frequency または Einstein Engagement Scoring を利用してメールエンゲージメントを判定し、その結果によってフローを分岐します。

フローから離脱させる

Exit from a Flow は、対象者を Marketing Cloud の特定のフローから離脱させます。

例えば、キャンペーン期間中に商品を購入した顧客を、その後の販促メールのフローから除外できます。

パスをテストする

Path Experiment は、顧客をランダムに異なるパスへ振り分け、最大 10 パターンのカスタマージャーニーを比較できます。

最適なパスを自動選択することも、手動で選択することもできます。

メッセージを送信する

Marketing Flow には、チャネルごとの送信要素が用意されています。

• Send Email Message：メールを送信

• Send SMS Message：SMS を送信

• Send WhatsApp Message：WhatsApp を送信

• Send RCS Message：RCS メッセージを送信

• Send Mobile App Message：モバイルアプリへプッシュ通知を送信

• Send Mobile In-App Message：モバイルアプリ内メッセージを送信

• Send Flash Message：Flash 通知を送信

Email や SMS などでは、オプトインした対象者への送信やエンゲージメントのトラッキング、対応するチャネルでは Einstein による最適化なども利用できます。

Marketing Cloud Engagement からメールを送信する

Send Marketing Cloud Engagement Email を利用すると、Marketing Cloud Engagement の既存のコンテンツ、送信分類、Publication Listなどを使用してメールを送信できます。

Data 360 のオーディエンスを Marketing Cloud Engagement に複製・アクティベーションすることなく利用できる点も重要です。

別のフローや Journey に送る

Send to a Flow は、対象者を特定の Marketing Cloud On-Demand Flow に送ります。

Send to Journey は、対象者を Marketing Cloud Engagement の Journey に送ります。

例えば、ロイヤルティステータスによって、対象者を異なるフローや Journey に振り分けることができます。

エンゲージメントイベントを待つ

Wait Until Event は、特定のエンゲージメントイベントが発生するまで処理を待機します。

例えば、Email Link Click や SMS Response、カスタムエンゲージメントシグナルなどを待ち、そのイベントが発生した後にフローを再開できます。

試験のポイント

試験では、要素名を丸暗記するよりも、要件に対してどの要素を選択するかを押さえておきましょう。

• 同意を Opt In / Opt Out に変更する → Create Consent

• Contact / Lead / Prospect を判定する → Determine CRM Record for Individual

• Einstein のエンゲージメント結果で分岐する → Einstein Decision

• 対象者をフローから離脱させる → Exit from a Flow

• 複数のパスを比較・最適化する → Path Experiment

• 別の Marketing Cloud Flow へ送る → Send to a Flow

• Marketing Cloud Engagement Journey へ送る → Send to Journey

• クリックや SMS 返信などを待つ → Wait Until Event

• 各チャネルからメッセージを送信する → Send Email / SMS / WhatsApp など

Path Experiment（パス試験）

Salesforce は、このパス試験を大きく取り上げている傾向がありますので、Advanced Edtion 限定の機能ではありますが、学習してください。

Marketing Cloud Next の「パス試験（Path Experiment）」要素は、顧客を複数のパスへランダムに振り分け、どのカスタマージャーニーが最も効果的かを比較・検証する機能です。

最大 10 個のパスを作成でき、自動選択 または 手動選択 によるテストが可能です。

利用条件

パス試験を利用するには、Marketing Cloud Manager または Marketing Cloud Admin 権限セットが必要です。

また、事前に Personalization（パーソナライゼーション）機能の設定が必要です。

パス試験を利用できるフローは、次の 2 種類です。

• Automation Event-Triggered Flow

• Segment Flow

パス試験の 3 つの使い方

試験対策としては、パス試験を次の 3 パターンに分けて理解すると分かりやすいです。

① ランダム分岐

単純に、指定した割合に基づいて顧客を複数のパスへランダムに振り分けます。

Manual（手動）を選択し、サブセットテストを使用しないことで、シンプルな「ランダム分岐」として利用できます。

たとえば、2つのパスを 50%：50% に設定しても、実際の人数が必ず半分ずつになるわけではありません。

パスへの割り当ては、個人の一意の ID と実験 ID を基に個別に決定されるためです。そのため、6人であれば 3：3 ではなく、4：2 になることもあります。

設定した割合は保証された件数ではなく、確率的な目標値であることが重要です。母数が大きくなるほど、実際の割合は設定値に近づきます。

※ また、一度パスが割り当てられた個人は、ループや Go To コネクタによって同じ実験へ再度入っても、同じパスに割り当てられます。

② Path Optimizer（自動）

Automated（自動）を選択すると、テストグループの結果からシステムが勝者パスを判定し、残りのオーディエンスを最適なパスへ送ることができます。

設定する主な項目は、次のとおりです。

• Performance Metric：勝者を判定する指標

• Test Group：実験対象とするオーディエンスの割合

• Duration：テスト期間

• Fallback Behavior：勝者を決定できなかった場合の動作

Performance Metric には、Email Link Clicks などの標準イベントだけでなく、カスタム Engagement Signalも利用できます。

自動選択では、ベイズ予測（Bayesian Prediction）を使用します。

あるパスが他のすべてのパスを上回る確率について、95%以上の信頼度 に達すると、そのパスが勝者として選択されます。

95%に達するパスがなかった場合は、あらかじめ指定したフォールバック動作が適用されます。

③ Path Optimizer（手動）

Manual（手動）を選択し、Test a subset of your audience（オーディエンスの一部をテストする）を有効にすると、オーディエンスの一部で先にテストを行えます。

たとえば、オーディエンスの 20% で複数のパスをテストし、残りの 80% を一定期間待機させる、といった使い方です。

テストグループの割合と待機期間を設定し、結果を確認しながら人間が勝者パスを選択できます。

ただし、サブセットテストを利用できるのは、1 回のみ実行するように設定されたフローに限られます。

パスの設定

パスは最大 10 個まで作成できます。

各パスには、主に次の情報を設定します。

• Path Label

• Path API Name

• Path Percentage

すべてのパスの Path Percentage の合計は 100% にする必要があります。

たとえば、A：50%、B：30%、C：20% といった設定が可能です。

アクティブ化後でも勝者を手動選択できる

フローをアクティブ化した後でも、パス試験要素の Winning Path から勝者パスを手動で指定できます。

勝者を指定すると、新規・残り・待機中のオーディエンスはすべてそのパスへ送られます。

重要なのは、勝者パスを手動で選択しても、新しいフローバージョンを保存する必要がないことです。

分析・履歴・通知

パス試験には、結果を確認するための機能も用意されています。

Analytics タブでは、各パスの参加者数、Performance Metric、Confidence Level などを確認できます。また、Open Details から各パスの Outcome Metric を確認できます。

History タブでは、アクティブ化後に発生した変更を追跡できます。実験開始、勝者選択、待機グループの解放、フォールバック処理などについて、いつ・誰が・自動または手動のどちらで変更したかを確認できます。

さらに、パス試験が完了すると、フローをアクティブ化したユーザーへアプリ内通知 が自動的に送信されます。勝者やフォールバックの発生、結果が確定しなかったことなどを確認できます。

試験のポイント

試験では、特に次の点を押さえておきましょう。

• パス試験では最大 10 個のパスを比較できる

• Automation Event-Triggered Flow と Segment Flowで利用できる

• 利用には Personalization の設定が必要

• Marketing Cloud Manager または Marketing Cloud Admin 権限セットが必要

• Automated では ベイズ予測 を使用して勝者を判定する

• 95% 以上の信頼度で他のすべてのパスを上回ると勝者になる

• 勝者が決まらなければ Fallback Behavior が適用される

• Manual では、Salesforce 外部のデータなども考慮して人間が勝者を選択できる

• サブセットテストは 1 回のみ実行するフローで利用できる

• パスの割合の合計は 100%

• 設定した割合は 正確な人数配分を保証するものではない

• 同じ個人が実験へ再度入った場合も 同じパスに割り当てられる

• アクティブ化後でも 新しいフローバージョンを作成せずに勝者を手動選択できる

• Analytics / History / 完了時のアプリ内通知 で実験結果や変更を確認できる

特に試験問題では、「単純にランダム配分したい」「システムに自動で勝者を決めさせたい」「外部データも考慮して人間が勝者を決めたい」というシナリオから、適切な設定を選ばせる問題が出しやすいところです。

Activation Template

Data 360 では、データソース違いで、1 人の顧客に対して複数の連絡先情報が存在することがあります。

たとえば、ある Unified Individual に、

• Marketing Cloud Engagement：aaa@example.com

• CRM：bbb@example.com

• Amazon S3：ccc@example.com

という 3 つのメールアドレスが紐づいているとします。

ID 統合によって同一人物に統合されても、これらの Contact Point が 1 つのメールアドレスに統合されるわけではありません。複数の Contact Point は残ります。

そこでどのメールアドレスを使うの？を決めるのが Source Priority Order です。

Primary / Any / Personal / Business

Contact Point の選択条件として、次のタイプを利用できます。

• Primary：Primary Flag がマッピングされている場合に使用可能

• Any：利用可能な Contact Point から選択

• Personal：For Personal Use = 1 の Contact Point

• Business：For Business Use = 1 の Contact Point

したがって、「会社メールより個人メールを優先する」といった制御も、必要な項目がマッピングされていれば可能です。

また、Any を選択しないことで、指定したソースやタイプだけに限定できます。ただし、その条件を満たす Contact Point がない人は Activation の対象から外れるため、母集団は減る可能性があります。

データグラフの設定

Source Priority Order を利用して、Unified Individual に複数のメールアドレスが紐づいている場合にどのメールアドレスを優先するかを制御するには、事前に Unified Individual を起点としたデータグラフを準備します。

データグラフでは、次のパスを接続します。

Unified Individual → Unified Link Individual → Individual → Contact Point Email

また、Contact Point Email では Data Source 項目を必ず追加します。

Data Source が含まれていない場合、メールアドレスがどのデータソースから取得されたものなのかを判別できないため、Source Priority Order を正しく適用できません。その場合は Any Source と同様の扱いになります。

さらに、Email Type で特定の種類のメールアドレスを優先したい場合は、用途に応じて次の項目もデータグラフに追加します。

• Primary Flag：プライマリーのメールアドレスを使用

• For Personal Use：個人用のメールアドレスを使用

• For Business Use：ビジネス用のメールアドレスを使用

たとえば「CRM の Primary Email を最優先し、存在しなければ別ソースのメールアドレスを使用する」といった優先順位を設定できます。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• Identity Resolution 後も、複数ソースの Contact Point は残る

• Reconciliation Rules は Unified Individual の項目を調整するもので、Unified Contact Point の選択には使用されない

• Activation でどの Contact Point を使うかは Source Priority Order で決める

• Any を削除すると特定ソースに限定できるが、母集団が減る可能性がある

• Source Priority Order を利用するには、データグラフに Data Source を含める

マーケティングコンテンツを作成する

注：パーソナライズされたマーケティングメールのコピーを作成すると、コピーされたメールには一部の要素が含まれません。

• 動的コンテンツ：コピーされたバージョンには、元のコンポーネントのデフォルトのバリエーションが含まれます。コピーされたバージョンには、その他のバリエーション、パーソナライゼーションポイント、決定事項、およびルールは含まれません。

• レコメンダーデータソース：コピーされたバージョンにはレコメンダーは含まれていませんが、レコメンダーを使用するマージフィールドとリピーターは含まれています。コピーされたバージョンにレコメンダーを追加するか、レコメンダーに関連するすべての要素を削除してください。

マーケティングワークスペース

Marketing Cloud Next で作成したコンテンツは、マーケティングワークスペースに保存されます。

デフォルトのワークスペースに加えて、チームや施策ごとに追加のワークスペースを作成し、フォルダーを使ってコンテンツを整理できます。

ワークスペース間のコンテンツ共有

ワークスペースを別のワークスペースと共有することで、同じコンテンツを複数のワークスペースから利用できます。

共有されたコンテンツは、ターゲットワークスペースの ［ワークスペースと共有］フォルダーに表示されます。

ただし、ソースコンテンツを変更できるのはソースワークスペースのコンテンツ作成者のみです。

また、共有は自動的に連鎖しません。

たとえば、A → B → C とワークスペースを共有していても、A の画像を C で利用・公開するには、A → C の共有も必要です。

ワークスペースの削除

組織のデフォルトのマーケティングワークスペースは削除できません。

その他のワークスペースを削除する場合は、事前に次の対応が必要です。

• ワークスペース内のすべてのコンテンツを公開解除

• ソース／ターゲットの共有関係から削除

試験のポイント

試験では、次のポイントを押さえておきましょう。

• ワークスペースはコンテンツの整理・チーム間共有に利用する

• 共有コンテンツは［ワークスペースと共有］フォルダ に表示される

• ソースコンテンツを変更できるのはソース側の作成者

• ワークスペース共有は 推移的ではない（A → B → C でも A → C にはならない）

• ソースコンテンツがすべてのワークスペースでどこで使用されているかを特定するには、ソースコンテンツの詳細レコードを開き「使用状況情報」（Usage Info）タブをクリックします。

• デフォルトのマーケティングワークスペースは削除できない

• 削除前にコンテンツの公開解除と共有関係の解除が必要

コンテンツのブランディング

Marketing Cloud Next では、ブランド（Brand）を作成し、マーケティングコンテンツ全体に統一されたデザインやブランドイメージを適用できます。

ブランドでは主に、以下を設定できます。

• 会社のカラー

• フォント

• ボタンのスタイル

• ブランドアイデンティティ

• ブランドトーン

ブランドは複数作成でき、Marketing Workspace ごとにデフォルトブランドを設定できます。また、特定の商品やイベントなどでは、コンテンツごとに別のブランドを指定することもできます。

ブランドは主にメール、ランディングページ、フォームに割り当てます。ランディングページとフォームでは、デスクトップ用とモバイル用のスタイルを個別に設定できます。ただし、モバイル専用のブランド設定はメールには適用されません。

Agentforce との関係

ブランドアイデンティティとブランドトーンは、Agentforce がメール、ランディングページ、SMS などのコンテンツを生成するときにも利用されます。

これにより、AI が企業のブランドイメージやトーンに沿った文章を生成できます。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• ブランドでカラー、フォント、ボタン、ブランドアイデンティティ、トーンなどを統一できる

• Marketing Workspace ごとにデフォルトブランドを設定できる

• コンテンツごとに別のブランドへ変更することも可能

• 未公開ブランドを使用したコンテンツを公開すると、関連するブランドも同時に公開される

• ランディングページとフォームでは、デスクトップ用とモバイル用のブランドスタイルを個別に設定できます。モバイル専用のブランド設定はメールには適用されず、個別設定はできません。

• ブランドアイデンティティとブランドトーンは、Agentforce のコンテンツ生成にも利用される

動的コンテンツ

Marketing Cloud Next では、受信者の属性などに応じて、メールやランディングページのコンテンツを動的に切り替えることができます。

動的コンテンツの中心となるのが、パーソナライゼーションポイント（Personalization Point）です。動的コンテンツの最初のバリエーションを作成すると、パーソナライゼーションポイントが自動的に作成されます。

各バリエーションには、決定（Decision）とターゲティングルールが関連付けられます。ターゲティングルールでは、属性、関連属性、計算済みインサイト、セグメントメンバーシップなどを条件として利用できます。利用できる属性はデータグラフによって決まります。

複数のバリエーションに該当した場合は優先度に従って表示内容が決まり、どの条件にも一致しない場合はデフォルトバリエーションが表示されます。

パーソナライゼーションポイントのリンク

複数のコンポーネントを同じパーソナライゼーションポイントにリンクすることで、同じターゲティングルールやバリエーションを共有できます。

たとえば、画像とボタンをリンクしておけば、「ハイキング」と「ランニング」という同じ条件で両方を切り替えられます。

リンクされたコンポーネントでは、バリエーションの追加・削除、ターゲティングルール、優先度の変更がすべてのコンポーネントに反映されます。一方、画像やテキスト、スタイルなどのコンテンツ自体は同期されません。

リンクを解除すると、パーソナライゼーションポイントが複製され、それまでのルールや優先度を保持したまま個別に編集できるようになります。

試験のポイント

• 動的コンテンツはメールとランディングページで利用できる

• パーソナライゼーションポイント → 決定 → ターゲティングルールの関係を理解する

• 利用できるターゲティング属性はデータグラフによって決まる

• 複数条件に一致した場合は優先度で決定する

• 一致しない場合はデフォルトバリエーションを表示する

• 1 つのメールまたはランディングページに最大 25 個のパーソナライゼーションポイント

• 各コンポーネントには最大 15 個のバリエーション

• 複数コンポーネントを 1 つのパーソナライゼーションポイントにリンクできる

• リンクにより、25 個の制限を超えて 25 個以上のコンポーネントをパーソナライズすることも可能

• リンクされたコンポーネントではルール・バリエーション・優先度が同期されるが、コンテンツ自体やスタイルなどは同期されない

• リンク解除するとパーソナライゼーションポイントが複製される

• バリエーションを含むコンテンツはエクスポート／インポートできない

リピーターコンポーネント

リピーター（Repeater）は、データソースから取得した複数のレコードを、メール内に繰り返し表示するためのコンポーネントです。

例えば、顧客ごとに最近閲覧した商品、注文履歴、イベント、プロモーションなどを一覧表示できます。

リピーターでは、リピーターソースを選択し、内部の画像や見出しなどのコンポーネントにマージフィールドを設定してデータを動的に表示します。また、式を使用して、表示するデータのフィルタリングや並べ替えもできます。

Salesforce Personalization との連携

Salesforce Personalization の Recommenderをリピーターソースとして使用し、顧客ごとに複数のおすすめ商品やサービスを表示することもできます。

ただし、利用できるのはメールと同じ Data Graph に基づいて学習された Recommender のみです。

試験のポイント

• Repeater = 複数のアイテムを繰り返し表示

• リピーターソースのデータをマージフィールドで表示

• データのフィルタリング・並べ替えが可能

• Salesforce Personalization の Recommender も利用可能

• 対象データがない場合、リピーター部分は空で表示

• 設定後にレイアウトを変更すると、内部のコンテンツ・データ・スタイルが削除される

コンテンツのパーソナライズに使用するデータソース

Marketing Cloud Next では、メールなどのコンテンツに顧客ごとのデータを埋め込むために データソース（Data Source）を追加します。

データソースを追加すると、そのデータを以下のような機能で利用できます。

• 差し込み項目（Merge Fields）

• 式（Expressions）

• リピーター（Repeater）

• 動的コンテンツ（Dynamic Content）

例えば、顧客名をメール本文に差し込んだり、購入商品を繰り返し表示したり、顧客属性によって表示内容を変更したりできます。

Data Graph

• Data Graph は、Data 360 の DMO と関連オブジェクトをまとめ、パーソナライズなどで利用しやすくしたデータ構造です。

• Marketing Cloud Next のパーソナライズでは、通常 Unified Individual を起点とした Profile Data Graph を使用します。

• これにより、個人の基本情報だけでなく、関連する購入履歴やケースなどのデータもコンテンツから参照できます。

• Data Graph には Standard と Real-Time があり、Landing Page では応答速度やパフォーマンスの観点から Real-Time Data Graph が推奨されています。

• また、デフォルトの Data Graph を設定 でき、Email では通常、このデフォルト Data Graph で多くのパーソナライズ要件を満たせます。

Unified Individual

• デフォルトの Data Graph を設定していない場合に、Unified Individual DMO の項目を Merge Fields として利用できます。

• デフォルトの Data Graph を削除した場合も、Unified Individual がフォールバックとして利用できます。

• Starter / Pro Suite の Email では、Unified Individual DMO を参照する Merge Fields のみ利用できます。

Event

• Event は、注文完了やフォーム送信など、フローを開始するイベントのデータをコンテンツで利用するためのデータソースです。

• 1 つのコンテンツで使用できる Event Data Source は 1 つだけです。

• また、コンテンツを公開すると Event Data Source を削除・置換できなくなります。

Offer（Summer '26 の最新）

• Offer をデータソースにすると、オファー名、説明、クーポンコードなどを Email に差し込めます。

• Dynamic Content と組み合わせて、ロイヤルティランクなどの条件によって異なるオファーを表示することもできます。

• 1 つの Email に最大 5 つの Offer Data Provider を追加できます。

Personalization Recommender

• Salesforce Personalization の Recommender を利用して、顧客の興味・関心に基づくレコメンデーションを Email に表示できます。

• Recommender のデータは Repeater Component と、その内部の Merge Fields でのみ利用可能です。

• また、Email と同じ Data Graph を使用してトレーニングされた Recommenderを選択する必要があります。

Content Variable

• Content Variable は、Flow から実行時に値を渡すための動的なプレースホルダーです。

• Salesforce Flow で利用可能なデータソースにマッピングでき、MuleSoft や HTTP Connectorなどのデータも利用できます。

Salesforce Record

• 最新の Salesforce データを直接 Email のパーソナライズに利用したい場合は、Salesforce Record を使用します。

• 例えば Case や Lead などの Salesforce オブジェクトをデータソースとして追加し、その項目の最新の値を Merge Fields から参照できます。

Lookup Data Graph

• Lookup Data Graph は、商品カタログなどの非プロファイルデータを参照するために使用します。

• Primary Key を指定して受信者に関連するデータを取得します。

• 1 つのコンテンツに追加できる Lookup Data Graph Data Provider は最大 5 つです。

Apex Class

• Apex Class をデータソースとして、Flow からコンテンツへデータを直接渡すこともできます。

• 名前などの単純な値だけでなく、注文確認メールで使用する注文コレクションのような複雑な構造化データにも対応します。

ただし、1 つのメッセージで使用できる Apex Class Data Source は 1 つだけです。

Activation

• Activation をデータソースにすると、Data 360 の Segmentation Activation に含まれる受信者の属性を Email で利用できます。

• これにより、Activation に含まれる Segment Attribute を Merge Fields などから参照できます。

こちらも、1 つのメッセージで使用できる Activation Data Source は 1 つだけです。

試験のポイント

試験では、特に次を押さえておきましょう。

• Data Graph：Unified Individual と関連データを使った基本的なパーソナライズ

• Unified Individual：Data Graph がなくても Merge Fields で利用可能

• Event：1 コンテンツにつき 1 つ。公開後は削除・置換不可

• Offer：Email に最大 5 つ

• Personalization Recommender：Repeater 内で利用。同じ Data Graph が必要

• Lookup Data Graph：商品カタログなどの非プロファイルデータ。最大 5 つ

• Apex Class：Flow から構造化データを渡せる。1 メッセージにつき 1 つ

• Activation：Segment Activation の属性を利用。1 メッセージにつき 1 つ

• Landing Page では Real-Time Data Graph が推奨

• SMS / WhatsApp では Default Data Graph のみ利用可能

• Data Source の属性を Merge Fields ですでに使用している状態で Data Source を変更する場合、既存の Merge Fields を削除して作り直す必要がある

• Form と Landing Page などを組み合わせる場合、使用する Data Graph を一致させる必要がある

メールのプレビューとテスト

Marketing Cloud Next では、メールを送信する前に実際の受信者データを使用してプレビューし、テストメールを送信できます。

プレビューとテストを利用するには、少なくとも 1 つのセグメントが公開されている必要があります。

プレビューでは、セグメントとサンプル受信者 を選択して、マージフィールドなどがどのように表示されるか確認します。

テスト送信では、アクセス可能なメールアドレスを最大 5 件指定できます。また、送信元には 認証済みドメイン のアドレスを使用します。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• プレビューとテストには、公開済みのセグメントが少なくとも1つ必要

• テスト送信先は 最大 5 メールアドレス

• テスト送信も メッセージクレジットを消費する

• マージフィールド、リンク、ボタン、特にオプトアウトリンクを確認する

• プロモーションメールには、要件を満たす 完全な住所（Physical Mailing Address）が必要

マーケティングランディングページの URL 管理

※ マーケティングランディングページの作成方法は、基本的にメールと変わりませんが、以下が独特ですので、覚えてください。

Marketing Cloud Next のランディングページでは、公開 URL、URL エイリアス、URL リダイレクトを管理できます。

公開 URLは、ランディングページを公開すると生成される URL です。複数のドメインが設定されている場合は、複数の公開 URL を利用できます。

URL エイリアスは公開 URL の末尾に付く文字列で、バニティ URLとも呼ばれます。編集できるのは下書き状態のみです。

URL エイリアスには、下書き・有効・非アクティブの3つの状態があります。エイリアスを有効化するとランディングページが公開され、無効化するとアクセスできなくなります。

ランディングページの公開解除

ランディングページを 公開解除（Unpublish）すると、下書き状態に戻り、後から再公開できます。

公開解除後は、訪問者は公開 URL や URL エイリアスからページへアクセスできなくなります。

別のページへ誘導したい場合は、公開解除前に URL エイリアスを無効化して URL リダイレクトを設定します。リダイレクトを設定しない場合、訪問者は一般的な「URL が存在しません」ページへ誘導されます。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• URL エイリアスは公開 URL の末尾に設定される

• URL エイリアスを編集できるのは下書き状態のみ

• URL エイリアスの有効化／無効化が公開状態と連動する

• 公開解除すると下書き状態に戻り、再公開できる

• 公開解除後のアクセスを別ページへ誘導する場合はURL リダイレクトを設定する

マーケティングカレンダー

マーケティングカレンダー（Marketing Calendar）では、キャンペーンやフローのスケジュールを一元的に確認・管理できます。

デフォルトでは、キャンペーン、キャンペーンセグメントフロー、セグメントフローのカレンダーが用意されています。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• 日／週／月単位でキャンペーンやフローを確認できる

• イベントからステータス、開始日、セグメント、対象者数などを確認できる

• キャンペーンの日付は、ドラッグして日付を変更可能

• セグメントフローの送信日は、ドラッグして日付を変更できない

• イベントトリガーフロー（フォームトリガーフロー）など開始日がないものは、カレンダーには表示されない

• アクセス権のあるキャンペーンとフローのみ表示される

• カレンダーにイベントを追加し、キャンペーンと関連付けることができる

特に、「キャンペーンはドラッグで日付変更可能、セグメントフローは不可」と、「イベントトリガーフロー（フォームトリガーフロー）はカレンダーに表示されない」という違いは押さえておきましょう。

Agentforce と AI イノベーション

（割合：11%）… 6 問想定

このセクションでは、Marketing Cloud Next における Agentforce や AI の活用について問われます。

• Agentforce Marketing Agents を利用して、キャンペーン作成、オーディエンスセグメント、コンテンツ生成を自動化できる。

• シナリオに応じて、会話型メッセージングを構成し、顧客との継続的なコミュニケーションや応答処理を実現できる。

• シナリオに応じて、適切な予測 AI 機能を選択できる。

Marketing Cloud Next の AI 機能

Trailhead を見る限り、Marketing Cloud Next の AI 機能においては、

• 生成 AI ＝ Agentforce

• 予測 AI ＝ Einstein

という分け方で良いようです。

そして、Agentforce（生成 AI）では、データの質が高く、データが利用可能な状態（可用性）である ことをよく確認しておくことが重要です。high quality と available がキーワードです。

一方、Einstein（予測 AI）は、機械学習アルゴリズムを使用して過去のデータを分析し、将来のイベント、結果、またはトレンドについて的確な予測を行います。パターンとトレンドを分析して、顧客の行動、嗜好、エンゲージメントの可能性を予測します。

Growth Edition と Advanced Edition 両方で利用可能な AI 機能

生成 AI

• Agentforce Campaign Creation
  Agentforce を利用してキャンペーンを作成するためのエージェントテンプレート

• Agentforce Account Discovery
  蓄積されたマーケティングデータや営業活動の情報を横断的に分析し、営業担当者が次に取るべきアクションを提案する AI エージェント

予測 AI

• Einstein Send Time Optimization（ESTO）
  エンゲージメントが最大化するよう、最適な送信時間を予測

• Einstein Metrics Guard（EMG）
  ボットによる偽の開封やクリックをそうであると予測して除外し、エンゲージメント指標をより正確にする

Advanced Edition でのみ利用可能な AI 機能

Growth Edition の機能に加えて、以下を利用できます。

生成 AI

• Agentforce Journey Decisioning
  Marketing Cloud Engagement の Journey Builder で、購読者を適切なジャーニーに分類するためのエージェントテンプレート

予測 AI

• Einstein Engagement Frequency（EEF）
  メッセージ疲れを防ぐため、最適なエンゲージメント頻度を予測

• Einstein Engagement Scoring（EES）
  過去のデータをもとにコンタクト単位でスコアを算出し、エンゲージメントを予測

試験のポイント

まずは、どの機能が生成 AI であり、どの機能が予測 AI であるかの分類ができるようになることと、Growth Edition と Advanced Edition で利用できる AI 機能の違い をしっかりと押さえておきましょう。AI は基礎的な問題が多いはずなので、暗記しておけば正解できるはずです。

特に予測 AI は、名前から役割を連想できます。

• ESTO = Time → いつ送るか

• EEF = Frequency → どのくらい送るか

• EES = Scoring → 誰が反応しそうか

• EMG = Metrics → ボットによる偽の反応を除外

実際の設問では、「あるシナリオが書いてあって、どの予測 AI を利用するか？」という問題が出てもおかしくありません。Einstein は昔からブラックボックスな部分が多いので、細かい内容はおそらく問われないと思います。

Campaign Creation Agent について

Campaign Creation Agent については、まず キャンペーンがどのような流れで作成されるのかを押さえておきましょう。

Campaign Creation Agent のキャンペーンやコンテンツの作成の流れ

「キャンペーンを作成したい」と会話を開始すると以下の流れになります。この流れは丸暗記してよいと思います。

① ビジネスユニット（データスペース）を特定します
裏側で、キャンペーンを作成するビジネスユニット（データスペース）が特定されます。
　↓
② キャンペーンの目的を確認します
どのようなキャンペーンを作成したいのか、目的や概要を聞かれます。
※ 少し細かい話ですが、Salesforce Files にアップロードした既存のブリーフや戦略文書を参照させ、それを基にブリーフを作成することもできます。
　↓
③ 双方向シナリオにするかを確認します
顧客との双方向のやり取りを含むキャンペーンにするかを選択します。
　↓
④ キャンペーンブリーフが作成されます
入力したキャンペーンの目的などをもとに、ブリーフが完成します。
　↓
⑤ シナリオのプレビューが提示されます
作成されたブリーフをもとに、キャンペーンシナリオのプレビューが提示されます。
　↓
⑥ ブランドやシナリオを調整します
ブランドを追加したり、シナリオの要素やメッセージを必要に応じて修正します。
　↓
⑦ キャンペーンを作成します
完成したブリーフとシナリオをもとに、キャンペーンを作成します。
　↓
⑧ フローやコンテンツが自動作成されます
キャンペーンに必要なフローやメッセージコンテンツが作成されます。
※ 双方向シナリオを選択した場合は、フローの最後に「エージェントに転送」要素が追加されると一応覚えておきましょう。

これに関連する Agentforce の機能として、以下も押さえておきましょう。

• コンテンツの改善
  メールの件名や本文などを Agentforce を使って洗練できます。

• オーディエンスの作成
  ブリーフの情報をもとに、適切なオーディエンスをターゲットとするセグメントを AI で作成できます。

• キャンペーンパフォーマンスの要約
  開封率、クリック率、バウンス率などのキャンペーンパフォーマンスを要約できます。

カスタムエージェントにもできる

これらの機能は、標準の状態で利用するだけではありません。

フローなどを組み合わせることで、企業独自の要件に合わせてカスタマイズしたエージェントを構築することも可能です。

これらは決して、標準の状態で利用せずに、フローなどを用いて企業の独自要件に合わせて、カスタムエージェント可することが可能です。

Agentforce アイコンが表示されない場合

そして、もう一つ問われる可能性があるとすれば、機能の有効化の件です。

Campaign Creation Agent は Employee Agent タイプのエージェントであり、エージェントを利用するのは、顧客ではなく Marketing Cloud Next のユーザーです。このタイプのエージェントでは、エージェントへのアクセス権限を付与する必要があります。ですので、「なぜ画面上部に Agentforce アイコンが表示されないか？」と問われたら、ユーザーに対して「エージェントへのアクセス権が不足しているため」という回答になりますので、覚えておいてください。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• ブリーフ → プレビューの確認 → キャンペーン → 本番フロー／コンテンツの確認という作成の流れ

• ブリーフをもとにオーディエンスやコンテンツも生成できる

• 双方向シナリオでは、「エージェントに転送」要素 が追加される

• 標準機能だけでなく、企業要件に合わせてカスタマイズ可能

• Campaign Creation Agent は Employee Agent タイプ

• 利用するユーザーにはエージェントへのアクセス権限が必要

Conversational Marketing（会話型マーケティング）

Conversational Marketing（会話型マーケティング） は、従来の一方向のメッセージ配信を、Agentforce を活用した双方向のコミュニケーションへ発展させる仕組みです。

従来のメールマーケティングなどでは、企業から顧客へメッセージを配信し、メールを開封したりリンクをクリックしてもらったりする、一方向の Broadcast Model（ブロードキャストモデル） が中心でした。

会話型マーケティングでは、顧客が受け取ったメッセージにそのまま返信し、Agentforce と会話を続けることができます。

• 従来型（Broadcast Model）
  企業 → メッセージ → 顧客

• 会話型（Conversational Model）
  企業 / Agentforce ⇄ 顧客

例えば、商品のプロモーションメッセージを受け取った顧客が「自分にはどのサイズが合いますか？」と返信すると、Agentforce が Data 360 の購入履歴や返品履歴などを参照して回答し、そのまま商品の購入まで進めることができます。

つまり、単に顧客と会話することが目的ではありません。顧客データを利用してパーソナライズされた会話を行い、プロアクティブに、購入、予約、アップセルなどの具体的なビジネス成果につなげることが重要です。

※「プロアクティブ」がキーワードです。

対応するチャネル

会話型マーケティングでは、次の 3 つのチャネルがサポートされています。

• メール

• SMS

• WhatsApp

会話型マーケティングを構成する4つの要素

会話型マーケティングは、主に 「チャネル」「フロー」「Agentforce」「Data 360」 の4つの要素で構成されます。

① チャネル

顧客との会話の入り口です。顧客はメール、SMS、WhatsApp などのチャネルを通じてメッセージを受け取り、そのまま返信して会話を開始できます。

② フロー

顧客にメッセージを送信し、会話を開始するタイミングを制御します。

例えば、顧客のロイヤルティレベルが変更されたことを条件として SMS を送信し、顧客から返信があった場合に Agentforce へ会話を引き継ぐ、といった処理が可能です。

③ Agentforce

実際に顧客との会話を担当します。

単純なキーワードへの応答ではなく、顧客の質問や意図を理解し、コンテキストを検索して、設定された指示やブランドのトーンに従って回答します。

④ Data 360

Agentforce に顧客のコンテキストを提供します。

統合された顧客プロファイルや購入履歴などを利用することで、一般的な回答ではなく、顧客一人ひとりの状況に応じたパーソナライズされた会話が可能になります。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• Conversational Marketing は、一方向の Broadcast Model を双方向のコミュニケーションへ発展させる仕組み

• 対応チャネルは、メール、SMS、WhatsApp

• 「チャネル」「フロー」「Agentforce」「Data 360」の 4 つの要素で構成される

• フローが会話を開始するタイミングを制御し、Agentforce が顧客との会話を担当する

• Data 360 の顧客データを利用して、パーソナライズされた会話を実現する

• 会話そのものが目的ではなく、プロアクティブに、購入、予約、アップセルなどの具体的なビジネス成果につなげることが重要

Einstein Trust Layer による AI の保護

Marketing Cloud Next では、Agentforce が生成 AI を利用して顧客と会話するため、不適切な回答やハルシネーション、顧客データの取り扱いにも注意する必要があります。

これらのリスクから企業と顧客のデータを保護するために利用されるのが、Einstein Trust Layer です。

Einstein Trust Layer では、AI に送信するデータから回答が生成されるまでのさまざまな段階で、安全性を確保するための仕組みが提供されています。

ブランドと回答を保護する仕組み

Agentforce がブランドに適さない回答や、不適切な回答を生成しないようにするため、次のような仕組みが利用されます。

カスタムガードレール

ブランドガイドライン、FAQ、トーンなどを指定し、Agentforce がどのように回答すべきかを制御します。

Toxicity Scorer（毒性スコアラー）

AI が生成した回答を評価し、有害または不適切なコンテンツを検出してブロックします。

Dynamic Grounding（動的グラウンディング）

信頼できる企業データや顧客データなどを AI の回答に組み込むことで、回答を実際のデータに基づかせ、ハルシネーションを抑制します。

顧客データを保護する仕組み

生成 AI を利用する際には、顧客の個人情報を外部の LLM にそのまま送信しないことも重要です。

Data Masking（データマスキング）

電話番号、住所、クレジットカード番号などの PII（個人識別情報）を匿名化されたプレースホルダーへ置き換えてから LLM に送信します。

これにより、LLM に不要な個人情報を渡すことを防ぎます。

Zero Data Retention（データ保持ゼロ）

LLM プロバイダーに、プロンプト、顧客データ、生成された回答を保持させない仕組みです。

送信されたデータは外部モデルの学習にも使用されません。

そのほか、転送中・保存時のデータの暗号化や、AI とのやり取りを記録して確認できる監査機能も提供されています。

Human-in-the-Loop

AI にすべてを任せる必要はありません。

Agentforce だけでは対応できない複雑なケースでは、Human-in-the-Loop によって人間の担当者へ会話をエスカレーションできます。

AI が対応できる範囲は AI に任せ、必要に応じて人間が介入できる仕組みになっています。

試験のポイント

試験では、それぞれの機能が「何を保護するためのものなのか」を区別して覚えておきましょう。

• Einstein Trust Layer： 生成 AI と顧客データを安全に利用するための仕組み

• カスタムガードレール： ブランドガイドラインやトーンなどに従うよう回答を制御

• Toxicity Scorer： 有害・不適切な回答を検出してブロック

• Dynamic Grounding： 信頼できるデータに回答を基づかせ、ハルシネーションを抑制

• Data Masking： PII を匿名化されたプレースホルダーへ置き換えてから LLM に送信

• Zero Data Retention： LLM プロバイダーにプロンプトや顧客データ、回答を保持させない

• Human-in-the-Loop： AI だけでは対応できない場合に人間へエスカレーション

分析とパフォーマンスインサイト

（割合：8%）… 5 問想定

このセクションでは、Marketing Cloud Next の分析機能やレポート機能について問われます。

• シナリオに応じて、要件に最適な標準ダッシュボードを選択できる。

• Salesforce 標準のレポートや分析機能を活用・拡張できる。

• Salesforce プラットフォーム全体でマーケティングデータや分析結果をどのように活用・可視化するかを説明できる。

Marketing Cloud Next の分析とレポート

Marketing Cloud Next では、キャンペーンやコンテンツ全体のパフォーマンスから、メールや SMS などのエンゲージメント、個人単位の活動まで、さまざまな方法でマーケティング成果を分析できます。

試験対策としては、分析機能を大きく 3 種類に分けて整理すると分かりやすいです。

① Data 360 と Tableau Next を利用した分析

Marketing Cloud Next では、Data 360 と Tableau Next の技術を利用した最新の分析機能が提供されています。

代表的なものは次のとおりです。

• Marketing Performance Intelligence：キャンペーンやコンテンツ全体のパフォーマンス、傾向、インサイトを確認

• Campaign Performance：キャンペーン単位のパフォーマンスを確認

• Flow Performance：フロー単位のパフォーマンスを確認

• Content Performance：メール、SMS、WhatsApp、ランディングページ、トラッキングリンクなど、コンテンツ単位のパフォーマンスを確認

• Deliverability：メールの配信到達状況や配信失敗の理由を確認

• Conversion：メールや SMS が 30 日間のコンバージョン期間内で注文完了やフォーム送信などの成果にどのように貢献しているかを追跡します

試験では、それぞれの名称だけではなく、「何のパフォーマンスを確認する機能なのか」を区別しておきましょう。

② CRM 標準のダッシュボードとレポート

Marketing Cloud Next には、CRM 標準のレポート機能を利用したダッシュボードとレポートも用意されています。

• Email Engagement：メールの開封・クリックなどの KPI

• SMS Engagement：SMS のエンゲージメント KPI

• Forms Engagement：フォームのパフォーマンス KPI

• Landing Page Engagement：ランディングページのパフォーマンス KPI

Email、SMS、Forms、Landing Page には、それぞれ全体の統計を確認するダッシュボードと、個別の KPI を確認するレポートがあります。

CRM 標準の機能を利用しているためカスタマイズも可能で、各ダッシュボードでは最大 5 つのフィルターを利用できます。

③ レコードページで確認するエンゲージメント

個々の顧客のエンゲージメントを確認するために、CRM のレコードページへ配置できる LWC も提供されています。

• Engagement Score：Prospect、Lead、Contact のエンゲージメント度合いをスコアで確認

• Engagement Details：Prospect、Lead、Contact の最近のエンゲージメント活動を詳細に確認

Score はエンゲージメントの度合い、Details は実際の活動内容を確認するもの、と区別しておきましょう。

紛らわしいメールのクリック指標

メールの指標では、メールクリック率と Email Click-Through Rate（メールクリックスルー率） の違いに注意してください。

• メールクリック率：送信されたメールのうち、クリックにつながったメールの割合

• Email Click-Through Rate：開封されたメールのうち、クリックにつながったメールの割合

違いは分母です。

メールクリック率 → 送信数
Email Click-Through Rate → 開封数

試験のポイント

試験では、次のポイントを押さえておきましょう。

• Marketing Performance Intelligence は Data 360 と Tableau Next の技術を利用する

• Marketing Performance Intelligence、Campaign Performance、Flow Performance、Content Performance、Deliverability の役割を区別する

• Email、SMS、Forms、Landing Page には CRM 標準のダッシュボードとレポートが用意されている

• CRM 標準のダッシュボードでは最大5つのフィルターを利用できる

• Email Engagement V2 は、V1 より詳細な分析に対応している

• Engagement Score と Engagement Details は Prospect、Lead、Contact のレコードページで利用する

• Engagement Score はスコア、Engagement Details は最近の活動の詳細を確認する

• メールクリック率は送信数、Email Click-Through Rate は開封数を基準にする

レポートの展開・アクセスと権限

Marketing Cloud Next の分析機能を利用する際は、レポートの種類だけでなく、どのように展開するのか、どこからアクセスするのか、どの権限が必要なのかも押さえておきましょう。

レポートの展開

Marketing Performance Intelligence と CRM 標準のダッシュボード／レポートは、基本的に 1 クリックでインストールできます。

ただし、Marketing Performance Intelligence については、新しいレポート機能が追加された場合などに、最新機能を利用するため定期的に再インストールが必要になる場合があります。

その場合は、既存の Marketing Performance Intelligence を削除して再インストールすることで、最新の機能へ更新できます。

Marketing Performance Intelligence へのアクセス

Marketing Performance Intelligence は、分析専用の画面だけでなく、マーケティング業務を行うさまざまな場所からアクセスできます。

代表的なアクセス場所は次のとおりです。

• マーケティングパフォーマンスタブ

• キャンペーンレコード

• フローの要素

• コンテンツのプロパティ

つまり、キャンペーンやフロー、コンテンツを操作している場所から、関連するパフォーマンス情報へアクセスできます。

一方、CRM 標準のダッシュボードやレポートは、主に「分析」タブや「レポート」タブからアクセスします。

Marketing Performance Intelligence に必要な権限

Marketing Performance Intelligence を利用するには、次の権限セットが必要です。

• Tableau Next Included App Business User
  （Tableau Next 付属アプリケーションビジネスユーザー）

この権限セットを持つユーザーが、「マーケティングパフォーマンス」タブを表示してアクセスできます。

標準ダッシュボードとレポートの権限

CRM 標準のダッシュボードやレポートでは、Marketing Performance Intelligence とは権限の考え方が異なります。

それぞれのダッシュボードやレポートが保存されているフォルダへのアクセス権が必要になる場合があります。

そのため、ユーザーが標準のレポートやダッシュボードを表示できない場合は、保存先フォルダへのアクセス権も確認しましょう。

試験のポイント

試験では、次のポイントを押さえておきましょう。

• Marketing Performance Intelligence と標準のダッシュボード／レポートは、基本的に 1 クリックでインストールできる

• Marketing Performance Intelligence は、最新機能を利用するため再インストールが必要になる場合がある

• Marketing Performance Intelligence は、マーケティングパフォーマンスタブ、キャンペーンレコード、フローの要素、コンテンツのプロパティなどからアクセスできる

• CRM 標準のダッシュボードやレポートは、主に「分析」タブや「レポート」タブからアクセスする

• Marketing Performance Intelligence の利用には「Tableau Next Included App Business User」権限セットが必要

• この権限セットによって「マーケティングパフォーマンス」タブへアクセスできる

• 標準のダッシュボードやレポートでは、保存されているフォルダへのアクセス権が必要になる場合がある

Opportunity Influence（商談の影響）

Opportunity Influence（商談の影響）は、リードや取引先責任者によるメールや SMS のクリックエンゲージメントを利用して、成立した商談の収益にどのキャンペーンが影響したのかを分析する機能です。

例えば、1 人の取引先責任者が商談成立までに複数のキャンペーンをクリックした場合、「最初のキャンペーンを評価するのか」「最後のキャンペーンを評価するのか」をアトリビューションモデルによって決定できます。

First Touch と Last Touch

Opportunity Influence で利用できる代表的なアトリビューションモデルは、次の 2 つです。

• First Touch（初回接触）：最初にエンゲージしたキャンペーンに 100% のクレジットを付与

• Last Touch（最終接触）：商談成立前に最後にエンゲージしたキャンペーンに 100% のクレジットを付与

両方のモデルを設定し、それぞれの結果を比較することもできます。

どのエンゲージメントデータを利用するのか

Opportunity Influence では、リードや取引先責任者に紐づく個人オブジェクトのメールや SMS のクリックエンゲージメントデータを利用します。

ここで重要なのは、Data 360 の統合プロファイルのデータは利用しないことです。

また、クリックした人物が、その商談の 取引先責任者の役割（Contact Role）として登録されている必要があります。

つまり、単にキャンペーンをクリックしただけでは、そのキャンペーンが商談へ影響したとは判断されません。

対象となる商談とクリック期間

Opportunity Influence の対象となるのは、Closed Won（成立した商談）のみです。

さらに、すべての過去のクリックが対象になるわけではありません。

対象となるのは、

• 商談作成の 30 日前 → 商談作成 → Closed Won

までに発生したクリックです。

つまり、商談作成前のエンゲージメントも対象になりますが、遡ることができるのは 30 日前までです。

初回のデータ生成

Opportunity Influence を最初に有効化した際には、過去のデータについても一定期間遡って処理されます。

初回のデータは、

• 過去 60 日間のエンゲージメント

• 過去 30 日間に作成された商談

を基に生成されます。

「クリックの対象期間である30日前」と混同しやすいため、この 60 日 / 30 日 の組み合わせにも注意しましょう。

その他の重要な条件

• 複数通貨を利用する組織には非対応

• キャンペーン階層は影響度の計算に含まれない

試験のポイント

Opportunity Influence は条件が多いため、それぞれを区別して覚えておきましょう。

• メールや SMS のクリックエンゲージメントから、キャンペーンが成立した商談に与えた影響を分析する

• First Touch は最初にエンゲージしたキャンペーンに100%のクレジットを付与する

• Last Touch は商談成立前に最後にエンゲージしたキャンペーンに100%のクレジットを付与する

• First Touch と Last Touch の両方を設定して比較できる

• 対象となるのは Closed Won の商談のみ

• 個人オブジェクトのエンゲージメントデータを利用し、Data 360 の統合プロファイルは利用しない

• クリックした人物が商談の Contact Role として登録されている必要がある

• 対象となるクリックは、商談作成の30日前から Closed Won になるまで

• 初回は過去 60 日間のエンゲージメントを基に、過去 30 日間に作成された商談のデータを生成する

• 複数通貨を利用する組織には対応していない

• キャンペーン階層は影響度の計算に含まれない

いかがでしたでしょうか。

この 1 年間、私はほぼ毎日のように Marketing Cloud Next について検証し、記事を書き続けてきました。その認定資格がいよいよ現実のものとなり、自分の理解度を試せる機会が登場するのは、本当に楽しみです。

今回は以上です。

次の記事はこちら

前回の記事はこちら

私の note のトップページはこちら