楽天・Amazon・Yahoo!・自社ECの受注を1つにまとめる方法｜品番ルールの統一が先、ツールは後
楽天・Amazon・Yahoo!・自社ECの受注を1つにまとめる方法｜品番ルールの統一が先、ツールは後
自社ECに加えて楽天・Yahoo!ショッピング・Amazonにも出店していると、受注が4か所に散ります。「全部を1つの表にまとめたい」という相談は多く、たいてい「どのツールで取り込むか」から話が始まります。
結論から書きます。先に決めるのは取り込みツールではなく、モールごとに違う品番を自社の商品コードへ戻すルールです。 受注を1か所に集める作業そのものは難しくありません。手が止まるのは、集めた後に「この注文はどの商品の何色か」を特定する場面です。ここを先に片づけておけば、取り込み方式は後からいくらでも選べます。
この記事は、名古屋の革製品メーカー（自社EC＋3モール、月70件前後）で受注メール4チャネルを1つの台帳へ自動で落とす仕組みを作った際の実測をもとに、品番ルールの決め方と判定の手順を書いています。台帳そのものの設計や、APIで取る範囲とメールに頼る範囲の線引きは「ネットショップの受注を1枚のスプレッドシートに集約する設計」で書いたので、本稿はその続きにあたる「品番の正規化」に絞ります。
結論：受注メールの品番と自社マスタを並べて「規則があるか」を先に判定する
やることは1つです。各チャネルの受注メールに出てくる品番と、自社の商品マスタの商品コードを横に並べ、規則で変換できるのか、対応表が要るのかを判定する。 これだけで、その後の工数が桁で変わります。
- 規則があるなら、変換ルールを1本書けば終わりです。対応表は要りません。新しい商品を出品しても、同じ規則で自動的に引き当たります
- 規則がないなら、モールの商品コードと自社コードの対応表を作ることになります。既存の出品数だけ行が必要で、新商品のたびに1行増やす運用が続きます
多くの解説は「対応表を作りましょう」で止まっていますが、実際に受注メールを並べてみると、規則がある方が普通です。モールに商品を登録するとき、担当者は何らかの形で自社の品番を入れているからです。それが「そのまま」なのか「一部だけ」なのか「別の欄に書いてある」のかを確かめるのが、この判定の中身です。
なぜツールより先に品番なのか
集約先の表に4チャネルの注文が並んでも、品番の表記が揃っていなければ「この商品は全チャネルで何本売れたか」が数えられません。行が集まっただけの表になります。
もう1つ、現場の手作業が実際にどこで止まっているかという問題があります。受注メールを見て商品マスタを「品番の頭」で検索し、候補が複数出て目視で特定し、色も目視で確認する。その後に商品名や色名を別の表へ転記する。この流れの起点が品番の特定です。受注1件の品番を正しい商品コード・色・サイズに戻せた瞬間に、商品名も、革の必要量も、担当工場も、マスタから自動で引けるようになります。 逆に品番が確定しなければ、後ろの自動化はすべて宙に浮きます。
自動化の依頼を「受注をスプレッドシートに入れてほしい」という言葉どおりに受け取ると、この品番の特定が丸ごと手作業として残ります。依頼の聞き方については「業務の自動化で何を聞けば外さないか」で書きました。
実例：4チャネルの品番は、こう違っていた
対象は名古屋の革製品メーカーです。自社EC（Shopify）・楽天・Yahoo!ショッピング・Amazonの4チャネルで、月間の受注は自社EC30件・楽天20件・Yahoo!10件・Amazon10件の計70件前後。自社の商品マスタはPOSから書き出したCSVで約1万4千件、色やサイズ、素材、製造工場まで持つ詳細マスタが約7万6千行・118列あります。
受注メールの実物を4チャネル分並べて、品番の出方を整理したのが次の表です。
| チャネル | 受注メールでの品番の出方 | 自社の商品コードへの戻し方 |
|---|---|---|
| Amazon | SKUが「商品コード-枝番-色-サイズ-価格-登録日」の完全な規則で連結されている | 先頭2つの区切りをそのまま使えば商品コードになる |
| Yahoo! | 自社の商品コードがそのまま入り、末尾に枝番が付くことがある | 品番はそのまま使える。色は本文の「カラー：」行から取る |
| 楽天 | 商品名の末尾に括弧書きで自社の商品コードが入る。別途モール独自の管理番号もある | 括弧内を使う。色は本文の「カラー：05 サドル」のように色コードが直接出る。モール独自の番号は使わない |
| 自社EC（Shopify） | SKUが「商品コード（ハイフン抜き）＋色2桁＋サイズ2桁＋内部連番3桁」の15桁で連結されている | 区切り位置を確定してから分解する。見ただけでは境目が分からない |
4チャネルとも、対応表は不要でした。ただし、そう言い切るためには「見た感じ規則がありそう」では足りません。次の手順で数字にしました。
判定は「全数抽出してマスタと突き合わせ、一致率を出す」
いちばん判定が難しかったのは自社ECのSKUです。15桁の連結で、どこまでが商品コードでどこからが色なのかが1件見ただけでは決まりません。
そこで、直近90日分の受注メール140通からSKUを130個（重複を除いて59種類）すべて抜き出し、仮定した区切り方で分解して詳細マスタと突き合わせました。結果は次のとおりです。
| 突合項目 | 結果 |
|---|---|
| 商品コードの一致 | 59種類中59種類（100%） |
| 色・サイズまで完全一致 | 59種類中54種類（91.5%） |
| 例外5種類の内訳 | マスタ側にその色が未登録（SKUの色コードをそのまま採用して実害なし） |
商品コードが100%当たった時点で区切り方は確定です。色・サイズの例外5件も、原因がSKU側ではなくマスタ側の登録漏れだと分かっているので、変換規則を疑う必要はありません。この数字が出て初めて「対応表は要らない、変換ルール1本で行く」と決められます。
楽天・Yahoo!・Amazonは規則が見た目にも明らかでしたが、同じように実物のメールで商品コードがマスタに実在するかを確認してから採用しています。
結果：初回8日分55行、解析失敗ゼロ
規則を確定して取り込みを走らせた結果、初回の8日分は55行（楽天13・自社EC19・Yahoo!17・Amazon6）で、メールの解析に失敗した件数はゼロでした。品番から商品名・色名・革の必要量・製造工場までマスタから自動で補完され、人が見るのは次の「要確認」に落ちた行だけです。
- 品番の候補が2つある商品（1つの出品に2品番を併記していたケース）：4行
- SKUが付いていない注文（修理・カスタムオーダー）：3行
- マスタに未登録の品番：1行
全体の1割台です。残りの8割以上は、人が品番を検索することなく台帳に載ります。これが「品番ルールが先」の意味です。
手順：受注メールを台帳に落とすまでの6ステップ
同じことを自社でやる場合の順番です。
- 各チャネルの受注メールの実物を、最低1通ずつ集める。 キャンセル通知も1通あるとよいです。「こういう形式のはず」という想像では規則は判定できません
- 商品マスタを読み取り専用のCSVで受け取る。 POSや基幹システムに直接つなぐ必要はありません。書き出したファイルを引き当てに使うだけなら、事故のリスクもほぼありません
- 品番の出方を4パターンのどれかに分類する。 「そのまま入っている」「規則で連結されている」「別の欄や括弧内に書いてある」「モール独自の番号しかない」のどれかです。4つ目だけが対応表の対象になります
- 一致率を出す。 直近数か月の受注から品番を全数抜き出し、仮定した規則で変換してマスタに実在するかを数えます。9割を超えれば規則を採用し、例外は「要確認」列に逃がします。半分を切るようなら、その規則は間違っているか、対応表が必要です
- 色とサイズの取り方をチャネルごとに決める。 SKUに埋め込まれているのか、本文の1行に書いてあるのか、名前だけしか無くマスタから逆引きするのか。品番より色の方が表記の揺れが大きいので、ここは別に決めます
- 台帳の一意キーを決めて、二重取り込みを防ぐ。 チャネル＋注文番号＋明細行の組み合わせで1行を特定し、同じキーがあれば書き込まない。日次で同じメールを読み直しても行が増えない状態を先に作ります
判断基準：対応表を作るのはどんなときか
対応表が必要になるのは、手順3で「モール独自の番号しかない」に分類されたチャネルか、手順4で一致率が低かったチャネルだけです。その場合も、既存の出品を全件書き起こすのではなく、受注が来たものから1行ずつ積む方が現実的です。月70件なら、数か月で主力商品はほぼ埋まります。
もう1つ、根本的な対策があります。モールに新しく出品するときのSKUや管理番号に、自社の商品コードを必ず含める規則を先に決めておくことです。上の実例で対応表が要らなかったのは、過去に出品した担当者が結果的にそうしていたからです。出品時のルールが、後工程の自動化の難易度を決めます。
取り込み方式は「メールを読む」で足りる。ただし経路が変わる前提で組む
品番のルールが決まれば、取り込み方式は後からで構いません。月70件は1日2〜3件です。リアルタイムやWebhookは過剰で、全チャネルを日次バッチで読めば十分です。
受注メールを1つの受信箱へ転送で集める方式が一般的ですが、その前提が崩れることがあります。実際、Gmailで他のアカウントのメールをPOPで取り込む機能は、新規の追加ができなくなっています。上の実例でも転送方式は採れなかったため、受注メールを受けているPCのメールソフトがローカルに保存しているデータを、日次バッチが直接読む方式にしました。転送設定も、モール側の認証情報も、外部業者への依頼も不要で、結果としてこちらの方が簡単です。
この方式の弱点は、そのPCとメールソフトが動いていることが前提になる点です。だから取り込みの鮮度チェックを必ず組み込みます。 最後に受信したメールの時刻が48時間より古ければ「取り込み停止の疑い」として通知する。処理が正常終了したかではなく、データの鮮度で健全性を見る考え方は「自動処理の監視は「最後に成功した時刻」を見る」に書いたとおりです。
起こりうるリスクと予防策
品番ルールを確定して取り込みを自動化するときに、実際に起こりうる問題と、設計段階で潰しておく方法です。
色コードが数値に変換されて一意キーが合わなくなる。 色コード「05」をスプレッドシートに書き込むと、自動の型変換で数値の「5」になることがあります。次の日に同じ注文を読んだとき「05」と「5」が別物と判定され、二重に取り込まれます。書き込み時は型変換をしない設定（RAW入力）にし、キーに使う値は文字列のまま保持します。
転記先が複数あると、色の表現がずれてキーが合わない。 受注台帳から製造依頼リストへ転記するような二段構成では、片方が「05」でもう片方が「05 サドル」のように表現が違うと、同じ行を二重に転記します。キーを作る処理を1本の関数にまとめ、すべての書き込みで同じものを使うようにしておきます。
1つの出品に2つの品番が併記されている。 セット販売や色違いをまとめた出品で起こります。機械的にどちらかを選ばず、先頭の品番を仮採用したうえで「品番候補2件・要確認」と表示し、判断は店舗側に残します。
マスタに無い品番が来る。 解析は成功しても引き当てが空になる場合です。エラーで止めず「未処理」の別シートへ隔離し、翌日以降も残り続けるようにします。上の実例では初回55行のうち1行がこれでした。
メール本文の一部が文字化けする。 注文番号と品番の抽出には影響しませんが、備考欄の文言を自動判定に使っている場合は注意が要ります。備考は原文も一緒に台帳へ残し、人が読める状態にしておきます。
キャンセル通知の処理が実データで検証できない。 期間内にキャンセルが1件も無いと、作った処理が動くかどうかを確認できません。テスト用に1件だけ実際にキャンセルを起こして通すか、過去のキャンセルメールを1通もらって流すか、どちらかを納品前に済ませます。
まとめ
複数モールの受注を1つにまとめる仕事で、最初に決めるべきことを整理します。
- 取り込みツールより先に、モールの品番を自社の商品コードへ戻すルールを決める
- 各チャネルの受注メールの実物と商品マスタを並べ、規則があるか、対応表が要るかを判定する
- 判定は見た目ではなく、受注品番を全数抜き出してマスタと突き合わせた一致率で決める。9割超なら規則を採用し、例外は要確認に逃がす
- 色とサイズは品番とは別に、チャネルごとに取り方を決める
- 取り込みは日次で足りる。ただし経路が変わる前提で、鮮度チェックを必ず付ける
- 新規出品のSKUに自社コードを含める規則を作っておくと、対応表は将来も要らない
品番のルールが決まれば、商品名も色名も必要な材料も製造先も、マスタから自動で引けます。受注を集めることが目的ではなく、集めた後の手作業を消すことが目的なら、順番はこの通りです。
よくある質問
Q. 受注一元管理の専用ツールを入れれば、品番の問題は消えますか？
消えません。専用ツールでも「モールの商品コードと自社の商品コードの紐付け」は設定する必要があります。規則があれば一括で紐付けられ、無ければ1件ずつ登録することになるので、先に規則の有無を判定する順番は同じです。ツールを選ぶ前に判定しておくと、ツールの初期設定にかかる時間も読めます。
Q. 月に数十件なら、手作業のままでもよいのではないですか？
件数よりも、1件あたりの工程数で判断してください。上の実例では、受注1件ごとに品番の検索と目視の特定、それに続く4回の転記がありました。月70件でも、担当していた2名の作業時間を積み上げて見積もると、月におよそ76時間に相当しました。1件あたりの手数が多い業態ほど、件数が少なくても自動化の効果が出ます。
Q. モールごとに品番の付け方が違ってしまっているのは、もう直せませんか？
既存の出品を直す必要はありません。今ある表記の揺れは変換ルールで吸収できます。直すのは今後の出品ルールで、新規に登録するSKUや管理番号に自社の商品コードを含める形に揃えれば、変換ルールが将来にわたって壊れなくなります。