EC WMSとは？受注・OMS連携の設計と自社倉庫か3PLかの判断基準

EC WMSとは、ECの受注を起点に、倉庫での入荷・保管・ピッキング・梱包・出荷を管理する倉庫管理システム（WMS）を、ECの小口で多頻度の出荷に合わせて運用する仕組みを指します。本記事では、BtoB向け倉庫のWMSと何が違うのかを整理し、カート・OMS（受注管理システム）・WMS・送り状発行・基幹システムの役割分担を示す構成です。そのうえで、在庫数の正本をどこに置くか、連携の方式と頻度、出荷指示後のキャンセルの扱いという連携設計の3つの論点を解説します。最後に、3PLや発送代行のWMSで足りる条件と、自社WMSや連携開発に進む条件を言い切ります。

まとめ：EC WMSは在庫の正本と出荷指示の締めを決めてから製品を選ぶ

EC WMSの導入でつまずく原因は、製品の機能不足よりも連携の設計不足にあります。モールの在庫表示とWMSの実在庫がずれる、出荷作業に入った注文がキャンセルされて誤出荷になる、といった事故は、どのシステムが在庫数と注文の状態を確定させるかを決めていないまま連携を組んだときに起こります。

先に決めるのは2つです。実在庫の正本はWMSに置き、販売できる在庫数はOMSが受け取ってカートやモールへ返す。出荷指示をWMSへ渡した後のキャンセルは、ピッキング開始前までなら受け付け、それ以降は返品として扱う。この線を引いてから、製品や連携方式を選びます。

1日の出荷が数百件までで、カートと発送代行の標準連携で回るなら、自社でWMSを持つ必要はありません。複数モールと実店舗の在庫を1つにまとめる、基幹システムへ出荷実績を戻す、といった要件が加わった段階で、連携部分の開発を検討します。

EC向けWMSの役割と、BtoB倉庫のWMSと違う小口・多頻度出荷の要件

EC物流の出荷特性、1注文あたり数点の小口出荷と当日出荷の締め時刻

BtoB倉庫の出荷は、取引先の店舗や物流センターへケース単位でまとめて送る形が中心です。ECは逆に、個人宅へ1注文あたり1〜数点を送る小口の出荷が大半を占めます。出荷件数は注文件数とほぼ同じになり、倉庫作業の単位は「ケース」から「注文」に変わります。

量の面でも、個人宅向けの小口配送は大きな規模になっています。経済産業省の令和6年度電子商取引に関する市場調査によると、2024年の国内BtoC-EC市場規模は26.1兆円で前年比5.1%増、BtoC-ECのEC化率は9.8%でした。国土交通省の宅配便等取扱実績の集計では、令和6年度の宅配便の取扱個数は約50.3億個で、対前年度比100.5%と増加が続いています。

ECの倉庫には「午後2時までの注文は当日出荷」のような締め時刻があります。WMSはこの締めに合わせて、注文の取り込み・引当・ピッキングリストの発行を1日に何度も回す必要があり、BtoB倉庫のように1日1回の出荷指示で済む前提とは設計が違ってきます。

EC向けWMSに求める機能、同梱物・ギフト対応・送り状発行と返品処理

WMSの基本機能である入荷・ロケーション管理・ピッキング・棚卸は、WMSとは？倉庫管理システムの機能・在庫管理との違い・導入判断を解説で扱っています。ここでは、ECの出荷で追加で必要になる機能に絞ります。

実務でまず押さえるのは上の2つです。送り状の追跡番号がカートやモールに戻らないと、購入者への発送通知が手作業になります。納品書の入れ違いは誤出荷であると同時に個人情報の漏えいにもなるため、納品書のバーコードと注文番号を照合する工程が必要です。ピッキング方式ごとの照合の組み方はピッキングシステムとは？7方式の比較とWMS連携、選定と開発の判断軸を解説で比べています。

受注からOMS・WMS・送り状・基幹までのEC物流システムの役割分担

カート・モール、OMS、WMS、送り状、基幹ERPが持つデータの範囲

EC物流のシステムは、注文が流れる順に5つの層に分かれます。どの層が何のデータを確定させるかを表にすると、連携の設計で迷う箇所がはっきりします。

事故が起きやすいのは、同じデータを2つの層が確定させようとする箇所です。たとえばカートとWMSの両方が在庫数を持ち、それぞれが更新すると、どちらが正しいのか誰も答えられなくなります。受注側の機能と一元管理の考え方は受注管理システムとは？機能・受発注システムとの違いとEC一元管理・導入判断で整理しています。

OMSとWMSの境界線、引当と出荷指示をどちらで確定させるかの判断

