見出し画像

【第576回】 Marketing Cloud Next : CMS コンテンツを REST API で検索

Marketing Cloud Next Growth & Advanced Editions の Winter '27 の新機能リリース では、REST API を使用して、CMS ワークスペースに保存されているコンテンツを REST API を使って管理できるようになりました

この Connect REST API では、コンテンツに対して主に以下の操作を実行できます。

  • 作成

  • 更新

  • 検索

そして、対応しているチャネルコンテンツは以下があります。

  • メール

  • SMS

  • WhatsApp

  • モバイルアプリ

さらに、チャネル別のメッセージだけでなく、以下のようなコンテンツも API から操作できます。

  • 動画コンテンツ

  • コンテンツブロック

  • トラッキングリンク

  • フォーム

これにより、外部システムや独自のアプリケーションから Marketing Cloud Next のコンテンツを取得・作成・更新し、コンテンツ管理の一部を自動化できるようになります。

この機能がリリースされると知った時、まず始めに試してみたかったのが、本文内のテキストを検索する機能の作成でした。

そこで今回は、この REST API を利用した Lightning Web Component(LWC)を作成してみたいと思います。

今回のツールは安全性を優先し、GET リクエストのみを使用する参照専用(Read Only) の構成としています。

作成した LWC を Marketing Cloud Next のタブとして追加することで、例えば以下のような操作を Salesforce 上から行えるようにします。

  • メール本文に含まれる特定の文言を検索

    • Winter '27 Campaign

    • Preference Center

  • 特定の URL を含むコンテンツを検索

    • 旧ランディングページ URL

    • テスト用 URL

    • 特定ドメインの URL

  • AMPscript や Handlebars の記述を検索

    • ContentBlockBykey

    • getContentBlock

    • 特定の Content Key

  • Reusable Content Block 内の文字列まで含めて検索

    • メール本体に直接保存されていない Content Block 内の文字列も対象

検索時には、対象を以下の条件で絞り込むこともできます。

  • Marketing Workspace

  • Content Type

    • Email

    • Email Template

    • Email Content Block

    • SMS

    • WhatsApp

    • In-App Message

    • Tracked Link

    • Form

    • Image

    • Video

    • Document

    • Landing Page など

  • Status

    • All

    • Published

    • Revised

    • Draft

例えば、

  • 公開されている Email だけを対象に、古い URL が残っていないか検索

  • 下書きのメールだけを対象に、example.com が残っていないか確認

  • コンテンツブロックに絞って、特定の文言が含まれているものを探す

といった検索ができます。

また、検索結果から対象コンテンツを「View」ボタンで開くと、

  • Content Body JSON

  • Raw HTML

  • 簡易 QA(品質)チェック

  • リンク一覧

なども確認できるようにします。

検索結果には、

  • Content Type

  • Status

  • Last Modified Date

  • Content Key

なども表示されるため、どのコンテンツが該当したのかを確認しやすくしています。

さらに、検索時に使用した

  • API Request 数も表示

して、REST API の消費量を確認しながら利用できます。


API Request について

今回の検索では、対象となるコンテンツの詳細を REST API で取得して本文まで確認するため、検索するコンテンツ数に応じて Salesforce の API Request を消費します。

そのため、検索結果には以下のように、その検索で使用した API Request 数を表示します。

Matches: 2
Content Scanned: 52
API Requests Used: 58

API Requests Used は、その検索処理の中で実際に発生した CMS API の呼び出し回数です。

例えば、検索対象のコンテンツが多い場合や、メール内で Reusable Content Block を参照している場合は、追加でコンテンツ詳細を取得するため、API Request 数も増えます。

なお、これは Message Credit や Data 360 Credit のようなクレジット消費ではなく、Salesforce 組織の API Request 利用量として扱われます。

大量のコンテンツを頻繁に検索する場合は、組織全体の API 利用量も考慮してください。

Salesforce の Enterprise Edition では、通常の Salesforce ユーザーライセンスの場合、1ライセンスあたり 24 時間で 1,000 API Request が基本割り当てです。さらに組織にはベースとして 100,000 API Request があり、Enterprise Edition の1日あたりの上限は概ね次の計算になります。

100,000
+
Salesforce ライセンス数 × 1,000
+
購入済みの API Call Add-On

例えば Salesforce ライセンスが 50 ユーザーある Enterprise Edition の組織なら、

100,000 + (50 × 1,000)
= 150,000 API Requests / 24 時間

が目安になります。

Salesforce 組織全体の API Request 利用量は、[設定]→[組織情報]の[API 要求数(この 24 時間以内)]から確認できます。ここでは、直近 24 時間の利用量と組織の API 上限を確認できます。


設定手順

Agentforce Vibes で実装しますので、まずはお試しがてら Sandbox や SDO での実装をお勧めします。本番環境や Trailhead Playground には Agentforce Vibes がないので同じような実装はできません。

0. 事前準備

1. まず、以下の ZIP ファイルをローカルにダウンロードします。

2. Agentforce Vibes を開きます。

