Salesforce Marketing Cloud Engagement を運用するうえで、メール、画像、テンプレート、バナー、共通フッターなどのコンテンツ管理は欠かせません。配信数が増えたり、複数の部署・ブランド・Business Unit で運用したりするようになると、「どこに何の素材があるのか分からない」「同じフッターを何度も作っている」「古いバナーを使い回してしまった」といった課題が起こりやすくなります。

そこで重要になるのが Content Builder です。

Content Builder は、単なるメール作成画面ではありません。Salesforce 公式ドキュメントでは、画像、ドキュメント、コンテンツを単一の場所に集約して管理する、Marketing Cloud Engagement 向けのクロスチャネルなコンテンツ管理機能として説明されています。

この記事では、Marketing Cloud の Content Builder とは何か、何ができるのか、Email Studio や CloudPages との違い、導入時に確認すべきポイントまで、実務目線でわかりやすく解説します。

---

Content Builder とは

Content Builder とは、Salesforce Marketing Cloud Engagement における コンテンツ資産の管理・作成・再利用を行うための機能 です。

メール本文を作るだけでなく、メールテンプレート、画像、テキスト、ボタン、コードスニペット、動的コンテンツ、SMS、プッシュ通知、アプリ内メッセージなど、複数チャネルで使うコンテンツを一元的に扱えます。Trailhead でも、Content Builder で作成できる対象として、メールメッセージ、メールテンプレート、コンテンツブロック、SMS、モバイルアプリのプッシュ通知などが紹介されています。

つまり Content Builder は、「メールを作る場所」というよりも、Marketing Cloud 全体で利用する コンテンツハブ と捉えるほうが実態に近い機能です。

たとえば、次のようなコンテンツをまとめて管理できます。

• メールテンプレート
• ヘッダー、フッター、会社情報などの共通パーツ
• 画像、バナー、ロゴ
• CTAボタン
• 商品紹介文
• 免責文、注意事項
• HTMLやAMPscriptを含むコードスニペット
• 動的コンテンツ
• SMS、プッシュ通知、アプリ内メッセージ用のコンテンツ

これらを部品として整備しておくことで、メールやメッセージを毎回ゼロから作る必要がなくなり、制作効率と品質を両立しやすくなります。

---

Content Builder でできること

1. メールを作成できる

Content Builder では、メールをゼロから作成したり、既存テンプレートを使って作成したりできます。

Trailhead では、メール作成時の選択肢として、既存テンプレートから作成する方法、AMPメールテンプレートを使う方法、HTMLを貼り付ける方法、AMP対応のHTMLメールを作る方法、テキストのみのメール、既存メールの複製などが紹介されています。

そのため、マーケティング担当者がドラッグ＆ドロップで作る運用にも、制作会社や開発者がHTMLを直接扱う運用にも対応しやすいのが特徴です。

---

2. コンテンツブロックを再利用できる

Content Builder の大きな強みは、コンテンツブロック を作成・管理できる点です。

コンテンツブロックとは、メールやメッセージを構成する部品のことです。Trailhead では、画像、テキスト、ボタンなどを含むさまざまなブロックを Content Builder で作成できると説明されています。

たとえば、次のようなブロックを作っておくと便利です。

• ブランド共通ヘッダー
• 共通フッター
• 会社情報
• SNSリンク
• 問い合わせ導線
• キャンペーンバナー
• 商品説明
• 法務確認済みの免責文
• 会員ランク別の案内文
• CTAボタン

一度作ったブロックは複数のメールで使い回せるため、制作スピードが上がるだけでなく、ブランド表現の統一や更新漏れの防止にもつながります。

たとえば、フッターの会社情報が変わった場合、各メールを個別に修正するのではなく、共通ブロックの管理方針を整えておくことで、運用負荷を抑えやすくなります。

---

3. 動的コンテンツでパーソナライズできる

Content Builder では、受信者の属性や条件に応じて表示内容を出し分ける Dynamic Content も利用できます。

Trailhead では、Dynamic Content を使って、受信者の氏名や会員ステータスなどの属性に応じたパーソナライズコンテンツを作成できると説明されています。

たとえば、次のような出し分けが可能です。

• 会員ランク別にオファーを変える
• 居住地域別に店舗情報を変える
• 購入履歴に応じておすすめ商品を変える
• BtoB向けに業種別の訴求文を変える
• 休眠顧客と既存顧客でCTAを変える