OMSとWMSの境界で最初に決めるのは、在庫の引当をどちらで行うかです。引当とは、注文に対して在庫を確保し、他の注文に回らないようにする処理を指します。

複数の倉庫や実店舗の在庫を持つ場合は、OMSで引当を行い、出荷する倉庫を決めてからWMSへ出荷指示を送る形が向いています。倉庫が1か所なら、WMS側で引当まで行い、OMSは注文の取り込みと状態管理に専念させる構成でも足ります。

どちらの構成でも、引当の責任を持つシステムは1つにしてください。OMSとWMSが別々に引当を行うと、同じ在庫が2つの注文に割り当てられ、欠品による出荷遅れが起きます。受注引当と出荷引当の違いや、有効在庫の計算式は在庫引当とは：受注引当と出荷引当の違い、有効在庫の計算と引当解除・欠品時の配分をSQLで実装で実装例とともに扱っています。

EC WMS連携の設計で決める在庫の正本・連携の頻度・キャンセルの扱い

在庫数の正本をWMSに置き、販売可能数をOMS経由でモールへ返す流れ

実在庫の正本はWMSに置きます。棚に何個あるかを確定できるのは、入荷検品や棚卸の結果を持つ倉庫側だけだからです。

ただし、WMSの実在庫をそのままモールに表示してはいけません。実在庫から、引当済みの数・出荷指示済みの数・不良品や検品待ちの数を差し引いた「販売可能数」を計算し、OMSを通して各モールへ配る流れにします。複数モールに同じ在庫を出す場合は、モールごとに安全在庫を引いて表示する設計も必要です。モール横断の在庫同期ツールの類型と選び方はEC在庫管理システムとは？多店舗の在庫連携・受注同期の機能と費用・選び方を解説にまとめています。

在庫数の更新が一方向に流れているかを確かめる方法は簡単です。カートの管理画面で在庫数を手で書き換えたとき、その数がWMSに戻る経路があるなら、正本が2つある状態です。

連携方式の比較、CSV定時取込・API・Webhookの遅延と障害時の戻し方

カート・OMS・WMSのつなぎ方は、大きく3つの方式に分かれます。

即時性だけで選ぶと失敗します。Webhookは速い反面、受け手の停止中に届いた通知を取りこぼすことがあるため、APIでの定期的な突き合わせと組み合わせて使うのが前提です。Shopifyの例では、Shopifyのフルフィルメントサービス向け開発ドキュメントによると、外部の倉庫側システムは出荷依頼を通知で受け取る一方、在庫数はShopifyが倉庫側へ1時間ごとに全件を問い合わせる仕組みになっています。通知と定期取得を役割で分けた設計の一例です。

月商が小さく注文も1日数十件なら、CSVの1日数回の取込で困ることはありません。売り越しが月に何件出ているかを数え、件数が無視できなくなってからAPI連携に移る順番で十分です。

出荷指示後のキャンセル・住所変更を止める締め処理と状態遷移の設計

ECでは、出荷指示を倉庫へ送った後に購入者からキャンセルや住所変更の連絡が届きます。このとき、倉庫がどこまで作業を進めていたら受け付けを断るのか、という締めのルールを決めておかないと、キャンセル済みの注文が出荷されます。

Shopifyの同ドキュメントでは、この流れが注文の状態として定義済みです。倉庫側システムは出荷依頼（FULFILLMENT_REQUEST）を受けて fulfillmentOrderAcceptFulfillmentRequest で受諾すると、その注文は作業中（IN_PROGRESS）になります。後からキャンセル依頼（CANCELLATION_REQUEST）が届いた場合、倉庫側は受諾して取り消すか、fulfillmentOrderRejectCancellationRequest で拒否して作業中のまま出荷を続けるかを選べます。

この「倉庫側がキャンセルを拒否できる」設計は、自社で連携を組む場合にも取り入れるべき考え方です。目安としては、ピッキングリストを発行する前ならキャンセルを受け付け、発行後は拒否して出荷し、届いてから返品として処理します。住所変更も同じ締めで扱い、送り状の発行後は配送会社側の転送に切り替える運用にすると、倉庫の作業を止めずに済みます。

自社倉庫でWMSを持つか3PL・発送代行のWMSを使うかの判断基準

3PL・発送代行のWMSで足りるEC事業者の出荷件数とSKUの条件

次の条件にすべて当てはまるなら、自社でWMSを持たず、3PLや発送代行の会社が使っているWMSに乗る形で足ります。

• 販売チャネルが自社カートと1〜2のモールで、委託先に標準の連携がある
• 在庫を置く倉庫が委託先の1か所で、実店舗との在庫共有がない
• 出荷実績は月次の集計で会計に入れており、日次で基幹へ戻す要件がない

