EC事業者のための商品コード・SKU設計実務ガイド：発送代行・WMS連携を前提にした設計の落とし穴

商品コードが必要になるタイミングと理由

「商品名で管理できる」はいつまで通用するか

商品点数が10〜20SKU以下で、自分一人で管理しているうちは商品名での管理でも大きな問題は起きません。しかし、SKUが増えるにつれて問題が顕在化します。「ピンクのシャツ」という管理では、SサイズなのかMサイズなのか、ストレートカットなのかフレアなのかが区別できません。スタッフや発送代行業者と共有すると、認識の齟齬が誤出荷・在庫差異の原因になります。

発送代行への委託が「商品コード整備の必然」を生む

発送代行業者は倉庫内のすべての商品をバーコード管理しています。EC事業者から商品を受け入れる際、業者側のWMSに商品を登録するための「一意の識別コード」が必要です。インストアコードがなければ、発送代行業者が独自のコードを割り当てることになりますが、その場合でもEC事業者側との商品対応表が必要になります。結局、商品コードの整備は発送代行導入の前提条件になります。発送代行の導入前に整備すべき商品マスターデータの全体像を確認してください。

SKUとは何か：最小管理単位の正確な理解

SKUの定義と計算方法

SKU（Stock-Keeping Unit：在庫管理単位）とは、在庫管理における最小の識別単位です。同じ商品でも、カラー・サイズ・容量・仕様など属性が異なればそれぞれ別のSKUになります。例えばTシャツ1アイテムで「カラー3色×サイズ3種類＝9SKU」、「カラー3色×サイズ4種類＝12SKU」のように計算します。

商品コードはこのSKU単位で設定します。商品単位（アイテムレベル）でコードを付けても、同一商品の異なるサイズを区別できないため、発送代行のWMSとの連携時にピッキングミスが発生します。WMSとSKU管理の深い関係でWMSがSKUをどのように処理するか確認してください。

SKUとJANコードの違い

SKUは「自社内での在庫管理単位の概念」であり、JANコードは「業界・国際標準の商品識別コード」です。JANコードはGS1 Japanへの登録が必要な国際標準コードで、小売店や他社との取引・楽天・Amazonへの出品時に必要になります。一方、インストアコードは自社内での管理に使う任意のコードです。JANコードの詳細はJANコードの完全ガイドを参照してください。

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

①インストアコード（自社独自コード）

申請不要・コスト不要で即座に設定できる、最も導入ハードルが低いコードです。ネットショップの自社管理・発送代行との連携・社内スタッフとの情報共有に使用します。設計の自由度が高い反面、採番ルールを自分で設計する必要があります。本記事では主にこのインストアコードの設計実務を解説します。

②JANコード（EAN/UPCコード）

GS1 Japanへの登録が必要な国際標準の商品識別コード（13桁）。楽天・Amazon・実店舗での委託販売・海外展開時に必要です。登録には初期費用（売上規模により異なる）が発生します。詳細はJANコードの完全ガイドを参照してください。

③ASINコード

Amazon独自の商品識別番号（10桁）。Amazon.co.jpへの出品時に必要です。Amazonへの新商品登録時に自動で付与されます。Amazon以外のプラットフォームでは使用できないため、自社管理の主軸には使いにくいです。

④ISBNコード

書籍・出版物専用の国際標準識別番号（13桁）。書籍・コミック・音楽CD等を販売する場合に使用します。一般的なネットショップ商品の管理コードとしては使用しません。

インストアコードの設計実務：採番ルールと構造

採番の基本原則：「コードを見れば商品が特定できる」

インストアコードの設計で最も重要な原則は「コードを見るだけでSKUを一意に特定できること」です。コードから商品内容がわかると、倉庫スタッフ・発送代行業者・ECカートのデータ管理が全員同じ認識を持てます。「このコードは何の商品？」という確認コストがゼロになります。

推奨採番構造：ブランド＋商品番号＋属性

一般的なインストアコードの推奨構造は「ブランド/ショップコード（2〜4文字）－商品番号（3〜4桁）－カラーコード（3文字）－サイズコード（1〜2文字）」です。具体例：SC-001-BLU-M（STOCKCREWブランドのTシャツ001番・ブルー・Mサイズ）。商品カテゴリ・カラー・サイズの採番表を事前に作成し、命名ルールを統一してください。

属性コードのルール化

