1つのプレスリリースに、7人のフロンティアAIパートナーが名を連ねた。いまMCPエンドポイントを中心に構築されたプラットフォーム上で、2万ものブランドが稼働している。しかも年間1兆件の体験が、そのインフラを通じて流れている。ところが、つい先週までそのインフラのベンダー契約書には「Model Context Protocol（モデル・コンテキスト・プロトコル）」という言葉は一度も出ていなかった。これが、2026年4月20日、ラスベガスのAdobe Summit基調講演で変わった。
TL;DR: Adobeは「Experience Cloud」というブランドを廃止し、CX Enterpriseを発表した。これは、コアにMCPを据えたフルスタックのエージェント型オーケストレーション・プラットフォームである。Adobe Marketing Agentは、ChatGPT Enterprise、Gemini Enterprise、Claude Enterprise、Microsoft 365 Copilot、IBM watsonx Orchestrate、Amazon Qにまたがって展開される。新コンポーネントとして、Adobe Brand Intelligence、Engagement Intelligence、Experience Platform Agent Orchestrator、そしてCX Enterprise Coworker（GA時期：[未検証]、Adobeは「今後数か月で」）が含まれる。発表当日、ADBEは2.49%上昇して$250.53で引けた。実務上の結論は、MCPが開発ツール系のプロトコルではなく、調達（procurement）の計上項目になったということだ。
1つのプレスリリースに並んだ7つのフロンティアAIパートナー
パートナーのリストだけでも、じっくり腰を据えて見たくなる内容だ。Amazon Web Services、Anthropic、Google Cloud、IBM、Microsoft、NVIDIA、そしてOpenAI。7社が1つの発表に集約されている。エコシステム参加者や「互換」などとしては触れられていない。Adobe Marketing Agentの統合先として、明示的に名指しされている。
つまり、Adobeがデプロイする1つのエージェントが、ChatGPT Enterprise、Gemini Enterprise、Claude Enterprise、Microsoft 365 Copilot、IBM watsonx Orchestrate、Amazon Qの中で動作する。全部だ。同時に。これはヘッジ戦略ではない。これは、フォーチュン500企業のある顧客がすでにどのフロンティア・モデルをライセンス済みか、Adobeが気にしていないという宣言だ。CX Enterpriseは、購入者がすでに支払っているホスト環境のどれであっても現れる。
私がこれまで見てきた限り、ティア1のSaaS企業の名前が、3つのフロンティアラボと2つのハイパースケーラーを、同じく「並ぶ」統合ターゲットとして、このように一息で挙げられた例はない。これまでにも「パートナーシップ」や「powered-by」のバッジはあった。しかしこれは建築（アーキテクチャ）的に別物だ。7つのすべての環境に対して、機能としてのMCP準拠をコミットしている。つまりAdobeは、基盤となる各モデルのAPIが進化するたびに、その統合が動き続けるよう維持する責任を負うことになる。
それは、引き受けたいとは思わないメンテナンス領域だ。だが市場はそれを、負債ではなく「堀（モート）」として読み取ったのは明らかだ。
MCPは先週まで開発者向けツールのプロトコルだった
この6か月の間にMCPサーバーを作っていたなら、すでにModel Context Protocolが何かは知っているだろう。これは、LLMホストが外部ツールを構造化された形で呼び出せるようにするオープン標準である。Anthropicが提案し、Claude Codeが開発者コミュニティの間で普及させ、そしてオープンソースのエコシステムが素早く取り込んだ。機能的には、パワーユーザーや独立系のビルダーが気にしていたものだった。中堅SaaSの調達（procurement）チームは、それについて聞いたことがなかった。
そのギャップは、約48時間で埋まった。
Adobeのプラットフォームは、毎年1兆回以上の体験を、世界の2万を超えるブランドに提供している。これらのブランドには調達部門があり、ベンダーのセキュリティ質問票や、ソフトウェア調達の検討サイクル（6〜18か月）がある。AdobeがCX Enterpriseの中核となるアーキテクチャ要素として、MCPエンドポイントを「プラグインでもなく、ベータ機能でもなく、コア」として挙げるなら、それはMCPがそれらの質問票に登場することを意味する。Anthropicの変更履歴（changelog）を一度も開いたことがないベンダー調達チームは、RFP（提案依頼書）のチェックリストに「MCP準拠（compliance）」を追加することになる。
これはGitHubのスター数とは別種の正当性だ。
私はサイドでMCPサーバーを作っている。いずれも、エンタープライズの営業サイクルを意識して作られたわけではない。この見立ては変える必要があり、そしてそれが変わる理由はAdobeにある。
Adobeが実際に出荷したコンポーネント
Adobeは、CX Enterpriseの傘下で4つの新しいコンポーネントを発表した。
Adobe Brand Intelligenceは、エージェント層にまたがってブランドのシグナルを標準化する仕組みだと説明されている。つまり、AdobeのMCPエンドポイントを呼び出すエージェントは、適当な（または誤った）創作（ハルシネーション）をするのではなく、一貫したブランドのガイドライン、トーンのパラメータ、アセットのメタデータを得られる、という考え方だ。これはエージェント型マーケティングのパイプラインにおける実在の課題であり、少なくとも既知の失敗モードに対処している。
Adobe Engagement Intelligenceはデータ層である。行動シグナル、オーディエンス・セグメント、そしてコンテンツのパフォーマンス指標が、同じMCPの表面（surface）を通じて公開されるため、エージェントは推測ではなく、実際のエンゲージメントデータに基づいた意思決定をできる。
Adobe Experience Platform Agent Orchestratorはルーティング層だ。ChatGPT Enterprise、Copilot、Claudeのように、複数のエージェントを同時に動かす—CX Enterpriseのアーキテクチャが示唆している通り—なら、彼らの出力（output）を調整する何かが必要になる。Orchestratorがその層だ。これはスタックの中でも最もアーキテクチャ的に興味深いコンポーネントであり、同時に、エージェントの出力が衝突した場合にそれをスケールでどう扱うのかについて私が最も疑問を持っている場所でもある。
そしてCX Enterprise Coworkerがある。Adobeはこれを、マルチエージェントのタスク・コーディネータだと説明している。ビジネスユーザーが、全エージェント・スタックを起動し、監督するためのインターフェースである。一般提供（GA）は「今後数か月で」と予定されている。この文言には具体的な日付が紐づいておらず、Adobeは確固たるリリースのタイムラインを公表していない。[未検証] Coworkerは「発表済み」として扱い、「出荷済み」ではない。スタックの上位にあるものは「今すぐ利用可能」として位置付けられていたが、Coworkerがその部分にあたり、そこでは「今すぐ利用可能」が静かに「後で」に変わる。
MCPサーバーを作っているなら、これが意味すること
すでにMCPネイティブなツールに投資してきた独立系開発者や小規模SaaSビルダーには、現実的なメリットがある。
エンタープライズの買い手は、GitHubを見てツールを評価しない。既存のソフトウェア・ベンダー—Adobe、Salesforce、ServiceNow—に「承認されている統合の道筋（approved integration path）」がどうなっているかを尋ねる。もしこれらのベンダーが、いまMCPサーバーのカタログやパートナーディレクトリを公開しているなら、2人チームが作ったうまく作り込まれたMCPサーバーには、6か月前には存在しなかった信頼できる流通（ディストリビューション）経路ができる。エンタープライズ買い手に直接売る必要はない。買い手が信頼する場所に掲載される必要がある。
これは新しい。そして、この分野で作ってきたなら、真剣に受け止める価値がある。
裏返しは、もう少し気の重い話だ。Adobe、Salesforce、ServiceNow、そしてその他の数十社の既存勢は、今後12か月の間にMCP準拠をすべて発表するだろう。その発表の多くは、実装が本当にきれいに整う前に行われるはずだ。MCPは仕様（spec）であり、仕様は、締切のプレッシャーや環境の違いによって、異なるエンジニアリングチームにより別様に解釈される。結果として断片化したMCP方言（dialects）になる。つまり、準拠していると主張しているのに、ベンダー自身の環境の外から呼び出すと壊れる、というものだ。
相互運用性が落ち着くまで、その状態が12か月続くことになるだろう。複数のエンタープライズ・プラットフォームにまたがって動作することを意図したMCPサーバーを作るなら、今すぐテスト用のハーネスを用意し、各ベンダーの実装に対して個別にテストすること。仕様が実装であると仮定しないこと。
本当のリスクは、エンタープライズがMCPを無視することではない。名前を採用し、しかしプロトコルを静かに守っていないものを出荷してしまうことだ。オープン標準がエンタープライズ文脈で死ぬのは、拒否からではなく、薄め（dilution）によってだ。
これは、Hermes 4がツール呼び出しを別途訓練したスキルとして何をしているか、という文脈で監視する価値がある。もしまだその分解（breakdown）を読んでいなければ、ここで重要なのは、MCPの信頼性においてサーバー側と同じくらい、モデル側の信頼性も重要だからである。
株式市場も同意した
ADBEは発表当日に2.49%上昇し、$250.53で引けた。
それは特定の種類のマーケットシグナルです。Adobeの時価総額を持つ企業での2.49%の値動きはノイズではありません——それは読み（シグナル）です。そしてその読みは「Adobeが自分自身を破壊した」ですらない。そうではなく「Adobeがうまく自社の防衛線（堀）を守った」です。
市場は、エンタープライズのマーケティング予算がAdobeから離れて、より新しい何かへシフトしていくシナリオを織り込みませんでした。織り込んだのは、Adobeが依然としてエンタープライズのマーケが稼働するプラットフォームであり、さらにその上にAIレイヤーが乗っていて、引き剥がし（乗り換え）がより難しくなっている、というシナリオです。これは典型的な既存企業の戦略です。スイッチングコストが下がるのではなく上がるように、AIを十分に深く組み込む。
この見立ては、MCPサーバーのビルダーとしてAdobeに対して競合するのか、並走するのかをどう位置づけるかに影響します。あなたはAdobeのAI能力と競っているわけではありません。あなたは、Adobeが今まさに「粘着性」を持たせようとしているエコシステムの中に構築しているのです。問題は、あなたのMCPサーバーがAdobeの買い手にとって「取り込みたい」ものなのか、それとも信頼しているカタログに載っていないために「そもそも目に入らない」ものなのか、という点です。
この領域で戦おうとして、効率の悪いコンテキスト管理にトークンを燃やしているなら、そのトークンのオーバーヘッドは実際のコストです。Claude Codeのトークン無駄遣いに対するcontextzipアプローチは、何かをスケールする前に実行する価値があります。
ちなみにですが、Opus 4.7のSWE-benchでのジャンプが87.6%——この投稿でカバーされている——の発表は、Adobeのキーノートの3日前でした。同じ方向を指す、無関係な2つの発表です。つまり、2026年に本気のツール開発の資金が向かうのは、MCPネイティブなエージェント基盤である、ということです。
私がずっと考えてしまうのは、「今後数か月でGA（一般提供）」というギャップと、Adobeが発表した内容の幅です。彼らは7つのフロンティアAIパートナーを挙げました。フロンティアをまたぐMCPのコンプライアンスについてコミットしました。20,000社のエンタープライズ・ブランド向けの、本番投入可能なインフラとして全スタックを位置づけています。ですが、実際にエージェントを調整するコンポーネントには出荷日がありません。
このギャップは、エンタープライズ向けソフトウェアのローンチでは珍しいことではありません。しかし、それでもなお、特に注目する価値があるのはこの点です。CX Enterprise Coworkerが——約束ではなく本当の日付とともに——出荷されたとき、プロトコル戦争は実際に始まるでしょう。
MCPはマーケティング予算をもらいました。実際に動く実装ができるかどうかが、これからの18か月のエンタープライズ向けエージェント・ツールの行方を決める問いになります。
出典: Adobe CX Enterpriseのプレスリリース | CX Enterprise Coworkerの発表 | ADBE株の報道 | Martechの分析
