ECコマースSaaS AEO比較 2026

ECコマースカテゴリのAEO概況

AIエージェントがEC業務——在庫確認・受注処理・商品登録・レポーティング——を自律的に実行する時代が来ている。しかし、このカテゴリのAEO成熟度は、エージェントが「使いやすい」プラットフォームと「使いにくい」プラットフォームの格差が最も大きいカテゴリの一つでもある。

その格差を象徴するのがShopifyと楽天の対比だ。Shopifyは2026年3月に公式MCPサーバー4種（Dev・Storefront・Customer Account・Checkout）を揃え、すべてのストアが/api/mcpエンドポイントを自動公開する体制を整えた。一方、楽天市場のRMS Web ServiceはXML-RPC（SOAPベース）という旧世代のプロトコルを採用しており、現代のAIエージェントとの相性問題が顕在化している。

ECカテゴリは、グローバルプラットフォームと国産プラットフォームのAEO格差が最も鮮明なカテゴリでもある。Shopifyに代表されるグローバル勢が「エージェントファースト」の設計思想を持って仕様策定を進める一方、楽天・BASEに代表される国産EC基盤は、歴史的な技術選択や審査型API運用モデルが足かせとなっている。この構造的な格差がEC事業者のAEO対応を考える上での核心的な問いになる。

Shopify Japan — AAAグレード：公式MCP4種で圧倒的首位

ShopifyはECカテゴリ唯一のAAAグレード取得サービスであり、かつ全調査カテゴリ中でも最高水準の部類に入る。53件の実績件数・94%の成功率・123msの最低レイテンシという数値は、freee（会計AAA）と並んで「エージェントが実際に使える」サービスの代表格だ。

Shopifyのエージェント対応の特徴は、公式MCPサーバーが4種類存在する点にある。Dev MCP（開発・管理操作）、Storefront MCP（商品・カタログの読み取り）、Customer Account MCP（顧客アカウント情報）、Checkout Extensions MCP（チェックアウトフロー）——それぞれのユースケースに最適化された独立したMCPサーバーが揃っており、エージェントが目的に応じて接続先を選択できる設計になっている。

2026年3月15日にCheckout Extensions MCPが追加され、2026年3月25日にはStorefront MCPエンドポイントが全ストアに自動組み込みされた。これにより、新たなセットアップなしにすべてのShopifyストアがエージェント接続可能な状態になっている。

ShopifyとAIエージェントを連携させるポイント

• 複雑なクエリには GraphQL Admin API を使用（REST より1リクエストで多くのデータ取得可）
• 商品価格フィールドは文字列型（例: "1500.00"）——数値として扱うと型エラーが発生
• 在庫操作にはlocation_idが必須。先にGET /locations.jsonで取得すること
• 日本語ストアでは全角文字を含む商品名・説明文が頻出。エンコーディングを正確に処理すること
• Webhook: /webhooks.jsonで受注・在庫変動のリアルタイム通知を受信可能
• APIバージョン（現在: 2024-10）はURLパスに含まれる。最新安定バージョンを使用すること

BASE — BBグレード：国産スモールビジネスECの現在地

BASEは日本のスモールビジネス・個人クリエイター向けEC構築プラットフォームとして約200万店舗の利用実績を持つ国産ECの雄だ。OAuth2認証に対応したREST APIを提供しており、商品・注文・店舗情報へのアクセスが可能。エージェントデータでは2件100%成功を記録している。

BBグレード（AEOスコア0.60）の評価は、主に「公式MCPサーバーの不在」と「実績サンプルの少なさ」によるもので、APIの品質自体は問題ない。平均レイテンシ360msはカテゴリ中2位の水準。

BASEの主要顧客層（個人・スモールビジネス）がAIエージェントの活用に積極的とは言えない現状を踏まえると、MCPサーバーへの投資優先度は短期的に高くならない可能性がある。一方で、API連携によるECツールとの自動化ニーズは着実に増えており、MCPへの対応が競合サービスとの差別化ポイントになる時期が来ると予想される。

BASEとエージェントを連携させるポイント

