Shopifyの在庫同期アプリを停止・再設定するときの復旧設計｜商品・SKU・ロケーション別在庫を守るスナップショットと差分照合台帳

まず決めるべきは「元に戻す」ではなく「何を正本にするか」

Shopifyの在庫同期アプリを削除、接続解除、または接続先を切り替える作業では、アプリを止めること自体よりも、異常が起きた後の判断が難所になります。

たとえば停止後に在庫が0になったとしても、削除前のCSVをそのままインポートすればよいとは限りません。停止時点から復旧時点までに発生した注文、返品、入荷、倉庫移動、棚卸し調整まで削除前の数量で上書きすると、今度は実在庫と販売可能数がずれます。

この作業は「アプリ削除」ではなく、商品マスタと在庫の変更管理・復旧作業として設計します。復旧の正本を、次の4層に分けると判断を記録しやすくなります。

1. 商品マスタの基準：商品ID、ハンドル、バリエーション、SKU、商品ステータス
2. Shopify在庫の基準：SKU・ロケーション・在庫状態ごとの数量
3. 接続先システムの基準：POS、WMS、基幹、仕入先システムなどの停止直前エクスポート
4. 停止後に生じた正当な変動：受注、返品、入荷、移動、棚卸し、手動調整

ここでいう「正本」は、常に外部システムとは限りません。たとえば、倉庫の実在庫をWMSで管理しているならWMSが数量の正本になり得ます。一方で、複数ロケーションの一部だけを外部システムで管理し、店舗在庫はShopifyで調整しているなら、SKU・ロケーション単位で正本が分かれます。

したがって、作業前に「この連携では、どのSKUのどのロケーションを、どちらが更新してよいか」を表にします。同期方向を「Shopify→外部」「外部→Shopify」「双方向」とだけ書くのでは不十分です。対象外SKU、対象外ロケーション、在庫を追跡しない商品、バンドル商品も明記してください。

作業対象をSKUだけで管理しない：ロケーションと在庫状態まで固定する

在庫同期の復旧台帳でSKUだけをキーにすると、複数ロケーションを使う店舗では判定できません。同じSKUでも、倉庫Aでは在庫があり、店舗Bでは0である状態は通常あり得ます。

Shopifyの在庫CSVでは、ロケーション別の在庫をエクスポートできます。また、全在庫状態を含むCSVを扱うことで、偶発的な上書きに対する保護を利用できる仕様があります。CSVのインポート時には、エクスポート時点の値と現在値を比較する安全検証が行われます。仕様確認時点は2026年10月9日です。Shopifyの在庫CSVに関する公式ヘルプを、実作業前にも確認してください。

台帳の最小単位は、次のように設計します。

「在庫0」は必ずしも障害ではありません。在庫切れ、販売停止、特定ロケーションへの未配賦、予約・引当など、意図した結果である可能性があります。逆に、販売可能数だけを見て問題がないと判断するのも危険です。連携対象の在庫状態と、ストアフロントで販売可否に使う状態を、アプリ設定とShopify設定の両方で確認します。

削除・接続解除の前に取る4種類のスナップショット

Shopify公式は、アプリをアンインストールする前に必要なデータをエクスポートするよう案内しています。また、アプリが管理するロケーションの在庫は、移管または削除が必要になる場合があります。アプリを再インストールしても、以前の設定やデータが復元されない場合がある点も前提にします。仕様確認時点は2026年10月9日です。アプリ削除に関するShopify公式ヘルプを確認してください。

1. 商品マスタのスナップショット

Shopifyから商品CSVをエクスポートし、ファイル名に店舗名、対象範囲、タイムゾーン付きの取得時刻を入れます。

products_before_inventory_sync_stop_2026-10-09_2130_JST.csv

確認する項目は、少なくとも以下です。

• 商品ハンドル、商品タイトル、商品ステータス
• バリエーション名、SKU、バーコード
• 商品ID・バリエーションIDを別途取得できる場合はその値
• 在庫追跡の有無
• 販売チャネルへの公開状態

