在庫同期を導入した店舗から届く相談で、なかなか根が深いのが返品まわりです。「返品を受けてShopifyで在庫を1つ戻したのに、翌朝には元の数字に戻っていました」。同期のログを見ても異常はなく、設定にも間違いはない。それでも戻した1個は消えている。
この現象は、同期の不具合ではありません。むしろ同期が設計どおりに正しく動いた結果です。原因は仕組みではなく運用の順序にあり、だからこそ設定をいくら見直しても直りません。この記事では、Shopifyの返品処理が在庫に何をするのかを確認したうえで、返品と在庫同期をきれいにかみ合わせる方法を考えていきます。
なぜ返品は在庫同期とぶつかるのか
まず、何が起きているのかを整理しましょう。理屈が分かれば対策は自然に見えてきますし、「同期が信用できない」という誤解も解けます。ここは急がずに読んでみてください。
在庫を書き込む人が2人いる状態
スプレッドシートを在庫の単一の真実として運用している店舗では、Shopifyの在庫数はシートから流れ込んできます。ここに返品処理が入ると、状況が変わります。Shopifyの管理画面で返品を処理すると、Shopify自身が在庫を戻すからです。つまり、在庫を書き込む担当が2つ存在することになります。
単一の真実という考え方は、書き込む担当が1つであるときにいちばんきれいに機能します。2つになった瞬間、どちらが勝つかという問題が生まれ、答えは「あとから書いたほう」です。夜間にスケジュール同期が走れば、シートの内容が最終的な結果になります。どの数字が動くのかを押さえるには、Shopifyの在庫状態の読み解き方が近道です。
戻した1個が消えるまでの流れ
時系列で追ってみましょう。朝の時点で、シートもShopifyも在庫は10個。昼にお客さまから返品が届き、担当者がShopifyで返品を処理します。「商品を再入荷する」がオンになっているので、Shopifyの在庫は11個になります。ここまでは期待どおりです。
問題は、シートが10個のままだということです。誰もシートを更新していません。そして深夜、スケジュール同期が走り、シートの10個がShopifyに書き込まれます。翌朝には11個が10個に戻っている。同期は言われたとおりのことをしただけで、どこにもバグはありません。
誰も間違えていないのに数字が減る
この現象がやっかいなのは、関わった全員が正しく仕事をしている点です。返品担当は手順どおりに処理し、同期は設定どおりに動きました。それでも結果は間違っています。責める相手がいないので、原因究明が「なんとなく同期が不安定」という曖昧な結論に落ち着きがちです。
しかも影響は静かに広がります。返品された商品は実際には棚にあるのに、Shopify上は存在しないことになっている。売れるはずの1個が売れないまま滞留し、在庫回転の数字も少しずつ歪んでいきます。返品件数が多い業種ほど、この歪みは無視できない大きさになります。
アパレルのようにサイズ違いの返品が日常的に起きる業種では、この積み重ねが数か月で数十点規模になることも珍しくありません。しかも返品されやすいのは人気サイズであることが多く、本来なら真っ先に売れるはずの在庫が眠ってしまいます。機会損失としてはかなり痛い形です。
逆に言えば、返品まわりの手順を整えるだけで、追加の仕入れをせずに売れる在庫が増えるということでもあります。倉庫に眠っている在庫を掘り起こす作業だと考えると、地味な手順の整備にも取り組む価値が見えてきます。
Shopifyの返品処理は在庫に何をするのか
対策を考える前に、Shopify側の挙動を正確に押さえておきましょう。ここを曖昧にしたまま運用ルールを作ると、ルールのほうが現実とずれてしまいます。ヘルプセンターの記述に沿って確認します。
「商品を再入荷する」は既定でオン
注文を返金する画面には「商品を再入荷する」のオプションがあり、これは既定で選択されています。つまり、意識して外さないかぎり在庫は自動的に戻ります。手動で戻したい場合は、このチェックを外して返金だけを行う、という運用も可能です。
重要な条件がひとつあります。このオプションは、その商品の在庫を追跡している場合にのみ表示されるという点です。在庫追跡をオフにしている商品では、そもそも戻す対象がありません。返品の扱いを設計するときは、対象商品が在庫追跡されているかを先に確認しておきましょう。
どのロケーションに戻るのか
返品を処理する際には、どのロケーションに戻すかを指定できます。返金された商品は、指定したロケーションの在庫に加算されます。複数のロケーションを運用している店舗では、この指定が実態と合っているかが精度を左右します。
よくあるずれは、注文が倉庫から出荷されたのに、返品は本社や店舗に届いているというケースです。物理的にどこに戻ったのかと、Shopifyでどこに戻したのかが食い違うと、ロケーション単位の在庫が両方ともおかしくなります。返送先の住所と戻し先のロケーションを対応づけておくと、この種の混乱は減ります。
返金なしで在庫だけ戻すケース
返金の必要がない場合、たとえば配送不能で商品が戻ってきたようなときには、返品や返金を作らずに在庫だけを戻すこともできます。注文画面から再入荷の操作を選び、戻す数量を入力する形です。この経路も在庫を動かすので、同期の観点では返金付きの返品とまったく同じ扱いになります。
見落とされやすいのはこちらの経路です。返金という金銭のやりとりがないぶん、カスタマーサポートの記録にも残りにくく、在庫だけが静かに動きます。「返品対応をした人」と「在庫を戻した人」が別になりやすいのも、この経路の特徴です。
戻ってきた品が売り物とは限らない
もうひとつ大事な視点があります。返品された商品がそのまま販売可能になってよいのか、という問題です。開封済み、汚れあり、検品が必要。こうした状態のものを自動的に販売可能へ戻してしまうと、売れた後で「出荷できません」という事故が起きます。
Shopifyには販売不可という在庫状態があり、破損や品質チェック待ちといった理由で在庫を保持できます。返品直後は販売不可に置き、検品を通ったものだけを販売可能に移す。この一手間を挟むだけで、返品在庫にまつわるトラブルはかなり減らせます。
ずれない返品フローの作り方
挙動が分かったところで、実際の運用ルールに落とし込みます。ポイントは、複雑な仕組みを作ることではなく、順序を決めることです。ルールが3行で書ける程度に単純でないと、忙しい日には守られません。
シートに書いてからShopifyを触る
いちばん確実なのは、返品で在庫が戻るときは必ずシートを先に更新する、というルールです。シートの数量を10から11に直し、そのうえでShopifyの返品処理を行う。こうすれば、次の同期が走ってもシートは11なので、戻した在庫は消えません。
順序を逆にしないことが肝心です。「Shopifyで処理してから、あとでシートも直しておく」は、忙しい日に必ず後半が抜けます。先にシートを触る習慣にしておけば、たとえShopify側の操作を忘れても、次の同期が正しい数字を入れてくれます。安全側に倒れる順序を選びましょう。戻し漏れを見つける突き合わせは、倉庫ごとの実地棚卸しの合わせ方で扱っています。
誰が数字の責任を持つかを決める
返品処理はカスタマーサポート、在庫の数字は倉庫、という分担になっている店舗は多いはずです。この分担自体は自然ですが、返品在庫はちょうどその境目に落ちます。誰がシートを更新するのかが決まっていないと、両者が「相手がやるだろう」と考えて誰もやりません。
決め方はどちらでも構いません。サポートが返品処理と同時にシートも更新するか、倉庫が現品を受け取ったときに更新するか。大事なのは、どちらか一方に明確に寄せることです。「気づいた人が直す」という運用は、返品件数が増えた瞬間に崩れます。
検品待ちの置き場所を用意する
返品在庫をすぐに販売可能にしたくない場合、シート側にも置き場所を用意しておくと運用が滑らかになります。たとえば「検品待ち」という列を設け、返品を受けたらまずそこに数を積む。検品が終わった分だけ販売用の数量列に移す、という流れです。
この形にしておくと、返品が届いた事実は記録されつつ、Shopifyに反映される数字は検品済みのものだけになります。ロケーションごとに列を持てる仕組みであれば、こうした列の追加も設計の延長線上で行えます。数字が動いた理由がシート上に残るのも、あとから振り返るときに助かります。
検品待ちの列を作るときは、その列が同期の対象範囲に入らないようにしておくのを忘れないでください。うっかり同期対象に含めると、検品前の在庫までShopifyの販売可能に流れてしまい、せっかく分けた意味がなくなります。列を追加したら、一度接続テストで反映範囲を確かめておくと安心です。
検品待ちの数が増え続けている場合、それ自体がひとつのシグナルです。検品が追いついていないのか、そもそも返品率が高すぎるのか。返品を在庫の問題としてだけでなく、商品説明やサイズ表記の見直しのきっかけとして扱えるようになると、シートは在庫管理以上の役割を果たしはじめます。
- 返品で在庫が戻るときは、先にシート、あとでShopify
- 戻し先のロケーションは、現品が物理的に届く場所に合わせる
- 返金なしの再入荷も在庫を動かす。同じルールを適用する
- 検品が必要な商品は、販売可能に戻す前に一段階挟む
- 誰がシートを更新するかを1人（1部署）に決める
起きてしまったずれを早く見つける
ルールを決めても、抜けはゼロにはなりません。返品は繁忙期に集中しますし、そういう日ほど手順は飛ばされます。だからこそ、ずれを早く見つける仕組みをあわせて持っておくと安心です。
シートに返品の記録を残す
同じスプレッドシートの別タブに、返品を受けた日付・SKU・数量・戻し先を記録する簡単なログを作っておきます。数分の作業ですが、あとから「この在庫はいつ戻したのか」を追えるようになります。同期の数量列とは別なので、同期の動作には影響しません。
このログがあると、月末に「返品で戻したはずの数」と「実際にシートに反映された数」を突き合わせられます。差があれば、どこかで手順が抜けたということです。原因を特定するというより、抜けの傾向を知るための道具として使うのがコツです。
週に一度の突き合わせ
返品が発生したSKUだけを対象に、週に一度シートとShopifyを見比べます。全商品を見る必要はありません。返品ログに載っているSKUだけなら、多くの店舗で10件前後、数分で終わります。返品在庫のずれは対象が限られているので、この絞り込みがよく効きます。
シートの構成を変えたときや、返品フローの担当者が変わったときは、その週だけ確認を丁寧にすると安心です。変更の直後は、慣れた人でも手順を間違えやすい時期です。同期を本格的に走らせる前に接続テストで確かめられる仕組みなら、変更内容の確認にも使えます。ずれが大きくなってしまった場合は、間違った在庫を同期してしまったときの戻し方の手順に進んでください。
返品が増える時期に備える
セール後や年末年始の後など、返品が集中する時期はあらかじめ分かっています。この時期だけは、返品在庫の扱いを一時的に単純化するのも手です。たとえば、繁忙期のあいだは返品分をすべて検品待ちに積み、落ち着いてからまとめて販売可能へ移す、といった運用です。
急いで販売可能に戻すことで得られる売上より、混乱によって発生する売り越しやキャンセルのコストのほうが大きくなる時期がある、ということです。忙しいときこそ手順を減らす。この考え方は、返品にかぎらず在庫運用全般で役に立ちます。
返品で戻した在庫が消える現象は、同期の欠陥ではなく、在庫を書き込む担当が2つある状態が生む必然でした。だとすれば解決策も明快で、書き込む担当を1つに戻せばよいことになります。シートを真実とするなら、返品による増加もシートに書く。それだけの話です。
順序を決め、担当を決め、週に一度だけ確かめる。この3つがそろえば、返品は在庫同期にとって特別な存在ではなくなります。むしろ返品の扱いがきれいに整理されている店舗は、在庫データ全体の精度も高い傾向があります。境目にある仕事をきちんと決めておくことは、それだけで在庫運用の質を押し上げてくれるのです。