マーケットプレイス基盤アーキテクチャ：ベンダー・カタログ・決済・AIとスケール

この技術記事は、マルチベンダー・マーケットプレイスの構築やストアのマーケットプレイス転換を計画しているCTO、アーキテクト、プロダクトオーナー向けです。アーキテクチャ、主なトレードオフ、テスト方法を解説します。情報提供を目的としており、構築のスコープを検討する準備ができている方は、ECサイト・マーケットプレイスソリューションをご覧ください。カスタムプラットフォームがそもそも正当化されるかという広い問いについては、カスタムECプラットフォームガイドをご参照ください。あわせてエージェンティックコマース対応度およびマルチテナントSaaSアーキテクチャもご覧ください。またマーケットプレイス基盤の選択肢もご参照ください。

背景：ストアがマーケットプレイスになると何が変わるか

シングルセラーストアには、カタログオーナー、マーチャント、フルフィルメント運営がそれぞれ1つずつあります。マーケットプレイスはそれぞれが複数存在し、プラットフォームがその間に位置します。

各行がデータ、ルール、障害モードを追加します。アーキテクチャはこれらを明示的に扱うべきであり、シングルセラーストアを無理に拡張して破綻させるべきではありません。

リファレンスアーキテクチャ

このアーキテクチャ上での注文の流れ：

1. 購入者が3ベンダーの商品を含むカートをチェックアウトする。
2. 決済プロバイダーが購入者に1回課金する。
3. 台帳が各ベンダーの取り分、プラットフォームコミッション、手数料を記録する。
4. 受注ルーティングが3件のベンダー注文を生成し、各ベンダーに通知する。
5. 各ベンダーが発送し自社注文を更新し、購入者には1つの統合ステータスが表示される。
6. ホールド期間後、各ベンダーの残高が銀行口座に送金される。
7. 1つのベンダー注文への返金・紛争は、そのベンダーの残高のみに影響する。

ベンダーオンボーディングとアカウント

オンボーディングの速度がカタログの成長速度を決めます。管理フォームではなく、プロダクトフローとして扱ってください。優れたフローは、開始に必要な情報のみを収集し、審査中も商品を出品でき、審査完了まで出品ではなく支払いをブロックします。

スクラッチで構築すべきでない2つの要素があります：

• 身元確認と支払い確認。マーケットプレイス向け決済サービスがこれを担います。例えばStripe Connectは、コネクテッドアカウントのオンボーディングオプションを提供し、各アカウントに必要な確認情報を収集し、支払いを管理します。
• セラーの報告義務。EUでは、2023年1月1日から適用されているDAC7（EU理事会指令（EU）2021/514）により、デジタルプラットフォーム運営者はセラーに関する情報を収集・確認し、税務当局に年次報告することが義務付けられています。これらのフィールドが後付けではなくオンボーディング時に取得されるよう、ベンダーデータモデルを設計してください。

ベンダーアカウントには専用のロールが必要です：オーナー、出品管理スタッフ、注文と支払いを参照するスタッフです。すべてのベンダークエリはそのベンダーのレコードにスコープされなければなりません。

カタログ：ベンダー独自出品か共有プロダクトカタログか

ファッション・ライフスタイル系マーケットプレイスの多くはベンダー独自出品またはキュレーション出品を選び、同一商品系マーケットプレイスはオファー付き共有カタログを選ぶ傾向があります。どのモデルを選択しても、出品はパイプラインを通じて処理してください：インポート、必須属性と画像のバリデーション、モデレーション、そして検索への公開。キューにより大量インポートが購入者に影響することを防ぎます。

決済とペイアウト

マネーレイヤーはマーケットプレイスにとって最もリスクの高い部分です。3つの意思決定がそれを形作ります。

自社口座に入金してベンダーに手動で支払うのではなく、プラットフォーム向けに設計された決済サービスを利用してください。Stripe Connectはその一例です：マーケットプレイスが顧客から入金し、セラーに一部を支払うことができ、コネクテッドアカウントの残高と支払いはプロバイダーが管理します。それでも自社台帳は維持してください。コミッション、手数料、返金、調整はプロバイダーのレコードと照合する必要があるためです。詳細は精算ガイドをご参照ください。

カードデータは自社システムに入れないでください。PCI DSS（Payment Card Industry Data Security Standard）は、カード会員データを保存・処理・送信するすべてのエンティティに対して、ベースラインとなる技術的・運用上の要件を定めています。プロバイダーのホスト型決済フィールドまたはチェックアウトを使用することで、カード処理の大部分をプロバイダー側に置き、自社のコンプライアンス範囲を縮小できます。

注文・フルフィルメント・返品

