2026年のエージェント型マーケティング：システムが公開すべき4つの要素

短い答え： エージェント型マーケティングとは、次のステップを自ら選び、それを実行するソフトウェアによって行われるマーケティング業務です。合意がほぼそこで終わるのが実情です。2026年8月18日にこの用語とその派生語で返ってきた11ページを取得しましたが、そのうち8ページはプロトコル、ツール呼び出し、関数呼び出しに一切触れていません。そこはエージェントがチャットウィンドウではなく、あなたのコミュニティ、キャンペーン、顧客記録を変えうるものになる層です。そこで本記事では、エージェントがマーケティング業務を一切行えるようになる前にシステムが公開すべき4つの要素でエージェント型マーケティングを定義し、そうしたシステムが自らについて公表するラベルが信頼できない理由をModel Context Protocolから引用し、Zealy自身のエージェント機能をこの定義に照らして採点します。私たちが基準を満たせていない部分も含めて。

開示： Zealyがこのページを公開し、Zealyがその主題となるものを販売しています。Zealyはコミュニティおよびクエストのプラットフォームです。その機能のうち2つは本記事が定義する意味でのエージェントです。外部のAIが操作できるMCPサーバーと、製品内のAIレビュアーです。3つとも以下に登場します。ここにあるZealy自身のエージェント機能に関する内容はすべてファーストパーティです。Zealyのリポジトリから読み取り、私たちがZealy自身のサーバーに対して実行し、他者による監査は受けていません。自社製品を説明するあらゆるベンダーに対して向けるのと同じ懐疑心で読むべきです。

最終確認： 2026年8月18日。

エージェント型マーケティングとは？

エージェント型マーケティングとは、人が描いたワークフローに従うのではなく、目標に向けて次の行動を自ら選ぶソフトウェアによって行われるマーケティング業務です。システムが該当するのは、チャットボックスではなく名前付きのツール、行動前にそれらを発見する手段、意図的な承認境界、そして返ってくるものに対する信頼境界の4つを公開している場合のみです。

この定義は私たちのものであり、意図的に野心ではなく仕組みから組み立てています。読んだ公表済みの定義はすべて、ソフトウェアが何をしようとしているかを説明しています。あなたのスタックがそれを実行できるようになる前に何が真でなければならないかを説明したものは一つもありません。以下が4つの要素で、システムが満たすべき順に並べています。

1. テキストボックスではなく、名前付きのツール。 エージェントには名前、引数、戻り値の形を持つ操作が必要です。たとえば create_campaign, list_members や send_messageのようなもので、文章しか生成できないモデルは文章しか生成できないからです。Model Context Protocolは現在、そうしたリストを公開する一般的な方法であり、そのツールはモデル制御と呼ばれるものです。言語モデルがコンテキストとユーザーのプロンプトに基づいて自ら発見し、呼び出します。この層がなければ、あなたが持つのは執筆アシスタントです。それは有用な製品ですが、本記事の対象ではありません。
2. 行動前の発見。 エージェントは何かへコミットする前に、何が存在し、それぞれが何をするのかを問い合わせられなければなりません。人がすでに3つの呼び出しを選んだハードコードされた統合は、コピーにモデルを付けただけの自動化です。
3. 誰かが意図的に選んだ承認境界。 すべての行動は人を待って止まるか、止まらないかのどちらかであり、どこかにどちらかを決めるルールがあります。ルールは厳しくても緩くても構いません。許されないのは、検討されていないことです。
4. 返ってくるものに対する信頼境界。 ツールの結果は、メンバー、顧客、フォーム、スクレイピングされたページなど、他者が書いたデータです。返された文字列がエージェントを次のツール呼び出しへ説得できるなら、あなたはクエスト提出欄に記入する誰からでも指示を受け取るシステムを構築したことになります。

そこから2つの帰結が生まれ、それが私たちがわざわざ定義を書いた理由です。 最初の要素を欠くものは、マーケティングが上手くなったチャットボットです。 そして 3番目の要素を欠くものは、自律性について決定を下していません。自律性が勝手に起きただけです。 自分で選んでいない承認境界は設計上の立場ではなく、まだ何の犠牲も生んでいない事故です。

存在する定義と、それぞれが自律性の線をどこに引くか

公表済みの定義は、エージェントが自ら計画し行動するという点で一致し、人の関与をどこまで残すかで意見が分かれます。Vlerick Business Schoolは最小限の介入を許容します。Brazeは知覚し、決定し、行動するシステムを説明します。Young Urban ProjectとNetcoreはどちらも各ステップでの人の承認に線を引きます。Forresterはエージェントとエージェント型AIを完全に分けています。

