JANコードと社内コードの使い分け方｜商品マスタ統一のベストプラクティス| 在庫管理

多くの企業では、商品マスタに「JANコード」と「社内コード（自社型番）」の両方が存在します。
どちらも商品を識別するためのコードですが、用途と管理範囲がまったく異なるため、
現場では「どちらを基準に運用すべきか」混乱が起こりがちです。

特に、在庫管理・販売管理・POS連携・ECサイト運営など複数のシステムが関わる環境では、
JANコードと社内コードの扱いを明確に区別しないと、
商品登録の重複や在庫データのズレといった問題が発生します。

まずは、それぞれの役割と位置づけを整理してみましょう。

H2-1　なぜ「JANコード」と「社内コード」が混在してしまうのか

---

H3-1　JANコード＝流通業界の共通識別コード

**JANコード（Japanese Article Number）**とは、
日本で流通している商品を共通で識別するための13桁のバーコード番号です。
家電・食品・日用品など、ほとんどの商品に印字されており、
小売店や卸売業界でのPOSレジ処理や物流スキャンに使われています。

つまりJANコードは、**業界全体で共有する“外部向け識別子”**です。

• 商品A（メーカー発行のJANコード）：4581234567890
• POSやECでも同じ番号で認識される
• 販売時点で「どのメーカーのどの商品か」が即座に特定できる

JANコードの目的は「流通業全体の共通認識」であり、
企業内の在庫や仕入れ管理の都合を反映させるものではありません。
そのため、同一商品を複数仕入先から調達している場合でも、JANコードは1つに統一されます。

H3-0　JANコードの目的と誰がコードを発行するか　JAN　と　SKU

目的は先の章で説明しましたが、しっくりこない方も多いと思います。もう少し深堀しましょう！

JANコードとSKUの決定的な違いは「用途」と「管理範囲」にあります。初心者にもわかりやすいように具体例も交えて説明します。

JANコードとは

• 「Japanese Article Number」の略で、主に商品流通のために使われる世界共通商品識別コードです。
• 13桁（または8桁）の数字で構成され、バーコードとして商品パッケージに付けられます。
• 流通業界全体で使われ、小売店や仕入れ先、ECサイトなど商品を識別しやすく管理するための標準です。
• 例えば、同じ種類の赤いTシャツでサイズがSもMもあれば、サイズごとに別々のJANコードが付与されます。

SKUとは

• 「Stock Keeping Unit」の略で、商品の在庫管理の最小単位です。
• 企業内部で独自に設定し、英数字など自由にコード化できます。
• 色やサイズ、パッケージ違いなどのバリエーションごとにSKUが割り当てられます。
• 例えば赤のTシャツのSサイズを1SKU、Mサイズを別SKUとして管理します。まとめ売りのセットを別SKUにすることも可能です。

決定的な違いと目的

項目	JANコード	SKUコード
用途	流通・販売・POSなど、外部流通に使う世界共通コード	企業内部での在庫管理や販売管理用コード
管理範囲	世界共通の規格に基づき全国・全流通で使われる	会社や事業者の独自管理範囲で自由に設定可能
コード体系	13桁数字（国コード・メーカーコード・商品コード・チェックデジット）	英数字など自由に設定
対象単位	商品単位（SKUごとに付与されることも多い）	商品の最小バリエーション単位（色・サイズなど）

まとめ例

赤のTシャツ（ブランドA）があり、S・M・Lの3サイズ、色は赤・青の2種類の場合

• JANコード：サイズ・カラーごとに異なる世界共通識別番号が付与される（例：赤のSサイズ用、青のMサイズ用それぞれ別のJANコード）。
• SKU：同じく赤Sサイズ、赤Mサイズ、青LサイズそれぞれがSKUとして社内で個別管理される。SKUコードは店舗や企業ごとに違う。

つまり、JANコードは外部流通や販売の共通ルールとして「どの事業者のどの商品か」を示し、SKUは企業内部の在庫や販売の管理単位として「商品のバリエーションの最小単位」を示します。JANコードがあれば、SKUごとに管理しやすいという関係です。

​JANコードは在庫識別の最小単位として扱えないのですか？

JANコードは在庫管理の最小単位として「使える場合もあります」が、業務実態に即した正しい最小単位としてはSKU（Stock Keeping Unit）が推奨されます。