全員に同じメールを送るのではなく、顧客データに応じて内容を最適化したい場合、Content Builder の動的コンテンツは非常に有効です。

---

4. SMS、プッシュ通知、アプリ内メッセージも作成できる

Content Builder はメール専用の機能ではありません。

Trailhead では、Content Builder はメールだけでなく、SMSメッセージやプッシュ通知の作成にも利用できると説明されています。また、アプリ内メッセージではレイアウト選択、画像、タイトル、メッセージ、ボタンなどの設定ができることも紹介されています。

そのため、メールマーケティングから始めた企業でも、将来的にSMS、アプリ通知、モバイル向け施策へ展開しやすくなります。

特に、Journey Builder などと組み合わせて顧客接点を設計する場合、チャネルごとにコンテンツ管理が分断されていると運用が複雑になります。Content Builder を中心にコンテンツ資産を整理しておくことで、クロスチャネル施策の土台を作りやすくなります。

---

5. Interactive Email Form を活用できる

Content Builder では、メール内にフォームを埋め込む Interactive Email Form も利用できます。

Salesforce ヘルプでは、Content Builder により、プロフィール情報、商品レビュー、見込み顧客情報などを、メール内に埋め込まれたフォームから直接受け取れると説明されています。

通常のメール施策では、ユーザーがメール内のリンクをクリックし、ランディングページへ移動してからフォームに入力します。一方、Interactive Email Form を使うと、メール内で入力体験を完結させやすくなります。

たとえば、次のような用途に向いています。

• 簡易アンケート
• 商品レビュー投稿
• セミナー参加意向の確認
• プロフィール情報の更新
• リード情報の取得
• 顧客満足度調査

メールからLPへ遷移させるだけでなく、メール自体をインタラクティブな接点にしたい場合に有効です。

---

Email Studio や CloudPages との違い

Content Builder を理解するうえで、混同しやすいのが Email Studio と CloudPages です。

Content Builder と Email Studio の違い

Email Studio は、Marketing Cloud Engagement におけるメール作成・送信・管理のための機能です。Salesforce ヘルプでは、Email Studio について、基本的なニュースレターから複雑なキャンペーンまで、パーソナライズされたメールを作成・送信する機能として説明されています。

一方、Content Builder は、メールやメッセージで使うコンテンツ資産を作成・管理する場所です。

整理すると、次のように考えると分かりやすいです。

機能	主な役割
Content Builder	コンテンツを作る・管理する・再利用する
Email Studio	メールを送る・テストする・配信運用する

つまり、Content Builder は「素材や本文を整える場所」、Email Studio は「メール施策として配信する場所」と捉えると理解しやすくなります。

---

Content Builder と CloudPages の違い

CloudPages は、ランディングページ、フォーム、マイクロサイトなど、Web上の公開ページ体験を作成するための機能です。

Salesforce ヘルプでは、CloudPages は見込み客データの取得・整理・活用を支援する機能として説明されています。また、CloudPages のマイクロサイトは、複数のランディングページを意味のあるサイトマップとして整理できるものとされています。

Content Builder がメールやメッセージ内で使うコンテンツ資産の管理に強いのに対し、CloudPages はキャンペーンLP、フォームページ、マイクロサイトなどの公開ページに強い機能です。

機能	向いている用途
Content Builder	メール、テンプレート、画像、共通ブロック、メッセージ素材の管理
CloudPages	LP、フォーム、キャンペーンページ、マイクロサイトの作成
Email Studio	メール配信、テスト、送信管理

実務では、Content Builder で作った画像やコンテンツをメールに使い、必要に応じて CloudPages のLPへ誘導する、という組み合わせで使われることが多くあります。

---

Content Builder の主な活用場面

1. メールテンプレートを標準化したい場合

複数の担当者がメールを作成していると、デザイン、余白、CTA、フッター、表記ルールがばらつきやすくなります。

Content Builder でテンプレートや共通ブロックを整備しておけば、担当者ごとの差を抑えながら、一定品質のメールを作りやすくなります。

特に、以下のような企業では効果が出やすいです。

• メルマガ配信本数が多い
• 複数ブランドを運用している
• 複数部署で Marketing Cloud を使っている
• 制作会社と共同でメールを作っている
• 法務確認済みの文言を使い回したい

---

2. ブランド統制を強化したい場合

ヘッダー、ロゴ、カラー、ボタン、免責文などの共通パーツを Content Builder に集約しておくことで、ブランド表現の統一がしやすくなります。