• 早期分割。後ではなくチェックアウト時にベンダー注文を生成し、各ベンダーがすぐに自分の作業を確認できるようにします。
• ベンダー別配送。各ベンダーが異なる場所から異なる料金・時間で発送する場合があります。購入者には統合された配送サマリーを表示します。
• 集約ステータス。購入者にはベンダー別明細付きの1注文として表示し、サポートスタッフには全履歴が見えます。
• ベンダー明細ごとの返品・返金。1ベンダーの商品への返品が、別ベンダーの残高に影響してはなりません。

プラットフォームのスケーリング

プラットフォーム基盤の選択

Netbase JSCはWooCommerce、Magento 2、Laravel、ヘッドレスコマースでコマースプラットフォームを提供しており、より広いスタックにはPrestaShop、OpenCart、Shopware、CS-Cart、Shopify、Salesforce、Akeneo、Odoo、Symfonyが含まれます。マーケットプレイスの場合、選択は通常3つの選択肢に絞られます：

どの基盤を選んでも、APIファーストで設計してください。ベンダーアプリ、パートナーフィード、AIサービスがストアフロントと同じインターフェースを使用できるようになります。

セキュリティと信頼

マーケットプレイスはアクセス権を持つ人数を増加させます。ベンダーごとおよびプラットフォームロールごとのロールベースアクセス制御、管理者・ベンダーダッシュボードへのMFA、転送中のTLSと保存時の暗号化、定期的な脆弱性スキャンを適用してください。Netbase JSCの開発はこれらの実践に加え、セキュアコードレビュー、ペネトレーションテスト、災害復旧計画に従っています。マーケットプレイス固有のコントロールも追加してください：新規ベンダーや異常な支払い変更に対する不正チェック、出品・レビューのモデレーション、銀行口座情報へのすべての変更に対する監査証跡。AIリスクスコアはレビューキューの優先順位付けに使用できますが、停止や支払い保留の判断は人が行います。

テスト証拠：ローンチ前にテストすべき内容

以下は特定プロジェクトの結果ではなく、一般的なエンジニアリングプラクティスです：

• 台帳照合テスト。複数ベンダー、コミッション、手数料を含む生成されたカートについて、取り分・返金・ペイアウトがプロバイダーのレコードに対してゼロバランスになることを確認します。
• 注文分割テスト。1件・複数件・多数のベンダーを含むカート。1明細への部分返金・キャンセルを含みます。
• アクセステスト。あるベンダーが別ベンダーの出品・注文・ペイアウトを読み取りまたは変更しようとする自動テストが失敗することを確認します。
• インポート負荷テスト。シミュレートされた購入者トラフィック中に最大想定ベンダーフィードを実行し、ページ応答時間が維持されることを確認します。
• ペイアウト失敗テスト。銀行口座情報の拒否、ペイアウト保留、紛争が残高を正確に保ち可視化されることを確認します。
• ランキングとリスクのチェック。AI検索・不正スコアは、購入者への表示やベンダーの保留判断に影響を与える前に、ラベル付きクエリサンプルと過去ケースと照合します。

事例：EUファッションテック・マーケットプレイス

Netbase JSCは、ダイレクトセールスからマーケットプレイスモデルへ移行するEUファッションテックアグリゲーター向けにマルチベンダー・マーケットプレイスを構築しました。クライアントは匿名です。公開されたケースでは、ローンチから6カ月以内にGMVが47%増加し、ベンダーオンボーディング時間が60%削減されたことが報告されています。これはこの記事の2つの要点を支持します：オンボーディングは成長のレバーであり、マーケットプレイス決済プロバイダー（今回はStripe Connect）を使用することでエンジニアリングリソースをオンボーディングとカタログフローに集中できます。マーケットプレイスのケースを読む。

さらに2件の事例が他の市場で同じ要素を示しています。RB Marketplace（西アフリカおよびディアスポラ向け）は、ベンダー承認・コミッション・ペイアウトをマーケットプレイスAPIを使用した顧客アプリと組み合わせています。オンライン分類広告プラットフォーム（匿名の創業者向け）は、攻撃的な広告を管理者モデレーション用にフラグするAIフィルタリングを追加しています。どちらの事例も数値結果は公開されていません。

この記事の限界

• リファレンスアーキテクチャと一般的なプラクティスを説明しています。すべてのマーケットプレイスはベンダー、商品、地域に合わせてこれを調整します。
• 決済・税・消費者規則は国によって異なります。DAC7とPCI DSSは設計上考慮すべき義務の例として挙げており、完全なリストではありません。法律・税務のアドバイスを専門家に求めてください。
• Stripe Connectはプラットフォーム決済サービスの一例として挙げており、他のプロバイダーに対する推薦ではありません。
• EUマーケットプレイスの数値はそのクライアントのローンチから6カ月後の報告結果です。絶対値は公開されていません。

次のステップ

ベンダーモデル、カタログ規模、決済対応地域をお知らせいただければ、アーキテクチャと最初のリリースをスケッチするソリューションレビューを予約します。関連サービスを見る、Netbase JSCのリテール・ECでの取り組みを確認する、またはNetbase JSCのインサイトをご覧いただくこともできます。

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