右の列より中央の列を先に読んでください。誰がカテゴリを定義しているかは、どこに線を引くかを大いに物語ります。

右側の列の各文字列は、検索結果から読み取ったものではなく、2026年8月18日に取得したリンク先ページの生テキストと照合したものです。この用語で上位表示される6ページは、まったく読み取れませんでした。Salesforce、IBM、Gartner、BCGはすべての試行で403を返し、McKinseyとAdobeはタイムアウトしました。ここにはいずれも引用していません。

3つのページは、隣接する用語との使える境界線も引いており、残す価値があると判断したのはこの3つだけです。

マーケティング自動化との違い。 Treasure Dataは「エージェント型マーケティングはAIマーケティングより狭く、マーケティング自動化とは異なる」と述べています。なぜなら「マーケティング自動化は、人間が定義した固定のワークフローを実行する」からです。テストすべきは、ソフトウェアがあなたなしで動作するかどうかではありません。あなたのメールツールはすでにそうしています。テストすべきは、一連のステップが事前に人間によって選ばれたかどうかです。

生成AIとの違い。 Optimoveはこれを2つのトリガーの対比として表現しています。「生成AIは人間のプロンプトに基づいてコンテンツを生成する」一方、「エージェント型AIはプロンプトを待たずに自律的に行動する」。プロンプト型かゴール型かという区別は実在するものであり、めったに守られていない区別です。

アシスタントとの違い。 このセットの中で最も鋭い一文は、 Docketの Arjun Pillaiによるものです。「アシスタントはユーザーを待ち、タスクを支援し、人間のワークフローの中で生きる」。そのエージェント側は「エージェントは目標に向かって行動し、境界のある意思決定を行い、ワークフローを起動し、監督下で実行の一部を担う」。同じページの別の箇所が、その表現に欠けている仕組みを補っています。人間は「目的、エスカレーションルール、トピック制約、承認しきい値を定義する。エージェントはそれらの境界内で動作する。何かが境界外に落ちた場合、エージェントはエスカレーションする」。エスカレーションとは、私たちの定義における承認境界を、エージェント側から記述したものです。

ひとつの不一致は、ならすのではなく、そのまま示す価値があります。Forresterは、 AIエージェントのユースケースに関するページ でCraig Le Clairの名前が挙がっており、上のすべてのベンダーページが同義として扱う2つの用語を区別しています。AIエージェントは「事前定義されたルール」で動作するのに対し、「エージェント型AIはより広い自律性と適応性をもたらす」としています。この引用には注意が必要です。これは公開された調査ノートではなくポッドキャストのランディングページであり、調査結果としてではなく、あるアナリスト企業の枠組みとして引用しています。

11の定義のうち8つが省いている層

2026年8月18日にこの用語で取得した11ページのうち、8ページはModel Context Protocol、ツール呼び出し、関数呼び出しに一切言及していません。この層こそが、キャンペーンブリーフを書いてくれるモデルと、クエストを作成したり、メンバーをBANしたり、イベントストリームを新しい場所に向けたりできるモデルの違いです。

これらの文字列に一切言及していない8つ：braze.com、cdp.com、docket.io、forrester.com、netcore.ai、tofuhq.com、vlerick.com、youngurbanproject.com。残りの3つのうち、hubspot.comはModel Context Protocolに言及していますが、定義ページではありません。 Optimove は私たちの印象に残った唯一の例です。文字列 MCP はそのページのナビゲーションメニューに「The Optimove MCP」としてのみ現れ、このカテゴリーを説明する記事の本文には決して現れません。MCPサーバーを提供しているベンダーが、エージェント型マーケティングの自社解説で、自社が提供するものに決して到達していないのです。これはある一日の11ページについての記述であり、カテゴリー全体についてではありません。しかし、確認したすべてのページに当てはまりました。

このセットのうち2ページは欠けている層を名指ししており、どちらも見事にやっています。

HubSpotのDuncan Lennoxは こう書いています：「しかしエージェントはダッシュボードをクリックしたりインターフェースを操作したりしません。APIを呼び出し、構造化された出力を読み取り、行動します」。同じページはスコープを「エージェントが読み取り、書き込み、行動できるもの」と位置づけており、これが正しい単位です。「マーケティングができるか」ではなく、どの名詞とどの動詞かです。

