EC商品マスタの名寄せ方法｜表記ゆれ・重複をAIで統合する手順

商品マスタの名寄せ（複数のデータから同じ商品を指すものを特定し、1つにまとめること）は、①正とするマスタを1つ決める、②JANコードや型番などの突合キーで各チャネルのコードを対応づける、③キーで一致しないものをAIで同一商品の候補として抽出し、確度に応じて人が確認する、という手順で進めます。表記ゆれが全角半角や空白といった機械的なものに限られるなら、表計算やツールで足ります。同じ商品を担当者が別の呼び方で登録している場合に、文脈から判断できるAI（LLM）が役に立ちます。

自社EC・モール出店（楽天・Amazon等）・卸/BtoB受発注システム・店舗POSと販売チャネルを増やすほど、商品データを管理するシステムも増えます。そこで起きるのが、同じ商品なのにシステムごとに商品コードや名称の表記が異なる状態です。たとえば「白Tシャツ Mサイズ」が自社ECでは商品コード「WT-M」、モールでは「ホワイトTシャツ（M）」、POSでは「白T/Mサイズ」と登録されていると、人が見れば同じ商品でも、システムは文字列が一致しない限り同じ商品として扱えません。

この「表記ゆれ」に加えて、チャネル追加のたびに商品を登録し直した結果、同一商品が複数のコードで登録される「重複」も積み重なります。単独のシステム内では気づきにくく、複数システムのデータを突き合わせたり、横断でレポートを出したりする段階で、業務の滞りとして表面化します。

なぜ商品マスタは「同じ商品なのに別物」になってしまうのか

原因は1つに限らず、複数の要因が積み重なって発生します。

• チャネル導入の時期が異なる：自社ECの立ち上げ後にモール出店を追加し、その後に卸向けの受発注システムを導入する、といった具合に、システムごとに異なる時期・異なる担当者が商品を登録する。命名ルールが統一されないまま蓄積する
• 各チャネルの入力形式に合わせ込む必要がある：モール側の必須項目・文字数制限・カテゴリ体系に合わせて商品名を調整すると、自社ECとは異なる名称になる
• 担当者ごとの入力ルールのばらつき：全角/半角、スペースの有無、型番の桁数、旧型番の継続使用など、担当者が違えば入力の癖も変わる。ルールを文書化していても、日々の運用の中で少しずつずれていく

こうした要因が重なると、システムをまたいで商品を照合するたびに、担当者が目視で「これとこれは同じ商品のはず」と判断し、手作業で対応表を作る状態が続きます。

表記ゆれ・重複を放置すると何が起きるか

放置した場合の影響は、次の4つの形で表れます。

• 在庫の二重管理：同じ商品が複数コードで登録されていると、在庫数がコードごとに分散し、実際の在庫と表示上の在庫数が合わなくなる
• EC内検索での取りこぼし：商品名の表記が統一されていないと、サイト内検索や商品リコメンドの精度が下がり、「探しているのに見つからない」機会損失につながる（検索精度の改善はECサイトの商品検索をAIで改善するを参照）
• 注文・在庫連携時の突合ミス：受発注システムとECサイトを連携する際、商品コードが一致しないと自動連携が組めず、手作業での照合が発生する
• 売上集計が商品単位で正しく出ない：同一商品が複数コードに分かれたまま集計すると、どの商品がどれだけ売れているかという基本の数字が正確に出ない

どれも、表記ゆれ・重複という小さな不整合が、在庫管理・接客・経営判断に波及する例です。

名寄せ作業で最も時間を失うのは、どのシステムを正とするかを決めないまま突合を始めることです。着手前に次の3点を決めます。

• 正とするマスタを1つ決める：基幹（販売管理）を正にする会社が多い。仕入・在庫・請求が基幹の品番で動いているためで、EC側を正にすると請求との突合が崩れる
• 突合キーを決める：JANコード、メーカー型番、自社品番のどれを軸にするか。JANがある商材はJANが最も確実だが、バラ・セットで同一JANになる商品があるため、入数と組み合わせて一意にする
• 統合後の命名ルールを1枚に書く：全角半角、スペース、型番の桁、色・サイズの書き方。ルールを決めずに統合すると、半年後には同じ状態に戻る

この3点が決まれば、名寄せは「正のマスタに対して、各チャネルのコードをぶら下げる対応表を作る」作業になります。ここが曖昧なまま自動化に進むと、出てきた候補をどちらに寄せるかを毎回人が悩むことになります。

突合の精度は3段階に分けて確認する

名寄せの候補には、確度の異なるものが混ざります。一括で確定させず、次の3段階に仕分けると、確認の手間を最小にできます。

