在庫同期を運用していると、どこかのタイミングで必ずこの疑問にぶつかります。「毎回すべての商品を送り直すのは無駄ではないか」。商品数が1,000点あって、その日に動いたのが30点だけなら、残りの970点を送るのは確かに冗長に見えます。もっと賢いやり方があるのではないか、と考えるのはとても自然です。
この疑問への答えは「場合による」なのですが、その『場合』を判断する材料はあまり共有されていません。この記事では、全件同期と差分同期のそれぞれが何を得て何を失うのかを整理し、店舗の規模や運用スタイルに応じてどちらを選べばよいかを考えていきます。結論から言えば、多くの店舗にとっては両方を組み合わせるのが現実的な答えになります。
在庫を反映する2つの考え方
まず用語をそろえておきましょう。同期の方式を語るとき、人によって微妙に違う意味で言葉を使っていることがあり、それが議論をややこしくしています。ここでは、それぞれが具体的に何をしているのかから確認します。
全件同期 — 毎回すべてを書き直す
全件同期は、対象になっているすべてのSKUについて、シートに書かれた数量をそのままShopifyに反映する方式です。前回どうだったかは考慮しません。今シートに10と書いてあれば10を書き込む。変わっていない行も同じように処理します。単純ですが、この単純さこそが最大の武器になります。
この方式の性格をひとことで言えば「収束する」ことです。途中で何が起きても、次の同期が走れば結果はシートの内容に一致します。誰かが管理画面で数字をいじっても、前回の同期が途中で止まっていても、次の1回ですべてが揃う。運用が安定するのは、この性質のおかげです。
具体例で考えてみましょう。ある日、誰かがShopifyの管理画面で商品Aの在庫を手作業で50に書き換えたとします。シートには12と書いてある。差分同期ではこの変更は検出されず50のまま残りますが、全件同期なら次の実行で12に戻ります。人の手による割り込みを自動的に打ち消してくれるわけです。
この挙動を「勝手に上書きされる」と感じる方もいますが、シートを真実と決めた以上はこれが正しい振る舞いです。むしろ、管理画面での手作業がいつの間にか正になってしまう状態のほうが危険です。どちらが勝つかが常に同じであること自体に、運用上の大きな価値があります。
差分同期 — 変わった分だけを送る
差分同期は、前回から変化のあったSKUだけを抽出して送る方式です。1,000点のうち30点しか動いていなければ、30件だけを処理します。通信量も処理時間も大幅に減るため、頻繁に同期を回したい店舗にとっては魅力的に見えます。
ただしこの方式は、「何が変わったか」を正しく知っている必要があります。前回の状態をどこかに覚えておくか、更新日時のような手がかりを持つか。この記憶が現実とずれた瞬間、変化を検出できなかったSKUは永遠に更新されないまま取り残されます。差分同期の弱点はここに集約されます。
ゴールは同じ、抱えるリスクが違う
どちらの方式も「Shopifyの在庫をシートと一致させる」という同じゴールを目指しています。違うのは、うまくいかなかったときの壊れ方です。全件同期が失敗すると、大きく目立つ形で失敗します。時間がかかりすぎる、途中で止まる、といった具合に、気づける形の失敗です。
一方、差分同期の失敗は静かです。ある1件の変更を検出し損ねても、処理自体は成功として終わります。ログにも異常は残りません。数週間後、誰かが「この商品だけずっと数字が古い」と気づくまで、誰も知らない。同じ失敗でも、発見のしやすさがまったく違うのです。
全件同期が向いている場面
まずは全件同期のほうが素直に効く場面から見ていきます。世の中の中小規模のShopifyストアの多くは、実はこちらに当てはまります。「全件は非効率」という直感は、規模の感覚を確かめてみると意外とあてにならないものです。
シートが単一の真実であるとき
スプレッドシートを在庫の単一の真実（single source of truth）として運用しているなら、全件同期は方式として自然です。シートに書いてある内容がそのまま正なのですから、それを丸ごと反映するのはむしろ定義どおりの動きです。Sync Masterのようにシートを起点に設計された仕組みは、この考え方に立っています。
この形の良いところは、説明のしやすさです。新しく入ったスタッフに「シートに書いた数字がShopifyに入ります」とだけ伝えれば済みます。差分の仕組みを説明する必要も、「なぜこの商品だけ更新されなかったのか」を調べる必要もありません。運用のシンプルさは、そのまま事故の少なさにつながります。全件を流す前の確認項目は、フル同期前のチェックリストにまとめてあります。
壊れたときに戻しやすい
在庫データが乱れたとき、全件同期を採用している店舗の復旧手順は驚くほど短くなります。シートを正しい状態に直して、もう一度同期を走らせる。それだけです。何が更新されて何が更新されなかったかを追跡する必要はありません。次の1回ですべてが正しくなります。
差分同期では同じようにはいきません。差分の記憶が壊れている可能性があるので、まずは全件を一度流して基準を揃える、という手順が必要になります。つまり差分同期を採用していても、結局は全件同期の仕組みを持っておかないと復旧できないわけです。これは覚えておく価値のある事実です。
商品点数と処理時間の現実
「全件は重い」という印象を、実際の数字で確かめてみましょう。ShopifyのAdmin APIはコストベースのレート制限を採用しており、スタンダードプランで毎秒100ポイント、Shopify Plusで毎秒1,000ポイントが割り当てられます。在庫更新のような軽い操作であれば、数百から数千SKUの処理は現実的な時間に収まります。
つまり、商品数が数千点までの店舗であれば、全件同期を1日に数回走らせることは十分に可能です。「効率が悪いから差分にすべきだ」と考える前に、自分の店舗がその心配をする規模なのかを確かめてみてください。多くの場合、答えはノーです。
差分同期が向いている場面
とはいえ、差分同期が明確に優れている場面もあります。規模と更新頻度がある閾値を超えると、全件同期では追いつかなくなるからです。ここでは、その分岐点がどこにあるのかを考えます。
更新頻度が高い店舗
実店舗のPOSと連動していたり、複数チャネルで同時に売れていたりする店舗では、在庫は1日中動き続けます。こうした環境では、同期の間隔を短くしたいという要求が自然に生まれます。10分おきに全件を流すのは負荷が高いので、差分で回すという判断が出てきます。
ただし、頻度を上げること自体が目的化していないかは一度考えてみる価値があります。10分の遅延を5分にすることで防げる売り越しが、実際にどれくらいあるのか。安全在庫を少し厚くするほうが、同期の頻度を倍にするより効果的で安上がりということも珍しくありません。
API負荷とレート制限の話
商品点数が数万点の規模になると、レート制限は現実の制約として見えてきます。Shopifyはこのためにバルクオペレーションという仕組みを用意しており、公式ドキュメントでも大量データの扱いには単発のクエリではなくバルクを使うことが推奨されています。大規模ストアではこの選択肢が視野に入ります。
レート制限は「越えたら壊れる壁」ではなく、超過すると待たされるという性質のものです。したがって全件同期が制限に触れても、処理が失敗するわけではなく、単に時間が伸びます。この違いを知っておくと、「制限があるから全件は無理」と早合点せずに済みます。APIの呼び出し方の違いは、在庫APIのRESTとGraphQLで噛み砕いて説明しています。
差分同期が抱える隠れコスト
差分同期を選ぶなら、取りこぼしを検出する仕組みをセットで用意する必要があります。定期的に全件と突き合わせて差がないかを確認する、といった作業です。これを省略すると、静かにずれた在庫が積み上がり、気づいたときには原因を遡れなくなります。
結局のところ、差分同期は「速さを買うかわりに、正しさを確認する手間を引き受ける」という取引です。この手間を払える体制があるかどうかが、採用の判断基準になります。人手が限られている店舗ほど、単純な仕組みのほうが総コストは低くなります。
- 全件同期 — 単純で収束する。復旧が容易。商品点数が増えると時間が伸びる
- 差分同期 — 速く軽い。取りこぼしが静かに起きる。検証の仕組みが別途必要
- 共通 — どちらを選んでも、全件を流せる手段は必ず持っておく（復旧に必要）
- 判断軸 — 商品点数、1日の在庫変動件数、同期を見ている人の数、許容できる遅延
実務でのおすすめは「組み合わせる」
ここまで対比してきましたが、実際の運用では二択にする必要はありません。時間帯や目的に応じて使い分けるのが、最も無理のない形です。ここでは具体的な組み立て方をいくつか紹介します。
1日1回の全件を土台にする
おすすめしやすいのは、開店前や深夜に全件同期を1回走らせて基準を揃え、日中は必要に応じて範囲を絞った更新を行う形です。1日1回の全件があることで、日中にどんな取りこぼしが起きても、翌朝には必ず正しい状態に戻ります。安全網としてこれ以上シンプルなものはありません。
スケジュール同期を設定できる仕組みなら、この土台は設定ひとつで作れます。人が忘れる余地がないというのが大事な点です。「毎朝やる」という運用ルールは必ず忘れられますが、スケジュールは忘れません。時間帯の決め方は、スケジュール同期のベストプラクティスが参考になります。
シートの持ち方で「対象を絞る」
差分の仕組みを作らなくても、対象を絞る方法はあります。よく動く商品だけを別シートに分けておき、そちらは頻度高く、全商品を含むシートは1日1回、という運用です。「変化を検出する」のではなく「範囲を人が決める」ので、取りこぼしの心配がほとんどありません。
季節商品やセール対象など、期間限定で動きが激しくなる商品群にも同じ考え方が使えます。その期間だけ対象シートに載せ、終わったら外す。仕組みを複雑にせずに、実質的な差分同期の効果を得られる現実的な工夫です。
この方法にはもうひとつ利点があります。「いま重点的に見ている商品はどれか」がシートの形として残ることです。担当者が交代したときも、そのシートを見れば店舗の関心がどこにあるかが伝わります。設定ファイルの中に隠れた条件ではなく、誰でも開けるシートに書いてあるという点が効いてきます。
注意点は、頻度の高いシートと全体シートで同じSKUが重複したときの扱いです。どちらも同じ値を書くなら問題は起きませんが、片方だけを更新していると、走った順番によって結果が変わります。重複させるなら「頻度の高い側だけを人が更新する」と決めておくと迷いません。
方式を変える前に確認したいこと
- 01いまの全件同期に、実際どれくらい時間がかかっているかを一度計測する（体感ではなく実測）
- 021日に在庫が動くSKUの件数を数える。全体の何割かを把握すると判断が変わることがある
- 03許容できる遅延を決める。「30分以内に反映されればよい」なら選択肢は一気に広がる
- 04方式を変えた直後の1週間は、主要SKUの突き合わせを毎日行う
- 05どの方式でも、全件を手動で流せる手段を必ず残しておく
この5項目のうち、最初の2つを実測するだけで判断が変わることが本当によくあります。「全件同期は重い」という思い込みが、実は数分で終わっていた、というケースは珍しくありません。感覚ではなく数字で決めるのは、在庫まわりのあらゆる判断に共通するコツです。
全件同期と差分同期は、どちらが優れているという関係ではありません。全件は正しさを、差分は速さを買う方式です。そして在庫という領域では、正しさのほうが先に効いてきます。売り越しの謝罪一件がもたらす損失は、同期にかかる数分の処理時間よりずっと大きいからです。
多くの店舗にとっての最適解は、全件同期を土台に置き、必要な部分だけ範囲を絞って頻度を上げる形です。まずはシンプルに始めて、実測した数字が「これでは足りない」と教えてくれたときに次の手を打つ。この順番を守るだけで、在庫同期は驚くほど長く安定して回り続けます。