1なぜ在庫同期は永遠にズレるのか

EC担当者なら一度は経験があるはずです。「楽天の在庫を10に直したのに、次の日見たら8になっている」「Amazonがゼロ在庫表示なのに、なぜか注文が入って売り越し」「Yahoo!の在庫数だけ更新されていない」――。マルチモール運営における在庫同期問題は、EC実務における永遠のテーマです。

多くの担当者は「在庫管理システムの不具合」「APIのバグ」と片付けてしまいがちですが、実際の原因はもっと根の深い構造的な問題です。仕組みを理解しないまま「同期ツールを変える」「目視で毎日チェックする」を繰り返しても、ズレは絶対になくなりません。

本記事では、在庫同期がズレる5つの根本原因と、売り越しを最小化するための実務設計を解説します。「ツールを買えば解決する」という幻想を捨て、現実的な落としどころを見つけるための内容です。

2原因1：APIの更新タイミングがモールごとに違う

最も多くの人が誤解しているのが「在庫を更新したら、即座にモールの商品ページに反映される」という思い込みです。実際には「更新APIを叩く」と「お客様が見るページに反映される」の間には、想像以上のタイムラグがあります。

各モールの更新タイミングの実態

モール	API反映	ページ表示反映	備考
楽天市場	数分〜10分程度	追加で数分	キャッシュの影響大、CSV更新は別タイミング
Amazon	数分〜15分	カタログ反映は最大数時間	FBA在庫はAmazon側の倉庫スキャンに依存
Yahoo!ショッピング	数分	追加で数分	ストア側のCDNキャッシュで遅延あり
自社サイト（Shopify等）	ほぼ即時	ほぼ即時	自前管理なので最も速い

※ 上記は経験則による目安。サーバ負荷・モール側の状況により変動します。

ここで気付くべきは、「ほぼ即時」のモールと「数分〜15分」のモールが混在していることです。仮に在庫管理システムが「全モールに同時にAPIを送信」したとしても、実際にお客様の目に映る在庫が一致するのは数分〜数十分後です。

セール時の致命的な遅延

さらに厄介なのが、セール期間中はAPI遅延が普段の数倍に膨れ上がること。楽天スーパーSALE初日、Amazonプライムデーの開始直後、ブラックフライデーのピーク時――。各モールの在庫APIは混雑し、普段5分の反映が30分以上かかることも珍しくありません。

3原因2：注文発生→在庫減算の「順序問題」

もう一つの大きな原因が、「注文が入ったタイミング」と「他モールの在庫を減らすタイミング」のズレです。これを理解しないと、永遠に売り越しから逃れられません。

典型的な売り越しシナリオ

商品Aの在庫が「1個」だったとします。これを楽天・Amazon・Yahoo!の3モールに「在庫1」で出品しているとします。

問題はこの「楽天注文発生」から「Amazonに在庫0が反映される」までの数分間。この時間帯に他モールで注文が入ると、確実に売り越しが起きます。受注頻度の低い商品では問題にならなくても、動きの早い人気商品ほど被害が大きいのがこの問題の特徴です。

「ポーリング型」と「Webhook型」の違い

注文の検知方法には2つの方式があります。これによって遅延の度合いが大きく変わります。

方式	仕組み	遅延	EC実務での主な使われ方
ポーリング型	定期的にAPIを叩いて新規注文を取得	1〜10分	大半の在庫管理ツール
Webhook / 通知型	注文発生時にモールから通知が届く	数秒〜1分	Shopify、一部の高機能ツール

大半の在庫管理ツールはポーリング型です。「5分おきに新規注文をチェック」という仕組みなので、最悪のケースで5分間は在庫が減らないことになります。Webhook型ですら、ネットワーク遅延を考えれば数秒のラグは避けられません。

4原因3：SKU紐付けと「楽天SKUプロジェクト」の罠

2024年〜2025年にかけて、楽天市場では「SKUプロジェクト」と呼ばれる大規模な仕様変更が進行しました。これに対応していない在庫管理の運用は、2025年以降は確実にズレが発生します。

