techbeans / Industry Pains
wholesale-02卸売業 ・ マスタ管理

商品マスタ・型番ゆらぎ・名寄せ

強度頻度引用22件

商品マスタ・型番ゆらぎ・名寄せ

一行要約

卸売業の現場では、JANコード・ITFコード・商品名・容量・サイズ・原材料・アレルゲン・ロット・賞味期限・原産国・税区分・掛率・取引先別単価など200項目以上の商品マスタを、基幹システム・取引先ポータル・倉庫管理・ECモール・Excelに分散させながら、取引先A社では「客先品番A-11732」、B社では「いつものコネクタ（短い方）」、C社では「コカ・コーラ500」と発注されるため、自社15,000SKUが取引先別呼称で実質50,000以上の管理単位に膨張し、ベテラン事務員1人の暗黙知が単一障害点として「退職時に受注処理3倍」の経営リスクとして突きつけられている。

ペインの核

卸売業の商品マスタは、JANコード（13桁/8桁）・ITFコード（集合包装用14桁）・社内品番・メーカー品番・商品名・容量・規格・サイズ・原材料・アレルゲン・特定原材料表示・原料原産地・賞味/消費期限・ロット管理単位・温度帯（常温/冷蔵/冷凍）・税区分（軽減税率/標準）・インボイス番号・関税分類（HSコード）・上代/下代/掛率・取引先別単価・送料負担区分・販促リベート・特売送り込み数量・廃番フラグ・改廃情報など、「だいたい200項目以上」（林拓人氏／一般社団法人リテールAI研究会代表理事・今村商事SVP）から構成される情報インフラだが、その実態は「会社ごとに決まったUIで手打ちしたり、エクセルやCSVファイルで交換」され「流通や小売業と各企業で数人から10人以上いるので、むっちゃコストがかかっている」（林拓人）状態にある。中小卸では更に「商品マスタが共有サーバーではなく、担当者個人のパソコンに保存されたExcelファイルで管理」「複数担当者が異なるファイルを所有し、勝手に更新する結果、どれが最新版か誰も分からない」（EC卒業）状態が常態化し、「ポテトチップス」「ポテチ」「じゃがいもチップス」が同一商品として集計できず、「あの商品の価格、今週だけ特別に安くするから、よろしく！」（EC卒業）という社長の口頭値引き指示が文書化されないまま赤字販売が後で発覚する事故が頻発する。卸売業に固有の最も深刻な構造ロックは「取引先ごとに呼び方が違う」という多軸の呼称ゆらぎで、部品商社の例では「15,000SKU（在庫管理単位）を扱うが、取引先ごとに呼び方が異なるため、実質的な管理単位は50,000を超える」（株式会社リチェルカ／梅田祥太朗CEO）。FAX/メール/EDIで届いた注文書には「客先品番A-11732」「いつものコネクタ（短い方）」「コカ・コーラ500」とだけ記載され、「自社マスタ上は近い候補が複数（メーカー品番違い／長さ違い／改版違い）あり、過去のやり取りや納入実績を突き合わせないと特定できず、営業・技術・倉庫への確認が増加」（リチェルカ）する。卸売業の特徴は、これに加えて「製・配・販」の三層構造――メーカーが採番した「メーカー品番」、卸が「自社品番」、小売が「ストアSKU」、ECモールが「商品ID」、物流倉庫が「ロケーションコード」――をすべてクロスリファレンスで持たねばならず、新商品が日々追加される食品卸では「200項目を1商品ずつ」（林拓人引用）の登録作業が追いつかない。さらに食品卸では賞味期限・ロット・温度帯・アレルゲンが、医薬品卸ではGS1個別認識コード・薬機法分類が、部品商社では客先品番・改版履歴・代替品適合情報が、雑貨卸ではJAN・サイズ・カラーバリエーションが、書籍取次ではISBN・配本情報が、酒販ではアルコール度数・税率区分が必要となり、業態ごとに「商品マスタの定義そのもの」が異なる。「FAXやメールで届く注文書の処理です。取引先から送られてくる受注データを、担当者が目で確認しながら手入力する」「FA関連機器という専門性の高い商材では、品番や仕様の入力ミスが後工程に与える影響も小さくありません」（マサシ／Wikiだるま開発者）という後工程波及リスクと、「ベテラン事務担当者の退職後、受注処理に3倍の時間がかかるようになった」（株式会社ripla／井上氏）という定量証言が示す通り、これは単なる事務負担ではなく、ベテラン1人が単一障害点となる経営リスクである。リチェルカ試算では「属人化継続による年間コスト約4,500万円（人件費2,000万円＋誤出荷800万円＋工数500万円＋機会損失1,200万円）」「取引先の約40%が例外ルール保有」（リチェルカ・梅田氏）。卸売業界全体で見ると、経済産業省は2024年11月に「商品情報連携標準に関する検討会」を設置し2026年の商品情報プラットフォーム稼働を目指すが、現状は「メーカー・卸・小売それぞれによる、各社都合での管理が常態化」（METI公開資料）し、共通商品マスタへの集約は道半ばのままである。

誰が困っているか

業態別の発信者層

業態 発信者の立場 規模感の典型例 商品マスタの特徴
食品卸（総合・専門・冷凍冷蔵） 受注事務・営業・経営者 取扱SKU 5,000〜数十万、取引先100〜2,000社 JAN/ITF混在、賞味期限・ロット・温度帯・アレルゲン、JICFS／規格書連動
医薬品卸（医療用・OTC） 物流・購買・MR担当 取扱SKU 1〜2万、取引先（病院/薬局）数千〜万 GS1コード（医療用個別認識）、薬機法分類、麻向法対象品
部品商社（電子部品・FA機器・機械要素） 受注事務・営業・社長 取扱SKU 5,000〜数万、客先品番が常態 メーカー品番＋客先品番＋自社品番のトリプル管理
自動車部品卸（純正・補修・カー用品） 一次卸・二次卸 一次卸全国30社、二次卸2,000社 車種適合表・互換品、改版・廃番管理、純正/汎用混在
雑貨・生活用品卸 EC担当・受注事務 取扱SKU 数千〜数万 サイズ/カラーバリエーション、JAN必須化（取引拒否リスク）
化粧品・健康食品卸 商品マスタ管理担当 取扱SKU 1〜5千 表示義務（薬機法・景表法）、ロット・有効期限
書籍取次 配本・受注担当 流通する書誌数百万 ISBNコード、版違い・刷違い・廃版
アパレル卸 受注・物流 取扱SKU 数千〜数万 サイズ×カラー×柄バリエーション、季節商品の入れ替え
家電・OA機器卸 受発注・営業 取扱SKU 数千 メーカー型番、後継機種、生産終了品
酒販卸 受注・営業 取扱SKU 数千 アルコール度数、税率（酒税）区分、JAN
マリン用品輸入卸 経営・受発注担当 取扱SKU 約200、海外仕入10社、国内卸先500社 海外型番→国内呼称変換、確認書PDF→PCA手入力
食肉卸（仲卸） 営業・経営 部位×等級×グラム単位 重量変動・歩留まり、産地・銘柄、トレーサビリティ

