自社EC・モール・実店舗の在庫連動｜スプレッドシート＋AIで在庫ズレを防ぐ方法

自社EC・モール・実店舗の在庫連動スプレッドシート＋AIで在庫ズレを防ぐ方法

▶ あわせて読みたい：ネットショップのAI活用

自社EC、楽天市場やAmazonなどのECモール、実店舗を並行して運営していると、少しずつ問題になってくるのが「在庫数のズレ」です。

実店舗では商品が売れているのに、EC側ではまだ「在庫あり」と表示されている。反対に、ネットショップではすでにキャンセルされて在庫が戻っているのに、別のモールでは欠品したままになっている。

• 在庫がない商品を販売してしまう
• 注文後に欠品連絡をしなければならない
• 販売できる商品があるのに「売り切れ」と表示される
• 毎朝担当者が複数の管理画面を開いて在庫数を修正する

といった問題が発生します。

「AIを使えば在庫管理も全部自動化できるのではないか」と考える方もいるかもしれません。

しかし、最初に結論をお伝えすると、自社EC・モール・実店舗の在庫連動は、AIよりもシステム連携を優先するのが基本です。

AIは、在庫をリアルタイムで確実に同期する仕組みの代わりではありません。在庫数そのものを動かす処理は、POS連携、EC連携、在庫同期アプリ、一元管理ツールなど、決められたルールでデータを連携する仕組みに任せたほうが安全です。

一方で、すべての販売チャネルを直接連携できるとは限りません。古いPOSを使っている、独自の自社ECがある、取扱商品ごとに商品コードが違う、といった場合には、どうしても手作業が残ります。

連携できるところはシステムでつなぐ。つながらないところはスプレッドシートへ集める。AIは在庫差分の検出、警告、安全在庫の計算に使う。

という分け方が現実的です。この記事では、毎朝手作業で在庫数を直しているEC事業者に向けて、自社EC・複数モール・実店舗の在庫ズレを減らす考え方と、スプレッドシート＋AIを使った運用方法を解説します。

実店舗で売れた商品をECから減らし忘れ、売り越しが起きていた店

毎朝在庫を直していても月数件の売り越しが発生

ある小規模なアパレル店では、実店舗と自社EC、2つのECモールで同じ商品を販売していました。商品の仕入れは一括ですが、在庫管理はそれぞれ別です。

実店舗ではPOSレジを使用し、自社ECとモールには販売可能な数量を手入力していました。担当者は毎朝、前日の販売状況を確認してスプレッドシートを更新し、その数字を見ながらEC側の在庫数を修正していました。

一見すると、大きな問題はなさそうです。しかし、問題は営業時間中に起きます。たとえば、在庫が残り1着の商品が実店舗で午後3時に売れたとします。POS上では在庫ゼロになっても、自社ECやモール側の在庫表示は翌朝まで「1」のままです。

その間にECで注文が入ると、在庫がない商品を販売したことになります。担当者は購入者へ欠品連絡をし、キャンセルをお願いしなければなりません。こうした売り越しが月に数件発生していました。

1件、2件であれば担当者が対応できます。しかし、購入者から見れば、注文できた商品が後から欠品になるため、店舗への信頼にも関わります。

問題は担当者ではなく「在庫を別々に持っていたこと」

このような問題が起きると、「担当者が更新を忘れた」「もっとこまめに確認すればよい」と考えてしまいがちです。しかし、本質的な問題は担当者の注意力ではありません。

同じ商品の在庫数を、実店舗・自社EC・モールで別々に管理していることです。在庫を4か所で持てば、4か所を更新する必要があります。販売チャネルが増えるほど、更新箇所も増えます。

結論｜在庫連動は「AIより連携」が原則

AIはリアルタイムの在庫同期装置ではない

生成AIは、データ整理、数字の傾向分析、異常値の発見、条件に合う商品の抽出、安全在庫候補の計算、運用ルールの文章化などを得意とします。

一方で、「実店舗で1着売れた瞬間に、自社ECとモールの在庫数を必ず1つ減らす」という処理は、AIの判断を挟む必要がありません。必要なのは、売れたというデータを正確に受け取り、決められたルールに沿って各システムへ反映することです。

つまり、判断が必要なところはAI、確実な同期が必要なところは連携、と分けて考えると分かりやすくなります。

優先順位は「直接連携→自動化→AI補助」

1. POS・自社EC・モールを直接連携できないか確認する
2. 在庫同期アプリや既存の連携機能を確認する
3. 必要に応じて一元管理ツールを検討する
4. 直接連携できない部分をスプレッドシートへ集める
5. AIで差分検出や警告を行う

