ECを選ぶとき、「AI機能はありますか？」と聞くのは、そろそろ質問として弱いかもしれません。

これから聞くべきなのは、
「AIから、何を触れますか？」
です。

商品説明文を生成できます。
問い合わせ対応を支援できます。
レポートを要約できます。

もちろん、どれも便利です。
でも、それだけならAIはまだECの外側にいます。

注文を探す。
会員データを確認する。
商品情報を取得する。
分析する。
必要なら、商品情報を更新する。

ここまでできて、ようやくAIがEC運営の中に入ってきます。

これからECサイトを新しく構築する、あるいは数年使う前提でリプレイスするのであれば、「機能」「拡張性」「コスト」「外部連携」に加えて、もうひとつ見ておきたい項目があります。

AIエージェントが、このECで仕事をできるか。

その判断材料として無視できなくなってきたのが、MCP（Model Context Protocol）です。

「AIを使えるEC」と「AIが働けるEC」は違う

生成AIをEC運営に使っている企業は、すでに珍しくありません。

商品説明文をつくる。
販促企画を考える。
CSVを渡して分析する。
レポートを要約する。

ここまでは、EC基盤が何であってもかなりできます。

ただ、この使い方にはひとつ面倒があります。
ECから人がデータを取り出して、AIに渡している。

AIは賢くなったのに、その手前で人間が管理画面を開き、検索条件を指定し、CSVをダウンロードし、ファイルをアップロードしている。
AI活用と言いながら、入口の仕事はなかなか減らない。

これから変わっていくのは、この部分です。

AIエージェントがECシステムに接続し、
「直近90日で2回以上購入している会員の傾向を見て」
と指示すれば、必要な情報を取得して分析する。

さらに許可された範囲で、
「この商品の説明文を修正して」
という指示から、EC側のデータ更新まで行う。

AIがECについて考えるだけではなく、ECの中で処理を実行するようになります。
その接続方法のひとつとして注目されているのがMCPです。

MCPは、AIからシステムを扱いやすくするための共通ルール

MCPは、AIアプリケーションと外部のデータやツールを接続するためのオープンなプロトコルです。

MCPサーバー側から、

• AIに参照させる情報
• 利用できるツール
• 外部システムに対して実行できる処理

などを提供できます。

少し噛み砕けば、
「このシステムでは、AIから何が見えて、何ができるのか」を共通の作法で伝える仕組み
です。

ここで、よく混同されるのがAPIとの違いです。
MCPが普及するとAPIが不要になる、という話ではありません。
むしろMCPサーバーの裏側で、既存のAPIを使ってECシステムと通信する構成も十分にあります。

違いが出るのは、AIからどう使える状態にするかです。

従来のAPI連携では、どのAPIを、どんな条件で、いつ呼び出すかを、あらかじめシステム側で実装するケースが中心でした。

MCPでは、AI側が利用できるツールを把握し、状況に応じて必要な処理を選べるようにします。

EC基盤側にMCPサーバーが用意されることで、AIエージェントを業務の実行主体として組み込みやすくなる。

ここが選定上のポイントです。

「MCP対応です」と言われたら、その次を聞く

今後、おそらくECサービスの機能一覧に「MCP対応」という表記は増えていきます。
でも、比較表に、

MCP対応：○
と付いたから安心、ではありません。

私ならその次に、
「で、何ができます？」
と聞きます。

この記事では便宜上、AIがデータを参照することを「Read」、登録・更新することを「Write」と分けて考えます。

MCPの正式な機能分類ではありませんが、EC基盤を比較するときには、この分け方がかなり実用的です。

まず見るのは、AIから何が読めるか

注文。
会員。
商品。
在庫。
レビュー。
カテゴリ。
配送情報。

ECには、さまざまなデータがあります。

例えば「AIで売上分析できます」と書かれていても、取得できるのが注文データだけなのか、会員属性や商品情報まで横断できるのかによって、分析できる内容はまったく違います。

だから見るべきなのは、「MCP対応」の文字ではありません。
AIにどのデータが公開されているのか。
ここです。

○が付いていることより、○の中身を聞いた方がいい。

