「モールごとに商品情報が微妙に違う」「SKUが担当者ごとにバラバラで、どれが最新かわからない」「Excelの商品台帳が壊れそうで怖い」——EC運営の現場で、商品情報まわりの悩みは尽きません。
これらはすべて、商品マスターという「単一の正（Single Source of Truth）」が存在しないことが原因です。本記事では、EC商品マスター（PIM：Product Information Management）の設計手順を、SKU採番・属性設計・モール別変換ルール・運用体制まで、実務レベルで解説します。商品マスターが整えば、標準化・自動化・AI活用のすべてが加速します。
1. EC商品マスターとは何か？PIMとの違い
EC商品マスターとは、「商品の基本情報・属性・画像・価格・在庫を、社内で一元管理するデータベース」のことです。モール側のRMSやセラーセントラルではなく、自社側が「正」として持っているデータであることがポイントです。
よくPIM（Product Information Management）という言葉と混同されますが、関係はシンプルです。
| 概念 | 意味 |
|---|---|
| 商品マスター | 自社側で一元管理する商品情報データそのもの |
| PIM | 商品マスターを管理するためのツール・仕組みの総称 |
| RMS / セラーセントラル | モール側の管理画面（出力先であって、正ではない） |
商品マスターが果たす3つの役割
単一の正（Single Source of Truth）
商品情報の「どれが正しいか」で迷わなくなります。楽天の商品名・Amazonの商品名・社内台帳の商品名が食い違ったときに、常に参照すべき原本が存在する状態を作ります。
モール横断の配信元
マスターの情報を各モール仕様に変換して配信します。「マスター1件を直せば、全モール同時に直る」という理想状態を目指します。
自動化・AI活用の土台
商品説明文の自動生成、在庫同期、広告出稿データ連携など、自動化とAI活用はすべて「構造化された商品マスター」の存在を前提にしています。
商品マスターが存在しない状態では、どれだけSOPや自動化を頑張っても「入力元がバラバラ」なので品質が安定しません。標準化・自動化・AI活用は、商品マスターの整備なしには成立しないのです。
2. 商品マスターがないEC運営で起きる5つの問題
商品マスターが未整備のEC事業者でほぼ必ず起きている、典型的な問題を整理します。自社にいくつ当てはまるか、チェックしてみてください。
| 症状 | 発生する損失 |
|---|---|
| モール間で商品名・スペックが微妙に違う | ブランドの一貫性が崩れ、CVRと信頼を落とす |
| SKUが担当者ごとにバラバラ | 在庫・売上の集計が合わず、意思決定が遅れる |
| 商品画像が複数バージョン存在 | どれが最新か不明、差し替え漏れで古い画像が残る |
| 価格変更が各モールに手作業で反映される | 更新漏れによる販売機会損失・利益毀損 |
| 新メンバーが商品情報を探せない | オンボーディングが長期化、質問コストが膨らむ |
これらはすべて、「どのデータを正とするかの合意がない」ことから派生しています。ツール導入の前に、まずは「何を原本にするか」を決めるところから始めましょう。EC運営が担当者依存になる原因の多くは、実は商品情報の管理方法に根があります。
3. 【実例】失敗しないSKU採番ルールの作り方
SKU（Stock Keeping Unit）は商品マスターの背骨です。ここが崩れると、他のすべての属性が信頼できなくなります。採番ルールは、以下の4原則で設計しましょう。
意味を持たせすぎない
「カテゴリ＋色＋サイズ」のように意味を詰め込みすぎると、商品仕様が変わった際にSKUまで作り直す羽目になります。意味は最小限（カテゴリ＋連番）に留め、詳細は属性項目側で持つのが鉄則です。
桁数を固定する
後からソート・集計する際に、可変長のSKUは必ず事故の元になります。例：「ABC-0001」のように前ゼロ埋めで桁数を固定しましょう。
モール別SKUと社内SKUを分ける
楽天の商品管理番号、Amazonの出品者SKU、Yahoo!のコード——それぞれ制約が異なります。社内SKUを「原本」とし、モールSKUはマッピングで紐付ける構造にします。
廃番SKUを再利用しない
過去データとの紐付けが壊れ、返品・問い合わせ対応で必ず混乱します。一度使ったSKUは、どれだけ古くても二度と使わないのが原則です。
# SKU採番ルール例
社内SKU：[ブランド3桁]-[カテゴリ2桁]-[連番4桁]
例：KBR-AP-0001（KBRブランド／アパレル／1番）
→ 楽天商品管理番号、Amazon SKUはマッピング表で紐付け
採番ルールはEC運用ルールの標準化の中核です。最初に決めたルールを途中で変えると必ず破綻するので、小さく始めて早めに合意形成しましょう。
4. 属性設計の考え方｜コア属性とモール依存属性
商品マスターの属性は、「コア属性」「モール依存属性」「運用属性」の3層で設計します。この切り分けができていないと、Excelが早晩カオス化します。
| 層 | 役割 | 例 |
|---|---|---|
| コア属性 | 商品そのものの本質情報。全モール共通で使う。 | 商品名、ブランド、素材、サイズ、色、原産国、JAN |
| モール依存属性 | 特定モールの仕様に合わせた項目。 | 楽天ジャンルID、Amazonブラウズノード、検索キーワード |
| 運用属性 | 社内運用のための情報。公開はされない。 | 仕入先、原価、最低販売価格、担当者、ステータス |
属性設計の3つのコツ
コア属性は「増やしすぎない」
全商品共通で埋める必要がある項目だけをコアに置きます。一部商品しか使わない属性をコアに入れると、空欄が増えてデータ品質が落ちます。
選択肢は必ずマスタ化する
色・サイズ・素材などの値は、自由入力ではなくリストから選ばせる設計にします。「ネイビー」「navy」「紺」のような表記ゆれを根本から防げます。
画像はファイル名に意味を持たせる
「SKU_連番.jpg」の形式で統一し、「main」「sub1」「sub2」のような固定タグを付けます。AI生成画像やバナー差し替えの自動化がしやすくなります。
5. 楽天・Amazon・Yahoo!・Qoo10への変換ルール設計
商品マスターが整っても、モールの仕様は統一されていません。マスター1件から各モールの仕様に機械的に変換できる「変換ルール」を定義することが、横断運営の最後の鍵になります。
| モール | 商品名の特徴 | 変換ルール例 |
|---|---|---|
| 楽天市場 | 127文字まで、キーワード羅列型が有効 | [ブランド]＋[商品名]＋[用途]＋[特徴1-3]＋[サイズ] |
| Amazon | ブランド→商品名→規格→色の厳格な順序 | [ブランド] [商品名] [色] [サイズ] [型番] |
| Yahoo!ショッピング | 75文字前後、検索キーワード重視 | [商品名]＋[用途]＋[特徴]＋[ブランド] |
| Qoo10 | メインタイトルとサブタイトルを分けて最適化 | メイン：コア訴求／サブ：検索キーワード |
変換ルールをテンプレ化しておくと、新商品の展開スピードが桁違いに変わります。「マスター入力 → 変換ロジックで各モール用CSV出力 → 一括アップ」の流れまで作れれば、1商品あたりの登録工数は半分以下になります。
変換ルール自体のロジック言語化は、生成AIの活用と非常に相性が良い領域です。ChatGPTに「マスター項目→楽天商品名生成」のプロンプトを組めば、モール別タイトルを一括で生成できます。
6. ツール選び｜ExcelかPIMか、移行の判断基準
「いきなりPIMを入れるべきか、まずはExcelで作るべきか」——これはよくある悩みです。結論は「商品数・モール数・担当者数で判断する」です。
| 状況 | 推奨ツール |
|---|---|
| SKU 500点未満 / 1モール / 1名運用 | Excel・Googleスプレッドシートで十分 |
| SKU 500〜2,000点 / 2モール / 2〜3名 | スプレッドシート＋AppSheet、Notionデータベース |
| SKU 2,000点超 / 3モール以上 / 4名以上 | PIM（Hunzaku、コマースロボ、Aladdin EC等）を本格導入 |
| 越境EC・多言語展開あり | 多言語対応PIM（akeneo、Salsify等） |
ツールを入れる前に、必ず「紙の設計図」を作ること。属性定義とSKU採番ルールが曖昧なままPIMを導入しても、ツール上でカオスが再現されるだけです。
業務の全体像と接続先が整理できていない場合は、先にEC業務整理のやり方でタスクマップを書くのがおすすめです。
7. 商品マスターを壊さない運用体制
商品マスターは「作ること」より「壊さないこと」が難しい資産です。以下の5つのルールで運用を守ります。
マスターのオーナーを1名決める
「商品マスターの最終責任者」を明確にします。複数人が自由に書き換えられる状態は、必ずデータ破損に繋がります。
変更は「申請→承認→反映」にする
コア属性の変更は、必ず申請フォーム経由で行い、オーナーが承認した上で反映します。小さな手間に見えて、データ品質を劇的に改善します。
変更履歴を必ず残す
「誰が」「いつ」「何を」「なぜ」変更したかをログに残します。クレーム調査や、価格ミスの原因特定で必ず効いてきます。
四半期ごとに属性定義を見直す
モールの仕様変更、商品ラインナップの変化、越境対応など、環境は変わり続けます。定期レビューを行わないと、マスターは徐々に現実と乖離します。
モール側を正にしない
楽天RMS・Amazonセラーセントラルの値を直接書き換える運用は厳禁です。必ず社内マスターを先に更新し、そこからモールへ配信する流れを守ります。
商品マスターの運用ルールは、EC担当者の引き継ぎの前提条件でもあります。マスターが整っていれば、担当者が変わっても品質は落ちません。整っていなければ、どんな引き継ぎ資料を作っても成果は下がります。
8. まとめ
EC商品マスターは、標準化・自動化・AI活用のすべてを支える「土台のデータ資産」です。SKU採番、属性設計、モール変換ルール、運用体制。この4つを丁寧に設計するだけで、商品数が倍になっても工数は倍にならない運用が現実になります。ツールの導入は、設計ができてから。順番を守ることが最大の近道です。
本記事のポイント
商品マスターの本質
自社側で持つ「単一の正（Single Source of Truth）」
SKU採番
意味を持たせすぎず、桁数固定、廃番は再利用しない
属性設計
コア／モール依存／運用の3層で切り分ける
モール変換
マスター→各モール仕様への変換ルールをテンプレ化
ツール選定
SKU数・モール数・人数で段階的に移行
運用体制
オーナー設置・申請承認・変更ログ・四半期レビュー
関連記事
Contact
まず、現状の課題を整理するところから。
1時間の無料相談で、御社のEC運営における構造課題を整理し、
最適な支援の形をご提案します。
初回1時間・オンライン対応・2営業日以内にご連絡