ここで重要なのは、最初からすべてをAIに寄せないことです。自社ECとPOSが標準機能で連携できるのであれば、その部分は連携機能を使ったほうが安定します。AIを使う価値が高いのは、商品コードがバラバラ、CSVの形式が違う、一部の販売チャネルだけ直接連携できない、といった「システム同士の継ぎ目」です。

リアルタイム同期と定期チェックを混同しない

「毎朝AIが在庫表を確認してズレを教えてくれる」仕組みを作っても、営業時間中の売り越しは防げません。朝9時に在庫が合っていても、10時に店頭で最後の商品が売れ、11時にEC注文が入れば売り越します。

そのため、売り越しを防ぐための在庫同期と、ズレがないか確認するためのAIチェックは別の仕組みとして考える必要があります。

自社EC・モール・実店舗の在庫がズレる5つの原因

実店舗の販売がECへ反映されない

最も分かりやすい原因です。実店舗ではPOS上の在庫が減っていても、その情報がECへ送られていなければ、ネットショップ側の在庫は変わりません。特に、実店舗とECが別々のシステムになっている店舗で起こりやすい問題です。このケースはAIよりもPOS・EC間の在庫連携を優先すべきです。

複数ECで同時に注文が入る

在庫が残り1個しかない商品を、自社ECとモールの両方で「在庫1」と表示しているケースです。ほぼ同時に注文が入れば、どちらかは売り越しになります。この問題も、AIによる朝のチェックでは防ぎにくく、リアルタイムまたは短い間隔で在庫数を連携できる仕組みが必要です。

返品・キャンセルを戻し忘れる

返品やキャンセルが発生すると、販売時とは逆に在庫を戻す作業が必要です。自社ECでは戻したが、スプレッドシートでは戻していない、モールでは欠品のまま、といったズレが起きます。

商品コード・SKUがチャネルごとに違う

同じ商品でもPOS、自社EC、モールで商品コードが異なることがあります。人が見れば同じ商品でも、システムは別商品として扱います。この場合は共通SKUと各チャネルの商品コードを紐づける対応表が必要です。

棚卸差異や破損・紛失が反映されていない

システム上の在庫数が10個でも、実際に棚を数えると9個しかないことがあります。破損、紛失、入出庫記録漏れ、サンプル使用、数え間違いなどが原因です。これはEC連携だけでは解決できず、現物を確認して実在庫を修正する必要があります。

▶ 関連記事：楽天・Amazon・自社ECの受注を一元化

まず確認するのは「今使っているサービス同士が連携できるか」

POSと自社ECの連携を確認する

実店舗と自社ECを運営している場合は、最初にPOSとECの連携可否を確認します。

• 商品情報を連携できるか
• 店頭販売時にEC在庫も減るか
• EC注文時に店舗在庫も減るか
• キャンセル時に在庫が戻るか
• 同期のタイミングはリアルタイムか定期処理か

「連携対応」と書かれていても、売上だけ連携し、在庫は対象外というケースも考えられます。何が連携されるのかを具体的に確認してください。

ECモール間の在庫同期機能を確認する

複数モールへ出店している場合も同様です。特に売れ筋商品や在庫数の少ない商品は、同期タイミングが重要です。

モールごとに直接在庫を持つのではなく、特定の在庫管理機能や外部連携によって同期できる場合があります。1日1回ではなく、より短い間隔で更新できるかを確認しましょう。

在庫同期アプリ・一元管理ツールを確認する

チャネルが増えてくると、複数EC・モールの在庫をまとめて管理するサービスも選択肢になります。ただし、受注件数、SKU数、販売チャネル数、更新頻度によって必要性は変わります。

一元管理ツールを導入すべき具体的な件数や判断ラインは別記事へ譲り、ここでは直接連携できない部分が残る場合の現実的な方法に絞ります。

連携できない組み合わせではスプレッドシートを「正」にする

すべてのシステムを直接連携できない場合は、データを集める基準となる場所を決めます。小規模ECであれば、スプレッドシートを利用する方法も現実的です。大切なのは、どの数字を正しい在庫として扱うかを決めることです。

「正しい在庫」を1か所だけ決める

実店舗、EC、モール、スプレッドシートのすべてを「正」とすると、数字が違ったときに判断できません。そのため「最終的にこの数字へ合わせる」という基準を1つ決めます。POSの実在庫、基幹システムの在庫、共通スプレッドシートなど、自社の運用に合うものを基準にします。

最低限そろえる在庫表の項目

必要に応じて、最終更新日時、担当者、確認済み、要修正といった項目を追加します。

商品コードが違う場合は対応表を作る