• 完全一致（JAN・型番が一致）：自動で確定してよい層。ここが全体の何割を占めるかで作業量が決まる
• 高確度の候補（名称の表記ゆれのみで、入数・価格も一致）：一覧で確認し、まとめて承認する層。1件ずつ開かずに済む一覧の形で確認できるようにする
• 要判断（名称は似ているが規格・入数が違う、旧型番と後継品の関係）：人が1件ずつ見る層。新旧型番の切り替えが混ざるため、機械的に統合すると在庫が壊れる

注意したいのは3層目です。旧型番と後継品は同じ商品に見えますが、在庫としては別物です。統合するのか、関連品として紐づけるにとどめるのかを、商品担当と決めてから進めてください。

AIによる名寄せ・統合の進め方（4つのフェーズ）

名寄せ・統合は、全チャネルを一括で突合せず、段階を踏んで進めると手戻りが減ります。

①現状の把握では、対象となるシステム（自社EC・モール・卸/受発注・POS等）と、それぞれの商品データの件数・項目構成を洗い出し、名寄せの対象範囲を決めます。表記ゆれが特に起きやすいカテゴリをここで見極めると、後工程の精度が上がります。

②PoC（概念実証。小規模に試して効果を確認する工程）では、全商品を対象にせず、一部のカテゴリでAIによる名寄せを試します。LLMは、商品名の文字列が完全一致しなくても、「白Tシャツ Mサイズ」と「ホワイトTシャツ（M）」が同じ商品を指している可能性が高いことを、文脈から判断できます。実際のデータを使い、どの程度の精度で同一商品を特定できるか、誤って別商品を同一と判定するケース（誤名寄せ）がどの程度出るかを確認します。

③実装では、PoCで見えた精度・誤判定の傾向を踏まえ、対象範囲を全商品に広げます。名寄せ結果は、どの表記をマスタとして採用するかという統合ルールとともに、Excel・DB・各システムへ反映できる形で出力します。

④運用は、新商品の追加やチャネル拡張のたびに表記ゆれが再発することを見込んだ工程です。新規登録データを継続的にチェックし、必要に応じて名寄せルールを更新する保守体制を維持します。

よくある失敗パターン3つ

①ルールベースの表記統一で済ませようとする：「全角・半角を統一する」「特定の記号を除去する」といった単純なルール（辞書登録）では、「白Tシャツ」と「ホワイトティーシャツ」のような表記の違いまでは吸収しきれません。意味の近さで判断できるAIを組み合わせると、こうした揺れにも対応できます。

②名寄せの正解基準を決めずに始める：色違い・サイズ違いを同一商品とみなすのか、別商品とみなすのかを事前に決めずに進めると、名寄せ結果の解釈が部署ごとにばらつき、統合作業がやり直しになります。現状把握の段階で、この基準を業務側とすり合わせます。

③統合後の運用ルールを作らずに終わる：初回の名寄せで満足し、新商品登録のたびに表記ゆれが積み重なるケースがあります。整合性を保ち続けるには、更新のたびにチェックできる運用体制まで含めて設計します（紙・PDFカタログを起点に商品データを作る進め方は紙・PDFカタログを商品データ化するにはにあります）。

費用の目安

費用は対象システムの数・商品件数・表記ゆれの発生度合いで変わります。以下は市場の一般的な目安で、特定サービスの確定価格ではありません。

表のどれを選ぶかは、表記ゆれのパターンを「ルールで書けるか」で決めます。全角半角・大文字小文字・空白といった機械的なゆれが中心なら上の2行、担当者ごとの略称や社内用語での登録が中心ならLLMを使った構築が候補です。

まとめ：名寄せは整えたあとの運用まで設計する

商品マスタの表記ゆれ・重複は、複数チャネルを運営する会社ほど起きやすい構造的な問題です。一度整えても、チャネルや商品が増えるたびに再発します。正とするマスタ・突合キー・命名ルールを決め、確度別に確認し、新規登録時のチェックを運用に組み込むところまでを、1つの作業として扱います。

複数チャネルを併用していると、マスタを整えたあとも「在庫連携ツールを入れているのに在庫がずれる」ことがあります。その場合は、複数モールの在庫連携を自動化する方法｜在庫ズレの原因とマスタ統合の手順で、連携のどこでずれが生じているかを切り分けます。

自社ECの構築や移行では商品データを登録し直すため、名寄せに手を付ける機会になります。awaiはその構築・保守運用の中で、モールや卸システムとの商品データの突き合わせ、命名ルールづくり、新規登録時のチェックまでを受け持ちます。