在庫の数字をスプレッドシートで管理して、そこからShopifyへ同期する。仕組みとしてはとてもシンプルに聞こえますが、実際に運用を始めてみると「なぜかこの拠点だけ数が合わない」「同期は成功しているのに店頭の在庫が動かない」といったつまずきが起こりがちです。そしてその原因の多くは、同期の設定そのものではなく、同期先をどこに定めているかという一点に集まっています。
Shopifyの在庫同期は、商品に対して数を書き込む作業ではありません。書き込み先は必ず「どの商品を、どのロケーションで」という組み合わせです。この記事では、ロケーションという単位を正しく理解して、シートの一行がShopifyのどこへ届くのかを自分の言葉で説明できる状態を目指します。最初の同期でつまずかないための確認手順まで、順番に見ていきましょう。
在庫同期の書き込み先は「商品」ではなくロケーション
在庫同期の設計で最初に決めるべきなのは、数字の宛先です。ここが曖昧なまま同期を始めると、正しい数を用意していても、まったく違う場所に届いてしまいます。まずはShopifyが在庫をどういう形で保持しているのか、その構造から確認していきます。
在庫アイテムと在庫レベルは別のもの
Shopifyでは、商品(product)とその販売単位であるバリエーション(variant)があり、さらにその裏側に在庫アイテム(inventory item)という存在があります。SKUが結びついているのはこの在庫アイテムです。ただし在庫アイテムそのものは「何個あるか」という数字を持っていません。数字を持っているのは、在庫アイテムとロケーションを掛け合わせた在庫レベル(inventory level)のほうです。
つまり在庫同期とは、商品を更新する作業ではなく、在庫レベル、すなわち「在庫アイテム × ロケーション」という交差点の数字を更新する作業だということになります。この理解があると、なぜ同期の設定でロケーションを選ぶ必要があるのかが腑に落ちますし、同じSKUなのに拠点によって数が違うという状態も、まったく自然なこととして受け止められるようになります。
ロケーションの取り違えは静かに起こる
書き込み先が交差点である以上、ロケーションを一つ取り違えるだけで、数字はまるごと別の拠点へ流れ込みます。しかも厄介なことに、この間違いはエラーとして表面化しません。同期は正常に完了し、ログにも成功と記録されます。ただ、東京倉庫に入れるはずだった30個が、大阪倉庫に入っているだけです。
気づくきっかけは、たいてい実務のほうから来ます。店頭では品切れなのにオンラインでは在庫あり、あるいは出荷指示が想定と違う拠点に飛ぶ。こうした症状が出たときは、シートの数字を疑う前に、まず「その数字がどのロケーションへ向かう設定になっているか」を確認してください。原因が同期先の指定にあるケースは、驚くほど多いのです。
デフォルトロケーション任せの落とし穴
ロケーションが一つしかないうちは、どこへ書き込むかを意識する必要はほとんどありません。既定のロケーションが一つだけなので、何も指定しなくても正しい場所へ届きます。問題は、店舗を増やしたり3PLを追加したりして、ロケーションが二つ以上になった瞬間に起こります。
それまで暗黙のうちに使われていた「とりあえず最初のロケーション」という前提が、突然まちがった前提に変わるからです。ロケーションを追加した直後は、既存の同期設定がどの拠点を向いているかを必ず見直してください。追加した側ではなく、以前から動いている側の設定が置き去りになっている、というのがよくある形です。
3つの数字のうち、シートが持つべきものはひとつだけ
ロケーションごとの在庫は、ひとつの数字ではなく複数の状態に分かれています。ここを混同したまま同期を組むと、シートとShopifyの数字が合わない理由が最後まで見えなくなります。実在庫・引当済み・販売可能という3つの数字を、役割の違いで整理しておきましょう。5つの状態の詳細は、Shopifyの在庫状態の読み解き方で一つずつ説明しています。
実在庫(on hand)がシートの担当範囲
実在庫は、そのロケーションに物理的に存在している数です。棚に並んでいる分、バックヤードに積んである分を数えれば出てくる、いちばん現実に近い数字だと考えてください。入荷したら増え、出荷したら減り、棚卸しで実地の数と突き合わせる。この動き方は、そのまま倉庫や店舗の日常業務と重なります。
だからこそ、スプレッドシートが原本として持つべきなのは実在庫です。仕入れ担当が入荷数を打ち込み、店舗が棚卸し結果を反映する。シート上にはロケーションごとの実在庫が並び、それがそのまま同期でShopifyへ渡っていく。この形にしておくと、数字の責任範囲がはっきりして、誰が何を更新すべきかで迷わなくなります。
引当済み(committed)は注文から生まれる
引当済みは、注文は入ったけれどまだ出荷されていない数です。お客様が購入した時点で、その商品はまだ倉庫の棚にありますが、すでに別の人のものとして確保されています。この数字はShopifyが注文の状況から自動的に計算するもので、外から書き込む種類の数字ではありません。
ここを取り違えて、シートで引当分を差し引いた数を実在庫として送ってしまうと、二重に引かれた在庫がShopify側に出来上がります。シートは「棚にある数」だけを見ていればよく、注文の動きはShopifyに任せる。この分担を守ることが、数字のずれを防ぐいちばん確実な方法です。
販売可能(available)は勝手に動く数字
販売可能は、実在庫から引当済みなどを差し引いた、これから売れる数です。オンラインストアの在庫表示や、売り越しを防ぐ判断に使われるのはこの数字になります。そして販売可能は、実在庫と引当済みから導かれる結果なので、注文が入るたびに自動的に減っていきます。
同期直後に管理画面を見て「シートの数と表示が違う」と感じたときは、見ている数字が販売可能になっていないか確かめてみてください。実在庫は指定どおりでも、その時点で未出荷の注文があれば、販売可能はその分だけ小さく表示されます。これは不具合ではなく、正しく動いている証拠です。
シートの形を決める : 1行が何を表すのか
同期先の構造がわかったら、次はそれをスプレッドシート上でどう表現するかです。ここで決めた形が、そのまま日々の運用のしやすさになります。難しいことをする必要はなく、原則をひとつ守るだけで十分に整います。ロケーションごとに列を持つ具体的な形は、1枚のシートで複数ロケーションを扱う列設計にあります。
1行 = 1SKU × 1ロケーションが基本形
在庫レベルが「在庫アイテム × ロケーション」なのですから、シートの1行もそれに合わせるのが素直な設計です。A列にSKU、B列にロケーション、C列に実在庫。たったこれだけで、シートの構造とShopifyの構造がぴったり重なります。同じSKUが3拠点にあるなら、その商品は3行を占めることになります。
行数は増えますが、この形には大きな利点があります。どの行がどこへ届くのかが一目でわかること、そして拠点を追加するときに行を足すだけで済むことです。列の構成を変えずに拠点を増やせるので、シートを共有している人たちの作業も変わりません。まず迷ったら、この縦持ちの形から始めることをおすすめします。
ロケーションごとに列を分ける形
もうひとつの選び方が、1行を1SKUにして、ロケーションごとの実在庫を別々の列に持たせる形です。SKUが縦に一度だけ並び、拠点が横に広がるので、拠点間の在庫バランスを見比べたいときには圧倒的に読みやすくなります。棚卸しの入力画面としても、この形のほうが扱いやすいという声はよく聞きます。
- 縦持ち(1行 = SKU × ロケーション) : 拠点の増減に強く、どの行がどこへ届くかが明確です
- 横持ち(ロケーションごとに列) : 拠点間の在庫を見比べやすく、棚卸しの入力に向いています
- 縦持ちは行が増え、横持ちは列が増えます。拠点数が少ないうちは横持ち、増えてきたら縦持ちが扱いやすくなります
- どちらを選んでも、1つのマスが必ず「1つのSKUの、1つの拠点の実在庫」を表すという原則は変わりません
どちらが正解ということはありません。大事なのは、シートの中で一つのセルが指しているものが「1つのSKUの、1つの拠点の実在庫」で一貫していることです。この一貫性さえ保たれていれば、あとはどちらの形でも同じように同期できます。途中で形を変えることもできますが、切り替えのタイミングでは必ず少量で試してから全体に広げてください。
名前ではなくロケーションそのものに結びつける
運用を続けていると、ロケーションの表示名はしばしば変わります。「本社倉庫」が「東日本DC」になり、店舗名が移転で書き換わる。人が読むための名前なので、変わること自体は自然です。問題は、同期の宛先が表示名の文字列だけに頼っている場合、名前が変わった瞬間に行き先を見失ってしまうことです。
ですから、同期の設定はロケーションそのもの、つまり名前ではなくロケーションの実体に結びつけておくのが安全です。シート側にも表示名だけでなく、変わらない識別子や社内コードの列を用意しておくと、名前が変わっても対応関係を保てます。ロケーション名を変更したときは、念のため同期設定を開いて宛先が保たれているか確認する。この一手間が、後々の大きな事故を防ぎます。
最初の同期の前に確認したい3つのこと
設計が固まったら、いよいよ最初の同期です。ただ、いきなり全商品を流すのはおすすめしません。ここで紹介する3つの確認を挟むだけで、初回のつまずきはほとんど避けられます。どれも数分で終わる作業です。
接続テストで宛先を確かめる
同期を実行する前に、接続テストを走らせて、シートとShopifyが正しくつながっているかを確かめましょう。ここで見たいのは、つながるかどうかだけではありません。どのストアの、どのロケーションを向いているのかという宛先の確認こそが本題です。
特に、開発用ストアと本番ストアを両方持っている場合や、ロケーションを追加した直後は、必ずこの確認を挟んでください。テスト用のつもりで流した数字が本番の在庫を書き換えてしまうと、元に戻すのは思いのほか手間がかかります。接続テストは、その一手間を数十秒で肩代わりしてくれる保険です。接続テストで何が見えるかは、同期前の接続テストに詳しく書きました。
在庫の追跡が有効になっているか
Shopifyでは、商品ごとに在庫を追跡するかどうかを設定できます。追跡がオフになっている商品は、そもそも在庫数という概念を持たないため、いくら同期してもロケーションごとの数字が入りません。「同期は成功しているのに数が反映されない」という相談の多くは、この設定が原因です。
また、追跡が有効でも、その商品がそのロケーションで扱われる設定になっていなければ、やはり数字は入りません。新しい拠点を追加したときは、扱う商品をそのロケーションに紐づける作業が必要になります。初回同期の前に、対象商品の追跡設定と、拠点への紐づけをまとめて確認しておくと安心です。
少量から始めて差分を確認する
準備が整ったら、まずは5件から10件ほどの小さなまとまりで同期してみましょう。全商品を一度に流すと、何かがずれていたときに原因の切り分けが一気に難しくなります。少量なら、管理画面で一つひとつ目視で確かめられます。
- 01拠点をまたぐSKUや在庫ゼロの商品など、確認したい条件を含む5件から10件を選びます
- 02接続テストを実行して、宛先のストアとロケーションが意図どおりかを確かめます
- 03その小さなまとまりだけを同期し、管理画面でロケーションごとの実在庫を目視で確認します
- 04シートの値とShopifyの実在庫が一致していれば、対象を広げて全体の同期へ進みます
確認するときは、必ず実在庫の欄を見てください。販売可能の数字は未出荷の注文の影響を受けるため、シートの値と一致しないことがあります。実在庫が指定どおりに入っていれば、同期は正しく動いています。ここまで確認できたら、対象を広げて全体を流し、以降は定期実行のスケジュールに乗せてしまいましょう。
在庫同期は、突き詰めれば「正しい数字を、正しい交差点に届ける」という作業です。数字を用意する部分はスプレッドシートが得意ですし、正しい交差点を選ぶ部分は、ロケーションという単位を理解していれば迷いません。この記事の内容が身についていれば、拠点が2つに増えても5つに増えても、同じ考え方でそのまま対応していけるはずです。