ECの商品登録データを整える｜ID・項目・単位・選択値の登録仕様表

商品一覧では「紺」、詳細ページでは「ネイビー」、取り込み用の資料では「NV」。同じ色のつもりでも、別々の担当者が登録すると、絞り込みや商品説明に違いが残ります。寸法も、ある商品はミリ、別の商品はセンチで記載されていれば、購入者が数字だけを比べてしまうことがあります。

ECの商品情報をまとめて登録する前に必要なのは、資料を一つのファイルへ集めることだけではありません。何を一つの商品として識別するか、各項目は何を意味するか、どの値をサイトへ渡すかを決めることです。元資料と登録先の間に「登録仕様表」を置くと、登録担当者と制作会社が同じ判断基準を参照できます。

この記事では、商品ID・項目定義・単位・選択値・確認者を整理し、商品ページや絞り込みに反映するまでの設計を扱います。使用する商品名やIDは架空の例です。特定のECサービスにそのまま取り込めるファイル形式を示すものではありません。

最初に、どの画面の違いをなくすか決める

商品資料の整理を始めると、仕入れ、在庫、発送まであらゆる項目をそろえたくなります。ただ、サイト改善の依頼としては、最初に購入者へ見せる画面と、その画面が参照する項目を決める方が作業範囲を説明しやすくなります。

たとえば色名なら、詳細ページの仕様欄、色の選択肢、一覧の絞り込みが対象です。寸法なら、商品説明文に埋め込んでいるのか、専用の幅・高さ欄から表示しているのかを確かめます。見た目が同じ「幅」でも、表示元が二つあると片方だけが更新される可能性があります。

画面の問題を一つ選び、その表示元を管理画面や現行の出力データでたどります。「紺とネイビーの検索結果が分かれる」「商品ごとにサイズ表の順番が違う」といった具体例を残せば、値の修正で済むのか、項目の追加や表示方法の変更が必要なのかを分けられます。

商品のまとまりと、販売する単位を分ける

商品を区別するIDは、商品名の代わりに照合するための目印です。商品名は変更することがあり、似た名前も存在します。名前だけで既存商品を探して更新する運用では、同名商品や色違いを取り違えないための確認が毎回必要になります。

架空のポーチで考えると、シリーズとしての商品を社内商品ID「P001」、ネイビーのSサイズという販売単位を社内SKU「P001-NV-S」で管理する設計が考えられます。一つの商品に複数の販売単位がある場合、どのSKUがどの商品に属するかも記録します。IDの命名規則は自社の既存ルールに合わせます。

ここで、社内商品IDとECサービスが発行するID、取り込み時の照合キーを同じものだと決めつけないことが大切です。登録先によって、既存商品を照合する項目や親子関係の指定方法は異なります。社内の識別子、登録先の識別子、今回の更新で照合に使う項目を対応表にしておきます。

新規登録と既存商品の更新も区別します。既存商品に新しい社内IDを付けたからといって、取り込み先が同じ商品だと認識するとは限りません。現行データから既存の商品と販売単位を特定し、新規追加する行と更新する行を分けるところまでが、登録前の準備です。

識別子に先頭のゼロがある場合は、数値として扱って桁を落とさないようにします。作業中の表で正しく見えていても、書き出したファイルで値が変わっていないかを確認します。IDの重複や親商品のないSKUが見つかった行は、担当者が対応を確定するまで登録対象と分けておきます。

登録仕様表で、値の意味と確認先をそろえる

下表は、架空のポーチを掲載するための設計例です。実際の登録用ファイルとは別に、担当者間で意味を共有する資料として使います。右端の確認者は役割の例であり、自社の担当者名と確認日へ置き換えます。

項目	定義と登録例	単位・選択値の扱い	確認者の例
社内商品ID	商品のまとまりを識別。P001	文字列として保持。登録先IDとの対応を残す	商品管理担当
社内SKU	色・サイズ別の販売単位。P001-NV-S	親となる商品IDと対応。重複を確認	受注管理担当
表示色名	購入者に見せる色の名称	承認した対応表でNVをネイビーへ変換	商品担当
商品本体の幅	本体の左右方向の長さ。例：12	掲載単位はcm。元値120mmを残す	商品仕様の確認者
サイズ選択値	この商品の販売サイズ。例：S	実在する販売単位だけを登録	商品・在庫担当
商品画像	対象SKUを確認できる画像	ファイル名と対象SKUの対応を記録	画像担当
更新対象	新規追加か既存更新か	更新時の照合項目と対象値を明記	登録担当

仕様表では「寸法」だけで終わらせず、何の寸法かを書きます。本体の幅、包装後の幅、取っ手を含む高さは別の項目です。単位をそろえても、測っている対象が違えば比較できません。商品担当者が元資料の意味を確認し、制作側が掲載欄と見出しへ反映します。