共通する立場

  • 商品マスタ管理に「数人から10人以上」を専任配置する余力がある中堅以上（林拓人氏指摘）と、1人兼務で個人PCのExcelに散らばる中小の二極化
  • 取引先ごとの「客先品番」「いつもの〇〇」「短い方」を記憶で紐付けるベテラン事務員――退職時に「受注処理3倍」（ripla井上氏）の業務停止リスク
  • 「あの商品、今週だけ特別に安くするから、よろしく！」と口頭値引きを出す中小卸の社長――マスタに反映されないまま赤字販売が発生（EC卒業）
  • 取引先A社の独自フォーマット、B社のEDI、C社のWebポータル、D社のFAX、E社のLINEを使い分ける受注事務――取引先ごとに異なる商品コード体系の「翻訳役」
  • メーカー機能を兼ねる中堅卸の商品開発／PB担当――JANコード新規取得（年16,500円〜）、JICFS登録、規格書作成、各取引先別フォーマットへの転記
  • ECモール（楽天・Amazon・Yahoo!ショッピング）への出品担当――同一商品をモールごとの仕様（親番号/子番号、画像サイズ、説明文の文字数制限）に合わせて再登録
  • 流通BMS／JCA手順／Web-EDIのシステム担当――取引先小売ごとに異なる商品マスタフォーマットへの変換責任を負う
  • 基幹システム刷新プロジェクトのPM・情シス――10万件×100項目の名寄せ・クレンジングが本体プロジェクトを上回る重さに直面

卸売業の業務フロー（時系列：新商品登録→受注突合→出荷→請求→廃番処理）

卸売業で繰り返される「商品マスタにまつわる1日／1か月／1商品ライフサイクル」：

  • 新商品登録依頼受付（メーカー営業／PB企画から）：メーカーカタログ・規格書・サンプルを受領。JANコード（メーカー側で取得済みの場合あり、PBの場合は自社で年16,500円で取得）、ITFコード（集合包装用）、商品名・略称、容量・サイズ、原材料・アレルゲン（食品の場合は28品目）、原産国、温度帯、税区分（軽減税率8%／標準10%）、賞味/消費期限の管理単位、メーカー希望小売価格・上代・下代・掛率、推奨陳列期間などを200項目超のマスタへ転記。「まず最初に決めるのは商品マスタ。ここを起点に在庫・販売・購買・会計が動く」（林拓人引用）
  • 画像取得・規格書整備：商品撮影（自社ECサイト・取引先ポータル用）、メーカー規格書（成分表示）受領。「BtoBプラットフォーム規格書」等を介してメーカーから取り寄せ、アレルギー・原産地・添加物情報を確認。「現在は商品マスタが共有サーバーではなく、担当者個人のパソコンに保存されたExcelファイルで管理されている」（EC卒業）状態のため、画像・規格書PDFが個人PCに散在
  • 既存マスタ重複確認：「同じ商品でも『ポテトチップス』と『ポテチ』、『じゃがいもチップス』」（EC卒業）の表記揺れを検索で見つける作業。検索でヒットしないため別IDで重複登録されるリスクが恒常化
  • 取引先別マスタ展開（最大の卸売特有作業）：自社品番が決まった後、取引先A社のポータル（独自コード体系）、B社のEDI（流通BMS／Web-EDI／JCA手順）、C社のFAX用紙、D社のExcelテンプレート、E社のLINEに、それぞれの「客先品番」「呼称」「カテゴリコード」「カラー記号」「サイズ表記」を登録。「複数のWeb-EDIシステムを使用しており、フォーマットの変換が大変」「取引先が異なるWeb-EDIを導入した場合、それぞれに合わせたファイルを生成・取込しなければなりません」（Masstery）状態
  • 受注突合（毎日数百〜数千件）：FAX/PDF/メール/Webポータル/EDI/LINEで届いた注文書を確認。「取引先から送られてくる受注データを、担当者が目で確認しながら手入力する」（マサシ／Wikiだるま）。注文書には「客先品番A-11732」「いつものコネクタ（短い方）」「コカ・コーラ500」と書かれ、「自社マスタ上は近い候補が複数（メーカー品番違い／長さ違い／改版違い）あり、過去のやり取りや納入実績を突き合わせないと特定できず、営業・技術・倉庫への確認が増加」（リチェルカ）。判断がつかなければ営業／技術／倉庫／取引先に電話確認、新規登録判断はベテラン1人に集約
  • 価格マスタ確認（卸特有）：商品マスタとは別に、取引先別単価マスタ・掛率テーブル・特売送り込み価格・販促リベート率・期間限定値引きを確認。「価格システムが取引先×商品×数量の3軸で変わる場合、シンプルなマスタ設計では対応できない」（受発注ライフ／aladdin-ec知見）。「あの商品の価格、今週だけ特別に安くするから、よろしく！」（EC卒業）が反映されておらず赤字販売が後で発覚するリスクが恒常的
  • 出荷指示・物流連携：自社品番→ITFコード（段ボール表記）→倉庫ロケーションコード変換。WMS（倉庫管理システム）と販売管理システムで品番体系が異なれば名寄せテーブルを介する。「営業部では商品をアルファベット+数字で管理しているが、物流部では別の連番を使っている」（株式会社ripla井上氏）状態が中小卸では常態化
  • 納品・請求：取引先A社向けには「下代（卸価格）」、フランチャイズ向けには「上代（小売参考価格）」を表示し、出荷元の表記もフランチャイズ名に書き換える「『価格あり』と『価格なし』の両パターンで納品書を出力、送付先ごとに異なる送料の請求書反映、問屋ごとに異なる下代への対応」（マサシ／Wikiだるま）。インボイス制度対応で適格請求書発行事業者番号も付記
  • 月末：仕入先別の価格条件、得意先別単価、リベート、特売送り込み数量を集計。「リベートの精算に毎月1週間かかっている」（株式会社ripla）「仕入先ごとの価格条件がExcelに散らばっていて、誰も全体像を把握できていない」（ripla）状態のため各部門のExcelを集めて手動マージ
  • 廃番処理（メーカー生産終了通知受領後）：商品マスタの「廃番フラグ」をオン、しかし在庫は残るため出荷可能の維持、後継品・代替品の紐付け登録、取引先各社へ廃番案内、過去の取引履歴は保持。「商品の販売を一時停止する場合は『非表示』『無効』フラグを使い、削除はしない」（業界一般のベストプラクティス）
  • 基幹システム刷新時：データ移行プロジェクトで「旧システムでは『株式会社ABC』『（株）ABC』『ABC』が別々のコードで登録」（ripla井上氏）された取引先マスタも、商品マスタも重複・表記揺らぎが噴出。「全角30文字→25文字」「ハイフンあり/なし混在」（大垣伸悟氏）が「10万件×100項目で掛け算」となり本番直前まで問題が見えてこない
  • ECモール出品・PIM運用（成長期の卸の追加業務）：楽天・Amazon・Yahoo!ショッピング・自社ECサイト・卸先ECサイトの仕様（楽天は親番号/子番号、Amazonはカテゴリツリー、Yahoo!は文字数制限）に同一商品を再登録。「商品選定をするバイヤーの70%は営業担当と連携をとる前に、まずネット検索」（monolyst）に対し、「ECサイトへの掲載が増え、商品管理が煩雑化」「約3,000時間（20人/月）もの時間が、紙から基幹システムへの転記作業に投下されている状況」（monolyst）

note引用（卸売業の生声・業界横断）

引用1：商品マスタは200項目超、流通・小売で各企業に「数人から10人以上」必要

「商品マスタは商品のあらゆる情報で、JANコードから始まり商品名や容量、サイズ、原材料やアレルゲンなど商品を表す情報の塊で、だいたい200項目以上」「現在は基幹システムのデータベースで管理され、会社ごとに決まったUIで手打ちしたり、エクセルやCSVファイルで交換しており、流通や小売業と各企業で数人から10人以上いるため、むっちゃコストがかかっているのが現状」「メーカー、流通、小売業、関連テック企業」「星の数ほど商品マスタに絡むプレイヤー」「生身の人間が作業しているのが現状」

  • 出典: 知る人ぞ知る商品マスタ by 林拓人（一般社団法人リテールAI研究会代表理事、今村商事株式会社シニア・バイス・プレジデント兼営業本部統括本部長）
  • 著者の立場: 大手食品流通出身（SE・営業・経営・DX歴任）、商品マスタ業界の第一人者
  • 投稿日: 2025-04-14
  • ペインの強度: ★★★★★

