この記事の要点
- EC向けMCPサーバーはShopifyとcommercetoolsがGA提供を開始し、2026年4月時点で実験段階を抜けて本番運用フェーズに入った。
- 用途は社内AIアシスタントによる業務自動化、CSの一次応答、AIエージェント経由の買い物体験の3つに集約され、最初の2つはROIが出しやすい。
- 自前で立てる場合は読み取り専用から始めて段階的に権限を広げる設計が、ShopifyとYottaaの両方で推奨されている。
EC向けMCPサーバーが実験段階を抜けて本番運用に入った
2024年11月にAnthropicがMCPを発表した直後、EC業界の反応は静かでした。「AIがツールを呼ぶ標準ができた」というニュースは技術的には重要でも、具体的に何に使うのかがピンと来ない時期が半年ほど続きました。状況が変わったのは2025年後半以降で、ShopifyがStorefront MCPを、commercetoolsがCommerce MCPをそれぞれ発表したあたりから、「EC向けMCPサーバー」が具体的なプロダクトとして認識され始めました。
この記事では、2026年4月時点の主要なEC向けMCPサーバーの実装を一覧し、マーチャントがどのように使っているか、そして自前でMCPサーバーを立てる場合の設計指針を整理します。MCP全体の基礎はMCPとは何かとMCPサーバーの作り方にまとめてあるので、本記事はEC特化の視点に絞ります。
EC向けMCPサーバーとは何か
MCPサーバーは、AIエージェントが外部ツール・データにアクセスするための統一プロトコル実装です。EC向けMCPサーバーの役割は、ECプラットフォーム（Shopify、BigCommerce、commercetoolsなど）や周辺システム（PIM、OMS、CDP）の機能を、AIエージェントが呼び出せる形で公開することです。
従来のREST APIと何が違うのか、という疑問はよく出ます。答えは2つあります。1つはディスカバリです。MCPサーバーは自分が提供するツールと入出力スキーマを機械可読な形で公開するため、AIエージェントが「何ができるか」を自動で把握できます。REST APIは人間がドキュメントを読んで実装する前提ですが、MCPは「AIが自分でつなぐ」ことを前提に設計されています。
もう1つは文脈の維持です。MCPは単なるRPCではなく、リソースやプロンプトといった概念を通じて、エージェントと外部システムの間で状態や背景情報をやり取りできます。これにより、「この顧客の過去の購買履歴を踏まえて」といった文脈依存の処理が自然に書けます。
Shopify Storefront MCP — 最も採用が進む事例
ShopifyのMCP対応は、2025年9月に「Shopify Storefront MCP」として発表されました。2026年初頭に一般提供が始まり、現時点ではShopify Plusプランのマーチャントに対して自動で有効化されています。
提供するツールは主に3カテゴリです。商品検索（カタログクエリ、バリエーション展開、在庫確認）、カート操作（カート作成、商品追加・削除、割引適用）、そしてチェックアウトリンク生成（カートをStripeやShop Payに引き継ぐURL発行）です。注目すべきは、チェックアウト自体はMCPサーバーからは実行できないことで、セキュリティを考慮してそこだけ意図的にプロトコル外に出しています。
Shopifyが公開したベンチマークデータによれば、Storefront MCPを有効化したストアでは、AIチャットボット経由の平均セッション時間が伸び、商品発見から購入完了までの離脱率が改善しています。特にロングテール商品の発見に効いており、「検索窓で正しい単語を知らなかった顧客」がAI経由で目的の商品にたどり着くケースが増えているといいます。
commercetools Commerce MCP — ヘッドレス陣営の答え
ヘッドレスコマースのcommercetoolsは、2026年2月に「Commerce MCP」をプレビューとして発表しました。Shopifyのアプローチと大きく違うのは、どのMCPツールを公開するかをマーチャント自身が細かく制御できる点です。
commercetoolsの顧客基盤はB2Bと大規模B2Cが多く、「AIエージェントに注文を作らせることはできても、値引き交渉はさせない」「読み取りは広く許すが、書き込みは承認付きのみ」といった細かい制御ニーズが強くあります。Commerce MCPはこの要件に応えるため、ツール単位のスコープとRBACを組み込んでいます。
面白いのは、commercetoolsがMCPサーバーの実装を自社内に閉じず、パートナーが独自のMCPサーバーを追加できるエコシステム型にしている点です。例えばPIMベンダーが「商品コンテンツ生成用MCPツール」を提供し、マーチャントが必要に応じて組み込む、といった構成が可能になっています。
Yottaa — 専門ベンダー発のEC向けMCP
Yottaaは2026年1月に、マーチャント向けMCPサーバーをSaaSとして提供する発表をしました。ShopifyやcommercetoolsのようなECプラットフォーム本体ではなく、既存ECサイトに後付けでMCP対応を追加するミドルウェアとしての位置付けです。
Yottaaの強みは、ECプラットフォームの違いを吸収する抽象化レイヤーを持っていることです。Magento、BigCommerce、Shopify、WooCommerceなど複数プラットフォームに対応しており、マーチャントはYottaaに繋ぐだけで主要な商品・カート・注文操作がMCP経由で使えます。パフォーマンス最適化のバックグラウンドを持つYottaaらしく、AIエージェントからの大量同時リクエストを裁くキャッシュ層も組み込まれています。
3つの代表的ユースケース
EC向けMCPサーバーを導入したマーチャントの使い方は、大きく3つのパターンに集約されます。
1つ目は社内業務の自動化です。マーチャンダイジング担当やCS担当が、ClaudeやChatGPTに「昨日の新商品の中で在庫が100以下のものをリストアップ」「サイズM・Lで売り切れ中のSKUを教えて」と聞くと、MCPサーバー経由で実データが返ってきます。これまでBIツールや管理画面を往復していた作業が、自然言語で即座に片付きます。最もROIが出しやすく、実際に多くのマーチャントが最初に手を付けるユースケースです。
2つ目はカスタマーサービスの一次応答です。問い合わせを受けたAIアシスタントが、MCPサーバーで顧客の注文状況や配送追跡を直接照会し、大半の問い合わせを人間を介さずに解決します。従来のFAQチャットボットと違い、リアルタイムのデータに基づいた個別回答ができるのが本質的な差分です。
3つ目はAIエージェント経由の買い物体験です。ChatGPTやClaude上で顧客が「ランニングシューズを探して」と話したとき、MCPサーバー経由でストアの在庫から提案が返り、そのままカートに追加されます。これは一番派手な使い方ですが、エンドユーザーへのリーチや計測の難しさがあり、ROIが見えやすいのは前2つです。
自前でEC向けMCPサーバーを立てるときの設計指針
ShopifyやcommercetoolsのMCPサーバーをそのまま使うのではなく、自前で立てたいというニーズも多くあります。独自のデータ（PIM、CDP、社内ツール）を組み合わせたいケースや、既存ECプラットフォーム以外を使っているケースです。
設計時に最も重要なのは「AIに何を触らせないか」を最初に決めることです。MCPサーバーは原理的に、エージェントが呼べるあらゆるツールを提供できてしまいます。ですが、全部を最初から公開するとセキュリティとコストの両面でリスクが大きくなります。推奨は読み取り専用から始めるアプローチで、商品検索や在庫照会から公開し、運用が安定してからカート操作、最後に注文確定や返金といった破壊的操作を段階的に許可していきます。
もう1つの設計論点は認証とテナント分離です。MCPサーバーを複数マーチャント向けに提供するSaaS型で立てる場合、リクエストごとに「このトークンはどのストアのどのユーザーに紐づくか」を明示的に検証する仕組みが必要になります。トークンをMCPサーバー側で保持せず、リクエストに添付させて都度検証するパターンが一般的です。
実装の具体的なコードはMCPサーバーの作り方 完全ガイドにまとめました。EC特有の論点は本記事、基礎と実装はそちらを参照してください。
まとめ — 実験から本番へ
2026年4月時点のEC向けMCPサーバーは、もはや「実験」ではなく「本番運用プロダクト」のフェーズに入りました。ShopifyとcommercetoolsがGA品質の実装を提供し、Yottaaのような専門ベンダーがミドルウェア層を埋め、マーチャントは自前実装かSaaS購入かを選べる状況になっています。
最初の一歩は難しくありません。Shopify PlusマーチャントならStorefront MCPはすでに利用可能で、社内ClaudeにつなぐだけでCS業務とマーチャンダイジング業務が目に見えて楽になります。そこから徐々に対外的なAIエージェント体験に広げていくのが、現時点で最もリスクが少ないロードマップです。
プロトコル全体の位置付けはMCP・A2A・AP2・UCP・ACP完全比較で整理しています。本記事の内容は、そのうち「ツール接続層」に該当する部分の具体的なEC実装ガイドとして読んでください。