次に、どこまで書き換えられるか

検索や分析だけなら、AIはかなり優秀な参謀になります。

でもEC運営には、

商品名を変更する。
商品説明を更新する。
カテゴリを登録する。
設定を変更する。

といった実行系の業務も大量にあります。

ここまでAIに任せられるようになると、AIの位置づけは「分析ツール」から「オペレーションを担うエージェント」へ変わります。

だから選定時には、
何が見えるかだけではなく、どこまで動かせるか。
ここまで見ておきたい。

「AIにつながっています」と「AIに仕事を任せられます」は、似ているようでかなり違います。

makeshop byGMOでも「読む」から「動かす」へ進んでいる

この変化は、すでに実サービスでも始まっています。

makeshop byGMOでは2026年5月11日にMCPサーバーの提供を開始しました。

当初は注文検索・会員検索からスタートし、その後、商品データの検索・取得だけでなく、商品名、価格、画像、説明文、SEO設定などの商品データの作成・更新へ対応範囲を拡張。

さらにレビュー検索、カテゴリ登録、お届けサイクル関連など、利用できる処理は段階的に増えています。

ここで見たいのは、単純な対応機能数ではありません。
AIに開放する業務範囲を、継続的に広げているか。
AIエージェント周辺の技術は、かなり速い速度で変わっています。

なのでEC基盤選定でも、
「今、何ができるか」
だけを比較しても足りません。

「半年後、1年後に何を任せられるようにしようとしているのか」
まで見たい。

EC基盤は、一度導入したら気軽に交換できるものではありません。
だから現在地と同じくらい、進む方向が重要です。

接続しただけでは、EC運営はうまくならない

makeshop byGMOでは、MCPとあわせて「エージェントスキル」も提供されています。

現在は「ショップ分析」「商品分析・改善」「ショップ開店」といった用途のスキルが用意されています。

例えばショップ分析では、注文情報などをもとに売上や受注、アクセスの傾向を見る。
商品分析・改善では、商品データを分析し、商品名や説明文などの改善提案や更新につなげる。

ショップ開店では、開店準備やページ改善、集客までを支援する。
MCPがAIからECへアクセスするための仕組みだとすれば、Skillsは、

「EC運営では、何をどう考えるのか」
をAI側へ渡していく考え方です。

ここは結構大事です。
データを渡せば、AIが勝手に良い分析をしてくれるわけではありません。

何を見るのか。
どう切り分けるのか。
どの数字同士を比較するのか。
そこから何を判断するのか。

EC運営には、EC運営なりの問い方があります。
AI活用の差は、接続できるデータ量だけではなく、どんな業務知識をAIに持たせられるかでも生まれます。

接続できることと、使いこなせることは別です。

AIに何をさせるかより、何をさせないか

AIから更新できる範囲が広がるほど、難しくなるのが権限設計です。

商品情報を変更できる。
カテゴリを登録できる。
注文データにアクセスできる。

機能として可能だからといって、全部AIに渡せばいいわけではありません。

例えば、

閲覧だけを許可する。
特定の処理だけ実行させる。
重要な更新には人間の承認を挟む。
といった制御が必要になります。

ここも、ベンダーに「権限制御できますか？」と聞いて終わりでは弱いです。

私なら、
「どの単位で？」
と聞きます。

データ単位なのか。
操作単位なのか。
ユーザー単位なのか。
実行前に人間が確認できるのか。

MCPに対応していることと、安全にAIへ業務を任せられることは別の話です。

できることが増えるほど、できないようにする設計の重要性も増します。

ECでは「AIに渡さないデータ」も選定項目になる

さらに、ECでは避けて通れないのが個人情報です。
注文情報や会員情報には、氏名、住所、電話番号、メールアドレスなどが含まれます。

AIエージェントからECデータを扱うのであれば、
「アクセスできるか」だけではなく、「外部AIへ何を送らない仕組みになっているか」
まで確認する必要があります。

makeshop byGMOのMCPでは、会員・注文情報に含まれる氏名、電話番号、メールアドレス、住所などをマスキングして外部AIへ送信する仕組みが用意されています。

