1「同じ商品なのに、コードがモールごとに違う」が当たり前になっていませんか

楽天では RAK-001-RED-M、Amazonでは amz_redM_v2、Yahoo!では 0001赤M、自社の在庫管理ツールでは SKU-1024――。同じ赤・Mサイズの同じ商品なのに、4つのコードを行き来して人間が頭の中で突き合わせている。マルチモール運営の現場で、これは珍しい話ではありません。

最初は1モールだけだったのが、楽天を始めたタイミングで楽天用のコードを追加し、Amazonに展開したときに別のルールで採番し、Yahoo!出店時にまた別の人が別のルールで作り――気づけば社内で誰も全体像を説明できない状態になっています。

この状態のまま、在庫連動を組もうとすると必ずどこかでズレが出ます。売上を統合しようとすると同じ商品が別々の行として集計されます。誰かが退職すると、なぜそのコードがそうなっているのか永遠にわからなくなります。

本記事では、11年のEC実務で何度も見てきたSKU設計の失敗パターンと、最初に決めておけば詰まなかったルールを整理します。すでに混乱しているケースの建て直し方も、後半でお伝えします。

2SKU設計でやりがちな5つの失敗パターン

「商品コードなんて、わかりやすければ何でもいい」と思って始めると、ほぼ確実にこのどれかにハマります。

パターン1：商品名やメーカー型番をそのままSKUにする

「タオル_白_L」「KS-2024-A型番」のように、人間が読める文字列をそのままSKUにするパターン。最初は親切に見えますが、メーカーが型番を変えたとき・商品名をリニューアルしたときに、過去データと連続性が切れます。

そして、こういう「意味のあるSKU」は後から意味が変わると訂正の圧力がかかります。「白」を「ホワイト」に変えたい、「L」を「LL」に統合したい――そのたびに、コード変更が議論にのぼり、議論したまま放置されます。

パターン2：モール開始順に1から連番で採番する

SKU-001, SKU-002, SKU-003...と、出品した順番に番号を振っていくパターン。これも、最初の100点くらいまではうまくいきます。

問題はカテゴリ・ブランド・取引先で並び替えたいときに、SKUに何の意味も入っていないこと。結局、SKUとは別に「カテゴリコード」「ブランドコード」を商品マスタに持たせる必要が出てきます。それなら最初からSKUにその情報を入れるべきだった、と後から気づきます。

パターン3：全角・半角・記号・大文字小文字が混ざる

「ＳＫＵー００１」「sku-001」「SKU_001」「SKU 001」――同じ意味のつもりが、システム上はすべて別のSKUとして扱われます。

とくに事故が起きやすいのは以下の組み合わせです。

混ざりやすい要素	典型的な事故
全角ハイフン「ー」と半角ハイフン「-」	VLOOKUPで突合できず、在庫が反映されない
大文字 SKU と小文字 sku	モール側は区別、自社DBは区別しない、で行数が合わない
アンダースコア _ とハイフン -	担当者ごとに違うルールで入力され、マスタが二重化
スペース有無「SKU 001」「SKU001」	CSVで前後の空白が見えず、原因不明のエラーが続く
絵文字・機種依存文字	モール側で受け付けられず登録失敗

パターン4：バリエーション軸を含めない、または含めすぎる

色・サイズ・容量といったバリエーションをSKUにどう反映するかは、設計で最も悩ましい部分です。

• 含めないと、楽天・Amazonのバリエーション登録機能と紐付けるときに別表が必要になり、管理が二重化する
• 含めすぎると、商品名・カテゴリ・素材・色・サイズ・販路・年度...と続いてBAG-LEATHER-BLK-L-2024-RAK-V2のように長大化し、人間が読めなくなる

正解は「親SKU（商品本体を識別）」と「子SKU（バリエーションまで識別）」を分けて、子SKUは親SKU + 軸記号 で機械的に作る、という二段構成です。詳しくは第4章で扱います。

パターン5：廃番・再販で同じSKUを使い回す

「もうこのSKUの商品は売らないから、新商品にこの番号を付け替えよう」――これが最大の事故源です。

SKUを使い回すと、過去の注文履歴・レビュー・在庫履歴・売上集計が、別商品のものと混ざります。「2023年に売れたSKU-001」と「2025年から売り始めた別物のSKU-001」が同じ行に集計されてしまい、過去データの分析が壊れます。

3「コード変更」が後からほぼ不可能な6つの理由

「気づいたところで直せばいいのでは？」と思うかもしれません。残念ながら、稼働中のEC事業ではSKU変更は想像の10倍コストがかかります。

理由1：モール側の商品IDと紐付いている