この対応表があるだけでも、CSVをまとめる作業はかなり楽になります。AIでマッピング候補を作ることもできますが、似た商品、色違い、サイズ違いを誤って紐づける可能性があるため、最初の対応表は必ず人が確認しましょう。

AIに任せるのは在庫更新ではなく「差分検出と警告」

各チャネルのCSVをスプレッドシートへ集める

まず、自社EC、モール、POSなどから取得できる在庫データを集めます。理想は自動連携ですが、難しい場合はCSV出力でも構いません。重要なのは、毎朝複数の管理画面を見て、人が目で比較する状態から抜けることです。

AIに「ズレている商品だけ」を抽出させる

500SKUあっても、実際にズレている商品が10件なら、490件の確認は不要です。実在庫とEC在庫が違う、安全在庫を下回る、昨日から急激に減った、モール間で差が大きい、といった商品だけを抽出します。

差分の大きい商品から確認する

差分1個で在庫100個の商品より、差分3個で在庫3個の商品を優先すべき場合があります。AIに売り越しリスクが高い順の整理をさせると、確認の優先順位をつけやすくなります。

AIが直接在庫を書き換える運用は慎重にする

在庫差分には、正しい販売、返品、欠品、棚卸差異、入荷予定、予約分、取り置きなどさまざまな事情が含まれます。初期段階では、AIが異常を提示し、人が理由を確認し、必要な箇所だけ修正する運用がおすすめです。

売り越し防止の「安全在庫」をAIに計算させる

安全在庫とは

ここでいう安全在庫とは、実際に持っている在庫のすべてをEC上で販売可能にしない考え方です。たとえば実在庫が10個あっても、安全在庫を2個に設定し、ECでは8個まで販売できるようにします。実店舗側で急に商品が売れても余裕があるため、売り越しが起きにくくなります。ただし、安全在庫を多くしすぎると販売機会を失います。

販売速度から安全在庫を決める

• 通常商品：販売頻度が低く在庫にも余裕があるなら、安全在庫は少なめ
• 人気商品：実店舗とECの両方で動く商品は更新までの時間差を見て厚め
• セール商品：短時間に注文が集中する可能性があるため通常時より余裕を持たせる
• 実店舗で動きやすい商品：店頭販売が多くEC反映が遅れるなら安全在庫を確保

AIには「計算」と「候補提示」を任せる

過去の1日あたり平均販売数、最大販売数、店頭販売比率、EC販売比率、更新間隔、欠品発生状況などをAIに整理させると、安全在庫候補を考える材料になります。ただし、季節商品、セール予定、大口注文、次回入荷日などを人が確認し、最終判断してください。

在庫ズレの原因別対策表

「◎」だから必ず完全自動化できるという意味ではありません。自社の利用システムやデータ構造によって対応範囲は変わります。重要なのは、在庫の数字を動かす処理ほど連携を優先し、理由を判断する処理ほど人やAIを使うことです。

毎朝の在庫確認を「5分で終わらせる」運用

①各チャネルの最新データを取得

自社EC、ECモール、POS、基準在庫表から最新データを取得します。自動連携できる場合は自動で取り込み、難しい場合はCSV出力を使います。

②スプレッドシートへ集約

各データを共通SKUを基準に1枚へまとめます。人が毎回コピー＆ペーストしているなら、CSV取り込み、インポート機能、スクリプト、自動化サービスなどで減らせないか検討します。

③AIまたは数式で差分商品だけ抽出

単純な数値比較ならスプレッドシートの数式だけで十分な場合があります。AIは、商品コード表記が一定しない、商品名の表記ゆれがある、原因候補を整理したい、リスク順に並べたい、といった場面に向いています。

④警告商品のみ人が確認

全500SKUのうち警告が12SKUなら、担当者は12SKUだけを確認します。返品処理漏れ、店頭販売の反映遅れ、商品コード不一致、棚卸差異などの原因を確認します。

⑤必要なチャネルだけ修正

原因が分かったら必要なチャネルだけ在庫を修正します。全商品を書き直すのではなく、問題が起きた商品だけ修正します。

この形に変えることで、朝30分、1時間かかっていた在庫チェックを数分程度の確認作業へ近づけられる可能性があります。実際の所要時間はSKU数やデータ取得方法によって異なるため、「必ず5分」ではなく、確認対象を減らす設計を目標にしましょう。

在庫連動でやってはいけない運用

AIに毎回在庫数を判断させる

販売可能在庫は、実際の保有数量や引当状況をもとに決める必要があります。AIは判断材料を出す役割にとどめ、在庫数の根拠となるデータを優先しましょう。

各チャネルをそれぞれ正として管理する

