ネットショップの在庫管理｜複数モールの売り越しを防ぐ一元管理の方法

楽天市場・Amazon・Yahoo!ショッピング・自社ECと販路を増やすほど、頭を悩ませるのが在庫です。実在庫は1つでも、各モールの在庫表示はすぐにずれます。在庫は「足りない」より「売り越す」ほうが痛く、これは倉庫の整理ではなく、複数チャネルの在庫を1つの真実へ同期する問題です。

手作業やExcelでの在庫合わせは、売れるほど破綻します。この記事では、なぜ売り越しが起きるのかという構造から、在庫連携で「やること」、自社の規模・チャネル構成に合う方法の選び方までを順に見ていきます。個別の製品比較は在庫管理システムの比較でご紹介しています。ここでは、自社の要件を言葉にして選べるところまでを扱います。

なぜ「在庫の同期」が問題になるのか

複数の販売チャネルで同じ商品を扱うと、実在庫は一つでも在庫表示は容易にずれます。売り越しが起きる仕組みと、キャンセルやモール上の評価へ及ぶ影響を押さえることが、運用を見直す出発点になります。

複数チャネルで在庫がずれ、売り越しが起きる構造

同じ実在庫を複数モールで販売する場合、店舗ごとの商品を同一商品として紐づけ、ある店舗で売れた数を他店舗の表示在庫からも減らす必要があります。連動がなければ、先に売れた事実が別店舗へ届かないまま、同じ1点を販売し続けてしまいます。GoQSystemの案内でも、紐づいた同一商品の在庫数を他モールにも反映する仕組みが示されています。

しかも、購入者がカートへ入れた段階で在庫が確保されるとは限りません。Yahoo!ショッピングでは注文確定までに別の購入者の注文で品切れになる場合があり、楽天市場でも買い物かご投入時点では商品は確保されません。Yahoo!ショッピングの案内、楽天市場の案内が示す通り、注文が重なる時間帯には表示在庫と受注の間に差が生じます。

実店舗も併売しているなら、レジでの販売や補充も共通在庫に反映する対象です。POS上で販売または補充が行われると、そのロケーションの在庫数が更新されます。Shopify POSのヘルプにあるような更新がEC側と分かれていると、店頭で最後の1点が売れたあとも、モールには在庫ありと表示されかねません。

足りない在庫より、売れてしまった在庫のほうが後工程を重くします。「残り1点」がほぼ同時に二つのモールで売れ、片方の注文を取り消して謝罪メールを送る。こうした事態は、商品数の多さだけではなく、同じ在庫をどこで減らしているかが分かれていることから起こります。

売り越しはキャンセル率とモール評価に直結する

売り越しは、注文を受けた後に欠品を伝えてキャンセルする問題です。担当者には連絡、在庫確認、注文処理のやり直しが残り、購入者にとっては予定していた商品が届かない体験になります。

Amazonの出品者出荷では、出荷前キャンセル率は直近7日間の出品者キャンセル注文数を総注文数で割って算出され、目標は2.5％未満です。これを超えると出品権限が制限または停止される可能性があります。Amazonのポリシー資料で示されています。

Yahoo!ショッピングでは、欠品などによるストア都合キャンセルを「注文キャンセル発生率」として商品詳細画面に表示します。対象は当日から9日前〜98日前までの90日間で、ストア都合キャンセル注文数を対象期間の注文数で割って算出されます。この集計方法はYahoo!ショッピングの案内で示されています。また、Yahoo!ショッピングの開示情報にある通り、優良配送などの表示条件にも、出荷遅延率とストア都合キャンセル率が含まれています。

楽天市場については、欠品キャンセル率の公開閾値や、何％で検索順位・契約へ影響するかを示す一般公開の公式資料は、2026年7月時点で確認できません。公開されている数値の有無にかかわらず、在庫差異を「後で処理すればよい事務作業」と扱わず、受注前の表示精度として捉える必要があります。

Excel・手作業から切り替える境界

表計算ソフトで管理できる範囲を、チャネル数や商品数だけで一律に決めることはできません。中小企業基盤整備機構も、表計算ソフトから在庫管理アプリへ切り替える数量的な境目は業種により異なるとしています。中小企業基盤整備機構の解説で確認できます。

判断のサインは日々の作業に現れます。出荷時に配送ミスが心配になる、営業や顧客からの在庫問い合わせへの回答に時間がかかる。こうした状態では、Excelそのものが問題なのではなく、受注・販売・補充という在庫変動を転記でつなぐ工程に無理が生じています。

