在庫・出荷・システム
ECカート・受注管理・物流システム移行チェックリスト
記事確認日：
当サイトは広告・アフィリエイトを利用しています。広告掲載について
商品や顧客が新しい画面に表示されても、決済や出荷まで引き継げたとは限りません。カートを移す部分と、受注管理や倉庫へのつなぎ方を変える部分を分け、注文を最後まで確認してから切り替えます。
本記事は、すでに日々の注文や出荷を行っている店舗向けの実務チェックリストです。これから初めて出店する方は、基本的な初期設定をまとめた「Shopifyの始め方」や「初めての注文から発送まで」をご覧ください。
何を移し、何を残す？誰が確認する？
システムを移行するときは、まず商品、顧客、注文、決済、在庫、出荷、通知、会計、計測の各情報を一覧にして、「新環境へ移すもの」「旧環境や手元のファイルで参照用に保管するもの」「新環境でゼロから再設定するもの」の3つに分けます。あわせて、自店の責任者と各サービスの確認担当者を決め、契約や支援にかかる費用を事前に確認しておきます。
ここでは、日本国内向けに布小物を10商品販売している架空の小さな店舗を想定します。担当者1名が日々の注文対応や梱包を続けながら、週に3時間を使って移行準備を進める体制です。外部支援を含む準備支出枠は税込10万円と仮定します（新旧サービスの通常月額利用料、決済手数料、通常の発送実費は除きます）。この予算で不足する場合は、移行範囲や日程を見直す判断基準とします。
バックヤードの仕組みは店舗の運営体制によって変わります。OMS（注文をまとめて管理する仕組み）やWMS（倉庫の在庫と入出荷を管理する仕組み）は、すべての店舗に不可欠なわけではありません。自宅から発送していてWMSを使っていない店舗であれば倉庫連携の作業は対象外ですが、過去の発送履歴をどこで確かめるかは決めておく必要があります。一方、外部倉庫へ委託している場合は、旧倉庫と新倉庫、それぞれのシステム担当者を確認体制へ加えます。
Shopifyの公式移行手順でも案内されているように、移行作業には手動の複製、対応CSVの活用、専用アプリ、専門家への支援依頼、API連携といった多様な選択肢があり、すべてのデータを同じ方法で移せるわけではありません。契約の継続や解約が一律で無料とは限らないため、自店が扱うデータの行き先を一覧表で個別に確認していきます。
商品・顧客・過去注文は、そのまま移せる？
移行作業では、まず移行先が指定する公式の形式に合わせて代表的な1商品を登録し、商品コードや色展開などの種類、顧客情報、過去注文の対応関係を確かめます。CSV（表の項目を保存するファイル形式）が手元にあっても、過去の注文履歴、会員パスワード、クレジットカード情報まで一緒には移せません。
布小物10商品を扱う店舗であれば、色やサイズごとに在庫を管理する単位であるSKU（最小管理単位）を含む代表商品を1つ選び、試験登録を行います。確認する項目は、販売価格、消費税の計算設定、商品重量、SKUごとの在庫数、そして公開・非公開の状態です。
データの取り込み順序にも注意が必要です。Shopifyの公式移行マニュアルでは、データの関連性を保つために「商品」「顧客」「過去注文」の順序でインポートすることが案内されています。
とくに顧客データは、移せる項目が限られます。Shopify公式の顧客インポート手順にあるとおり、標準の顧客CSVでは過去の注文情報、累計の利用合計額や合計注文数、他店で使っていた顧客パスワードをそのまま取り込むことはできません。パスワードの移行対応については、全顧客が一律で再設定必須と決めつけず、採用する顧客アカウント方式に応じた公式案内を確認して案内方法を決めます。
また、クレジットカード情報は契約先の公式な案内に沿って移行できる範囲を確認し、店舗独自のCSVに書き出して直接移すことは避けます。ポイント残高や商品レビューの移行可否も、利用するサービスごとに個別の確認が必要です。すべての過去注文を新システムの管理画面へ無理に投入するのか、それとも過去の照会用として別データで保管するのかを見極めると、作業の肥大化を防げます。
URLが変わるとき、検索と購入導線はどう残す？
カートシステムを乗り換えてページのURLが変更になる場合は、旧URLごとに対応する適切な新URLを決める表を作り、適切な転送と新ページの正常な表示を確認します。検索エンジン向けの設定と、決済画面・自動送信メール・アクセス計測ツールの動作確認は、それぞれ切り離して検証を進めます。
布小物を扱う店舗であれば、10商品の商品ページURL、商品画像、利用規約、お問い合わせ窓口、そして注文確認メールに記載している各種リンクの対応を整理します。内容を統合した適切な新ページへ複数の旧URLを転送する設計は有効ですが、無関係な旧URLをすべて新トップページへ転送することは避けます。Google検索セントラルのサイト移転案内では、URL対応表に基づく301や308などの恒久転送（旧URLから新URLへ案内する設定）、新URLにおけるcanonical（検索エンジンに代表URLを伝える記述）やクロール許可の設定、最新サイトマップ（ページURLの一覧）の送信を案内しています。移転初期には検索順位の一時的な変動が起こり得ることを前提とし、転送設定は一般に1年以上維持することが案内されています。なお、Search Consoleのアドレス変更ツールはドメインやサブドメイン自体が変わる場合に使用するものであり、同一ドメイン内のURL変更では必須ではありません。
なお、カートの画面はそのままで、バックヤードのOMS（受注管理）や倉庫の接続だけを変える場合は、店舗のURL自体は変わりません。転送作業を無理に足す必要はなく、購入完了画面でのアクセス解析やコンバージョン計測が途切れていないかの確認へ注力します。
通常・取消・返品を、どこまでテストする？
システム移行前の試験では、正常に買い物が完了する通常注文だけでなく、出荷前のキャンセルや出荷後の返品までを一連の流れとして確認します。決済、在庫の増減、出荷指示、購入者への通知、会計連携までを対象とし、試験環境での動作と実際の請求や発送の境界を慎重に切り分けます。
試験計画を立てる際は、全体の件数と工程ごとの確認分母を整理します。ここでは業務の流れを把握するため、30件の注文モデル（通常20件、出荷前取消5件、出荷後返品5件）を紙上で想定して期待される記録を整理します。なお、これはShopifyの模擬注文25件を実際に発送したり実返金したりする操作手順ではなく、出荷、通知、返品、会計の実連携試験については、模擬・確認用の記録と実際の発送や課金の境界、試験方法、費用を担当者間で決めて進めます。
| 試験対象の工程 | 確認する分母 | 期待される記録と確認内容 |
|---|---|---|
| 注文生成と取込 | 30件 | 通常20件、取消5件、返品5件の全データが新環境へ取り込まれる |
| 在庫引当と取消処理 | 30件 | 通常＋返品の25件は在庫を引き当て、出荷前取消の5件は引当を解除する |
| 出荷指示・出荷・通知 | 25件 | 通常20件と返品5件の出荷相当記録を確認し、取消5件には出荷指示を出さない |
| 最終状態の照合 | 30件 | 通常20件の売上計上、取消5件の請求取消、返品5件の返金と再販判断を確認する |
もし事前確認の段階で「在庫引当で1件のエラーが未解消」「最終返金の連携で2件が未確認」といった保留結果が出た場合、出荷工程の25件の記録が揃っていたとしても合格扱いにはしません。前段の不備が残ったまま本番移行へ進むと、後から大きなトラブルにつながります。
また、管理画面上の操作が現実の物流や金銭へ直結しないよう安全対策を整えます。Shopify公式のテスト注文案内にあるように、有料プランを選択した後にテスト決済機能（Shopify Paymentsテストモードなど）を使って模擬注文を試すことができます。模擬決済では実際の請求は発生せず、支払い明細やレポートにも計上されませんが、注文データ自体は作成される場合があります。そのため、本番稼働中の店舗ではテストモードを有効にしません。
さらに、Shopify Paymentsのテストモード公式ドキュメントでは、配送ラベルの意図しない課金を防ぐためにテスト注文をフルフィルメント（出荷処理）しないことや、注文を自動処理する外部アプリを事前に無効化することが案内されています。模擬試験が終了した後は、実際の決済を受け付けるためにテストモードを確実に解除します。自動処理アプリや通知、出荷の再開は、関係者が安全を確認した順序で進めます。テスト注文（決済等の動作を確認する注文）であっても実発送や顧客への誤通知を防ぎ、実顧客の注文を無断で返金テストに使うことも避けます。返品後の在庫復帰も、再販できる状態かを別に確かめます。
在庫・決済・出荷・会計は、どう突き合わせる？
新旧のデータを比較する際は、「いつの時点のデータか」という基準時刻と、「その数字が何を指しているか」という定義を一致させる必要があります。注文ごとに処理がどこまで進んでいるかを突き合わせ、数字の差や未確認の項目が残れば原因と業務への影響を記録して、移行判断の材料にします。
とくに在庫数はシステムごとに定義が分かれます。販売可能数（実在庫や引当済み数量等から自店の規則で販売に出す数）の扱いはシステムや事業者によって異なるため、突き合わせを行う際は、同じ商品・SKU・保管場所・時点・状態・計算式をそろえて以下のような対照表で確認します。
| 照合分野 | 突合する単位と基準 | 確認する内容と着眼点 |
|---|---|---|
| 在庫 | 同一時刻・SKU単位 | 実在庫数、引当数、販売可能数の計算が一致しているか |
| 決済 | 注文番号ごと | 注文総額と、売上確定・未確定・取消・返金の状態が合っているか |
| 出荷 | 出荷指示単位 | 店舗側からの出荷依頼と、倉庫側の出荷実績・追跡番号が一致しているか |
| 会計 | 日次・月次単位 | 売上計上基準日、消費税区分、返金時の仕訳が正しく処理されているか |
金額に不一致が生じた場合は、決済手数料が差し引かれた後の入金額を注文総額と直接比較していないか、キャンセルや一部返品のデータが一方のシステムにのみ残っていないかを追跡します。日々の締め処理の基礎については「ECの月次締め手順」の確認も役立ちます。不明な差異を安易にゼロとみなさず、原因を特定してから切り替えの可否を判断します。
切替中の注文と発送を、誰が動かす？
移行当日に最も注意すべき事故は、新旧両方のシステムから二重に請求や出荷の指示が送られてしまうことです。双方の記録を見比べる並行確認の期間を設ける場合でも、指示元（倉庫や決済へ実作業を依頼するシステム）は常にどちらか一方に限定します。
布小物の架空店であれば、切替作業に入る直前の「最終出荷締切時刻」をあらかじめ設定します。もし旧システム側に未発送の注文が1件残っている場合、それを「旧システムの指示で出荷を完了させてから切り替える」のか、それとも「新システムへ注文番号を紐付けて引き継ぎ、新システムから出荷指示を出す」のかを注文番号ごとに決め、記録を残します。未発送の注文を、すでに終わった発送済みの過去注文データとして新環境へ流し込むことは避けます。
切替時には、旧システムの連携停止時刻と新システムの接続開始時刻を定め、誰がAPI連携の停止や接続設定を行うかを明確にします。Shopify公式の移行ガイドにあるように、過去の注文データを取り込む際に設定済みのスタッフ宛へ注文通知メールが送信される仕様があるため、取り込み前にスタッフ宛通知を一時停止し、取り込み完了後に元に戻す手順を確認しておきます。これは一般の顧客向け通知や倉庫連携とは分けて扱います。他のシステム構成を検討したい場合は「受注管理サービスを比較する」なども参考にしてください。
問題が出たら戻せる？切替後は何を見る？
切替直後に重大な問題が発生した場合は、あらかじめ確認しておいた切り戻し（確認済み手順で旧環境へ戻す対応）の手順に従って元の運用へ復旧します。ただし、単に旧システムの画面を再度開くだけで元通りになるわけではありません。新システムが稼働していたわずかな時間にも、新しい注文の受付、決済の確定、在庫の減少といった事象が発生しているからです。
この新環境で生じた差分（切替以後に増えた注文や変化した在庫/決済/出荷の記録）を手元に確実に記録し、決済や出荷の重複処理への対処を済ませてから、旧環境での注文受付を再開します。
切替作業を中断して旧環境へ戻すかどうかの判定基準は、あらかじめ店舗内で設定しておきます。代表的な条件は以下のとおりです。
- 新規注文のデータが途中で欠落し、顧客や受注管理画面に届かない
- 決済の二重請求や、倉庫への二重出荷が発生する兆候がある
- 原因を説明できない在庫数のズレが発生し、販売可能数と実態が乖離している
契約形態によっては、一度停止した旧環境を即座に再開できない場合もあります。その際は、一時的にショップにメンテナンス画面を表示して購入者へ案内を出し、新環境側で集中的に不具合を修復する案も想定し、事前に各ベンダーと対応範囲を確認しておきます。
切替が無事に完了した後は、注文確認メールが正常に届いているか、決済が正しく確定されているか、アクセス解析や広告の計測タグが稼働しているかを数日間にわたり監視します。
移行に向けた具体的な次の行動は以下の2点です。
- 自店で扱う情報について「移す」「残す」「再設定する」を分類し、確認担当者を決める。
- 代表的な1商品を使って、通常注文だけでなく取消や返品まで含めたテスト計画を作成する。
関連記事
この記事の確認範囲
料金や記載の誤りを知らせる
公式ページの変更や計算ミスを見つけた場合にお知らせください。氏名は不要です。個人情報や注文情報は入力しないでください。
送信内容は記載確認のためCloudflare D1へ保存します。保存項目・期間・削除依頼はプライバシーポリシーをご確認ください。