1「在庫が合わない」は、現場の永遠のテーマ

楽天・Amazon・Yahoo!ショッピング・自社EC――4チャネルで運営しているEC店舗で、「在庫が完全に一致している瞬間」を見たことがある人は、ほぼいません。常にどこかが1個ずつズレています。

この「ズレ」が業務に与える被害は、想像以上に大きいです。

「ネクストエンジン入れたから大丈夫でしょ？」――それでもズレます。「APIで毎分同期してます」――それでもズレます。多店舗の在庫同期は、構造的に「100%一致」にはならない領域なのです。

本記事では、なぜ在庫がズレるのか、その7つの構造的原因と、手動運用・SaaS導入・自作API連携の3つの選択肢を、それぞれどの規模・どのフェーズで選ぶべきかを11年のEC実務経験から整理します。「とりあえずネクストエンジン」と「とりあえず自作」のどちらにも倒れず、自社にとっての現実解を見つけるための地図にしてください。

2在庫がズレる7つの構造的な原因

在庫がズレる原因は、たいてい「APIの反映が遅い」で片付けられがちです。が、現場で本当に効いているのはもっと深いところにあります。

原因① モール側の在庫反映ラグ

これが一番有名な原因です。各モールのAPIには「叩いてから反映されるまでの遅延」があります。

モール	在庫API	典型的な反映遅延	備考
楽天	RMS WEB API（在庫一括更新）	数秒〜数分	更新件数が多いとキューが詰まる
Amazon	SP-API（FBM在庫）	5〜15分（フィード処理待ち）	FBA在庫はAmazon側管理で別ロジック
Yahoo!	ストアクリエイターProのAPI	数分	更新成功＝即反映ではない

「分単位の遅延」は、人気SKUなら売り越しが起きる十分な時間です。

原因② 注文確定タイミングのズレ

もっと厄介なのが、「注文が入った瞬間に在庫を引き当てるタイミング」がモールごとに違うことです。

• 楽天：購入手続き完了で受注確定 → 在庫引き当て
• Amazon：注文成立後にAPIで取得可能になるまでタイムラグあり
• Yahoo!：注文確定→在庫減算のタイミングがストア設定で変わる

結果として、「楽天で売れた瞬間にはAmazonの在庫がまだ更新されていない」という時間帯が必ず発生します。残り在庫が1個のSKUは、特にここで売り越しになります。

原因③ APIレート制限

各モールのAPIには呼び出し回数制限があります。SKU数が多い店舗ほど、ここに当たって在庫更新が追いつかなくなります。

• 楽天 RMS API：商品APIごとにリクエスト数上限あり、超過で429エラー
• Amazon SP-API：エンドポイントごとに「リクエスト/秒」「バーストサイズ」が個別設定。詳細は Amazon SP-APIの罠 参照
• Yahoo!：1秒あたり数リクエストの上限あり

3,000 SKUを5分ごとに全更新したいと思っても、API制限にぶつかって全部終わるのに30分かかるみたいな状況は普通に起きます。

原因④ SKU紐付けの崩れ

これは在庫同期の「最大の地雷」です。各モールでSKUコードがバラバラに採番されている店舗は、「楽天のSKU 0001」と「AmazonのASIN B0XXX」と「自社ECのSKU 0001-A」が本当に同じ商品を指しているかが、人間の頭の中にしかありません。

SKU設計が崩れていると、どんなに高機能なツールを入れても在庫は合いません。SKU設計は「SKU設計のルール」で深掘りしています。

原因⑤ 楽天 SKUプロジェクトの影響

楽天が進めているSKUプロジェクト（バリエーション項目→SKU管理への移行）は、在庫同期に大きな影響を与えています。商品ID（item_url）単位での在庫管理から、SKU単位の在庫管理へと構造が変わっており、既存の一元管理ツールやAPI連携の作り直しが必要になっています。

「ある日突然、楽天の在庫だけ反映されなくなった」――SKUプロジェクト移行を機にAPIエンドポイントが変わり、古いままだった、というケースを2025年以降で何度も見ています。