3. Agentforce Vibes が開いたら、以下の赤枠の箇所に ZIP ファイルをドラッグアンドドロップします。

4. 以下に ZIP が格納されました。

5. 次にメニューからターミナルを開きます。

6. こちらに以下の 2 行のコマンドをそのまま一度にコピペして、Enter をクリックします。

unzip MCN_Content_Utility_ReadOnly_v4_9.zip
bash mcn-content-utility/install.sh

7. これで以下の作業をしています。

  • ZIP の解凍

  • MCN Content Utility の Metadata をデプロイ

  • MCNContentUtilityControllerTest の Apex テスト実行

  • 現在のユーザーへ MCN_Content_Utility 権限セットを付与

これで処理を待ち、最後まで成功になれば OK です。


1. External Client App Manager を開く

続いて、Setup の Quick Find で、External Client App Manager を検索して開き、New External Client App をクリックします。


2. Basic Information

次の値を入力します。

  • External Client App Name
    MCN Content Utility

  • API Name
    MCN_Content_Utility

  • Contact Email
    あなたのメールアドレス(特にメールが送信されるとかはありません)

  • Distribution State
    Local


3. API (Enable OAuth Settings)

続いて、Enable OAuth を ON にします。

Callback URL は、ひとまず次で作成します。

https://login.salesforce.com/services/oauth2/callback

これは Salesforce が External Client App の一般的な OAuth 検証例でも使用している URL です。こちらは後で変更することになります

また、Available OAuth Scopes から、この 2 つを追加してください。

  • Manage user data via APIs (api)

  • Perform requests at any time (refresh_token, offline_access)

今回の用途は以下です。

  • api → Connect REST API を呼ぶため

  • refresh_token / offline_access → 毎回再ログインせず Named Credential から継続利用するため


4. Security

最後のセキュリティーで以下の 2 つを新たに有効化してから、保存してください。

  • Require secret for Web Server Flow

  • Require secret for Refresh Token Flow


5. Consumer Key と Consumer Secret を確認

保存できたら Settings タブから Consumer Key and Secret をクリックします。※ 管理者によるログインが必要です。

ここで取得できる

  • Consumer Key

  • Consumer Secret

は、次に作成する External Auth Identity Provider で使用するので、画面をそのまま開きっぱなしにしておいてください。


6. External Auth Identity Provider を作成

Setup の Quick Find で Named Credentials を検索し、External Auth Identity Providers タブから New をクリックします。

以下のように設定します。

  • Label
    MCN Content Utility Salesforce OAuth

  • Name
    MCN_Content_Utility_Salesforce_OAuth

  • Authentication Protocol
    OAuth 2.0

  • Authentication Flow Type
    Authorization Code (Browser Flow)

  • Client ID
    先ほど上で確認した Consumer Key

  • Client Secret
    先ほど上で確認した Consumer Secret

  • Pass client credentials in request body
    オフ

  • Use Proof Key for Code Exchange (PKCE) Extension
    オン

Identity Provider URL には、その Salesforce 組織自身の My Domain URL を使用します。

例えば、

https://<Your-My-Domain>.my.salesforce.com

であれば、

  • Authorize Endpoint URL
    https://<Your-My-Domain>.my.salesforce.com/services/oauth2/authorize

  • Token Endpoint URL
    https://<Your-My-Domain>.my.salesforce.com/services/oauth2/token

  • User Info Endpoint URL
    https://<Your-My-Domain>.my.salesforce.com/services/oauth2/userinfo

とします。

設定したら保存します。


7. Callback URL を External Client App に設定

External Auth Identity Provider を保存すると、Salesforce が Callback URL を生成します。

この URL をコピーします。

続いて、

External Client App Manager → MCN Content Utility → Settings タブ

と進み、先ほど一時的に設定した、

https://login.salesforce.com/services/oauth2/callback

を、今取得した Callback URL に置き換えて保存します。必ず保存ボタンをクリックしてください。手順 12 の Oauth 認証ができなくなります。


8. External Credential を作成

次に、Setup の Named Credentials を開き、External Credentials タブから New をクリックします。

以下のように設定します。

  • Label
    MCN Content Utility OAuth

  • Name
    MCN_Content_Utility_OAuth

  • Authentication Protocol
    OAuth 2.0

  • Authentication Flow Type
    Browser Flow

  • Scope
    api refresh_token

  • Identity Provider
    External Auth Identity Provider

  • External Auth Identity Provider
    MCN Content Utility Salesforce OAuth

設定したら保存します。


9. Named Principal を作成

保存後、下にスクロールすると Principals セクションがあるので New をクリックします。

今回は検証を簡単にするため、1 つの認証を共有する Named Principal を使用します。

  • Parameter Name
    MCNContentUtility

  • Sequence Number
    1

  • Identity Type
    Named Principal

保存します。


10. 権限セットから Principal へのアクセスを許可

実は、最初の ZIP のインストール時に、

MCN_Content_Utility

という権限セットを現在のユーザーへ付与しています。

この権限セットに、今作成した External Credential Principal へのアクセス権も追加します。