また、数値の精度や丸め方も必要に応じて決めます。120mmを12cmへ変換することと、細かな端数を丸めることは別の処理です。元の数値と単位を残し、どの段階で変換したかを追えるようにします。確認できない寸法を、見栄えのために近い商品の値で埋めることはしません。

元資料、登録仕様、登録先への対応、取り込みと画面確認をつなぐ設計 — 登録用データを作る前に、値の意味と変換規則を決める構成例。

選択値をそろえる前に、同じ意味かを確認する

色名の「NV」と「ネイビー」は、仕入れ先の資料で対応が確認できれば、サイトの表示名をそろえる候補になります。一方、「濃紺」と「ネイビー」が常に同じ色とは限りません。文字の似ている値を機械的にまとめず、元の値、採用する表示名、対象商品、確認者を対応表に残します。

一覧の絞り込みで使う色分類と、商品固有の正式な色名を分ける方法もあります。絞り込みでは「青系」、詳細ページでは商品固有の色名を表示する設計です。この場合は一つの欄を共用せず、検索用の分類と購入者が選ぶ名称が、それぞれどの項目から表示されるかを指定します。

サイズについても、Sという文字があるだけで全商品の寸法が同じになるわけではありません。選択値はそろえても、各商品のサイズ表は必要です。元資料の「小」をSへ変える場合は、正式な販売サイズとの対応を確かめます。存在しない組み合わせを、表の空きを埋めるために追加しないようにします。

商品画像は、ファイル名の似ているものを順に割り当てるだけでは判断できません。共通画像なのか、色別画像なのか、特定サイズだけの画像なのかを区別します。対象のSKUが変わったときに、どの画像を引き継げるかも記録しておけば、登録後に色と写真が食い違った際の確認先が分かります。

空欄を「分からない」の共通記号にしない

整理中の資料には、未確認、該当なし、既存値を消す、既存値を残すという異なる状態が混ざります。すべてを空欄にすると、登録担当者は意図を判断できません。作業用の資料では状態を別欄へ記録し、登録用の値へ変換する前に未確認の行を分けます。

取り込み先で空欄がどう処理されるかも確認が必要です。Shopifyの商品CSVの説明では、既存商品を上書きする設定のもとで、必須でない列の空欄と、列そのものを含めない場合の扱いが区別されています。さらに、関連する列の組み合わせによって結果が変わるため、一つの列だけを見て更新方法を決められません。

したがって「空欄なら変更しない」という社内のつもりを、そのまま登録ファイルへ持ち込まないようにします。消去・維持・設定の意図を作業資料に残し、使用するサービスと取り込み方法の仕様へ変換します。未確認の値は無条件に空欄で更新せず、対象から外すか確認を待つかを決めます。

価格や公開状態など、今回変更しない項目が同じファイルに含まれる場合もあります。商品説明だけを直す依頼なのに、古い価格が上書きされることのないよう、更新対象の項目と、維持を確認する項目を分けます。使っていない列を削除する際にも、関連項目として必要な列でないかを確かめます。

登録先への対応表を作り、少数の商品で確認する

仕様表で意味が決まったら、作業用の項目を登録先のどの欄へ渡すかを決めます。「表示色名→色の選択肢」「商品本体の幅→商品仕様の幅欄」のように、管理画面の項目名とサイト上の表示箇所までつなげます。商品説明文へまとめて書く項目と、絞り込みに使う項目は区別します。

WooCommerceの商品CSV取り込みの説明でも、仕入れ先のデータを整える際の識別子や属性の統一、少数の商品での試行が案内されています。実際の列名や更新方法は、現在使っている環境の出力データと公式資料で確認します。他サービス用のサンプルを見た目だけ合わせて使うことは避けます。

試す商品は、単純な一商品だけでなく、色とサイズのある商品、単位変換が必要な商品、既存値を消す予定の商品など、今回の変換規則を確かめられるものから選びます。公開への影響を管理できる検証環境や方法を用意し、取り込み前の記録と戻す方法を担当者間で確認します。

結果の確認では、読み込めた行数だけで判断しません。新規追加と更新が想定どおりか、親商品とSKUが対応しているか、管理画面に入った値が仕様表と合うかを照合します。そのうえで商品ページの見出しと単位、絞り込みの分類、画像の対象を見ます。登録に成功しても、表示側が別の項目を参照していれば画面の問題は残ります。

対象外として読み飛ばされた行や、エラーで止まった行も区別して記録します。「全件の処理が終了した」という表示だけでは、予定した全商品が更新されたとは判断できません。予定件数と追加・更新・除外・失敗の内訳を確認し、未反映の商品を残したまま完了扱いにしないことが大切です。

修正した場合は、元資料、変換後の登録用データ、取り込み結果を区別して保存します。どの版を使ってどの商品を更新したかが分かれば、二回目の登録時に古い変換結果を使うことを防ぎやすくなります。照合キーや属性構成を変更する場合は、連携先への影響も含めて改めて確認します。