↗付きの用語リンクは、別タブで説明を開きます。
複数のECと実店舗を運営していると、受注を一つにまとめるだけでは足りない場面がありますよね。基幹システムや独自の出荷手順をどこまで残すかによって、標準機能で進める範囲と追加開発する範囲が変わります。
この記事では、通販する蔵を候補に入れる際、受注・在庫・POS・倉庫のどのデータをつなぐか、どこからカスタマイズが必要になるかを整理します。契約前には自社の例外注文を使い、提供範囲と費用を確認してください。
標準利用とカスタマイズでプランの考え方が違う
公式プラン案内では、標準機能と一部オプションを利用するスタンダード版と、標準機能をベースにカスタマイズできるエンタープライズ版が示されています。「通販する蔵なら何でも自由に変えられる」と一括りにせず、利用するプランと追加開発の条件を確認します。
標準運用に合わせられる会社と、既存基幹や独自処理を残す必要がある会社では、導入方法が異なります。最初に公式のプラン案内を確認し、変えられる業務と変えられない業務を整理します。
受注・在庫・商品情報をまとめる範囲を確認する
公式機能紹介には、複数モールの受注取り込み、決済連携、メール、帳票、送り状データの入出力が掲載されています。在庫の履歴や発注・仕入、商品情報の登録・CSV更新なども案内されています。
たとえば基幹システムでは売上計上済みの注文が、モール側でキャンセルされた場合、誰がどちらのデータを確認し、どこへ変更を戻すか決めておく必要があります。導入前に店舗ごとに「取り込むデータ」「確認する担当」「戻すデータ」を書き出し、キャンセルや返金など例外注文でも試しましょう。対応する機能の範囲は公式機能紹介から確認できます。
FAQでは、商品マスターがない状態での受注処理と、商品・在庫連動を区別しています。在庫連動まで使う場合は、商品コードやSKUの整備を導入準備に含めます。コードが一致しているように見えても、セット品や色・サイズの違いを混同しないことが重要です。
基幹連携はデータの正本と受け渡しを決める
基幹システムは、社内の販売・仕入・会計などの中心になるシステムです。通販する蔵との連携を検討する際は、商品、価格、在庫、受注、売上について、どちらを正本にするかを項目ごとに整理します。
| 連携対象 | 決めること | 検証する例外 |
|---|---|---|
| 商品情報 | 商品コード、必須項目、更新元 | 新SKU、終売、セット構成変更 |
| 価格 | 通常価格と店舗別価格の優先 | 期間価格、値引き、更新失敗 |
| 在庫 | 販売可能数と確保済み数量の扱い | 棚卸差異、返品、不良品 |
| 受注 | 取り込み、変更、処理状態の対応 | キャンセル、分割、住所不備 |
| 出荷 | 倉庫指示と実績・追跡情報の返却 | 一部出荷、欠品、再送 |
| 売上 | 計上の基準日と金額項目 | 返品、送料、手数料、値引き |
同じ「連携」という言葉でも、CSVによる受け渡しとAPIによる処理では、運用や停止時の対応が違います。更新頻度、失敗の通知、再実行、二重登録を防ぐ方法まで要件に含めます。個別仕様の対応可否は開発側と確認し、未確認の接続を可能と断定しないようにします。
実店舗と自社倉庫はオプションも含めて考える
公式には、実店舗向けPOSの「レジする蔵」と、自社倉庫管理の「ロジする蔵」が紹介されています。店舗とECの在庫共有や、倉庫の入荷・検品・棚卸し・出荷などを含めた運用を検討するための選択肢です。
既存のPOSやWMSをそのまま接続する場合と、これらのオプションを導入する場合では、機器・費用・移行の範囲が変わります。スマートフォンやバーコード機器を利用する場合も、自社の作業場所と読み取り対象で確認します。詳細は公式オプション紹介をご覧ください。
費用は初期・追加開発・運用後に分ける
プランごとの料金と、カスタマイズを含む個別見積を分けて確認します。FAQに記載された初期費用を、すべてのプランや追加開発込みの価格として読み替えないようにします。基本環境、設定支援、移行、オプション、追加開発、月額利用、機器などを見積の項目で確認してください。
また、最初に合意した仕様の不具合修正と、後から増えた要望は区別されます。サービス側・モール側の仕様変更、バックアップからの復旧、追加店舗への対応も含め、運用後に費用が発生する条件を確認します。判断材料は公式FAQで確認できますが、契約時点の回答と見積を優先します。
カスタマイズ要望は画面より業務条件で伝える
「このボタンを作ってほしい」だけでは、なぜ必要なのか、どの注文に適用するのかが伝わりません。発生条件、入力情報、現在の手順、期待する結果、例外、担当者を整理して相談します。
公式のカスタマイズ事例は検討材料になりますが、他社向けの仕様がそのまま標準で利用できるとは限りません。自社の要件へ置き換え、受け入れテストで何を確認すれば完了かを決めます。必要以上に独自処理を増やさず、運用をそろえることで解決できる課題も分けておくと、保守範囲を見通しやすくなります。
切り替えはデータ整備と試験の時間を確保する
独自連携を含む場合は、契約後すぐに使い始められる前提で計画しないようにします。商品コード、店舗別の設定、移行データ、通常注文と例外注文の試験を準備し、誰が確認するかを決めます。
少人数の会社では、社内で要件整理と検証に使える時間があるかを先に確認します。基幹や倉庫の担当が別にいる会社は、双方の変更予定と問い合わせ窓口を共有します。新旧システムで二重に出荷指示が出ない切り替え方法や、停止時の手順も必要です。
古いFAQには過去のモール名や開発中の連携が残る場合があります。サービス名が記載されているだけで、現在の受注・在庫・商品・出荷のすべてに対応すると解釈せず、利用予定の機能単位で現行の対応表と回答を確認してください。
まとめ
通販する蔵を検討するときは、標準利用とカスタマイズを分け、基幹・POS・倉庫との接続要件を先に整理します。導入費用だけでなく、データ整備、検証、運用後の変更まで含めて、自社の体制で維持できる構成を選びましょう。
受注・在庫・物流の業務整理にはEC運営・販売促進ガイド、OMS・WMSなどの意味の確認にはEC用語集をご利用ください。
掲載情報の確認日：2026年9月3日。機能・料金・画面は変更される場合があるため、利用時は最新の公式案内をご確認ください。