ベンダー評価を販売するマーテック調査会社Real Story Groupが、議論を締めくくる一文を提供しています。 MCPに関する記事 （2025年6月11日付）で、主席アナリストのScott Simmonsはこれを「AIエージェントのために構築された普遍的なAPI抽象化層」と呼び、エージェントは「ベンダーが何を公開することを選ぶかによってのみ、その能力が決まる」という結論を導いています。

その最後の節がすべてです。エージェント型マーケティングは、あなたが選んだモデルの特性ではありません。ベンダーが公開するサーフェスの特性です。ツールが読み取り専用なら、あなたのエージェントは報告するだけです。ツールがなければ、あなたのエージェントはコピーを書くだけです。能力の問いと調達の問いは同じ問いです。だからこそ、この層を飛ばす定義は読むのは心地よく、行動に移すのは難しいのです。エージェントが行動するであろうチャネルの全体像を知りたい場合は、私たちの web3マーケティングの柱 でそれらとそのコストを扱っています。

ツールリストが証拠であり、ツールラベルが単なるヒントにすぎない理由

Model Context Protocolは、エージェントがあなたに対して何ができるかという問いに、サーバーのツールリストを読むよう指示することで答え、その後クライアントにはそのリストが自分自身について語ることを信頼しないよう伝えます。そう述べた注記は本文ではなくスキーマにあり、それがほとんど誰も読んでいない理由の一部です。

以下がその箇所です。 ToolAnnotations インターフェースの 仕様のスキーマ （リビジョン2026-07-28）より：

注記： ToolAnnotations 内のすべてのプロパティは ヒントです。これらはツールの動作を忠実に説明することを保証するものではありません（次のような記述的プロパティを含みます： title).

そして同じテーマについて、次から引用します： ツールページ:

信頼性・安全性・セキュリティのため、クライアントは 必ず ツールの注釈は、信頼できるサーバーからのものでない限り信頼できないものと見なしてください。

その形を少しの間、噛みしめてみてください。"このものが自分に何をしうるかをどうやって知ればよいのか" に対するこのプロトコルの答えは、リストを読むことです。そのすぐ次の指示は、リストはあなたが評価している当事者による主張である、というものです。ツールの 名前 と schemas は重要な役割を担っています。モデルがそれらを呼び出し、サーバーがそれらを遵守する必要があるためです。それらに付与されたリスクラベルは、サーバー自身の動作に関するサーバー自身の説明です。

そのようなラベルは4つあります — readOnlyHint, destructiveHint, idempotentHint と openWorldHint — そしてそのうちの2つ、 destructiveHint と openWorldHint、デフォルトは true. ラベル付けされていないツールは破壊的で外部世界に触れると見なされる。これは正しい判断であり、多くの人の予想とは逆である。

エージェント型マーケティングの定義で重要なのは、 destructiveHint、それが問わないことにある。上書きと追加を区別する。危害は別の軸であり、スキーマにはその列がない。そのため、純粋に追加的な呼び出しがエージェントがあなたのスタックに対して行う最も重大な行為でありながら、完全に誠実に動作するサーバーによって安全とラベル付けされることがある。各フラグが実際に何を意味するか、そしてデフォルトを適用したときに実際のリストがどう見えるかは、 隣のウォークスルー.

これは、マーケターが「エージェントウォッシング」と呼び続けているものの正直な姿でもあります。Young Urban Projectはそれを正確に名指ししています。「最もよくある失敗はエージェントウォッシングです。既存の自動化製品やチャットボット製品を、その下に計画や意思決定のレイヤーを追加することなくエージェント型としてブランド変更することです」と述べ、さらに「デモは、まさに重要なギャップを隠すように台本化されています」と付け加えています。ツール一覧はデモよりもはるかに台本化が難しいものです。また、このカテゴリー全体の中で、ベンダーの協力なしに購入者が確認できる唯一の成果物でもあります。だからこそ私たちは、以下について別のウォークスルーを書きました。 接続する前に任意のMCPサーバーのツールを列挙する方法.

承認の境界がどこにあり、誰がそれを設定するべきか

Model Context Protocolは、ツール呼び出しを拒否できる権限を持つ人間が常にループ内にいるべきだと述べており、それはクライアントアプリケーションに対して、MUSTではなくSHOULDとして示されています。プロトコル内で、あなたが接続するサーバーに義務を課すものは何もありません。承認の境界をどこに置くかは誰かが下した選択であり、多くの場合それはあなたではありません。