カラーコードは英語3文字（BLU=ブルー、RED=レッド、WHT=ホワイト、BLK=ブラック等）、サイズコードはS/M/L/XL/XXLまたは数値（60/90/120等）で統一します。複数の人が運用することを前提に、「ルールブック（採番表）」をスプレッドシートで管理して全関係者と共有することが重要です。

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

①「0」始まりのコードはExcelで文字化けする

「0001」「0012」のような先頭がゼロから始まるコードは、ExcelやGoogleスプレッドシートで開くと「1」「12」と先頭のゼロが削除されます。これがシステムへのインポート時のコード不一致の原因になります。「1以上の数字」または「アルファベット始まり」のコードを推奨します。

②日本語・記号を含むコードはシステムエラーの原因

「赤マグ！001」のような日本語・記号を含むコードは、一部のシステム・APIではエラーになります。発送代行業者のWMSやECカートのAPIは英数字のみ対応が基本です。商品コードはすべてアルファベット・数字・ハイフン（-）・アンダースコア（_）のみで構成してください。

③大文字と小文字の混在は入力ミスを招く

「SC001」と「sc001」を同じコードとして処理するシステムもあれば、別のコードとして扱うシステムもあります。大文字・小文字の混在は入力ミスにつながるため、全コードを「すべて大文字」または「すべて小文字」に統一してください。

④20桁以上の長いコードはシステム制限に引っかかる

多くの在庫管理システム・ECカートAPIには商品コードの文字数制限があります（通常12〜20文字程度）。「SC-20240101-001-BLU-M-LIMITED」のような極端に長いコードはシステムで切り捨てられる可能性があります。SKUを特定するために必要最低限の情報を10〜15文字以内で表現することを目指してください。

⑤同じコードを複数の商品に使い回す

過去に廃番にした商品コードを新商品に再利用すると、WMSや在庫管理システムに旧データが残っている場合に混乱が生じます。廃番になったコードは「使用済み」として採番表に記録し、新しい商品には新しいコードを割り当てる原則を徹底してください。

⑥属性の意味が採番表なしでは解読不能

「SC001-10-1」のような数字のみのコードは、採番表がないと「10」「1」が何を意味するか分かりません。コードを見ただけで商品が特定できない設計では、スタッフが増えるほどミスが増えます。英略語を使って意味が直感的にわかるコードにするか、必ず参照できる採番表を全員が共有できる環境に置いてください。

⑦商品コードを後から変更する

一度使い始めた商品コードを途中で変更すると、ECカートの商品登録・WMSの在庫データ・過去の注文履歴・発送代行業者のシステムなど複数の場所での更新が必要になり、漏れが生じやすくなります。最初の設計に時間をかけて、後から変更が不要な体系を構築することが長期的には低コストです。

発送代行・WMS連携を前提にした商品コード設計

発送代行業者が必要とする商品情報

発送代行業者のWMSに商品を登録する際、通常以下の情報が必要です。①商品コード（SKUコード）、②商品名（日本語・英語）、③JANコード（あれば）、④商品サイズ・重量（段ボール包装後の数値）、⑤商品画像（検品・ピッキング用）、⑥保管上の注意事項（割れ物・温度管理等）。この中で最重要なのが①の商品コードです。正確な商品コードがなければWMSへの登録そのものができません。

ECカート↔発送代行WMSのコード対応表

ECカート（BASE・Shopify等）の商品登録番号と、発送代行業者のWMSの商品コードが一致していないと、API連携時に注文データと在庫データのマッチングエラーが発生します。導入前に「ECカートのSKUコード ↔ 発送代行のWMSコード」の対応表を作成し、業者に共有することが重要です。STOCKCREWでは独自の物流IDを採番してシール貼付で管理するため、EC事業者はコード変換の手間を省けます。EC物流アウトソーシングの連携設計も参照してください。

バーコードラベルの印刷・貼付

発送代行業者への入庫時に商品にバーコードラベル（インストアコード）が貼付されていると、入庫検品・ピッキング時の精度が向上します。STOCKCREWでは入庫時のシール貼付作業にも対応しており、EC事業者が事前に準備できない場合でも対応できます。STOCKCREWのサービス内容で入庫オプションを確認してください。

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

BASE・楽天・Amazonで商品コードを統一する

複数のECプラットフォームで同一商品を販売している場合、プラットフォームをまたいで商品コードを統一することが在庫管理の精度を高めます。「BASEの商品番号はA001、楽天では12345、Amazonでは別のASIN」という状態では、マルチチャネルの在庫リアルタイム同期が難しくなります。インストアコードを「唯一の識別子」として全プラットフォームの商品登録に使うことで、WMSとの連携時のコード変換が不要になります。ネットショップの在庫管理完全ガイドでマルチチャネル管理の全体設計を確認してください。