商品CSVはバックアップや一括編集に使えますが、復旧用の原本をそのまま編集用ファイルにしないでください。Shopifyは、CSVを並べ替えて再インポートするとバリエーションや画像URLの対応に影響し得ると案内しています。原本は読み取り専用で保管し、加工・復旧検証は複製ファイルで行います。仕様確認時点は2026年10月9日です。商品CSVのエクスポートに関するShopify公式ヘルプを参照してください。

2. Shopify在庫のスナップショット

ロケーション別・全在庫状態のCSVをエクスポートします。対象を絞る場合でも、切替対象外のSKUやロケーションが混ざっていないか後で確認できるよう、可能なら全件原本も保存します。

このファイルは「復旧インポート用」ではなく、まず停止直前の事実を示す証跡です。インポートを前提に列削除、行削除、並べ替えを行わない原本を残してください。

3. 外部システムとアプリ設定のスナップショット

外部システム側でも、対象SKU・拠点・利用可能在庫・予約在庫など、同期に使う数量をエクスポートします。取得時刻、タイムゾーン、抽出条件を記録します。

加えて、アプリ画面の次の設定を画面保存または設定エクスポートで残します。

• 同期方向と優先システム
• 対象ロケーション、対象SKU、除外ルール
• 数量フィールドの対応関係
• 同期頻度、手動同期・一括同期の実行権限
• SKU作成・更新、商品作成・更新を許可する設定
• バンドル、セット品、複数在庫地点の計算ルール

設定を再現できない場合、アプリの再設定後に同じ同期が再開する保証はありません。削除前の画面保存は、障害調査だけでなく、新しい接続で旧設定を無批判に再現しないためにも役立ちます。

4. 停止後変動を記録する台帳

T0以後に在庫へ影響する業務を、通常の運用と分けて記録します。完全に業務を止められないなら、この台帳が復旧可否を左右します。

停止の順番：同期を止めてから権限・ロケーションを変える

停止手順はアプリごとに異なります。そのため、アプリ独自の「切断」「同期停止」「初回同期」「全件同期」の挙動は、提供元の手順で確認してください。そのうえで、Shopify側で守る順番は次のようにします。

1. 作業時間帯と販売継続・停止の判断者を決める
2. T0直前の4種類のスナップショットを取得する
3. 外部システム側で自動同期・スケジュール実行を停止する
4. アプリ側で自動同期、キュー、再試行、一括同期を停止する
5. Shopify側で最終同期時刻と対象件数を記録する
6. T0を宣言し、停止後変動台帳の記録を開始する
7. 接続解除またはアプリ削除を行う
8. アプリ管理ロケーションの在庫の移管・削除要否を確認する
9. Shopify・外部システムの双方で、意図しない更新が止まったことを確認する

アプリ削除後にアプリ管理ロケーションを先に消すと、そのロケーションに残る在庫を比較しにくくなります。公式案内に従い、在庫をどのロケーションへ移管するか、不要なら削除するかを決めてから作業します。

販売を継続する場合でも、対象SKUについては一時的に販売チャネルから外す、または注文を手動確認する運用を検討します。ただし全商品を一律に非公開にする必要はありません。誤った在庫で販売する影響、停止中の受注処理能力、対象SKUの重要度を踏まえ、対象範囲を限定して決めます。

異常時はCSVを即時に戻さず、差分を3区分に分ける

停止・再設定後に数量やSKUの変更が見つかった場合、最初にすることはCSVの再インポートではありません。差分を抽出し、原因と復旧方法を分けます。

Shopifyでは在庫調整履歴から、変更日時、変更者、アプリ、在庫状態などを確認できます。直近180日を超える分析には在庫調整変更レポートを使う案内があります。仕様確認時点は2026年10月9日です。在庫調整履歴に関するShopify公式ヘルプを参照してください。

区分A：アプリ起因が疑われる差分

次のような差分は、該当アプリや連携処理の記録と照合します。

• T0直後に多数SKUの数量が同時刻に変わった
• 特定の連携対象ロケーションだけが0または異常値になった
• 在庫調整履歴にアプリ名が表示される
• SKU、バーコード、商品ステータスがT0前後で変わった

