外部POS・基幹から「販売済み注文」をShopifyへ取り込むときの在庫ずれ防止｜二重減算を防ぐ受注連携監査・テスト台帳
ON THIS PAGE▼
外部POS、基幹システム、OMSで販売・出荷を完了した後、その実績をShopifyへ注文として取り込む運用では、「注文を記録すること」と「Shopifyの販売可能在庫を減らすこと」を同じ処理として扱わないことが重要です。
たとえば、外部注文をShopifyに作成してフルフィルメント済みにしても、その操作だけで期待した在庫変動が起きるとは限りません。逆に、注文作成や既存の在庫同期によってすでに在庫が減っている状態で、別途APIによる在庫調整を実行すれば、同じ販売を二度減らすことになります。
この問題は「Shopifyで在庫が減らない／減りすぎる」という結果だけでは判定できません。販売が起きた場所、在庫の正本、注文作成時点の在庫状態、ロケーション、再送の有無を取引単位で追跡できる設計が必要です。
この記事では、Shopifyの在庫数を物理在庫そのものではなく、Shopify上で販売可否を判断する在庫状態として扱います。外部システムの実在庫とShopifyのAvailable（販売可能在庫）を常に同値にする必要があるかは、在庫の正本をどちらに置くかによって決めます。
本記事の仕様・APIに関する記述は、Shopify公式資料を2026年9月22日時点で確認したものです。導入時は、利用中のShopifyプラン、APIバージョン、連携アプリの挙動もあわせて確認してください。
最初に固定するべきは「どの販売イベントが在庫を一度だけ減らすか」
在庫ずれの調査を始める前に、各販売経路について、在庫を減らす責任を持つイベントを一つに固定します。責任イベントが二つある状態では、担当者が注意しても再送や例外処理で二重計上を防ぎ切れません。
Shopifyの在庫履歴では、注文、アプリ、システム処理による調整を確認できます。注文に伴うCommitted（未フルフィルメント注文に割り当てられた在庫）とAvailableの変化も区別して確認できるため、まずは「どの記録が、いつ、どのロケーションの在庫を動かしたか」を見る必要があります。
フルフィルメント完了と在庫調整は別の判断にする
フルフィルメントは、注文商品をどこから、どの数量、いつ出荷したかを表す処理です。一方の在庫調整は、特定SKU・特定ロケーションの在庫状態を増減させる処理です。
そのため、外部POSで販売済みの取引をShopifyへ取り込む場合、次のように判断を分けます。
| 確認項目 | 判断 | 実施する処理 |
|---|---|---|
| Shopifyの注文作成または既存連携によって、当該販売分がすでに在庫へ反映済みか | 反映済み | 追加の在庫調整はしない。注文・フルフィルメントの記録のみ行う。 |
| 外部販売による減算がShopifyのAvailableへ一度も反映されないか | 未反映 | 対象SKU・ロケーション・数量を特定して、在庫調整を一度だけ記録する。 |
| SKU、ロケーション、販売数量、返品の扱いのいずれかが確定できないか | 判定不能 | 自動調整を保留し、照合キューへ送る。 |
外部POS由来の注文をShopify Flowでフルフィルメント済みにしても在庫が減らず、在庫調整APIを別途検討した相談はShopify Communityにあります。ただし、これは単一の相談であり、すべての連携で同じ動作になる根拠ではありません。自社の注文作成方法、在庫追跡設定、ロケーション割当、既存アプリの処理をテスト環境で確認してください。
在庫の正本別に、減算の責任範囲を決める
「外部で売れたらShopifyも減らす」というルールだけでは不十分です。外部側とShopifyのどちらが在庫の正本かによって、連携の目的が変わります。
外部POS・基幹が在庫の正本である場合
店舗POSや基幹システムが実在庫と引当を管理し、Shopifyはオンライン販売に使える数を参照する構成です。この場合、外部で販売が確定したとき、Shopifyの販売可能在庫にも反映が必要になることがあります。
ただし、次の二つが同時に動いていないかを確認します。
- 外部在庫の残数をShopifyへ定期同期する処理
- 販売済み注文の取込を契機に、Shopify在庫を差分調整する処理
定期同期が絶対数で残在庫を更新し、注文取込が同じ販売数を減算する設計では、処理順によって一時的または恒久的な二重減算が起きます。販売イベント連携と在庫スナップショット同期を併用する場合は、どちらを最終値として採用するか、競合時にどちらを停止・再実行するかを仕様に明記します。
Shopifyが在庫の正本である場合
Shopifyを在庫の正本とするなら、外部POSの販売はShopify在庫を減らすための入力イベントです。この場合も、外部注文をShopifyに作成する処理自体が在庫へ与える影響を確認し、別の調整処理との重複を防ぎます。
特に、外部販売の時点では注文を作らず、日次でまとめてShopifyに取り込む構成では、売り越し許容時間が発生します。即時性を優先するなら販売イベント連携、安定性を優先するなら同期間隔と安全在庫の設定を検討します。どちらにも、連携障害時に手動で販売停止へ切り替える基準が必要です。
在庫を共有していない、または対応付けできない場合
店舗専用在庫とEC専用在庫を物理的・運用上分けている場合、外部POSの販売をShopifyへ減算してはいけないことがあります。また、外部SKUがShopifyの複数バリエーションに対応する、セット品の構成が異なる、販売ロケーションが特定できない場合も、自動減算は保留します。
不明な情報を仮のSKUや既定ロケーションへ寄せて調整すると、後から差異の原因を追えなくなります。対応付け不能の取引は例外として記録し、商品マスタまたはロケーション設計を修正してから再処理します。
受注連携監査台帳で「一取引、一在庫イベント」を証明する
二重減算防止の中心は、外部取引IDをキーにした冪等な記録です。ここでいう冪等とは、通信失敗やジョブ再実行によって同じ取引を複数回受信しても、在庫変動が一回だけになる性質です。
スプレッドシートから始める場合でも、最終的に連携システムのデータベースで管理する場合でも、次の項目を持つ監査台帳を用意します。
| 項目 | 記録内容 |
|---|---|
| 連携イベントID | 自システム内で一意のID。処理単位を識別する。 |
| 外部取引ID | POS・基幹・OMSで発番された、再送しても変わらない取引ID。 |
| 外部明細ID | 部分返品、同一SKU複数行、部分出荷を区別する明細ID。 |
| Shopify注文ID／注文名 | Shopifyへ注文を作成する場合に記録する。 |
| Shopify商品・バリエーションID／SKU | 文字列SKUだけでなく、解決済みの対象を記録する。 |
| 対象ロケーション | 在庫を動かすShopifyロケーション。推測値を使わない。 |
| 在庫イベント種別 | 販売減算、返品増算、取消取消、棚卸差異など。 |
| 判定結果 | 調整要、調整不要、保留、失敗、完了。 |
| 予定数量・実行数量 | 符号を含む数量。販売減算ならマイナス、返品増算ならプラスといった規約を固定する。 |
| Shopify調整の参照情報 | APIの参照URI、調整結果、実行日時、実行者またはジョブ名。 |
| 冪等性キー | 同じ在庫調整要求の再送を識別するキー。 |
| 取消・返品の元取引ID | 元の販売明細へ必ずひも付ける。 |
外部取引IDだけでは不足するケース
一つの取引に複数SKU、部分出荷、部分返品があり得るなら、取引ID単位で「処理済み」にするだけでは不十分です。少なくとも「外部取引ID + 明細ID + 在庫イベント種別」を重複判定キーの候補にします。
再送時は、最初にこのキーで完了済みのイベントを検索します。存在すればShopifyへの新規調整は行わず、既存の実行結果を返します。失敗中または結果不明の場合は、先にShopifyの在庫調整履歴とAPI応答を照合してから再実行します。
取消では、販売減算が実行済みかどうかを確認してから戻します。販売分が未反映なのに取消だけを増算すると、在庫が過大になります。返品も同様で、返品受付、倉庫到着、販売可能への戻し入れを一つの出来事とみなすかは、返品運用に合わせて定義します。
Admin APIで在庫を調整する場合の実装要件
Shopify Admin GraphQL APIのinventoryAdjustQuantitiesでは、ロケーションごとに在庫数量を増減できます。公式ドキュメント上、このミューテーションにはwrite_inventory権限が必要で、調整理由とreferenceDocumentUriを記録できます。
referenceDocumentUriには、監査台帳または社内受注詳細を示す、権限管理されたURIを設定する設計が有効です。個人情報をURLのクエリ文字列などに含めないようにします。調整の理由も、単に「adjustment」とせず、外部販売、返品、棚卸差異など、自社のイベント分類と対応する値を使います。
2026年4月以降のAPIでは、inventoryAdjustQuantitiesに対する冪等性キーが必須と案内されています。キーの形式や指定箇所は利用するAPIバージョンと公式ドキュメントで実装時に再確認し、同一の監査イベントでは再送しても同じキーを使う設計にしてください。
実装前に決める四つの検証
API呼び出しを作る前に、次を仕様書に書きます。
- 増減対象：Shopifyで追跡する在庫状態、商品バリエーション、ロケーションをどのマスタで確定するか。
- 重複判定：外部取引ID、明細ID、イベント種別、数量変更をどう比較するか。
- 失敗時の扱い：タイムアウト時に「未実行」と断定せず、API結果・在庫履歴・台帳を照合する手順。
- 手動調整との競合：棚卸しや倉庫移動による手動調整と連携イベントが同日に発生した場合の優先順位と担当者。
Shopify Flowは業務の振り分けや通知には利用できますが、フルフィルメントの状態変更を在庫減算の代替と決めつけないことが必要です。Flowを起点にAPIを呼ぶ構成でも、上記の重複判定と調整履歴の照合は連携側で担保します。
公開前テストは「在庫数」ではなく履歴と再送結果まで確認する
テスト注文では、処理直後の在庫数だけを見て合格にしないでください。テスト終了時に数量が偶然一致していても、販売減算と取消増算が二重に起きて相殺されている可能性があります。
Shopifyでは、商品またはバリエーションごとの在庫調整履歴を確認できます。また、在庫レポートには未フルフィルメント注文に対するCommitted inventoryや、在庫状態の変更を確認するInventory adjustment changesが含まれます。テスト台帳とこれらの履歴を、SKU・ロケーション・時刻・数量・参照情報で突き合わせます。
最低限実施するテストケース
| ケース | 期待結果 |
|---|---|
| 外部で1点販売し、Shopifyへ初回連携 | 仕様上必要な場合だけ、対象ロケーションで1点分の在庫イベントが一回記録される。 |
| 同じ外部取引を同じ内容で再送 | 新たな在庫イベントを作らず、初回結果を返す。 |
| API応答取得前に通信が切断された想定 | 再送前に履歴・台帳を照合し、実行済みなら追加減算しない。 |
| 一部数量だけ出荷 | 出荷明細と一致する数量だけを処理し、未出荷分を減算しない。 |
| 販売後に全量取消 | 元の販売減算が確認できる場合に限り、同数量を戻す。 |
| 一部返品 | 元の明細を参照し、返品確定数量だけを戻す。 |
| SKU未対応またはロケーション不明 | 在庫を動かさず、保留として台帳・通知に残る。 |
合格条件は「最終在庫が想定値」であることに加え、各ケースで次を満たすことです。
- 監査台帳に外部取引ID、対象SKU、ロケーション、数量、判定結果、参照情報が残る
- Shopifyの履歴で、期待した在庫イベントだけを確認できる
- 同一イベントの再送で、在庫イベント数が増えない
- 保留ケースが自動減算されず、担当者が確認できる
日次照合では、差異の発見と再処理を分離する
本番後は、在庫数を直接書き換えて差異を解消する前に、原因となる取引を特定します。差異調整だけを先に行うと、連携の再送や返品処理が後から到着した際に、再び差異が広がるためです。
日次または運用に合う頻度で、少なくとも以下を照合します。
- 外部側で確定した販売・取消・返品明細数
- 監査台帳で完了、保留、失敗となっているイベント数
- Shopifyの在庫調整履歴にある対象ロケーション・数量・参照情報
- ShopifyのCommitted inventoryと、未処理または未出荷の注文
- SKUまたはロケーション未対応で保留された取引
差異が見つかった場合は、外部取引 → 監査台帳 → Shopify注文／調整履歴の順に追います。先に在庫数だけを修正せず、「減算漏れ」「二重実行」「SKU対応誤り」「ロケーション誤り」「取消・返品の順序不整合」のどれかを記録します。
この記録が残れば、障害時に在庫を復旧するだけでなく、次回から自動調整を止めるべき条件や商品マスタを修正すべき条件も判断できます。外部注文の取込を増やす前に、少数のSKU・一つのロケーション・取消を含むテストから始め、台帳と履歴で一回だけ動いていることを確認してから対象を広げてください。
参考情報
この課題、もっと詳しく相談したい方へ
記事では答えきれない個別の状況にもお応えします。