商品コード・SKU設計の実務ガイド【2026年版】|発送代行・WMS連携を前提にした採番設計

商品コード・SKU設計の実務ガイド【2026年版】

商品コード・SKU設計は、EC事業の物流効率を左右する重要な決定です。正しく設計されていないと、発送代行業者との連携がスムーズに進まず、在庫管理システムの混乱や誤発送につながります。本記事では、商品コード体系の基礎から、実務現場での採番ルール、WMS(倉庫管理システム)・発送代行連携を前提とした設計のポイント、そしてマルチチャネル販売における統一戦略まで、EC事業者が押さえるべき全てを実務的に解説します。

商品コード・SKUとは何か — EC物流における役割

商品コードとSKUの違い

EC事業において、商品コードとSKUは商品を一意に識別するための仕組みです。この2つは異なる概念ですが、実務ではしばしば混同されます。

商品コード(商品識別番号)は、商品そのものに付与される統一的な識別番号です。特にバーコード形式のJANコードが流通・小売業界の標準となっています。一方、SKU(Stock Keeping Unit)は、在庫管理単位を表します。同じ商品でもサイズ・色・入数が異なれば、異なるSKUとして管理されます。

商品コードとSKUの関係 商品コード(JAN等) 商品そのものを識別 SKU(在庫管理単位) サイズ・色・入数で分割 WMS・発送代行の管理単位 ロケーション・ピッキング・出荷 例:「黒Tシャツ」JANコード 1種 → SKU 3種(S/M/L) → 各SKUに倉庫ロケーション割当

発送代行・WMSでの活用場面

発送代行業者やWMSは、この商品コード・SKUを使って以下を実現しています:

  • 入荷時の商品検品・ロケーション割当
  • ピッキング・梱包時の誤出荷防止
  • 在庫数量の正確な追跡
  • 商品の組み替え・返品処理
  • マルチチャネル販売時の在庫同期

EC物流の全体像を理解する上で、商品コード設計は基盤となります。設計の段階で失敗すると、運用段階で多大な手戻りが発生するため、事業立ち上げ時点で最初に手をつけるべき課題です。発送代行の仕組みと費用の全体像も合わせて理解しておくと、コード設計の目的がより明確になります。

商品コードの種類と使い分け

主要な4つのコード体系

EC・流通業界には複数の商品コード体系があります。各々の特性を理解し、事業規模・販売チャネルに応じて適切に組み合わせることが重要です。

コード種類 桁数 発行元・管理者 用途・特徴 発行・運用コスト
JANコード(日本標準商品コード) 13桁(標準)、8桁(短縮) GS1 Japan 流通・小売業の標準。バーコード印刷対応。POS連携。流通チャネル販売時は必須 中程度(GS1会員費+コード割当料金)
社内SKU(独自採番コード) 8~20桁の可変長 企業が独自設計 社内WMS・ECシステムの在庫管理。自社EC専売モデル向け 低(システム設定のみ)
インストアコード(店舗別商品コード) 8~13桁 各小売企業が発行 Amazon、楽天など販売プラットフォーム独自のコード。プラットフォーム間では非互換 低~中(プラットフォーム側で付与、企業負担は小)
カスタムコード 可変長 発送代行業者やシステムが生成 発送代行業者内部での管理用。顧客企業には意味不明だが運用上必須 低(発送代行費用に含まれる)

コード体系は「共存する」もの

重要なポイントは、これらのコード体系は共存するということです。例えば、一つの商品が以下の複数のコードを持つことは珍しくありません:

  • JANコード(流通向け・小売向け)
  • 社内SKU(自社WMS向け)
  • Amazon商品コード(Amazon販売用)
  • 楽天商品管理番号(楽天販売用)
  • 発送代行業者内部コード

各コード間のマッピングを正確に管理することが、WMS導入時の成功鍵となります。

採番ルールと命名規則の設計方法

採番ルール設計の4つの基本原則

商品コード・SKUの採番ルール設計は、将来の事業拡張を見越した柔軟性と、日々の運用効率のバランスを考えることが重要です。

  1. 連続性よりも意味性 — 採番を日付やシーケンス番号で機械的に付与するのではなく、商品カテゴリ・仕入先・季節などの経営情報を埋め込む方が、後の検索・分析時に有用です
  2. 固定長化を検討 — 変動長では仕分けシステム、バーコードスキャナー、データベース設計で支障が出やすい。できる限り固定長(例:16桁)を推奨
  3. チェックデジット導入 — バーコード読み取り誤りを検出するため、最後の1~2桁をチェックデジットにする
  4. 拡張性の確保 — 今後の事業拡張時にルール変更を迫られない設計。カテゴリ枠、仕入先枠を過度に細分化しない

アパレルECの採番ルール例

例えば、アパレルECを営む企業の採番ルール例は以下のとおりです。