この区分でも、削除前の数量をそのまま適用するのではなく、T0後の正当な変動を加味します。数量を外部システムで復旧するのか、Shopifyで調整するのかは、当該SKU・ロケーションの正本ルールに従います。

区分B：業務上の正当な変動

注文、キャンセル、返品、入荷、移動、棚卸しと一致する差分は、異常として戻しません。停止後変動台帳の根拠と一致するかを確認します。

復旧の考え方を式にすると、概念上は次の通りです。

復旧候補数量 = T0時点の正本数量
             + T0後の入荷・返品・増数調整
             - T0後の出荷・減数調整
             ± 実棚差異

ただし、予約在庫や利用可能在庫の扱いは利用中の在庫状態・アプリ仕様で変わります。この式だけでCSVを作らず、どの状態を更新するかを先に確認してください。

区分C：実棚または業務確認が必要な差分

外部システム、Shopify履歴、伝票のいずれとも一致しない差分は、数値の推測で埋めません。対象SKUを販売停止または受注確認対象にし、実棚・倉庫照会・未処理入荷の確認に回します。

SKUが書き換わった場合は、SKU文字列だけで旧SKUと新SKUを結び付けないことも重要です。商品タイトル、バリエーション属性、バーコード、商品IDやバリエーションID、外部システムの品番を組み合わせ、対応表を作ります。新SKUが既存SKUと重複する場合は、商品CSVの再インポートより前に重複解消の方針を決めます。

復旧・再設定・販売再開を分離して承認する

復旧が終わったかどうかを「アプリが再接続できた」で判断しません。数量復旧、マスタ復旧、同期再開、販売再開にはそれぞれ別の完了条件があります。

復旧の実行順

1. 差分台帳から復旧対象SKU・ロケーションを確定する
2. 商品・SKUの変更が必要なら、少数件で対応表と影響を確認する
3. 在庫は正本側で修正し、必要な側へ反映する
4. Shopify在庫調整履歴で反映時刻・実行者・アプリ名を確認する
5. Shopifyと外部システムで、対象SKU・ロケーションの値を再照合する
6. 新しい連携設定をテスト対象だけで有効化する
7. テスト結果を確認後、対象を段階的に広げる

在庫CSVは、全件を一度に復旧するより、差分対象に絞って検証するほうが影響範囲を確認しやすくなります。ただし、CSVの安全検証を回避するために列や値を恣意的に加工する運用は避けてください。検証メッセージが出た場合は、現在値がスナップショット取得後に変わった理由を差分台帳で確認します。

販売再開の判定表

特に再設定直後は、「全件同期」「初回同期」がどちらの数量を優先するかを確認してから有効化します。検証用SKUまたは限定ロケーションで結果を確認できるなら、全対象を一度に同期させるより安全です。アプリの仕様上、限定テストができない場合は、販売影響が小さい時間帯に実施し、ロールバック判断者と連絡経路を明示します。

作業記録を残すと、次回の切替コストを下げられる

この種の作業では、障害が起きなかった場合にも記録を残す価値があります。次回のアプリ変更時に必要なのは「何となく問題なかった」という記憶ではなく、どの範囲をどの順で止め、どの値を照合したかです。

最低限、次を1つの作業記録にまとめます。

• 作業目的、対象アプリ、対象ストア、担当者、承認者
• T0、取得したCSV名、保存先、タイムゾーン
• 同期方向とSKU・ロケーション別の正本
• 停止・削除・再設定を行った時刻
• 検出した差分と3区分の判定根拠
• 実施した在庫調整、SKU修正、販売停止・再開の記録
• 再開後の確認結果と、残課題・例外SKU

在庫同期アプリの停止は、アプリを消すだけの作業ではありません。削除前のスナップショット、T0後の業務変動、ロケーション別の正本、再開条件を分けて管理すれば、異常時にも「どの数値に戻すか」を推測だけで決めずに済みます。

参考情報

• Shopify Help Center｜Uninstalling apps
• Shopify Help Center｜Exporting and importing inventory with a CSV file
• Shopify Help Center｜Viewing inventory adjustment history
• Shopify Help Center｜Exporting products