楽天の商品管理番号、AmazonのSKU、Yahoo!のサブコードは、そのまま広告・URL・モールの内部DBにも紐付いています。SKUを変えると、楽天SKUプロジェクトの設定、Amazonの出品ステータス、SEO上の蓄積、広告のターゲティング履歴が失われます。

理由2：注文履歴・レビュー・販売実績がコードに付いている

過去の注文データはSKU単位で保存されています。コードを変更すると「過去」と「現在」が連続したデータとして見られなくなります。レビューもAmazon商品ページに紐付いているため、SKU変更は実質「商品ページを作り直す」ことになります。

理由3：在庫管理ツール・受注管理ツール・倉庫システムすべてに変更が必要

ネクストエンジン、TEMPOSTAR、GoQSystem、各種WMS（倉庫管理システム）、自社の販売管理ソフト、Excelの集計表――SKUは社内の至るところに散らばっています。1つの変更で、関係システムすべての書き換えが発生します。

理由4：倉庫の現物に貼られたラベル・棚番が連動している

これが意外と忘れられがちですが、倉庫の棚にもSKUのラベルが貼ってあります。コードを変えるなら、ピッキングリスト、ラベル、棚番マップ、現場スタッフの記憶を全部更新する必要があります。事故が起きるのはほぼ確実です。

理由5：ヤマト・佐川・郵便などの配送伝票・送り状ソフトとの連携

受注データを送り状ソフトに流す自動連携も、SKU基準で動いていることがあります。コードを変えれば、送り状の品名・伝票区分・梱包指示が一斉に狂います。

理由6：法的・税務的に「同じ商品の連続性」が必要なケースがある

軽減税率の対象/非対象、酒類・医薬品・PSEなどの規制商品、リコール対応――「いつから・いつまで・どのSKUで・どの仕様の商品を売っていたか」を後から追える状態にしておく必要があります。SKU使い回しはこの追跡を壊します。

4最初に決めるべき5つのルール

事業の最初の100SKU、遅くとも1,000SKUに到達する前に、以下の5つを文書化して関係者全員で合意してください。後からの修正がほぼ不可能なぶん、最初に決める価値は計り知れません。

ルール1：マスタSKUとモール別SKUを分ける

社内で使うマスタSKU（自社の真実の源）と、各モールに登録するモール別SKUを分離します。マスタSKUは絶対に変えない。モール別SKUはモールの仕様に合わせて派生させ、マスタSKUとの対応表を持つ。

役割	例	変更可否
マスタSKU	TWL-001-WHT-L	絶対に変えない
楽天用SKU	twl-001-wht-l	モール仕様に合わせる
Amazon用SKU	TWL001WHTL	モール仕様に合わせる
Yahoo!用SKU	twl-001-wht-l	モール仕様に合わせる

ルール2：半角英数字とハイフンだけで構成する

SKUは半角英数字（A-Z, 0-9）とハイフン（-）のみとします。アンダースコア・スペース・全角・記号は禁止。理由はシンプルで、各モール・各ツールで一律に扱える文字集合がこれだからです。

• 大文字小文字は大文字に統一（モールによって区別/非区別が異なるため、変換事故を避ける）
• 区切り文字はハイフン1種類（アンダースコアとの混在を防ぐ）
• 長さは最大40文字程度に収める（モール側の桁制限を超えない）

ルール3：桁数を固定する（連番はゼロ埋め）

連番部分は 1, 2, 3 ではなく 0001, 0002, 0003 のように桁数を固定してゼロ埋めします。これにより、Excelやテキスト並び替えで意図通りの順序になります。

桁数は将来のSKU数を見込んで決めます。年間100点ペースで増えるなら4桁（最大9,999点）、ブランド・カテゴリで分けるなら3桁ずつでも足ります。「足りなくなったから5桁にしよう」は事故のもとなので、最初から多めに取ってください。

ルール4：意味の階層は「カテゴリ-連番-バリエーション」

SKUに最低限の意味を持たせる構造として、3階層構造をおすすめします。

ポイントは、カテゴリコードは3〜4文字の固定長で、現場が口頭で言える長さに収めること。「タ-001-白-L」のような全角・無秩序な略称は避け、英字の固定アルファベットにします。

ルール5：廃番・改版のルールも先に決める

運用中に必ず起きる廃番・仕様変更・再販のルールを最初に決めておきます。

• 廃番：SKUは残し、状態フラグを「廃番」にする。同じSKUは二度と使わない
• 仕様変更（素材・色味・原産国）：原則、新SKUを切る。連番を進める
• 軽微な変更（パッケージのみ・JAN同一）：同一SKUのまま、版数を別フィールドで管理
• 再販（同一仕様）：同一SKUを使う。誤って新SKUを切らない

このルールを商品登録フォームのレベルで強制しておくと、担当者ごとのブレが激減します。

5すでに混乱している現場の建て直し方

