【第553回】Salesforce 認定 Marketing Cloud Next コンサルタント 資格試験 合格体験記

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

• 試験の申込は こちら（現時点では 英語版のみ です）

• 試験ガイドは こちら

• 2026 年 8 月 21 日 から受験登録が開始されました。

そして、私も 英語版の試験を受験し、無事に合格することができました 🎉

今回の記事では、私が実際に行った試験対策や、受験して感じたことなどを交えながら、Marketing Cloud Next コンサルタント試験の準備方法と受験体験 についてまとめていきたいと思います。

それでは、まずは 試験の概要 から見ていきましょう。

試験概要

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

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

• 3 つの回答からの 1 つの答えの選択式（複数回答なし）

• 試験時間：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

模擬試験

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

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

私の友人であり Salesforce MVP でもある Rodrigo Santander（ロドリゴ・サンタンデール）さんと、この模擬問題の特設サイトを立ち上げました。

サイト上でも模擬問題に挑戦できますので、ぜひ試験対策の一環としてご活用ください。日本語で表示するには、ブラウザ（Chrome など）の「日本語翻訳」機能を用いてください。

合格体験談・感想

ここからは、実際に受験してみて感じたことを書いていきます。あくまで 私個人の体験談 ですので、参考程度に読んでいただければと思います。

私は今回、「英語版」で受験しました。受験時点では、まだ「日本語版」が提供されていなかったためです。

英語で問題を読みながら回答する必要があったこともあり、私の場合は 105 分という試験時間をほぼすべて使い切りました。

最終的には、60 問目を解き終えたところで、ちょうどタイムアップ となりました。

そのため、回答後に問題を振り返ったり、選択した解答を確認したりする時間は取れませんでした。

また、今回は自分自身で模擬試験を作ってきたこともあり、

「この問題では何を理解していることを確認しようとしているのか？」

というところまで考えながら解いてしまった部分もあります。

試験に合格することだけを考えれば、もちろんそこまで分析する必要はありません。今回は、問題を解くと同時に、試験全体の傾向も確認しながら受験していた というのが正直なところです。

問題はすべて 3 択

私が受験した試験では、出題される選択肢はすべて 3 択 でした。

また、複数選択の問題はなく、すべて 1 つの正解を選択する形式 でした。

選択肢の傾向としては、1 つは比較的除外しやすく、残りの 2 つのどちらを選ぶかで判断が必要になる 問題が多かった印象です。

そのため、単純な用語の暗記だけではなく、それぞれの機能の違いや、どのようなシナリオで使用するのかまで理解しておくこと が重要だと感じました。

Summer '26 の最新機能まで出題される

私が受験したのは、2026 年 8 月 22 日 です。

受験登録が始まった 2026 年 8 月 21 日の翌日で、一番最初に予約できた テストセンターの枠 で受験しました。

実際に受験して印象的だったのは、2026 年 7 月にリリースされた Summer '26 の最新機能まで、しっかりと出題範囲に含まれていた ことです。

私自身、最近「最新機能」として記事にしていたような内容も含まれており、現在の Marketing Cloud Next の機能をどこまでキャッチアップできているか も重要だと感じました。

そのため、現時点（2026 年夏時点）で受験するのであれば、基本的な機能だけではなく、Summer '26 までの最新機能についても一通り確認しておくことをおすすめします。

もちろん、基本的な知識を確認する比較的回答しやすい問題もあります。

そして、試験結果です

模擬試験 なんぞ作っておきながら、お恥ずかしい結果となり公開するか悩んだのですが、実際に私がどの程度のスコアだったのかも、参考情報として公開しておきます。

私の試験結果は以下のとおりでした。

• Platform Setup & Governance: 75%（6 / 8）

• Consent: 88%（7 / 8）

• Data Modeling, Identity Resolution & Segmentation: 93%（14 / 15）

• Campaign Design, Flow Orchestration & Content: 88%（16 / 18）

• Agentforce & AI Innovation: 100%（6 / 6）

• Analytics & Performance Insights: 80%（4 / 5）

ということで、全体では 7 問ほど間違えた計算になります。

英語版での受験だったため、長文のシナリオ問題では問題文を正確に読み取ることにも時間を使いました。その結果、後半になるほど時間的な余裕が少なくなったため、英語版で受験される方は、特に時間配分を意識しておくことをおすすめします。

