マーケットプレイスプラットフォームのアーキテクチャ：ベンダー、カタログ、決済、AIとスケール

この技術記事は、マルチベンダーマーケットプレイスの構築を計画しているCTO、アーキテクト、プロダクトオーナーを対象としています。アーキテクチャ、主なトレードオフ、テスト方法について説明します。情報提供を目的としており、構築のスコープを定める準備ができている場合は、ECサイトマーケットプレイスソリューションをご覧ください。カスタムプラットフォームが正当化される場合については、カスタムECプラットフォームガイドをお読みください。関連情報として、エージェンティックコマースの対応状況、マルチテナントSaaSアーキテクチャ、マーケットプレイスプラットフォームの選択肢もご参照ください。

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

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

各行にはデータ、ルール、障害モードが加わります。アーキテクチャは、単一セラーストアを無理に改造して破綻させるのではなく、それぞれを明示的に扱うべきです。

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

このアーキテクチャにおける注文の流れ：

1. ショッパーが3つのベンダーの商品を含むカートでチェックアウトする。
2. 決済プロバイダーがショッパーに1回請求する。
3. 台帳が各ベンダーの取り分、プラットフォーム手数料、各種費用を記録する。
4. 注文ルーティングが3つのベンダー注文を作成し、各ベンダーに通知する。
5. 各ベンダーが発送し、自分の注文を更新する。ショッパーには1つのまとめたステータスが表示される。
6. 保留期間後、各ベンダーの残高が銀行口座に移動される。
7. 1つのベンダー注文に対する返金または紛争は、そのベンダーの残高のみを調整する。

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

オンボーディングの速度がカタログの成長速度を決定します。管理フォームではなくプロダクトフローとして扱い、開始に必要な情報のみを収集し、審査中もベンダーが商品をリストできるようにし、リストではなく支払いを審査完了まで停止するようにします。

スクラッチから構築すべきでない部分が2つあります：

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

ベンダーアカウントには独自のロールが必要です：オーナー、リストを管理するスタッフ、注文と支払いを確認するスタッフ。すべてのクエリはそのベンダーのレコードにスコープされます。オンボーディングフロー自体については、カタログ取り込み方法とレビューキュー設計に関するAIセラーオンボーディングガイドをご覧ください。

カタログ：ベンダーリストか共有商品カタログか

ファッション・ライフスタイル系マーケットプレイスの多くはベンダー独自リストまたはキュレーテッドリストに傾き、同一商品を扱うマーケットプレイスはオファー付き共有カタログに傾きます。どのモデルを選ぶにしても、インポート、必須属性と画像の検証、モデレーション、検索への公開というパイプラインを通じてリストを処理してください。カタログモデルが確定したら、それをAIショッピングエージェントが読み取れるようにすることは、スキーマ、フィード、ツールインターフェースに関する別の決定事項です。詳しくはエージェント対応マーケットプレイスカタログガイドをご覧ください。

決済と支払い

マネーレイヤーは、マーケットプレイスが最もリスクを負う部分です。3つの決定がこれを形成します。

自分のアカウントに資金を集めてベンダーに手動で支払うのではなく、プラットフォーム向けに設計された決済サービスを使用してください。Stripe Connectはその一例で、マーケットプレイスが顧客から決済を受け取り、セラーに一部を支払うことができ、コネクテッドアカウントの残高と支払いはプロバイダーが管理します。手数料、費用、返金、調整はプロバイダーの記録と照合する必要があるため、独自の台帳も維持してください。詳しくは決済ガイドをご覧ください。

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

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

• 早期に分割する。後から分割するのではなく、チェックアウト時にベンダー注文を作成し、各ベンダーがすぐに作業を確認できるようにします。
• ベンダーごとの配送。各ベンダーは異なる場所から異なる送料と配送時間で発送できます。ショッパーには、それらをまとめた1つの配送概要を表示します。
• 集約ステータス。ショッパーにはベンダーラインごとの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カ月後のクライアントの報告による結果です。絶対値は公開されていません。

次のステップ

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

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