WMS在庫同期の設計パターン2026｜OMS連携でズレをゼロにする実装手順と運用KPI

WMS-OMS在庫同期の3つの連携方式

WMSとOMSの在庫同期には大きく3つの方式があります。自社の出荷規模・技術リソース・利用するシステムの組み合わせによって、適切な方式は異なります。

① API連携（双方向リアルタイム）

WMSとOMSがREST APIやWebAPIで直接通信し、在庫変動をリアルタイムで相互反映する方式です。API連携では受注確定時の引き当て処理、出荷完了時の在庫減算、入荷時の在庫加算が自動で行われます。月商1,000万円以上・取扱SKU数が500以上・マルチモール運営の事業者に適しています。開発工数は高くなりますが、在庫精度がもっとも高く、機会損失・過剰販売の両リスクを最小化できます。

② Webhook連携（イベント駆動・準リアルタイム）

出荷完了・入荷確定などの「イベント」発生をトリガーに、WMSからOMSへ在庫データをプッシュ送信する方式です。常時ポーリングが不要なためサーバー負荷が低く、API連携とCSV連携の中間として位置づけられます。Shopifyや一部のOMSが標準でWebhookをサポートしており、月商300万〜1,000万円規模の事業者が導入しやすい方式です。

③ CSV連携（定時バッチ）

WMSが定時（毎時・毎日など）に在庫CSVを出力し、OMSが取り込む方式です。API連携と比較してリアルタイム性は劣りますが、システム開発不要でほぼすべてのOMSが対応しており導入障壁が低いのが特徴です。出荷頻度が低い・SKU数が少ない・単一モール運営の事業者や、まず発送代行に切り替えてから段階的にシステム高度化を図るフェーズに適しています。

リアルタイム同期 vs バッチ同期の選定基準

どちらの同期方式を選ぶかは、日次出荷件数・取扱SKU数・連携モール数・在庫バッファ（安全在庫）の水準という4指標を基に判断します。

リアルタイム同期が必要なケース

以下のいずれかに該当する場合、CSV連携のバッチ周期（最短でも毎時1回）では在庫ズレリスクが高く、API/Webhook連携を選定すべきです。

• 日次出荷件数が200件超——1時間あたり平均8件以上の出荷が発生すると、次のバッチ実行までの1時間に累積する在庫変動が無視できなくなります。
• 3モール以上で同一SKUを販売している——複数モールで同じ在庫を共有する場合、バッチ周期中に複数モールで同時注文が入ると過剰販売が発生します。
• 安全在庫が5個以下のSKUが全体の30%超——バッファが薄いほど同期遅延による欠品・過剰販売のリスクが高まります。

バッチ同期で十分なケース

月商500万円未満・単一モール・取扱SKU数が200以内・安全在庫を10個以上確保できているなら、まずCSV連携でスタートし、事業拡大に合わせてAPI連携に移行する段階的アプローチが合理的です。発送代行への切り替えと同時にシステム刷新すると変数が増えて問題の切り分けが難しくなるため、まず発送代行に切り替えてCSV連携で安定稼働を確認し、その後API連携に移行する順序を推奨します。

経済産業省「令和6年度 電子商取引に関する市場調査」によると、物販系BtoC-ECの市場規模は14兆6,760億円（前年比6.86%増）に達しており、EC事業者の出荷量増加とシステム高度化への投資需要は継続して拡大しています。

出典：経済産業省「令和6年度 電子商取引に関する市場調査」（2025年8月）

在庫ズレが発生する5つの原因と根本対策

WMS-OMS間で在庫同期を設定していても「なぜか数字が合わない」状況が続く場合、以下の5原因を体系的に確認します。

原因①：同期タイミングのズレ（レイテンシ）

CSV連携では「WMSが在庫CSVを出力する時刻」と「OMSが取り込む時刻」の間にタイムラグが生じます。このラグ中に注文が入ると在庫が正確に反映されません。対策は同期周期を短縮するか（毎時→毎30分→毎10分）、API/Webhook方式に切り替えることです。