引用2：中小卸の杜撰な商品マスタ管理5パターン――個人PC保存・口頭値引き・ベテラン依存・表記ゆらぎ・空欄

「商品マスタが共有サーバーではなく、担当者個人のパソコンに保存されたExcelファイルで管理されている」「複数の担当者がそれぞれ異なるファイルを所有し、それぞれが勝手に更新している」「どれが最新版か誰も分からない」「『あの商品の価格、今週だけ特別に安くするから、よろしく！』といった口頭での指示が多く、文書化されていない」「価格変更がマスタに反映されず、赤字で販売してしまう」「長年の勘と経験で商品コードを覚えているベテラン社員がおり、その人がいないと誰も商品の特定や在庫確認ができない」「その人が退職したら、業務が完全にストップする」「同じ商品でも担当者によって名前の表記がバラバラ。『ポテトチップス』と『ポテチ』、『じゃがいもチップス』」「結果として、集計や検索がまともにできない」「新しい商品を登録する際、必要な項目が入力されていなかったり、空欄が多い」

引用3：部品商社のSKU 15,000が取引先別呼称で実質50,000超に膨張

「部品商社の例：15,000SKU（在庫管理単位）を扱うが、取引先ごとに呼び方が異なるため、実質的な管理単位は50,000を超える」「『この商品の価格、今週だけ特別に安くするから、よろしく！』といった口頭での指示が多く、文書化されていない」「価格変更がマスタに反映されず、赤字で販売してしまう」

引用4：受発注属人化「3つの悲鳴」――ダブルチェックしても減らないミス、変わらない取引先、ベテラン依存

「『ダブルチェックしているのに、ミスが減らない』」――根本原因は「情報が何度も変形される構造」がミスを生む。FAX/PDF/メールの転記、顧客表記の曖昧性、例外が散在。「『取引先が変わらない。だから、こちらが苦しい』」――取引先の多様性（体制、ITリテラシー、費用）で一律変更が難しい、重要顧客のFAX指定など商習慣上の制約。「『結局、○○さんがいないと回らない』」――属人化の原因は商品マスタ／顧客マスタの統一不足、客先品番、通称、改版／仕様差で品番候補が割れる

引用5：「いつものコネクタ（短い方）」が日常、ベテラン名が"固有名詞"化、属人化年間コスト4,500万円

「『山田さんがいないと、この取引先の発注ができない』『鈴木さんしか、あの品番体系を理解していない』——受発注の現場で、ベテラン社員の名前が"固有名詞"として語られる瞬間、その業務は既に属人化しています」「お客様が『この部品が欲しい』『この部品ってこれに適合しますか？』と言っても、それが具体的にどの品番なのか、○○さんに聞かないとわからない」「品番の表記ルール（ハイフンの有無、大文字・小文字、全角・半角）、支払条件（月末締め・翌月払い）など、取引先ごとに異なるルールが存在します。取引先が100社を超える企業では、平均して約40%に何らかの例外ルールが存在する」「年間コスト試算（属人化継続）約4,500万円（人件費2,000万円＋誤出荷800万円＋工数500万円＋機会損失1,200万円）」

引用6：販売管理の属人化――ベテラン退職で受注処理3倍、商品コードが部門ごとに異なる

「『この見積もり、田中さんじゃないと出せないんだよね』『Excelの関数、触れるの鈴木さんだけだから』といった状況が日常化」「ベテラン事務担当者の退職後、受注処理に3倍の時間がかかるようになった」「営業部では商品をアルファベット+数字で管理しているが、物流部では別の連番を使っている」「『株式会社○○』と『(株)○○』、『○○商事 東京支店』と『○○商事（東京）』といった同一取引先の複数表記が売上集計を阻害」「請求漏れや二重請求が発生し、月次決算の修正が常態化する企業も存在」「『なぜこの価格で販売したのか』『誰が承認したのか』といった質問に『答えられない状態』が内部統制上の課題」

引用7：販売管理データ移行で取引先名「株式会社ABC／（株）ABC／ABC」が別コード、月次決算2週間遅延

「旧システムでは『株式会社ABC』『（株）ABC』『ABC』が別々のコードで登録されています。部門ごとに独自の商品コードを振っています」「こうした表記揺れが解消されないまま移行すると、新システムで受注を入力しても取引先が見つからない、商品を選べないという事態に陥りかねません」「『得意先Aは月末に急ぎの追加注文が入るので、締め日を過ぎても翌月請求に回す』という運用があった事例。システム設計では『締め日以降の受注は翌月計上』としていたため、本番稼働後『請求額の不一致が多発し、現場は結局Excelでの手作業に逆戻り』」「入金伝票を移行対象から外した結果、新システムの売掛金残高が実態と合わず、月次決算に2週間の遅延が生じた」「数千件の取引先データから重複候補を洗い出し、営業部門に1件ずつ確認してもらう作業の負担」

引用8：要件定義段階で「例外処理が全業務量の3〜4割」、汎用要件で統一すると失敗

「基本フローに乗らない業務が実は全業務量の3〜4割を占めているケースが珍しくない」「受注データを営業が手入力してから、在庫システムへ倉庫担当が再入力する」構造が在庫食い違いや出荷遅延を生成。「大手小売チェーンと地場の中小卸問屋では、価格体系も納品条件もまったく違う」にもかかわらず、汎用要件で統一されることが失敗パターン。「掛率管理、締め処理パターン、在庫引当ロジック、返品ワークフローなど、業務特有の複雑性が後工程での手戻りを招く」「システムを入れたのに、得意先別の単価計算は結局Excelで確認している」「FAX受注の処理は手作業のまま変わっていない」「パッケージやSaaSで要件が8割しか満たせず、導入後に後悔したという声を現場でよく聞く」

引用9：マリン用品輸入卸――10名・取扱200点・国内卸先500社で確認書PDFを手入力、属人化

「マリン用品輸入卸業：海外取引先10社、国内卸売先約500社、取扱商品数約200点、従業員10名」「『確認書（PDF）の内容をPCAへ手入力する』ことが現在のボトルネック」「その作業は担当者しかできない属人的な状態」「入荷時期が変わることが珍しくないため、確認書をシステムに取り込んだあと、入荷予定日が変わったら該当のデータを手動で修正できるようにしたい」

引用10：金属加工製造業――200社×150社×3,000〜4,000部品、5名で弥生販売運用、業務がシステムに歪められる

「東京都金属製品製造業：仕入先200社、取引先150社、部品数3,000〜4,000点、担当人数5名」「出荷データを入力した時点で初めて在庫数が減ります」――受注済みでも出荷処理完了まで在庫数が減らないため、複数受注で同一部品が必要な場合に実在庫と表示在庫が乖離。後から欠品が判明する状態。「発注書をExcelで作成→FAX送信、取引先からのメールデータ→CSV変換→弥生販売へ取込という手作業フロー」「業務がシステムの限界に合わせて歪んでいる状態」――小売業向けシステムが製造業の「加工プロセス」に対応していない設計思想の問題

引用11：FA機器販売・部品商社――専門性高い商材で品番ミスが後工程に波及、拠点ごとにExcel運用が分裂

「FAXやメールで届く注文書の処理です。取引先から送られてくる受注データを、担当者が目で確認しながら手入力する」「FA関連機器という専門性の高い商材では、品番や仕様の入力ミスが後工程に与える影響も小さくありません」「同じ会社のなかで受注管理のExcelシートが拠点ごとに違う形になっているのは、それぞれの現場が独自に運用を積み重ねてきた結果」