楽天SKUプロジェクトとは

楽天SKUプロジェクトは、ひとことで言えば「商品（バリエーション）ごとに正式なSKU管理を導入する」仕組みの刷新です。従来の楽天は「商品管理番号＋バリエーション選択肢」という独特の構造で、他モールと比較して在庫管理が複雑でした。SKUプロジェクトはこれをAmazon型のSKU単位管理に近づけたもの、と理解するとわかりやすいです。

SKU紐付けで発生する典型的なズレ

マルチモール運営では、同じ商品なのにモールごとに違うSKUコードが振られているのが普通です。例えば「Tシャツ・赤・Mサイズ」という1つの実商品が、各モールでは別々のSKUとして管理されています。

モール	SKUコード例	紐付けの難しさ
自社マスタ	TSHIRT-RED-M	―（基準）
楽天	tshirt-red-m + 項目選択肢	SKUプロジェクト前後で構造が違う
Amazon	TSHIRT_RED_M / ASIN: B0XXXXXX	SKUとASINの2層管理
Yahoo!	tshirt-red-m-yahoo	サブコードで派生

この紐付けマスタが1箇所でも間違っていると、その商品の在庫は永遠にズレ続けます。「Mサイズの在庫を更新したつもりが、Lサイズに送信されていた」「楽天SKUプロジェクト移行時に紐付けが切れていた」――こうした事故は、現場では日常茶飯事です。

5原因4：キャッシュ・CDN・人力更新の混在

もう一つ見落とされがちなのが、API以外の経路で在庫が更新されるケースです。「在庫管理システムが正しく動いているのにズレる」原因の半分は、ここにあります。

表示キャッシュによる遅延

各モールの商品ページは、表示速度のためにCDN（コンテンツ配信ネットワーク）でキャッシュされています。在庫がAPIで更新されても、古いキャッシュが残っている間はゼロ在庫の商品ページが表示されたままです。お客様が「あれ、在庫あるじゃん」とポチった瞬間、内部的には在庫不足で売り越し――というシナリオが頻発します。

人力更新と自動更新の競合

在庫管理ツールが裏で自動更新している横で、人がモール管理画面から手動で在庫を直すケースもよくあります。

「自動更新と手動更新、どちらを正解とするか」の運用ルールが決まっていないと、この衝突は無限に起きます。在庫マスタは1つに絞り、手動修正は必ずマスタ側で行うのが鉄則です。

セット商品・予約販売・FBA移管中の特殊在庫

さらに以下のような「特殊な在庫状態」が混じると、APIだけでは管理しきれなくなります。

• セット商品：「Aを1個＋Bを1個＝セットC」の構成。AかBの在庫が減ると、セットCの在庫も連動して減らす必要
• 予約販売：未来日付の在庫を売る形態。実在庫とは別カウントが必要
• FBA移管中：自社倉庫からAmazon FBA倉庫へ移送中。どちらにもカウントできない宙ぶらりん期間
• 引当済み・出荷待ち：「注文は確定したが出荷前」の在庫。実在庫からは引いて、販売可能在庫からも引く

これらを「物理在庫」と「販売可能在庫」を分けて管理できているかどうかが、運用のレベルを決めます。在庫管理ツールの設定が「物理在庫＝販売可能在庫」のままだと、必ずどこかで歪みが出ます。

6原因5：在庫管理ツール側の限界

「ツールを変えれば解決する」と期待する方が多いですが、市販の在庫管理ツールには共通の限界があります。これを知らないと、ツールを乗り換えても同じ問題が起き続けます。

市販ツールの典型的な制約

制約	内容	結果として起きるズレ
更新間隔	「5分おき」「10分おき」など固定	注文発生〜他モール反映まで最低5分のラグ
API制限への配慮	各モールのレート制限を守るため、更新を遅らせる	大量SKU運営では1周に1時間以上かかることも
順次処理	SKUを1つずつ順に更新	人気商品の更新が後回しになる
エラー時のリトライ	失敗したSKUは次回更新まで放置	特定SKUの在庫が長時間ズレ続ける

