複数モールの在庫連携とは？売り越しとキャンセルを防ぐ仕組みと運用

複数モールで売り越しが起きる原因

売り越しは、ある店舗で売れた在庫が、ほかの店舗の在庫数に反映されるまでの「ずれ」の間に注文が入ることで起こります。

まずは、ずれが生まれる典型的な原因と、売り越しが店舗運営に与える影響を整理します。

売り越しとは何か

売り越しとは、実際の在庫数を超えて注文を受けてしまうことです。たとえば在庫が1点しかない商品が、楽天市場とAmazonでほぼ同時に売れた場合、どちらか一方のお客様には商品を届けられません。

販路が1つなら、在庫数はモールの管理画面だけで完結します。しかし販路が2つ以上になると、在庫の実数は倉庫に1つしかないのに、在庫数の表示は店舗の数だけ存在することになります。この「実数は1つ、表示は複数」という構造が、売り越しの根本的な原因です。

手作業の更新と同期のタイムラグ

各モールの管理画面に在庫数を手で入力している場合、入力ミスや更新漏れは避けられません。商品数や販路が増えるほど作業量が増え、ミスも起きやすくなります。

在庫連携システムを使っていても、一定の時間ごとにまとめて在庫を更新する方式では、更新と更新の間に売れた分がすぐには反映されません。セールやテレビ・SNSでの紹介などで短時間に注文が集中すると、このタイムラグの間に売り越しが起こりやすくなります。

売り越しがストア評価に与える影響

売り越しによるキャンセルは、多くのモールで出品者側の都合によるキャンセルとして扱われます。Amazonの「アカウント健全性の確認」に関する資料では、キャンセル率を、指定された7日間の注文に対して出品者都合でキャンセルした注文の割合と定義し、出品者出荷の注文について2.5%未満に抑える必要があるとしています。

Yahoo!ショッピングでも、業界メディアの解説によると、ストア都合キャンセル率が2.5%未満であることが優良配送の条件の一つとされています。キャンセルが続くと、検索での見え方やラベルの付与に影響するおそれがあるため、売り越しは「たまに起きる事故」ではなく、仕組みで防ぐべき課題と考える必要があります。

在庫連携の仕組みと方式の違い

在庫連携の方式は、大きく分けて、モールのAPIを使って自動で更新する方式と、CSVファイルなどで一定時間ごとにまとめて更新する方式の2つがあります。

方式を選ぶ前に、どのデータを在庫の「正」とするかを決めておくことが、連携をうまく機能させる前提になります。

在庫連携とは

在庫連携とは、ECモールや自社ECサイト、倉庫、実店舗などで別々に管理されている在庫情報をつなぎ、注文・入荷・出荷に合わせて在庫数を自動で更新する仕組みのことです。一般的には、在庫連携システムや受注管理システムが各モールとつながり、どこかで注文が入ると、その分をほかの店舗の在庫数からも差し引きます。

連携の方法は、モールが提供するAPI（システム同士が直接データをやり取りするための窓口）を使った自動連携が中心で、APIが使えない場合はCSVファイルの取り込みで対応することもあります。

API連携とCSV（バッチ）連携の違い

API連携は、注文などが発生するたびにシステム同士がすぐに情報をやり取りするため、各店舗の在庫数をほぼ同時に更新でき、ずれを小さくできます。その分、導入には設定の知識が必要で、費用も高くなる傾向があります。

CSV連携は、在庫データを決まった時刻や間隔でまとめて更新する方式です。費用を抑えやすい一方で、更新の間隔の分だけずれが生じます。商品数が少なく、注文が集中しにくい店舗ならCSV連携でも運用できますが、セールに参加する店舗や売れ筋の在庫が少ない店舗では、API連携のほうが安心です。

在庫の「正」をどこに置くか

在庫連携では、どのシステムの在庫数を基準（マスター）にするかを最初に決めます。考え方は主に2つあり、既存の基幹システムや自社ECの在庫を基準にする方法と、在庫管理システムや倉庫管理システム（WMS）を中心に置き、そこから各モールへ在庫数を配る方法があります。

販路を今後も増やす予定があるなら、在庫管理の中心となるシステムを1つ決め、そこから各モールに配る形にしておくと、新しい販路を追加するときも設定を増やすだけで済みます。基準があいまいなまま、モールの管理画面でも直接在庫数を書き換えていると、どの数字が正しいのか分からなくなるため注意が必要です。