複数ECの受注・在庫・商品をまとめて処理すれば、バックヤード業務の軽減につながると中小企業基盤整備機構は案内しています。中小企業基盤整備機構のEC講座にもあります。切り替えを検討する場面では、「何件から必要か」ではなく、最後の1点が売れたとき、どのチャネルの表示を誰がいつ減らすのかを追えるかで現状を見ます。

在庫連携で「やること」の全体像

在庫連携の柱は、在庫を1つの真実として同期すること、受注時に引き当てること、そしてチャネルごとの見せ方を決めることです。単に在庫数を書き換えるのではなく、販売できる数量をどこで確保し、どこまで公開するかを運用に組み込みます。

在庫を「1つの真実」に横串同期する

複数のモールや自社ECで同じ商品を扱う場合、チャネルごとに別々の在庫表を持つのではなく、1つの在庫を全チャネルで共有する設計が出発点になります。ある店舗で注文が入れば、その減算結果を他店舗の在庫数にも反映する仕組みです。TEMPOSTARも、同一商品の在庫情報を共有し、各店舗の在庫数を自動連動させる機能を案内しています。TEMPOSTARの機能案内にあります。

ただし、連携先によって接続方法は同じではありません。モールやカートごとにAPI、CSV、FTPなどの方式があり、受注・在庫・商品それぞれで対応可否も異なります。接続先の名称だけで判断せず、自社で必要な在庫連携が対象になっているかを確認する必要があります。TEMPOSTARの対応一覧で確かめられます。

同期には更新間隔もあります。ネクストエンジンはEC店舗間の在庫を5分間隔で連動すると案内しており、商品コードが異なる場合も条件を満たせば紐づけて連携できます。つまり、同じ商品を正しく対応付け、注文後の減算を各販売先へ届けるところまでが、横串同期の仕事です。ネクストエンジンの機能案内にあります。

受注時の「引当」で二重販売を防ぐ

在庫が帳簿上に残っていても、すでに別の注文に割り当てられているなら、新たに販売できる数量ではありません。この状態を明確に分けるのが引当です。Shopifyでは、販売可能な数量を「Available」、注文済みで未発送の数量を「Committed」と区分しており、Committedは販売可能在庫に含まれません。これは、注文済みの商品を次の注文へ重複販売しないための引当に相当します。Shopifyの在庫状態の解説にあります。

「注文は入ったが、まだ出荷していない」商品を在庫ありのまま扱うと、現場では確保済みの商品をもう一度売ることになります。Shopify POSの日本語ヘルプでも、未発送注文に追加された在庫を「引当済み」とし、「販売可能」「販売不可」「入荷予定」と区別しています。Shopify POSのヘルプにあります。

注文登録の時点で引当を自動化する考え方もあります。mylogiは、注文登録時の自動在庫引当を機能として案内しています。受注、確保、出荷という流れで在庫の意味を切り替えることで、横串同期だけでは埋めきれない二重販売の余地を減らします。mylogiの機能案内にあります。

在庫の「見せ方」を決める（全数か、按分か）

実在庫が5点ある商品を、全モールに「在庫5」と表示したとします。短時間に複数チャネルから注文が入れば、「どこでも売れるようにしたかったのに、同時に売れて足りなくなった」という状況になりかねません。とくに限定品、在庫1点の商品、注文が集中しやすい商品では、全チャネルに満数を見せる運用だけでなく、割合や数量を指定して按分する判断も検討する必要があります。

アシスト店長は、在庫を全店舗へ一律に配分する方法のほか、割合指定、数量指定で各モールへ振り分けて自動反映する機能を案内しています。販売機会を広く取るために全数を見せるのか、特定チャネルへ数量を確保するのかは、商品ごとの販売状況に応じて決める部分です。アシスト店長の機能案内にあります。

在庫連携は、在庫数を一致させるだけの機能ではありません。共有する在庫を定め、受注済み分を引き当て、公開数量をコントロールする。この3つがつながって初めて、売り越しを防ぐ運用になります。

自社に合う方法の選び方

在庫管理の手段は、手作業のExcel、カート標準機能、一元管理システム、POS・WMS・基幹連携の四つに分けて考えられます。正解を決める数字を探すより、自社の販売条件と日々起きている困りごとを基準に選びます。

手段は四つ、それぞれ向く条件がある

手作業のExcelは、表を更新する担当や在庫確認の流れが回っている間は選択肢になります。ただし、配送ミスが気になり始めた、営業や顧客からの在庫問い合わせへの返答に時間がかかる、といった場面は切り替えを考える合図です。中小企業基盤整備機構も、表計算ソフトから在庫管理アプリへ移る数量的な境目は業種によって異なるとしています。中小企業基盤整備機構の解説にあります。

