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

「同じ商品なのに、システムが別物として扱ってしまう」——複数チャネル運営の落とし穴

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

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

この記事では、複数チャネル・複数システムに分散した商品マスタの表記ゆれ・重複を、AI（LLM＝大規模言語モデル。文章の意味を人のように理解して処理できる生成AIの中核技術）でどう名寄せ（複数のデータの中から同一の対象を指すものを特定し、1つにまとめること）・統合できるのか、進め方と費用の目安を整理します。

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

原因は1つではなく、複数の要因が積み重なって発生します。

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

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

この状態を放置すると、次のような形で業務に影響が及びます。

• 在庫の二重管理：同じ商品が複数コードで登録されていると、在庫数がコードごとに分散して管理され、実際の在庫と表示上の在庫数が合わなくなるリスクが生まれます。
• 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つ

商品マスタの名寄せ・統合を検討する際、よくつまずくポイントを3つ挙げます。

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

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

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

費用の目安

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

判断の目安は、表記ゆれのパターンが「ルールで書けるか」です。全角半角・大文字小文字・空白といった機械的なゆれが中心なら、表計算やツールで足ります。同じ商品を人が別の呼び方で登録している状態が中心なら、文脈から判断できる仕組みが要ります。

まとめ——マスタが整えば、その先の施策が動き出す

商品マスタの表記ゆれ・重複は、複数チャネルを運営する会社ほど陥りやすい構造的な問題です。しかも一度整えて終わりではなく、チャネルが増えるたび・商品が追加されるたびに、同じ苦労が繰り返されがちです。

また、複数チャネルを併用していると、マスタを整えたあとも「在庫連携ツールを入れているのに、なぜか在庫がズレる」という悩みが残ることがあります。この場合の自動化の進め方は複数モールの在庫連携を自動化する方法｜在庫ズレの原因とマスタ統合で整理しています。