35-2　商品コードが混乱する理由は“設計ミス”だった？色・サイズを迷わないSKUルールをプロが解説｜在庫管理の基本

商品コードが混乱する理由は“設計ミス”だった？色・サイズを迷わないSKUルールをプロが解説｜在庫管理の基本

在庫管理の現場で「同じ商品なのに属性がバラバラ」「色やサイズが揃わない」「検索に出てこない」──そんな“商品情報の乱れ”に悩む声を多く聞きます。
実はこの問題、担当者の入力ミスではなく “SKU設計の初期設定が間違っている” ことが原因です。

SKUは、商品を識別し、在庫と販売をつなぐ“土台”となる情報。
ここがブレると、どれだけ気をつけても在庫ズレ・欠品・誤出荷が再発します。

この記事では、迷いやすい 色・サイズ・型番の入れ方 をプロ視点で整理し、
“もう迷わないSKUルール” を実務に落とし込む方法をわかりやすく解説します。

H2-1　なぜ「色・サイズ」の入れ方で混乱が起きるのか

＝＝＝＝＝＝＝

在庫管理システムやExcel台帳を扱う中で、もっとも混乱を招きやすいのが「色」と「サイズ」の表記方法です。
同じ商品でも担当者や店舗ごとに書き方がバラバラになると、データの重複登録・検索ミス・誤出荷などのトラブルが起こります。

例えば「黒」を表すコードひとつとっても、「BL」「BK」「BLACK」など複数のパターンが存在します。
これが数百SKUを超える商品群になると、たとえ在庫数が正しくても「同じ商品が別物として扱われる」状態に陥ってしまうのです。

SKU設計の基本は、「誰が見ても同じルールで理解できるコード体系をつくる」こと。
色・サイズの入れ方は単なる表記の問題ではなく、在庫管理の精度を左右するデータの土台になります。

---

H3-1　現場でよくある「BL」「BK」「BLUE」などの表記ゆれ問題

現場で最も多いのが、「表記ゆれ」と呼ばれる入力の不統一です。
たとえば、同じ“青いシャツ”を登録するときでも以下のように分かれてしまうケースがあります。

• 「BLUE」
• 「BL」
• 「B」
• 「青」

担当者が変わるたびに違う略称が使われることで、システム上では別商品として認識されるというのが最大の問題です。
検索や抽出の際に「BLUE」で検索しても「BL」表記の商品はヒットせず、在庫の過不足や売上集計の誤差が発生します。

このような表記ゆれを防ぐには、「カラーマスター」「サイズマスター」などを設け、コード一覧を統一管理することが欠かせません。
SKU設計は、単なる略語の決め方ではなく、社内全体で共有できるルール化がポイントです。

---

H3-2　統一されていないと起こるトラブル（重複登録・検索ミス・誤出荷）

表記が統一されていないと、現場では以下のような具体的トラブルが起こります。

• 重複登録：同じ商品が別コードで登録され、在庫数が二重計上される
• 検索ミス：発注・出荷時に同一商品の在庫がヒットせず、在庫があるのに「欠品」と判断される
• 誤出荷：類似コードを選択してしまい、色違いやサイズ違いの商品を誤って発送する

これらは日常的な人的ミスに見えますが、根本原因は「SKU設計が統一されていない」ことにあります。
特にECや複数倉庫を運用している企業では、1つの誤登録が全体に影響し、在庫精度が一気に低下するリスクがあります。

---

H3-3　SKU設計の中で色・サイズが持つ“識別キー”の重要性

SKU（Stock Keeping Unit）は、商品を一意に識別するための“最小単位”です。
つまりSKU設計とは、「どの情報をどの順序でコード化するか」を決めるルール作りそのもの。
その中でも「色」と「サイズ」は、SKUを区別するための最重要要素＝識別キーです。

たとえば、同じ型番「TSHIRT-001」でも、

• TSHIRT-001-BK-M
• TSHIRT-001-BK-L
• TSHIRT-001-WH-M

のように、色（BK／WH）やサイズ（M／L）を組み合わせることで、SKU単位の在庫数や売上を正確に追跡できます。