一方で、すべての入力項目が自動的にマスクされるわけではありません。

会員IDや名入れ情報、伝達メッセージ、備考、会員情報メモなど、運用によって個人情報が入力される可能性のある項目については、利用者側でも扱いを確認する必要があります。

これはMCPに限った話ではありません。

AIと業務データの接続範囲を広げるほど、
「どのデータを使わせるか」より、「どのデータを使わせないか」
が効いてきます。

開いていることより、必要なところだけ開けられること。
これも、これからの接続性です。

EC基盤選定で聞くべき質問は、この5つ

これからECサイトを構築・リプレイスするのであれば、
「AI対応していますか？」
では質問が大きすぎます。

私なら、少なくとも次の5つを聞きます。

1．AIエージェントから取得できるデータは何か

注文、会員、商品、レビューなど、具体的なデータ単位まで確認します。
「MCP対応予定です」ではなく、
何をAIに公開しているのか。

ここまで聞きたい。

2．AIから登録・更新できるデータは何か

参照系と更新系は分けて確認します。

商品情報は更新できるのか。
在庫はどうか。
カテゴリはどうか。
受注ステータスはどうか。

この差は、そのまま「AIに任せられる仕事」の差になります。

3．権限はどの単位で制御できるか

閲覧だけなのか。
特定処理だけ許可できるのか。
実行前に承認できるのか。

「制御できるか」ではなく、どの粒度で制御できるかまで確認します。

4．AIへ送信しないデータをどう扱うか

個人情報のマスキング。
外部AIへ送られるデータの範囲。
マスク対象外項目の扱い。

「何が使えるか」は資料に載りやすい。
でも、
「何を使わせないか」は、こちらから聞かないと見えてこない。

ここは外したくありません。

5．これから何を開放する予定なのか

そしてロードマップです。

現在の対応範囲だけではなく、

「次にどのデータ・処理をAIエージェントへ開放する予定なのか」
まで確認する。

ここを見ると、そのベンダーがAIを追加機能として見ているのか、それともEC基盤そのものをAIエージェント前提へ変えようとしているのかが、かなり見えてきます。

「AI搭載」より、「AIに仕事を渡せるか」

これからEC基盤を比較するとき、「AI搭載」という言葉はかなり増えてくると思います。

でも、私ならその言葉だけではあまり評価しません。

商品説明文を生成できます。
チャットボットがあります。
レポートを要約できます。

便利です。

ただ、それだけではECの機能としてAIが追加されただけとも言えます。
一方で、
ECのデータへアクセスできる。
必要な処理を実行できる。
権限を制御できる。
必要以上にデータを外へ出さない。
接続できる範囲を継続的に広げられる。
ここまで来ると、EC基盤そのものの性格が変わります。

AIを搭載したECではなく、AIに仕事を渡せるECになる。
この違いは、数年後かなり大きくなるはずです。

EC基盤選びで、比較表の一行を変えてみる

これまでECの拡張性というと、

機能追加ができる。
API連携できる。
カスタマイズできる。

といった話が中心でした。

もちろん、これらは今後も重要です。
そのうえで新しく見るべきなのが、
AIエージェントに、どこまでECの仕事を渡せるか。

MCPは、その判断材料になる重要な接続方式のひとつです。

もし今、ECサイトの新規構築やリプレイスで候補を数社まで絞っているのであれば、比較表の一行を少し変えてみてください。

AIエージェント連携：○／×
ではなく、
AIに何を任せられるか。何を任せないか。

この方が、これからのEC運営をずっと正確に表します。

GMOクラウドECでも、EC基盤そのものの機能比較だけではなく、AIエージェントを含めた運用設計まで踏まえて考える場面は、今後さらに増えていくはずです。

「今使えるAI機能」から基盤を選ぶのではなく、
これから人とAIに、それぞれどんな仕事を任せたいのか。
そこからEC基盤を逆算する。
選定基準だけではなく、選ぶ順番そのものが変わり始めています。

※参照：「makeshop byGMO」、AIエージェント連携を可能にする「MCP Server for Backoffice」（MCPサーバー対応）をリリース

※関連リンク：「GMOクラウドEC」公式サイト