エージェンティック・コマースのアーキテクチャ:1つのMCPケイパビリティ層で4つのAIチャネルに対応する

主要なポイント

• 4つのAIアクセスチャネル(自社ポータル、OpenAI ACP、Meta Muse、外部A2Aエージェント)は、1つのMCPケイパビリティ層を共有できます。 同じコマースロジックを4通りに実装し直す必要はありません。
• 判断ルールは1行です。外部プロトコルが MCP と異なる場合にのみ、プロトコルアダプターを追加します。 OpenAI の Agentic Commerce Protocol には ACP→MCP アダプターが必要ですが、すでに MCP を話すコネクターには不要です。
• Magento / Adobe Commerce は、引き続き信頼できる唯一のシステム・オブ・レコードです。 ACP、MCP、A2A がその価格、在庫、税、注文のロジックを再現することはなく、呼び出すだけです。
• 書き込みツールは、ツール境界で影響度に応じて制御します。 catalog.search_products のような読み取りは自由に流れますが、order.submit や payment.authorize のような機密性の高い書き込みには、人による承認と冪等性が必要です。

コマースカタログを ChatGPT、Meta Muse、パートナー企業のエージェントに接続すると、素朴な設計では価格、在庫、チェックアウトのロジックを プラットフォームごとに4回、実装し直す ことになります。各AIサーフェスは異なるプロトコルを話します。OpenAI は Agentic Commerce Protocol(ACP、Stripe と共同開発)を打ち出し、エージェントは Model Context Protocol(MCP)でツールと通信し、エージェント同士は A2A で作業を委任します。プラットフォームごとに連携スタックを1つ作るのが反射的な対応ですが、その反射こそが高くつく誤りです。

本稿では、エージェンティック・コマースのためのプロバイダー中立なアーキテクチャを示します。サウスバウンド側に企業向けMCPケイパビリティ層を1つ、ノースバウンド側に複数のAIアクセスチャネルを置く という構成です。コマースのシステム・オブ・レコードの実例として Magento / Adobe Commerce を用いますが、このパターンはあらゆるERP、OMS、カタログに適用できます。中心となる成果は、単一の判断ルール、すなわち 外部プラットフォームのプロトコルを MCP に変換しなければならない場合にのみアダプターを追加する というものです。これにより、連携コードをどこに置くべきか、そして、より重要なことに、どこに置くべきでないかが明確になります。

落とし穴:4つのプラットフォームに4つの再実装

どのAIコマースサーフェスも、求める基本操作は同じです。カタログ検索、在庫確認、価格取得、カート作成、注文送信です。素朴なアーキテクチャでは、各サーフェスを独自のロジックでコマースプラットフォームに直接つなぎます。

• 自社ウェブサイト → 独自の Magento 呼び出し
• OpenAI / ChatGPT → 別の Magento 呼び出し
• Meta Muse → さらに別の Magento 呼び出し
• パートナーのエージェント → またもう1セット

こうなると、価格ルールの変更、新しい課税地域の追加、在庫引当の修正のたびに、4か所で修正とテストを行う必要があります。ビジネスロジックがコピーされ、コピーは乖離していきます。これは、あらゆる規模でポイントツーポイント連携のコストを押し上げるコネクター乱立と同じ問題が、SaaSのエンドポイントではなくAIチャネルで起きているにすぎません。

解決策は、4つのサウスバウンド実装を1つにまとめることです。すべてのチャネルは同じ 企業向けケイパビリティ層 に到達します。この層は MCP を通じて公開され、正規のコマースサービスに支えられ、最終的には商品、価格、在庫、カート、税、注文の唯一の信頼できる情報源である Magento に行き着きます。コマースロジックは引き続き Magento が担い、AIチャネルはそれを 呼び出す だけです。

判断ルール:アダプターはプロトコルが一致しない場合のみ