もしこの識別キーが曖昧であれば、
「売れ筋の色・サイズ」が特定できず、発注判断や在庫補充がすべて“感覚頼み”になります。

つまり、色・サイズの表記ルールをSKU設計の段階でしっかり定義することが、
在庫精度の安定・販売分析の効率化・業務の標準化につながるのです。

---

H2-2｜色・サイズを「商品マスタ」で一元管理する考え方（SKU崩壊を防ぐ実践メソッド）**

---

---

H3-1｜SKUが崩れる根本原因は「商品マスタが機能していない」こと

SKUの混乱は命名ルールそのものではなく、
「入力する場所＝商品マスタ」側の仕組みが不完全であること
が大半の原因です。

・担当者によって表記が違う
・登録場所が複数ある
・ECと在庫システムで別マスタ
・Excelとシステムの共存

これらが起きると、
どれだけSKUルールを整えても、現場入力で崩壊します。

「SKUを直す」より先に
“SKUを作る起点となるマスタを整える”
という考え方が大切です。

---

H3-2｜色・サイズを「属性」として扱い、SKUと切り離す

SKU＝識別コード
属性＝商品の性質（色／サイズ／素材など）

多くの企業がここを混同し、

SKUの中にすべての属性を詰め込もうとする

→ その結果、SKUが複雑化し、更新不能になる。

理想は、

【SKU】は1つのID
【属性】は商品マスタの別カラム

として明確に切り分けること。

例：

SKU	色	サイズ	型番
001	BK	M	TSHIRT-001

という構造にすると、
EC・POS・システム連携すべてが一気にラクになります。

---

H3-3｜SKU自動生成の「禁止すべき3つのパターン」

現場でよくあるNG例は以下の通り：

❌ NG1：SKUの先頭にカテゴリ名を入れる

例：TSH-001
→ カテゴリ変更でSKUが破綻。

❌ NG2：サイズを後ろに増殖させる

例：TSH-001-M-L
→ 小変更のたびにSKUが肥大化。

❌ NG3：JANコードをSKU化してしまう

→ 完全な別概念を混同し、後から100%破綻します。

SKUは最小単位のIDであり、「意味を持たせすぎない」のが鉄則。

---

H2-3　色・サイズコード表を作って標準化する

SKU設計の精度を高めるうえで欠かせないのが、「色・サイズコード表」＝マスタ表の整備です。
色やサイズを人それぞれの感覚で入力してしまうと、
せっかく設計したルールもすぐに崩壊してしまいます。

SKUを組み立てる前に、全社共通で参照できる「カラーマスタ」と「サイズマスタ」を整備し、
誰が登録しても同じコードになる仕組みを先に作りましょう。

---

H3-1　カラーマスタを事前に定義（BL＝Blue／BK＝Black／WH＝White）

色コードはSKUの中でもっとも表記ゆれが起こりやすい要素です。
現場で「BL」「BLUE」「青」と入力がバラつくと、
同じ商品が複数SKUとして登録され、在庫が正確に集計できなくなります。

そのため、カラーマスタを事前に定義しておくことが重要です。
例として、以下のような表を社内共有フォルダやシステムマスタに登録します。

色名	コード	備考
Black	BK	黒
White	WH	白
Blue	BL	青
Red	RD	赤
Gray	GY	灰
Green	GR	緑

運用のポイントは以下の通りです：

• 略号は2文字統一（英大文字）：Excelやシステムでの見やすさ・安定性を確保。
• 曖昧な表現は禁止：「Navy」「DarkBlue」などは「BL」に統一。
• 新色追加はマスタ更新フローを設ける：勝手に新コードを作らせない。

カラーマスタは、SKU体系全体の“共通言語”となる基盤です。

---

H3-2　サイズマスタを定義（S／M／L／Fなど）

色と同様に、サイズ表記にもバラつきが生じやすいです。
たとえば「M」「Ｍ」「m」と全角・半角が混ざるだけで、別SKUとして認識されてしまいます。

そのため、サイズマスタも事前定義して、入力を統一する必要があります。

