Shopify在庫連携の設計方法｜EC・倉庫・会計で在庫がズレない構成

Shopifyで在庫管理や在庫連携を考えるとき、最初に「どのアプリを入れるか」「APIでつなげるか」という話になりがちです。

しかし実務では、連携方法より前に決めることがあります。

• Shopifyの商品バリエーションとSKUをどう持つか
• 在庫の正本をShopify、WMS、基幹システムのどこに置くか
• ロケーションを倉庫、店舗、外部倉庫、委託先ごとに分けるか
• 受注、出荷、返品、キャンセルで在庫をいつ動かすか
• freeeやマネーフォワードなど会計側へ何を渡すか
• 欠品、低在庫、連携失敗を誰へ通知するか

Shopify公式ヘルプでも、在庫は管理画面で追跡、在庫数確認、調整、履歴確認ができる領域として説明されています。

Shopify Help Center: Managing inventory

ただ、複数倉庫、店舗、モール、会計ソフト、WMSが絡むと、Shopifyだけを見ても運用全体は設計できません。

Shopify在庫連携で先に決めるべきなのは、在庫アプリではなく「どの数字を正とするか」と「どのイベントで在庫を動かすか」です。

結論：商品、在庫、受注、出荷、会計を分けて考える

Shopifyの在庫連携は、1つの表を同期する話ではありません。

最低でも次の領域を分けて設計します。

領域	主なデータ	設計で決めること
商品データ	商品名、説明、画像、バリエーション、SKU、メタフィールド	販売に見せる情報と社内管理情報を分ける
在庫データ	SKU、ロケーション、販売可能数、引当、入出庫	どのシステムを正本にするか
受注データ	注文、顧客、支払、配送先、明細	在庫確保のタイミングを決める
出荷データ	出荷指示、配送会社、追跡番号、返品	WMSや配送管理との責任範囲を決める
会計データ	売上、手数料、返金、消費税、入金	会計ソフトへ渡す粒度を決める

ShopifyはECの中心に置きやすいツールです。

一方で、倉庫作業、原価、棚卸評価、複数モールの在庫配分まで全部をShopifyに集約するとは限りません。

在庫連携では、Shopifyに持つものと、外部システムに任せるものを先に分けます。

在庫の正本を先に決める

在庫連携で一番危ないのは、複数のシステムが同じ在庫数をそれぞれ正として更新する状態です。

よくある候補は次の3つです。

在庫の正本	向いているケース	注意点
Shopify	小規模EC、倉庫が少ない、Shopify中心で受注する	モールや実店舗が増えると調整が重くなる
WMS・倉庫システム	倉庫作業、出荷、返品、棚卸しが中心	Shopify側は販売可能数の表示に寄せる
基幹・在庫管理システム	複数チャネル、卸、店舗、会計評価まで扱う	Shopifyは販売チャネルの1つとして扱う

Shopifyにはロケーションの考え方があります。ロケーションを追加すると、注文をどの場所に割り当てるか、在庫をどの場所に持たせるかを設定できます。

Shopify Help Center: Locations

たとえば、自社倉庫、店舗、外部倉庫をロケーションとして持つ場合、Shopify上の在庫は「全体の在庫」ではなく「ロケーション別に販売へ使える在庫」として見ます。

WMSを正本にするなら、Shopifyの在庫数はWMSから反映される結果です。Shopify管理画面で手動調整する運用を残すと、次回同期で戻る、または二重更新になることがあります。

SKUとバリエーションを雑に作らない

Shopifyでは、商品にサイズや色などのバリエーションを持たせられます。

在庫連携では、SKUがかなり重要です。

設計項目	悪い例	よい例
SKU	手入力で担当者ごとに違う	命名ルールを決め、商品・色・サイズなどを識別できる
バリエーション	色とサイズを説明文に書くだけ	バリエーションとして分け、在庫を別に持つ
セット商品	セット用SKUだけを作る	構成品との在庫引当ルールを決める
予約商品	通常在庫と同じ扱いにする	予約枠、入荷予定、通常在庫を分ける

ShopifyのAdmin APIでは、商品バリエーションと在庫アイテム、在庫レベルの関係を理解しておく必要があります。

Shopify Dev Docsでは、商品バリエーションとInventory Item、Inventory Levelの関係が説明されています。

Shopify Dev Docs: InventoryLevel

API連携をする場合、単に「商品IDで更新する」と考えるより、バリエーション、Inventory Item、ロケーションごとの在庫レベルをどう扱うかを整理します。

連携させる範囲と切り出す範囲

Shopify在庫連携では、全部をリアルタイム同期にしない方がよいこともあります。

連携対象	リアルタイム寄り	バッチ・手動確認寄り
販売可能在庫	欠品防止のため即時反映したい	商品数が少なければ定期更新でもよい
受注情報	出荷指示に必要なら即時	会計集計だけなら日次でもよい
返品・キャンセル	在庫復帰に直結するなら即時	検品後に戻すなら確認後
会計連携	入金や売上計上と関係する	手数料、返金、消費税を確認してから
Slack通知	欠品、同期失敗、異常値は即時	通常売上通知は日次集計でもよい