この形なら、在庫の正本は委託先のWMSになり、自社はOMSやカートの管理画面で在庫と出荷状況を見るだけで済みます。委託先を選ぶときは、使っているカートやモールとの連携が標準で用意されているか、追跡番号がいつ戻るかを確認してください。3PLへの委託と自社でWMSを持つ判断の全体像は3PLとは？意味と4PLとの違い、メリット・デメリットと自社WMSとの判断基準で解説しています。

自社WMSや連携開発に進む条件と、パッケージを入れても失敗する例

自社倉庫を持ち、複数モールと実店舗の在庫を1つにまとめる場合や、出荷実績を日次で基幹システムへ戻して売上と原価を確定させる場合は、委託先の標準連携では足りません。カートの数が増えるたびに連携の設定が増え、どこかの在庫数がずれても原因を追えなくなるからです。この段階では、WMSの製品選びと並行して、OMS・WMS・基幹の間で在庫と注文の状態をどう渡すかを設計し、足りない連携部分を開発します。既存のWMSや販売管理を残したまま連携だけを組み直す場合も含め、一創の物流システム開発で、現在の受注から出荷までの流れの棚卸しからご相談いただけます。

見送るべき場面もはっきりしています。在庫の正本と引当の担当を決めないまま高機能なWMSパッケージを入れても、カート側で在庫を手で直す運用が残り、ずれは解消しません。1日の出荷が数十件で、売り越しが月に数件なら、WMSの導入よりもカートとOMSの在庫連携を見直す方が先です。製品タイプごとの費用の目安はWMSの比較｜製品タイプ別の選び方と費用相場、受託開発を選ぶ判断軸を参考にしてください。

よくある質問

EC事業者がWMSを検討するときによく出る疑問に答えます。

EC事業者にWMSは必要ですか？

1日の出荷が数十件までで、倉庫も1か所なら、カートやOMSの在庫管理機能と送り状発行ソフトで回ります。WMSが必要になるのは、出荷件数が増えて紙のピッキングリストでは誤出荷が減らなくなったとき、SKU数が増えてロケーション管理なしでは商品を探せなくなったとき、複数モールの在庫を倉庫の実在庫と合わせる必要が出たときです。発送代行に委託している場合は、委託先のWMSを使う形になります。

WMSとOMSの違いは何ですか？

OMS（受注管理システム）は、カートや各モールから届く注文を1か所に集め、決済の確認や引当、出荷指示の作成までを担います。WMS（倉庫管理システム）は、出荷指示を受けて倉庫の中での作業、つまりピッキング・検品・梱包・出荷と、実在庫やロケーションを管理するシステムです。注文の状態を確定させるのがOMS、棚にある在庫の数を確定させるのがWMS、と分けると混同しません。

WMSとECカートはどのように連携しますか？

多くはOMSを間に挟み、カートの注文をOMSが取り込んでWMSへ出荷指示を送り、WMSから出荷実績と追跡番号が戻る流れになります。方式はCSVの定時取込、APIの定期取得、Webhookによる通知の3つです。即時性の高いWebhookは取りこぼしに備えてAPIでの定期的な突き合わせと組み合わせ、在庫数はWMSを正本として一方向に流すように設計します。

3PLに委託している場合でも自社でWMSを持つべきですか？

委託先が1か所で、使っているカートやモールとの標準連携が用意されているなら、自社でWMSを持つ必要はありません。委託先のWMSが在庫の正本となり、自社は管理画面で在庫と出荷状況を確認します。複数の委託先や自社倉庫に在庫を分けて持つ場合や、出荷実績を日次で基幹システムに戻す場合は、委託先のWMSとは別に、在庫と注文を束ねるOMSや連携の仕組みを自社側に用意します。

出荷指示を出した後のキャンセルはどう扱えばよいですか？

倉庫の作業の進み具合で受け付けの可否を決めます。ピッキングリストを発行する前ならキャンセルを受け付けて出荷指示を取り消し、発行後は拒否して出荷し、届いてから返品として処理する運用が一般的です。この締めをシステム上の状態として持たせておくと、キャンセル済みの注文が出荷される事故を防げます。Shopifyのように、倉庫側がキャンセル依頼を拒否できる仕組みを公式に用意しているプラットフォームもあります。

関連記事

• 物流のデータ連携｜社内WMS・TMSと企業間EDIの二層設計と標準への寄せ方：社内のWMS連携と取引先とのEDIを分けて設計する考え方をまとめています。
• 倉庫管理システムは中小企業に必要か｜規模別の適合条件と段階導入の進め方：小規模なEC事業者がWMSを段階的に入れる進め方を扱っています。