一方で、単純に知識が足りず、回答に迷った問題も数問ありました。

今回の結果からも、Marketing Cloud Next の主要機能だけではなく、細かな設定や比較的新しい機能まで幅広く理解しておくことが重要な試験 だと感じています。

今後、日本語版が利用できるようになったら、再チャレンジしてみたいですね。

受験して分かった試験対策

さて、試験問題そのものについて直接的なヒントを出すことはできませんが、実際に受験した体験をもとに、試験対策としてお伝えできること はいくつかあります。

この note にまとめていますので、ぜひ学習にお役立ていただければと思います。

まず、私の結果を見ると、Platform Setup & Governance が 75% と、他のセクションに比べて低くなっています。

どの問題を間違えたのかを正確に特定することはできませんが、実際に受験した際には、ビジネスユニットに関する知識が重要だと感じました。

そのため、ビジネスユニットについては設定方法だけではなく、権限やデータスペースとの関係なども含めて、しっかり理解しておくことをおすすめします。以下の記事がかなり詳細ですので、是非ご確認ください。

また、私は Agentforce & AI Innovation では 100% でしたが、このセクションについても、基本的な AI の知識だけで回答できるという印象ではありませんでした。

特に、会話型メール（Conversational Email）については、機能の概要だけではなく、設定の流れまで理解しておくことが重要 だと感じました。

この内容については、以前かなり詳しくまとめた記事を書いています。少し長い記事ですが、試験前に一度読んでおくことをおすすめします。

記事はこちら。

さらに Campaign Creation Agent で何ができるのか はもちろん、Summer '26 で追加された Account Discovery Agent まで、それぞれのエージェントが「何をするものなのか」を一通り整理しておくことをおすすめします。

公式セミナーのクイズは必ず確認する

そして、試験対策として特におすすめしたいのが、以下の Salesforce 公式セミナーです。

まず、このセミナーで出てくるクイズは、すべて理解しておくくらいのつもりで確認することをおすすめします。

もちろん、私も一言一句まで覚えていたわけではないので、「まったく同じ問題だった」と断言することはできません。

ただ、実際に受験している中で、

「あれ？ これ、見たことがあるな」

と感じる問題が 数問ありました。

この Web セミナーは Salesforce 公式の試験対策セミナーですので、そこで扱われているテーマは、試験対策として特に重要なポイント だと考えてよいと思います。

そのため、セミナー内のクイズについては、正解だけを覚えるのではなく、なぜその回答になるのかまで理解しておくことをおすすめします。

そして、重要なのはクイズだけではありません。

セミナー内で説明されている内容そのものについても、しっかり学習しておくことをおすすめします。

実際に受験してみると、Marketing Cloud Next の一部の主要機能だけではなく、細かな機能まで含めて、かなり幅広い範囲の理解が求められる試験 だと感じました。

そのため、普段よく利用している機能だけに絞って学習するのではなく、試験範囲に含まれている機能を一通り確認しておくこと が重要です。

合格ラインも 72%（60 問中 43 問以上）ですので、確実に合格するためには、得意な分野だけではなく、各セクションをバランスよく学習しておくことをおすすめします。

それでは、残りの試験対策については、この後の 学習メモ の中で詳しく紹介していきます。

ぜひ、以下の内容もあわせて確認してみてください。

私の学習メモ

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 で利用するのか

• チャネルと同意：メール、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 におけるユーザー権限

Marketing Cloud Next では、標準のマーケティング権限セットとして、主に次の権限セットが用意されています。

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

• マーケティングクラウドマネージャー
  キャンペーン、セグメント、キャンペーンフロー（管理者向け機能を除く）を管理できる権限です。また、Agentforce とプロンプトテンプレートを利用できます。

初期セットアップの流れ

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

1. Data 360 を有効化する

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

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

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

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

試験のポイント

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

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

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

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

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 つのロール を使用します。

1. Marketer-Standard
   キャンペーンの フローを有効化 できます。また、マーケティングワークスペースではコンテンツマネージャーとして、コンテンツの作成、編集、表示、公開が可能です。

2. 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 による検証が完了すると、ステータスが「アクティブ」に変わります。これにより、そのドメインから正当にメールを送信できることが証明されます。

DKIM レコード

• 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 Bounce／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 は キャンペーン単位ではなく、認証済みドメイン単位で設定され、そのドメインから送信されるすべてのメッセージに適用される ことです。また、認証済みドメインが有効になっていなければ、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 プールへメールトラフィックを段階的に移行 します。

