通販モール連携で受注受付を一元化する設計手順

◆監修・編集責任者　小園 将隆　2026年8月27日

B2B EC-COLUMN

モール連携の「受付一元化」で変わるのは受注データの構造

一元化するのは管理画面ではなく受注データの構造です。経路ごとに異なる注文を単一のスキーマへ正規化し、在庫・単価・出荷の判断を1つの台帳に集約します。制度要件は一元化後も各経路に残るため、設計の起点として先に押さえておく必要があります。

対象になる経路は、複数のモール、自社サイト、電話やFAXによる注文までを含めた範囲です。経路ごとに注文番号の体系・決済方法・配送区分が異なるため、そのままでは同じ受注として扱えません。一元化とは、この差を吸収する共通の受注データ構造を用意することを指します。

世界のEC市場の売上高は、総務省「令和7年版 情報通信白書」によると2024年の7.2兆ドルから2028年に10.4兆ドルまで拡大すると予測されています^*7。

これは世界市場全体の予測値であり、日本国内の通販事業者1社ごとの受注件数を示すものではありません。同白書は、2024年から2029年までの年平均成長率について、日本・米国・ドイツは世界平均を下回ると予測しています^*7。市場の伸びそのものより、経路が増え続ける前提で受付をどう設計するかが論点になります。

一元化される対象は管理画面ではなく受注データの構造

一元管理という言葉から、複数のモールを1つの画面で見られる状態を想像しがちです。しかし画面の統合だけでは、モールごとの注文属性の違い（配送区分・決済方法・注文番号の体系など）は解消されません。

実務で意味を持つのは、経路ごとに異なる注文データを共通の受注データ構造へ変換できているかどうかです。画面はその結果を見るための入口にすぎません。

「受付」に含む工程と含まない工程—名寄せ・引当・出荷指示・請求の境界

受付の一元化に含める工程は、受注取込・商品識別子の名寄せ・在庫引当の判断までです。出荷指示や請求は受付の後工程であり、正規化された受注データを参照する側になります。

この境界をあいまいにすると、受付システムが出荷・請求まで抱え込む設計になり、経路が増えるたびに改修範囲が広がります。含む工程と含まない工程を先に線引きすることが、後述する設計手順の前提になります。

「モール連携」は手段、「受付の一元化」は到達状態

モール連携（API連携。各モールが提供する受注・在庫データの取得口を自社システムに接続する仕組み）は、受注データを取得するための手段です。受付の一元化は、その手段を使って到達する状態、つまり単一の受注データ構造ができている状態を指します。

この2つを区別しないと、「モールとAPI連携すれば一元化は終わる」という誤解が生まれます。連携は入口の整備であり、正規化と台帳の設計が本体です。

受付が経路ごとに分散すると在庫・表示・保存で不整合が生じる

受注が経路ごとに分かれたままだと、在庫の引当・表示義務・保存要件のそれぞれで整合が取れなくなります。3つの不整合はいずれも一次情報の要件と結びついており、一般論の失敗談ではありません。

在庫の二重売り—引当の権威が経路ごとに分かれる

複数の経路がそれぞれ独自に在庫を引き当てると、どの経路の在庫数が正しいかを判断する権威（在庫の正本）が定まりません。結果として同じ商品が複数の経路で同時に売れ、後から欠品が判明する事態が起こります。

在庫の二重売りが起きると、欠品連絡・キャンセル対応・代替品提案を経路ごとに個別対応する必要が生じ、顧客対応の工数が経路の数だけ積み上がります。この負担を避けるには、後述する設計手順のステップ4（在庫と単価の権威を1か所に置く設計）が欠かせません。

表示すべき事項が経路ごとにずれる—特定商取引法第11条・第12条の6

通信販売には、特定商取引法第11条により販売価格・支払時期と方法・引渡時期・申込みの撤回や解除に関する事項などの広告表示義務があります^*3。また第12条の6第1項は、特定申込みに係る画面において分量や第11条各号の事項を表示することを求めます^*3。

経路ごとに別々の画面・カートを運用していると、この表示事項が経路によって異なってしまう恐れがあります。一元化の設計では、経路をまたいで表示事項をそろえる仕組みをあわせて検討する必要があります。

受注データを後から出せない—電子帳簿保存法の検索機能3要件

電子取引で受け取った受注データは、電子帳簿保存法上の保存要件を満たす必要があります。国税庁の一問一答（問48）は、検索機能の確保について3要件を示しています^*4。取引年月日・取引金額・取引先を検索条件として設定できること、日付または金額の範囲指定ができること、2つ以上の記録項目を組み合わせて条件設定できることです。

経路ごとにばらばらの形式で受注データを保存していると、この3要件を横断的に満たすことが難しくなります。監査や税務調査の際に必要な受注履歴をすぐに出せないリスクにつながります。