自社EC、モール、POSのすべてを正とすると、数字が違ったときにどれへ合わせるか判断できません。必ず基準を決めます。

商品コードの対応表を作らない

商品名だけで照合すると、色違い、サイズ違い、セット商品、リニューアル商品を誤って同一商品として扱う恐れがあります。

安全在庫ゼロで全チャネルへ公開する

直接同期できない状態で最後の1個まで複数ECへ公開すると、売り越しリスクが高まります。

自動化した後にエラー確認をしない

API仕様変更、CSV列変更、商品コード変更、新規商品追加、連携エラーなどで処理が止まることがあります。異常があったら分かる仕組みまで作りましょう。

スプレッドシート運用からシステム連携へ切り替えるサイン

更新回数が増えた

1日1回では追いつかず、午前・午後・夕方と何度も在庫更新している場合は、リアルタイムまたは短時間で同期できる仕組みを検討したほうがよいでしょう。

販売チャネルが増えた

2チャネルなら管理できても、4、5、6チャネルと増えるほど手作業の組み合わせは増えます。

SKUが増えた

100SKUの確認と5,000SKUの確認では必要な仕組みが違います。商品点数が増えるほど人が直接確認する運用は難しくなります。

セール時の同時注文が増えた

キャンペーンやセールのたびに売り越しが発生する場合は、更新速度が販売スピードに追いついていない可能性があります。

担当者以外が対応できない

「このスプレッドシートは○○さんしか分からない」という状態は属人化のサインです。

朝だけでは確認しきれない

朝の差分チェックでは売り越しを防げないほど受注量が増えた場合は、スプレッドシート＋AIによる定期確認から直接連携へ移行する段階です。

一元管理ツールを導入すべき具体的な件数や判断ラインは、受注数・チャネル数・SKU数を合わせて考える必要があります。詳細は一元管理ツールの導入判断を扱う関連記事で確認してください。

よくある質問

ChatGPTなどのAIだけでEC在庫を自動同期できますか？

AIだけでの在庫同期を前提にするのはおすすめしません。在庫更新そのものはPOS連携やEC連携、在庫同期機能を優先し、AIは差分検出・異常商品の抽出・安全在庫の計算補助などに使うのが現実的です。

Googleスプレッドシートだけで複数モールの在庫管理はできますか？

規模が小さければ可能ですが、リアルタイム同期にはなりません。SKU数や同時注文が増えた場合は、直接連携や在庫同期システムへの移行を検討してください。

実店舗とECの在庫ズレをなくすには何から始めればよいですか？

まずPOSとECが直接連携できるか確認します。次に基準となる在庫を一つ決め、連携できないチャネルだけスプレッドシートへ集約すると整理しやすくなります。

安全在庫は何個に設定すればよいですか？

商品ごとの販売速度、在庫数、更新頻度、店頭販売比率などを見て決めます。売れ筋商品やセール商品は多めにするなど、一律ではなく商品特性に合わせて設定してください。

在庫同期システムとAIはどちらを先に導入すべきですか？

在庫の更新漏れや売り越しが問題なら、まずシステム連携を確認します。AIは、連携できない部分の差分確認や分析を補助するものと考えるとよいでしょう。

まとめ｜在庫を動かすのは連携、ズレを見つけるのはAI

自社EC・複数モール・実店舗を運営していると、在庫管理は販売チャネルが増えるほど複雑になります。毎朝スプレッドシートを見ながら在庫数を手入力している場合は、担当者の作業速度を上げるより、まず仕組みを見直しましょう。

基本は次の3段階です。

1. 直接連携できるPOS・EC・モールは連携する

2. 連携できないデータを共通のスプレッドシートへ集める

3. AIや数式で差分商品だけ抽出し、人が最終確認する

特に重要なのは、AIにリアルタイム在庫同期の役割を任せすぎないことです。在庫を正確に動かすのはシステム連携。在庫ズレを見つけ、確認対象を減らすのはAI。この役割分担ができると、毎朝の確認作業と売り越しリスクの両方を減らしやすくなります。

現在のEC、モール、POS、スプレッドシートの組み合わせによって最適な方法は異なります。「全部入れ替える」のではなく、まずはどこが連携でき、どこに手作業が残っているのかを整理するところから始めてください。

自社EC・モール・実店舗の在庫連動は、最初から大きなシステムへ入れ替える必要があるとは限りません。現在使っているEC、POS、スプレッドシートを整理すると、直接連携する部分、AIで差分を確認する部分、人が最終判断する部分を分けられます。

「毎朝在庫数を手で直している」「売り越しが月に何件か起きている」「一元管理ツールを入れるほどの規模か分からない」といった場合は、現在の運用から整理してみるのがおすすめです。