該当する正確な文は次のとおりです:

信頼性・安全性およびセキュリティのため、 SHOULD ツール呼び出しを拒否できる権限を持つ人間が常にループ内にいるべきです。

同じセキュリティのセクションでは、クライアントに対して「悪意のある、または偶発的なデータ流出を避けるため、サーバーを呼び出す前にツールの入力をユーザーに表示する」ことと、「LLMに渡す前にツールの結果を検証する」ことが求められています。どちらもクライアント、つまりあなたの側で動作し、モデルを保持するClaudeやChatGPT、あるいは社内製ハーネスに向けられたものです。したがってプロトコルを素直に読めば、エージェント型マーケティングの安全性はクライアントの責務であり、あなたが接続したサーバーは正直なツール一覧以外に何もあなたに負うていません。

このカテゴリはそのことを認識していますが、どう対処すべきか確信が持てていません。ベンダーのガイドは、人間の不在によってエージェントを定義しておきながら、同じページのさらに下で人間をどこに戻すべきかを説明するのが常です。私たちはそうしたページの一つを次の記事で分解しています: AIエージェントは実際にあなたのコミュニティを運営できるのか. どちらの半分も本心です。定義は市場に向けて書かれ、指示はデプロイに向けて書かれており、その間のギャップこそが、自律性に関するあらゆる実際の意思決定が本当に行われる場所です。

擁護する価値があるのは「完全な自律性」でも「すべてを承認する」でもありません。境界は意思決定ごとの設定であり、双方にコストがかかるという考え方です。そして、それを強制する仕組み自体が失敗しうるソフトウェアであるという点です。これは今年初めのDiscordモデレーションの障害が示した通りで、公開された設計には人間によるレビュー工程が存在していたにもかかわらず、バグによってその工程が経路から外れました。これについては エージェントにコミュニティを運営させることの意味を 別途記事にしました。一つの節では収まらないからです。

「どの呼び出しがゲートに値するか」について、今では計測に基づく答えも存在します。 どの 呼び出しがゲートに値するかについて、今では計測に基づく答えも存在しますが、それは直感が示すものとは異なります。 SABER: Small Actions, Big Errors — LLMエージェントにおける変更ステップの保護Alejandro Cuadron、Pengfei Yu、Yang Liu、Arpit Gupta による2025年11月26日提出の論文は、ツールを使用するエージェントの軌跡が誤った場合に実際にコストがかかる場面を研究している。同論文は「対照的に、非変更アクションの逸脱はほとんど、あるいはまったく影響しない」と報告している。その直前の文は反対側を示している。追加の逸脱ごとに「 変更中 アクションは、最先端モデルにおいて、2つのドメインのうち一方で成功率を最大92%、もう一方で最大96%低下させます。失敗は状態を変更する呼び出しに集中します。

設計上の結論は地味で安上がりだ。書き込みにはゲートを設け、読み取りはそのままにし、「human in the loop」を単一の設定で切り替えられる単一のダイヤルとして扱うのをやめる。Zealyのサーバーはたまたまそう動いており、これを本論文から導いたわけではないと明確にすべきだ。論文は設計の後に届き、設計に同意している。これは証拠主導のエンジニアリングより弱く、何もないよりは強い。引用には注意点が一つ伴う。SABERは基盤とするベンチマークのアノテーションエラーを文書化し、修正版を公開している。古いツールエージェントのベンチマークスコアを、現在のモデルを依然として表すかのように引用すべきでない、という良い理由になる。ここで単一の数値を慎重に扱うべきもう一つの理由は、エージェントの失敗が主に分散の問題であることだ。 マルチターンの調査では、劣化は能力のわずかな損失と信頼性の大幅な低下に分かれ、これはモデルが単に十分でないというのとは別の管理上の問題である。

同じ「実装者に委ねる」パターンは、我々の定義の第4の部分、つまり一層下でも見られる。我々は2026年8月18日に7つの仕様・セキュリティページをダウンロードして検索した。仕様の脅威モデルは認可とトランスポートの脅威モデルであり、confused deputy、トークンパススルー、サーバーサイドリクエストフォージェリ、侵害されたローカルサーバーなど複数をカバーする一方、モデル層の攻撃は実装者に委ねられている。ダウンロードしたページに「prompt injection」という語句は現れない。セキュリティベストプラクティス文書における「injection」の4件の一致は、クロスサイトスクリプティング、シェルコマンドインジェクション、リモートコード実行である。これはトランスポート仕様への不満ではない。仕様は自らの範囲を定める権利がある。これは、何かをつなげた瞬間に問題のどちらの半分を引き継ぐのか、そして返されたデータの信頼境界がプロトコルの想定された性質ではなく、誰かの明示的な責務でなければならない理由についての陈述である。

