マルチチャネル在庫同期と売り越し：壊れたリンクの見つけ方

昨年のブラックフライデーの夜11時、ホームオーガナイズ商品の販売者から震える声で電話がかかってきた。彼はShopify、Amazon、TikTok Shopの3つで同時に販売していた。あるデスクオーガナイザーの在庫は800個。2時間で230個も売りすぎた。カスタマーサービスチームは一晩中キャンセルのために購入者に電話をかけ続け、店舗評価は一晩で星が半分落ちた。翌朝、彼は私にこう聞いた。3つのチャネルはみんな「うちのせいじゃない」と言う——では一体誰のせいなのか？

まず結論を言おう。10回中9回、マルチチャネルの売りすぎは特定のプラットフォームのせいではない。原因はその間にある層——在庫同期チェーンだ。そして私は毎回同じやり方でこのチェーンをデバッグする。1つずつリンクをたどり、壊れている箇所を見つける。どのリンクが壊れても、そこに責任が落ちる。

本当の売り越しか、幻の売り越しか？

最初のステップはログを読むことではない。1つの質問をすることだ。「販売可能在庫」は実際どう定義されているのか？

物理的な手持ち在庫をそのまま販売可能数として全チャネルに流している倉庫を、私は何度も見てきた。棚に800個あるから、販売可能も800個。だがその800個のうち、60個は検査待ち、40個は明日の卸売出荷に引き当て済み、50個は届いたばかりでまだ品質検査を通っていない顧客返品かもしれない。本当の販売可能数は650個なのに、チャネルは800個に対して売っている。150件の余分な注文がすり抜けたのも無理はない。

だから最初のチェックはこうだ。4つの数字を並べてみる——物理手持ち在庫、輸送中・検査待ち数量、引き当て済み・未出荷の予約、そして各プラットフォームが表示している販売可能数。この4つが一致しなければ、それ以上掘るのをやめて、まず定義を確定させる：販売可能＝手持ち−引き当て−検査待ち−凍結。定義を間違えれば、どんな高度な技術も誤りの上に積んだ精密さに過ぎない。

倉庫作業員がバーコードスキャナーを持ち、保管ラックの間でサイクルカウントをしている様子

更新は何分遅れたのか？

定義が正しければ、時間の遅れを追え。売りすぎはほぼ必ずタイミングの問題だ。チャネルBのページがまだ在庫ありと表示している間に、チャネルAが最後の10個を売り切った。

3組のタイムスタンプが必要だ。1つ目は、WMSで在庫変動が起きた時刻——出荷オーダーが確定した瞬間。2つ目は、WMSが更新を送信した時刻。3つ目は、各プラットフォームが実際に掲載を更新した時刻。この3つを注文ごとにタイムラインに並べれば、遅れが明らかになる。

いつもの容疑者たち：チャネルによって送信頻度が違う——あるチャネルにはリアルタイム、別のチャネルには数分ごとのバッチ（ここに出てくる間隔の数字はすべて例示であり、プラットフォーム公式の保証ではない。各プラットフォームの最新ドキュメントを確認すること——たとえば5分ごとや15分ごと）。大セールの日、バッチのチャネルがたまたま売れ筋で、数十件の余分な注文が遅れの窓から滑り込む。あるいは連携がコールバック受信ではなくポーリングなので、プラットフォームは自分のスケジュールで在庫を取りに行く。そこにネットワークのリトライが重なれば、1回の更新が10分遅れで届く——安全在庫のバッファを焼き尽くすには十分な時間だ。

私の定石はこうだ。セール当日の売りすぎ注文を20件取り出し、各注文の注文時刻、WMSの在庫引き落とし時刻、プラットフォームの在庫更新時刻を調べる。10回中8回、売りすぎ注文はすべて「遅延ウィンドウ」の中に収まる——遅れがどれだけ長くても、そのウィンドウの中で正確に売りすぎが起きている。

同じ秒の注文：実際に在庫を取ったのは誰？

もう1つ、もっとずるいパターンがある。3つのチャネルが同じ1秒——いや同じ1ミリ秒に注文を出し、WMSに3件の引き落とし要求が届いた。在庫残り2個、3件の注文がみんな「自分が先だ」と主張し、3件とも通ってしまった。

これは典型的な競合状態（レースコンディション）だ。WMSの在庫引き落としログを確認する：同じSKUが1秒以内に複数回、引き落とし成功し、それぞれが同じ古い「現在在庫」値を読んでいなかったか？もしそうなら、引き落としはアトミックではない——在庫の読み取りと書き込みの間にロックがなく、3件の要求がみんな「残り2個」を読んで、3件とも承認されてしまった。

修正は難しくないが、技術設計に明記しなければならない：在庫引き落としはアトミックな操作にすること——データベースの行ロックか、直列化されたメッセージキューだ。小さな倉庫では誰も気づかない。ボリュームが跳ね上がった瞬間に爆発する。私は2024年、カリフォルニア州オンタリオにある50,000平方フィートの3PLで見た。1日3,000件の注文はまったく穏やかだったが、ブラックフライデーの夜に20,000件が押し寄せ、並行した引き落としで人気SKUが400個売りすぎた。

返品は戻ってきた。在庫は戻らなかった。

最後のリンクは一番見落とされやすい：返品だ。100個が戻ってきて、品質検査を通り、棚に戻った——でも販売可能在庫には加算されなかった。あるいは、2日遅れで加算された。

この痛手は2つの形で現れる。1つ目は幻の欠品：商品はそこにあるのにチャネルはゼロ表示で、何もないのに売上を失う。もっと厄介なのは、返品が再格納フローを2回通り、販売可能が2回加算され、どこからともなく100個の幻の在庫が出現してチャネルが売り続けるパターンだ。

確認方法：返品注文を20件サンプルし、「品質検査完了時刻」と「販売可能在庫の加算時刻」を比べる。ギャップが自社の基準（たとえば4時間）を超えていれば、このリンクは漏れている。多くの倉庫では返品と出荷は別のチーム・別のシステムで回っている——返品は棚入れされるが、在庫同期の送信は発火しない。

本当の教訓：技術を直す前に数字を定義せよ

5つのリンクを全部たどれば、犯人は見つかる。だが順番が大事だ。まず関係者全員——オペレーション、エンジニアリング、3つのチャネルチーム——に、販売可能在庫の定義を1つ書面で合意してもらう。その後で初めて、送信頻度、コールバックかポーリングか、チャネルごとの安全在庫バッファの切り分けの話をする。定義が1で、技術はその後に続く0だ。

これが私がすべてのクライアントと回しているチェックリストだ。箱にチェックを入れていくだけ：