商品マスタとは、商品を識別し、販売・仕入れ・在庫・出荷などの業務で共通に使う基準情報です。商品コード、商品名、規格、単位などを整理し、各システムで同じ商品を正しく扱えるようにします。ECサイトの商品一覧と似ていますが、顧客に見せる情報だけでなく、社内や倉庫で使う情報も含みます。
商品名をそろえただけでは、色違いや容量違い、セット商品を正しく管理できない場合があります。本記事では、商品マスタの役割、登録項目、コードの決め方、Excelやシステムでの管理方法を説明します。新規登録から変更、販売終了、CSV連携まで、ミスを防ぐために決めておきたいルールを整理します。
商品管理やEC運営業務を見直したい方は、FORCE-Rへご相談ください。
| 確認したいポイント | 結論 | 詳細 |
| 商品マスタの役割は？ | 商品を識別する業務の基準データ | 商品コード、名称、規格、単位などを整理し、各業務で同じ商品を扱います。 |
| 作成前に決める単位は？ | 商品・SKU・セット・ケースを区別 | 一件のデータが何を表すかを定め、入数と在庫の扱いを対応付けます。 |
| CSV更新時の注意点は？ | 空欄・省略列・操作区分を確認 | 更新前のデータを保存し、少数商品で試してから件数と反映結果を照合します。 |
Contents
商品マスタとは商品を識別し業務で使う基準データ
商品マスタは、扱う商品の識別情報と基本条件を登録した、業務の基準になるデータです。 商品コードを手掛かりに、名称、仕様、分類、単位などを参照します。会社やシステムによって含む範囲は異なるため、商品マスタという名称だけで、価格や在庫まで同じ方法で管理すると判断しないようにしましょう。
LOGILESSの商品マスタ用語説明でも、商品コード、JANコード、型番、カテゴリなどが例として挙げられています。複数の販売先を使うECでは、顧客向けの商品名が違っていても、倉庫が同じ商品を特定できる必要があります。表示名とは別に、業務で共通に参照するコードと、その対応関係を用意することが大切です。
注文などの取引データとは更新の意味が異なる
商品マスタは商品の基準情報、受注や入出荷の記録は取引によって増える情報として区別します。 例えば、商品マスタにはカップの品番と容量を登録し、受注データには誰がいつ何個注文したかを残します。注文のたびに同じ容量を入力し直す必要がないよう、基準情報を参照する形にします。
価格や分類の変更では、過去の注文をどう扱うかも確認してください。現在の価格を変えた際に、過去の注文金額まで変わって見える設計では、売上や問い合わせの照合が難しくなります。注文時の名称や価格を取引側に残すのか、適用時期の異なるマスタを参照するのかなど、採用するシステムの仕様を調べておく必要があります。
商品ページ・在庫一覧・PIMとの関係を整理する
商品ページは掲載情報、在庫一覧は数量の状態、PIMは商品情報を整備して配る仕組みとして考えます。 商品マスタがこれらの情報をつなぐ基準になる場合もありますが、すべてを一つの表へ入れる必要はありません。どの情報をどこで更新するかが分かる構成を選びます。
在庫の管理元を考える際は、Shopify在庫管理の解説も参考になります。商品が何であるかを定義する情報と、今いくつ販売できるかを決める情報は、変更の頻度と担当が異なります。PIMを使う場合も、基幹システムの商品コードを受け取り、説明や画像を加えるなど、役割を分けることができます。既存の業務とデータの流れに合わせて整理しましょう。
登録項目は識別・規格・取引・物流・掲載の用途から決める
登録する項目は、実際に使う業務から決め、意味と入力形式をそろえます。 全社共通の必須項目が決まっているわけではありません。品番や商品名だけで足りるのか、容量、入数、温度帯、仕入先などが必要かを、販売、仕入れ、受注、物流の担当者と確認してください。
商品コードと名称は別の役割で持つ
商品コードは識別に使い、名称は人が商品を理解するために使います。 名称へ広告向けの語句を加えても、コードまで変える必要があるとは限りません。社内の管理名、顧客向けの掲載名、納品書や送り状に使う名称が異なる場合は、用途を区別して項目を設けます。
GoQSystemの公式商品マニュアルでも、管理用の商品名と伝票用・物流用の名称やコードが分けて案内されています。これは同製品の例であり、自社のシステムでも同じ項目があるとは限りません。コードを変換する機能を使う場合は、元の品番と変換後の品番を記録し、注文から倉庫まで追えるかを確認します。
規格と単位は商品を取り違えない粒度にする
規格は、受注・在庫・出荷で区別する違いを明確にします。 容量、色、サイズ、味などが異なり、別の商品として届ける必要があるなら、その違いを識別できるようにします。商品名だけに容量を埋め込むより、容量と単位を別項目にしたほうが、検索や変換に使いやすい場合があります。
単位では、個、本、袋、ケースのどれで受注し、どれで在庫を数えるかを確認します。「数量1」が何を表すかが曖昧だと、出荷数を誤る原因になります。寸法なら本体と梱包後、重さなら正味と総重量を分けてください。同じ項目名でも使う側で意味が違う場合は、どちらかへ統一するか、別の項目として管理します。
価格・仕入れ・物流の条件には適用範囲を付ける
取引条件は、誰に、いつ、どの単位で適用する情報かを明確にします。 標準価格、仕入価格、法人向け単価、モール別価格は同じではありません。商品の共通情報へ一つの金額だけを置くと、販売先や期間による違いを表せなくなる可能性があります。
仕入れでは、仕入先の品番、発注単位、納期などを確認します。物流では、保管温度、梱包サイズ、配送条件など、現場が必要な項目を洗い出します。値の入力が不要な商品へ、推測で同じ条件を入れないようにしてください。税区分など判断が必要な項目は、経理や専門担当に確認し、商品マスタを作る担当者だけで決めない運用にします。
画像・説明・分類は共通と販売先固有を分ける
掲載情報には、全販売先で共通にする内容と、販売先ごとに変える内容があります。 商品の材質や容量は共通でも、掲載名、販促文、カテゴリ、画像の並べ方は異なる場合があります。共通情報を複製して各所で自由に直すと、訂正が反映されにくくなるため、変更元を決めておきます。
店舗とECの説明をつなぐ際は、O2OとOMOの違いの解説も参考になります。顧客が接点を変えても基本仕様が一致していることが重要です。一方で、店舗限定セットやオンライン限定企画の条件まで同じにする必要はありません。共通の商品情報を参照しながら、掲載先固有の情報を追加する形にすると、違いの理由を管理しやすくなります。
商品登録と受注業務の課題を整理したい方は、FORCE-Rへお問い合わせください。
商品・SKU・セット・ケースの単位を混同しない
設計では、一件のデータが何を表しているかを最初に定めます。 商品のシリーズ、在庫を数える単位、販売ページ、セットを同じ意味で商品と呼ぶと、情報の対応が崩れます。自社で使う呼び方を確認し、システムごとの用語との関係を記録してください。
一つの商品ページと在庫管理の単位は一致しないことがある
同じページで選べる商品でも、在庫を別に数えるなら区別が必要です。 例えば、カップを200mlと350ml、それぞれ白と青で販売する場合、実際に扱う四つの組み合わせを識別します。商品ページを容量ごとに分けるか、一つにするかは販売先の仕様と見せ方によって変わります。
共通のシリーズ名や材質は上位の商品情報へ置き、容量や色によって変わる情報は各管理単位へ持たせる方法が考えられます。ただし、色によって素材が違うなら素材まで共通にしてはいけません。どの値が全種類に共通かを確かめてから分けます。販売先のページ数を、そのまま倉庫の在庫種類数として数えないようにしましょう。
セット商品は構成品と数量を対応付ける
セットは、販売する組み合わせと、出荷・在庫で使う構成品の関係を管理します。 カップ二個のセットなら、どの品番を何個使うのかを記録します。組み立て済みのセットを独立在庫として持つ場合と、注文後に単品からそろえる場合では、必要な処理が異なります。
例えば、白と青を一個ずつ組み合わせたセットを一件受注した際、単品在庫をそれぞれ一個減らすのか、完成済みセットを一個減らすのかを決めます。返品で片方だけが戻る場合も、同じ処理では済まないことがあります。販売用のセットコードを作ることに加え、構成、在庫の減り方、出荷指示、返品の扱いまで確認してください。
単品とケースは入数とコードを分けて確認する
単品とケースを扱う場合は、入数と取引単位の関係を明確にします。 ケースを一つ出荷することと、単品を一つ出荷することは同じではありません。GS1 JapanのGTIN設定原則では、異なる取引単位へ同じGTINを設定できないと説明されています。自社品番の運用も、この関係を踏まえて整理します。
単品のカップを12個入れたケースなら、ケース二箱を24個分と換算する処理が必要になる場合があります。ケースから単品へ崩して出荷するか、ケースのまま保管・出荷するかも確認します。入数を変更する際には、コードや説明の変更基準を提供元のルールに照らして判断し、旧入数の在庫と混ざらない扱いを決めてください。
商品コードは重複を防ぎ変更に耐えられるルールで付ける
コードの設計では、重複しないことと、各システムで変わらず受け渡せることを優先します。 人が読み取りやすいよう意味を持たせる方法もありますが、分類や仕入先が変わるたびにコードを作り直す設計は負担になります。変更し得る属性は、コードとは別の項目へ持つことを検討しましょう。
自社コードとJANコードを区別する
自社で発行する管理コードと、流通で使うGTIN・JANコードは別のものです。 GS1 JapanのGTIN紹介では、GTINがGS1標準の商品識別コードの総称であると説明されています。自社コードに同じ桁数を使っただけで、JANコードとして使えるようになるわけではありません。
仕入商品のJANがすでにある場合は、メーカーの情報と現物を照合します。社内コードと一対一で対応するのか、販売単位やセットによって関係が変わるかも確認してください。流通コードがない商品へ、架空の番号を推測で登録しないようにします。販売先で必要なコードの条件と、コードを取得・設定する手続きは別に確認しましょう。
桁数・文字種・採番担当を定める
採番ルールは、接続するシステムが扱える条件の範囲で決めます。 最大文字数、利用できる記号、英字の大文字・小文字を区別するかを確認します。固定桁の連番を使う場合は、将来の件数も考慮しますが、すべての事業者に同じ桁数が適しているわけではありません。
コードの発行を複数担当が行う場合は、使った番号を一か所で管理します。仮登録と正式登録を分ける場合も、同じ商品へ別々のコードを発行しない確認が必要です。先頭のゼロが落ちたり、大文字を小文字へ変換したりしないよう、取り込み先まで照合してください。数字だけのコードでも、数量と同じ計算対象として扱わないことが大切です。
販売終了後も過去の対応関係を残す
終売した商品は、過去の注文や返品と照合できる状態を保ちます。 新しい商品のために古い社内コードを使い回すと、以前の購入品を別商品と取り違える可能性があります。自社コードの再利用は避けるルールを設け、終売や非掲載の状態で履歴を管理する方法を検討してください。
GTINについては、GS1 Japanの再利用停止の説明を確認します。2019年からの原則と、過去の終売商品に関する移行措置が案内されています。社内コードへの運用上の推奨と、GTINの正式なルールを混同しないようにしましょう。商品を新しいものへ置き換える場合も、旧商品と後継品の関係を残し、単純に上書きしない扱いが必要です。
複数の販売先にまたがるEC運営を見直したい方は、FORCE-Rへご相談ください。
商品マスタの作り方は現状把握・定義・登録・照合の順で進める
最初に既存の情報と業務を整理し、項目と管理単位を決めてから登録します。 システムの表へ手当たり次第に情報を移すと、意味の違う項目や重複が残ります。まず、現在どこに何の情報があり、誰が使っているかを調べ、整理する範囲を決めましょう。
既存データと使われ方を棚卸しする
現状把握では、ファイルや画面だけでなく、後工程での利用も確認します。 商品登録用の表、仕入先の資料、倉庫の一覧、モールの掲載情報などを集めます。どのデータを正しいものとしているかが担当によって異なる場合は、判断根拠を確認してください。
情報の一覧には、項目名、意味、取得元、更新担当、利用先を記載します。例えば、発送サイズが商品本体の寸法なのか、梱包後の箱のサイズなのかを確認します。二つの表に同じ項目名があっても、意味が違えば一つへ統合できません。件数や空欄の数を調べる前に、各データの単位と用途をそろえることが重要です。
項目の定義と入力例を用意する
項目ごとに、入力する値、形式、単位、必須となる条件を決めます。 一覧だけでは、担当者によって解釈が変わることがあります。正しい入力例と、間違えやすい例を添え、入力時に迷う箇所を減らします。分類や色名などは、必要に応じて選択肢を決めておきましょう。
空欄にも、未確認、対象外、値なし、非公開などの違いがあります。これらを区別しないと、未入力の商品を公開したり、不要な項目の入力を求め続けたりする可能性があります。最初から全項目を埋めることを目標にせず、取引や掲載に必要な条件を決めます。項目を追加する際の判断者も置き、似た意味の列が増え続けるのを防いでください。
重複候補は元情報に照らして確認する
似た名称を見つけても、同じ商品だと判断する前に規格とコードを照合します。 名称の表記揺れを直すことと、複数の商品を一つへ統合することは、影響が異なります。容量、色、入数、仕入先品番、JANなどを確認し、別商品を誤って統合しないようにします。
不明な情報は、元の値を残して確認対象にします。メーカー資料や現物に照らせる担当へ問い合わせ、修正した根拠を記録してください。画像だけで容量を推測したり、前の商品と似ているという理由で価格や条件を流用したりしないことが大切です。確認待ちの情報がある商品は、その状態を分かるようにし、必要な工程を進められる範囲と公開を止める条件を分けます。
登録後は注文と出荷まで一件を通して確かめる
登録の完了は、保存できたことだけで判断せず、業務で正しく使えることを確認します。 カップの例なら、白200mlの単品と、白・青のセット、12個入りケースで試します。画面に見える名前、受注データのコード、倉庫へ渡る数量を対応付け、一つの注文を最後まで追ってください。
単品を二個注文した結果と、二個セットを一組注文した結果が、在庫や帳票でどう違うかを確認します。セットを販売ページから外した後も、すでに受け付けた注文を出荷できるかは別の論点です。新規登録、変更、販売停止で確認対象を決めておくと、修正のたびに試す内容を考え直さずに済みます。
現場でバーコードを読み取る場合は、実際の商品ラベルと登録情報を照合します。同じ形の箱でも容量や色が違うなら、読み取った結果で区別できることが必要です。送り状や納品書の名称が短縮される場合も、受注担当や倉庫担当が特定できる表記かを確認しましょう。例外だけを口頭で伝えるのではなく、登録情報と作業手順へ反映します。
Excel・CSV・専用システムは作業量と管理条件で使い分ける
管理方法は、商品数だけでなく、同時編集する人数、更新頻度、連携先、確認履歴で選びます。 少ない商品でも販売先の形式が多ければ加工に手間がかかります。反対に、商品数が多くても変化が少なく、使う範囲が限られる場合があります。現在の負担がどこにあるかを確認しましょう。
Excelでは原本と配信用ファイルを分ける
表計算で始める場合は、編集する原本と、各システムへ渡すファイルを区別します。 配信用に列の並びを変えたファイルを、そのまま次回の原本へ戻すと、情報が欠ける可能性があります。原本の保存場所と編集担当、変更履歴、バックアップを決めてください。
商品コードは先頭のゼロや文字列を保持する形式で扱い、数量や価格と分けます。結合したセルや途中の見出し行を混ぜると、CSVへ変換した際の処理が難しくなる場合があります。入力規則や選択肢を使う場合も、取り込み先の条件を確認しましょう。複数の人が同時に変更するなら、競合をどう防ぎ、どちらを正式版にするかの手順も必要です。
CSV更新は空欄と省略列の扱いを確認する
CSVは、新規登録と更新の方法、空欄による上書き、列を省いた場合の動作を確認して使います。 GoQSystemの公式CSV説明では、CSVにない項目が空白で上書きされる注意事項が示されています。製品によって動作は異なり、更新したい列だけ送れば他は維持されると決めつけることはできません。
実施前に現在のデータを保存し、少数の商品で変更結果を確かめます。追加、更新、削除などの指示を持つ形式では、操作区分を間違えない確認が必要です。ファイルを受け付けた件数と、実際に反映された件数、エラー件数を照合してください。一括処理が途中で止まった際に、どの商品を再実行すべきかを判断できる記録も残します。
専用システムは商品構造と変更の流れで比較する
システムの選定では、自社の商品単位、セット構成、コード対応、変更履歴を扱えるかを試します。 販売管理、受注管理、PIMなど、候補の目的によって得意な範囲が異なります。必要な業務を一覧にし、標準機能、追加設定、個別開発で対応する部分を分けて見積もりましょう。
検証では、通常の商品のほか、複数規格、セット、廃番、価格変更のある商品を使います。倉庫やモールへ渡した情報を読み戻し、名称、数量、コードが正しいかを確認します。性能、料金、利用者の追加、連携先の追加、契約終了時のデータ出力も比較してください。導入後に誰がルールを維持するかまで決めておくと、使い続ける負担を判断しやすくなります。
商品情報を使った販売施策と運営業務を改善したい方は、FORCE-Rへお問い合わせください。
運用では変更履歴と業務への反映を確認する
商品マスタは、一度作った後も、商品の追加・変更・終売に合わせて維持します。 修正した値がEC、受注、倉庫へ反映されたかを確認し、処理が食い違っていないかを見ます。担当者が変わっても同じ判断ができるよう、変更の理由と確認結果を残すことが大切です。
登録・変更・公開の担当を決める
入力する担当者と、重要な変更を確認する担当者を決めます。 商品名の誤字、価格、入数、保管条件では、影響する業務が異なります。すべてを同じ手順で処理するのではなく、変更する項目に応じて必要な確認を設けます。公開日と反映先も記録しましょう。
SNS向けの商品情報を作る場合は、ソーシャルコマースの種類と注意点の解説も参考になります。短い投稿用の名称や説明を、物流に使う管理情報へ上書きしないようにしてください。販売のための表現を工夫することと、受注・出荷で商品を特定する情報を変えることを区別すれば、販促と業務の両方で使いやすくなります。
変更の適用日と連携の順序を管理する
価格や入数などを変更する際は、いつから使う値かと、どの順番で反映するかを決めます。 未来の価格を前もって登録できる構成でも、すべての連携先が同じ時刻に切り替わるとは限りません。日付の扱い、予約機能、反映の遅れを確認し、切り替え中の受注をどう処理するかを定めます。
更新が終わった後は、配信元の値と受け取り側の値を照合します。コードは一致していても、価格、入数、販売状態のどれかだけが古い可能性があります。不一致があった場合に、もう一度配信するのか、登録の条件を直すのかを判断できるよう、処理結果を残してください。連携先で一時的に直したときも、次の配信で戻らないよう元情報へ反映する手順が必要です。
担当者の交代時は、採番ルールと項目定義だけでなく、処理中の変更を引き継ぎます。確認待ちの商品、公開予定の価格、終売するセットなどが対象です。更新日だけでは作業の状態が分からない場合は、確認中、公開待ち、反映済みといった区分を設けます。誰が次の工程を進めるかが分かる記録を残すことが重要です。
不一致と手戻りを記録して設計を見直す
運用の評価では、登録件数だけでなく、修正の手戻りや連携エラーを確認します。 倉庫で商品を特定できなかった件数、掲載内容の誤り、価格の反映漏れなどを記録し、入力ルール、項目、確認工程のどこを直すべきかを判断します。担当者への注意だけで終えず、間違いにくい形を検討してください。
売上の分析に商品分類を使う場合も、分類を変えた前後で集計の条件が異ならないかを確認します。アクセス解析は、ユニークユーザーなどの指標の違いの解説も参考になります。継続購入を扱う際には、リピート率と向上施策の解説の考え方を踏まえ、商品コードの変更で同じ商品の履歴が分断されていないかも確認しましょう。
まとめ
商品マスタは、同じ商品を各業務で正しく扱うための基準データです。 登録項目を増やす前に、商品・SKU・セット・ケースの単位と、コードの役割を定めます。共通の仕様と販売先固有の掲載情報を分け、価格や在庫の管理元も明確にしてください。
作成時は現状の資料を調べ、項目の意味と入力例をそろえ、登録後の結果を照合します。ExcelやCSVでも原本と更新方法を決め、専用システムを使う場合も実際の商品で試すことが必要です。変更履歴と反映先を確認し続けることで、受注、在庫、出荷、販促で使える情報を維持できます。
ECの商品管理や運営改善にお悩みの方は、FORCE-Rへご相談ください。各システムの項目・連携仕様は提供元へ確認し、運営支援の範囲は個別にご相談いただけます。