アーキテクチャ上重要なのは、チャネル間でただ1点、どのプロトコルを話すか だけが異なるという点です。この1点が、チャネルに変換アダプターが必要か、MCP に直接つなげるかを決めます。3つのプロトコルは競合するものではなく、それぞれ異なる問いに答えます。

テクノロジー	概要	答える問い
HTTP / REST / JSON	トランスポート、APIスタイル、データ形式	バイトがどう移動するか
ACP	AIコマースの相互運用性(OpenAI + Stripe)	AIコマースプラットフォームと販売者がどう取引するか
MCP	エージェント/アプリとツール間の相互運用性	エージェントやアプリケーションがどのツールを呼び出せるか
A2A	エージェント間の相互運用性	あるエージェントが別のエージェントにどう作業を委任するか

ACP と MCP は異なる問題を解決するため、ACP アダプター は本当に必要です。ACP のコマースセマンティクス(チェックアウトセッション、注文状態、フィード形式)を MCP のツール呼び出しに変換します。A2A もまた別物です。外部エージェントが A2A でタスクを委任し、ゲートウェイがそれを Agent Core にルーティングし、Agent Core が MCP を呼び出します。一方、コネクターモデルがすでに MCP を利用しているプラットフォームには、アダプターはまったく不要 です。ケイパビリティ層に直接到達できます。

ここが常識に反する部分です。「新しいAIプラットフォームには新しいアダプター」というのが直感ですが、このルールは逆を述べます。プラットフォームのプロトコルが MCP でない場合にのみ、アダプターを構築します。 すると4つのチャネルは、4つの連携ではなく4つのアクセス経路に整理されます。

• 自社ポータル → Agent Core → MCP
• OpenAI / ChatGPT → ACP → ACP アダプター → MCP
• Meta Muse → Muse コネクター → MCP (アダプター不要。コネクターが MCP を話すため)
• 外部エージェント → A2A → A2A ゲートウェイ → Agent Core → MCP

すべてが MCP に収束します。この収束こそが設計の核心です。

アーキテクチャの全体像は次のとおりです。

MCP コマースサーバーは再利用可能な境界である

ケイパビリティ層は、小さく安定したコマースツール群、すなわち catalog.search_products、pricing.get_price、inventory.check、cart.create、cart.add_item、order.submit、order.get_status を公開する MCP サーバーです。すべてのチャネルが同じツールを使います。自社ポータルの Agent Core、ACP アダプター、Muse コネクター、A2A 経由で届く外部エージェントは、いずれも catalog.search_products を呼び出します。それぞれが商品検索を実装することはありません。

重要なのは、MCP は ケイパビリティのインターフェース であって、ビジネスデータモデルではないという点です。ツールの背後には、Product、Variant、Price、Inventory、Cart、Order からなるプロトコル非依存のモデルである 正規コマースサービス と、その正規モデルを Adobe Commerce の API に対応付ける Magento アダプターがあります。OpenAI の商品フィード形式や ACP のチェックアウトスキーマが変わっても、変更されるのは ACP アダプターだけです。Magento の API が変わっても、変更されるのは Magento アダプターだけです。中間にあるツールは安定したままです。これは、ガバナンスの効いた MCP モジュール と同じ構造上の規律であり、型付きツール、安定した契約、ベンダー固有の癖を境界部に閉じ込めることを意味します。

ツールは影響度で分類され、ガバナンスはこの分類に宿ります。読み取り(catalog.search、pricing.get、inventory.check)は低リスクで、自由に流れます。書き込み(cart.add_item)は状態を変更しますが、元に戻せます。機密性の高い書き込み(order.submit、payment.authorize、refund.create)は金銭を動かしたり義務を生じさせたりするため、人による承認、重複注文を防ぐ冪等性キー、監査ログが必要であり、どのチャネルが呼び出したかにかかわらずツール境界で強制されます。コネクター自身のガバナンス層(認証、ユーザー権限、人による承認ゲート)は、MCP サーバーの代わりではなく、その 手前 に置かれます。