リアルタイム連携は便利ですが、失敗時の再実行、重複処理、順序ズレを考える必要があります。

たとえば、注文作成、支払い確定、出荷完了、返品受付、返金完了は、それぞれ別のイベントです。

どのイベントで在庫を減らすか、どのイベントで戻すかを決めないまま連携すると、在庫が合わなくなります。

Shopify FlowとWebhookを使い分ける

軽い通知やタグ付け、外部サービスへの送信なら、Shopify Flowで扱える場合があります。

Shopify Flowのアクションには、注文タグの追加、顧客タグの削除、フルフィルメント注文の保留、メール送信、Slackメッセージ送信、HTTPリクエストなどがあります。

Shopify Help Center: Actions in Shopify Flow

一方で、独自DBやWMS、会計処理、再実行管理まで含めるなら、WebhookやAdmin APIを使った連携基盤が必要になることがあります。

ShopifyのWebhookは、特定イベントのデータを指定URLへ送る仕組みです。

Shopify Help Center: Creating webhooks

使い分けの目安は次です。

方法	向いている用途	向かない用途
Shopify Flow	通知、タグ付け、軽いHTTP連携	複雑な再実行、独自DBとの厳密な同期
Webhook	注文、在庫、顧客などのイベント連携	受信後の処理設計をしない運用
Admin API	在庫更新、商品更新、注文取得など	権限・制限・エラー処理を無視した直接更新
手動CSV	初期移行、棚卸後の一括調整	毎日の通常運用

Shopify Flowで足りる通知と、Webhook/APIで作るべき連携基盤を分けることが、運用を重くしないコツです。

低在庫と連携失敗を見えるようにする

在庫連携では、正常な注文よりも例外を見えるようにすることが重要です。

最低限、次の一覧や通知を作ります。

例外	見る人	対応
低在庫SKU	EC担当、仕入担当	発注、表示停止、広告停止を判断する
在庫同期失敗	EC担当、開発担当	再実行、原因確認、手動補正
SKU未設定商品	EC担当	商品登録ルールを修正する
返品後の在庫未反映	CS、倉庫	検品後に在庫復帰するか判断する
WMSとShopifyの差分	倉庫、EC担当	棚卸し、出荷漏れ、二重更新を確認する

在庫連携は「同期できたら終わり」ではありません。

同期できなかったとき、誰が、どの画面で、どの数字を見て直すかまで決めます。

会計連携は売上だけで考えない

Shopifyの注文データを会計ソフトへ渡す場合、売上金額だけ見ても足りません。

確認すべきデータは次です。

項目	注意点
売上	注文日、支払日、出荷日、計上基準を決める
送料	売上に含めるか、別科目にするか
決済手数料	Shopify Paymentsや外部決済で扱いが変わる
返金	返金日、手数料、在庫復帰との関係を見る
税	軽減税率、海外販売、税込/税抜を確認する
入金	注文単位と入金単位が一致しないことがある

会計は会計ソフトを正本にし、Shopifyからは必要な明細を渡す設計にした方が安全です。

在庫も会計もShopifyに寄せすぎると、どの数字が正式なのか分からなくなります。

Shopify在庫連携の失敗パターン

よくある失敗は次です。

失敗	起きること	対策
SKUルールがない	同じ商品を別SKUとして扱う	命名ルールと登録チェックを作る
ShopifyとWMSの両方で在庫を手動更新する	次回同期で数字が戻る	在庫正本と手動更新の権限を決める
全部リアルタイム同期にする	エラー時の再実行が複雑になる	即時・日次・手動確認を分ける
返品時の在庫復帰ルールがない	不良品まで販売可能になる	検品ステータスを挟む
会計へ売上だけ渡す	手数料、返金、入金消込で崩れる	会計連携の粒度を先に決める

ShopifyはECの入口として強いですが、在庫、倉庫、会計、CRMまで含めると、EC運用全体の設計が必要です。

まとめ

Shopify在庫連携を進めるなら、最初に決めるべきことは次です。

1. 在庫の正本をShopify、WMS、基幹システムのどこに置くか
2. SKU、バリエーション、ロケーションのルールを決める
3. 受注、出荷、返品、キャンセルで在庫をいつ動かすか決める
4. Shopify Flowで足りる通知と、Webhook/APIで作る連携基盤を分ける
5. 低在庫、同期失敗、WMS差分など例外を見えるようにする
6. 会計連携は売上、手数料、返金、税、入金まで含めて設計する

Shopify在庫連携は、アプリを入れる作業ではありません。

商品、在庫、受注、出荷、会計の責任範囲を決め、例外が起きたときに直せる状態を作ることです。