理由と具体例

• JANコードは主に流通・POSレジで「商品識別」のために付与されますが、サイズや色などが異なっても同一JANコードになることがあります。たとえば「同じTシャツで色違い・サイズ違い」が1つのJANコードの場合、それぞれの在庫を個別に管理することができません。​
• SKUは「これ以上細かく分類できない最小単位」であり、色・サイズ・セット品・パッケージ違いなどまで分けて社内で管理できるため、ミスや在庫管理のロスを防げます。​
• 一部アパレル商品やパーツなど、JANコードが製品バリエーションごとに付与されていれば、その場合に限りJANコードで最小単位として扱うことが可能です。ですが、JANコード体系の都合や会社の運用次第で、「1つのJANコードに複数バリエーション在庫が含まれる」ケースも多く、SKUのほうが柔軟です。​

まとめ

• JANコードだけで在庫の最小単位管理ができるとは限りません。
• 「SKU：自社の業務や運用に合わせて、色・サイズ・仕様・販売形態など最小単位で管理」
• 「JANコード：流通やPOSのための標準識別用の番号。SKUほど柔軟な最小単位ではない」

したがって、JANコードをそのまま最小単位として扱うのは例外的ケースであり、多くの現場においてはSKUが「在庫識別の最小単位」です。

乱暴に言うと商品の識別のために振られているので、必ずしもカラー・サイズ・材料といった識別になっているわけではない」という理解は正しいです。

JANコードの本質

• JANコードは「どの事業者のどの商品か」を識別するために割り振られる国際標準のコードです。​
• JANコード自体は「カラー」「サイズ」「材料」といった商品バリエーション情報まで必ずしも細かく反映する仕組みではありません。​
• 事業者が必要に応じて、色・サイズ毎に別々のJANコードを発行することもできますが、その運用は事業者に委ねられていて、必ずしも全バリエーションごとに分けるルールはありません。​

具体例

• 例えば同じTシャツ（ブランドA）で、赤・青やS・M・Lなど複数のバリエーションがある場合、すべてをひとつのJANコードで管理してしまう事業者もいれば、色・サイズごとに細かく分けて付与する企業もあります。​
• どの商品か（型番・規格など）さえ明確になればJANコードは成立するため、「原則として全ての属性を識別する」わけではありません。

したがって、JANコードは商品の基本識別用ですが、カラー・サイズ・材料などのきめ細やかなバリエーションを識別できるかは事業者の運用次第です。

​誰がJANコードを割り振るのか

JANコードは、商品のブランドを持っている事業者（商品の主体的な供給者）が、自社で商品を識別するために割り振るものです。ただし、そのためには一般財団法人流通システム開発センター（GS1 Japan）という組織から「GS1事業者コード（JAN企業コード）」を取得する必要があります。

具体的には、

• まず事業者がGS1 Japanに申請し、事業者固有のコード（GS1事業者コード）を取得します。
• 次に、自社の商品ごとに重複のない商品コードを設定し、それらを組み合わせてJANコードを作成します。
• GS1 Japanは日本国内におけるJANコードの管理と発行の認可をしている機関です。

このように、JANコードは事業者が自社商品に対して割り振るコードですが、その前提としてGS1 Japanから事業者コードを正規に取得する必要があります。​

つまり「JANコードを割り振るのは商品を供給する企業自身」ですが、発行権限やコード構造の管理はGS1 Japanが担っています。

---

H3-2　社内コード＝自社の在庫・販売を管理する独自キー

一方、**社内コード（自社コード・社内型番）**は、
自社での在庫・販売・仕入れ管理を目的として独自に設定されるコードです。

これは、JANコードとは異なり、社内システム（在庫管理・受注・発注）で使われる内部的な識別子です。
SKUコード（Stock Keeping Unit）と同義で使われることも多く、
商品仕様・サイズ・色などのバリエーションを区別するための最小単位になります。

社内コードの主な特徴は以下の通りです。

項目	内容
用途	社内の在庫・販売・仕入・製造管理
管理範囲	自社内限定（他社とは共有されない）
柔軟性	色・サイズ・セット商品など自由に設計可能
管理者	マスタ担当・システム管理者・商品登録担当

