Shopifyと倉庫の在庫が合わないのはなぜ？売り越しを防ぐ連携の考え方

倉庫に十個あっても、十個売ってよいとは限らない

説明用の例として、倉庫に十個の商品があり、うち二個は出荷する注文に割り当て済み、一個は返品の検品待ちとします。ほかの条件がなければ、新たに売れる候補は七個です。十個をそのまま販売在庫として送ると、既に用途が決まった商品まで売りに出します。数が合わないときは、まず同じ状態の数量を比較しているか確かめます。

Shopifyにもavailable、on_hand、committedなどの在庫状態があります。倉庫側が返す数量には何が含まれ、何が引かれているかを確認し、対応を決めます。返品は返金した時点と再販売できる時点が違うこともあります。在庫の式は技術担当だけで決めず、検品や引当を行う物流担当と一緒に確かめる必要があります。

参考：Shopify：Manage inventory quantities and states

同じ商品コードでも、更新する場所が違うかもしれない

在庫は商品だけでなく、どの拠点で管理しているかと組み合わせて扱います。Shopifyの在庫アイテムとロケーションを、倉庫側の商品と拠点へ対応させます。商品名やSKUが似ているだけで結び付けると、再登録した商品や別倉庫の数量を書き換えるおそれがあります。商品コードの変更時にも、同じ商品として続けて扱うかを決めます。

セット商品、予約商品、店舗と共用する在庫は別に確認します。部品の残数からセットの販売可能数を求めるなら、通常商品の単純な数量コピーでは足りません。既存の連携アプリがある場合は、同じ商品や拠点を更新していないかも調べます。一つの数量を複数のアプリが別々に修正すると、正しい変更を上書きする原因になります。

参考：Shopify：Manage inventory quantities and states

一件の注文で、在庫を二度減らしていないか

説明用の例として、注文時にShopifyの販売可能数が減り、その注文を受けた倉庫も引当後の数量を返す連携を考えます。倉庫の値は既に同じ注文を含んでいるのに、さらに注文分を引けば二重控除になります。逆に、注文をまだ含まない古い倉庫の数量で上書きすると、売れた分を販売可能数へ戻すことになります。

必要なのは、何時の数量かに加え、どの注文まで倉庫へ反映されたかの記録です。未反映の注文がある間は保留する、反映状況を確認して販売可能数を計算するなど、更新の条件を設計します。販売経路が複数なら、各経路の引当も対象です。安全在庫として一部を販売に出さない案もありますが、数量は商品の動きと許容する販売機会の減少から判断します。

「今の数にする」と「入荷分を足す」は違う処理

倉庫が全体数量を確定できるなら絶対数量を設定する案があり、入荷の変化だけを伝えるなら増減を反映する案があります。ShopifyのinventorySetQuantitiesは、在庫の正本となるシステム向けの操作として案内されています。数量を設定する場合も、取得後に販売が進んでいれば古い値になります。比較条件で競合を検知し、最新の業務状態から計算し直すことを検討します。

2026年10月7日の公式資料確認では、inventorySetQuantitiesはAPIバージョン2026-04以降、@idempotentによる冪等キーが必須です。これは同じ要求の再送対策であり、別の注文を反映した新しい数量との競合対策とは役割が異なります。比較が合わなかったときに無条件で上書きせず、理由を調べられることまで開発範囲に含めます。

表が収まらない場合は横にスクロールできます。

参考：Shopify：inventorySetQuantities - GraphQL Admin

通知で早く反映し、照合で漏れを探す

変更通知を使えば、変化に合わせて在庫を更新できます。ただしShopifyのWebhookは到着順や配送だけに依存できず、公式資料は定期的な照合も勧めています。通知を受けて必要な商品を確認する経路と、通知が欠けても差分を見つける経路を分けると、速さと確認を両立しやすくなります。

照合で差が出ても、倉庫の値を押し込めば解決するとは限りません。未連携の注文、棚卸し、商品対応の誤りなら、まず原因を確かめます。差分には取得時刻と反映済みの注文、保留理由を添えます。原因が説明できる範囲だけ自動補正し、それ以外は商品単位で止める設計なら、原因不明の変更を全商品へ広げずに済みます。

参考：Shopify：Best practices for webhooks

連携アプリと個別開発は、扱う在庫ルールで比べる

既存アプリを試すなら、普段の入荷だけでなく、返品、取消、棚卸し、複数拠点での販売を再現します。自社の状態と商品対応を設定でき、差分の調査も運用できるなら候補になります。個別開発が必要なのは、変更できない倉庫側の形式や、独自の引当計算などが残る場合です。アプリ利用料と開発費に加え、倉庫追加や障害時の調査を誰が担うかも比較します。

導入は、読み取りと差分確認から始め、商品・拠点を絞った書き込みへ進めます。物流担当と販売担当が同じ取引を追い、古い数量の到着や通信切断も試します。APIにはバージョンのサポート方針があるため、公開後の更新確認と移行試験も担当を決めます。まず数字の違いを説明できる状態を作ることが、手で合わせ続ける運用から抜ける一歩です。

参考：Shopify：About Shopify API versioning

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □倉庫の数量に引当や検品待ちが含まれるか確かめる。確認状況・メモ：
• □商品・在庫アイテム・拠点・ロケーションを対応させる。確認状況・メモ：
• □同じ数量を更新する既存アプリや手作業を探す。確認状況・メモ：
• □どの注文まで反映した数かを追えるようにする。確認状況・メモ：
• □採用API版の比較条件と冪等キー要件を確認する。確認状況・メモ：
• □差分確認から対象を絞った書き込みへ進める。確認状況・メモ：
• □返品・取消・棚卸しを物流担当と試す。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• Manage inventory quantities and statesShopify
• inventorySetQuantities - GraphQL AdminShopify
• Best practices for webhooksShopify
• About Shopify API versioningShopify