APIリトライによる重複注文：二重出荷はなぜ起きるのか、どう防ぐか

まず言わせてくれ。15年もハンドルを握ってきて、路上ではいろんな奇妙な光景を見てきた。だが、荷主にとって毎回胸が痛む種類の奇妙さがある：まったく同じ貨物が、2回出荷されることだ。

昨年の11月下旬、ブラックフライデーの直後だった。Rancho Cucamongaの配送倉庫で積み込みの順番待ちをしていたところ、倉庫リーダーの老王（ワン）が近づいてきて言った。「師傅（シーフー）、あんたのこの積荷、ちょっとおかしいぞ」。書類を見ると：同じレーン、同じ納品先住所（Phoenixの自動車部品店）、同じSKU（ブレーキパッド、48ケース）、注文番号までほぼ同じに見える——タイムスタンプだけが違った。1件目は9:41 AM、もう1件は9:45 AM。4分差だ。システムは出庫オーダーを2件生成し、配送ラベルを2枚印刷し、ピッカーたちはすでに同一のパレット2枚をドックにステージング済みだった。

「2回プッシュしたのか？」と聞くと、王は苦笑いした。「プラットフォームのAPIが hiccup して、ACKが返ってこなかったから、もう一度プッシュしたんだよ」。

その日、私はRancho CucamongaからPhoenixまで、同じ住所行きの同一ブレーキパッドを2台分運んだ。サインは2つもらった。受領担当者は困惑していた。「注文は1回しかしてません」。余分な1台分は拒否され、はるばる持ち帰りになった。この無駄な往復輸送で、荷主は数百ドルを失った。何のためでもなく。

しかも初めてじゃない。2024年の夏、Fontanaの生活雑貨倉庫で積み込みをしていたとき、フロアスーパーバイザーの小李（リー）が愚痴をこぼした：繁忙期になると、彼らのシステムは毎月数百件の「重複疑い注文」を吐き出す——同じ購入者、同じ住所、同じ商品が、数分差で注文されている。ある専任担当者の毎朝の最初の仕事は、それらを手作業で探し出し、大セール期間中は1日に50件から60件もフラグ付けすることだった。見つけられたものは運がよかった。見逃したものは？2回出荷された。貨物を取り戻すのは別の話だ——顧客が拒否するか返品するか、輸送費はどちらにせよ戻らず、商品は道中で傷だらけになって帰ってくる。

では実際、なぜこんなことが起きるのか？解説しよう

仕組みは電話とまったく同じだ。

倉庫に電話する：「おい王、100個をPhoenixに送ってくれ」。話の途中で電話が切れた。聞こえたかどうかわからないから、もう一度かけて同じことを言う：「100個をPhoenixに送ってくれ」。それを聞いた彼は考える——わかった、注文は2件だ、トラックを2台出そう。

販売プラットフォームと倉庫システムの間で起きているのはこれだ。ただ彼らはそれを「API注文プッシュ」と呼ぶ。流れはこうだ：顧客がプラットフォームで注文し、プラットフォームがAPI経由で倉庫システムに注文をプッシュし、倉庫システムが「了解」と返す。だが時々ネットワークがつまずいたり、倉庫システムが混雑したりして、ACKが時間内に返ってこない。プラットフォームは注文が届かなかったと判断し——もう一度プッシュする。同じ注文が、数分差で。

倉庫システムに「これ、前にも見たことないか？」と尋ねる分別がなければ、2回のプッシュを2件の別注文として扱う：出庫オーダー2件、ラベル2枚、ピック2回、出荷2回。ドライバーが積み込むとき、書類上の住所もSKUも数量もすべて合っている。おかしいところは何もない。そしてこうして、同じ貨物が2回出荷される。ここで多くの人が間違える：これはピッカーのせいじゃない。ピッカーは書類通りに動く。システムが注文2件のピックを指示すれば、彼らは2件ピックする。根本原因は1つ上の層、つまりインテグレーションにある——注文が届いたその瞬間に「この注文、もう見たことないか？」と誰も尋ねなかったのだ。

二重出荷は実際いくら損するのか？計算してみよう

多くの人がこう考える：たかが1回余分に出荷しただけ、送り返せばいい。1件の重複した小口注文が実際に燃やす金額を分解してみよう。

コスト項目	金額（USD）	備考
余分な出庫輸送費	$8–12	3ポンドの荷物、州をまたぐUPS/FedEx Groundで、だいたいこの範囲
返送輸送費	$8–15	拒否・返品——荷主負担で、返送ラベルの方が高い
余分な倉庫人件費	$4–6	ピック、検品、梱包、ラベル貼り——すべて人の時間
カスタマーサービス時間	$5–10	クレーム対応、注文の追跡、返品手配
梱包資材	$2–3	箱、緩衝材、ラベル——一度出荷したら戻らない
合計	$27–46	しかもこれは重複注文1件あたり