引用12：問屋＋フランチャイズ双方の受発注で「価格あり／なし」両パターン納品書、独自フォーマットFAXに対応

「問屋向けには卸売価格（下代）を表示し、フランチャイズ向けには小売価格（上代）を表示する」「出荷元の表記もフランチャイズ向けにはフランチャイズ名を記載しなければならない」「『価格あり』と『価格なし』の両パターンで納品書を出力、送付先ごとに異なる送料の請求書反映、問屋ごとに異なる下代への対応が必要」「一部の取引先は独自フォーマットの発注書をFAXで送ってくる」ためAI-OCRによる自動データ化機能が必須

引用13：スプレッドシートでは仕入先120〜130社の納品書一元管理が不可能

「規模が大きくなるにつれ、ヒューマンエラーが後を絶たなくなった」「エラー対応に追われて、本来一番大切な売上管理に手が届いていない」「スプレッドシートで事業を拡大できるのは、ある規模までです」「仕入れ先120〜130社分の納品書をシステム上で一元管理することは、スプレッドシートでは不可能な領域」「集荷ルート管理ではスプレッドシートとメール・LINEでやっているとすれば、情報の鮮度と正確性に問題が起きているはず」

引用14：商品マスタ脱Excel化――情報検索遅延、変更履歴不明、画像管理不能

「欲しい情報を見つけるのに時間がかかる」「商品マスタ情報の変更履歴が分からない」「商品の画像などのファイルを管理できない」（Excel管理の限界として列挙）

引用15：PIM必要性――卸売業で20人月3,000時間が転記作業、バイヤー70%が事前ネット検索

「ECサイトへの掲載が増え、商品管理が煩雑化している」「商品情報の掲載に多くの時間がかかるのでなんとかしたい」「約3,000時間（20人/月）もの時間が、紙から基幹システムへの転記作業に投下されている状況」「多くの企業では商品情報をExcelやスプレッドシート、部門ごとのファイルサーバーなどでバラバラに管理」「誰でもアクセス可能な一元管理の欠如による情報の属人化リスク」「商品選定をするバイヤーの70%は営業担当と連携をとる前に、まずネット検索」「販売側のEC対応は8%にとどまる」「1日1000枚ものFAX注文書」「10万SKU分のカタログ解析で年間10,000時間の工数削減」「塗料商社ORSコジマ株式会社では商品登録作業を9割削減」

引用16：医療系営業の客先別呼称・属人化40%、年間1.6〜2.4億円のコスト削減余地

「『この術式に使える○○メーカーの代替品はあるか』といった問い合わせへの対応が、全体の約4割を占め、ベテラン営業に依存」「医療現場は緊急性が高く、電話・FAX・メールが混在し、病院ごとに異なる品番体系や『いつものカテーテル』といった曖昧な注文が多い」「日々数百件の注文処理」「間接材の年間仕入額約80億円のうち、全体の約5%程度しか横断的なチェックができていない実態」「同一品目の価格差や割高な発注先の特定で、平均2〜3%のコスト削減余地」（年間1.6億〜2.4億円規模）

引用17：JANコードなしで取引拒否、お店側でコード貼付の手間

「JANコードないことによって取引できなくなったケースは普通にあった」（大手雑貨販売店）「JANコードなし商品はお店で発行してつけています」「こういう細かいところが面倒なので次は無いと思われても仕方ない」（セレクトショップ）「レジを通す商品は１つ１つコード印刷して商品に貼るのがすごく面倒」「JANコード付き資料の営業効果：その場で注文もらえたりマスター登録までいくこともある」（プロダクトデザイナー）「JANコードがないと取引してくれないお店は普通にあるよ」「お店が発行する場合、パッケージの思わぬ場所にコードシールが貼られる場合もある」「Amazon出品はJANコードを取得した商品の出品が原則」「取得費用は12,960円→16,500円（10月以降）」

  • 出典: 卸をするならJANコードを取得しよう！ by ミヤジマ リカ（個人作家／レザーアクセサリー・オリジナルインソール製作販売）
  • 著者の立場: 個人作家（卸新規参入の現場声）
  • 投稿日: 2019-09-09
  • ペインの強度: ★★★★

引用18：SAP S/4HANA移行で「些細な違い」が10万件×100項目で爆発

「旧システムでは『得意先名』が全角30文字まで登録できたのに、S/4HANAでは25文字が上限だった」「旧システムでは『電話番号』にハイフンあり・なしが混在していたが、S/4HANAでは統一フォーマットが必要だった」「10万件のデータ×100項目で掛け算になると、膨大な調査・変換・検証の工数が発生」「『些細な違い』が積み重なり、本番直前まで問題が見えてこない」

引用19：取引先コード「思い思いに付与」で重複登録、複数口座に「○○商事1111111」と社名末尾に付記する謎運用

「運用を設計せず、ルールを設定しないまま、いろんな人がその都度思い思いに付与しまくって収拾つかない状態」「カタカナの全角・半角混在（『ソフトバンク』vs『ｿﾌﾄﾊﾝｸ』）、英数字の全角使用、スペース表記の不統一、商号の有無など複数の変数」が検索時に「別物と認識される」「社名で検索してもひっかからない」ため、登録済みの取引先を見落とし「新たに登録してしまう」という重複登録の悪循環。複数口座対応では社名末尾に口座番号を付記（『○○商事1111111』）するという「謎運用」「支払い申請ソフトと会計ソフトで別コード付与、対応表なし、データじゃなくて人間の目で追って手で消し込む」

  • 出典: 取引先コードを体系的に運用開始した話 by 高橋 本塁打（年商300億円未上場企業の経理財務・管理本部担当）
  • 著者の立場: 中堅卸売の経理財務・管理本部担当
  • 投稿日: 2024-04-29
  • ペインの強度: ★★★★★

引用20：SKUコード「区切りなし・桁数バラバラ」で経営分析が止まる

「『AN1034556BLACKS』や『ZB103455ASBLTBEIGEXL』といったSKUが混在しているケース」「『-』を指定して抽出しても、どれが品番で、どれがカラーなのか指定するのが難しくなる」「経営分析に時間がかかる→経営分析の頻度と精度が下がる→経営の意思決定の精度が下がる」「日々の分析の負荷が大きく、頻度が落ち、それゆえに細やかな意思決定や方針の変更が行えず」

引用21：商品マスタEXCEL編集の手作業限界、複数人同時編集困難

「商品マスタのEXCEL編集されている方も多い」「商品名への情報追加（再入荷表記、セール価格表示など）が必要な場面で、一件ずつの手作業編集が発生」「複数人で同時編集可能というスプレッドシートの利点」――裏返せば従来Excel運用では複数人同時編集の困難があった

引用22：データクレンジング・名寄せは「人手でチェックすることは必要」――契約単位の手続き漏れ

「日付の並び順の統一、郵便番号のハイフンありなし」など複数のデータ値の不統一、「契約単位で行われており、手続きの漏れにつながりやすい」「転居により加入している3契約のうち2契約のみ保全した場合、通知物の一部が以前の住所に送られてしまう」評価指標として「データ値の種数の減少度合い」および「パターン数の減少度合い」を測定することを推奨。属人化については「人手でチェックすることは必要」と指摘

このペインの構造的原因