たとえば、同じJANコードを持つ商品でも、自社内でバラ売りとセット販売がある場合、
それぞれ別の社内コードを付けて管理することで、在庫数や粗利率を正確に把握できます。

---

H3-3　二重管理が生むトラブル（重複登録・整合性崩壊・棚卸ミス）

JANコードと社内コードが混在すると、現場では以下のようなトラブルが発生します。

① 重複登録

同じJANコードの商品を、仕入先ごと・担当者ごとに別々の社内コードで登録してしまい、
同一商品が複数行に分かれて管理される。
結果として在庫数や販売履歴が分断され、正しい分析ができなくなる。

② 整合性の崩壊

社内コードを基準に在庫を更新しているのに、
ECサイトやPOSではJANコードを基準に処理している場合、
在庫が自動で同期せず、理論在庫と実在庫が一致しなくなる。

例：
ECでは「4581234567890」の在庫が0だが、
社内システム上は「A-001」として在庫10が残っている、など。

③ 棚卸ミス・販売ロス

現場でバーコードスキャン（JAN）と在庫表（社内コード）の不一致が起こり、
棚卸時に「存在するのに無い」「無いのにある」といった誤差が発生。
最悪の場合、売上計上漏れや返品ミスにつながります。

---

💡まとめると：

• JANコードは「外部と共有する識別番号」
• 社内コードは「自社業務を最適化する識別番号」

両者の目的を明確に分け、どちらを「軸」に商品マスタを統一するかを決めない限り、
データの混乱はなくなりません。

---

H2-2　JANコードと社内コードの役割を整理する

• H3-1　【外部向け】JANコードの管理範囲（POS・卸・小売・EC）
• H3-2　【内部向け】社内コード（SKU・型番）の運用目的
• H3-3　JANとSKUをどうリンクさせるか（対応表・キー紐づけ）

H2-2　JANコードと社内コードの役割を整理する

「JANコード」と「社内コード（SKU）」は、見た目こそ似ていますが、
使う場所・目的・管理責任者がまったく異なるものです。
ここでは両者の役割を明確に分け、それぞれが担う範囲を整理していきましょう。

---

H3-1　【外部向け】JANコードの管理範囲（POS・卸・小売・EC）

JANコードは、メーカーや卸売業者、小売店など、
異なる企業間で商品を識別するための**「共通の識別キー」**です。

たとえば、次のようなシーンでJANコードは使われています。

使用先	利用目的
POSシステム	レジで商品をスキャンして販売データを登録
卸売・仕入	注文書・納品書で共通の番号として指定
ECモール	商品ページの識別（Amazon、楽天など）
物流・倉庫	梱包・検品・出荷時のスキャン識別

JANコードは、あくまで「流通全体での共通番号」なので、
企業が独自に変更したり、別の用途に転用したりすることはできません。

👉 **つまり、JANコードは「外部と会話するための共通言語」**です。

そのため、在庫や原価の管理にJANコードをそのまま使うのは危険です。
流通の都合上、同一JANでも内容量違い・リニューアル品が存在する場合もあるため、
社内の運用では、後述する「社内コード（SKU）」で精緻に管理する必要があります。

---

H3-2　【内部向け】社内コード（SKU・型番）の運用目的

一方の**社内コード（SKU）**は、自社システム内で使う“内部識別子”です。
JANコードが「外部コミュニケーション」のための言語なら、
社内コードは「自社オペレーションを回すための言語」といえます。

主な目的は次の通りです。

目的	内容
在庫管理	倉庫・店舗ごとの数量をSKU単位で把握
受発注	仕入単価・仕入先・納期をSKU別に管理
販売管理	利益率・回転率・ランキングをSKU単位で算出
原価・会計	SKU別の原価・粗利を算出し経理へ連携

SKUを活用することで、
「同じJANの商品でも、販売単位・パッケージ・販路ごとに別管理」
といった柔軟な運用が可能になります。

たとえば――

• JANコード：4581234567890（共通）
• SKUコード：
  　A001-BL-M → 通常販売用
  　A001-BL-M-S → セット販売用

このように、同一JANでもSKUを細かく分けることで、
社内の販売形態・在庫単位に合わせた管理ができるのです。

---

H3-3　JANとSKUをどうリンクさせるか（対応表・キー紐づけ）

JANとSKUを正しく運用するためには、
両者の関係を明示的に「対応表（マッピング表）」として管理することが欠かせません。