サイズ名称	コード	備考
Small	S	小サイズ
Medium	M	中サイズ
Large	L	大サイズ
Free	F	ワンサイズ（フリーサイズ）
XL	XL	特大サイズ

マスタ化する際のポイント：

• 半角英字統一（S/M/L/Fなど）。
• 桁数固定：すべて1～2桁に揃える。
• 商品カテゴリごとの拡張対応：靴であれば「24」「25」「26」、衣類であれば「S/M/L」など分けて管理。

SKU設計で重要なのは「データ構造の一貫性」です。
どんなカテゴリの商品でも、同じ入力ルールでSKUが作れる仕組みを整えましょう。

---

H3-3　部門間で共通化する「バリエーションマスタ表」の作り方

SKU設計を社内で浸透させるには、
開発・生産・販売・倉庫の各部門が共通のマスタを使うことが不可欠です。

たとえばアパレル企業であれば：

• 開発部：新商品の色・サイズを企画
• 生産部：発注や製造コードに変換
• 販売部：EC登録やタグ印刷で使用
• 倉庫：入出庫管理に利用

これらがバラバラのコード体系を使うと、SKUが正しく連携しません。

そのために整備するのが「バリエーションマスタ表」です。
カラーマスタ・サイズマスタを一元化し、下記のような構成で管理します。

カテゴリ	カラーコード	サイズコード	SKU例	備考
TSHIRT	BK	M	TSHIRT-001-BK-M	メンズシャツ
TSHIRT	WH	L	TSHIRT-001-WH-L	メンズシャツ
PANTS	GY	M	PANTS-010-GY-M	スラックス
PANTS	BL	L	PANTS-010-BL-L	スラックス

このように、SKUの構成要素を一元化して登録管理することで、
Excelやシステムが異なっても同じルールで運用できます。

---

H3-4　【テンプレート例】Excelでの標準SKU対応表

以下は、実務でそのまま使える標準SKU対応表のテンプレート例です。

カテゴリ	型番	カラーコード	サイズコード	SKUコード	商品名
TSHIRT	001	BK	M	TSHIRT-001-BK-M	シャツ 黒 M
TSHIRT	001	WH	L	TSHIRT-001-WH-L	シャツ 白 L
PANTS	010	GY	M	PANTS-010-GY-M	スラックス 灰 M
PANTS	010	BL	L	PANTS-010-BL-L	スラックス 青 L

Excel運用のコツ：

• 「SKUコード」は =A2&"-"&B2&"-"&C2&"-"&D2 のように自動生成式を入れておく。
• マスタ参照には VLOOKUP／XLOOKUP を活用して手入力を排除。
• 新色・新サイズを追加する際は、必ずマスタ表を更新してからSKU表を再生成。

このようにExcel上でも「SKUの統一ルール」を仕組み化することで、
将来クラウド在庫管理システムへ移行する際もスムーズにデータ連携が可能になります。

---

H2-4　商品コードの設計をシステムに反映させる

• H3-1　在庫管理システムやPOS連携時の「自動生成ルール」設定
• H3-2　EC連携時にSKUが崩れない命名フォーマット
• H3-3　バーコード・JANとの整合性を取るポイント

H2-4　商品コードの設計をシステムに反映させる

SKUや商品コードの設計は、Excel上だけで完結させるのではなく、
在庫管理システム・POS・ECなどの外部システムに正しく引き継ぐことが最終目的です。

SKUルールを事前に整理していても、
システム登録時に命名フォーマットが崩れたり、POS側で自動生成されたコードが別体系になったりすると、
在庫データの整合性が一気に崩れてしまいます。

ここでは、設計したコード体系を「システム運用に定着」させるための実装ポイントを紹介します。

---

H3-1　在庫管理システムやPOS連携時の「自動生成ルール」設定

多くの在庫管理システムやPOSには、商品登録時にコードを自動生成する機能があります。
この設定を最初にきちんと設計しておくことが、SKU崩壊を防ぐ最大のポイントです。

自動生成ルール設定の基本例：

要素	内容	設定例
プレフィックス	カテゴリ識別	TSH、PNT、ACC など
連番	商品ごとの番号	001、002、003…
色コード	カラーマスタ参照	BK、WH、BL など
サイズコード	サイズマスタ参照	S、M、L、F など