なぜ卸売業でこのペインが20年以上消えないか、業界固有の制度・歴史・取引慣行・流通構造から分析：

  • 製・配・販の三層流通構造（卸売業最大の構造ロック）：メーカーが採番した「メーカー品番」、一次卸が「自社品番」、二次卸がさらに別の「自社品番」、小売が「ストアSKU」、ECモールが「商品ID」、物流倉庫が「ロケーションコード」と、サプライチェーン全層で別々の品番体系が並走する。「メーカー → 一次卸 → 二次卸 → 小売店という流れが一般的」「中間業者が増えるため、コストが上がる」「価格の透明性が低く、流通のスピードが遅くなる」（Luca）構造そのものが、商品マスタの統合を阻む
  • 取引先別呼称の爆発（卸売業特有の最大ペイン）：自社が「ABC-1234」と統一したくても、取引先A社は「客先品番A-11732」、B社は「いつものコネクタ（短い方）」、C社は「コカ・コーラ500」と発注する。100社の取引先があれば1品番あたり最大100通りの呼称に対応するクロスリファレンスが必要。部品商社では「15,000SKUが取引先別呼称で実質50,000を超える」（リチェルカ）。これは自社単独では解消できず、卸売業に固有の構造的問題
  • JAN／ITF／メーカー品番／社内品番の並列管理：JAN（13桁・商品単品）、ITF（14桁・集合包装）、GS1（医薬品個別認識）、ISBN（書籍）、メーカー品番、社内品番、客先品番が同一商品に並存。「JANコードは商品１つに対して１コード、ITFコードは同一複数個商品に対して1コード」（バーコード講座）の併用で、注文時単位（個／ボール／ケース）が混在
  • 業態別の必須項目差：食品卸は賞味期限・ロット・温度帯・アレルゲン・原産地、医薬品卸はGS1個別認識・薬機法分類、部品商社は客先品番・改版履歴・代替品適合、雑貨卸はサイズ/カラー、書籍取次はISBN・配本情報、酒販は税率区分。同じ「卸売業」でも商品マスタの定義が異なり業態横断の標準化が困難
  • 卸売特有の取引条件マスタ（掛率・上代/下代・リベート・特売送り込み）：商品マスタとは別に取引先別単価・掛率テーブル・特売送り込み価格・販促リベート率を持つ必要がある。「価格システムが取引先×商品×数量の3軸で変わる場合、シンプルなマスタ設計では対応できない」（業界一般）「リベートの精算に毎月1週間かかっている」（株式会社ripla）
  • 下代／上代の併用表示要請：「問屋向けには卸売価格（下代）を表示し、フランチャイズ向けには小売価格（上代）を表示する」「『価格あり』と『価格なし』の両パターンで納品書を出力」（マサシ／Wikiだるま）と、同一商品でも取引先タイプにより価格表示の出し分けが必要
  • 商品マスタ200項目超の多さ：JAN、ITF、商品名（正式名／略称）、容量、規格、サイズ、原材料、アレルゲン、特定原材料、原料原産地、賞味/消費期限、ロット管理、温度帯、税区分、インボイス番号、関税分類、上代、下代、掛率、取引先別単価、送料負担、販促リベート、特売送り込み、廃番フラグ、改廃情報など。「だいたい200項目以上」（林拓人）。新商品が日々追加される食品卸では追いつかない
  • 中小卸に専任マスタ管理者を置く余力がない：林拓人氏指摘「数人〜10人以上」が必要だが、中小卸では1人が兼務する。結果として個人PC・Excel管理が常態化、「どれが最新版か誰も分からない」（EC卒業）
  • 口頭値引きの未反映文化：「あの商品の価格、今週だけ特別に安くするから、よろしく！」（EC卒業）が文書化されないまま赤字販売。価格マスタが商品マスタと連動しない取引慣行
  • メーカー側のマスタ整備差：メーカーが採番した「メーカー品番」「JAN」「規格書」が完全に整備されているとは限らない。メーカーから受け取った時点で項目が空欄、画像不備、規格書未提出のケースが恒常的。「メーカーに対して『違うよ』と言える主体がない」（業界一般）
  • HACCP／PL法／景表法／食品表示法／インボイス制度の必須項目増：食品卸では加工食品の食物アレルギー表示（特定原材料8品目＋推奨21品目＝28品目）、原料原産地表示、栄養成分表示、特定保健用食品（トクホ）／機能性表示食品の届出番号、機能性関与成分など、年々マスタ項目が増加。インボイス制度（2023年10月開始）で適格請求書発行事業者番号がマスタ必須項目に追加
  • JICFS／規格書ネットワーク等の標準DBは活用半ば：GS1 Japanの「JICFS/IFDB」（JANコード統合商品情報データベース）、インフォマートの「BtoBプラットフォーム規格書」、N-Sikle（日食協商品情報連携標準化システム）等、業界横断の標準DBが存在するが、メーカー登録率・項目網羅率に課題。「メーカー・卸・小売それぞれによる、各社都合での管理が常態化」（経済産業省2025年資料）
  • 流通BMS／JCA手順／Web-EDI／FAX／LINE混在：取引先によって受発注チャネルが異なり、商品マスタフォーマットも各社別。「複数のWeb-EDIシステムを使用しており、フォーマットの変換が大変」（Masstery）
  • ECモール各社の仕様差：楽天（親番号/子番号構造）、Amazon（カテゴリツリー）、Yahoo!ショッピング（文字数制限）、自社ECサイトで同一商品を別フォーマットで再登録。「商品選定をするバイヤーの70%は営業担当と連携をとる前に、まずネット検索」「販売側のEC対応は8%にとどまる」（monolyst）
  • 海外規格との差異（輸入卸）：マリン用品輸入卸の例「海外取引先10社、国内卸売先約500社、取扱商品数約200点」（マサシ）で、海外型番→国内呼称変換、HSコード（関税分類）対応、輸入規制品目（食品衛生法、薬機法）の追加項目
  • 季節商品・モデルチェンジによる入れ替え頻発：アパレル卸は春夏秋冬で全SKUが入れ替わる、家電卸はモデルチェンジで型番が変わる、食品卸は限定品・期間商品が日々追加される。マスタ整備が「終わらない」業務として常時発生
  • 廃番処理の遅延と並走：メーカー生産終了後も流通在庫があるため即削除できず、後継品・代替品の紐付け登録が必要。「商品の販売を一時停止する場合は『非表示』『無効』フラグを使い、削除はしない」が中小卸では削除されベテランが「そういえば前にあった」と記憶で対応
  • ベテラン暗黙知の集積：「客先品番A-11732」=「自社品番ABC-1234」の紐付けが、過去の納入実績・取引先担当者との会話・経験則に基づく判断。マスタ化されていない。「品番候補が複数（メーカー品番違い／長さ違い／改版違い）あり、過去のやり取りや納入実績を突き合わせないと特定できず」（リチェルカ）
  • 基幹システム同士の非連携：販売管理（営業）・在庫管理（物流）・購買管理・会計が別システムで、それぞれ別の商品コード体系。「営業部では商品をアルファベット+数字で管理しているが、物流部では別の連番を使っている」（ripla井上氏）
  • 取引先名表記の多様性：「『株式会社ABC』『（株）ABC』『ABC』が別々のコードで登録」（ripla井上氏）「カタカナの全角・半角混在（『ソフトバンク』vs『ｿﾌﾄﾊﾝｸ』）」（高橋本塁打氏）。検索でヒットせず重複登録される悪循環
  • 基幹システム刷新コストの重さ：商品マスタ統合のためのERP刷新は数千万円〜数億円。中小卸には不可能。スプレッドシート・Excelで運用してきた事業者ほどデータ量と表記ゆらぎが膨大化。「全角30文字→25文字」「ハイフン有無」が「10万件×100項目で掛け算」（大垣伸悟）
  • データクレンジングの効果が見えにくい：「マスタ整備に3カ月」と提案しても、経営層には効果が見えにくく後回し。「投資は3,000万円と明確だが、効果は『入力ミスが減る』『処理が速くなる』という曖昧なもの」（リチェルカ）と投資判断が困難
  • 2024年問題（ISDN廃止）に伴うEDI刷新の同時並行：「ISDN回線の廃止で従来のJCA手順が使えなくなる」（株式会社ripla／Masstery）、流通BMS移行コスト負担と商品マスタ整備が同時発生し、中小卸の負担が複合化
  • METIの商品情報連携標準化（2026年稼働予定）の影響：経済産業省が2024年11月に「商品情報連携標準に関する検討会」を設置し2026年の商品情報プラットフォーム稼働を目指すが、現状は「メーカー・卸・小売それぞれによる、各社都合での管理が常態化」（METI公開資料）。完全普及まで時間がかかる
  • 「結局○○さんがいないと回らない」属人化文化：「『山田さんがいないと、この取引先の発注ができない』『鈴木さんしか、あの品番体系を理解していない』——受発注の現場で、ベテラン社員の名前が"固有名詞"として語られる瞬間、その業務は既に属人化」（リチェルカ）。マスタ統合への動機が個人レベルでは生まれにくい