🔹基本構造の考え方

1つのJANに対して、複数のSKUが紐づく構造が一般的です。
（1対多の関係）

JANコード	SKUコード	商品名	販売形態
4581234567890	A001-BL-M	Tシャツ Mサイズ	通常販売
4581234567890	A001-BL-M-S	Tシャツ Mサイズ（2枚セット）	セット販売

このような対応表をシステムやExcel上で管理することで、
どのSKUがどのJANに属しているのかを即座に確認でき、
データの重複や在庫ズレを防げます。

🔹管理上のポイント

• 対応表はマスタデータベース内に正式項目として登録する
• 新商品登録時に「JAN⇔SKU対応」を必須入力にする
• 外部システム連携時（POS・EC）ではJANをキーに、内部ではSKUをキーに扱う

特に、在庫管理システムを導入している場合は、
「JANコードは外部照合キー」「SKUコードは在庫キー」として設計しておくと安定します。

---

💡まとめると：

• JANコード → 取引・流通を統一する“外部識別子”
• SKU（社内コード） → 在庫・販売を最適化する“内部識別子”
• 両者を結ぶ「対応表（マスタ連携）」がデータ精度の要

次章では、この対応関係を実際のシステム・運用にどう反映させるか、
「商品マスタ統一のベストプラクティス」として解説します。

---

H2-3　商品マスタ統一のベストプラクティス

JANコードと社内コードを正しく使い分けるだけでは、
在庫データの整合性はまだ不十分です。
両者を含めた「商品マスタ全体の設計」を一元化することが、
正確な在庫・販売管理を実現するための次のステップです。

この章では、SKUマスタ・JANマスタ・商品マスタをどう整理し、
組織として運用ルールを確立するかを解説します。

---

H3-1　マスタ構造を一元化する（SKUマスタ・JANマスタ・商品マスタ）

商品マスタの統一で重要なのは、**「どのマスタが基準で、どの情報が派生するか」**を明確にすることです。
現場ではよく、POS側・EC側・在庫管理側それぞれが別のマスタを持ち、
結果として「同じ商品なのに別データ」という状態が起こります。

理想的なマスタ構造は次の3層です。

階層	名称	役割	主キー
第1層	商品マスタ	商品の基本情報（カテゴリ・名称・ブランドなど）	商品コード
第2層	SKUマスタ（社内コード）	色・サイズ・セット構成などの在庫単位	SKUコード
第3層	JANマスタ	流通用の外部コード・バーコード情報	JANコード

💡SKUマスタとJANマスタを“別レイヤー”で設計し、
両者を1対多で紐づける構成が理想です。

この構造により、

• 同じJANでも複数SKUを持つ（例：通常・セット販売）
• 同じSKUでも異なるJANを持つ（例：OEM先ごとに異なるJAN）
  といった複雑な現場パターンにも柔軟に対応できます。

---

H3-2　更新ルールを明文化（誰が・いつ・どのシステムで変更できるか）

マスタ統一の成功は、技術よりも運用ルールにあります。
「誰が・いつ・どのシステムで・どの項目を更新して良いか」を明文化しておくことで、
無秩序なデータ更新を防げます。

主なルール設計のポイントは以下のとおりです。

項目	更新権限者	更新タイミング	注意点
商品マスタ（名称・カテゴリ）	商品企画部	新商品登録時のみ	命名ルールを固定（全角／半角・略称統一）
SKUマスタ（サイズ・カラー等）	在庫管理担当	仕様変更時・棚卸時	コード体系変更は禁止（SKUは一貫性重視）
JANマスタ（バーコード登録）	営業・EC担当	外部出荷開始前	他社JANとの重複を必ずチェック

加えて、

• 登録時には重複チェックを自動化
• CSV・Excelでの手動更新を最小化
• 更新履歴をログとして残す

といったシステム的な制御も必須です。

特に、在庫・受注・販売が別システムにまたがる場合は、
“どのマスタが基準か”を決めておかないと、
データの上書きや同期ミスが頻発します。

---

H3-3　変換テーブルでJAN⇔社内コードの整合性を保つ

マスタ統一の最終ステップは、
JANコードと社内コード（SKU）の変換テーブルを構築することです。