特に、グローバル企業や複数事業部を持つ企業では、Business Unit ごとに自由にメールを作ると、ブランドルールが崩れやすくなります。

Content Builder を使えば、全社共通で使うべきパーツと、各部署で自由に編集してよいパーツを分けて管理しやすくなります。

---

3. パーソナライズ施策を強化したい場合

顧客データに応じてメール内容を変えたい場合、Content Builder の Dynamic Content が役立ちます。

たとえば、同じキャンペーンメールでも、既存顧客にはアップセル訴求、新規顧客には初回購入特典、休眠顧客には再来訪クーポンを表示する、といった使い分けが可能です。

顧客ごとに関連性の高い情報を届けることで、クリック率やコンバージョン率の改善につながる可能性があります。

---

4. 複数 Business Unit でコンテンツを共有したい場合

複数の Business Unit をまたいで運用する場合は、Content Builder の共有設計が重要です。

Salesforce Developers のドキュメントでは、Content Builder Sharing が有効な Business Unit にアセットを共有できること、共有タイプとして view、edit、local が定義されていることが説明されています。view は閲覧・送信利用のみ、edit は共有先でも編集可能、local はメールに限って共有先 Business Unit 内のローカル編集コピーを作成できる方式です。

この設計を誤ると、全社共通で守るべきテンプレートが勝手に編集されたり、逆に各地域・各ブランドで必要なローカライズができなかったりします。

導入時には、どのコンテンツを全社共通資産にするのか、どの範囲まで編集を許可するのかを事前に決めておくことが重要です。

---

5. API や外部システムと連携したい場合

Content Builder は標準UIだけでなく、API連携によって拡張することもできます。

Salesforce Developers では、Content Builder REST API を使ってマーケティングコンテンツを作成・操作できること、API上ではメール、画像、テキスト、ドキュメントなどのコンテンツを asset として扱うことが説明されています。また、アセットは階層構造を持つことができ、作成、更新、削除、検索、公開に Asset Model を利用できます。

たとえば、次のような用途が考えられます。

• 外部CMSから画像や記事コンテンツを取り込む
• 商品データベースからメール用コンテンツを自動生成する
• 大量の画像アセットを一括登録する
• テンプレートメールをAPI経由で生成する
• 複数環境間でアセット管理を効率化する

Marketing Cloud を大規模運用する場合、Content Builder をUIだけで使うのではなく、API連携も含めて設計しておくと拡張性が高まります。

---

Content Builder とあわせて知っておきたい関連機能

Customer Key

Content Builder の運用設計では、Customer Key も重要です。

Salesforce Developers のドキュメントでは、Customer Key はアセットに対するユーザー定義の識別子であり、エンタープライズ内で一意の値になると説明されています。また、customerKey 属性には36文字の制限があります。

Customer Key の命名ルールを決めずに運用を始めると、後から API 参照、移行、テンプレート管理、外部連携を行う際に混乱しやすくなります。

たとえば、次のような命名ルールを検討できます。

brand_channel_type_purpose_version

例：

abc_email_footer_common_v1
abc_email_cta_signup_v1
abc_campaign_summer_banner_v2

最初から完璧に作り込む必要はありませんが、少なくとも「誰が見ても用途が分かる」ルールを決めておくことが大切です。

---

Content Builder REST API

開発連携を想定する場合、Content Builder REST API は重要な拡張ポイントです。

APIを利用すれば、手作業では負荷が高いアセット登録、更新、検索、外部システム連携を自動化しやすくなります。Salesforce Developers では、Content Builder REST API により、マーケティングコンテンツを作成・操作できることが説明されています。

ただし、API連携には Installed Package や API Integration の設定が必要になります。Salesforce Developers では、REST API や SOAP API にアクセスする第三者アプリケーションとの連携には、API Integration コンポーネントを持つ Installed Package を作成して Client ID と Secret を取得する流れが説明されています。

---

Content Builder Block SDK

標準のコンテンツブロックだけでは要件を満たせない場合は、Content Builder Block SDK を使ってカスタムブロックを開発できます。

Salesforce Developers では、Content Builder には block widget と呼ばれるネイティブエディタがあり、独自の編集体験を提供したい場合は Content Builder Block SDK でカスタム block widget を開発できると説明されています。

たとえば、次のようなケースに向いています。

• 独自の商品選択UIを作りたい
• ブランドルールに沿った編集画面を提供したい
• 地図、動画、タイマー、アンケートなどの特殊ブロックを使いたい
• 外部システムから認証付きコンテンツを取得したい
• マーケティング担当者がコードを書かずに複雑なHTMLを生成できるようにしたい