原因⑥ キャンセル・返品時の在庫戻し漏れ

注文時の在庫減算は自動化されていても、キャンセル・返品時の在庫戻しが手動運用で残っている店舗が多いです。1日5件のキャンセルを毎日取りこぼせば、月150件分の在庫差異になります。これが半年積もると、棚卸しで「実在庫と帳簿が100個合わない」という事態になります。

原因⑦ 「ゼロ在庫表示」の罠

意外な落とし穴がこれです。「在庫切れ」の表示方法が、各モールで違うのです。

• 楽天：在庫0でも商品ページが残る（在庫切れ表示）。SEO評価が下がるため意図的に商品を非表示にする運用もあり
• Amazon：在庫0で出品が「停止」扱いに。再出品でランキングがリセットされるリスク
• Yahoo!：在庫0表示と非公開のフラグが別で、運用ルールが店舗ごと

「ゼロ在庫を一斉に同期する」だけでは、SEO・ランキング・広告配信に副作用が出ます。「在庫数」と「公開状態」を別軸で同期する設計が必要です。

3選択肢は3つ ― 手動・SaaS・自作の比較

では、どう解決するか。多店舗の在庫同期には、大きく3つのアプローチがあります。

アプローチ	初期費用	月額	同期精度	柔軟性	向いている規模
① 手動運用 （CSV＋目視）	0円	0円 ＋人件費	低	◎	SKU 〜100点／2モールまで
② 一元管理SaaS （ネクストエンジン等）	0〜10万円	1〜10万円	高	△	SKU 100〜10,000点／3モール以上
③ 自作API連携 （独自開発）	100万〜数百万	運用コスト	◎	◎	SKU 10,000点超／特殊要件

① 手動運用の現実

「Excelで在庫リストを管理して、毎朝CSVで全モールに上げる」――SKU 100点くらいまでなら、これで十分機能します。運用コストはほぼ人件費だけで、ロジックも頭の中で組める。SKU設計やCSVの基本ができていれば、立ち上げ初期はこれが一番早いです。

限界が来るのはSKU 200点を超えたあたり。「全モール手動更新」が1日仕事になり、人件費が一元管理SaaSの月額を上回ります。

② 一元管理SaaSの現実

多店舗運営の事実上の標準解がここです。代表的なツールはこの3つです。

• ネクストエンジン　― 国内シェアトップ。受注・在庫・出荷・商品登録まで一気通貫。月額1万円〜＋従量課金
• GoQSystem　― 楽天運営に強い。月額1.5万円〜のオールインワンプラン
• クロスモール　― モール特化型。商品登録・在庫同期に強み

注意点として、SaaSも「100%一致」を保証してはくれません。APIレート制限、反映遅延、SKU紐付けの問題は依然として残ります。SaaSが解決してくれるのは「これらの問題に対する標準的な対応」を肩代わりしてくれることであり、運用ルールを店舗側で設計する必要は変わりません。

③ 自作API連携の現実

「SaaSでは要件が満たせない」場合の最終手段。SKUが10,000点を超え、独自の在庫引き当てロジック（実店舗との連動、海外倉庫からの直送、複数倉庫の優先順位付けなど）が必要になると、ここを検討せざるを得ません。

個人事業や中小EC店舗なら、自作はほぼ「悪手」です。よほど特殊な要件がない限り、SaaSで7〜8割を解決し、残りをスクリプトで補完する「ハイブリッド型」が最も費用対効果が高い構成になります。

4規模別の現実解 ― あなたの店舗はどれか

「結局うちはどれを選べばいいのか？」――この問いに、規模・モール数・SKU数別の現実解を示します。

フェーズA：1〜2モール／SKU 〜100点

手動運用 + 安全在庫の余裕設定で十分です。各モールの在庫を「実在庫より少し少なめ（例：実在庫の80%）」に設定して、売り越しリスクを構造的に下げる方法が有効です。