「うちはもう、ぐちゃぐちゃの状態で1万SKUある」――この場合でも、無理にすべてのSKUを変更する必要はありません。「これからどうするか」と「過去をどう扱うか」を分けて段階的に整理します。

ステップ1：マスタSKU表を新設する（既存SKUは変えない）

まず、すべての商品に新ルールに沿ったマスタSKUを割り当てる対応表を作ります。既存のモールSKU・在庫管理ツールのSKUは触りません。マスタSKUを「真実の中心」に据え、既存のSKUは「マスタSKUに紐付く別名」として扱います。

ステップ2：新規商品から新ルールを適用する

これから登録する新商品は新ルールでマスタSKUを採番し、各モールにも新ルールのSKUで登録します。既存商品は触らないので、現場の混乱は起きません。3年もすれば、新規率の高い商品から自然に新ルールに置き換わります。

ステップ3：商品マスタに「ステータス」と「優先度」を持たせる

すべての既存SKUに以下の管理情報を持たせます。

• ステータス：稼働中 / 廃番予定 / 廃番
• 優先度：A（売上上位）/ B / C（販売停止検討）
• リネーム予定：いずれ新ルールに乗り換える / 廃番まで放置

これで、「どのSKUを優先的に整理するか」の判断基準が生まれます。Aランクの売れ筋から順に、廃番タイミングや商品ページリニューアルのタイミングで新SKUに切り替えていきます。

ステップ4：在庫連動・売上集計はマスタSKU基準で組み直す

在庫管理・売上集計のロジックを、マスタSKUを軸に書き換えます。各モールから来るデータは、最初の処理ステップで「モールSKU → マスタSKU」に変換してから集計に回します。

これだけで、ABC分析・在庫回転率・粗利分析が「同じ商品」単位で正しく出るようになります。経営判断のためのデータが、ようやく機能し始める瞬間です。

6マスタSKUを統一すると、何が変わるのか

SKU設計は地味で、整理しても売上が直接上がるわけではありません。しかし、EC事業をスケールさせるための土台として、これほど重要なテーマもありません。

変わること1：在庫精度が一段上がる

マスタSKU基準で在庫を持つと、各モールの在庫数を集計した「実在庫」と「販売可能数」が初めて正確に出ます。売り越しの根本原因の半分は、SKU不整合です。コードが揃った瞬間に在庫精度は跳ね上がります。

変わること2：売上分析が「商品単位」で正しく出る

「楽天では月間30万、Amazonでは月間20万、Yahoo!では月間10万売れているこの商品は、合計60万の主力商品である」――この当たり前の集計が、SKUが分かれていると出ません。同じ商品が4つの行に分散しているため、ABC分析では「すべてB〜Cランク」になります。マスタSKU統合で、本当の主力商品が初めて見えます。

変わること3：自動化のコストが激減する

SKUがバラバラのまま自動化を組むと、「コード変換ロジック」が処理の至るところに散らばります。GAS・Pythonの自動処理スクリプトの半分以上が「モール間のSKU変換」に費やされる、というのは珍しくありません。SKUを統一すれば、自動化のコードはシンプルになり、保守性も上がります。

変わること4：人の引き継ぎが現実的になる

新人・後任が商品コードの体系を1日で理解できる――これがどれほど価値があるかは、引き継ぎで苦労した人ならわかるはずです。属人化を解消する第一歩は、コード体系の言語化です。

7まとめ ― SKUは「事業の背骨」

SKUは、商品マスタというEC事業の背骨を構成する最も重要な要素です。背骨が曲がっていれば、その上に乗る在庫管理・売上集計・自動化・引き継ぎ、すべてが歪みます。

• マスタSKUとモール別SKUを分ける
• 半角英数字とハイフンだけ、大文字統一・桁数固定
• カテゴリ-連番-バリエーションの3階層で意味を持たせる
• 廃番SKUは絶対に使い回さない
• すでに混乱しているなら、マスタSKU表を新設して段階移行

「商品が増えてきて、そろそろ整理したい」「在庫連動がどうしてもズレる」「自動化を組もうとしたらSKU不整合で詰まった」――そんな段階の事業者の方は、商品マスタを設計し直すタイミングに来ています。

マスタSKUの設計、既存SKUの棚卸し、モール別SKUとの対応表整備、在庫・売上集計の基準切り替え――これらは一気にやろうとせず、優先順位をつけて段階的に進めるのが現実的です。まずは新規登録から新ルールを適用するだけでも、半年後・1年後の景色は大きく変わります。

商品マスタの設計や、マルチモール運営の効率化でお困りの方は、ぜひ一度ご相談ください。11年のEC実務経験から、事業規模・モール構成・現状の混乱度に合わせた現実的な再設計プランをご提案します。