カスタムブロックを使う場合は、Installed Package に Custom Content Block コンポーネントを追加する必要があります。Salesforce Developers の Installed Packages ドキュメントでも、Content Builder の標準WYSIWYGではなく別の編集体験を使いたい場合、Custom Content Block コンポーネントを持つ Installed Package を作成する例が示されています。

---

Salesforce CMS 連携

Webサイトや他システムで管理しているコンテンツを Marketing Cloud 側でも活用したい場合は、Salesforce CMS 連携も検討できます。

Salesforce CMS Developer Guide では、Marketing Cloud の Content Builder が CMS コンテンツを CloudPages や各種メッセージで利用できること、パブリックチャネル、接続アプリ、CMS Sync AppExchange パッケージなどを通じて CMS コンテンツを Marketing Cloud に取り込めることが説明されています。

たとえば、Webサイト側の商品画像、記事、キャンペーン素材を CMS で管理し、その一部をメールやCloudPagesでも利用したい場合に有効です。

コンテンツ管理がWebチームとメールチームで分断されている企業では、CMS連携によって重複作業を減らしやすくなります。

---

Einstein 生成AI・Einstein Content Selection

AI活用の観点でも、Content Builder は注目すべき領域です。

Salesforce ヘルプでは、Einstein 生成AIを使って Content Builder 内で件名や本文コピーを作成できること、また利用には有効化が必要であることが説明されています。

さらに、Einstein Content Selection は、開封時に購読者ごとにパーソナライズされたコンテンツを選択するノーコードの機能として説明されています。Salesforce ヘルプでは、購読者のエンゲージメントをもとに、メッセージ開封時に画像アセットを選択できることが紹介されています。

つまり Content Builder は、コンテンツを作る場所であると同時に、AIを活用して制作効率やパーソナライズ精度を高める起点にもなります。

---

導入前に確認したいポイント

Content Builder は便利な機能ですが、何も決めずに使い始めると、後から整理が大変になります。導入・再設計の前には、次のポイントを確認しておきましょう。

1. フォルダ構成を決める

画像、テンプレート、共通ブロック、キャンペーン別素材などをどの単位で整理するかを決めておきます。

おすすめは、少なくとも以下のような分類を用意することです。

• 共通テンプレート
• 共通ブロック
• ブランド別素材
• キャンペーン別素材
• 商品・サービス別素材
• テスト用
• アーカイブ

最初にフォルダルールを決めておくことで、担当者が増えても運用が乱れにくくなります。

---

2. 命名ルールを決める

メール名、テンプレート名、画像名、Customer Key の命名ルールを決めておくことも重要です。

たとえば、次のような要素を含めると管理しやすくなります。

• ブランド名
• チャネル
• コンテンツ種別
• 用途
• 配信時期
• バージョン

例：

brandA_email_template_newsletter_v1
brandA_block_footer_common_v2
brandA_banner_2026summer_campaign_v1

命名ルールがないと、同じような名前のコンテンツが増え、どれが最新版か分からなくなります。

---

3. 共有範囲と編集権限を決める

複数 Business Unit で利用する場合は、どのコンテンツを共有し、どこまで編集を許可するかを決める必要があります。

Salesforce Developers のドキュメントでは、共有タイプとして view、edit、local が定義されています。

実務では、次のように分けると整理しやすくなります。

コンテンツ種別	推奨方針
全社共通ロゴ	編集不可で共有
ブランド共通フッター	原則編集不可
キャンペーンテンプレート	必要に応じてローカル編集
地域別コンテンツ	各BUで編集可能
法務文言	中央管理

「全社統制したいもの」と「現場で調整したいもの」を分けることが、Content Builder 運用の成功ポイントです。

---

4. 利用したい機能の有効化状況を確認する

Dynamic Content、A/B Test ブロック、Einstein 関連機能などは、契約、権限、設定状況によって利用可否が変わる場合があります。

Trailhead でも、Dynamic Content や A/B Content block を有効化するには、Marketing Cloud Engagement 管理者またはサポートへの確認が案内されています。

「記事やデモで見たから使えるはず」と進めるのではなく、自社アカウントで利用できる機能を事前に確認しておくことが大切です。

---

5. API・CMS連携の予定を早めに整理する

将来的に外部システムやCMSと連携する可能性がある場合は、初期設計の段階から考慮しておくべきです。