自社の数字でこのリスクを確かめるには、無料相談で要件を整理するのが近道です。

モール開示条件・消費者保護・取適法—一元化の前提となる3つの制度要件

設計に着手する前に、3つの制度が定める要件を確認しておきます。いずれも一元化の可否そのものを左右する前提条件です。

モール側の提供条件は開示される—取引透明化法第5条第2項第1号

特定デジタルプラットフォームの透明性及び公正性の向上に関する法律（取引透明化法）第5条第2項第1号は、モール側が開示すべき事項を定めています^*1。事項には、提供拒絶の判断基準、抱き合わせ要請の内容と理由、検索順位を決定する主要な事項が含まれます。さらに、商品等提供データの取得・使用条件、出店者が自らのデータを取得できるかの可否・方法・条件、苦情の申出の方法も挙げられています。これらに加えて、開示が特に必要なものとして経済産業省令で定める事項も同号の開示対象に含まれます。

「モールから自社の受注・売上データを引けるか」は交渉で決める事項ではなく、開示されている条件として確認できます。一元化の可否判定は、この開示情報の確認から始めます。

問い合わせ導線の一致が求められる—取引DPF消費者保護法第3条第1項

取引デジタルプラットフォームを利用する消費者の利益の保護に関する法律（取引DPF消費者保護法）第3条第1項は、3つの事項を努力義務として定めています^*2。販売業者と消費者が円滑に連絡できる措置、表示への苦情調査、販売業者特定情報の提供の求めです。

この規定を踏まえると、問い合わせ導線と販売業者情報は経路を横断して一致させておく必要があります。受付を一元化する際は、問い合わせ窓口の情報も正規化対象に含めます。

卸受注が同じ台帳に載る場合—取適法の支払期日と受領拒否禁止

製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律（取適法）第4条第1項は、明示義務を定めています^*6。給付内容・代金額・支払期日・支払方法等を、直ちに明示することを求めています。第3条第1項は支払期日を給付受領日から起算して60日以内、かつできる限り短い期間に定めることを求め、第5条第1項第1号は受領拒否を禁止しています^*6。

BtoCの「注文イコール即時決済」と、BtoBの「明示から受領、60日以内の支払」は同じ受注レコードでは表現しきれません。この分岐点を、正規化スキーマの設計段階で明示しておく必要があります。

受付一元化の設計手順—棚卸しから保存要件まで5ステップ

ステップ1：受付経路と注文属性のマトリクスで棚卸しする

まず、モールごと・自社サイト・電話やFAXなど、現在受け付けているすべての経路を洗い出します。経路ごとに注文番号の体系・決済方法・配送区分・キャンセル可否といった属性を一覧化し、マトリクスを作成します。

このマトリクスが、後続ステップで正規化スキーマを設計する際の一次資料になります。棚卸しを省くと、正規化の途中で属性の見落としが発覚し、手戻りが発生します。

ステップ2：GTIN原則で商品識別子を1本の名寄せキーに統一する

モールごとのSKUと自社品番が別々に存在すると、同じ商品が別商品として扱われ、在庫の名寄せができません。GS1 Japan（一般財団法人流通システム開発センター）が示すGTIN設定の基本原則は、GTIN（Global Trade Item Number。商取引に用いる商品識別コードの国際標準）をサプライチェーン上の取引単位ごとに、他と重複することなく識別・特定できるように設定するというものです^*5。

この原則を根拠に、モール側SKUと自社品番の対応表を作成し、単一の名寄せキーへ寄せます。名寄せキーが定まって初めて、経路をまたいだ在庫の突合ができるようになります。

ステップ3：受注データを必須・経路固有・非保持の3項目に正規化する

受注データの各項目を、全経路共通で必須とする項目、経路固有で保持する項目、そもそも保持しない項目の3つに分類します。この分類が、正規化スキーマの骨格になります。

分類を曖昧にしたまま実装すると、経路が増えるたびにスキーマへ例外項目を継ぎ足すことになり、保守性が下がります。3分類を先に確定させることが、拡張性を保つ条件です。

ステップ4：在庫と単価の権威を1か所に集約する

引当のタイミング、経路別の在庫按分、単価の適用順を、どのシステムが最終的に決定するかを1か所に定めます。この権威が定まっていないと、前段で述べた在庫の二重売りが再発します。

単価についても、卸取引先ごとの掛け率や締め請求などBtoB固有の条件がある場合は、適用順を明確にしておく必要があります。ここがBtoC専用の設計と最も異なる部分です。

ステップ5：電子帳簿保存法の検索3要件を保存設計に落とし込む