JANコードとインストアコードの並行運用

楽天・Amazonなどのモールに出品する場合はJANコードが必要ですが、JANコードはインストアコードを「置き換える」ものではなく「追加する」ものです。商品マスターデータに「インストアコード」「JANコード」「楽天商品コード」「AmazonASIN」をすべて列として持ち、相互参照できる体制にすることが理想的です。JANコードの取得と活用の詳細も合わせて確認してください。JANコードの申請はGS1 Japan（流通システム開発センター）の公式サイトから行えます。

商品マスターデータの整備：スケールに備えた設計

商品マスターデータはGoogle スプレッドシートで管理する

商品マスターデータの管理ツールは、導入初期であればGoogle スプレッドシートで十分です。全関係者がリアルタイムで参照できる点・バージョン管理が容易な点・ECカートや発送代行のCSVインポートのひな型として使える点が利点です。スプレッドシートの列は「インストアコード」「JANコード」「商品名（日本語）」「商品名（英語）」「梱包後サイズ（3辺の和）」「梱包後重量」「注意事項」を最低限持つことを推奨します。

SKU数が増えたらWMSへの移行を検討

SKU数が100を超えてきたら、スプレッドシートでの管理には限界が生じます。ネットショップの在庫管理完全ガイドでWMSへの移行の判断基準を確認してください。発送代行のWMSを活用するか、クラウド型の在庫管理システムへの移行を検討するタイミングです。WMSの機能と導入の考え方で移行の判断基準を確認してください。

商品コード整備後の運用管理：継続的な品質維持

採番表のバージョン管理と共有ルール

採番表（商品コードのルールブック）は作成して終わりではなく、継続的に更新・管理する必要があります。新商品追加時・廃番時・カラー・サイズ追加時に採番表を更新し、発送代行業者・ECカート担当者・倉庫スタッフ全員に変更を周知することが重要です。Google スプレッドシートで一元管理し、変更履歴を記録することで誰が何をいつ変更したかが追跡できます。

定期棚卸しと商品コードの整合性チェック

月1回程度の定期棚卸しで、WMSのデータ上の在庫数と実在庫数の差異を確認してください。差異があった場合は商品コードの登録ミス・ピッキングミス・入庫未処理などが原因のことが多く、商品コード体系の問題に起因することもあります。差異が繰り返し発生するSKUは採番の見直しや商品画像の充実を検討してください。

発送代行業者への商品追加時の手順

新商品を発送代行業者の倉庫に追加する際は、①商品マスターデータに新SKUを追加する、②発送代行業者のWMSに商品登録を依頼する（商品コード・名称・サイズ・重量・画像を提供）、③入庫後に検品・在庫計上の完了を確認する、④ECカートの在庫数を更新する、という手順を標準化しておくことで、追加時のミスを防げます。入庫・入荷の実務フローで詳しく解説しています。

フルフィルメント拡大期の商品コード設計の見直しポイント

事業規模が拡大してSKU数が200〜500に達すると、当初のインストアコード体系では管理しにくくなることがあります。特に商品カテゴリが増えた場合、初期設計で2桁の商品番号（001〜099）しか想定していないと番号が不足します。スケールを想定して最初から3〜4桁の商品番号（001〜9999）を採用しておくことで、長期的な運用に耐えます。WMSの機能と在庫管理の高度化で大規模運用時の設計も確認してください。

まとめ：商品コード設計は物流インフラの土台

商品コード・SKU設計は「地味だけれど後から変えるのが最も難しい」物流インフラの基礎工事です。SKU数が少ない段階で正しく設計しておくことが、スタッフ採用・発送代行導入・マルチチャネル展開といった成長フェーズでの混乱を防ぎます。

設計の原則は「コードを見れば商品が特定できる」「日本語・記号を使わない」「大文字・小文字を統一する」「採番表を全関係者で共有する」の4点です。発送代行業者との連携を前提に、ECカートのコードとWMSのコードが一致する体制を構築しておくことが、ピッキングミスゼロと在庫精度向上の基盤になります。

発送代行の仕組みと費用の完全ガイドとネットショップの在庫管理完全ガイドも合わせて確認し、STOCKCREWの無料資料ダウンロードまたはお問い合わせからご相談ください。