この記事では、複数モールの在庫を連携する考え方、受注から出荷までのデータの流れ、倉庫在庫と販売在庫を分ける方法、導入前に整理すべきマスターと運用ルールを解説します。すでにExcelや個別の管理画面で運用している企業が、どこから整理し、どの機能を連携すべきか判断するための内容です。
この記事で分かること
- EC在庫管理で連携するモール、受注、倉庫、出荷のデータ
- 商品コードと在庫区分をそろえて販売可能数を計算する方法
- 受注、引当、出荷、キャンセル、返品を在庫へ反映する考え方
- API連携、ファイル連携、手入力を使い分ける際の確認ポイント
- 導入前の業務整理と、段階的に連携を広げる進め方
EC在庫管理とは
EC在庫管理は、オンラインで販売する商品の数量と状態を記録し、受注や出荷の結果を販売チャネルへ反映する業務です。対象は現在庫だけではありません。倉庫に到着して検品が終わっていない商品、注文に割り当てた商品、出荷作業中の商品、返品された商品など、販売可否が異なる数量を区別して扱います。
たとえば倉庫に100個あり、そのうち20個が未検品、30個が受注済み、5個が破損品であれば、販売画面へ100個と表示することはできません。販売可能在庫を45個とするのか、出荷作業の余裕を考えて安全在庫を差し引くのかは、商品の特性と出荷体制によって決まります。EC在庫管理の目的は、すべての数字を同じ画面に集めることではなく、注文を受けられる数量を一貫したルールで算出することです。
モールが一つだけで、注文数も少ない時期は、管理画面への入力や簡単な表計算で対応できる場合があります。しかし販売先が増えると、同じ商品を複数の画面で販売するため、更新の遅れが欠品や過剰受注につながります。店舗販売や卸売も同じ在庫から引き当てる場合は、ECだけの数字を管理するのではなく、全販売先を含めた在庫の基準を定める必要があります。
在庫連携が必要になるタイミング
連携の必要性は、モール数よりも業務の重なりで判断します。複数の販売チャネルで同じSKUを扱う、受注後に倉庫や外部の物流会社へ出荷指示を渡す、予約商品と通常商品を同じ画面で受け付ける、といった条件が重なるほど、手作業の転記がボトルネックになります。担当者が毎日各管理画面を確認し、注文数を集計して在庫数を入力しているなら、仕組みを見直す候補です。
目安として確認したいのは、在庫更新にかかる時間、更新漏れの回数、注文を受けてから出荷指示を作るまでの時間、在庫差異の調査に要する時間です。これらを一週間から一か月ほど記録すると、連携によって減らせる作業と、仕組みを変えても残る作業を切り分けやすくなります。連携製品を先に決めるより、どの作業で情報が止まり、どの遅れが売上や顧客対応に影響するかを確認することが大切です。
複数モールと倉庫在庫を連携する仕組み
複数モールを連携する場合、中心に共通の在庫管理データを置き、各チャネルから受注を取り込み、在庫の変動を計算し、販売可能数を各チャネルへ返します。モールAの在庫をモールBへコピーするだけではなく、全チャネルの受注を集計したうえで残数を配信する点が重要です。倉庫が複数あるときは、倉庫別の在庫を合算して配信するのか、特定倉庫の在庫だけを販売対象にするのかも決めます。
一般的な流れは、商品マスターを照合する、受注を取り込む、在庫を引き当てる、販売可能数を算出する、モールへ在庫を更新する、倉庫へ出荷指示を送る、出荷実績を受け取る、という順序です。すべての処理を一度に自動化できない場合でも、受注の取り込みと在庫の更新だけを先に整え、出荷指示はファイル連携から始める方法があります。
連携方式を選ぶ
連携方式には、APIでリアルタイムに送受信する方式、決まった形式のCSVを定期的に取り込む方式、担当者が画面を確認して入力する方式があります。APIは注文や出荷の反映を早くできる一方、認証情報、エラー時の再送、仕様変更への対応が必要です。CSVは既存の倉庫や会計システムと接続しやすい反面、出力と取り込みの間に時間差が生じます。
連携方式は、速ければよいという基準だけで選びません。販売チャネルの更新頻度、倉庫の作業時間、注文の集中する時間帯、障害時の手動切替、担当者がエラーを確認できるかを合わせて評価します。少量の商品を一日数回更新する業務であれば、安定したCSV連携のほうが運用しやすいこともあります。大量注文の受付中に数分単位で在庫が変わるなら、在庫更新の頻度と排他処理をより厳密に設計します。
連携エラーを前提にする
外部サービスとの通信は、常に成功するとは限りません。モールのメンテナンス、認証期限切れ、項目の形式違い、ネットワークの一時的な切断などが起こります。失敗した注文を消して再取り込みするのではなく、受信済み、処理中、完了、要確認、再送待ちといった状態を残すことが必要です。同じ注文を二重に登録しないため、モール側の注文番号を重複チェックに使います。
在庫更新に失敗した場合は、最後に成功した時刻、対象商品、送信した数量、相手側の応答、再送結果を確認できるようにします。担当者がエラー一覧を見て判断できる画面があれば、システム担当者を呼ばずに一次対応できます。自動再送は便利ですが、数量の状態が変わったまま古いデータを送り直す危険もあるため、再送前に現在の販売可能数を再計算する設計が安全です。
商品コードと在庫区分を統一する
在庫連携で最初に問題になりやすいのは、商品名ではなく商品を識別するコードです。モールごとに商品番号やバリエーション番号が異なると、同じ商品を別のものとして取り込んだり、サイズ違いの在庫を誤って合算したりします。社内の代表SKUを定め、モールの商品ID、商品ページ、バリエーション、倉庫の商品コードを対応表で管理します。
セット商品や選択肢付き商品も、単純な一対一の対応にならないことがあります。セット商品を一つ販売すると、構成品を一単位ずつ減らすのか、セット用の在庫を別に持つのかを決めます。色やサイズを組み合わせた商品は、親商品と子SKUを分け、受注時に減らす在庫の単位を明確にします。コードの変換を担当者の記憶に任せると、新商品を登録するたびに連携ミスが発生するため、登録申請と確認の手順もマスター管理の一部にします。
販売可能在庫の計算
販売可能在庫は、一般に倉庫に存在する数量から、販売対象外の数量と他の注文へ確保した数量を差し引いて計算します。実際の式は業務によって異なりますが、「現在庫」「引当済み」「出荷待ち」「検品中」「返品確認中」「安全在庫」「入荷予定」といった項目の意味を決めておく必要があります。入荷予定を販売可能数に含める予約販売では、到着遅延時の案内や上限数量も別途管理します。
| 項目 | 意味 | 確認すること |
|---|---|---|
| 現在庫 | 倉庫や店舗に物理的に存在する数量 | 検品前・破損品を含むか |
| 引当済み | 受注などにより確保した数量 | キャンセル時に戻す条件 |
| 販売可能在庫 | 新しい注文へ割り当てられる数量 | 安全在庫と倉庫別の配分 |
| 入荷予定 | 仕入れや製造から到着する予定数量 | 予約販売に使うか、納期を表示するか |
安全在庫を設定する場合は、全商品に同じ割合を掛ける方法が必ずしも適していません。出荷頻度、補充にかかる日数、仕入先の納期、欠品時の影響を基準に、商品群ごとのルールを作ります。安全在庫は売らないための在庫なので、担当者が意味を理解しないまま数値だけ入力すると、売れる商品まで販売停止になる可能性があります。設定値の根拠と見直し日を残しましょう。
受注から出荷までのデータをつなぐ
受注を取り込んだら、決済状況、出荷先、配送方法、商品、数量、希望日、同梱の有無などを確認し、出荷できる注文と保留する注文を分けます。決済確認前に在庫を引き当てるか、確認後に引き当てるかは、支払い方法と販売方針に合わせて決めます。取り込み時点で在庫を減らすのか、引当時点で販売可能数を減らし、出荷確定時に現在庫を減らすのかも、帳尻を合わせるために明文化します。
倉庫へ渡す出荷指示には、受注番号、商品コード、数量、配送先、配送指定、ロットや期限の条件を含めます。倉庫側で別のコードを使用している場合は、受注システムから変換後のコードを出力し、作業者が毎回読み替えなくて済むようにします。ピッキング完了と出荷完了を分ければ、作業中の注文を確認でき、問い合わせに対して現在の状態を説明できます。
キャンセルと返品を別の取引として扱う
キャンセルは、受注前、引当後、ピッキング後、出荷後で処理が変わります。引当前のキャンセルは受注を無効にするだけで済む場合がありますが、引当後は確保数量を戻し、倉庫で作業中なら出荷指示の取消を伝える必要があります。出荷後の受取拒否や返品は、戻ってきた商品を検品してから販売可能在庫へ戻す運用にします。
履歴上は、元の注文を消去せず、キャンセル、返品受付、返品検品、再入庫、交換品出荷などの取引を追加します。これにより、注文数と在庫の増減が合わない理由を追跡できます。モールから返されるステータス名と社内の状態名が異なる場合は、対応表を持ち、未知のステータスを自動で完了扱いにしないことが重要です。
倉庫在庫とEC在庫の差異を減らす
販売画面の在庫数と倉庫の実棚数が合わない原因は、システムの計算だけとは限りません。入荷した商品が検品待ちのまま登録されていない、返品品を棚へ戻したが再入庫していない、出荷したが実績が連携されていない、棚卸し後の調整が販売側へ届いていないなど、現場の状態と記録の時点がずれていることがあります。
差異を減らすには、在庫が動く場所とタイミングを洗い出し、必ず記録する取引を決めます。入荷、棚入れ、ロケーション移動、引当、ピッキング、出荷、返品、廃棄、棚卸しを一続きの履歴として保存し、誰がいつ処理したかを確認できるようにします。帳簿上の数量を直接上書きして合わせる方法は、短期的には便利でも原因を隠してしまうため、理由付きの調整取引に置き換えます。
棚卸しと在庫同期の運用
棚卸し中も受注や出荷が続く場合は、作業対象を一時的に販売停止にする、カウント時刻の取引を分ける、差異確定後に同期するなどのルールが必要です。全商品を一斉に止められない場合は、倉庫や商品群ごとに棚卸しの時間帯を決めます。カウントした数量だけでなく、システム数量、差異、理由、承認者を残すと、次回の棚卸しで重点的に確認する場所が分かります。
在庫同期は、定期実行の結果を確認するだけでなく、手動で再同期できる仕組みも用意します。全商品を再送する操作は負荷や誤更新のリスクがあるため、商品、モール、倉庫、期間などの条件を指定できるようにします。同期前後の値をログに残し、店舗や卸売の在庫も含めて同じ基準で説明できる状態を目指します。
EC在庫管理システム導入の進め方
導入を成功させるには、最初からすべてのモールと業務を連携しようとせず、在庫差異と手作業が大きい流れから着手します。現状の業務を図にし、モール、受注、在庫、倉庫、配送、会計のどこでデータが発生し、どこへ渡るかを整理します。担当者ごとに異なる手順がある場合は、例外も含めて記録します。
次に、商品マスターの重複や未使用コード、在庫の区分、倉庫ごとの管理単位を確認します。データが整っていない状態で連携だけを自動化すると、誤った商品や数量を速く配信することになります。開発や製品選定の前に、現行データの棚卸しとサンプル受注の確認を行うと、必要な変換処理が見えやすくなります。自社の状況に応じた整理方法は、開発前診断・ロードマップで検討できます。
段階導入の例
第一段階では、代表的な商品群と一つのモールを対象に、商品コードの照合、受注取り込み、在庫更新、出荷実績の反映を確認します。手作業が残る部分を明記し、担当者がどの画面で何を確認するかを決めます。テストでは正常な注文だけでなく、同時注文、キャンセル、欠品、分納、返品、連携エラーを含めます。
第二段階では、他のモールや倉庫を追加し、在庫配分と優先順位を確認します。すべての倉庫から出荷できるとは限らないため、配送地域、在庫の保管条件、出荷締め時間などを使って出荷先を決める場合があります。第三段階で、予約販売、セット商品、店舗在庫、卸売在庫、発注や入荷予定との連携を広げます。段階ごとに、在庫差異、手作業時間、エラー解消時間を比較し、次の対象を判断します。
担当者と例外処理を決める
自動連携を導入しても、例外がなくなるわけではありません。新商品の登録、価格変更、販売停止、納期変更、商品統合、モールの仕様変更などは、担当者が判断して処理します。エラーを誰が確認し、何分以内に一次対応し、解決しない場合に誰へ連絡するかを決めておくと、トラブル時の迷いを減らせます。
運用手順には、通常時の操作だけでなく、通信が止まったときの受注確認、在庫を一時的に絞る方法、手動で出荷する場合の二重登録防止、復旧後の再同期方法も含めます。連携先が増えるほど、システム担当者だけでは現場の判断を代替できません。EC担当、倉庫担当、受注担当、管理者が同じ用語で状態を確認できるよう、画面の表示名と手順書をそろえます。
社内だけで要件を整理しきれない場合は、お問い合わせ窓口で現在の運用と困りごとを共有し、必要な範囲から相談を始める方法もあります。
自社の管理方法を見直し、必要な機能を小さく整理したい場合は、在庫管理システムの相談ページで対象業務を確認できます。費用や開発期間を比較するときも、モール数だけでなく、商品マスターの変換、倉庫との連携、エラー対応、権限管理、保守の範囲まで含めて検討します。
EC在庫管理で起きやすい失敗
よくある失敗は、在庫連携を始める前に商品マスターを整理しないことです。モールの商品登録を担当者ごとに行い、SKUの命名規則が異なると、同じ商品の在庫が分散します。登録時に代表SKU、バリエーション、販売単位、倉庫コード、販売停止フラグを確認する台帳を用意し、変更履歴を残しましょう。
次に、在庫更新の成功だけを確認し、受注と出荷の状態を追跡しない失敗があります。モールの在庫が更新されても、倉庫へ出荷指示が届かなければ注文は完了しません。受注番号を軸に、受信日時、引当日時、出荷指示日時、出荷実績日時、モールの発送通知日時を確認できるようにします。
もう一つは、連携を一度作れば保守が不要だと考えることです。モールの項目追加、配送会社の変更、倉庫の拠点追加、販売単位の変更があれば、変換ルールやテストも見直す必要があります。月次でエラー件数と在庫差異を確認し、四半期などの間隔で商品マスターと権限を点検すると、運用の変化を仕組みに反映できます。
よくある質問
小規模なECでも在庫連携は必要ですか？
モールが一つで商品数も少ない場合は、手入力や定期的なCSV更新で足りることがあります。ただし、店舗販売や卸売と同じ在庫を使う、注文が特定の時間帯に集中する、担当者が不在になると出荷できない、といった条件があるなら、早い段階で商品コードと在庫区分を整理しておくと後から連携しやすくなります。連携が必要かどうかはモール数だけでなく、在庫更新の頻度、手作業の時間、欠品時の影響を基準に判断します。
まとめ
EC在庫管理では、複数モールの在庫数を同じ値にするだけでなく、商品コード、受注、引当、倉庫の実績、キャンセル、返品を一つの流れで記録することが大切です。販売可能在庫の定義と在庫区分を先にそろえ、APIやCSVなどの連携方式を業務の速度と運用体制に合わせて選びます。
導入時は、現状のデータと業務の流れを確認し、代表的な商品とチャネルから段階的にテストします。連携エラーや棚卸し差異が起きることを前提に、状態、履歴、再送、手動切替の手順を用意すれば、担当者が変わっても運用を続けやすくなります。最終的には、EC担当と倉庫担当が同じ在庫の意味を共有し、注文を受けられる数量を正しく判断できる環境を整えることが目標です。