原因②：キャンセル処理の非同期

受注後のキャンセルがOMSでのみ処理されWMSに伝達されないと、WMS側では引き当て済みのまま在庫が拘束されます。OMSのキャンセル処理フローにWMS向けの在庫戻し通知が含まれているかを確認し、含まれていない場合は手動戻し運用かAPI拡張で対処します。

原因③：返品在庫の区分管理の欠如

返品品を検品なしで即座に「販売可能在庫」に戻すと、品質不良品が出荷される可能性があります。入庫処理と同様に、返品品は「要検品在庫」として別区分で管理し、検品合格後に販売可能在庫へ移動するフローを設計します。

原因④：WMS内の複数ロケーション間の移動漏れ

保管棚間のロット移動や流通加工後の仕掛品がWMS上で「未確定状態」のまま残ると、実在庫と帳簿在庫が乖離します。WMSのロケーション移動は完結まで確定操作を行い、仕掛品は専用ステータスで管理する運用ルールが必要です。

原因⑤：マスタデータの不整合（SKUコード体系の差異）

WMSとOMSで同じ商品に異なるSKUコードが付与されていると、在庫データを突合できません。SKU設計段階でWMS・OMS・各モール間のコード体系を統一するか、連携テーブル（マッピングテーブル）を整備して変換処理を挟みます。

国土交通省「総合物流施策推進プログラム」では、物流DX・データ連携の推進を重点施策として位置づけており、WMS・OMS間のシステム連携による在庫可視化は物流効率化の基盤と明記されています。

出典：国土交通省「総合物流施策推進プログラム」

発送代行WMS連携の実装手順

発送代行に在庫を預けてWMSを利用する場合、以下の手順で連携設定を進めます。STOCKCREWではネクストエンジン・Shopify・楽天RMS・Yahoo!ショッピング等の主要プラットフォームとの連携に対応しています。

Step 1：SKUマスタの整備と棚割り設計

連携開始前に、取り扱うすべての商品についてSKUコード・JANコード・商品名・サイズ・重量・保管区分を発送代行側に提出します。SKUコードはOMS・モール・WMSで統一することが前提です。棚割りは発送代行側が設計しますが、ピッキング効率に影響するため出荷頻度の高いSKUと低いSKUの区分情報を事前に共有しておくと精度が上がります。

Step 2：連携方式の選定とテスト環境構築

利用するOMSが対応する連携方式（API/Webhook/CSV）を確認します。ネクストエンジンのAPI連携を使う場合は、ネクストエンジンの開発者向けドキュメントに従ってAPIキーを発行し、サンドボックス環境でテスト連携を実施します。本番移行前に以下のテストシナリオを必ず通過させます。

1. 入荷テスト——テスト商品を発送代行倉庫に入荷し、OMS側の在庫数が正しく加算されるか確認
2. 出荷テスト——テスト注文を処理し、出荷完了後にOMS在庫が正しく減算されるか確認
3. キャンセルテスト——出荷前キャンセルを処理し、WMSの引き当て解除とOMS在庫の戻しが連動するか確認
4. 在庫差異テスト——意図的にOMS在庫を手動変更し、次の同期サイクルで正しく上書きされるか確認

Step 3：並行稼働期間の設定

本番移行後、最初の2〜4週間は旧システム（自社出荷）と新システム（発送代行）の在庫数を毎日突合します。差異が発生した場合は即座に原因を特定して修正します。並行稼働を経ずに一気に切り替えると、問題発生時の原因特定が困難になります。

マルチモール・多拠点の在庫同期設計パターン

複数ECモールで同一SKUを販売する場合、在庫同期の設計難易度は急激に上がります。代表的な2つの設計パターンを解説します。

パターンA：単一在庫プール方式

楽天・Amazon・Yahoo!・Shopifyで同じ在庫を共有する方式です。在庫効率が高く欠品リスクが低い一方で、複数モールで同時に注文が入った場合の「在庫競合」を防ぐためリアルタイムAPI連携が必須です。ネクストエンジンなどのOMSが在庫プールを管理し、モールへの在庫数反映・引き当てを一元処理します。