移行は、次の順番で進みます。

1. General（共有 IP）

2. Transition（移行中）

3. 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 ですが、その他の DMO についても確認しておきましょう。

1. Communication Subscription
   顧客が Opt-In / Opt-Out できる「購読の種類」を表します。
   例：ニュースレター、製品情報、キャンペーン情報

2. Communication Subscription Channel Type
   その購読を どのチャネルで配信するか を表します。
   つまり、Communication Subscription と Engagement Channel Type をつなぐ役割です。

3. Engagement Channel Type
   コミュニケーションに使用するチャネルの種類 を表します。
   例：Email、SMS、WhatsApp

4. Communication Subscription Consent
   実際の顧客の同意状態 を保持します。
   「どの顧客（Contact Point）が、どの Subscription・Channel に対して Opt-In / Opt-Out しているか」を管理する中心的な DMO です。

試験のポイント

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

• 同意は、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 Cloud トリガーフロー（「Create Consent」アクション）

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

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

データエクスプローラー

データエクスプローラーは、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」アクション）

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

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 を削除すると、それに紐づく同意履歴のレコードも完全に失われてしまいます。

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

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

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

ダブルオプトインでは、利用者が登録フォームを送信した後に、プロモーションメールへのオプトインを必要としない特別な トランザクションメール を送信します。そのメール内のリンクを利用者がクリックして、初めて正式なオプトインが完了します。

これにより、メールアドレスの誤入力や、第三者による不正登録を防止できます。

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

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

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

試験のポイント

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

• 同意は 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 が重要な起点 となる

データストリーム、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

この他に、ID 解決自体にもフィルター機能が新機能として登場しています。

この機能の特徴としては、B2B と B2C のデータを分離する などが挙げられます。この機能については、こちら の記事をよく読んでください。

試験のポイント

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

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

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

• データエクスプローラーの検索対象は、DLO、DMO、Calculated Insights、Data Graphs の 4 種類

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

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

• 2026 年 7 月の新機能で ID 解決フィルターが登場しており、B2B と B2C のデータを分離する などが可能になった

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 解決は、自動、手動、フロー、API から実行できる

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

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

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

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

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

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

一致ルールと調整ルール

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

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

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

ID 解決の流れ

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

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

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

統合の成果物

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

1. 統合プロファイル（Unified Profile）
   統合されたデータを表します。ただし、Individual ID は直接含まれません。そのため、次の統合リンクを利用します。

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 属性を使用してカスタムロジックを定義します。

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

試験のポイント

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

• セグメントでは、直接属性、関連属性、計算済みインサイト を利用できるが、ストリーミングインサイトは利用できない

• セグメントを保存すると、他のセグメントでも、そのセグメントを条件として設定できる

• 直接属性（統合個人の項目）では、集計とネストを利用できない

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

• 関連レコードの条件では、対象とする期間を指定できる

  • 標準公開では、デフォルト 90 日、最大 24 か月のデータを対象にできる

  • 日付には、データストリーム設定時に指定した イベント時刻項目（Event Time Field） を使用する

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

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

• 標準セグメントの公開スケジュールには、次の 3 種類 がある

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

  • 標準公開：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 から利用できない場合があります。

Unified Individual と Individual の接続

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

Unified Individual → Unified Link Individual → Individual

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

データグラフの必須項目

• [Individual] オブジェクトの [Individual ID]

• [Contact Point Email] オブジェクトの [Email Address]

• [Contact Point Phone] オブジェクトの [Telephone Number]

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

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

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

試験のポイント

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

• 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 関数を通じて、メールのパーソナライゼーションに利用できます。

ちなみに、Marketing Cloud Next では、AMPscript は必ず Handlebars に変換されます。

%%[
SET @points = Lookup(
    CustomerRewardMembers__mo,
    RewardsPoints__c,
    EmailAddress__c,
    $dataGraph.Email__c
)
]%%

上記のような AMPscript は、以下のような Handlebars に変換されます。

{{set points=(
  get
    (queryFirst
      type="MO"
      object="CustomerRewardMembers__mo"
      EmailAddress__c=$dataGraph.Email__c
    )
    "RewardsPoints__c"
)}}