業界が試している既存の解決策と限界

  • 基幹システム（販売管理・卸売業向けERP：ASPACシリーズ／FOODMASTER／PieceWorks Smart／弥生販売／PCA／キャムマックス／GRANDIT／NetSuite／Biz∫ 等）

    • 卸売業向けには食品・部品・アパレル等の業種特化テンプレートが存在
    • 商品マスタ・取引先別単価・掛率・リベート等を管理する機能を提供
    • 「製造業向けのパッケージをそのまま使おうとして、現場が回らなくなった」（ripla）事例多数。卸売特有の業務（リベート・掛率・取引先別単価・例外3〜4割）に汎用ERPは不適合
    • 中小卸では「弥生販売」「PCA」など小売業向けが流用される結果、「業務がシステムの限界に合わせて歪んでいる」（マサシ／Wikiだるま）状態
    • 月額数万〜数十万円のランニングコスト

  • PIM（商品情報管理：monolyst／Contentserv／PCS／VPJ等）

    • 「ECサイトへの掲載が増え、商品管理が煩雑化」（monolyst）への対応として登場
    • 「10万SKU分のカタログ解析で年間10,000時間の工数削減」「商品登録作業を9割削減」（monolyst導入企業）の事例
    • ただし「PIMだけでは解決できない」――取引先別呼称の名寄せまではPIM単独で解けず、マスタ整備の前提工事が必要
    • 中小卸には依然として導入コストが重い

  • JICFS／IFDB（GS1 Japan）――JANコード統合商品情報データベース

    • メーカーが登録した商品情報（236項目）を卸売・小売が共通利用できる業界標準DB
    • 「JICFS/IFDB商品情報を活用することで、地域流通VANに参加する卸売・小売業の商品マスタメンテナンス負担を軽減」（GS1 Japan）
    • メーカー登録率・項目網羅率に課題、メーカーが登録しなければ卸が個別整備
    • グロサリ・日用品中心で、専門商材（部品商社・FA機器・特殊食品）はカバーされない

  • N-Sikle（日食協 商品情報連携標準化システム）

    • メーカー・卸間の見積書・商品マスタ情報共有をデジタル化
    • 各小売への個別対応や重複作業を削減
    • 食品業界限定、参加メーカー・卸の網羅率に課題

  • 流通BMS（流通ビジネスメッセージ標準）

    • 製・配・販の三層を標準フォーマットで接続するEDI標準（GS1 Japan）
    • 「流通BMS接続で従来比1時間半早く出荷作業に入れる」（事例）
    • ただし大手取引先間中心、中小取引先には50万円/社のコスト負担
    • 取引先ごとに移行タイミングが異なり「複数の小売取引先がそれぞれ異なるタイミングで流通BMS移行を要請」（ripla）

  • MDM（マスタデータマネジメント）プロジェクト

    • 大手卸・商社中心の取り組み、中小には予算的に不可能
    • データクレンジング・名寄せに「人手でチェックすることは必要」（アットストリーム）
    • 効果が見えにくく経営層の支持が得にくい

  • AI-OCR・AI受発注（Wikiだるま、batton、CO-NECT等）

    • 注文書からの自動データ化は進歩。「FAXやメールで届く注文書の処理を担当者が目で確認しながら手入力する」（マサシ）課題に対応
    • 「自社マスタへの紐付け」は別問題。取引先別呼称→自社品番の変換テーブルが整備されていなければAIでも判定不可
    • 「いつものコネクタ（短い方）」のような曖昧表現は人手判断が残る

  • エンベディング・LLMによる類似品名寄せ（萌芽期）

    • 2024〜2026年に商品名のベクトル化で類似度判定する試行が登場
    • 「コカ・コーラ500」と「コカ・コーラPET500ml」を同一視するなど
    • 精度は未成熟。最終判断は人手が必要

  • ノーコード・ローコード（kintone、Canbus、Bubble等）

    • 「商品マスタ情報の変更履歴」「画像ファイル管理」（canbus_systena）等のExcel限界に対応
    • 脱Excel化には有効。ただし新規構築の手間と運用設計が必要
    • 既存の品番ゆらぎを名寄せする機能は標準では持たない

  • 業界VAN（食品流通：プラネット／日食協／Tanomu等）

    • 食品メーカー・卸間のデジタル受発注インフラ
    • LINE／スマホでの卸受発注（Tanomu）など中小取引先向けの軽量化
    • 商品マスタの完全統合までは至らず、業態横断の標準化に課題

  • JANコード新規取得（GS1 Japan）

    • 「JANコードないことによって取引できなくなったケースは普通にあった」（雑貨販売店）「JANコードがないと取引してくれないお店は普通にある」（プロダクトデザイナー）――取引条件としてJAN必須化
    • 取得費用：年間16,500円〜（2019年時点）、PB商品開発時に都度取得
    • 取得しても自社品番との紐付け作業は別途必要

  • METI共通商品マスタ構想（2026年稼働予定）

    • 経済産業省主導で「商品情報連携標準に関する検討会」設置（2024年11月）
    • メーカーが入力した商品情報を小売・卸等に共有する手順をガイドラインでルール化
    • 「メーカー・卸・小売それぞれによる、各社都合での管理が常態化することがデジタル化の取組を阻害」（METI公開資料）――現状打破のための施策
    • 普及までの時間、参加義務化の有無、既存DBとの整合等が課題

  • EC一元管理システム（クロスモール、ネクストエンジン、JUNGLE等）

    • 楽天・Amazon・Yahoo!・自社ECの商品情報・在庫を一元管理
    • 卸売向けにはBtoB機能（取引先別価格、掛率、与信）の追加が必要
    • モール側仕様変更（楽天の親番号/子番号、Amazonのカテゴリ刷新）への追随コスト

  • 業務委託（マスタ整備BPO・データクレンジング外注）

    • インテージテクノスフィア等が商品情報構築・運用アウトソースを提供
    • 一定規模以上の中堅卸向け
    • 中小卸には費用面で対応困難、また外部委託で蓄積したノウハウが社内に残らない問題

関連ペイン

