【EC事業者】商品データの表記ゆれをAIで整理する方法

商品データの表記ゆれが起きる理由と影響

表記ゆれとは、同じ意味の情報が異なる書き方で登録されている状態です。ECでは複数の資料やシステムから商品情報を集めるため、単なる文字の違いと、実際の商品仕様の違いが混在しやすくなります。

複数の登録経路で書き方が変わる

たとえば、同じ容量を仕入先資料では500mL、社内の商品名では500ml、モール用データでは500 MLと記載している場合があります。スペース、全角・半角、英字の大小文字も担当者や入力元によって変わります。

その結果、商品名の検索条件が一致しなかったり、CSVの照合作業で修正候補が増えたりします。ただし、検索結果や作業負荷への影響はシステムの設定によって異なります。

似た名称でも別の商品であるケース

ネイビーとブラック、単品と3個セット、500mLと750mLなどは、表記だけでなく商品属性や販売単位が違う可能性があります。こうした違いまでAIに一括置換させると、販売ページと実際の商品が食い違うおそれがあります。

表記を統一してよい項目・いけない項目

AIを使う前に、どの項目を同じ表現へ揃えるか、何を変更禁止とするかを決めます。文字の見た目だけではなく、商品を特定する情報を優先して扱うことが重要です。

同一商品の判断は商品識別情報を起点にする

SKUは事業者が管理する商品の識別単位に使うコードです。JANコードなどを含むGTINは、取引単位を識別するための標準的なコードです。GTINの原則では、異なる取引単位に同じコードを付けないことが求められます。詳しくはGS1 JapanのGTIN設定の基本原則を確認できます。

ただし、商品コードが一致していても登録ミスの可能性はあります。色・型番・容量・包装単位・仕入先の最新仕様を照合し、疑義が残る場合は要確認として分離します。

商品データをAIで整理する6つの手順

AIで一度に全件を書き換えるのではなく、ルールを決めて候補を抽出し、人が承認してから反映する流れを作ります。はじめは特定の商品カテゴリーや少数の商品データで試すと、判断の難しい例を発見しやすくなります。

1. 対象データと元資料を揃える

   商品マスタ、登録用CSV、仕入先の最新仕様書を準備します。行を追跡できる元データIDを付け、修正前のファイルを保存します。

2. 標準表記と例外ルールを決める

   単位、スペース、英字などの書式を設定し、SKU・JANコード・容量・入数は自動変更禁止とします。ブランド固有の名称は例外として管理します。

3. AIに表記ゆれ候補を抽出させる

   承認されたAI環境へ必要最小限のデータを入力し、変更案と理由を行ごとに出力させます。元の値は残し、上書きしません。

4. 候補を4つに分類する

   表記統一候補、属性差異、要確認、変更なしに分けます。情報不足や商品特定ができないものは要確認へ回します。

5. 担当者が元資料と照合して承認する

   品番、カラー、サイズ、容量、セット数を確認し、理由を残します。不一致は仕入先や商品責任者に問い合わせます。

6. テスト反映後に本番へ適用する

   修正CSVを検証環境などで確認し、商品ページ、バリエーション、在庫連携への影響を点検します。反映日・承認者・差分を保存します。

AIの前に単純な文字処理で済む項目を切り分ける

前後の余分なスペースを除くなど、ルールが明確な処理は表計算ソフトや既存システムで対応できる場合があります。AIは、似た表現の分類、統一候補の説明、曖昧な項目の抽出といった部分に絞ると、検証しやすくなります。

そのまま使えるAIへの指示文と整理例

AIに依頼するときは、正しい表記を考えさせるだけでなく、判断の根拠と変更禁止条件を明示します。以下は商品データの表記ゆれを抽出するためのテンプレートです。

あなたはEC商品マスタの表記ゆれ確認を補助する担当です。
目的は、表記ゆれの候補を抽出することです。
商品統合や商品情報の確定は行わないでください。

【統一ルール】
・容量の書式は、同じ容量と確認できた場合のみ mL に統一する
・全角半角、空白、英字の大小文字は、許可された項目だけ変更候補にする
・ブランド固有の正式名称は維持する

【禁止事項】
・SKU、JANコード、型番を推測・変更しない
・色、サイズ、容量、入数、セット構成の違いを同一商品と断定しない
・元資料にない商品属性を補完しない
・不明な項目を無理に統一しない

【出力形式】
元データID／元の表記／統一候補／判定区分／根拠／確認事項
判定区分は「表記統一候補」「属性差異」「要確認」「変更なし」の4種類。
入力の各行を省略せず、元データIDを維持して出力する。
根拠がない場合は「要確認」と記載する。

【対象データ】
この後に、社内で入力を許可された商品情報を貼り付けます。

モデルケース：同じ表現に見えても判断を分ける

以下は説明用に仮定した商品データです。実在する商品情報や導入実績ではありません。

表記統一候補は承認済みを意味しません。提案後に人がチェックし、元データIDと対応させたまま更新用ファイルを作ることがポイントです。

AIの提案を確認するチェック項目と失敗例

AIがもっともらしい統一案を出しても、元の登録情報と一致しているとは限りません。商品を誤って別の販売単位へ置き換えないため、変更内容を承認する際の確認項目を固定します。

失敗例1：色名を一括置換して別の商品にしてしまう

紺とネイビーを同じ色と判断しても、メーカーによって色の定義は異なります。カラーコードや仕入先資料で一致が確認できない場合は、そのまま要確認にします。

失敗例2：セット商品と単品を同一商品として扱う

商品名の前半が一致していても、2個セットと単品は販売単位が異なります。入数の差を表記ゆれと見なさず、別のレコードとして保持します。

失敗例3：生成AIへ商品マスタを無条件に投入する

商品マスタには、非公開の仕入条件、原価、発売前情報などが含まれる場合があります。利用するAIサービスの入力データの扱い、契約、社内ルールを確認し、不要な機密項目を除いた範囲で試します。

ECの現場で継続運用するためのルール

一度表記を揃えても、新商品登録や仕入先のデータ更新で表記ゆれは再発します。最初から完全自動化を目指すよりも、登録前チェックの流れを担当者間で共有する方が実務に定着しやすくなります。

商品データの対応表を残す

整理の履歴は、元データID、対象列、元の値、変更候補、判定区分、根拠資料、承認者、更新日の形で残します。これにより、後から商品ページの誤記が見つかったときも修正の経緯を追いやすくなります。

小さく試してから対象を広げる

まずは商品数の少ないカテゴリーを選び、修正候補数、要確認件数、承認済み件数、差し戻し理由を記録します。削減時間や精度を初めから決めつけず、対象業務に合った確認方法になっているかを評価します。

運用の流れは、仕入先データ受領、形式チェック、AIによる候補抽出、人の承認、テスト反映、本番更新、履歴保管という順番が一例です。複数モールで運用している場合は、基準となる商品マスタを決め、チャネル別の必要な書式変更を切り分けます。

まとめ：まずは商品属性を守りながら表記ゆれ候補を整理する

ECの商品データを整える際は、見た目を揃えることより、商品の識別と仕様を正しく保つことが優先です。次の4つから始めてみてください。

はじめから全商品を処理するのではなく、表記ゆれが多く確認しやすいカテゴリーを選び、自社で使える判断基準を作ることが大切です。