マルチベンダーマーケットプレイスのカタログをAIショッピングエージェントに対応させる：スキーマ、フィード、ツールインターフェース

このガイドは、マルチベンダーマーケットプレイスのCTO・アーキテクト・プロダクトオーナーを対象としています。プラットフォームのアーキテクチャを決定し、セラーオンボーディングの順序を整理した後、その結果として得られるカタログをAIショッピングエージェントが読み取り、比較し、取引できるものにする必要があると判断した方々を想定しています。この作業は設計が明確になった段階でECサイト開発として進められ、ECマーケットプレイスソリューションの上で稼働します。単一セラーストアのエージェント対応については、別途エージェンティックコマース対応ガイドをご参照ください。本ガイドは、カタログが1社のマーチャントではなく複数ベンダーのオファーを保持する場合に何が変わるかに絞って説明します。

このガイドの内容

• 単一セラー向け商品スキーマがマルチベンダーカタログで機能しない理由
• スキーマモデル：1商品、複数ベンダーのオファー
• ベンダーフィードをエージェントが読み取れる単一カタログフィードに正規化する
• マーケットプレイスのツールインターフェースが単一ストアと異なる点
• マルチベンダーカタログにおけるAIの位置づけ
• 実績があるものとないもの
• 代替手段：スキーマ・フィード・ツールインターフェース層を誰が構築・運用するか
• このガイドの制限事項
• よくある質問
• 次のステップ

単一セラー向け商品スキーマがマルチベンダーカタログで機能しない理由

単一セラーのストアは、1つのProductに1つのOfferを紐付けて公開します。つまり、価格・在庫数・セラー・ポリシーがすべて暗黙的にそのマーチャント自身のものとなります。マーケットプレイスのカタログでは、複数のベンダーが実質的に同一の商品を販売しているケースが多く、エージェントがそれらを比較するには、最安値だけでなく、その価格がどのベンダーに属するか、そのベンダーの在庫・配送・返品ポリシーはどうなっているか、そして注文を正しいセラーにルーティングするにはどうすればよいかを把握する必要があります。ベンダーレベルの情報を1つのサマリーにまとめると「価格帯は？」という問いには答えられますが、「誰からどのような条件で購入するか」という問いには答えられません。エージェントが行動に移るには、後者の問いに答える必要があります。

スキーマモデル：1商品、複数ベンダーのオファー

実用的なルールとして、人間向けのサマリー（最安値とセラー数）が必要なページにはAggregateOfferを使い、エージェント向けのフィードまたはAPIには、すべてのエントリーに安定したセラー識別子を付けた上で、その下に配置するベンダーごとのOffer配列を提供します。Googleが公開しているマルチセラーマーケットプレイスに関するガイダンスも、フィードレベルで同様の立場を取っています。マーケットプレイスアカウントは、更新をまたいで各セラーを識別できるよう、すべてのアイテムにexternal_seller_idを設定しなければなりません（Google Merchant Center、商品データ仕様、2026-10-26参照）。

マーケットプレイスのツールインターフェースが単一ストアと異なる点

単一ストアのMCP型またはプロトコル型ツールインターフェースは、すべての回答がその背後にある1つのマーチャントに属するという前提を持てます。マーケットプレイスのツールインターフェースにはその前提がありません。同一の検索や商品参照の呼び出しで、1つのアイテムに対して複数のベンダーが返される場合があり、各結果には独自の価格・在庫・ポリシー・セラー識別情報を添付する必要があります（カタログから継承するのではなく）。また、プラットフォームレベルのルール（たとえばマーケットプレイス独自の紛争対応返品期間）を、ベンダー独自のポリシーとは別に表現する手段も必要です。両者は異なる場合があり、エージェントはどちらが特定のオファーに適用されるかを知る必要があります。AnthropicのModel Context Protocolは、ツール呼び出し（特定セラーへの注文など、アクション）とリソース（カタログ出品など、クライアントが読み取るデータ）の違いとしてこれを整理しており、マーケットプレイスにきれいに対応します。カタログとオファーデータは複数ベンダーにわたって読み取られるリソースであり、チェックアウトは1つのベンダーの注文にスコープされたツール呼び出しです（Model Context Protocol、仕様、2026-10-26参照）。ShopifyとGoogleのUniversal Commerce Protocolも、カタログレベルで同様のアプローチを採用しており、単一マーチャントのデータを前提とするのではなく、エージェントが発見できるカタログとチェックアウトの機能を公開しています（Shopify Engineering、Universal Commerce Protocol、2026-10-26参照）。