自動生成式例（在庫管理システムやPOSでよく使われる形）：

{カテゴリ}-{連番}-{色}-{サイズ}

出力結果例：
→ TSH-001-BK-M

このようにコード構造をシステム上でルール化しておけば、
担当者が異なっても入力ミスや略称の混乱を防げます。
また、在庫・売上・出荷データがSKU単位で正確に紐づくため、
在庫精度が劇的に改善します。

---

H3-2　EC連携時にSKUが崩れない命名フォーマット

ECサイト（Shopify・BASE・楽天・Amazonなど）と在庫システムを連携させる際は、
SKUが自動的に短縮・変換・上書きされるリスクに注意が必要です。

特に注意すべきポイントは以下の3つです：

1. 英数字＋ハイフン構成に統一する
   　→ 例：TSH-001-BK-M
   　日本語・全角文字・記号（／・＿など）を含むと、システムによっては文字化け・切断が起こる。
2. 桁数を20文字以内に抑える
   　→ 楽天やAmazonなど一部モールでは、SKU桁数に制限があります。
   　冗長なカテゴリ名や余計な記号を避け、シンプルに保つ。
3. 在庫システムとEC側のSKU一致を確認する
   　→ どちらかでSKUが再生成されると連携が途切れ、在庫同期が正しく行われません。
   　初期登録時に「システム発行SKUを優先する」設定を必ず確認しておきましょう。

また、商品登録CSVやAPI連携を使う場合、
ExcelでSKUを一括管理し、CSV出力時にそのままアップロードできる形式にしておくと、
SKU崩壊を防げます。

---

H3-3　バーコード・JANとの整合性を取るポイント

商品コード（SKU）とJANコードは似て非なるものですが、
運用上は同じ商品を指す“識別キー”として連動させる必要があります。

SKUとJANの関係を整理すると次のようになります。

項目	用途	桁数	管理単位
SKUコード	自社内での商品識別	任意（短い）	在庫・販売・分析
JANコード	外部流通・POS連携	固定（13桁）	小売・バーコードスキャン

整合性を取るには、以下の2ステップが有効です。

1. SKUとJANの対応表を作る
   　→ Excelまたはシステム内で「SKUコード ⇄ JANコード」を紐づける列を設ける。
   　例：

　| SKUコード | JANコード |
　|————|————|
　| TSH-001-BK-M | 4580123456789 |
　| TSH-001-WH-L | 4580123456790 |

2. POSシステムでSKU単位の販売データをJANと連携させる
   　→ POSはバーコード（JAN）で読み取りを行うが、分析や在庫更新はSKU単位で行う。
   　　SKUとJANを1対1で対応づけておくことで、どの色・サイズが売れたかを正確に追跡できる。

SKUとJANがズレると、「黒Mが売れたのに白Lの在庫が減る」といった
システムトラブルが頻発します。
SKU設計時にJAN連携を想定しておくことで、将来のEC・POS統合がスムーズになります。

---

H2-5　途中変更を避けるための注意点

• H3-1　途中でコードルールを変えると履歴が壊れる理由
• H3-2　既存データとの整合を保つ「変換テーブル方式」
• H3-3　過去データを安全にマージする移行手順

---

H2-5　途中変更を避けるための注意点

SKUや商品コードの設計で最も注意すべきことは、運用途中でルールを変更しないことです。
たとえ小さな修正でも、コード体系を途中で変えると履歴や分析データが壊れ、
在庫管理の信頼性が一気に低下します。

この章では、途中変更を防ぐための考え方と、
やむを得ず修正が必要な場合の安全な移行方法を紹介します。

---

H3-1　途中でコードルールを変えると履歴が壊れる理由

一度運用が始まったSKUコードを途中で変更すると、
以下のような影響が連鎖的に発生します。

影響範囲	発生する問題
在庫履歴	過去データと新コードが紐づかず、在庫推移が正しく表示されない
販売分析	売上データが旧SKUと新SKUで分断され、トレンド分析が不可能になる
EC・POS連携	旧コードが残っている商品が「在庫ゼロ」と判定される
システム	外部連携（バーコード・CSV・API）が途切れ、同期エラーが多発