このテーブルがあれば、
どのシステムから見ても「同じ商品を同一のキーで参照」でき、
在庫・販売・出荷データのズレを防げます。

🔹変換テーブル例

JANコード	SKUコード	商品名	状態	登録日
4581234567890	A001-BL-M	Tシャツ Mサイズ	有効	2025/11/01
4581234567891	A001-BL-L	Tシャツ Lサイズ	有効	2025/11/01
4581234567899	A001-BL-M-S	Tシャツ M 2枚セット	有効	2025/11/05

🔹運用のポイント

• 在庫・販売・ECシステムは SKUコードを主キー に統一
• JANコードは外部連携時の**照合キー（サブキー）**として利用
• JANの追加・削除時はSKUを変更せず、変換テーブルだけを更新
• データ分析ではSKU基準、販売報告ではJAN基準という二段構えにする

こうすることで、
社内ではSKUを主軸に在庫を正確に管理しつつ、
外部システム（POS・EC・取引先）とはJANでスムーズに連携できます。

---

💡まとめると：

• SKUマスタ・JANマスタ・商品マスタの3層構造で一元管理
• 更新ルールを明確化し、誰がどこまで触れるかを定義
• JAN⇔SKUの変換テーブルで整合性を常に保証

このベースを整えておくことで、
後続の「在庫管理システム」や「EC連携」導入がスムーズに進み、
“ひとつの真実（Single Source of Truth）”としてのマスタを実現できます。

---

H2-4　システム設計で意識すべき「キー項目」の考え方

商品マスタを統一しても、システム設計でのキー項目の扱いを誤ると整合性は崩れます。
とくに「どのコードを主キー（基準）にするか」は、在庫管理や販売集計の信頼性を左右します。

ここでは、SKUコードとJANコードをどのようにシステムへ設計すべきか、
3つの視点から整理します。

---

H3-1　商品マスタの主キーは「SKUコード」を中心に設計

システム設計の基本原則は、内部処理はSKUコードを主キーにすることです。
SKUは企業ごとの在庫単位であり、サイズ・色・仕様などの違いを唯一識別できます。
逆に、JANコードはあくまで「外部識別子」なので、これを主キーにしてしまうと
以下のような問題が発生します。

問題	影響
同一JANで複数SKUが存在	売上・在庫データが混在
JANなしの商品がある	商品登録ができない
JAN変更が発生	旧JANとの履歴が切断される

💡SKUコードを主キーとすれば：
・同じJANの商品でもSKU単位で在庫を管理可能
・JANが未登録の商品も登録できる
・コード体系を変えずに商品履歴を追跡できる

🔹テーブル設計のイメージ

フィールド名	内容	主キー指定
sku_code	社内コード（在庫単位）	✅ 主キー
product_code	商品コード（型番）
jan_code	外部バーコード	外部キー扱い
color	カラー識別
size	サイズ識別
stock_qty	在庫数量
price	販売価格

このようにSKUを軸に据えることで、
商品がどのシステムから来ても一貫したデータとして扱えます。

---

H3-2　JANコードを外部キーとして連携する設計例

JANコードは、外部システム（POS・ECモール・仕入先）と連携する際の**外部キー（サブキー）**として設計します。
つまり、「システム内のSKU」と「外部取引先のJAN」をマッピングする構造です。

🔹設計例：JAN⇔SKU対応テーブル

（複数のJANが1つのSKUに紐づくケースにも対応）

id	sku_code	jan_code	status	remark
1	A001-BL-M	4581234567890	active	国内流通用
2	A001-BL-M	4900000001111	active	EC専用JAN
3	A001-BL-L	4581234567891	inactive	廃番品

この構成により、

• 同一SKUで複数のJANを扱える（OEMやモール別JAN対応）
• JAN更新が発生してもSKU履歴を切らずに管理できる
• 外部からの注文データをJAN基準で受け取り、内部SKUに変換できる

特にEC・POS・受発注システムが異なるプラットフォームで運用されている場合、
この「変換テーブル」をハブにしておくことでデータ連携が安定します。

---

H3-3　POS・EC・在庫システムを連動させる時の注意点

複数システムをつなぐ際、最も多いトラブルが「コードの不一致」です。
たとえば、POSではJANで集計しているのに、在庫システムはSKUで在庫を引き当てている場合、
どちらの値を正とすべきか判断がつかなくなります。