正規化した受注データは、前段で述べた検索機能の3要件を満たす形で保存します^*4。取引年月日・取引金額・取引先の条件設定、日付や金額の範囲指定、2つ以上の項目の組み合わせ条件設定です。この設計を最後に置くのは、正規化スキーマが確定していなければ検索条件の設計もできないためです。なお同じ問48は、税務職員によるダウンロードの求めに応じられる状態にしている場合は範囲指定と組合せ条件の2つが不要になり、加えて基準期間の売上高が5,000万円以下の事業者などでは検索機能の確保そのものが不要になるとしています^*4。自社がどの区分に当たるかを確認したうえで、満たすべき水準を決めます。

モール経由・自社サイト・卸—経路ごとに異なる4つの差分

受付を一元化しても、経路ごとの制度上の違いは消えません。表示義務・決済請求・キャンセル・データ取得可否の4つの観点で、経路ごとの差分を整理します。

自社で一元化できるかを判断するチェックリスト

段階導入の順序と撤退基準を先に決める

4つの判断軸をすべて満たしてから着手するのではなく、データ取得可否が確認できた経路から段階的に一元化を進める進め方が現実的です。あわせて、想定していた正規化ができないと判明した場合の撤退基準もあらかじめ決めておきます。

内製・パッケージ・自社開発の使い分け

内製で正規化スキーマを設計するには、経路ごとの受注仕様の理解、GTINなど商品識別の知識、電子帳簿保存法の保存要件の理解をあわせ持つ人材が必要です。実務では、受注設計とシステム要件定義の両方を担当できる人材の確保が課題になりやすいといえます。

特にBtoBの受注要件（明示義務・支払期日・受領拒否・掛売の締め請求・取引先別単価）は、卸取引の実務に即した設計が求められます。ここを自社だけで詰め切れない場合は、要件整理の段階から外部パートナーに相談するのも一案です。

まとめ：通販モール連携の受付一元化を進める3つの判断軸

本稿では、通販のモール連携における受付の一元化を、データ構造の正規化という観点から整理しました。要点を3つに集約すると次の通りです。第一に、一元化されるのは管理画面ではなく受注データの構造です。第二に、特定商取引法・電子帳簿保存法・取引透明化法などの制度要件は一元化後も経路ごとに残るため、設計の起点として先に確認します。第三に、BtoCのモール受注と卸のBtoB受注を同じ台帳で扱えるかどうかが、設計の分水嶺になります。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

受付の一元化と在庫連携は同じですか。

同じではありません。在庫連携は在庫数の同期を指す言葉であるのに対し、受付の一元化は受注データそのものの構造を単一のスキーマへ正規化することを指すものです。在庫連携は、正規化された受注データをもとに在庫の権威を1か所に集約した結果として機能します。

モールから自社の受注データを取得できるかはどう確認しますか。

取引透明化法第5条第2項第1号に基づき、モール側が開示している提供条件を確認します。商品等提供データの取得・使用条件や、出店者が自らのデータを取得できるかの可否・方法・条件が開示事項に含まれます^*1。

一元化した受注データはどのくらい検索できる状態にしておく必要がありますか。

国税庁の電子帳簿保存法一問一答（問48）が示す3要件を満たす必要があります。取引年月日・取引金額・取引先での条件設定、日付や金額の範囲指定、2つ以上の項目を組み合わせた条件設定です^*4。

モール経由の注文と卸の注文を同じ台帳で管理してよいですか。

同じ台帳で管理すること自体は可能ですが、支払期日・受領拒否の禁止・明示義務など取適法上の要件はBtoC受注とは別に満たす必要があります^*6。正規化スキーマの設計段階で、この分岐を明示しておくことが前提になります。

申込画面の表示は経路ごとに変えてよいですか。

表示のデザインは経路ごとに変わってもかまいませんが、特定商取引法第11条・第12条の6が求める表示事項の内容は、どの経路でも満たす必要があります^*3。

1. *1　出典：e-Gov法令検索（デジタル庁）「特定デジタルプラットフォームの透明性及び公正性の向上に関する法律」第5条第1項・第2項第1号（法令本文）（現行2026年5月21日施行）
2. *2　出典：e-Gov法令検索（デジタル庁）「取引デジタルプラットフォームを利用する消費者の利益の保護に関する法律」第3条第1項（法令本文）（現行2025年6月1日施行）
3. *3　出典：e-Gov法令検索（デジタル庁）「特定商取引に関する法律」第11条・第12条の6（法令本文）（現行2026年8月12日施行）
4. *4　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」問48（PDF資料）（令和8年7月）
5. *5　出典：GS1 Japan（一般財団法人流通システム開発センター）「GTIN設定の基本原則」
6. *6　出典：e-Gov法令検索（デジタル庁）「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」第3条第1項・第4条第1項・第5条第1項第1号（法令本文）（2026年1月1日施行）
7. *7　出典：総務省「令和7年版 情報通信白書」第II部第7節2（令和7年版）