パターンB：モール別在庫分割方式

モールごとに在庫を分割して割り当てる方式です。在庫競合は発生しませんが、分割数が増えるほど各モールの在庫回転が悪化し、資金効率が下がります。楽天のSKUプロジェクト移行後のように在庫管理が複雑化した際の暫定対処として使われるケースが多く、API連携が整備されたら単一在庫プール方式に移行するのが一般的です。楽天出店と発送代行の切り替えを同時に検討している場合は、在庫同期の再設計と合わせて進めると効率的です。

多拠点（複数倉庫）の場合は、WMSが拠点別在庫を集約して論理的な「利用可能在庫」をOMSに渡す設計が必要です。マルチFC戦略を採用する際は、各拠点WMSからの在庫データを集約する「在庫ハブ」レイヤーをOMS上に設けることを推奨します。

在庫同期KPIのモニタリングと異常検知

在庫同期の品質を継続的に担保するには、以下のKPIを週次・月次で追跡します。

在庫精度率（Inventory Accuracy）

在庫精度率 = 帳簿在庫と実在庫が一致するSKU数 ÷ 全SKU数 × 100。業界目標値は99.5%以上が一つの目安です。月1回の棚卸で算出し、99%を下回ったSKUについては原因カテゴリ（ロケーションミス・連携エラー・返品未処理など）を特定します。

在庫同期エラー率

API連携の場合、同期試行回数に対するエラー（タイムアウト・認証失敗・データ不整合）の発生率を記録します。エラー率が0.1%を超える場合はAPI仕様変更・ネットワーク問題・マスタデータ不整合のいずれかが原因である可能性が高く、即座の調査が必要です。

在庫差異発生件数（月次）

「WMS実在庫 ≠ OMS帳簿在庫」が発生したSKU件数と差異量（個数）を月次で集計します。差異の多いSKUを常にトップ10でウォッチし、反復発生するSKUには個別対策を施します。物流KPIの可視化とダッシュボード化により、チームが定期的に在庫品質を確認できる体制を整えます。

経済産業省「DX推進ガイドライン ver.1.2」では、基幹系システムのデータ連携・API整備を「DX推進の前提となるIT基盤」と位置づけており、WMS-OMS間のAPI連携はEC事業者のDX化における最初の実装ステップの一つです。

出典：経済産業省「DX推進ガイドライン」（経産省IT政策）

異常検知の仕組みとしては、在庫数が閾値（安全在庫の50%以下など）を下回った際のアラート通知をOMS側に設定し、担当者がリアルタイムで補充・発注判断できる体制を作ることが重要です。WMSの多くはアラート設定機能を持っており、この機能を活用することで欠品発生前に手を打てます。

まとめ：WMS在庫同期を成功させる3つの条件

WMS-OMS在庫同期の設計において、成功を左右する条件を3点に絞ると以下の通りです。

1. 規模に合った連携方式の選定——月商・SKU数・モール数に応じてCSV/Webhook/APIを正しく選ぶことが出発点です。過剰投資も過少投資も避けるため、現状規模と半年後の見通しを元に判断してください。
2. SKUマスタの統一——どんな連携方式でも、WMS・OMS・モール間のSKUコード体系が統一されていなければ在庫ズレは解消しません。連携設定の前にマスタ整備を完了させることが鉄則です。
3. KPIによる継続モニタリング——設定後は「動いている」と思い込まず、在庫精度率・同期エラー率・差異件数を定期的に計測することで問題の早期発見が可能になります。

発送代行への切り替えは、WMS在庫同期を整備する絶好のタイミングです。倉庫・システム・業務フローを一度に見直すことで、その後の拡張コストを大幅に削減できます。物流システム全体の最適化に向けて、まずは現状の在庫同期方式と精度率の把握から始めてみてください。STOCKCREWの料金・機能詳細やご相談はお問い合わせフォームまたは資料ダウンロードからどうぞ。