在庫連携システムを選ぶときの確認点

在庫連携システムは、自社が使っている販路と倉庫につながるか、同期の頻度を調整できるか、費用が受注量に対して見合うかの3点で比較します。

導入前に確認しておきたいポイントを、手順の形で整理します。

対応している販路と倉庫を確認する

1. 現在使っている販路（楽天市場、Yahoo!ショッピング、Amazon、自社ECのカートシステムなど）と、今後出店を予定している販路を一覧にします。

2. 候補のシステムが、それぞれの販路とAPIで連携できるか、CSVのみの対応かを確認します。

3. 外部の発送代行倉庫を使っている場合は、倉庫のシステムとも連携できるかを確認します。入荷や出荷の実績が自動で反映されないと、在庫数の起点がずれてしまいます。

なお、Amazonのように、外部システムとのAPI連携に出品プランなどの条件があるモールもあります。各モールの条件もあわせて確認しておきましょう。

同期の頻度と在庫の引き当てのルール

在庫の同期をどのくらいの間隔で行えるか、セールの時期だけ間隔を短くするといった調整ができるかを確認します。あわせて、注文が入った時点で在庫を差し引くのか、決済の完了や受注の確定を待ってから差し引くのかといった、在庫の引き当てのタイミングも重要です。

後払いや銀行振込など、注文から確定までに時間がかかる決済方法がある場合、引き当てのタイミングによって在庫数の見え方が変わります。自社の注文の流れに合わせて設定できるかを、デモや試用期間で確かめておくと安心です。

費用の内訳と運用の手間

費用は、初期費用と月額費用だけでなく、受注件数や連携する店舗の数、商品数に応じて料金が上がる仕組みかどうかも含めて比較します。販路を増やしたときや繁忙期に、費用がどう変わるかを試算しておくことが大切です。

また、連携エラーが起きたときに通知が届くか、どの商品の在庫がずれているかを画面で確認できるかといった、日々の運用のしやすさも見ておきましょう。エラーに気づかないまま放置すると、システムを入れていても売り越しは起こります。

売り越しを防ぐ現場の運用ルール

在庫連携システムは売り越しを減らす道具であり、売り越しをなくすには、安全在庫やSKUの管理、返品・棚卸しの反映といった運用ルールを現場で決めて守ることが欠かせません。

最後に、システムと組み合わせて整えておきたい運用のポイントを紹介します。

安全在庫を残して各モールに表示する

安全在庫とは、同期のずれや検品での不良などに備えて、販売可能な在庫数からあらかじめ差し引いておく数量のことです。たとえば実在庫が20点ある商品について、各モールには18点と表示しておけば、短時間に注文が重なっても売り越しが起きにくくなります。

売れ行きの速い商品、在庫が少なくなった商品、セール対象の商品ほど、安全在庫を多めに設定するのが基本です。一方で、安全在庫を多くしすぎると販売機会を逃すため、商品の売れ方を見ながら定期的に見直します。在庫が数点まで減った商品を、特定の販路だけで販売するように切り替えるのも有効な方法です。

SKUとセット商品の管理を統一する

SKUとは、色やサイズの違いまで区別した在庫管理の最小単位のことです。同じ商品でも、モールごとに商品番号の付け方が違っていると、連携システムの中で別の商品として扱われ、在庫が正しく差し引かれません。

社内でSKUの付け方のルールを決め、すべての販路で同じSKUを使うのが基本です。2点セットやギフトセットのように、単品を組み合わせて販売する商品は、セットが1つ売れたら構成する単品の在庫を正しく差し引く設定ができているかを確認しておきましょう。

返品・不良品・棚卸しの反映ルールを決める

返品された商品をいつ販売可能な在庫に戻すか、不良品や検品待ちの商品をどう区別するかを決めておかないと、売れない在庫が販売可能として表示されてしまいます。返品は検品を終えてから在庫に戻す、不良品は別の保管場所で管理する、といったルールを倉庫と共有しておくことが大切です。

また、システム上の在庫数と倉庫の実在庫は、運用を続けるうちに少しずつずれていきます。定期的に棚卸しを行い、差異があれば原因を確認したうえで在庫数を修正します。差異の多い商品や担当工程が分かれば、運用ルールの見直しにもつなげられます。