SFMC Frequency Capping 設計実装ガイド 2026：Einstein EEF設定・SQL横断制御・ツール比較

Salesforce Marketing CloudのFrequency Cappingで、顧客を疲れさせる「うざい配信」を根絶。基本設定からジャーニー実装、高度なSQL活用まで、顧客エンゲージメントを最大化する配信頻度設計の全貌を解説します。

更新：2026年6月17日
この記事をシェア：
目次 クリックで開く

Salesforce Marketing Cloud（SFMC）を運用する上で、最も回避すべきは、同一顧客への過剰なメッセージ送信による「ブランド毀損」と「購読解除」です。本ガイドでは、標準機能である頻度キャップ、AIを活用したEinstein Engagement Frequency、そして自由度の高いSQLを用いたカスタマイズ実装まで、実務担当者が直面する課題を解決するための具体的な手法を解説します。

SFMCにおける配信頻度管理の全体像

SFMCで配信頻度を制御する方法は、大きく分けて「AIによる自動最適化」と「ルールベースの強制制限」の2系統が存在します。それぞれの特性を理解し、ビジネス要件に合わせて組み合わせることが重要です。

標準機能とAI機能の比較

従来、配信頻度の管理は一律に「週に3通まで」といったルールベースで行われてきましたが、現在は顧客一人ひとりの反応（エンゲージメント）を学習し、個別に上限を変動させる手法が主流です。

SFMCにおける頻度管理手法の比較
手法 特徴 主な適用シーン
Einstein 配信頻度の最適化 AIが過去のエンゲージメントデータから個別の最適数を算出。 定期的なメルマガ、プロモーション、パーソナライズ配信。
Journey Builder 頻度制限 ジャーニー内で特定期間内の送信数をハードキャップ。 リマインドメールなど、しつこさを避けたい特定の導線。
SQL + Exclusion Script データエクステンション（DE）を参照し、複雑な条件で除外。 複数ジャーニー横断、またはLINEやPush通知を含むマルチチャネル制御。

【実装ガイド】Einstein 配信頻度の最適化（EEF）の設定手順

Einstein Engagement Frequency（EEF）は、SFMCのEinstein AI機能の一つであり、過去90日間のメール送信データとエンゲージメント（開封、クリック等）を分析し、各連絡先を「飽和（Over-saturated）」「最適（On Target）」「未達（Under-saturated）」の4つの層に分類します。

EEFの仕組みと分類ロジック

AIは単に送信数を見るのではなく、以下のエンゲージメントスコアに基づいて層を決定します。

  • 飽和（Over-saturated）: 送信数が多すぎて、エンゲージメント率が著しく低下している層。
  • 最適（On Target）: 現在の送信頻度で、最も効率よくエンゲージメントを獲得できている層。
  • 未達（Under-saturated）: まだ送信の余地があり、追加配信によってエンゲージメント向上が見込める層。

Journey Builderへの組み込みステップ

EEFを利用して、飽和状態の顧客を自動的に配信から除外する手順は以下の通りです。

  1. Einstein Frequency Split をジャーニーのキャンバス上にドラッグします。
  2. パスの分岐設定で「飽和（Over-saturated）」を選択します。
  3. 飽和層のパスの先を「待機」または「終了」に設定し、メッセージ送信アクティビティを回避させます。

【公式情報】

Einstein 配信頻度の最適化のヘルプ – Salesforce公式サイト

関連記事：高額MAツールは不要。BigQueryとリバースETLで構築する「行動トリガー型LINE配信」の完全アーキテクチャ

【高度な設計】SQLを用いた複数ジャーニーの横断制御

標準の頻度キャップ機能では「ジャーニーを跨いだ制限」が困難な場合があります。例えば、キャンペーンジャーニーAとリテンションジャーニーBの両方に合致した顧客が、同日に2通受け取ってしまう事態です。これを防ぐには、SQLを用いた共通配信ログの管理が必要です。

共有データエクステンション（DE）を用いた集計

まず、すべての配信アクティビティを記録する「送信履歴DE」を作成します。Automation Studioを使用して、毎日またはリアルタイムに近い頻度で以下のSQLを実行し、過去24時間以内に送信があった購読者を特定します。

SELECT SubscriberKey, COUNT(JobID) as SendCount
FROM _Sent
WHERE EventDate > DATEADD(day, -1, GETDATE())
GROUP BY SubscriberKey
HAVING COUNT(JobID) >= 1

Exclusion Script（除外スクリプト）によるリアルタイム判定