大したことなさそうに見えるだろ？だが量が効いてくる。1日5,000件の注文をさばく倉庫を考えてみろ。控えめに見積もっても0.5%の重複率で、1日25件の二重出荷だ。1件$35として、1日$875——300営業日で年間$260,000だ。しかも隠れたコストは別だ：顧客が全部2つずつ受け取ったとき、最初に思うのは「なんて気前のいい売り手」じゃない。「この売り手はめちゃくちゃだ」だ。悪いレビュー、キャンセル注文、二度と戻らない顧客——そうした損失はスプレッドシートには収まらない。

梱包ステーションでバーコードスキャナーを使って配送ラベルを確認する倉庫作業員

荷主と倉庫への実践的アドバイス

長年路上を走ってきて、1つわかったことがある：この問題の修正は積み込みドックにはない。ITにある。だが荷主や倉庫オーナーは、ITにどう頼むかを知っておく必要がある——平易な言葉で。そうでないと、ITは「システムは正常に動いている」と思い込み、ドックの現場は毎日火消しに追われる。翻訳はこうだ。

第一に、注文番号はすべて一意でなければならない——そしてシステムはその一意性を実際に守らなければならない。

プラットフォームを出るすべての注文は、グローバルに一意な注文番号を持つべきだ——トラックのVINのように、決して重複しない。倉庫システムが注文を受け取ったら、最初にすべきは出庫オーダーの生成じゃない。確認だ：この注文番号、前に見たことないか？見たことがあれば、2件目をブロックかマージする。なければ進める。これを重複排除（デデュープ）と呼ぶ。気取った言葉だが、要は「ナンバープレートを読む」だけだ。

第二に、同じリクエストを3回送っても、1回送ったのと同じ効果でなければならない。

ITの人たちはこれを「冪等性（idempotency）」と呼ぶ。怖い言葉だが、意味はシンプルだ：「100個をPhoenixに送れ」を1回言おうが3回言おうが、結果は100個でなければならない——300個じゃない。ITに話すときはこう言え：「APIがタイムアウトしてリトライするとき、同じ注文が複数回プッシュされても、出荷は1回だけにしなければならない」。どうやるかは彼らに任せろ。お前が言うのは、何を、だ。

第三に、リトライにはクールダウンと上限が必要だ。

リトライ自体は悪者じゃない——ネットワークがつまずいたときにリトライしなければ注文が失われ、そっちの方が悪い。だがリトライは盲目的で無限であってはならない：1回プッシュして、ACKがなければ数十秒待って、もう一度プッシュする。2回か3回試して、それでもダメなら、がむしゃらに叩き続けず人に渡す。重複注文の多くは、プラットフォームが1分間に同じ注文を5回も6回もプッシュし、倉庫システムがそのすべてを受け入れてしまうことから生まれる。

第四に、倉庫には人間のセーフティネットが必要だ。

システム修正には時間がかかる。ITが直すまで、倉庫は毎朝15分かけて「重複疑い」をスクリーニングすべきだ：同じ購入者、同じ住所、同じSKU、注文間隔が30分以内——人間に確認させるためにフラグを立てる。あのFontanaの倉庫？この1手で繁忙期の重複の大半を捕まえた。手作業のスクリーニングは粗いが、肝心なときに助けてくれるのは粗い道具だ。

最後に1つ、直感に反すること：**多くの倉庫KPIは実は二重出荷に報いている。**倉庫はピック速度で評価される——「注文ドロップから2時間以内に出庫」。システムに同一注文が2件現れたら、時計と競争しているピッカーは、ただピックしてしまうことを喜ぶ。あの2件が実は同じ注文じゃないかと考える時間は誰にもない。速度KPIが厳しいほど、重複はすり抜ける。トレードオフだ：速度が欲しければ、チェックはシステムが代わりにやらなければならない。システムがチェックしなければ、速度は「速いけど間違い」になる。だから処理時間を追い込む一方で、検証のための時間と人員を予算に入れなければならない——そうでないと、現場に顧客の金でギャンブルさせていることになる。

もう1つ：「うちは小さいから起きない」と自分に言い聞けるな。重複プッシュは注文量なんて気にしない——ネットワークの hiccup 1回、サーバーの再起動1回で、1日50件の倉庫も同じようにやられる。しかも小さい倉庫の方が痛い：1件の二重出荷が、薄い利益のより大きな部分を食う。