フェーズB：2〜3モール／SKU 100〜1,000点

ネクストエンジン or GoQSystem の導入推奨。月額1〜3万円ですべての一元化が回ります。「自作したい」気持ちはこの段階では我慢しましょう。

フェーズC：3モール以上／SKU 1,000〜10,000点

SaaS + 業務スクリプトのハイブリッド。SaaSの標準機能では足りない部分（特殊な引き当て、限定商品の出し方、独自レポート）を、Google Apps Script・Python・社内SQLで補完します。「全部SaaS」も「全部自作」も極端で、この層は組み合わせが王道です。

フェーズD：年商10億超／SKU 10,000点超／海外含む

自作API連携 or 大規模OMS導入を本格検討するフェーズ。エンジニアチーム必須。SaaSを「在庫マスター」とせず、「データを集約するハブ」として使うアーキテクチャが多くなります。

5「100%一致」を諦めて、被害を最小化する設計

ここまで読んでいただいた方ならわかると思いますが、多店舗の在庫を100%一致させることは構造的に不可能です。APIの遅延・タイミングのズレ・レート制限がある以上、必ずどこかでズレが発生します。

本当に大事なのは「ゼロにすること」ではなく、「ズレが起きたときの被害を最小化する設計」です。

設計1：安全在庫を構造的に持つ

各モールに公開する在庫数を、実在庫より一定割合少なく設定する運用です。例えば実在庫100個のSKUを、各モールには80個ずつ表示。残り20個分は「ズレが発生したときの吸収余地」として温存します。「機会損失」と「売り越し被害」のどちらを取るかの選択ですが、人気SKUほど売り越しの被害（評価ダウン・キャンセル対応工数）が大きいため、安全在庫を厚めに取る方が結果的に得です。

設計2：人気SKUと裾野SKUで運用を分ける

すべてのSKUに同じ更新頻度を設定する必要はありません。売れ筋上位20%のSKUだけ「分単位」で同期し、残り80%は「時間単位」「日次」で十分。APIレート制限の中で、本当に守るべきSKUを優先する設計です。

設計3：在庫アラートを業務に組み込む

「在庫が0になった」「売り越しが発生した」「在庫数が想定を超えてズレている」――こうした異常を、担当者のSlack・LINE・メールに自動通知する仕組みを入れます。「SaaSの管理画面を毎日見に行く」前提では、必ず見落とします。

設計4：棚卸しの定期化

どんなに自動化しても、3〜6か月に1回の実地棚卸しは必須です。帳簿在庫と実在庫のズレが、どの程度の幅で発生しているかを定期的に把握しないと、本当の異常に気づけません。

6在庫同期の「現実解」を一緒に作りませんか

本記事の整理を要約します。

• 多店舗の在庫がズレる原因は、API遅延だけではなく7つの構造的要因がある
• 「100%一致」は構造的に不可能。被害最小化の設計が現実解
• 選択肢は手動／SaaS／自作の3つ。規模とフェーズで最適解が変わる
• 多くの中規模ECは「SaaS＋業務スクリプト」のハイブリッドが最適
• 安全在庫・優先度別更新・アラート・棚卸しの4点で被害を最小化

とはいえ、「うちはどのフェーズなのか」「ネクストエンジン入れたけど運用が回らない」「自作したいが工数が読めない」――こういった個別事情は店舗ごとに違います。11年のEC実務経験から、自社の規模・モール構成・SKU数に合わせた在庫同期の設計を一緒に作ることもできます。

関連記事として、在庫同期の技術的な構造は「開発あるある「在庫同期のズレ」」、Amazon側の制約は「Amazon SP-APIの罠」、SKU設計は「SKU設計のルール」、自動化全体の進め方は「EC自動化、何から始める？ ― ROI順に並べた7つの着手領域マップ」もあわせてどうぞ。

「在庫が合わない」「売り越しが止まらない」「SaaSの限界を感じている」――そんな課題があれば、お気軽にご相談ください。