特に、次のような予定がある場合は、早めに要件を整理しましょう。

• 商品マスタと連携したい
• Web CMS の画像をメールでも使いたい
• APIでテンプレートを自動生成したい
• 複数環境間でアセットを移行したい
• カスタムブロックを開発したい

後から連携しようとすると、命名ルール、フォルダ構成、Customer Key、権限設計を見直す必要が出ることがあります。

---

Content Builder を活用するメリット

Content Builder を適切に設計・運用すると、次のようなメリットが期待できます。

制作スピードが上がる

共通パーツやテンプレートを再利用できるため、毎回ゼロからメールを作る必要がありません。

ブランド表現を統一しやすい

ロゴ、カラー、フッター、CTA、免責文などを標準化しやすくなります。

更新漏れを防ぎやすい

共通ブロックや管理ルールを整えることで、古い情報の使い回しを減らせます。

パーソナライズ施策を進めやすい

Dynamic Content や Einstein Content Selection などを活用することで、顧客属性や行動に応じた出し分けがしやすくなります。

クロスチャネル施策に展開しやすい

メールだけでなく、SMS、プッシュ通知、アプリ内メッセージなどにも活用できるため、顧客接点を広げやすくなります。

API・CMS連携に発展しやすい

REST API、Block SDK、Salesforce CMS 連携を活用することで、より高度な運用自動化や外部システム連携が可能になります。

---

まとめ

Content Builder は、Salesforce Marketing Cloud Engagement における クロスチャネルのコンテンツ管理基盤 です。

メールを作るだけでなく、テンプレート、画像、共通ブロック、動的コンテンツ、SMS、プッシュ通知、アプリ内メッセージ、Interactive Email Form など、幅広いコンテンツ資産を管理できます。さらに、共有コンテンツ、Customer Key、REST API、Block SDK、Salesforce CMS、Einstein 生成AI、Einstein Content Selection まで視野に入れると、単なる制作ツールではなく、マーケティング運用全体を支えるプラットフォームとして活用できます。

特に、次のような課題がある企業では、Content Builder の設計見直しが効果的です。

• メールテンプレートが乱立している
• 共通フッターやバナーの更新漏れが多い
• 複数 Business Unit でブランド統制したい
• 顧客属性別にコンテンツを出し分けたい
• API や CMS 連携を見据えて設計したい
• Marketing Cloud の運用を属人化させたくない

Content Builder をうまく活用するには、機能を覚えるだけでなく、フォルダ構成、命名ルール、権限、共有方針、Customer Key、外部連携方針まで含めて設計することが重要です。

---

FAQ

Content Builder とは何ですか？

Content Builder は、Salesforce Marketing Cloud Engagement で利用するメール、画像、テンプレート、コンテンツブロックなどを作成・管理・再利用するためのコンテンツ管理機能です。Salesforce 公式ドキュメントでは、画像、ドキュメント、コンテンツを単一の場所に集約するクロスチャネルのコンテンツ管理ツールとして説明されています。

Content Builder はメール専用ですか？

メール専用ではありません。Trailhead では、Content Builder で作成できる対象として、メールメッセージ、メールテンプレート、コンテンツブロック、SMS、プッシュ通知などが紹介されています。

Content Builder と Email Studio の違いは何ですか？

Content Builder はコンテンツを作成・管理する場所、Email Studio はメールを作成・送信・運用する機能です。実務上は、Content Builder で作ったテンプレートやブロックを使い、Email Studio で配信管理する、と整理すると分かりやすいです。

Content Builder と CloudPages の違いは何ですか？

Content Builder はメールやメッセージで使うコンテンツ資産の管理に向いています。一方、CloudPages はランディングページ、フォーム、マイクロサイトなどのWebページ体験を作る機能です。

Dynamic Content は使えますか？

Content Builder では Dynamic Content を使って、受信者属性に応じたコンテンツの出し分けができます。ただし、Dynamic Content や A/B Content block の利用には、管理者やサポートへの確認が必要な場合があります。

Content Builder は API 連携できますか？

はい。Content Builder REST API を利用することで、アセットの作成、更新、削除、検索、公開などを行えます。Salesforce Developers では、API上でコンテンツを asset として扱い、Asset Model を使って操作できると説明されています。

複数 Business Unit でコンテンツ共有できますか？

Content Builder Sharing が有効な Business Unit では、アセットを共有できます。共有タイプには view、edit、local があり、閲覧のみ、編集可能、ローカルコピー編集などの運用を設計できます。