卸売業界内

  • wholesale-01 FAX受注／取引先依存――商品マスタ未整備が誤入力の温床、取引先がFAX/独自フォーマットを手放さない限り自社単独でマスタ統一不能
  • wholesale-05 取引先依存／パワーバランス（既存pains.md）――「うちは今のやり方で問題ない」と言われたら自社のマスタ統一が頓挫、年商の20%を握る大口顧客の意向が決定的
  • 取引先別単価／リベート／特売送り込み数量管理（pains.mdカテゴリ5）――商品マスタとは別の価格マスタ群、卸売特有
  • EDI／流通BMS／2024年問題（pains.mdカテゴリ6）――ISDN廃止と商品マスタ刷新の同時発生
  • 属人化／ベテラン依存（pains.mdカテゴリ4）――商品マスタが整備されない最大の温床、退職時に業務停止
  • EC・複数チャネル展開（pains.mdカテゴリ8）――楽天・Amazon・自社EC・卸先ECで同一商品を別フォーマット再登録
  • インボイス制度・電帳法対応（pains.mdカテゴリ8）――マスタに適格請求書発行事業者番号追加
  • 販売実績データ・需要予測（pains.mdカテゴリ9）――マスタ未整備で集計できない、卸先POSが還流せず
  • 食品卸の賞味期限・トレーサビリティ（pains.mdカテゴリ3）――商品マスタの一部としてロット・期限管理
  • 基幹システム刷新コスト（pains.mdカテゴリ11）――マスタクレンジングが本体プロジェクトを上回る重さ

横断ペイン

  • 006 商品マスタ・型番ゆらぎ・名寄せ（業界横断）――製造業BOM管理・基幹システム刷新等とも共通する根本構造
  • 001 FAX/手書き受注処理疲弊――商品マスタ未整備が誤入力を増幅
  • 007 紙・Excel・属人化――商品マスタの個人PC保存、Excel運用の限界
  • 業務マニュアル不在・OJT依存――マスタ整備ルールが事業所ごと・先輩ごとに異なる暗黙知
  • 承継・後継者問題――マスタ管理ノウハウが特定個人に集中、退職時に算定停止リスク

卸売業の業界用語の前提知識

商品コード／識別子

  • JANコード（Japanese Article Number）: 日本の商品共通コード（13桁/8桁のバーコード）。EAN/UPCの日本版。商品単品（個）に付与
  • ITFコード（Interleaved Two of Five、集合包装用商品コード）: 14桁、段ボール等の集合包装に印刷。同一複数個商品に対して1コード
  • GTIN（Global Trade Item Number）: GS1の世界共通商品識別コード。JAN・ITF・UPC・EAN等を統合する総称
  • GLN（Global Location Number）: GS1の世界共通事業者識別コード（13桁）
  • GS1個別認識コード: 医薬品・医療機器の個別認識（製造番号・有効期限まで識別）
  • ISBN: 書籍の国際標準図書番号（13桁）
  • メーカー品番（型番）: メーカーが採番した型番。商社が転売する際の元品番
  • 自社品番（社内品番／管理コード）: 自社内で使う統一品番
  • 客先品番（顧客品番）: 取引先（顧客）が自社内で使っている品番。自社品番とは別管理
  • SKU（Stock Keeping Unit）: 在庫管理単位。色・サイズ・容量違いで別SKU化
  • TAISコード: 福祉用具・住宅改修の標準商品コード

卸売特有の取引・価格条件

  • 下代（げだい）: 卸価格（仕入価格）。卸が小売に納める価格
  • 上代（じょうだい）: 小売参考価格（メーカー希望小売価格）
  • 掛率（かけりつ）: 仕入価格／定価の比率（例：6掛＝定価の60%）。取引先別に異なる
  • リベート（割戻し）: 販売後に取引額に応じて還元される慣行。販促リベート、価格見直しリベート、年間達成リベート等
  • 送り込み数量: 特売時に小売へ卸す量
  • 日割チラシ: 日替わり特売チラシ
  • PB（Private Brand）: 小売・卸が自主開発する自社ブランド商品
  • NB（National Brand）: メーカーブランド商品
  • 適格請求書発行事業者番号: インボイス制度（2023年10月〜）で必要な登録番号

マスタ管理関連

  • 商品マスタ（商品台帳）: 商品の全情報を集約したデータベース。JAN、商品名、容量、サイズ、原材料、アレルゲン、規格、価格、産地、賞味期限など200項目超
  • 取引先マスタ（得意先マスタ・仕入先マスタ）: 取引先企業の基本情報DB
  • 取引先別単価マスタ: 取引先ごとの個別価格設定
  • 掛率テーブル: 取引先・商品群ごとの掛率設定
  • PIM（Product Information Management）: 商品情報管理システム。複数チャネル配信を一元化
  • MDM（Master Data Management）: マスタデータマネジメント。商品・取引先・組織等の基幹マスタを統合管理
  • データクレンジング: 重複・表記ゆらぎ・欠損値などを修正してデータ品質を上げる作業
  • 名寄せ: 表記が異なる同一商品・同一取引先のデータを1つにまとめる作業
  • エンベディング（ベクトル化）: 商品名・型番をベクトル空間に埋め込み、類似度で名寄せ判定するAI技術
  • VLOOKUP/XLOOKUP: Excelの参照関数。商品マスタ参照に多用される。VLOOKUPは列追加で壊れやすい

流通インフラ・標準

  • EDI（Electronic Data Interchange）: 企業間電子データ交換
  • 流通BMS（流通ビジネスメッセージ標準）: 消費財流通業界のEDI標準。GS1 Japan策定
  • JCA手順: 旧来のEDI通信方式。ISDN終了で2024年以降利用不可（2028年完全廃止）
  • Web-EDI: ブラウザベースのEDI。取引先ごとに別画面ログイン
  • 業界VAN: 業界横断ネットワーク（プラネット、日食協、自動車部品VAN等）
  • JICFS/IFDB: GS1 JapanのJANコード統合商品情報データベース。236項目
  • N-Sikle: 日食協の食品メーカー・卸間商品情報連携標準化システム
  • GS1 Japan Data Bank: GS1日本の商品情報DB
  • BtoBプラットフォーム規格書: インフォマートの食品規格書（成分表示）DB
  • METI共通商品マスタ: 経済産業省主導の2026年稼働予定の商品情報プラットフォーム

食品卸関連法令・項目

  • HACCP（Hazard Analysis and Critical Control Point）: 食品衛生管理手法。2021年6月から原則全食品事業者に義務化
  • 食品表示法: 食品の品質・期限・添加物・アレルゲン表示を規定
  • 特定原材料: 食品アレルギー表示義務8品目（卵・乳・小麦・そば・落花生・えび・かに・くるみ）＋推奨表示21品目
  • 原料原産地表示: 加工食品の主要原材料の原産地表示
  • PL法（製造物責任法）: 製品の欠陥による損害賠償責任
  • 景表法（景品表示法）: 不当表示・過大景品の規制
  • 薬機法: 医薬品・医療機器・化粧品の品質・効能表示規制

業態別用語

  • 食品卸: 総合食品卸（伊藤忠食品・三井食品等）、酒販卸、青果仲卸、冷凍冷蔵卸
  • 部品商社: 電子部品商社、FA機器販売、機械要素商社
  • 自動車部品卸: 一次卸（地区パーツ卸）約30社、二次卸（地方パーツ商）約2,000社
  • 書籍取次: トーハン、日販、大阪屋栗田等。出版社→取次→書店
  • 医薬品卸: メディパルHD、アルフレッサHD、スズケン、東邦HD（4大卸）
  • 3PL（Third Party Logistics）: 物流業務の包括受託
  • WMS（Warehouse Management System）: 倉庫管理システム

システム・技術

  • ERP（Enterprise Resource Planning）: 統合基幹業務システム（SAP S/4HANA、Oracle、GRANDIT、NetSuite、Biz∫等）
  • 販売管理システム: 受注・売上・請求を管理。卸売向け（ASPAC、FOODMASTER等）、汎用（弥生販売、PCA、キャムマックス）
  • MES（Manufacturing Execution System）: 製造実行システム。製造業卸ではERPと連携
  • MRP（Material Requirements Planning）: 資材所要量計画
  • OMS（Order Management System）: 受注管理システム
  • WMS: 倉庫管理システム

