EU向けマーケットプレイスで法人番号を入力させ、身分証を一枚アップロードさせた。これだけでDSAの出店者確認が終わるわけではありません。登記上の会社と商品ページの販売者が違う、入金口座だけ別法人、停止した事業者が別名で戻る。こうした分断を残したままでは、消費者にも当局にも「誰が売った商品か」を説明できません。
DSAの出店者確認で作るべき成果物は本人確認済みバッジではなく、法的主体、販売名、入金口座、商品、注文、苦情、停止履歴を一つのseller IDで再現できる取引経路です。
本記事は2026年9月2日時点のRegulation (EU) 2022/2065、とりわけArticle 30から32と欧州委員会のDSA実施情報を基にしています。DSA上の義務はサービス規模、機能、EUでの提供状況によって変わり、小規模・零細企業への一部適用除外にも例外があります。EU消費者が取引を完了できる機能を提供するなら、日本法人だけで運営していることを理由に外しません。
審査対象はアカウントではなく取引の相手方
販売名の後ろにいる法的主体と、返金・商品責任を負う相手を確定します。
最初に、マーケットプレイス、単なる広告掲示板、自社EC、比較サイトを分けます。DSA Article 30の中心は、消費者がtraderとdistance contractを結べるオンラインプラットフォームです。決済を外部へ飛ばしても、注文形成や販売者との契約を実質的に仲介しているなら、画面名称だけで対象外とは決められません。
一人の担当者が複数法人を運営し、一法人が複数ブランドを持ち、一つの銀行口座へ複数店舗の売上を集めることがあります。seller ID、legal entity ID、store ID、beneficial owner、payout accountを分け、関係を記録します。法人名の文字列一致より、誰が商品の適法性、返金、リコールへ責任を負うかを確定します。
審査単位をメールアドレスや店舗名にすると、同じ事業者の再出店と別法人への名義貸しを見抜けません。停止・再審査は法的主体と支配関係まで戻して判断します。
Article 30の六つを別々の箱にしない
本人、登記、口座、自己証明を突き合わせ、不一致を審査します。
プラットフォームは出店前に、事業者の氏名・名称、住所、電話、メール、本人確認文書または電子本人確認、支払口座、商業登記と登録番号、EU法へ適合する商品・サービスだけを提供する自己証明を取得します。入力欄を六つ作るだけでなく、互いの矛盾を検査します。
登記DBで会社が存在しても、提出者が代表者や権限を持つ担当者か、口座名義がその会社かは別問題です。登記住所がバーチャルオフィスでも直ちに不正とは限りませんが、返品先、製品責任者、税務情報と食い違えば追加確認へ進めます。機械判定が落とした正当な小規模事業者には、人による再確認と不服申立ての経路を用意します。
Article 30は、公開された公式オンラインDBやEU・加盟国のインターフェースを照会し、または信頼できる資料を求めて、情報の信頼性と完全性を最善の努力で確認する構造です。国ごとに登記形式、個人事業者の識別、文字体系が違うため、全世界を同じスコアで切りません。
資料ごとの合格ではなく、法的主体、提出権限、入金先、消費者表示のつながりと矛盾を確認します。
登記確認が200応答でも、代表権、口座名義、商品ページの販売者表示が別なら審査は未完了です。確認結果と不一致の理由を項目単位で残します。
GPSRの越境EC実務で確認するEU責任者や製品識別情報は、seller KYCとは別のデータですが、同じ商品ページへ正しく出す必要があります。
商品ページを出店者の自由入力だけにしない
責任主体と安全情報を構造化し、重要変更を再審査へ戻します。
Article 31は、出店者がEU法上必要な情報を提供できるようインターフェースを設計し、商品・サービスを提供する前に、その情報がそろっていることを確認するよう求めます。販売者の名称・住所・連絡先、製品識別、警告、安全情報など、商品カテゴリで必要項目が変わります。
自由記述欄へ全情報を詰めると、検索・検証・更新ができません。seller、manufacturer、EU responsible person、brand、model、GTIN、warning、対象国、言語を構造化します。画像内の警告だけ、説明文末尾の住所だけでは、利用者が購入前に見つけられないことがあります。
表示確認は登録時だけでは足りません。出店者が商品名、責任者、配送国を後から変更し、必須項目を空にできる設計なら審査を迂回できます。重要項目の変更は再審査へ戻し、公開中の旧表示、変更者、時刻を記録します。
商品ページの完成条件は必須欄が埋まったことではなく、EUの消費者が契約前に販売者と商品の責任主体、安全情報を理解でき、後から同じ表示を再現できることです。
ランダムチェックを全件監査の代用品にしない
公式DBと商品リスクを使い、確認できない状態を合格と分けます。
DSAはマーケットプレイスへ、公式で自由にアクセスできるオンラインDBやインターフェースがある場合、提供商品・サービスが違法と特定されていないか、合理的な努力で無作為確認することも求めます。全商品を適法保証する義務へ読み替えるのでも、年一回のサンプルで終えるのでもありません。
抽出は完全な無作為だけでなく、カテゴリ危険度、過去違反、苦情、価格異常、短期大量出品、画像・説明の使い回しを組み合わせます。医療、玩具、電気製品、化粧品と、一般雑貨では参照DBや確認項目が違います。チェック結果をseller riskと商品riskへ分けます。
公式DBが商品名では検索できず型式が必要な場合、商品マスターの識別精度が監査品質を決めます。検索できなかった結果を「該当なし」にせず、入力不足、DB未収載、確認済みを分けます。
違法商品の通知を注文と在庫へつなぐ
掲載停止から既購入者の救済、再出品防止まで一続きで実行します。
違法商品またはサービスの販売を把握した場合、プラットフォームは影響を受けた購入者を特定できる範囲で、違法性、出店者の身元、救済手段を通知します。画面を非公開にしただけでは、発送待ち、倉庫在庫、広告、再出品、既購入者が残ります。
通知からlisting ID、seller ID、product ID、注文、決済、倉庫、配送、購入国へ展開します。複数出店者が同じGTINを売る場合、商品自体の問題か、特定出店者の偽造・表示問題かを分けます。対象を広げすぎれば正当な販売を止め、狭すぎれば被害が続きます。
掲載停止、注文保留、購入者通知、再出品検知を同じ商品・出店者の記録から実行します。
listingを消すだけでは再発防止になりません。出店者、商品識別、画像、入金先、配送元を使って再出品を検知し、既購入者へ届く救済まで閉じます。
ECの業務標準化で注文例外を管理する時も、違法性・安全性によるholdを通常の在庫切れと別の権限で扱います。
停止判断に説明と異議申立てを組み込む
誤判定を前提に、訂正、人の再審査、解除権限を設計します。
必要情報が不正確、不完全、古いと判断した場合、出店者へ修正を求めます。期限内に直さなければ、情報がそろうまでサービス提供を停止します。即時永久追放を自動化するのではなく、リスク、反復、故意、消費者被害を見て比例的に判断します。
停止通知には、どの情報が問題か、必要な訂正、期限、販売への影響、異議申立て方法を示します。審査ロジックを悪用できるほど詳細に公開する必要はありませんが、「内部基準により停止」だけでは正当な反論ができません。
審査担当、商品安全、法務、不正対策、顧客対応の誰が解除できるかを決めます。売上目標を持つ営業だけで解除せず、証拠と判断理由を別担当が確認します。
KYCの誤判定をゼロにすることはできません。だからこそ、停止理由、訂正方法、人の再審査、解除権限を最初から製品仕様へ入れます。
本人確認データを増やすほど漏えい時の責任も増える
出店者確認では身分証、住所、電話、口座、登記情報を扱います。再審査へ備えて何でも永久保存すると、内部不正や侵害時の被害が大きくなります。反対に審査直後に証拠を捨てると、当局照会、異議申立て、再出店調査へ答えられません。
項目ごとに取得目的、法的根拠、閲覧者、保存期間、マスキング、削除、国外移転、再委託を定めます。審査担当へ口座番号全桁を常時見せず、照合結果と例外理由を分けて保持します。本人確認vendorが原本を持つ場合は、platform側が必要時に証拠を取得できる時間と、契約終了時の返却・削除を確認します。
紙の身分証画像をticketやmailへ添付せず、seller IDへ紐付いた制限領域で扱います。審査画面のscreenshot、download、作業端末、委託先の権限も監査します。高リスク出店者だけ証拠を長く残す場合は、risk判定の根拠と再評価日を持ちます。
出店者確認の精度を上げるために集めた情報が、新しい漏えいリスクになってはいけません。必要な証拠を必要な期間だけ、審査目的に限定して保持します。
海外出店者の原本が日本語・英語以外の場合、機械翻訳だけで法人形態や代表権を決めません。原文、翻訳、翻訳者・service、確認箇所を残し、重要な不一致は現地の公的registerか専門家へ戻します。
出店者が退店した後も、既に成立した注文、保証、返金、違法商品通知へ必要な情報は残ります。account削除と取引記録削除を同時にせず、法定・契約上の保存、係争、調査holdを確認します。保存期限を迎えた原本は削除し、統計・不正検知へ使うデータは再識別riskを評価して分離します。
内部監査では、閲覧権を持つ人数、期限超過、download、退職者権限、vendorの削除証明をsample確認します。privacy incidentが起きた場合に、どのsellerの何の資料が影響したかを記録単位で特定できるようにします。
確認精度とデータ最小化を、どちらか一方だけの目標にしません。
90日で一カテゴリを端から端まで通す
登録、表示、監査、停止、通知、異議申立てを一カテゴリで演習します。
最初の20日でEU消費者が契約できる機能と対象サービスを整理し、一商品カテゴリのseller、listing、order、payoutのID関係を図にします。既存出店者も新規と同じ項目で欠落を測ります。
21日目から45日目は、三つの国・法人形態を選び、公式登記照会、代表権、口座、自己証明を試します。自動判定のfalse positiveと、人手確認時間を記録します。
46日目から70日目は、商品ページの必須項目、変更時再審査、公式DBのランダムチェックを通します。欠落率ではなく、公開前に止められた率と誤停止率を見ます。
71日目から90日目は、違法商品通知を仮定し、listing停止、注文保留、購入者通知、再出品検知、出店者の異議申立てまで演習します。
本番前の合格条件は本人確認完了率100％ではなく、一つの疑義から、公開商品、注文、入金、購入者、再出品を期限内に制御し、判断を説明できることです。
マーケットプレイスのユニットエコノミクスで審査費を計算する場合も、確認一件の単価だけでなく、違法商品による返金、調査、再審査、信頼毀損を含めます。
まとめ
seller KYCを、商品と注文を制御できる取引トレーサビリティへ変えます。
DSAのtrader traceabilityは、本人確認サービスを一つ導入するプロジェクトではありません。出店者の法的主体を確定し、商品ページへ責任情報を出し、変更を再審査し、違法商品を注文・購入者まで止める運用です。
マーケットプレイスの信頼は「審査済み」と表示することではなく、誰が何を売り、何を根拠に許可し、問題時に誰へ何を通知したかを後から再現できることで生まれます。
参考情報
以下は2026年9月2日に確認した一次情報です。
よくある質問
気になる質問を開くと、本文の重要点を短く確認できます。
Q日本のマーケットプレイスもDSA Article 30の対象ですか？
AEUの消費者が事業者と遠隔契約できるサービスをEUへ提供する場合、日本法人による運営だけを理由に対象外とは判断できません。サービス機能、EUでの提供、企業規模と適用除外を確認します。
Q出店者の登記番号を取得すれば確認は完了ですか？
A登記の存在に加え、提出者の権限、本人、入金口座、販売者表示との整合を確認します。不一致が合理的に説明できる場合は、理由と根拠を残します。
Q出店者の本人確認情報を商品ページで全て公開しますか？
A取得・確認する情報と、消費者へ表示する情報を分けます。本人確認文書や口座情報を無制限に公開せず、適用法に従い販売者の必要な識別・連絡情報を示します。
Q商品が違法かどうかを全件審査する義務ですか？
ADSAは一般的な全件監視義務を置くものではありません。一方、マーケットプレイスには公式DB等を使った合理的なランダムチェックや、把握した違法商品への対応が求められます。
Q情報が古い出店者は直ちに永久停止しますか？
A訂正を求め、期限内に直らなければ情報がそろうまで停止します。リスクや反復性に応じた比例的判断、理由通知、異議申立て、人による再審査を設けます。
Q小規模なプラットフォームは全て免除されますか？
A小規模・零細事業者には一部義務の適用除外がありますが、非常に大規模なプラットフォーム等の例外があり、全DSA義務が一律に消えるわけではありません。最新の事業規模と機能で確認します。
