SKU
SKU（Stock Keeping Unit）とは、小売業者が特定の商品バリアントに割り当てる一意の英数字コードであり、在庫、販売、フルフィルメントを通じて商品を追跡するために使用されます。UPCやバーコードとは異なり、SKUは企業内部で使用され、サイズ、色、倉庫の場所などの属性をエンコードできます。販売可能な商品の個々のバリエーションには、それぞれ独自のSKUが割り当てられます。
SKUの定義
SKU（Stock Keeping Unit） とは、企業が在庫、発注、販売システムを通じて販売可能な特定の商品バージョンを追跡するために作成する一意の識別子です。パーカーが3色×4サイズで展開されている場合、それは12のSKUになります。なぜなら、各組み合わせを個別にカウント、価格設定、再発注する必要があるからです。SKUは商品名やリスティングと同じものではありません。1つの商品に多くのSKUが存在する可能性があり、顧客が実際に選択して購入できるバリアントごとに1つのSKUがあります。SKUはそれを作成した企業内部で使用されるものであり、外部機関（GS1）によって割り当てられ、その商品を販売するすべての小売業者間で共有される標準化されたコードであるUPCやEANとは区別されます。したがって、小売業者は卸売りで購入した商品に対して独自のSKUを作成し、メーカーのバーコードの上に内部コードを重ねることで、自社の倉庫やレポートシステムが一貫して追跡できるようにします。
SKUコードの構造
SKUの形式に関する普遍的な基準は存在せず、これは強みであると同時に混乱の一般的な原因でもあります。多くの販売業者は、倉庫やレポートの目的に重要な属性（カテゴリ、商品ライン、色、サイズなどが一般的な構成要素）をエンコードした短い英数字文字列を構築します。典型的なパターンは、黒・LサイズのクルーネックTシャツに対するTSH-CREW-BLK-Lや、12オンスのセラミックマグに対するMUG-CER-12OZのようになります。適切なSKU設計にはいくつかのルールがあります。コードの長さを統一して視覚的にスキャンしやすく、スプレッドシートでソートしやすくすること、CSVインポートやURLスラッグを壊す可能性のあるスペースや特殊文字を避けること、倉庫のピッカーがコードだけで商品を認識でき、調べる必要がない程度にコードを読みやすくすることです。一部の企業では、プラットフォームが自動生成する連続番号のSKU（10001、10002…）を使用し、可読性と引き換えに一意性を保証しています。どちらのアプローチでも、一貫して適用される限り機能します。失敗のパターンは通常、一貫性の欠如です。つまり、ある商品ラインは手動でコード化され、別のラインは自動生成され、両者の間に共通のロジックがない状態です。
EコマースにとってSKUレベルの追跡が重要な理由
SKUの粒度こそが、在庫管理を可能にするものです。商品レベルでの集計在庫数は、あるバリアントが売り切れている一方で別のバリアントが過剰在庫であるという事実を隠してしまいます。ストアには「Tシャツ：在庫あり」と表示されている一方で、実際に売れているサイズが2週間もバックオーダー状態になっているかもしれません。SKUレベルの追跡は、発注点の計算にも不可欠です。同じシャツでもMサイズとXLサイズでは販売速度が異なり、異なる再発注トリガーが必要だからです。在庫を超えて、SKUは利益率分析のための自然な結合キーでもあります。SKUにランディングコスト（単価、輸入運賃、包装費）が紐付けられると、各注文明細を実際のコストに結びつけることができ、収益と収益性を倉庫が在庫管理に使用するのとまったく同じ粒度でレポートできます。SKUレベルのコストデータがなければ、収益性レポートは注文レベルの平均値に頼らざるを得ず、高利益率の商品と損失覚悟の商品が混ざり合い、どのSKUを実際に販売促進すべきかがわからなくなります。
SKU vs UPC vs 商品ID
| 識別子 | 割り当て者 | 範囲 | 一般的な用途 |
|---|---|---|---|
| SKU | 小売業者またはブランド自身 | 1社の内部 | 在庫、再発注、内部レポート |
| UPC / EAN | GS1（外部標準化団体） | グローバル、全販売者間で共有 | POSスキャン、マーケットプレイス出品 |
| 商品ID / ASIN | プラットフォーム（例：Amazon、Shopify） | そのプラットフォームの内部 | 単一チャネル内のカタログ管理 |
| バリアントID | Eコマースプラットフォームのデータベース | ストアのバックエンド内部 | 技術的な参照、顧客にはほとんど表示されない |
1つの物理的な商品がこれら4つすべてを同時に持つことができます。メーカー割り当てのUPC、小売業者割り当てのSKU、マーケットプレイス割り当てのASIN、プラットフォーム割り当てのバリアントIDです。マルチチャネル販売業者は通常、これらを調整するマッピングテーブルを必要とします。これにより、Amazonでの販売もShopifyストアフロントでの販売も、レポート上で同じ基盤となるSKUに集約されます。
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
SKUデータとAI駆動型コマース
ショッピングがChatGPT Shopping、Perplexity Shopping、AmazonのRufusなどのAIアシスタントを通じて行われることが増えるにつれて、これらのシステムに在庫状況、価格、バリアント情報を伝える構造化データである商品データフィードは、その基盤としてクリーンなSKUレベルのデータに依存しています。「青のMサイズ」を推奨するAIショッピングアシスタントは、基盤となるフィードがその情報を一般的な商品リスティングではなく、実際の在庫と価格を持つ実際のSKUに解決できる必要があります。乱雑または重複したSKUは、商品フィードがこれらのチャネルで拒否されたり誤って表示されたりする一般的な原因です。分析面では、AmICitedのeshop_get_productsやeshop_list_product_costsレポートなどのツールは、収益性の質問に実際に回答できるレベルがSKU単位だからこそ、SKUの粒度で動作します。「この商品のどのバリアントを在庫として保持すべきか」は、SKUレベルの質問であり、商品名レベルの質問ではありません。収益と利益率を商品タイトルではなくSKU単位でレポートすることで、黒のMサイズが40％の利益率で販売されている一方で、同じ「商品」であるにもかかわらず、ネオングリーンのXXLがほぼ採算が取れていないことを販売業者は把握できます。
SKU管理のベストプラクティス
- 複数のチャネルに出品する前に、バリアントごとに1つの正規SKUを確立し、すべてのチャネル固有IDをそれにマッピングする
- SKUコードは短く、長さを統一し、スペースや特殊文字を含めない
- 各SKUに販売価格だけでなくランディングコストを紐付け、利益率が自動計算できるようにする
- 廃止されたSKUを新しく無関係な商品に再利用しない — 過去のレポートが両者を混同することになる
- 重複または類似したSKU（手動スプレッドシート編集の一般的な結果）を定期的に監査する
- 注文、返品、コストシートなど、すべてのエクスポートにSKUを含め、データセットが常に結合できるようにする
よくあるSKUの間違い
よくある問題は、レポートにおいて「商品」と「SKU」を互換的に扱うことであり、これにより在庫数や利益率の数値は集計上は問題なく見えるものの、好調なバリアントの陰に不調なバリアントが隠れてしまいます。修正方法は、すべてのレポート（売上、在庫、コスト）をSKUレベルで生成し、商品レベルへの集約は表示の便宜のためだけに使用し、基盤となる計算として使用しないことです。もう1つの一般的な問題は、販売チャネル間でのSKUの乖離です。販売業者がPOSシステムで1つのSKU体系を作成し、Eコマースプラットフォームが別の体系を自動生成し、マーケットプレイスの出品では3つ目の形式が表示されるため、手動でマッチングすることなく特定のバリアントの総売上を確実に照合する方法がなくなります。標準的な修正方法は、中央で管理されるマッピングテーブルを維持することです。理想的には、レポートを行うプラットフォーム内に保持し、そのたびにスプレッドシートでアドホックに再作成するのを避けます。3つ目の間違いは、商品が廃止されて代替品に置き換えられたときにSKUを再利用することです。新しい製品やリデザインに古いSKUを割り当てると、過去のトレンドデータが曖昧になり、明確な前後比較ができず、同じ商品のパフォーマンスが突然変化したかのように見えてしまいます。最後に、多くの小規模販売業者は各SKUに実際のランディングコストを紐付けることを省略し、代わりにカタログ全体にわたって一律の推定利益率をデフォルトで使用します。これによりSKUレベルの収益性レポートは技術的には可能ですが、実際には誤解を招きやすく、最も好調なバリアントと最も不調なバリアントの実際の差を明らかにすることができません。