単一のShopifyストアとShopify POSを中心にするなら、標準機能で商品・バリエーション・ロケーション別の在庫追跡、引当済み数量、在庫調整履歴を管理できます。実店舗で販売や補充をしたときにも、対象ロケーションの在庫を更新できます。一方、楽天市場やAmazonなど外部モールまで同期する場合は、別途アプリや連携システムの対応を確認する前提です。Shopifyの在庫管理で確認できます。

複数モール・自社ECをまたぐなら、受注、在庫、商品をまとめて処理する一元管理システムが候補になります。実店舗の販売在庫まで同じ流れで扱うならPOS連携、入庫後の保管・出庫・棚卸といった倉庫業務まで扱うならWMS連携、さらに基幹側の在庫と合わせるなら基幹連携の可否も確認します。WMSは、POSより倉庫業務に重点を置く仕組みです。中小企業基盤整備機構の解説にあります。

一律の「正解の数字」は無い、判断軸の作り方

チャネル数やSKU数だけで決めず、「どの在庫が、いつ、どこで動くか」を自社の運用に沿って書き出すことが選定の起点です。

「何チャネルになったら切り替えるべきか」「月間何件なら一元管理か」という一律の公的な基準は確認できません。代わりに、在庫が1点しかない商品の比率、注文が短時間に集中する商品があるか、実店舗販売があるかを見ます。限定品が売れる時間帯に、店頭販売とEC注文が重なるなら、単なる件数よりも在庫反映の遅れが問題になります。

もう一つは、現場の負荷です。例えば、店長が接客の合間に「この商品はまだ売れますか」と確認され、別の担当者がExcelを開いて返答する、といった場面です。こうした往復が続くなら、表の作り方より在庫情報の持ち方を見直す段階かもしれません。配送ミスの懸念や問い合わせ対応の遅延は、切り替え検討の目印として示されています。中小企業基盤整備機構の解説にあります。

実店舗がある場合は、POS販売時に対象ロケーションの在庫を減らせるか、店舗在庫をECの販売可能数に含めるかを分けて考えます。複数倉庫がある場合は、総在庫ではなく、どの倉庫から引き当てて出荷するかまで運用に含めます。数字を一つだけ比べるのではなく、販売・保管・出荷の流れに在庫差異が生まれる場所を探す考え方です。

「対応」表示だけで選ばない

「対応」と書かれていても、チャネルによっては在庫連携に別途アプリやオプション、API契約が必要になる場合があります。導入後に起きやすいのは、サービス名ではなく機能単位の対応範囲を見落とすことです。対応チャネルであっても、受注連携、在庫連携、商品連携の可否は同じとは限りません。

TEMPOSTARの公開一覧でも、チャネルごとに在庫連携のみ対応している場合や、商品連携が非対応・カスタマイズ対応となる差があります。候補を比べる際は、販売先の名前に丸が付いているかではなく、「受注を取り込むか」「在庫を更新するか」「商品情報も連携するか」を分けて確認します。TEMPOSTARの対応一覧で確認できます。

Shopify、BASE、メルカリShopsなどでは、アプリ、オプション、API契約、機能制限が必要になる場合があります。導入前には、使いたい各チャネルについて在庫連携方式、必要な追加契約、対象となる機能を確認しましょう。サービスの「対応」という表示は入口であり、自社の在庫が実際にどの経路で更新されるかまで確かめて、初めて比較の土台になります。ネクストエンジンの対応システム一覧にあります。

一元管理で自動化される中身

前章で触れたチャネル横断の同期と引当の先には、通常受注以外で動く在庫への対応があります。在庫変動の反映、発注点と棚卸、そして同期が動く間隔までを押さえると、運用で確認すべき場所が見えてきます。

通常の受注以外の在庫変動も自動で反映する

在庫を減らすのは受注だけではありません。キャンセル、返品、交換、不良品といった変動を扱い、セット商品の構成品在庫から販売可能数を計算できる一元管理システムもあります。たとえばネクストエンジンは、こうした在庫変動の管理を機能として案内しています。ネクストエンジンの機能案内にあります。

売り越しが判明して注文を取り消す場面では、購入者への連絡や決済のキャンセルに加え、一元管理側で引き当てた在庫を戻す処理も必要です。ただし、キャンセルのステータスを移しただけでは在庫が自動で戻らない場合があります。対象チャネルやキャンセルの操作方法によって動きが変わるため、導入時には「どの画面で、どの操作をすれば引当が解除されるか」を実際の運用に沿って確認します。

発注点アラート・棚卸で実在庫と帳簿を合わせる