「リアルタイム同期」という言葉のトリック

在庫管理ツールの広告でよく見る「リアルタイム在庫同期」という言葉。実際には「ほぼリアルタイム」「業界最速の1分間隔」程度を意味することが多く、本当の意味でのリアルタイム（ミリ秒単位）は技術的に不可能です。

7売り越しを最小化する実務設計

ここまで「完全な同期は不可能」と書いてきました。では諦めるしかないかと言えば、そんなことはありません。完全ゼロは無理でも、運用設計次第で売り越し件数を1/10以下に抑えることは可能です。

設計1：「予備在庫」をモール側に残す

最もシンプルで効果的なのがこれ。実在庫から「予備分」を引いた数値をモールに送信する方法です。

こうしておけば、API遅延中に複数モールで注文が入っても、3個分の余裕で吸収できます。動きの早い商品ほど予備在庫を多めに、動きの遅い商品は予備ゼロでもOK――というように、SKUごとに調整するのが理想です。

設計2：在庫が減ったら一気に「ゼロ」にする

「在庫1〜2個」になった瞬間に、強制的にゼロ在庫としてモールに送信する設計。残り1個を売り損なうデメリットはありますが、売り越しキャンセルによる顧客離脱・モール評価ダウンと比べれば、こちらが安いことが多いです。

設計3：在庫管理マスタを1つに絞る

当たり前のようでできていないのがこれ。「在庫マスタは在庫管理システムだけ」と決め、モール管理画面からの手動修正を禁止する運用ルールです。修正したい場合は必ずマスタ側を修正し、自動同期を待つ。ルール化しない限り、人手による上書きは絶対になくなりません。

設計4：SKU紐付けマスタの定期監査

新商品登録時・リニューアル時・終売時に紐付けマスタを更新するルール、加えて月1回は紐付けマスタとモール側の出品データを突き合わせる監査を入れます。「なんとなく動いている」状態を放置すると、必ず数ヶ月後に大事故が起きます。

設計5：売り越し発生時の「即時アラート」

どれだけ予防しても売り越しはゼロにできません。だからこそ、売り越しが発生した瞬間にSlack・メール等で担当者に通知する仕組みが重要です。早期に発見できれば、お客様への謝罪連絡・代替提案・モール評価ダメージの最小化が可能です。

8自社運用の限界と、外部の力を借りる選択肢

ここまで読んでいただいて、在庫同期問題が「ツール選定」の問題ではなく「運用設計」の問題であることがお分かりいただけたかと思います。市販ツールをただ導入するだけでは解決せず、自社のSKU構造・モール構成・業務オペレーションに合わせたカスタム設計が必須です。

• 自社の商品特性に合った予備在庫数の設定
• SKU紐付けマスタの整備と運用ルールの徹底
• 楽天SKUプロジェクト等の仕様変更へのキャッチアップ
• セット商品・予約販売・FBA等の特殊在庫の分離管理
• 売り越し検知・即時通知・原因分析の仕組み化

これらを自社の片手間で設計・運用するのは、想像以上に重い負荷です。さらに厄介なのは、各モールの仕様は年々変わること。一度作った仕組みも、楽天・Amazon・Yahoo!の仕様変更が来れば再設計が必要になります。

もし「マルチモール運営で売り越しが減らない」「SKUプロジェクト対応で在庫管理が崩れた」「在庫管理ツールを乗り換えても問題が続いている」といった課題を抱えているなら、運用全体を一度棚卸しして、自社の状況に合った設計に作り直すのが最も確実な解決策です。

EC現場の実務を知っていて、かつ各モールAPIの仕様まで踏み込んで設計できる人材は多くありません。11年のEC実務経験に基づいて、業務オペレーションとシステム設計を橋渡しできる――それが、mixt-incが在庫管理周りのご相談でお役に立てる部分です。「動いているけど不安定」な在庫運用を根本から見直したい方は、ぜひお気軽にご相談ください。