送信アクティビティの「除外スクリプト」欄にAMPscriptを記述することで、送信直前に上記の集計DEを参照し、既に本日配信済みの顧客をスキップさせることができます。

ROWCOUNT(LOOKUPROWS("Today_Sent_List", "SubscriberKey", _subscriberkey)) > 0

主要ツールの配信頻度制御機能スペック比較

SFMCと、他のエンゲージメントツールにおける頻度制限のスペックを比較します。SFMCはAIによる学習能力に強みがありますが、リアルタイム性の高い強制制限ではBraze等のツールが優位な面もあります。

配信頻度管理機能のツール比較
項目 Salesforce Marketing Cloud Braze Adobe Journey Optimizer
制限単位 日、週、月（設定による） 分、時間、日、週、月 日、週、月
AI最適化 Einsteinによる4層分類 Intelligent Timingのみ AIオーケストレーション
マルチチャネル 可能（SQL/共通DE推奨） 標準機能で統合管理 可能
導入事例 良品計画 メルカリ パナソニック

関連記事：【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

トラブルシューティング：頻度制限が正しく動作しない時のチェックリスト

実装後に想定通りの挙動をしない場合、以下の項目を実務的に確認してください。

  • データ保持ポリシー（Data Retention）の確認: 除外用のDEに保持期限が設定されており、データが消えていないか。
  • タイムゾーンの不一致: SFMCのシステム時刻（通常CST）と、SQLで指定したGETDATE()の時間のズレにより、24時間の計算が狂っていないか。
  • 連絡先キー（SubscriberKey）の重複: 同一人物が異なるキーで登録されている場合、頻度キャップは個別にカウントされてしまいます。
  • Einsteinの学習期間: EEFを有効化してから十分なデータ（数千件以上の送信実績）が蓄積されるまで、AIの分類は有効になりません。

関連記事：高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定と公式事例

SFMC × freee × kintone × Claude Code：Frequency Cappingデータの会計管理

  • 配信数→freeeマーケ費用の精算：SFMCのメール・SMSの月次配信数をClaude Codeが取得→freeeに「マーケティング費用（SFMC）」として自動仕訳。Einstein EEFによる配信抑制の効果（配信数削減→コスト削減）をfreeeデータで定量化。
  • Frequency Capping違反をkintoneで管理：SFMCのSQL横断制御で検出した「設定を超えた配信（バグ・設定ミス）」の履歴をkintoneのインシデント管理アプリに自動登録→Claude Codeが週次でkintoneの違反履歴を分析→改善提案レポートを生成。

SFMC×freee×kintone×Claude Codeの配信管理設計はAurantのDX推進支援にご相談ください。

まとめ：顧客体験を損なわないデータアーキテクチャの構築

「うざい配信」を卒業するためには、単一の機能を導入するだけでなく、全ジャーニー・全チャネルを横断して顧客が受けるメッセージ量を「可視化」し「制御」するデータアーキテクチャが不可欠です。Einsteinによる動的な最適化と、SQLによる静的な強制制限を組み合わせることで、エンゲージメントを最大化しつつ、購読解除リスクを最小限に抑えることが可能になります。

SFMCの高度な設計・運用にお困りですか？

数千万件規模のデータ処理から、SQLによる複雑な除外ロジックの実装まで、実務に即したアーキテクチャ構築を支援します。

無料相談・お問い合わせはこちら

実務担当者が知っておくべき「運用の落とし穴」と補足事項

Frequency Cappingを実務に投入する際、技術的な実装以上に「どのメッセージを制限対象外とするか」の定義が重要になります。ここでは、運用開始後に直面しやすい課題を補足します。

「トランザクションメール」は頻度制限から除外する

最も多い失敗が、パスワード再設定や購入完了メールといった「トランザクションメール（トリガー送信）」まで頻度制限に含めてしまうケースです。これらは顧客が自らアクションを起こして待っている情報であるため、飽和状態であっても必ず届ける必要があります。ジャーニー設計時、Einstein Frequency Splitの手前に「トランザクション属性」による条件分岐を入れる運用を徹底してください。

EEFが「アクティブ」にならない場合の確認事項

Einstein 配信頻度の最適化（EEF）は、スイッチをONにすればすぐに機能するわけではありません。以下の公式要件を満たしているか、ダッシュボードのステータスを確認してください。

  • 過去90日間のデータ量： 少なくとも10個以上のバリアント（送信パターン）が存在すること。
  • 購読者数： 十分な母数のエンゲージメントデータが必要（一般的に数千～数万件の送信実績が蓄積されるまで「学習中」となります）。
  • 公式リファレンス： Einstein 配信頻度の最適化ダッシュボードの確認方法