在庫数が指定した数量以下になった際の通知、入出庫に伴う在庫更新、バーコードを使った棚卸は、在庫管理システムで利用できる機能例です。バーコードを使えば、倉庫や店舗で数量を数えた後に帳簿へ手入力する負担と、入力ミスを減らす助けになります。中小企業基盤整備機構の解説にあります。

発注点を下回ると自動発注する仕組みもありますが、発注書の作成から仕入先への連絡まで自動で進む場合は、人が途中で異常値に気づく機会がない点に注意が必要です。シミュレーションを繰り返して発注点を段階的に定める考え方が示されており、在庫入力時のコード間違いが意図しない自動発注につながる点も注意点として挙げられています。中小企業基盤整備機構の注意点にあります。

システム上は在庫があるのに、棚には見当たらない。その差を放置すると、次の同期が正しくても販売可能数の土台がずれたままです。定期的な実地棚卸で実在庫を把握し、帳簿上の理論在庫との差異と原因を明らかにします。J-Net21の解説にあります。

「リアルタイム」表示でも、同期には間隔がある

一元管理は、注文確定と同時に全チャネルの在庫が書き換わる完全リアルタイム方式とは限りません。公開仕様には、在庫更新が5分間隔、5〜10分間隔とされる例や、受注を通常3分おきに取得する例があります。ここで混同しやすいのは、受注取得の間隔と在庫反映の間隔は別物である点です。数字だけを並べて速さを比べるのではなく、何を取得・反映する間隔なのかを確認する必要があります。ネクストエンジンの機能案内、TEMPOSTARの在庫管理機能案内、GoQSystemのマニュアルにそれぞれ記載があります。

たとえば「5分ごとに同期しているはず」と考えていても、セール開始直後の1分間に在庫1点の商品へ複数チャネルから注文が入れば、在庫反映前に受注が重なる余地は残ります。モールAPIには一度に取得できる件数の上限が案内されている例もあり、注文集中時の遅延やエラーを確認する運用が必要になります。GoQSystemのAPI件数に関する案内にあります。

同期の間隔を短くすることはタイムラグや売り越しのリスク低減につながりますが、リスクをゼロにするものではありません。限定品や在庫が少ない商品では、同期設定だけに任せず、販売数の配分や注文集中時の対応も含めて設計します。

よくある疑問に答える

在庫量、無在庫販売、売り越し時の対応は、併売を始めると迷いやすい3点です。販売機会と欠品リスクの間で、何を基準に判断するかを押さえます。

在庫はいくつ持つのが適正か

年間平均適正在庫の目安として、中小企業基盤整備機構は「年間販売高予想÷年間予定商品回転率」を示しています。ただし、これはあくまで平均的な目安です。商品ごとの季節性、納期に関わる時間要因、安全在庫まで踏まえて決める必要があります。中小企業基盤整備機構の解説にあります。

安全在庫は、出庫予測や発注、保管作業の誤差で在庫が少なくなっても欠品を防ぐための数量です。たとえば発注から納品までのリードタイム中に出庫速度が上がる商品なら、その増加を見込んで設定します。同じく中小企業基盤整備機構の解説にあります。また、受注から納期までの期間と生産リードタイムを踏まえ、過去の受注実績や顧客の生産計画から在庫の対象期間を定める考え方が中小企業基盤整備機構のQ&Aに示されています。

併売では「総在庫をいくつ持つか」と「各チャネルにいくつ見せるか」を切り離さずに考えます。たとえば実在庫が10点でも、全チャネルに10点ずつ表示すれば売り越しの余地が生まれます。安全在庫を確保したうえで、各チャネルへの按分と表示数を組み合わせることが、販売機会と欠品防止の両立につながります。

「無在庫販売」は在庫管理からの解放ではない

「仕入先から直送できるなら在庫管理は不要」と考えると、モール規約で足元をすくわれかねません。Amazonでは、第三者が購入者へ直接出荷するドロップシッピングを、出品者が記録上の販売者として明確であること、納品書・請求書・外装から第三者の販売者情報を除くこと、返品対応を出品者が負うことなどの条件付きで認めています。一方、別のオンライン小売業者から購入し、その小売業者名義で直送する形は禁止されており、違反時には出品者出荷の権限が制限される可能性があります。Amazon出品者向けヘルプにあります。

Yahoo!ショッピングは、在庫を確保していないにもかかわらず掲載する見せかけ販売を禁止と明記しています。Yahoo!ショッピング出店案内にあります。楽天市場については、経済産業省の資料が無在庫転売を規制する直接的な規定はないと整理する一方、出店規約などの他の禁止行為に該当する場合があるとしています。経済産業省の資料にあります。