実績があるものとないもの

• RB Marketplace。RB Marketplaceの実績は、顧客向けREST APIと同APIを基盤としたモバイルアプリを備えたライブのマルチベンダーマーケットプレイスを説明しており、外部クライアントがすでに読み取るAPIファーストのカタログを実証しています。ただし、AI支援の正規化ステップ、構造化データスキーマ、エージェント/MCPインテグレーションは説明されておらず、カタログサイズやパフォーマンスの数値も公開されていません。
• コマースプラットフォームの実績。Netbase JSCはWooCommerce、Magento 2、Laravel、ヘッドレスコマースでのECサイト構築を手がけており、PrestaShop、OpenCart、Shopware、CS-Cart、Shopify、Salesforce、Akeneo、Odoo、Symfonyとも連携しています（これらは本ガイドのカタログおよびフィードレイヤーが乗る、または連携するプラットフォームです）。
• 投資の方向性。David（CEO）は、エージェンティックコマースとAPIファースト開発をNetbase JSCのサービス全体における投資領域として挙げており、AIトランスフォーメーションを組み込んだ開発と並列で推進しています。これは表明された方向性であり、実装済みのエージェントカタログ機能ではありません。

存在しないもの。AIショッピングエージェントを念頭に置いて設計されたマルチベンダーカタログスキーマ、正規化されたエージェント向けフィード、またはMCP/UCP/ACPツールインターフェースのインテグレーションを説明するNetbase JSCの公開実績は存在しません。上記のフレームワークは、schema.org・Google Merchant Center・Model Context Protocolのドキュメントと、Netbase JSC自身のマルチベンダーカタログおよびAPIの作業構造をもとに構築された開発手法であり、測定済みのエージェント対応プロジェクトではありません。

代替手段：スキーマ・フィード・ツールインターフェース層を誰が構築・運用するか

Netbase JSCのカスタム開発では、クライアントが作成されたIPを所有します。ほとんどのプロジェクトはディスカバリー後に合意した請負契約で進められ、マイルストーンベース、月次チームリテイナー、KPI連動の条件も提供しています。エージェントやツールインターフェース呼び出し元は、APIの新しいクライアントタイプとして扱ってください。Netbase JSCの標準セキュリティプラクティス（ロールベースアクセス制御、管理ダッシュボードのMFA、転送中のTLS、保存データの暗号化）は、ストアフロントだけでなく、外部呼び出し元にサービスを提供するカタログAPIにも適用されます。このサービスはECサイト開発として提供され、ECマーケットプレイスソリューションおよび小売・ECマーケットプレイスに関連します。

このガイドの制限事項

• Schema.org・Google Merchant Center・Model Context Protocolのドキュメントは変更される場合があります。構築前に各公開者の最新フィールドと要件を確認してください。
• カタログサイズ、マッチング精度、エージェント注文数の数値は主張していません。現時点でNetbase JSCはこの作業について数値を公開していません。
• 本ガイドはカタログスキーマ・フィード正規化・ツール/APIインターフェースのみを対象としています。セラー受け入れは別のガイドで、単一セラーストアの対応はエージェンティックコマース対応で説明しています。

次のステップ

ベンダーが現在どのように商品データを送信しているかをお知らせください。マルチベンダースキーマ・フィード・ツールインターフェース設計のスコープを確認するためのソリューションレビューをご予約いたします。また、マーケットプレイスプラットフォームアーキテクチャガイドをお読みになるか、Netbase JSCのインサイトをご覧ください。

関連サービスとソリューション