この通り、AMPscript の Lookup() は内部的に単純な Handlebars の lookup に置き換わるわけではありません。Marketing Object から値を取得する場合、Handlebars では queryFirst で対象レコードを取得し、get で対象フィールドの値を取得する形になりますので、Handlebars へ変換されることと、queryFirst を使うことくらいは覚えておきましょう。

サポートされるデータ型

マーケティングオブジェクトで利用できるデータ型は、次の 3 種類 です。これは、そのまま丸暗記してください。

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

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

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

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

試験のポイント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 つだけ

• 一時停止中のフローもアクティブ として扱われる

• キャンペーンには、フローの 最後に有効化されたバージョン が表示される

• キャンペーンに関連付けられたフローは、キャンペーンの共有設定を継承 する

• キャンペーンを削除すると、フローは 自身の共有ルール に戻る

• 共有ルールがなければ、フローは 非公開 になる

• キャンペーンまたはフローを削除しても、もう一方のレコードは削除されない

• 削除されるのは、キャンペーンとフローの 関連付け

マーケティングで利用するフローの種類

※ このセクションは本当によく出題されます。最も多く出題されるセクションかもしれません。どのフローがどんな時に利用されるかを念入りに覚えてください。

Marketing Cloud Next では、マーケティング施策に応じて複数の種類のフローを利用できます。

Activation-Triggered Flow

Activation（アクティベーション）が公開されたことをきっかけに実行されるフロー です。

セグメント送信することも可能ですし、Data 360 のセグメントを外部サービスへ連携するようなユースケースでも利用されます。

対象レコードが追加されるタイミングは、セグメントの公開スケジュール に依存します。また、セグメントは手動で更新することもできます。

Automation Event-Triggered Flow

特定のイベントが発生したことをきっかけに実行されるフロー です。

例えば、

といった、顧客の行動に反応するマーケティングに利用できます。

標準で用意されている Automation Event のほか、Engagement Signals を使用してカスタムイベントを定義 することもできます。

Broadcast Flow

Dynamic Segment を使用して対象者を決定し、プログラムから実行するフロー です。

特徴的なのは、フローを開始した後にセグメントメンバーシップが判定される ことです。

例えば、

といった用途があります。

Broadcast Flow は、以下の方法から実行できます。

• API

• Apex

• 別の Flow

On-Demand Flow

必要なタイミングで即座に呼び出すためのフロー です。

特に、優先度が高く、イベント発生に応じて処理したいユースケースに向いています。

例えば、

といった用途です。

API からフローを呼び出す際には、注文 ID や購入金額などの情報を一緒に渡す こともできます。

実行方法は、以下の 2 つです。覚えてください。

• API

• Apex

Audience Flow

特定のオーディエンスを対象として実行する、マーケティングで基本となるフロー です。

対象には、以下を利用できます。

• Segment Members

• List Members

• Campaign Members

• レコード条件によって絞り込んだサブグループ

例えば、

といった施策に利用できます。

Audience Flow は、即時実行またはスケジュール実行 が可能です。

スケジュールは、一度だけ実行することも、定期的に実行することもできます。

また、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 を使用し、フロー開始後に対象となるセグメントメンバーが決定される点が特徴です。

マーケティングフローの要素

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 側は、API Event のエントリーソース である必要があります。

例えば、ロイヤルティステータスによって、対象者を異なるフローや 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 Edition 限定の機能ではありますが、学習してください。

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 内で利用し、Email と同じ 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 機能

Advanced Edition では、Growth Edition の機能に加えて、次の AI 機能を利用できます。

生成 AI

• Agentforce Journey Decisioning
  Marketing Cloud Engagement の Journey Builder で、購読者を適切なジャーニーに分類するためのエージェントテンプレートです。

予測 AI

• Einstein Engagement Frequency（EEF）
  メッセージ疲れを防ぐため、最適なエンゲージメント頻度を予測します。

• Einstein Engagement Scoring（EES）
  過去のデータをもとにコンタクト単位でスコアを算出し、エンゲージメントを予測します。

試験のポイント

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

• 生成 AI ＝ Agentforce

• 予測 AI ＝ Einstein

• Growth Edition と Advanced Edition の両方で利用できる機能 と、Advanced Edition でのみ利用できる機能 の違いを理解する

• Agentforce を利用するうえでは、データの品質（High Quality） と 可用性（Available） が重要

• 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 アイコンが表示されないか？」と問われたら、ユーザーに対して「エージェントへのアクセス権が不足しているため」という回答になりますので、覚えておいてください。

