AdobeのマーケティングAIがいつものチャットに。キャンペーンを変更できるのは誰?
AdobeはCX Enterprise CoworkerをほかのAIツールから利用する新しい方法を発表しました。キャンペーンの変更を例に、閲覧・承認・実行の権限を考えます。
あるマーケターが、対象となるオーディエンスの規模が想定より早く縮んでいることに気づきました。チームで使い慣れたAIアシスタントのチャットを開いていて、その場で何が変わったのか聞きたいと考えています。同じ会話から、運用中のキャンペーンを調整する案が生まれるかもしれません。傾向を調べる操作と、キャンペーンを変更する操作では、求められる権限が異なります。どちらもチャットから扱えるようになると、その違いが画面上で分かることが重要になります。
Adobeは2026年11月4日、同社の顧客体験向けツールで動作するアシスタント「CX Enterprise Coworker」の連携を発表しました。同社によると、ChatGPT、Claude、Databricks Genie、法人向けGemini、Microsoft Copilotからアクセスでき、ChatGPT向けのプラグインも提供されています。ほかのプラットフォームへの対応も計画されています。対応先が公表されたら、自社で利用できるかを確認する段階に入ります。利用の可否は、接続先、組織が利用するAdobe製品や契約、管理者の設定によって変わります。

2006年、サンノゼにあるAdobe本社。参考写真はCoolcaesar撮影。トリミングとサイズ変更を実施。CC BY-SA 3.0。画像の出典 · ライセンス。
キャンペーンへの質問から複数の権限が関わる
キャンペーン変更の流れ。Telli.sh作成のオリジナル図解。
ある小売企業で、対象条件が一部重なる二つのキャンペーンを運用しているとします。マーケターは二つ目のキャンペーンのリーチが落ちた理由を知りたいと考えています。アシスタントは、直近の対象者数と配信期間を集め、考えられる理由を示し、変更案を用意できます。変更によってユーザーの所属するオーディエンスが変わる場合、承認者には、どのグループが広がるか、どの除外条件が残るか、運用中のどのキャンペーンに影響するかが分かる必要があります。
発表では、Model Context ProtocolとAgent2Agentを使った相互運用が説明されています。これらは、接続先が利用できる機能を見つけたり、作業を別のシステムに引き継いだりする仕組みを理解する手がかりです。従業員一人ひとりが実行できる操作は、別途確認する必要があります。導入時は、コネクターが従業員自身の認証情報を使うか、サービスアカウントを通じて動くかを含め、接続の両側でどのIDと権限が使われるかを整理します。この部分の違いによって、操作画面を切り替えるだけで実際に行使できる権限まで変わる場合があります。
接続経路を具体的に区別する必要性は、Snowflakeの例から分かります。Adobeはパートナーとの接続を説明する中でSnowflake Cortex AIに触れています。同じ発表には、将来提供する、より広範なプラットフォーム連携についての記述もあります。一方の接続経路への言及から、もう一方も利用できるとは判断できません。Amazon QuickとIBMも、発表時点では連携先として予定されていました。試験導入は、組織で実際に有効になっているプラットフォームとコネクターから始められます。
| 段階 | アシスタントが行えること | マーケターが確認できるとよい情報 |
|---|---|---|
| 閲覧 | 権限の範囲内で傾向とキャンペーンの背景を取得する | データの出所、フィルター、対象期間、集計の遅れ |
| 立案 | 現在のオーディエンス定義を使って変更案を作る | 前提、想定される効果、除外条件 |
| プレビュー | 変更される項目を示す | 承認対象として内容が固定された提案 |
| 承認と書き込み | レビュー済みの提案を、権限のあるIDを使って反映する | 承認者、対象、変更内容、実行結果 |
| 照合 | 書き込み後に保存された状態を取得する | 変更が反映されたかと、必要な場合の復旧方法 |
表は導入の一例です。各項目を、使用する接続先とAdobe製品で確認します。たとえば、承認がどこで行われ、実行記録がどのシステムに残るのかを導入側で確かめます。Adobeの発表には、すべての接続先に共通する監査仕様は示されていません。
二つの役割で同じ依頼を試す
権限が適用される箇所。Telli.sh作成のオリジナル図解。
まずはテストデータを使い、分析だけに範囲を絞って試せます。一人にはキャンペーンレポートの閲覧権限を付け、もう一人にはステージング環境で変更案を作る権限を付けます。普段のチャットツールから、両者に同じ質問をしてもらいます。それぞれの役割に応じた情報が返ることを確認します。レポートの閲覧だけを許可された人は、依頼の言い回しを変えても書き込めない状態である必要があります。
次の試験では、ステージングの提案を承認したあと、適用する前に別のタブから対象キャンペーンを変更します。プレビューが引き続き有効か、適用時に途中の変更について警告が出るか、操作が監査記録に残るかを確認します。接続が途切れた場合にも、同じ変更を二重に送信せずに結果を照合できることを確かめます。接続先がリクエストを再試行できる場合は、とくに重要な試験です。
プライバシーは別に試験します。架空の顧客レコードを使い、集計値、個人に関する詳細、識別子のどれがプロンプト、エクスポート、チャット履歴に現れるかを確かめます。データの送信先と保存期間が組織の方針に合うことも確認します。別のチャットからマーケティングツールを開けることで、承認された業務に取りかかりやすくなり、従来のデータ管理も有効に保てることが望まれます。
AIツールを複数使うチームにとって何が変わるか
今回の発表でチームにとって利点となるのは、使い慣れたアシスタントから顧客体験の業務にアクセスできる可能性です。ツールの切り替えにかかる手間が減り、複数のツールをまたぐ質問がしやすくなります。一方で、同じ変更を依頼できる場所が増えることもあります。変更内容が分かるプレビューと、後から参照できる承認記録があれば、その利便性を管理しやすくなります。
質問してから実行可能な提案が出るまでと、承認してから変更の反映を確認できるまでの時間を測ります。本来拒否されるべき依頼も試験に含めます。権限が足りない理由をアシスタントが説明し、適切に引き継げるなら、利用者は操作の流れの中で権限を理解できます。接続先によってレビューを経ずに実行できたり、実行内容が分からなかったりすれば、同じ利便性でも運用にかかる負担は変わります。
まず集計データを使う判断から
小売の商品企画チームなら、季節キャンペーンへの反応が止まったオーディエンスを尋ねるかもしれません。最初の有用な回答は、集計傾向の対象期間を示し、直近のリスト除外がリーチにどう影響したかを説明するものです。利用が許可されたデータで、保存済みのレポートと件数を照合できるなら、比較的始めやすい試験です。対象期間、フィルター、集計の遅れを明示するよう依頼します。リーチの変動がデータの未確定によるものであれば、キャンペーン案はそのままにしておきます。
次の試験では、後日に予定するオーディエンス変更について、プロジェクトや承認フローの下書きを依頼することが考えられます。Adobeのワークフロー紹介ページによると、利用できる制御は設定したポリシー、接続製品、承認プロセスに依存します。より広い範囲で共有できるプロジェクトのワークフローは、今後提供されると案内されています。導入先ではまだ計画段階の機能なら、発表済みの連携がすでに対応していると社内に説明せず、ステージング環境で同様の提案フローを試せます。
キャンペーン責任者向けのタスクの下書きを作りたい企業もあれば、運用中のオーディエンス条件を変える前に正式な承認を求める企業もあります。二つのワークフローでは、実行時の影響が異なります。チームに必要な最小限の操作と、誰が承認するかを明文化します。実際の製品と接続先で、その制約が守られることを確かめます。デモは画面の使い方を理解するのに役立ち、チームが行うアクセス試験は、それが自社の権限や契約に当てはまるかを示します。
本番のインターフェースと同じ基準でコネクターを試す
- 組織で実際に利用できる接続先、Adobe製品、ロールを選びます。
- 保存済みのレポートと照合できる集計の質問から始めます。可能な限りテストデータを使います。
- レポートの閲覧者とキャンペーンの運用担当者として同じ質問をします。返る内容と、それぞれのIDに表示される操作を比較します。
- ステージングで変更案を依頼し、対象、条件、除外項目、適用時刻を含むプレビューを求めます。
- 期限が切れた承認や、承認後に変更された対象に対して書き込みを試します。エラーを記録し、対象キャンペーンの状態を確認します。
- 承認済みの書き込みを行ったあと、保存結果を元のプレビューと照合し、権限のあるレビュー担当者が操作記録を見つけられるかを確かめます。
結果がどこに記録されるかも文書に残します。接続先のチャットには会話、Adobeには変更記録、別のワークフローには承認記録が残る場合があります。導入時の不具合を調べる担当者には、これらをどう対応付けるかが分かる必要があります。コネクターが実行結果を返す場合は、キャンペーンの版や実行者のIDと結び付けられるかを確かめます。その目的に必要なデータだけを保存します。
接続先を複数有効にする組織は、同じケースを各接続先で試せます。集計の質問にはよく答えられても、書き込み前のプレビューが使いにくい接続先もあり得ます。管理者が監査記録を見つけやすい接続先もあるでしょう。結果は個別に比較します。ある接続先にコネクターが追加されたという事実だけでは、別の接続先で同じ操作やレビューの仕組みが使えるかは分かりません。
オーディエンスデータの利用範囲を決める
ある商品をすでに購入したグループを配信対象から外す変更を考えます。アシスタントには集計値とセグメントの識別子が必要かもしれません。レビュー担当者は通常、個々の顧客名簿をチャットで見る必要はありません。通常の許可された質問と、マーケターの役割を超える詳細を求める質問の両方を試します。何がチャット、コネクター、接続先のサービスに渡るかを確認します。
読み取りでは、適用されたフィルターと同意に関するルールが回答で説明されているかを見ます。書き込みでは、同じルールがプレビューと保存結果に反映されることを確かめます。意図せず対象範囲が広がったとレビューで分かった場合に備え、運用担当者は変更を照合したり前の状態に戻したりするための正式な手段を必要とします。書き込みを許す接続先では、復旧手順も導入計画に含めます。
AdobeのChatGPT向け解説は、具体的な実装を調べる手がかりになります。そこで紹介される手順から評価を始め、自社の製品、ID、ポリシーに合わせて試せます。複数のプラットフォームから利用できることに価値が出るのは、正当な業務にかかる時間を短縮しつつ、キャンペーン責任者が結果を説明、承認、確認できるときです。
クリエイティブ制作の承認は担当者が異なる
小売企業がオーディエンス分析の結果から、新しい広告素材の制作依頼を下書きするようアシスタントに頼む場合もあります。判断には、キャンペーン責任者、クリエイティブ責任者、ブランド上の制約を理解する承認者が関わるかもしれません。Workfrontを使う組織なら、有効になっている連携で、適切なプロジェクト情報を提案し、根拠を添付し、担当者を割り当てられるかを確認できます。どの構成が利用できるかは、Adobeのワークフロー紹介ページで確認します。プロジェクトの作成や承認経路の設定は、導入先でその操作を確かめるまでは試験シナリオとして扱います。
試験では、クリエイティブ責任者に依頼書の下書きを編集する権限を付け、運用中のオーディエンスを変更する権限は付けません。そのうえで、両方の操作を一文で頼みます。適切に機能するワークフローでは、制作依頼書とキャンペーンに適用される権限が区別されます。一方のシステムで書き込めることによって、他方への書き込み権限まで暗黙に付くことは避けます。成功した操作のリンクや識別子が結果にあれば、次の担当者も追跡できます。
接続先が違っても同じ証拠で評価する
| 確認項目 | 各接続先で確認すること |
|---|---|
| ID | チャットにログインした人物と、コネクターが実行者として認識するIDを比較する |
| 同意とデータ | 許可された集計の質問と、役割の範囲を超える依頼を試す |
| 承認 | 提案と承認が同じ版の対象を参照していることを確かめる |
| 監査 | 実行記録を取得し、実行者と結果を保存済みの対象と照合する |
| 復旧 | 失敗した依頼や再試行によって、書き込みが気づかないうちに重複しないことを確かめる |
この表を使えば、導入責任者はどの画面でも同じ観点で確認できます。ステージングの対象と結果を予測できるサンプルデータを使って試験結果を残します。読み取りには対応していても、組織が書き込みに求める承認フローを備えていない接続先では、キャンペーン運用担当者の権限を変えず、読み取りだけの効果を測れます。
最後に、コネクターへのアクセスを取り消し、最初の質問をもう一度試します。利用者にアクセスできない理由が分かる応答が返り、保存されていたチャットから新たな読み取りや書き込みが起きないことを確認します。保存方針に従って過去のどのデータがチャットに残るかは別に確認します。この試験によって、管理者はコネクターの無効化と会話記録の削除を分けて扱えます。
出典
仕事の背景となる会話や判断を検索できる記録にするには、Telli.shのアカウントを作成してください。