楽天市場では「在庫あり」表示でも予約商品やメーカー取り寄せ商品である場合があります。つまり、取り寄せ販売そのものと、在庫確保のない見せかけ表示は同じではありません。各モールの規約は改定されるため、2026年7月時点の最新規約と、自社の出荷・返品・表示方法を一次情報で確認したうえで運用します。

売り越しが起きてしまったときの対応

品切れが判明したら、購入者への連絡、モール上のキャンセル、決済の取り消し、在庫の戻しを別々の作業として取りこぼさないことが求められます。Yahoo!ショッピングでは、注文後の品切れはストアから購入者へメールで連絡し、キャンセル処理もストアが行います。Yahoo!ショッピングの案内にあります。楽天市場でも、注文後30分以内など購入者が操作できる場合を除き、基本的にはショップへ連絡する必要があります。楽天市場のヘルプにあります。

一元管理システムを使っている場合、キャンセル後に引当在庫を戻す処理も確認対象です。キャンセルのステータスを移しただけでは自動で戻らない場合があり、対象チャネルや操作方法によって動きが変わります。購入者への連絡だけで処理を終えると、引当のまま残った在庫が別の欠品や販売機会の損失を招きます。キャンセルを行った担当者が、決済、注文ステータス、引当在庫、各チャネルの表示数まで確認する流れを決めておくと、復旧作業が属人化しにくくなります。

自社の要件を言葉にして選ぶ

製品を選ぶ前に、自社の販売条件と在庫の動きを書き出すと、比較すべき選択肢が絞れます。「対応しているか」だけではなく、どの機能をどの条件で使うかまで言語化します。

まず自社の在庫連携の要件を書き出す

売り越しは、一つの実在庫を複数チャネルへどう反映するかという問題です。楽天市場、Amazon、Yahoo!ショッピング、自社EC、メルカリShopsなど、販売中のチャネルを並べ、同一商品をどのコードで結び付けるかを書き出します。チャネルごとに商品コードが異なっていても、条件に応じて同一商品として紐づけられる仕組みがあります。GoQSystemの案内にあります。

次に、月間受注数だけでなく、在庫が1点しかない商品や限定品、短時間に注文が集まりやすい商品の有無を記します。公開されている更新間隔には1分、3分、5分、5〜10分などの差があり、更新の間に複数の注文が入る場面をどこまで許容するかは、自社で決めるべき条件です。

• 販売チャネル：楽天市場／Amazon／Yahoo!ショッピング／自社EC／メルカリShops／その他（　　　　　　）
• 商品コード・SKUの対応表：チャネルごとに同一商品を識別できるか／異なるコードの紐づけが必要か
• 月間受注と在庫1点商品の状況：月間受注数（　　　　　　）／限定品・在庫1点・注文集中の有無（　　　　　　）
• 許容する同期遅延：何分までか（　　　　　　）／遅延時に販売を止める必要がある商品はあるか（　　　　　　）
• 在庫の見せ方：実在庫の全数を出すか／チャネルごとに数量・割合で按分するか
• 実店舗・倉庫・基幹連携：POSの有無（　　　　　　）／受注を引き当てる倉庫（　　　　　　）／拠点間移動中の在庫の扱い（　　　　　　）／基幹システム連携の有無（　　　　　　）
• 在庫の正本：棚卸差異、返品、キャンセル、破損などを、どのシステムの在庫として確定させるか

実店舗がある場合は、POS販売時にどのロケーションの在庫を減らすか、ECの販売可能在庫に含めない店舗があるかも条件になります。複数倉庫なら、総数だけで判断せず、受注の引当先、移動中在庫の扱い、出荷指示の連携まで決めます。棚卸差異や返品、キャンセルといった通常受注以外の変動についても、正本となるシステムが曖昧なままでは在庫数が再び食い違います。

要件がそろったら、製品比較で見比べる

価格から選ぶのではなく、自社の要件を満たせるかで比較することが、在庫連携では欠かせません。たとえば「楽天市場に対応」と表示されていても、受注・在庫・商品連携のすべてに対応するとは限りません。チャネルごとに在庫連携のみ、商品連携は非対応または個別対応といった差があります。

比較時は、必要なチャネルについて受注・在庫・商品の各機能が使えるか、連携方式は何か、アプリやオプション、API契約が必要かを確認します。料金とともに、実店舗連携、複数倉庫への引当、出荷指示連携が書き出した条件に合うかを見比べます。対応チャネル・料金・実店舗連携は、在庫管理システムの比較で自社条件に合わせて見比べてください。