連携を安定させるためのポイントは以下の3つです。

① データの“主従関係”を決める

どのシステムがマスタを持つのかを明確に定義します。

• 在庫基準：在庫管理システム
• 商品属性基準：商品マスタDB
• 取引基準：POSまたはEC
  この整理が曖昧だと、双方向更新でデータが競合します。

② コード変換は“1か所”で行う

各システムで独自にJAN⇔SKU変換を行うと、変換ロジックが乱立します。
変換テーブルを中央サーバーまたはマスタ連携APIに集約することで、
整合性を保ちながら複数システムを接続できます。

③ システム間で“キー項目の粒度”を揃える

POSでは「JAN単位」で売上を集計していても、
在庫管理は「SKU単位」で在庫を持っています。
この粒度差をそのまま放置すると、販売数と在庫数が一致しません。
→ 対応策として、SKU⇔JAN対応表で粒度をマッピングし、
販売集計時にSKU換算を行う仕組みを組み込みましょう。

---

💡まとめると：

• 内部処理はSKUを主キーに設計
• 外部連携はJANをサブキーとしてマッピング
• システム間連携では“変換テーブル一元化”が肝

これにより、在庫・販売・仕入・ECのすべてが「同じ商品を同じIDで認識」でき、
社内外の情報がひとつに統一された“正しいマスタ連携”が実現します。

---

H2-5　運用上の落とし穴と対策

• H3-1　同一商品に複数JANが付くケースの扱い
• H3-2　JAN未発行商品（自社製造・限定商品）の登録ルール
• H3-3　古いJAN・廃番商品の扱いと履歴管理

H2-5　運用上の落とし穴と対策

JANコードと社内コードの設計を整えても、運用現場での例外ケースを見落とすと、
データ整合性が一気に崩れることがあります。
特に、同一商品でJANが複数存在したり、未発行JANや廃番JANが混在したりするケースは、
システム的にも人的にもトラブルの温床になりやすいポイントです。

ここでは、マスタ統一を運用段階で守り続けるための「3つの落とし穴と対策」を整理します。

---

H3-1　同一商品に複数JANが付くケースの扱い

メーカーや販売チャネルによっては、同じ商品に複数のJANコードが存在することがあります。

代表的なケース

• OEM供給先ごとに別JANを発行している
• ECモール専用・店舗限定で別JANを割り当て
• 旧パッケージと新パッケージでJANが異なる

これらを単純に「別商品」として登録してしまうと、
在庫・販売履歴が分断され、正しいトータル分析ができなくなります。

✅ 対策：マスタ上で「代表SKU」を決め、JANを紐づける

1つのSKUに対して、複数のJANを紐づけられる構造（1対多）を採用します。
これにより、販売集計・在庫管理はSKU単位で一元化し、JANの差分は属性として保持できます。

SKUコード	JANコード	用途
A001-BL-M	4581234567890	通常流通用
A001-BL-M	4900000001111	EC限定JAN
A001-BL-M	4979999002222	旧パッケージ

運用ルールとしては、

• SKUを絶対基準に集計・在庫引当を行う
• JANは「外部出荷・受注時の照合キー」として使う
• 代表JANを決め、システム登録時は常に紐づけておく

このように設計することで、複数JANを持つ商品でも在庫管理が安定します。

---

H3-2　JAN未発行商品（自社製造・限定商品）の登録ルール

小規模メーカー・自社製造品・イベント限定品など、JANコードが発行されない商品も少なくありません。
こうした商品を扱う場合、JANを空欄のまま登録すると、他システムとの連携や販売履歴が不安定になります。

✅ 対策：社内コードで“仮JAN”を生成し、一貫して管理

JAN未発行商品には、以下のようなルールで「仮JANコード」を発行します。

区分	仮JANの形式例	備考
自社製造品	999＋SKUの下7桁（例：9990001234）	既存JANと重複しないルールを明示
限定商品	998＋SKUコード連番	期間限定品などに活用
サンプル・販促物	997＋内部管理コード	外部販売不可の識別用

これにより、POS・受注システム・在庫管理がすべて同じ形式で連携でき、
JAN未発行商品でも通常商品と同じロジックで処理が可能になります。