試験のポイント

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

• キャンペーンの作成は、ビジネスユニットの特定 → 目的の確認 → 双方向シナリオの確認 → ブリーフの作成 → プレビュー → 調整 → キャンペーンの作成 → フロー／コンテンツの作成 という流れで進む

• ブリーフをもとに、オーディエンスやコンテンツも生成できる

• 双方向シナリオでは、「エージェントに転送」要素 が追加される

• 標準機能だけでなく、企業の要件に合わせてカスタマイズできる

• キャンペーンからブリーフを削除しても、関連するセグメントやコンテンツは残せる

• ブリーフを削除すると、その後は Agentforce から適切なサポートを受けられない

• Campaign Creation Agent は、Employee Agent タイプ

• 利用するユーザーには、エージェントへのアクセス権限 が必要

• Agentforce アイコンが表示されない場合は、エージェントへのアクセス権限が不足している可能性がある

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 プロバイダーにプロンプト、顧客データ、回答を保持させない

• 暗号化と監査機能：転送中・保存時のデータを保護し、AI とのやり取りを記録する

• 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 日間のコンバージョン期間内で、注文完了やフォーム送信などの成果にどのように貢献したかを追跡します。

• Unified Engagement History Dashboards
  営業ユーザーなどが、メール開封やクリック、各種インタラクション履歴を CRM 画面上で可視化できるため、顧客理解の精度向上や、より適切なアクションの判断に役立ちます。

試験では、それぞれの名称だけでなく、何のパフォーマンスを確認するための機能なのか を区別しておきましょう。

② 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 の 最近のエンゲージメント活動を詳細に確認 します。

Engagement Score はエンゲージメントの度合い、Engagement 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、Conversion の役割を区別する

• Conversion は、メールや SMS が 30 日間のコンバージョン期間内で成果にどのように貢献したかを追跡する

• Email、SMS、Forms、Landing Page には、CRM 標準のダッシュボードとレポート が用意されている

• CRM 標準のダッシュボードでは、最大 5 つのフィルター を利用できる

• 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 と CRM 標準のダッシュボード／レポートは、基本的に 1 クリックでインストールできる

• Marketing Performance Intelligence は、最新機能を利用するため、再インストールが必要になる場合がある

• Marketing Performance Intelligence には、マーケティングアナリティクスタブ、キャンペーンレコード、フロー要素、コンテンツのプロパティ などからアクセスできる

• CRM 標準のダッシュボードやレポートには、主に ［分析］タブや［レポート］タブ からアクセスする

• Marketing Performance Intelligence の利用には、Tableau Next Included App Business User 権限セットが必要

• この権限セットによって、[マーケティングアナリティクス] タブへアクセスできる

• CRM 標準のダッシュボードやレポートでは、保存先フォルダーへのアクセス権が必要になる場合がある

Opportunity Influence（商談の影響）

Opportunity Influence（商談の影響） は、リードや取引先責任者によるメールや SMS のクリックエンゲージメントを利用して、成立した商談の収益にどのキャンペーンが影響したのかを分析する機能です。

例えば、1 人の取引先責任者が商談成立までに複数のキャンペーンをクリックした場合、「最初のキャンペーンを評価するのか」「最後のキャンペーンを評価するのか」を アトリビューションモデル によって決定できます。

※ Opportunity Influence は条件が多いため、試験で出題された場合は難問になる可能性があります。

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 日間に作成された商談 のデータを生成する

• 複数通貨を利用する組織には対応していない

• キャンペーン階層は影響度の計算に含まれない

消費カード

また、この消費カード（Consumption Cards）をどの大セクションの分類（分析なのかプラットフォームなのか）に入れるかは悩みますが、消費カードの役割についていても知る必要があります。

単純な AI や Data Cloud クレジットの消費量をほぼリアルタイムに、かつ正確知ることができますし、メールクレジットの残数に関してもこの消費カード上で見ることができます。1 送信 = 1 メールクレジットです。

いかがでしたでしょうか。

この 1 年間、私はほぼ毎日のように Marketing Cloud Next について検証し、記事を書き続けてきました。その認定資格がいよいよ現実のものとなり、自分の理解度を試せる機会が登場したことを、本当にうれしく思います。

今回は以上です。

次の記事はこちら

前回の記事はこちら

私の note のトップページはこちら