1つの商品に5つの名前：OMSにおけるチャネルSKUマッピングの実践ガイド

月曜の朝8時、コーヒーがまだ淹れ終わらないうちに電話が鳴った。クライアントがグループチャットにスクリーンショットを投げてきた：OMSの例外キューに47件の注文が滞留し、すべて「商品不一致」とフラグ付けされている。ブラックフライデーから3週間が過ぎ、返品シーズンは真っ盛り。この47件をこのまま放置すれば、カスタマーサービスはパンクする。

リモートでログインして一見して、思わず笑ってしまった。何も壊れていない。前週に新しいTikTok Shopの店舗を開設し、運用チームが二十数点のベストセラーをTikTok側のSKU命名規則で登録したが、それがOMSの何とも一致しなかった。注文自体は順調に入っていた――OMSはそのSKUを一つも認識できず、できることは一つだけだった：例外キューに並べ、人が引き取りに来るのを待つこと。

これこそ、マルチチャネル販売で最もありふれ、最も過小評価されている問題です：チャネル商品マッピング。1つの商品に5つの名前。AmazonではAMZ-BLK-HOODIE-L、WalmartではWM_98213、ShopifyストアではHOODIE-BLK-L-2024、TikTok ShopではTTS@hoodie-black-l。名前は5つ、実物のパーカーは1つ。チャネルから注文がOMSに取り込まれる瞬間、システムはこの5つの名前が同じものを指していると知らなければなりません。そうでなければ、良くて例外の山――悪くて誤出荷と誤った在庫引き当てです。

この業界での20年が一つだけ確実に教えてくれたことがあります：マッピングテーブルはスプレッドシートではありません。OMS注文フロー全体を支える土台です。土台を間違えれば、下流のすべて――WMSのフルフィルメント、財務の照合――が一緒に傾きます。

マッピングテーブルの実物

結論から言います：正しいマッピングの粒度は「チャネル」ではありません。「チャネル×店舗」です。

多くの企業は最初のマッピングテーブルをチャネル単位で作ります――AmazonのSKUをOMS商品に、WalmartのSKUをOMS商品に。すると2つ目のAmazon店舗を開設したとき、たとえば本ブランド店とアウトレット店で、同じ商品を異なるチャネルSKUで売ると、テーブルは破綻します。だから初日から、マッピングキーは3つの要素で構成すべきです：チャネル＋店舗＋チャネル側SKU。

実際に使えるマッピングテーブルに必要なのは、ほんの一握りの列です：チャネルコード、店舗ID、生のチャネル側SKU、チャネル側タイトルのスナップショット、対応するOMS商品ID、ステータス、有効日。なぜタイトルのスナップショットにこだわるのか、とよく聞かれます。例外キューをトリアージするとき、タイトルを一目見れば注文が何なのかおおよそ分かる――SKU文字列から推測するより10倍速いからです。ステータス列も忘れないでください。商品がチャネルで販売終了になったら、マッピングを無効化してください。削除はダメです。削除すると、履歴注文からどう翻訳されたかの記録がすべて消えます。照合は悪夢になります。

現場からの教訓、あと3つ。

一つ目、**照合は必ずチャネル側SKUで行い、タイトルは使わない。**タイトルは運用担当が一日中書き換えるもの――今日は「Hot Sale」、明日は新しいキーワード。タイトルで照合すれば、マッピングを毎日作り直すことになります。SKUは比較的安定しています。チャネル注文における最も信頼できる拠り所です。

二つ目、**照合前に大文字小文字と空白を正規化する。**Shopifyからは末尾に空白のついたSKUが届き、Amazon側は全部大文字、OMSは小文字で保持している――システムにとっては3つの異なる文字列でも、人の目には1つの商品。翻訳前にすべて小文字化して空白をトリムすれば、1行のコードで「偽の」例外のおよそ3分の1が消えます。

三つ目、**UPCをフォールバックキーとして保持する。**SKUは各チャネルが勝手につける名前ですが、UPCは商品のID番号であり、どこでも同じ。新商品を登録するときに商品マスターに記録しておきます。SKUが一致しなければ、UPCでもう一度照合。驚くほど多くの注文が救われます。

