9分

EコマースとERPの連携：在庫は2か所で同時に正しい状態にはなり得ません

2026/08/13

EコマースとERPの連携：在庫数は2つの場所で同時に正確であることはできません

同じ商品が、自社ストアでは12個、マーケットプレイスでは8個、倉庫では5個と表示されている場合、これは連携の不備ではありません。通常、どのシステムの在庫数を正しいものとみなすかを明確に決めずに設計された連携に起因するものです。

統合を構築する前に、各データタイプに1つの「所有者」を割り当ててください。所有者とは、そのデータを変更することが許可されている唯一のシステムであり、それ以外のシステムはデータを読み取るのみです。

在庫 → ERP。 商品は倉庫にあり、倉庫の記録はERPに保存されています。店舗やマーケットプレイスはERPから在庫情報を読み取りますが、決して変更することはありません。
価格 → ERP。 チャネルごとの価格設定は問題ありませんが、価格設定のルールは一箇所にまとめるべきです。
商品データ → ERP または商品情報システム。 コード、単位、重量などの技術的な項目は ERP に、画像やマーケティング用コピーはストアフロントに配置しても構いません。
注文 → チャネル。 注文はチャネルで発生し、ERP に流れ込みます。ERP は注文を履行しますが、注文内容自体を変更することはありません。
顧客 → ERP。 顧客アカウントの一意性はERPで管理されます。

双方向の在庫同期機能は構築しないでください。店舗とERPの両方で在庫を変更できる設計の場合、同時に行われた更新が互いに上書きし合い、どちらが優先されるかは予測できません。

予約在庫です。 注文済みですが、まだ出荷されていません。これは販売可能在庫から差し引く必要があります。そうしないと、同じ商品が二重に売れてしまうことになります。在庫が数点しか残っていない場合、これは重大な問題となります。

安全在庫です。 すべてのチャネルに全在庫を公開すると、同期の遅延時に過剰販売が発生する恐れがあります。売れ行きの良い商品については、少量の安全在庫を確保するのが一般的な慣行です。

複数の倉庫です。 複数の拠点から出荷する場合、どの販売チャネルがどの倉庫から商品を引き出すかを定義する必要があります。総在庫を単一のプールとして表示すると、出荷計画が破綻してしまいます。

同期頻度。 イベント駆動型の更新が理想的ですが、マーケットプレイスのAPI利用制限に抵触する可能性があります。実用的な妥協案として、重要な商品については即時更新、それ以外の商品については定期的な更新を行うことが挙げられます。

顧客の照合： 同一の顧客が異なるチャネルを通じて注文した場合、1つのアカウントとして扱われるのでしょうか？メールアドレスや電話番号に基づく照合ルールを定義する必要があります。
送料およびサービス料： これらはERPに明細行として反映される必要があります。そうしないと、注文総額と請求書の金額が一致しなくなります。
手数料および控除： マーケットプレイスの手数料はコストとして計上する必要があります。そうしないと、チャネルごとの収益性を算出できません。
返品およびキャンセル： 最も頻繁に見落とされがちなフローです。返品時には、在庫を元に戻し、アカウントにクレジットを作成する必要があります。
部分出荷： 注文の一部のみが出荷された場合、チャネル側のステータスを更新する必要があります。

連携の失敗：APIのタイムアウト、クォータの超過、予期しないフォーマットなど。重要なのは、失敗が決して起こらないことではなく、失敗が黙って見過ごされないことです：

失敗した操作はキューに入れられ、自動的に再試行されます。
設定された試行回数を超えると、アラートが発報されます。
エラーメッセージは分かりやすいものになります。「マーケットプレイスで商品コードが見つかりません」といった形で、「500 Internal Server Error」のような曖昧な表示にはなりません。

自動化すべきヘルスチェック：週に1回、ERP、店舗、マーケットプレイスにまたがるランダムに選ばれた20商品の在庫数量を比較します。不一致の数が、統合の真の健全性を示す指標となります。