データ基盤の統合による「真の頻度管理」

SFMC内でのSQL制御は強力ですが、Webサイト上のポップアップやLINE専用ツール、アプリ内メッセージまで含めた「真のマルチチャネル制御」を行うには、名寄せされたデータ基盤が不可欠です。広告配信を含めた統合制御を目指す場合は、以下のアーキテクチャ解説も参考にしてください。

SFMC内制御 vs 外部データ基盤（BigQuery等）での制御

配信頻度を「どこで」計算・制御すべきかの判断基準をまとめました。

制御場所によるメリット・デメリット
制御場所 メリット デメリット
SFMC（Einstein/SQL） リアルタイムな開封・クリックを即座に反映できる。 広告や他ツール（自社アプリ等）の接触回数を把握しにくい。
外部基盤（BigQuery等） 広告・Web・店舗など全チャネルの接触回数で制限可能。 SFMCへのデータ同期（リバースETL等）に数時間のタイムラグが生じる。

理想的な運用は、「基本のキャップ（週N通まで）は外部基盤で算出してDEに流し込み、送信直前の微調整をSFMCのEinsteinで行う」というハイブリッド構成です。全体の設計思想については、広告×AIの真価を引き出すデータアーキテクチャの考え方も応用できます。

📚 関連資料

このトピックについて、より詳しく学びたい方は以下の無料資料をご参照ください：

システム導入・失敗回避チェックリスト PDF

DX推進・システム導入で陥りがちな落とし穴を徹底解説。選定から運用まで安全に進めるためのチェックリスト付き。

📥 資料をダウンロード →


よくある質問（FAQ）

Q. SFMC「Frequency Capping」とは何ですか？なぜ設定が必要ですか？

Frequency Capping（フリークエンシーキャッピング）とは「同一顧客に対して一定期間内に配信するメッセージ数の上限を設定する機能」です。設定が必要な理由は①配信過多による配信停止（Unsubscribe）・スパム報告率の上昇を防ぐ（メールのUnsubscribe率が0.2%を超えると配信評判（Sender Reputation）が低下する）、②顧客体験の保護（複数のキャンペーンが同時進行している場合、同一顧客が1日に5通のメールを受け取るケースが起きやすい）、③配信インフラのコスト最適化（不要な大量配信を防ぐことで送信コストを削減できる）の3点です。特にJourney Builderで複数のJourneyが並行している企業では必須設定です。

Q. SFMCのEinstein Engagement Frequency（EEF）はどう設定すればいいですか？

EEF（Einstein Engagement Frequency）の設定手順：①SFMCのEinstein Suite→Einstein Engagement Frequency設定画面で「最適配信頻度の計算対象ビジネスユニット」を選択、②学習期間（最低4週間のメール送信履歴が必要）を設定してEinsteinに最適頻度を学習させる、③EEFの推奨頻度をJourney BuilderのDecision Splitで使用（「今週の配信数が推奨頻度以下の顧客→メール送信・超過の顧客→別チャネルまたはスキップ」という分岐を設定）、④定期的（月次）にEEFのパフォーマンスレポートを確認してチューニングする。EEFを使わない場合は「1週間に最大2通・1日に最大1通」という固定ルールをSQL Filterで実装する方法もあります。

Q. SFMCで「横断的なFrequency制御」が難しい理由と解決策は？

横断制御が難しい理由は「Journey単位でFrequency設定が独立しており、複数JourneyにまたがるCapが標準機能で難しい」ことです。例えばウェルカムJourney・プロモーションJourney・カゴ落ちJourneyが同時進行している場合、各JourneyのCapは設定できても「この顧客が3つ合計でいくつ受信したか」の管理が標準機能では難しい。解決策：①Suppress Data Extension（抑制リスト）：週2通以上受信した顧客をリスト化し全Journeyの配信前にこのリストと照合するSQL処理を実装する、②Contact BuilderのFirehoseで全送信履歴を集計してCapチェックに使う、③Marketing Cloud Personalization（旧Interaction Studio）を活用したリアルタイム制御（ライセンス追加が必要）の3つが解決策です。

業務システム・DX全般のご相談

業務の課題整理からツール選定、システム導入・連携・運用までを幅広く支援します。何から手をつけるべきか迷う段階でも、貴社の状況に合わせて最適な進め方をご提案します。

ソリューション一覧を見る →