Setup から、

Permission Sets → MCN Content Utility → External Credential Principal Access

を開き、Edit をクリックします。

Available External Credential Principals に表示される、

MCN_Content_Utility_OAuth - MCNContentUtility

をチェックして保存します。


11. Named Credential を作成

再び Setup → Named Credentials を開き、Named Credentials タブから New をクリックします。

以下のように設定します。

  • Label
    MCN Content API

  • Name
    MCN_Content_API

  • URL
    My Domain URL(例:https://na1772662003452.my.salesforce.com/)

  • External Credential
    MCN Content Utility OAuth

  • Generate Authorization Header
    オン

ここで Name は必ず MCN_Content_API としてください。

なぜなら、今回配布している Apex で、「callout:MCN_Content_API」という名前で Named Credential を参照しているためです。


12. OAuth 認証

続いて、

Named Credentials → External Credentials → MCN Content Utility OAuth

を開きます。

Principals セクションで、

MCNContentUtility

のアクションメニューから Authenticate をクリックします。

Salesforce のログイン画面が表示されたら、今回 API にアクセスさせる Salesforce ユーザーでログインし、アクセスを許可します。

※ この OAuth 認証は管理者が一度実行することになります。

正常に完了すれば、External Credential に OAuth Token が保存されます。


13. Lightning Component Tab を作成

ここまでで API を呼び出す準備ができました。

次に、今回デプロイした LWC を Marketing Cloud Next から開けるようにします。

Setup で Tabs を検索して開いたら、Lightning Component Tabs まで下にスクロールします。New をクリックして、以下を設定します。

  • Lightning Component
    c:mcnContentUtility

  • Tab Label
    Content Utility

  • Tab Style
    任意

設定したら、保存します。

今回の LWC には lightning__Tab target を設定しているため、Lightning Component Tab として使用できます。


14. Marketing アプリに Content Utility を追加

Marketing Cloud Next の Marketing アプリへ戻ります。

画面上部のナビゲーション右側にある 鉛筆アイコンをクリックします。

Add More Items をクリックし、

Content Utility

を検索して追加します。


15. Connection Test

最後に Content Utility タブを開いて確認します。

まず、Workspace を選択します。SDO の場合は Content Workspace for Marketing Cloud です。

次に Content Type は、デフォルトを Email にしています。All でも良かったのですが、大量にコンテンツがある環境の場合、不要なものを検索してしまう可能性があるためです。この設定は必ず目的に合わせて設定することをオススメします。

ステータスに関しては、不要な下書き(Draft)を結果に表示させたくない場合もあるかと思いますので、現在、公開済み(Published)のもので絞れるようにしてあります。

また、改訂済み(Revised)になっているものを一覧でチェックできるようにしています。その場合は検索テキストを空にして実行してください。

今回、一回の検索は「デフォルトで 100 件まで」にしてあります。例えば、1 万件の CMS コンテンツがあった場合、1 万件をすべて調べに行くと API Request を激しく消費するためです。コンテンツ量が多い組織のために、最大で 1000 件を同時に検索できるようにもしてあります。

最後に検索テキストに、本文中のキーワード(テキストや URL)を入力すると、CMS のコンテンツを検索できます。

検索結果から、各コンテンツへ遷移することもできますし、View をクリックすると、自動的に下側にスクロールして、Content Body や品質、リンクなどを確認することができます。


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

今回の仕組みでは、検索対象となるコンテンツの中身を 1 件ずつ取得して確認するため、どうしても API Request を一定数消費します

そのため、コンテンツ数が非常に多い環境では、検索対象をできるだけ絞り込んで利用することが重要です。

特に Content Type は必ず絞り込んで利用した方がよいと思います。

今回のツールではデフォルトを Email にしていますが、例えば Content Type を All にすると、メールだけでなく画像や動画、ドキュメントなども検索対象になります。

本文検索をしたいだけなのに、それらのコンテンツまで取得してしまうと、不要な API Request を消費する可能性があります。

今回、実際に作成して試してみたことで、便利な一方で、使い方によっては API Request の消費量にも注意が必要な機能であることが分かりました。

とはいえ、このような検索を毎日何度も実行するというよりは、

  • 過去のコンテンツから特定の URL を探したい

  • 特定の文字列を使用しているメールを確認したい

  • Revised のコンテンツだけを確認したい

といった、必要なタイミングで利用するケースが中心になると思います。

また、今回のツールでは権限セットを使用して利用者を制御しているため、API Request の消費について理解しているユーザーだけが利用する運用にしておけば、十分実用的だと思います。

最初は単純な CMS 検索ツールを作るつもりでしたが、実際に REST API を使って検証してみると、標準の検索では本文のすべてを検索できないことや、Content Block の参照、API Request の消費など、いろいろと考慮すべき点があることも分かりました。

結論として少し注意点の多い内容にはなりましたが、Marketing Cloud Next の REST API を使って同じようなツールを作ろうとしている方には、今回の検証結果も含めて参考になればと思います。

今回は以上です。


前回の記事はこちら

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