特にPOSやECシステムがSKUをキーにして在庫を引き当てている場合、
SKUの変更は「別商品扱い」になり、実在庫と理論在庫が一致しなくなります。

SKUコードは、いわばデータベース上の「一次キー（ID）」です。
一度発行したSKUは、基本的に永久不変の識別子として扱うのが鉄則です。

---

H3-2　既存データとの整合を保つ「変換テーブル方式」

それでも、やむを得ずSKU体系を修正したいケースもあります。
（例：商品番号体系を刷新した、サイズ表記を英数字に統一した、など）

この場合は、直接データを上書きせず、変換テーブル（マッピング表）方式を使って整合性を保ちます。

変換テーブルの例：

旧SKUコード	新SKUコード	備考
TSH-001-BL-M	TSH01-BL-M	型番体系を変更
TSH-002-WH-L	TSH02-WH-L	連番を統一
PNT-010-BK-M	PANT-010-BK-M	カテゴリ表記変更

運用のポイント：

• システムやExcelで旧SKU⇔新SKUの対応を明示的に紐づける
• データ分析時には変換テーブルをJOINさせ、過去データを継続利用
• EC/POS連携では、旧SKUを「別商品」とせず、内部的に新SKUへリダイレクト

この方法を取ることで、SKUルールを更新しても過去履歴が切れず、
分析や販売履歴を一貫して追跡できます。

---

H3-3　過去データを安全にマージする移行手順

SKUルールを変更する際は、いきなり本番データを書き換えず、
段階的に移行テストを行う手順を守ることが重要です。

安全な移行の流れは次の通りです：

1. 現行SKUを全件エクスポートする
   　→ ExcelやCSVで現状データをバックアップ。
2. 旧SKU・新SKUを対応させた変換表を作成する
   　→ 「変換テーブル」形式で1対1マッピングを整理。
3. テスト環境で変換インポートを実施
   　→ 在庫数・販売履歴・出荷履歴が崩れないかを確認。
4. 在庫基準日を決め、本番データを移行
   　→ 例：「○月○日23:00時点で旧SKUの更新を停止」。
   　　それ以降、新SKUのみを使用する。
5. 旧SKUは“参照専用”として残す
   　→ 検索・照会には使えるが、新規登録や在庫更新はできないように制御。

このように、SKUを“上書き”ではなく“引き継ぐ”設計にすることで、
過去データを失わずにSKU体系を進化させることができます。

SKUは一度定義したら変更しないのが理想ですが、
万一変える必要がある場合でも、**「変換テーブル方式＋段階的移行」**で安全に乗り切ることができます。

H2-6　まとめ｜色・サイズルールを統一すれば在庫も安定する

SKU設計における「色・サイズの統一ルール化」は、
単なる命名方法ではなく、在庫精度そのものを安定させる仕組みです。

SKUがバラつけば、在庫データも分析レポートも正確性を失います。
逆に、コード体系が整っていれば、システム間連携・販売分析・棚卸まで
すべての業務が一本化され、現場の負担を大きく減らせます。

SKU設計は地味に見えて、実は“業務の土台”そのもの。
在庫を安定させたい企業ほど、最初にSKUルールの整備に時間をかけるべきです。

---

H3-1　SKUの一貫性が在庫精度を左右する

SKUは、在庫・販売・仕入のすべてをつなぐ“共通言語”です。
SKUの一貫性が保たれていれば、どんなシステムを使ってもデータの整合性が崩れません。
逆にSKUがブレると、在庫ズレや誤出荷などのトラブルが頻発します。

SKUを変えない・増やさない・統一する。
この3原則を守るだけで、在庫精度・売上分析・発注判断が劇的に改善します。

特に中小企業では、現場判断でSKUが増殖しがちなので、
マスタ更新ルールを決めて“誰でも同じSKUを使う”環境を整えることが重要です。

---

H3-2　次に読むべき関連記事

SKUに関して、ぜひ読んでください。