EC在庫の一元化、業種で「やり方」はどう変わるのか——アパレル・家電・コスメ・食品、4業種の現場から見る導入判断の分岐点 ─ 在庫管理のDXに | 完全無償クラウド型ソフト「Spes」

アパレルEC——SKUの爆増と「季節切り替え」が最大の壁

アパレルECで在庫一元化を難しくするのは、商品管理の粒度だ。色×サイズ×シーズンで掛け算されるSKU数は、取扱品目が100点でも実際の在庫管理単位は数千を超えることがある。春夏コレクションと秋冬コレクションが切り替わるタイミングでは、旧シーズン品の残数処理と新シーズン品の登録が同時進行し、管理データが一時的に混乱しやすい。

ECモールごとに在庫を別管理している場合、楽天で売り切れたMサイズのベージュカーディガンがAmazonではまだ「在庫あり」のまま残り、受注後に欠品発覚——というパターンが繰り返される。顧客への謝罪とキャンセル対応で、週に何時間もが消えていく。

アパレルECに在庫一元化を導入する際に先に決めておくべきことは、「商品マスタの設計ルール」だ。カラー名称の表記揺れ（「ベージュ」「ベｰジュ」「BEIGE」等）をモール間でどう統一するか、サイズ表記（S・M・L vs 36・38・40）をどの基準に統一するかを先に固めないと、システムを入れても突合できないデータが大量に残る。

家電EC——型番管理・返品・修理品の動きが複雑化する

家電ECで在庫一元化が複雑になる理由は、「返品・修理品の在庫区分」にある。家電製品は購入後の初期不良返品や修理対応品の動きが一定数発生する。これらは新品在庫とは明確に分けて管理しなければならないが、複数のモールから戻ってくる返品品を一元管理する仕組みが整っていない場合、気づかぬうちに不良品が新品扱いで再出荷されるリスクが生じる。

また、家電は型番によって保証期間・取扱説明書のバージョン・対応電圧が異なる。同じ商品名でも型番が違えば別物として管理する必要があるが、モールの商品ページは型番より商品名を前面に出すため、在庫管理システム側で型番を正確に紐づけていないと誤出荷が起きる。

家電ECで一元化を進める際は、新品・返品良品・修理品・廃棄待ちの在庫区分を最初にシステム設計に組み込むことが前提になる。後から追加しようとすると、過去データの組み替えが発生して工数がかさむ。

コスメEC——ロット番号と使用期限が「見えていない」リスク

コスメ・化粧品のECでは、ロット番号と使用期限の管理が一元化の核になる。化粧品は製造ロットによって品質のトレーサビリティが必要であり、万が一のリコール対応時に「どのロットがどのモールでいつ誰に出荷されたか」を即座に追跡できなければならない。

小規模なコスメECのケースでは、Amazonと自社ECサイトの在庫を手動で調整しながら運用していたところ、期限切れ間近のロットが自社EC側の在庫として残り続け、半年後に大量の廃棄ロスが発覚した——という事例がある。複数拠点・複数モールで在庫を分散させているほど、期限管理の死角は広がりやすい。

コスメECで一元化を検討するなら、先入れ先出し（FIFO）の徹底をシステムで自動制御できるかが選定基準の一つになる。担当者の意識だけに頼る運用は、人が変わった瞬間に崩れる。

食品EC——賞味期限と「温度帯の混在」が最もシビアな管理を要求する

食品ECは、全業種のなかで在庫管理の制約が最も厳しいカテゴリの一つだ。賞味期限・消費期限の管理が必要であることに加え、常温・冷蔵・冷凍の温度帯が混在する商品を扱う場合、保管倉庫の区分と出荷のルールが複雑になる。

食品ECでよくあるのが、楽天向けの在庫として確保していた冷蔵品を、Amazon倉庫への在庫補充を忘れたまま販売継続してしまい、賞味期限3日前の商品が出荷される——という事態だ。顧客クレームに発展することもあり、ブランドへの信用棄損につながりかねない。

食品ECで在庫一元化を進める際の現実的な優先順位は、「期限切れアラートの自動化」と「出荷優先順の仕組み化」を最初に固めることだ。賞味期限の近い商品から順に出荷する仕組みを担当者の目視判断に頼っている限り、繁忙期に必ずミスが出る。

どの業種でも「現状の棚卸し→マスタ設計→システム連携→運用定着」の順序は変わらない

4業種に共通する「一元化で最初に整えるべきこと」

業種ごとにボトルネックは異なるが、在庫一元化を進める際の順序は共通している。最初にすべきことは、システムを選ぶことでも、モールAPIの設定を始めることでもない。「現在の在庫データが正しいかどうかを確認すること」だ。

正確性に疑問のある在庫データをそのまま一元化システムに移行しても、誤ったデータが一か所に集まるだけになる。まず自社の在庫データを棚卸しし、マスタ上の数字と実際の在庫数が一致しているかを確認する。この作業を飛ばして先に進もうとした結果、システム導入後に数量の不一致が多発し、再度手作業での修正対応に追われるケースは少なくない。

次に重要なのは、複数モールにまたがる受注データの取り込みルールを決めることだ。楽天とAmazonでは注文データの項目名・フォーマットが異なる。これを統一した形式に変換して一元的に処理できるようにする設計が、運用効率に大きく影響する。

たとえばSpesのBPOサービスでは、モールごとに異なるフォーマットの受注データを整理・データ化し、取引先ごとの特殊なフォーマットにも対応した受発注処理の自動化を支援している。EC運営の規模や現状の課題によっては、システム導入とあわせて業務フロー全体の設計から相談できる体制を整えておくと、導入後のトラブルが減る。気になる場合はSpesへの問い合わせから状況を共有してみるとよい。

よくある質問

在庫一元化ツールを入れれば、すぐにモール間の在庫ズレはなくなりますか？

ツールを導入しただけでは即座に解決しない場合が多い。商品マスタの整備・モールAPIの設定・在庫の初期データ入力が正確に完了してはじめて、リアルタイムでの在庫連動が機能し始める。導入後1〜2か月は、手動調整と並行して運用する移行期間を見込んでおくのが現実的だ。

アパレルECでセール時期の在庫管理はどうすれば良いですか？

セール期間中は出荷スピードが上がり、在庫数の更新が遅延すると二重販売が起きやすくなる。セール開始前に安全在庫の下限を通常より高めに設定し、残数が一定数を下回った時点で自動的に販売停止する設定を入れておくことで、ミスのリスクを下げられる。

食品ECで複数の温度帯商品を扱う場合、一元化は難しいですか？

常温・冷蔵・冷凍が混在する場合、保管場所・出荷ルールが複数に分かれるため、在庫管理システム側でロケーション（保管場所）単位の管理が必要になる。ロケーション管理に対応したシステムを選ぶことが前提となる。

EC在庫の一元化は、「システムを入れる」前に「業種に合わせた設計を決める」ことが実際の工数の大部分を占める。導入に向けて何から手をつけるべか迷っている場合は、まず現状の課題を整理して専門家に相談することが近道になることも多い。

参考: e-Stat（政府統計ポータル）——EC市場規模・業種別出荷統計などの一次データを確認する際に活用できる。