💡 仮JANを発行する場合は、必ず「仮JAN管理表」を別途設けておき、
後日正式JANが付与された際には紐づけ更新できるようにしておきましょう。

---

H3-3　古いJAN・廃番商品の扱いと履歴管理

マスタ統一を長期間維持するうえで、廃番やリニューアルに伴うJAN更新も大きな落とし穴です。

「古いJANを削除」してしまうと、過去の販売・在庫データとの整合が取れなくなり、
分析・返品処理・会計連携に支障が出ます。

✅ 対策：廃番商品も“無効化管理”で履歴を残す

削除ではなく、状態フラグを設定してアクティブ／非アクティブ管理を行うのが理想です。

SKUコード	JANコード	商品名	状態	廃番日	備考
A001-BL-M	4581234567890	Tシャツ Mサイズ	active	–	現行品
A001-BL-M	4900000001111	Tシャツ Mサイズ（旧パッケージ）	inactive	2025/10/01	統合済み
A002-WH-L	4581234000001	Tシャツ Lサイズ	inactive	2024/12/31	廃番商品

この方法なら、過去の受注履歴や売上データと照合しても矛盾が発生せず、
販売分析や返品対応もスムーズに行えます。

❗️削除ではなく「無効化」

データを消すのではなく、“販売終了”としてステータスを更新すること。
これが、履歴一貫性を守る最大のポイントです。

---

💡まとめると：

• 複数JANは「1SKUに多JAN紐づけ」で統一
• JAN未発行品は「仮JANルール」で連携を安定化
• 廃番JANは削除せず「非アクティブ管理」で履歴を保持

この3つの運用ルールを守ることで、商品マスタは“生きたデータベース”として機能し、
在庫・受注・販売履歴の信頼性を長期にわたって保つことができます。

---

H2-6　まとめ｜JANと社内コードを整理すれば在庫は“ひとつの真実”に

商品マスタの混乱は、在庫管理の信頼性を直撃します。
JANコードと社内コードを正しく整理し、役割を明確に分けることで、
企業内の在庫データは初めて「ひとつの真実（Single Source of Truth）」になります。

本記事で紹介してきた通り、SKUを基軸にしたマスタ統一は、
単なるコード管理ではなく、全社的な在庫精度を守る仕組みそのものです。

---

H3-1　コード体系の統一が在庫精度を左右する

在庫精度を下げる最大の原因は「同じ商品を複数のコードで管理すること」です。
重複登録・JAN変更・別担当による命名ブレ——これらはすべて在庫ズレの温床になります。

コード体系を統一すると、次のような効果が得られます。

• 在庫が即時に正しく反映される
• 販売・仕入・会計が同じ基準で動く
• EC・POS・倉庫システムが自動で同期できる

特に中小企業では、現場担当の判断で商品登録が行われがちですが、
「SKU命名ルール」と「JAN⇔SKU変換表」が整備されていれば、
システム任せでも整合性を維持できます。

在庫精度はシステムの精度ではなく、コード体系の一貫性で決まります。

---

H3-2　SKUを主軸に据えた商品マスタが最も安定する

在庫管理の中核は、JANではなく**SKU（社内コード）**です。
SKUは自社内で定義するため、どんな商品にも柔軟に対応でき、
色・サイズ・セット・販路別といった現場単位での最適化が可能です。

JANを基準に設計すると、次のような制約が生まれます：

• JAN未発行品が登録できない
• 同一商品で複数JANが存在する場合に在庫が分断
• 廃番やパッケージ変更時に履歴が切断

一方、SKUを主軸に据えれば：

• 在庫・販売履歴をSKU単位で一元管理
• JAN更新や販路違いにも柔軟に対応
• 分析・棚卸・EC連携がスムーズに連動

つまり、SKUは「在庫精度の軸」であり、
JANは「外部とつながるための窓口」にすぎません。

この考え方を徹底すれば、どんな業態でも在庫の“ぶれ”が減り、
管理負担が大幅に軽減されます。

---

H3-3　関連記事リンク

💡最終まとめ：

• JAN＝流通と共有する識別子
• SKU＝社内の在庫を守る識別子
• 変換テーブルとマスタ統一ルールが、“データの真実”を保証する

これで「JANコードと社内コードの使い分け方｜商品マスタ統一のベストプラクティス」記事が完全版として仕上がりました。