[カテゴリ(2桁)][仕入先(3桁)][商品タイプ(2桁)][色・サイズ(3桁)][チェックデジット(1桁)]
例:15-003-02-001-7
(メンズトップス / 仕入先003 / Tシャツ / 色001 / チェックデジット7)

採番時に絶対に避けるべきパターンは、在庫管理の現場での事例でも報告されています。制御されない採番(例:スタッフが手作業で連番付与)は、後の監査で重大な混乱を招きます。

商品コード設計でやってはいけない7つの落とし穴

実務現場では、以下の7つの落とし穴が繰り返し見られます。これらを避けることが、スムーズな物流運用の前提条件です。

落とし穴 悪い例 良い例 影響・対策
価格データとの紐付けミス SKU変更時に価格をバラバラに入力 商品コード・価格・原価を一つのマスターから配信 ヒューマンエラー増加 → マスターデータ一元管理
異メーカー品の混在 スペック同じでメーカー違いを同じSKU メーカー・原産地別にSKUを分割 返品原因追跡不可 → メーカー別SKU化
色・サイズの軽視 M黒とM白を同じSKU 各色・サイズで独立したSKU ピッキング誤出荷 → バリエーション別管理
採番ルール変更 運用中に突然ルール変更 事前に拡張枠を十分確保 全体システム混乱 → 事前設計が重要
発送代行業者との非合意 自社で勝手に16桁コード決定 業者仕様確認後に設計 非対応エラー → 事前の仕様合意
バーコード体系の混在 JANとインストアコード混在 体系を統一したバーコード スキャナー処理負担増 → 統一化
マルチチャネル後付け 自社EC後にAmazon用コード追加 初期段階から複数チャネル想定 運用複雑化 → 最初から設計

上記の表から明らかなように、商品コード設計の失敗は後の手戻りコストが極めて大きいため、設計段階での慎重な判断が不可欠です。

発送代行・WMS連携を前提にした設計のポイント

WMS連携で求められる5つの要件

発送代行業者やWMSシステムと連携する場合、商品コード設計は以下の実務要件を満たしていなければなりません。

GS1 Japanが提供するGS1標準では、商品識別のためのコード体系は「商品単位(GTIN)」「ロット単位」「階級単位」に分かれており、各々で異なるコード仕様が定められています。GTINは商品の標準化された識別番号として国際的に認識され、供給チェーン全体での情報共有を効率化します。

出典:GS1 Japan

1. スキャナー入力対応の仕様
発送代行業者のピッキング・検品時には、スキャナーで商品コードを読み込みます。このため、バーコード印刷対応のコード体系である必要があります。Amazonインストアコードのような数字のみの可変長コードはスキャナーと相性が悪い場合があります。

2. ロケーション管理との連携
入出庫処理の際、商品はロケーション(棚番号)に割り当てられます。商品コード体系が複雑すぎると、WMS上でロケーション検索が遅くなり、作業効率が低下します。ピッキング精度の管理方法でも、コード設計がピッキング効率に直結する事例を紹介しています。

3. 返品・不良品管理への対応
発送代行業者経由で顧客から返品が来た場合、どの商品がどのロットから返品されたのかを素早く特定する必要があります。SKUだけでなく、ロット番号やシリアル番号も運用ルールとして決めておくことが重要です。

4. 複数拠点の在庫同期
複数の発送代行拠点を利用する場合、各拠点で同じコード体系で商品を識別できなければ、在庫データが一元管理できません。コード体系は全拠点で共通化する必要があります

5. API連携時のデータ構造
WMS・ECシステムとのAPI連携を行う場合、商品コード、メーカー品番、JANコード、自社SKUなど複数のコードを同時に送受信することになります。このとき、各コード間のマッピングテーブルを正確に管理できるシステム設計が必須です。

経済産業省の「令和5年度電子商取引に関する市場調査」によると、日本のBtoC-EC市場規模は24.8兆円(2023年)に達し、EC化率の拡大に伴い物流基盤の効率化が急務となっています。商品コード体系の標準化は、物流品質の向上とコスト削減の基盤です。

出典:経済産業省

マルチチャネル販売での商品コード統一戦略

チャネル間コード統合の課題

自社EC、Amazon、楽天、Yahoo!ショッピング、実店舗など複数チャネルで販売する場合、各チャネル固有のコード体系と、企業全体の統一コード体系をいかに統合するかが課題になります。

マルチチャネル販売と発送代行サービスの連携について、以下のアプローチが実務的です:

アプローチ1:親SKUと子SKUの2層構造
社内で統一的な「親SKU」を定義し、各プラットフォーム固有の「子SKU」をマッピングします。例えば、「ブラック・Mサイズ」という商品が:

  • 親SKU:APPAREL-BLK-M-0001
  • 自社EC:BKTKM001
  • Amazon:ASIN-B001X2Y3Z4
  • 楽天:rakuten-item-5678

各チャネルの在庫数量を親SKUレベルで統合管理することで、どのチャネルで何個在庫があるか一目瞭然になります。