ペイン解消の難易度（仮説評価）

  • 技術難易度: ★★★★（LLM・エンベディングで「コカ・コーラ500」と「コカ・コーラPET500ml」の類似度判定は2024〜2026年で実用化途上。「いつものコネクタ（短い方）」のような曖昧表現や、改版・代替品適合判定は人手確認が必須。完全自動化は困難）
  • 業界普及難易度: ★★★★★（取引先依存があるため、自社単独でマスタ統一できない。100社の取引先がそれぞれ独自呼称を使い続ける限り、クロスリファレンス管理は残る。流通BMS／JICFS／N-Sikle等の業界標準DBも参加メーカー・卸の網羅率に課題）
  • 業態間の標準化困難: ★★★★★（食品・医薬・部品・雑貨・書籍・酒販等で必要項目が大きく異なり、汎用ERPで一括対応は困難。業態特化テンプレが必要だが市場規模が分散）
  • ROI明確化: ★★（マスタ整備の効果は「ミス削減」「処理高速化」「ベテラン依存解消」と曖昧。経営層への投資判断説明が困難。「投資は3,000万円と明確だが、効果は『入力ミスが減る』『処理が速くなる』という曖昧なもの」（リチェルカ））
  • マスタ整備の前提工事: ★★★★★（既存マスタの重複・表記ゆらぎの洗い出しに数カ月〜1年。これ自体がベテラン暗黙知の形式知化作業で、退職リスクと隣り合わせ）
  • 継続運用コスト: ★★★★（取引先側の品番変更・新規取引先追加・新商品登録・廃番処理に都度対応。「マスタは整備したら終わり」ではなく、季節商品入替・モデルチェンジで常時発生）
  • 基幹システム刷新時の壁: ★★★★★（SAP/ERP移行で「全角30文字→25文字」「ハイフン有無」等の些細な違いが「10万件×100項目で掛け算」（大垣伸悟）。卸売特有のリベート・掛率・取引先別単価・例外3〜4割が汎用ERPに収まらない）
  • METI共通マスタへの期待値: ★★★（2026年稼働予定の商品情報プラットフォームに期待があるが、メーカー登録義務化なしでは網羅率に課題、既存DBとの整合性、卸売特有の項目（取引先別単価・掛率）はカバー対象外）
  • 属人化解消の心理的抵抗: ★★★★（「結局、○○さんがいないと回らない」状態のベテラン本人にマスタ整備動機が弱い、「自分のノウハウを公開すると価値が下がる」心理）
  • 中小卸の予算制約: ★★★★★（年商数億〜数十億の中小卸では月額数万〜数十万円のSaaS導入も負担、ERP刷新数千万円は不可能。スプレッドシート・Excelからの脱却が業務量限界（仕入先120〜130社）に達するまで先送りされる）
  • 2024年問題（ISDN廃止）と並走: ★★★★（流通BMS／JCA手順切替と商品マスタ刷新の同時発生。中小卸の対応能力を超える）
  • EC化・複数チャネル化での新規負荷: ★★★★（楽天・Amazon・自社EC・卸先ECで同一商品を別フォーマット再登録。「20人月3,000時間」（monolyst）の追加転記負荷）

引用元記事リスト

  1. 知る人ぞ知る商品マスタ - 林拓人（一般社団法人リテールAI研究会代表理事、今村商事SVP）
  2. 倒産しそうな中小企業にありがちな、杜撰な商品マスタ管理の「あるある」 - EC卒業◆50歳で第二の起業・副業・リスタート（元卸売EC事業者）
  3. なぜ日本の受発注業務は「FAXと電話」から抜け出せないのか - 株式会社リチェルカ（梅田祥太朗CEO監修）
  4. 【連載#5】受発注業務の「属人化」が会社を蝕む—ベテラン依存のリスクと対策 - 株式会社リチェルカ（梅田祥太朗CEO）
  5. 【連載#7】【１章まとめ】受発注現場の「3つの悲鳴」と根本原因 - 株式会社リチェルカ（梅田祥太朗CEO）
  6. 【連載#24】AIエージェントが実現する受発注業務の自律化 - 株式会社リチェルカ（梅田祥太朗CEO監修）
  7. 販売管理の属人化を脱却する5ステップ｜マスタ整備から定着まで - 株式会社ripla（井上氏／ITコンサルタント・PM）
  8. 販売管理システム開発の失敗事例5選｜原因と防ぎ方 - 株式会社ripla（井上氏）
  9. 販売管理システムのデータ移行を成功させる5ステップ - 株式会社ripla（井上氏）
  10. 受発注管理システムの要件定義【業務フロー整理5ステップ実践ガイド】 - 株式会社ripla（井上氏）
  11. 卸売業の受発注管理システム導入【5つのポイントと開発会社の選び方】 - 株式会社ripla（井上氏）
  12. 「確認書のPDFを手入力している」——マリン用品輸入卸業が抱える発注管理のボトルネックと、Wikiだるまという選択肢 - マサシ（AI受発注システム『Wikiだるま』開発者）
  13. 金属加工の製造業が「弥生販売」を使い続けた結果、有効在庫が把握できなくなった話 - マサシ（Wikiだるま開発者）
  14. FAXで届いた受注票、まだ手で打ち直していませんか？ - マサシ（Wikiだるま開発者）
  15. 年間60万円で、問屋とフランチャイズ双方の受発注を一元管理したい - マサシ（Wikiだるま開発者）
  16. スプレッドシートでここまでやってきた食品卸会社が、「売上管理に手が届かない」と気づいた瞬間 - マサシ（Wikiだるま開発者）
  17. 商品マスタ登録の脱Excel化～ノーコードツール～ - canbus_systena（株式会社システナ）
  18. 卸売業注目の、「PIM」とは？導入メリットから選び方まで徹底解説 - monolyst公式（株式会社monolyst）
  19. 卸をするならJANコードを取得しよう！ - ミヤジマ リカ（個人作家）
  20. SAP導入プロジェクトが炎上する5つのパターン【前編】 - 大垣伸悟（ERP・SAPコンサルタント）
  21. 取引先コードを体系的に運用開始した話 - 高橋本塁打（年商300億円企業の経理財務担当）
  22. 経営と業務の効率化に直結する品番・SKUルール - Bizgem事務局（株式会社Bizgem）
  23. 正規表現を使って商品マスタ編集を劇的に楽にする方法 - もりもと（OMS+WMS一体型SaaS企業関係者）
  24. クレンジングが肝！ぐちゃぐちゃ顧客データの名寄せのコツ＜TIS共著コラム2-3＞ - アットストリームコンサルティング株式会社／TIS共著
  25. 卸売業のDX完全ガイド｜受発注から営業まで業務効率化の現場改善策 - Le Lien-Kuraoka
  26. 日本の卸売業 vs 世界の卸売業：何が違うのか？ - Luca
  27. 企業間の取引効率化に必須のEDIと2024年問題について解説します - Masstery
  28. 卸先での販売実績データ、活用できていますか？ - Masstery
  29. 見積書は掛率を確定してから作ろう 〜商談での掛率交渉テクニック〜 - 山添利也（食品展示会・小規模食品メーカーコンサルタント）
  30. バイクの輸入商社からSCM SaaSへ。困難なテーマを選んだ理由とは - リチェルカ起業エントリ #1 - 梅田祥太朗（株式会社リチェルカCEO）

関連する横断ペイン

更新 2026-05-09 ・ 引用元 22記事
← 卸売業のペイン一覧techbeansに相談する →