sku-naming-rule-generator
自社の商品コード／SKUコード／バリエーションコードの命名規則を、モール仕様・将来拡張性・既存資産との整合を踏まえて設計するスキル。「SKU命名規則」「商品コードのルール」「バリエーションコード」「SKUの桁数」「カラー軸・サイズ軸のコード」「シーズンコード」「マルチブランドの命名」「楽天とAmazonで統一」「在庫管理ツールのコード」「SKU入力ミス防止」「SKUの正規表現」など、商品コード・SKUコードの設計・改訂・統一の依頼で使う。あらゆるジャンル（化粧品・健食・食品・家電・アパレル・雑貨）に対応。楽天／Amazon／Yahoo!／Shopify／ネクストエンジン／Google Merchant Center横断対応。例示はすべて架空ブランド名（BRAND-NAME・BRD・BTN等）で行う。※バリエーションの軸選び・モール別バリエーション機能の使い分けは別スキル `variation-builder-jp`、楽天SKUプロジェクト特化のバリエーションチェックは `rakuten-sku-variation-checker`、商品マスタの一括クリーニングは `ec-product-master-cleaner-jp`。 【ALSEL独自スキル】株式会社ALSEL が、19年・5,000社超の EC 支援で得たノウハウをもとに開発したオリジナルスキルです。
SKILL.md 本文
SKU命名規則作成
概要
自社の商品コード／SKUコード／バリエーションコードを、モール仕様（楽天商品管理番号／Amazon出品者SKU／Yahoo!商品コード／Shopify Variant SKU／ネクストエンジン商品コード／Google Merchant Center id）と整合させた命名規則として設計するスキル。
ブランドプリフィックス・カテゴリ識別子・連番・バリエーション軸の組合せ方を、商品数・カテゴリ数・将来拡張性・複数ブランド運用・季節商品の有無に応じて最適化する。既存SKUがある場合は移行プランも提示する。
★最重要原則
SKUは「半角英大文字＋数字＋ハイフン」「桁数固定（ゼロパディング）」「30文字以内」「全モール統一値」が運用上の正解。 全角・スペース・特殊記号（# @ & + . /）は多くのモールで弾かれる。ハイフン以外の区切り記号はトラブルの元。一度公開したSKU（特に楽天商品管理番号）はURL・売上履歴に直結するため、既存変更は避け、新規商品から新体系を適用するのが安全。
知識ベース
| トピック | 参照先 |
|---|---|
| 7つの命名パターン（シンプル連番・カテゴリ＋連番・標準・年度シーズン・構造型番・マルチブランド・軽量） | references/patterns.md |
| モール別仕様（楽天・Amazon・Yahoo!・Shopify・ネクストエンジン・Google Merchant Center） | references/mall-sku-specs.md |
| バリエーション軸の表現方法 | references/variation-axes.md |
| ジャンル別実例 | references/examples.md |
主要な要点のみ本ファイルに記載。詳細は references/ を参照。
モール仕様（要点）
| モール | 該当列 | 文字種 | 文字数 |
|---|---|---|---|
| 楽天 | 商品管理番号 | 半角英数／_／-（大文字推奨） | 255バイト |
| 楽天SKU | SKU管理番号 | 半角英数／_／- | 別途 |
| Amazon | 出品者SKU | 半角英数／-／_／. | 40字推奨 |
| Yahoo! | 商品コード | 半角英数／-／_ | 128字（実用30字以内） |
| Shopify | Variant SKU | 緩い（実務上は英数＋-） | 255字 |
| ネクストエンジン | 商品コード | 半角英数／-／_ | 30字 |
| Google Merchant | id | 半角英数／-／_／. | 50字推奨 |
実務上は30文字以内・半角英大文字＋数字＋ハイフンに統一すると全モール安全。
7つの命名パターン（要点）
| # | パターン | 例 | 向く規模 |
|---|---|---|---|
| 1 | シンプル連番 | BRD-0001 | 〜500SKU |
| 2 | カテゴリ＋連番 | BRD-COS-0001 | 500〜2,000SKU |
| 3 | 標準（カテゴリ＋型番＋バリ） | BRD-COS-0001-30M | 2,000〜10,000SKU |
| 4 | 年度＋シーズン | BRD-24-SS-1001-BK-M | 季節商品多い |
| 5 | 構造的型番（家電） | BRD-AC-PRO-PLUS-WT | 家電・精密機器 |
| 6 | マルチブランド | BRD-COS-0001-30M／BTN-COS-0001-30M | 複数ブランド |
| 7 | 軽量（テスト用） | TEST001 | 短期キャンペーン |
詳細は references/patterns.md。例示の「BRD」「BTN」「BRAND-NAME」は架空ブランド名のプレースホルダ。実際の運用では自社ブランド略号に置き換える。
処理フロー
Step 1：入力情報の整理
必須：
- 自社ブランド数（単一／複数）
- 現在のSKU数（実際／3年後予測）
- 主要カテゴリ数
- バリエーション軸（カラー／サイズ／容量／セット数 等）の有無と数
- 既存SKU体系の有無（一括移行 or 新規だけ新体系）
任意：
- 販売チャネル（楽天／Amazon／Yahoo!／Shopify／自社EC）
- 在庫管理ツール（ネクストエンジン・ロジクラ等）
- 季節商品の比率
- OEM/PB混在の有無
Step 2：適切なパターンの選定
| 状況 | 推奨パターン |
|---|---|
| 単一カテゴリ・SKU500以下 | 1. シンプル連番 |
| 複数カテゴリ・SKU2,000以下 | 2. カテゴリ＋連番 |
| バリエーション軸あり・SKU2,000-10,000 | 3. 標準 |
| アパレル等季節商品が多い | 4. 年度＋シーズン |
| 家電・精密機器・モデルグレード重要 | 5. 構造的型番 |
| 複数ブランド運用 | 6. マルチブランド |
Step 3：構成要素の確定
[ブランドプリフィックス]-[カテゴリ識別子]-[連番]-[バリエーション]
BRD COS 0001 30M
ブランドプリフィックス（2〜4文字推奨）
- 自社ブランド略号（大文字）
- 例：「BRD」「BTN」「ECO」「PRM」
カテゴリ識別子（2〜4文字）
- COS（コスメ）／FOOD（食品）／AP（アパレル）／SUP（サプリ）／AC（家電・アクセサリ）
- 自社カテゴリ体系に合わせる
連番（桁数は将来想定の1桁多め）
| 想定SKU数 | 連番桁数 |
|---|---|
| 100以下 | 3桁（001-999） |
| 1,000以下 | 4桁（0001-9999） |
| 10,000以下 | 5桁 |
| 100,000以下 | 6桁 |
バリエーション
- カラー：BK／WT／NV／RD／PK／GY（2文字）
- サイズ：S／M／L／LL／XS（1〜2文字）
- 容量：30M／50M／100M（数値＋単位略）
Step 4：区切り記号の選定
- ハイフン「-」が推奨（互換性最も高い）
- アンダースコア「_」は混在禁止（どちらかに統一）
- ピリオド・スラッシュ・特殊記号は使わない
- スペースは絶対NG
Step 5：桁数固定（ゼロパディング）
- 001, 002, ..., 099, 100, ..., 999 のように先頭を0で埋める
- メリット：文字列ソートで数値順になる／視覚的に揃う
- デメリット：上限超過時の桁数追加が手間（999→1,000で1桁増）→ 連番桁数は将来1桁多めに
Step 6：バリデーション正規表現
入力ミスを防ぐ：
^[A-Z]{2,4}-[A-Z]{2,4}-[0-9]{4}(-[A-Z0-9]{1,4}(-[A-Z0-9]{1,2})?)?$
Step 7：移行プランの提示
既存SKUがある場合：
| 方式 | メリット | デメリット |
|---|---|---|
| 一括移行 | 体系統一・将来運用がシンプル | 楽天URL変更・SEO・売上履歴影響 |
| 段階移行（新規だけ新体系） | リスク小・既存資産を保護 | 旧新混在で運用やや複雑 |
| マッピング表方式 | 両体系並走可 | 管理コスト |
実務的には「新規商品から新体系・既存は変更しない」が現実的。
Step 8：モール間統一の徹底
自社マスター商品コードを「真実の唯一の情報源」として、各モールの該当列に同一値を投入：
| モール | 該当列 | 例（架空） |
|---|---|---|
| 楽天 | 商品管理番号 | BRD-COS-0001-30M |
| Amazon | 出品者SKU | BRD-COS-0001-30M |
| Yahoo! | 商品コード | BRD-COS-0001-30M |
| Shopify | Variant SKU | BRD-COS-0001-30M |
| ネクストエンジン | 商品コード | BRD-COS-0001-30M |
| Google Merchant | id | BRD-COS-0001-30M |
代表例：化粧品ブランド（架空ブランド「BRD」）
入力：
- ブランド：BRD（架空・1ブランド）
- 想定SKU数：現在300、3年後2,000
- カテゴリ：化粧水・乳液・美容液・クレンジング・ボディ（5カテゴリ）
- バリエーション：容量2-3軸（30ml/50ml/100ml）／一部に限定パッケージ
- 既存SKU：なし（新規ブランド）
推奨パターン：3. 標準（カテゴリ＋型番＋バリエーション）
構成：
BRD - [カテゴリ2文字] - [連番4桁] - [バリエーション]
カテゴリ識別子：
- LO ローション（化粧水）
- ML ミルク（乳液）
- SE セラム（美容液）
- CL クレンジング
- BD ボディ
SKU例：
| 商品 | SKU |
|---|---|
| 化粧水 30ml | BRD-LO-0001-30M |
| 化粧水 50ml | BRD-LO-0001-50M |
| 美容液 30ml | BRD-SE-0010-30M |
| クレンジング 150ml | BRD-CL-0050-150M |
| 限定パッケージ（クリスマス） | BRD-LO-0001-30M-XMS |
正規表現：
^BRD-[A-Z]{2}-[0-9]{4}(-[0-9]+[A-Z])?(-[A-Z0-9]{2,4})?$
全モール統一：
| モール | 値 |
|---|---|
| 楽天商品管理番号 | BRD-LO-0001-30M |
| 楽天SKU管理番号 | BRD-LO-0001-30M |
| Amazon出品者SKU | BRD-LO-0001-30M |
| Yahoo!商品コード | BRD-LO-0001-30M |
| Shopify Variant SKU | BRD-LO-0001-30M |
| ネクストエンジン商品コード | BRD-LO-0001-30M |
詳細パターン（食品・アパレル・家電・マルチブランド）は references/examples.md。
出力フォーマット
# SKU命名規則：[ブランド／事業者名]
## 1. 案件サマリー
- ブランド数：単一／複数
- 現在SKU数・3年後想定：
- 主要カテゴリ：
- バリエーション軸：
- 既存SKU体系：あり／なし
- 仮置きした前提：
## 2. 推奨パターン
- パターン番号と名称：
- 推奨理由：
## 3. 構成
```
[ブランド] - [カテゴリ] - [連番] - [バリエーション]
```
### ブランドプリフィックス
- 略号：（架空例：BRD）
### カテゴリ識別子表
| カテゴリ名 | 識別子 |
|---|---|
| | |
### 連番桁数
- ○桁（想定SKU数○以下）
### バリエーション軸
- カラー：BK/WT/NV/RD 等
- サイズ：S/M/L/LL
- 容量：30M/50M/100M
- その他：
## 4. SKU例（5〜10件）
| 商品 | SKU |
|---|---|
## 5. 正規表現（バリデーション）
```
^...$
```
## 6. 全モール統一テーブル
| モール | 該当列 | 値 |
|---|---|---|
| 楽天 | 商品管理番号 | |
| Amazon | 出品者SKU | |
| Yahoo! | 商品コード | |
| Shopify | Variant SKU | |
| ネクストエンジン | 商品コード | |
| Google Merchant | id | |
## 7. 既存SKU移行プラン（既存ありの場合）
- 採用方式：一括移行／段階移行／マッピング表
- リスクと対応：
## 8. 運用ルール
- 入力規則：半角英大文字＋数字＋ハイフン／桁数固定
- 自動採番ツール：
- バリデーション：正規表現
- 重複チェック：
## 9. NG例（避ける）
- 「ＡＬＳ-001」（全角混入）
- 「ALS COS 0001」（スペース混入）
- 「ALS#001」（特殊記号）
- 「ALS-1」「ALS-100」「ALS-1000」（桁数不揃い）
- 「ALS-cos-001」（大文字小文字混在）
## 10. 不足情報・追加確認
-
品質ゲート
- 推奨パターン1〜7の中から、自社規模・カテゴリ・バリエーションに合うものを選んだ
- ブランドプリフィックス・カテゴリ識別子・連番・バリエーションの構成を明示した
- 連番桁数は将来想定の1桁多めにした（ゼロパディング）
- 区切り記号はハイフン「-」に統一した（アンダースコア混在なし）
- 全角・スペース・特殊記号（# @ & + . /）を使っていない
- 30文字以内に収まる
- 全モール（楽天／Amazon／Yahoo!／Shopify／ネクストエンジン／Google Merchant）で統一値が使える
- バリデーション正規表現を提示した
- 既存SKUがある場合、移行プラン（一括／段階／マッピング表）を提示した
- 楽天商品管理番号は基本変更しない方針を明示した（URL・売上履歴影響）
- SKU例を5〜10件提示し、規則に従って正しく生成されている
- 例示に実在の商品ブランド名を使わず、架空ブランド名（BRD等）で示した
エッジケース
- 複数ブランド運用：パターン6（マルチブランド）でブランドプリフィックスを2〜4文字で確保。
- OEM＋自社ブランド混在：OEMは取引先別プリフィックス（OEM-A／OEM-B）、自社はブランドプリフィックス。
- 季節商品が多い：パターン4（年度＋シーズン）。年度2桁＋SS／AW／FW／SP の組合せ。
- 家電・モデルグレード重要：パターン5（構造的型番）。シリーズ・モデル・グレードを構造化。
- 既存SKU体系が破綻：パターン3〜6への一括移行は売上履歴・楽天URL影響大。新規だけ新体系適用＋マッピング表が現実解。
- テスト商品・短期キャンペーン：パターン7（軽量）。本格運用前に切替前提。
注意事項
- 楽天商品管理番号を変更すると、URL・売上履歴・楽天検索順位に影響する場合あり。既存商品の管理番号は基本変えない。
- Amazon出品者SKUを変更すると、在庫・レビュー履歴は引き継がれるが、設定変更とFBA再納品の手間が発生。ASINは変わらない。
- Yahoo!商品コード変更はURL変更・SEO影響。
- Shopify Variant SKU変更はURLは維持（Handle別管理）、影響は限定的。
- 全モールで統一値を使えば、CSV連携・在庫一元管理（ネクストエンジン）が大幅に楽。バラバラだとマッピング地獄。
- バリエーション軸はSKU命名側で表現するか、モールのバリエーション機能で表現するかの判断は別スキル
variation-builder-jp参照。 - 例示は必ず架空ブランド名（BRD・BTN・ECO等）で示し、実在の他社・自社ブランド名は使わない。
references/ 一覧
references/patterns.md：7つの命名パターンと比較表・桁数の決め方references/mall-sku-specs.md：モール別SKU仕様・SKU変更時のリスク・バリエーション機能の使い分けreferences/variation-axes.md：バリエーション軸の表現方法references/examples.md：ジャンル別実例
参考公式情報源
- 楽天市場 RMS「商品管理番号」「SKU管理番号」
- Amazon Seller Central「出品者SKU」
- Yahoo!ショッピング ストアエディタ「商品コード」
- Shopify Admin「Variant SKU」
- ネクストエンジン「商品コード」設定マニュアル
- Google Merchant Center「商品ID」要件
ライセンス: MIT
詳細情報
- 作者
- 株式会社ALSEL
- ライセンス
- MIT
- 最終更新
- 2026/5/13