Meta Muse にアダプターが不要で、ACP には必要な理由

判断ルールを最もよく示すのが、2つの外部AIプラットフォームの対比です。OpenAI の ACP と MCP は異なるプロトコルであるため、ACP 経路には ACP のコマースセマンティクスを MCP のツール呼び出しに変換するアダプターが含まれます。これに対し、連携を MCP エンドポイントとして提出するコネクターモデルは、ケイパビリティ層を直接利用します。ガバナンス境界はコネクターの審査と権限モデルですが、構築・保守すべき第二の変換層はありません。「Muse は別のプラットフォームだから」という理由でアダプターを追加しても、機能のない連携負債が増えるだけです。

同じ判定は、将来のあらゆるAIサーフェスにも当てはまります。問いは1つです。このプラットフォームは MCP を直接利用できるか。 できるなら、既存のサーバーにつなぎ、すべてのツールを再利用します。できないなら、プロトコルアダプターをちょうど1つ追加し、それ以外は何も足しません。こうして4つのチャネル(そして5つ目、6つ目)のコストが抑えられます。

コマースを超えて:同じ層が企業のエージェント基盤になる

コマースは MCP のドメインの1つにすぎません。同じ Agent Core が、コマース MCP サーバー、CRM MCP サーバー、ERP MCP サーバーを呼び出し、「この顧客の過去の購入と互換性のある商品で、500ドル以下、在庫ありのものを探し、提案を準備する」 といった依頼を、コマースと CRM にまたがる1つの計画として組み立てられます。外部への委任には A2A を使います。A2A は 最初の1年で150を超える組織に広がり、パートナー企業の調達エージェントが自社の営業エージェントに委任し、その営業エージェントが MCP 層を呼び出す、という流れを、パートナーに社内システムへの直接アクセスを与えることなく実現します。コマースのアーキテクチャと、より広範な MCP + A2A エンタープライズスタック は、スコープが異なるだけの同じアーキテクチャです。

代表的な構築事例

Adobe Commerce を使う中堅の販売者が、プラットフォームチームを持たずに ChatGPT と Meta Muse の中で商品を販売できるようにしたいと考えていました。私たちはまず正規コマースサービスと Magento アダプターを構築し、6つの MCP コマースツールを公開して、自社ポータルの Agent Core をそれらの上に載せました。次に OpenAI に対応し、ACP アダプターと商品フィード変換器を追加しました。その下では、まったく同じツールを再利用しています。Meta Muse は最も低コストなチャネルでした。既存の MCP コマースサーバーを文書化(エンドポイント、認証、ツール、読み取り/書き込みの分類、機密書き込みの承認)し、コネクターの審査に提出しただけで、独自のアダプターは書いていません。ケイパビリティ層は1つであり、新しいチャネルは作り直しではなく、アクセス経路の追加でした。

関連記事

• Commerce Protocols for AI Agents: UCP, ACP, AP2, and MCP — How the Stack Fits Together — このアーキテクチャが乗るプロトコルの全体像と、取引のどの部分をどのプロトコルが担うか
• A2A vs MCP: Choosing the Right Protocol for Agent Communication — A2A ゲートウェイと MCP 層の位置づけを決める、エージェント間通信とエージェント対ツール通信の違い
• MCP Module Code Standard — ケイパビリティ層を再利用可能にする、ガバナンスの効いた型付き MCP ツールの構造パターン

Adobe Commerce、ERP、CRM といった自社のスタック上にエージェンティック・コマース層を構築する第一歩は、プラットフォームごとではなく、正規のケイパビリティを一度だけ定義することです。

スコープを定めた構築をご依頼ください。 1週間のディスカバリー。システムインベントリ、ワークフローマップ、固定スコープをお渡しします。当社と構築するかどうかにかかわらず、成果物はお手元に残ります。