一致しなかった注文の行き先

翻訳に失敗した注文は例外キューに入れます。削除はしないし、強制作成はなおさらダメ。

キューは3つの課題を解決しなければなりません：例外が正常な注文を止めないこと、人が素早く片付けられること、修正後に注文が自動で回復すること。私の標準構成：注文取り込みジョブが未マッピングのSKUに当たっても、OMS注文は作りません。例外レコードを1件書きます――チャネル、店舗、チャネルSKU、タイトル、数量、注文時刻、「未引取」フラグ付き。正常な注文は1秒の遅れもなく流れ続けます。

人が1日2回キューを掃除します――10時と16時、ピークシーズンは4回。手は3つだけ。「引き取る」：このチャネルSKUがどのOMS商品か確認し、マッピングを追加すれば、注文は自動で再翻訳されます。「まとめる」：同じ買い手が複数チャネルで注文したら、社内ポリシーに従って荷物をまとめます。「捨てる」：テスト注文と不正注文はクローズ。

そのルーティンの裏には、痛い教訓があります。Thanksgiving 2023――カリフォルニア州オンタリオの3PLクライアントが、マッピングを作らないまま200超の新SKUをブラックフライデーに向けて公開しました。取り込みジョブは忠実に例外をすべてキューに入れましたが、誰も見なかった――みんな「システムがなんとかする」と思っていたから。3日後、キューには900件超の注文が溜まり、カスタマーサービスはすでに3回目の怒りの電話ラッシュを受けていました。それ以来、私のクライアント向けルールは：**例外キューには必ずオーナーを置く、ピーク時は1日4回以上チェックする、50件超の滞留でSMSアラートを飛ばす。**誰も見ないキューは、キューがないのと同じ。

一段を割くべき特別なケース：バンドル。1つのチャネルSKUが2つのOMS商品に対応――「パーカーを買うと靴下プレゼント」の定番パックSKU――は1対多の関係です。翻訳はこれを2つの注文明細に分割しなければならず、それぞれが自らの在庫を引き当てます。OMS製品の多くは1対1のマッピングしかサポートしないので、選定時に1対多のサポートを必ず確認してください。稼働後に気づけば、本番システムにパッチを当て続ける羽目になります。

新チャネルの立ち上げを3ステップで

新しいチャネルはすべて、マッピングをゼロから始めます。私の標準プレイブックは3ステップで、今まで一度も失敗していません。

ステップ1：全SKUリストをエクスポートし、何も売る前に照合する。店舗ができて商品が掲載されたら、最初の仕事は売ることではなく――チャネルのバックエンドからライブのSKUリストをエクスポートし、OMS商品マスターと1行ずつ突き合わせて最初のマッピングテーブルを作ることです。ミス1件ごとにその場で判断：OMSに商品がない（作る）のか、運用がチャネルSKUを間違えて命名した（直す）のか。**順番は常に「マッピングが先、販売は後」。**逆にすると、月曜朝の47件の例外が待っています。

ステップ2：注文取り込みを接続し、翻訳と例外処理をセットでリリースする。API連携ができたら、いきなり全量はやらない。直近7日間の実注文を翻訳フローに流し込んでマッピングのカバレッジを確認します。私の基準は98%――下回れば最初のマッピングテーブルに穴があるので、埋めに行きます。リプレイが通ったらライブ取り込みに切り替え、本当のトラブルが来る前（後ではない）にキューアラートルールを設定しておきます。

ステップ3：1週間照合する。カバレッジが安定するまで、チャネルは立ち上がったことにならない。毎日、3つの数字を突き合わせます：チャネル側の注文件数、OMSでの注文成功件数、キュー内の新規例外。第1週は毎日、第2週は隔日、きれいになったら定常チェックに引き継ぎます。新チャネルのマッピングテーブルは最初の2週間、ほぼ毎日数行ずつ増えます――それは正常です。ロングテールSKUは必ずすり抜けますが、プロセスが軌道に乗れば、マッピング1件の追加は2分で終わります。

倉庫オフィスでマルチチャネル注文を処理するEコマースオペレーター