アプローチ2:マスター商品情報の一元管理
EC運用ガイドでは、商品マスターデータを単一の情報源(Single Source of Truth)として管理することが推奨されています。社内の商品管理システムを親とし、各プラットフォームへ商品情報を配信する構造です。

アプローチ3:プラットフォーム統合ツールの活用
複数プラットフォーム上の在庫をリアルタイムで同期できるツールを活用すれば、各チャネルの在庫数を自動で統一管理できます。ただしツール側の仕様制約を受けるため、事前に自社のコード体系がツールで対応可能か検証が必須です。

ネットショップ運営の規模が拡大すると、手作業によるコード管理は破綻します。事業スケール段階で、コード体系と紐付きを自動管理するシステム導入を視野に入れることが必要です。在庫管理の全体設計と合わせて検討してください。

まとめ

商品コード・SKU設計は、EC事業の物流効率を決定する最も基本的な意思決定です。事業初期段階から、以下の6つのポイントを押さえることが重要です:

  1. 複数のコード体系の共存を理解する — JANコード、社内SKU、プラットフォームコードは各々の役割を持つ。一つに統一しようとするのではなく、各々を正確にマッピングすることが肝心
  2. 採番ルールは拡張性を重視 — 将来の事業拡張時にルール変更を迫られないよう、余裕を持った桁数・カテゴリ設計を
  3. 発送代行業者・WMS仕様の事前確認 — コード体系の設計段階で、外部パートナーの制約を把握し、対応可能な設計にすること
  4. マルチチャネル展開を初期段階から想定 — 後付けのコード管理は効率が悪い。事業初期から複数チャネル対応を前提に設計する
  5. バーコード体系の統一 — スキャナー読み込み対応など、実装段階での運用効率を見越した設計を
  6. 定期的な見直し — 事業規模の拡大、取扱商品数の増加に応じて、コード体系も定期的に見直す

STOCKCREWでは、発送代行サービスをご利用されるEC事業者向けに、商品コード設計から在庫管理、マルチチャネル販売対応まで、一貫したサポートを提供しています。コード体系の設計段階でお困りの場合は、いつでもお気軽にお問い合わせください。

詳しい内容は、無料ガイド料金表連携機能でもご確認いただけます。

よくある質問

Q. 中小EC事業者でも複雑な商品コード体系を導入すべきですか?

いいえ。事業規模が小さい場合は、採番ルールもシンプルに保つべきです。重要なのは、将来的に複数チャネル展開や事業規模の拡大があるなら、そうした拡張を想定した「枠」を設計しておくことです。初期段階では4桁の社内SKUから始めても、後で8桁や16桁に拡張できるルール設計がされていれば十分です。

Q. JANコードとSKUは同じものですか?

異なります。JANコードは流通・小売業界の標準コードで、商品単位の識別に使われます。SKUは在庫管理単位で、同じ商品でもサイズ・色が異なれば異なるSKUになります。例えば、ある黒いTシャツの商品があれば、JANコードは1つですが、S・M・L各サイズで3つのSKUを持つことになります。

Q. 発送代行業者への商品コード情報は、どのタイミングで伝えるべきですか?

契約前の仕様打ち合わせ段階です。発送代行業者によっては対応可能なコード体系に制限がある場合もあります。契約後に「このコード形式には対応していない」という事態を避けるため、商品コード体系の詳細を事前に確認することが重要です。可能であれば、テスト商品で実際の運用をシミュレーションしてから本格導入するとよいでしょう。

Q. Amazonや楽天で商品を出品する場合、自社のSKUを使わなければならないのですか?

いいえ。AmazonはASIN、楽天は楽天商品管理番号という独自コードを採用しており、自社SKUとは別です。しかし、社内的には「自社SKU」と「Amazon ASIN」「楽天商品管理番号」の対応表を作成し、一元管理することが重要です。これにより、各チャネルの在庫数量を統合管理できます。

Q. 商品コード体系を変更することは可能ですか?

理論上は可能ですが、実務上は非常に手間がかかります。既存商品全てに新しいコードを割り当て、WMS・ECシステムのデータベースを更新し、発送代行業者のシステムも修正する必要があります。そのため、事業初期段階で「将来の拡張を想定した」設計をしておくことが、後々の負担を大きく減らします。

Q. ロット番号とSKUの関係性は何ですか?

SKUは商品の「品種」を識別し、ロット番号は同じSKUの「製造ロット」を識別します。例えば、「黒いTシャツ・Mサイズ」は1つのSKUですが、その中でも「2025年1月製造分」「2025年2月製造分」は異なるロット番号を持ちます。返品対応や品質問題の追跡時に、ロット単位での管理が必須になります。

目次
この記事のタグ
完全ガイド
発送代行完全ガイド EC物流完全ガイド STOCKCREW完全ガイド ネットショップ完全ガイド 物流倉庫完全ガイド