Zealyは自らの定義に反しており、ここが

この記事の最も厳格な定義、すなわちYoung Urban Projectの「人間が個々のステップを承認することなく」とNetcoreの「各ステップで人間の承認を必要とせずに」によれば、Zealyはエージェント型マーケティングを行っていない。Zealyのエージェントサーフェスを通るすべての書き込みは人のために停止し、書き込みはオペレーターが有効にするまでオフになっている。

後で議論に負けるより、そう言ったほうがよい。以下は自社の4つの部分に対する完全なスコアカードであり、ファーストパーティかつ未監査である。

4つすべてが存在する。それは簡単な部分だ。3つ目はラベルに対して逆方向に設定されている。Zealyのサーバーは承認ゲートをサーバー側に置いており、これはプロトコルがサーバーに求める以上であり、エージェント型マーケティングの厳格な定義が許す以上である。ツールサーフェス自体は監査する価値があるほど大きい — 数えた時点で72の名前付きツール — だが数が要点ではない。設定が要点だ。

また、製品全体で一貫性を主張することもできない。Zealyはクエストのクレームを単独でクローズするAIレビュアーも提供しており、その経路に人はいない。同じ会社で、メンバーが報酬を受け取るかどうかに触れる決定に対して、逆の設定である。どちらの選択も擁護可能だが、適切な自律性の程度について会社全体で単一の答えがあると正直に言うことはできない。

だからラベルを外そう。Zealyが実際に提供するのは、人間のコミットステップを備えたエージェント可読なサーフェスであり、ほとんどのチームが最初に欲しがるべきものに対する地味な名前だ。接続の仕組みを知りたいなら、 MCP統合ドキュメント が正典であり、この記事は意図的にそれを再掲しない。その下にあるより古く広いサーフェスを知りたいなら、 APIドキュメント がそれをカバーしている。そして製品を使ったことがないなら、 Zealyとは何か がより短い入り口だ。

エージェント型マーケティングと呼ばれるものを買う前に何を尋ねるべきか

ツールリストを求めよ。エージェント型マーケティングを売るベンダーは、エージェントが得る名前付き操作を権限付きで示せるか、示せないかのどちらかだ。それ以外のすべて、計画の言語、目標追求の言語、デモは、フォームにつながれたチャットボットと互換性があり、Young Urban Projectにはそれに対する名前がある。

最も短い会議時間で最も多くの情報を得る順に並べた5つの質問：

1. 「エージェントはどの操作を、名前で得るのか？」 答えがリストではなく能力の文なら、答えは出ている。リストなら、動詞を読め。読み取り、書き込み、削除、送信、公開、支払い。
2. 「そのうちどれが私なしで行動できるのか？」 「human in the loopはあるか」ではない。その質問には誰もがはいと答える。どの具体的な呼び出しが人を飛ばすのか、そして誰がその分割を選んだのかを尋ねよ。
3. 「エージェントが読むとき、顧客が書いたテキストはどうなるのか？」 ツールの結果がデータとして扱われるのか、それとも潜在的な指示として扱われるのかを問うている。これを考え抜いたベンダーは即答する。エンジニアが眠れなくなる失敗モードだからだ。
4. 「リスクラベルは何を意味しますか？」 次に、営業資料ではなく仕様書と照らし合わせて答えを確認し、デフォルト設定はどうなっているかを尋ねる。多くの人はそれを逆に推測する。
5. 「できないことは何ですか？」 境界の一覧は最も安価な信頼性のシグナルであり、ほとんど誰も公開していない。その不在は何かの証拠ではない。その存在には大きな価値がある。

最後に語るべきは順序についてだ。ここでの購入判断はたいていタイミングを誤る。エージェント型マーケティングを評価しているチームの多くは、定常業務のうちどれを任せて安全でどれがそうでないかをまだ書き出していない。そしてその判断は、手が請負業者のものか、モデレーターのものか、モデルのものかに関わらず同じだ。 コミュニティタスクを委任する方法 は人を相手にそれを整理しており、その分析はほぼそのまま転用できる。まずそれをやる。エージェントはその間もそこにあり、どのツールを実際に持たせたいかが分かるだろう。