Black Friday 2024。あるセラーは1つの倉庫から3店舗を運営していたが、TikTok Shop の受注は6時間遅れで WMS に到着した。ヒーロー SKU は40分で完売したが、プラットフォーム上は在庫ありと表示されたままだった。300件超のオーバーセルで、カスタマーサービスの電話はパンクした。倉庫チームは理不尽に感じた——在庫はあったのだ。受注の到着が遅かっただけだった。根本原因は倉庫にはなかった。受注取込の設計にあり、初日から選択を誤っていたのだ。
10年前、マルチチャネルとは「Shopify の店がある」という意味だった。今では Shopify、Amazon、TikTok Shop、Walmart を同時に扱い、4つの方向から受注が1つの WMS に流れ込む。取り込む方法は2つしかない。ポーリング——各プラットフォームに数分おきに「新規受注はある？」と聞く方法——か、Webhook——プラットフォームが新規受注を発生した瞬間に送ってくる方法だ。どちらを選ぶかで、受注のレイテンシが分単位か秒単位かが決まり、ピーク日に眠れるか火消しに追われるかが決まる。
違いは速度だけではない
多くの人はこれを「速いか遅いか」の選択と考える。それはナイーブだ。この2つのアプローチは4つの軸で異なる：
レイテンシ。 ポーリングのレイテンシはポーリング間隔に等しい——5分おきにポーリングすれば、平均レイテンシは2分半だ。Webhook は数秒で送ってくる。普通の火曜日なら2分半など誰も気にしない。しかしヒーロー SKU が40分で売り切れるとき、4つのプラットフォームで掛け合わされたその遅れがオーバーセルになる。
コスト。 ポーリングは API 呼び出しの予算を消費する。Amazon の SP-API は厳格なレート制限を課しており、クォータを超えるとスロットルされる。ボリュームが大きいほどポーリング頻度が上がり、レート制限の壁すれすれを走ることになる。Webhook はクォータを消費しない——プラットフォームが送り、あなたが受け取る。
信頼性。 ポーリングで受注が消えることはめったにない——聞けば答えが返ってくるからだ。Webhook は2つの死に方をする。プラットフォームが送ったのにこちらが受け取っていない（ネットワークの一時障害）か、受け取ったのにきれいに処理できていない（サービスの再起動）かだ。だから Webhook にはリトライと冪等性が必須となる。同じ受注が3回送られてきても、WMS 内には必ず1件だけ存在しなければならない。ピーク中に重複受注の生成が二重出荷につながり、このことを学んだ現場を私は1つや2つ見ている。
プラットフォーム対応。 すべてのプラットフォームが Webhook を提供しているわけではない。Shopify のものは成熟しており、TikTok Shop は受注プッシュ通知を提供し、Amazon は SP-API Notifications の仕組みに依拠している——それぞれセマンティクスが異なる。各プラットフォームの最新の開発者ドキュメントを確認すること。去年の連携知識を今年の API に適用してはならない。
Amazon の件は特別な注意が必要だ。SP-API のレート制限は操作ごとに設定され、本当に強制される——Prime Day の急増時に受注ステータスを積極的にポーリングした 3PL を私は知っている。1時間近くスロットルされ、その間受注が積み上がるのを盲目のまま過ごした。彼らの修正は、自前のトークンバケット型リミッターと指数バックオフで、初日に作っておくべきものだった。Amazon をポーリングするなら、クォータはお金のように予算化せよ。各ジョブに呼び出し枠を割り当て、消費をログに残し、80%でアラートを上げること。ピーク中のスロットルは自業自得だ。
私の推奨：受注量で選べ
技術論争は忘れろ。自社の量を見て、該当する段階を選べ：
1日500件未満：ポーリングで十分。 4つのプラットフォームを5分おきに叩けばよい。レイテンシは許容範囲で、開発はエンジニア1人で数日。節約した時間は照合に使え。
1日500〜5,000件：Webhook を主、ポーリングをバックアップに。 Webhook がリアルタイムを担い、1時間おきのフルプルが Webhook の取りこぼしを拾う。私が知る中でコストパフォーマンス最高の組み合わせであり、私が関わってきた中規模セラーに最も多い構成だ。
1日5,000件超：Webhook → メッセージキュー＋照合。 プッシュはスパイク吸収のためにキューに入り、コンシューマーが冪等に重複排除し、夜間のフル照合がプラットフォーム受注と WMS 受注を突き合わせる。ピーク前にプッシュの嵐を負荷テストせよ——プラットフォームは自社の大イベント時に送りが遅れ、重複も増える。テストせずに臨むのは盲目の飛行だ。
どの段階にいても、3つのルールは譲れない。1つ、プラットフォーム受注 ID をグローバルなユニークキーにし、重複は黙って捨てること。2つ、Webhook の署名は必ず検証すること——時間を惜しんで検証を省いた現場が、偽造受注でデータベースを水浸しにしたのを見たことがある。3つ、1時間おきのフル照合ジョブを回し続けること。これはあらゆるマルチチャネル倉庫の生命保険だ——Webhook は落ちる、ポーリングは取りこぼす、照合は嘘をつかない。
その照合ジョブは独自の設計メモに値する。なぜなら多くのチームが間違った作り方をするからだ。「直近1時間に作成された受注」を比べるのではない——各プラットフォームのオープン受注の全集合を、プラットフォーム受注 ID で WMS のオープン受注と比べるのだ。ジョブはちょうど3つのリストを出すこと。WMS にないプラットフォーム受注（取込ギャップ——取り込め）、プラットフォームにない WMS 受注（上流でキャンセルか返金——レビュー対象としてフラグ）、ステータス不一致（片側は出荷済み、片側は保留中——調査）だ。1時間おきに実行し、1つ目のリストで誰かにページを飛ばし、残り2つはログに記録する。ここでの1時間のエンジニアリングが、Black Friday を救う。
冒頭の話のセラーはどうなったか？Webhook ＋1時間おきの照合に移行した。次の Black Friday：4つのプラットフォームで20,000件の受注、オーバーセルはゼロ。取込パターンに本質的な優劣はない——自社の量に合うものがあるだけだ。まず受注を数え、それからパイプを選べ。決して逆ではない。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