• 認証: OAuth2（認可コードフロー）。アクセストークンをAuthorizationヘッダーで送信
• ベースURL: https://api.thebase.in/1/
• 商品一覧: GET /items、注文一覧: GET /orders
• 日本語商品名・説明文はUTF-8で処理

Amazon Japan (SP-API) — BBグレード：巨人のAPI接続事情

Amazon Selling Partner API（SP-API）は、商品出品・受注・フルフィルメント・レポートを網羅する包括的なAPIだ。サードパーティ製のMCPサーバー（amazon-sp-mcp）が存在するため、MCPプロトコル経由での接続も技術的には可能だが、公式ではない。

エージェントデータは1件のみ（成功率100%）で統計的に意味のある評価はできない。BBグレードは信頼スコアベースの暫定評価だ。SP-APIのアクセスにはAmazon Sellerアカウントへの申請・承認が必要であり、エージェントが自律的にアクセス権を取得することはできない。この「人間の介在を要する認証フロー」がAEOスコアを抑制する構造的要因になっている。

なお、SP-APIのデータ構造は非常に複雑で、商品データ・在庫データ・受注データがそれぞれ独立したAPIグループに分散している。エージェントが一連のEC業務を実行するためには、複数のAPIを横断して呼び出す設計が必要になる。

楽天市場 — BBグレード：XML-RPCの壁

楽天市場は日本最大のオンラインマーケットプレイスとして圧倒的なGMVを持つが、AIエージェントとの接続という観点では最も課題の多いプラットフォームだ。

最大の問題はプロトコルの世代差だ。楽天RMS Web Serviceの商品管理・受注管理APIは、RESTではなくXML-RPC（SOAPエンベロープ形式）を採用している。KanseiLinkの実績データでは、エージェントが商品データ更新を試みた際にschema_mismatchエラーが発生。SOAPエンベロープを正しく構成し直すことで成功したケースが報告されているが、現代のAIエージェントが標準的なJSON RESTを前提に設計されている以上、この対応コストは無視できない。

レイテンシも550msとカテゴリ最高で、Shopifyの123msと比較すると4倍以上の差がある。楽天のAPIアクセスにはRMS IDカードによる審査・承認が必要で、エージェントが自律的に接続を確立できない点もAEO評価の障壁になっている。

なお、rakuten-travel-mcpは楽天トラベルAPI向けのサードパーティMCPであり、楽天市場の商品・受注管理APIとは別物である。楽天市場の商品管理をMCPで行うための公式ソリューションは現時点で存在しない。

楽天とエージェントを連携させるポイント

• RMS APIはXML-RPC形式。リクエストボディにSOAPエンベロープを含む必要がある
• 楽天Web Service API（書籍・商品検索等）はREST+JSON対応で比較的モダンな設計
• アクセスには楽天IDカード（RMS）への申請・承認が必要
• レイテンシが高いため、タイムアウト設定を長めに設定すること（推奨: 5秒以上）

4社比較サマリーと選択指針

AIエージェントシステム設計者への推奨

• 新規EC構築でエージェント対応を優先 → Shopify一択。公式MCP4種・94%成功率・123msで他の追随を許さない
• BASE既存ユーザー → API連携は技術的に問題ない。MCPサーバー整備を待ちながらREST APIで先行実装
• Amazon出品管理の自動化 → SP-APIは機能は豊富だが認証承認フローが複雑。人間の介在が必要な認証ステップを事前に完了してからエージェントを接続すること
• 楽天市場出品管理の自動化 → XML-RPC対応が必須。JSON RESTを前提としたエージェントフレームワークでは追加の変換レイヤーが必要。楽天Web Service（検索・レコメンド系）のREST APIを使う方が現実的なケースも多い

ECカテゴリのAEO格差は、プラットフォームのアーキテクチャ思想の違いを直接反映している。Shopifyが「すべてのストアにエージェントが接続できる世界」を標準として設計しているのに対し、国産ECプラットフォームはまだその設計思想の転換過渡期にある。日本のEC事業者がAIエージェントによる業務自動化を本格化させるに当たり、プラットフォームのAEO対応状況は今後の重要な選択基準になると予測される。

よくある質問