結論を先に言う。追跡番号がWMSと運送会社のラベルシステムの間で消えてしまうとき（いわゆるWMS追跡番号同期障害）、9割はラベルシステムのせいではない。WMSが落としているのだ。私はこの落とし穴を30回を超えるWMS立ち上げで3度見てきた。2024年のピークシーズン、ロサンゼルスの3PL倉庫は1日約3,000オーダーを出荷していて、追跡番号の消失率が2%に達した。カスタマーサービスはパンク寸前。ラベルシステムは完全に健全だった。3つの漏れはすべてWMS側にあり、毎回同じ3つの破綻ポイントだった。ラベルは印刷されたのに番号が戻ってこない。番号は戻ってきたのに別のオーダーに紐づいた。番号はWMS内では正しいのに下流システムに届かない。この記事では各破綻ポイントの見つけ方と直し方を解説し、最後にそのまま使える立ち上げ当夜のチェックリストを載せる。
破綻ポイント1：ラベルは印刷されるのに追跡番号が戻ってこない
消失が間欠的なら、まずラベルコールバックとWMSへの書き戻しが非同期かどうかを疑え。10回中9回、それが答えだ。
その3PL倉庫では、消失は毎日14時から16時に集中していた。静かな時間帯には消え、ラッシュになると戻ってくる。ログが物語を語っていた。ラベルシステムはまずラベルのPDFを返し、追跡番号は別系統の非同期コールバックで、タイムアウト5秒で後から届いていた。ピーク時間帯にラベルシステムが遅くなり、コールバックが遅延し、WMSはすでに「ラベル作成済み」と記録していた。ラベルはきれいに印刷され、荷物はきれいに出荷され、そのオーダーは「出荷待ち」としてWMS内に永遠に残り、カスタマーサービスは渡せる追跡番号を持たなかった。
修正は3ステップで、どれも省略不可だ。まず、ラベル作成と番号書き戻しを別々に確認する。ラベルPDFの到着は「ラベル作成済み」を意味するが、「番号受領済み」を意味するのは追跡番号入りの出荷テーブル行だけだ。この2つは別々のステータスフィールドに格納し、絶対に1つにしない。次に、リトライ付きでコールバックを冪等にする。ラベル側はネットワークが途切れるとコールバックを再送してくるので、WMSは重複を認識しなければならない。コールバックがまったく届かないときは、WMSは待つのではなく自分で番号を取りに行かなければならない。3つ目は、セーフティネットのポーリングジョブを追加することだ。15分ごとに、ラベルはあるのに追跡番号がないオーダーを全部なめ、各1件をラベルシステムに照会する。このポーリングジョブは命綱だ。詳細は後述する。
破綻ポイント2：番号は戻ってきたのに別のオーダーに載ってしまう
この破綻ポイントは複数小包オーダーを得意とする。ラベルシステムは小包単位で追跡番号の配列を返す。1オーダーが2小包に分かれれば追跡番号は2つだ。ところが多くのWMS出荷テーブルはオーダー単位、1オーダー1行で、開発者は近道をした。配列の先頭の番号をつかんでオーダーヘッダーに詰め、残りを捨てた。
2025年3月、家庭用品EC倉庫がまさにこの穴に落ちた。顧客は1つ目の小包を受け取った。2つ目の小包の追跡番号はWMSのどこにも存在しなかった。カスタマーサービスは運送会社サイトで1つ目の小包の番号を調べ、「配達済み」と表示され、顧客はオーダーの半分が行方不明だと主張した。1週間の言い合いの末、2つ目の小包がまだ輸送中であることが判明した。誰もその追跡番号を知らなかった。修正は単純だ。出荷テーブルは小包単位でなければならない。3アイテム2小包の1オーダーは出荷レコード2件になり、各追跡番号は小包と1対1で紐づく。立ち上げ当夜のチェックリストにもこの項目がある。3アイテム2小包のテストオーダーをエンドツーエンドで実行し、追跡番号2つがどちらもWMSで取得可能でなければならない。
梱包ステーションにも連動する手順がある。ラベルを小包に貼った後、作業員がハンディスキャナーでラベルバーコードをスキャンし、WMSがその場でスキャン番号とシステム格納番号の一致を検証する。小包1つあたり3秒。ラベル貼り間違いという地味だが致命的なミスを拾う。時間節約のために飛ばしてはいけない。1回の取り違えは、1年分のスキャンより多くのカスタマーサービス工数を食う。
破綻ポイント3：WMSは番号を持っているのに下流に届かない
WMSでは追跡番号が全部そろって見えるのに、OMSと販売チャネルは空白のままだ。この落とし穴も3度見たが、根本原因は毎回まったく同じだ。プッシュAPIがHTTP 200を返し、開発者がそれを成功とみなした。
200は「リクエストを受け取った」だけの意味で、「正常に処理した」ではない。ある倉庫では、WMSがOMSにプッシュし、OMSが200を返し、WMSはオーダーを「プッシュ済み」とマークした。ところがOMSのDB書き込みは失敗していた。エラーはレスポンスボディの中にあり、WMSはそれを解析していなかった。消失率は低く、月数十オーダー。すべてこの種の「偽の成功」だった。見つけ方。各プッシュのレスポンスボディ全文をログに保存し、週1回、エラーキーワードを含むボディを洗い出す。直し方。成功は相手側の業務ステータスで判定する。相手の照会APIを叩いて2重確認するか、受領確認を要求するかだ。2重確認が不可能なら、最低限ボディを解析し、エラーキーワードでアラートを上げる。
逆説的な話：リアルタイム同期信仰をやめよう
多くのチームは、リアルタイムAPI書き戻しが最も信頼できる選択肢だと信じている。チェーンがリアルタイムであるほど良い、と。30回を超える立ち上げを経た私の判断は逆だ。リアルタイムチェーンはリンクが多いほど障害面が大きくなり、WMS追跡番号同期障害はほぼ必ず「リアルタイム＝鉄壁」という思い込みから生まれる。
トレードオフは明確だ。純リアルタイム。低遅延。だがラベル側、ネットワーク、WMSのどこかがつまずけば番号が落ち、頼れるのはリトライロジックだけになる。そしてそれは、立ち上げ前に真っ先に削られるものだ。リアルタイム＋定時リコンシリエーション。1日2回、フルリコンシリエーションジョブを回し、WMS内のラベル済みオーダー全件をラベルシステムの追跡番号レコードと突き合わせ、欠けを埋める。リコンシリエーションは数時間遅れるが、消失率はほぼゼロになる。私の推奨は両方だ。リアルタイム書き戻しは残し、リコンシリエーションジョブは必須にする。構築は開発者2人日ほど。それが夜ぐっすり眠れる唯一の方法だ。
計算してみるとさらに明確になる。1日3,000オーダーで消失率2%なら、1日約60オーダーが手作業介入を要する。1件ごとに、オーダー照会、顧客連絡、追跡番号再発行で約5分かかる。月約150時間、フルタイムのカスタマーサービス担当の約3分の1だ。対する側。リコンシリエーションジョブ、開発者2人日、毎日自動実行、消失率を0.1%未満に押し下げる。算数は雄弁だ。
立ち上げ当夜のチェックリスト
| チェック | 方法 | 合格基準 |
|---|---|---|
| ラベル作成済みと番号受領済みを別格納 | 出荷テーブルのステータスフィールドを確認 | 独立した2フィールド、どちらも必須 |
| コールバックの冪等性 | 同じ追跡番号を2回プッシュ | 2回目は重複と認識、汚いデータなし |
| コールバックタイムアウト時の能動照会 | コールバックを10分間止める | WMSが自分で番号を取得、手作業なし |
| 複数小包オーダーの完全書き戻し | テストオーダー：3アイテム、2小包 | 追跡番号2つがWMSで取得可能 |
| 梱包ステーションのスキャン検証 | 現場で作業員を観察 | バーコードスキャンが標準手順 |
| 偽の成功プッシュ | プッシュログのレスポンスボディを読む | エラーキーワードでアラート発火 |
| 定時リコンシリエーションジョブ | スケジューラ設定を確認 | 1日2回以上実行、全件突き合わせ |
| 消失率のベースライン | 初週は毎日測定 | 0.5%超えは当日中に原因究明 |
この落とし穴も3度見たが、毎回チームは立ち上げ前に「ラベルが印刷できている、もう終わりだ」と思い、立ち上げ後に追跡番号書き戻しが逆を教えた。1行だけ覚えてほしい。印刷されたラベルは連携の半分にすぎない。連携が終わるのは、追跡番号が無事WMSに戻り、さらに無事すべての下流システムに届いたときだ。
Lin Xiao（WMS導入コンサルタント）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
