楽天のSKUとは？SKUプロジェクトで店舗運営がどう変わるかを解説

楽天のSKU（Stock Keeping Unit）とは、在庫管理の最小単位のことです。カラーやサイズなど、バリエーションのひとつひとつが1SKUにあたります。そして「楽天SKUプロジェクト」とは、これまで「商品ページ単位」で行っていた商品情報の管理を「SKU単位」へと転換する、楽天市場の構造改革です。この移行によって、在庫数・価格・カタログID・画像などが、商品ページの中の一つひとつのSKUごとに個別に持てるようになります。

つまり、これまで「1つの商品ページ＝1つの在庫・価格の器」だったものが、「1つのページの中に、それぞれ独立した在庫や価格を持つ複数のSKU」を抱える構造へと変わります。店舗運営の観点では、在庫・価格・受注データを扱う単位がすべてSKUベースに切り替わる、という点が本質です。この記事では、用語の意味から自店で今なにを確認すべきかまでを、楽天市場の出店者目線で整理します。

楽天のSKUとは？（Stock Keeping Unit＝在庫管理の最小単位を1分で）

SKUは「Stock Keeping Unit（ストック・キーピング・ユニット）」の略で、日本語では「在庫管理の最小単位」と訳されます。ECや小売の現場で古くから使われてきた言葉で、楽天に限らず在庫を数えるときの一番細かい単位を指します。

具体例で考えると分かりやすくなります。あるTシャツを、次の組み合わせで販売しているとします。

• カラー：ホワイト／ブラック／ネイビー／レッド（4色）
• サイズ：S／M／L／XL（4サイズ）

このとき、商品としては「1種類のTシャツ」ですが、実際に在庫として区別すべき組み合わせは 4色 × 4サイズ ＝ 16通りあります。この16通りの一つひとつがSKUです。「ホワイトのM」と「ブラックのM」は別のSKUであり、それぞれ在庫数を分けて管理する必要があります。

ここで押さえたいのは、「商品ページの数」と「SKUの数」は別物だという点です。商品ページが1つでも、その中に16のSKUが含まれることがあります。従来の楽天では、この細かい単位を「項目選択肢」という仕組みで表現していましたが、SKUプロジェクトによって「SKU」という単位そのものが正式に管理の中心に据えられました。

楽天SKUプロジェクトとは？何のための仕組みか

楽天SKUプロジェクトとは、商品管理の単位を「商品ページ単位」から「SKU単位」へ転換する、楽天市場全体の構造改革です。楽天の案内によると、SKU単位での商品登録・データ保持を可能にすることで、検索での見つけやすさを高め、1つの商品ページの中で入数違いや重さ違いといった「価格の違うバリエーション」を表示できるようにする、という狙いがあります。

なぜこの改革が行われるのか。背景には、従来の「商品ページ単位」の管理では表現しきれない販売形態が増えてきたことがあります。たとえば「同じ商品の10個入りと20個入り」を売りたい場合、これまでは価格が違うため別々の商品ページを作る必要がありました。SKU単位になると、1つのページの中で「10個入り＝◯円／20個入り＝◯円」と価格差をつけて登録できます。買い手にとっては1ページで比較・選択が完結し、店舗にとってはページの分散を防げます。

このプロジェクトは、一部の店舗だけの話ではなく、楽天市場に出店する全店舗を対象にした取り組みです。「用語が新しくなった」という表面的な変更にとどまらず、在庫・価格・受注データの持ち方という運営の土台に関わるため、出店者としては仕組みを理解しておく必要があります。

従来の「項目選択肢別在庫」と「SKU（バリエーション設定）」は何が違う？

SKUプロジェクトを理解するうえで避けて通れないのが、従来の「項目選択肢別在庫」と、新しい「バリエーション設定」の違いです。名称だけでなく、設定できる内容や上限が変わっています。複数の解説メディアで共通して挙げられている差分を、表で整理します。

ここで注意したいのは、単なる「呼び名の変更」ではないという点です。「項目選択肢別在庫」から「バリエーション設定」への移行は、扱える軸の数やSKU数の上限が大きく広がる一方で、後述するカタログIDの必須化やCSV仕様の変更など、店舗側で対応が必要な変化を伴います。この違いを「仕様が拡張された」とだけ捉えると、移行後の実務でつまずくことがあります。

SKU移行で変わる6つのポイント

SKUプロジェクトへの移行で具体的に変わる主なポイントを、6つに整理します。

1. 管理単位がSKU単位になる：商品ページ単位から、ページ内の一つひとつのSKU単位へ。在庫・価格・受注データの基準がSKUに変わります。
2. バリエーションが最大6軸・最大400SKUに拡張：従来の最大2軸から6軸へ。最大40選択肢・最大400SKUまで設定でき、複雑な組み合わせも1ページで扱えます。
3. 検索結果にSKUバリエーションが表示される：検索画面上でバリエーションを確認できるようになり、買い手がより少ないステップで目的の商品にたどり着けます。
4. カタログID（JAN等）が必須化：後述のとおり、全商品でカタログIDの入力が必要になります。
5. 商品属性がSKUレベルで設定できる：項目・値・単位の組み合わせを、SKUごとに設定できる仕様になります。
6. CSV仕様が変わる：登録用と更新/削除用が分離し、SKUレベルの属性列が追加されます。既存の一括更新フローやテンプレートは作り直しが必要になる場合があります。

この6点のうち、2〜3は「メリット（できることが増える）」、4〜6は「対応が必要になる変化」という性質を持ちます。両面をセットで押さえておくと、移行の全体像がつかみやすくなります。

在庫・価格・バリエーション管理はこう変わる

SKU単位への移行で、日々の在庫・価格・バリエーション管理は具体的にどう変わるのでしょうか。

まず在庫です。移行後は、SKUごとに個別の在庫数を管理することになります。カラー3色 × サイズ3種で9SKUの商品なら、9つの在庫数をそれぞれ持ち、それぞれを更新していく形です。組み合わせが多い商品ほど管理すべき在庫数が増えるため、手作業での更新はミスが起きやすくなります。CSVによる一括更新や、外部システムとのAPI連携で在庫を同期する運用が現実的な選択肢になります。

次に価格です。前述のとおり、SKU単位になると1つの商品ページの中で価格の違うバリエーションを表示できます。たとえば「入数違い」「重さ違い」「サイズ違い」で価格が異なる商品を、ページを分けずに登録できるようになります。これにより、これまで価格差のために複数ページに分けていた商品を1ページに集約でき、ページの分散による評価やレビューの分散を避けやすくなります。

バリエーション設定そのものも、最大6軸・最大400SKUという上限に広がるため、これまで表現できなかった複雑な組み合わせを扱えるようになります。ただし、扱える幅が広がることは、登録・更新すべきデータ量が増えることでもあります。「できることが増えた」ぶん、日々の管理工数も増えうる、という点はあらかじめ見込んでおくとよいでしょう。

移行は必須？任意？期限はあるのか

「SKUプロジェクトへの移行は、やらなければいけないのか」は、多くの出店者が気にする点です。ここは正確に押さえておきたいところです。

規約上、移行は強制ではなく、位置づけとしては任意です。とはいえ、実務上は早期の移行が推奨される、というのが各メディアで共通した見方です。理由は、未移行のページが検索表示や購買体験の面で不利になりやすく、中長期的には売上への影響が出うるためです。この意味で「規約上は任意だが、事実上は推奨」と理解しておくのが実態に近いといえます。

移行のスケジュールについては、2023年4月から全店舗を対象に順次進められてきました。移行のタイミングは店舗ごとに異なり、RMS（楽天の店舗管理システム）を通じて各店へ通知される仕組みです。そのため「全店一律の締切日」というよりは、店舗ごとに案内される個別のスケジュールに沿って進む形になります。

なお、「移行の締切そのもの」については、明示されていないとする記述と、実質的にほぼ全店が移行済みとする記述の両方が見られます。ここは店舗によって状況が異なりうるため、自店の最新の移行状況・必須化の状況は、RMS内のお知らせで直接確認することをおすすめします（これは事実の断定ではなく、確認の推奨としてお読みください）。

移行後にやるべき必須対応

移行そのものが完了したあとにも、店舗側で対応すべきことがあります。代表的なのがカタログIDと商品属性です。

まずカタログID（JANなどの製品コード）です。従来は「項目選択肢別在庫」や「セット商品」であることを理由に、カタログIDを「なし」にできる余地がありました。しかしSKU移行後は、その理由での「なし」は認められず、全商品でカタログIDの入力が必要になります。複数のメディアでは、移行後およそ半年（約180日）の猶予期間内に入力が必要で、必須属性が未入力のままだと商品情報の更新ができなくなる、と説明されています。

ただし、この「約180日（半年）」という猶予日数や、必須とされる属性の範囲は、公式の告知で更新される可能性があります。この日数はあくまで複数メディアで一致している数字であり、最新の正確な期限は、RMS内のお知らせで必ず確認してください。

もう一つが必須商品属性の入力です。SKU単位の管理では、商品属性を項目・値・単位の組み合わせで設定でき、その中に入力が必須となる属性が含まれます。必須属性が埋まっていないと、以降の商品情報の更新に支障が出る場合があるため、移行後は早めに整えておくのが安全です。

なお、一部のメディアでは「レビューの付け替え申請の期限」に関する記述（例として過去の期限日）も見られましたが、今回の調査では公式の一次情報で再確認できませんでした。すでに過ぎた期限である可能性が高く、現在の店舗には無関係なケースもあるため、この点についても最新情報はRMS内のお知らせで確認してください。

SKU移行のメリット

SKU移行には、対応の手間がかかる一方で、店舗と買い手の双方にメリットがあります。主なものを挙げます。

• 検索性の向上：検索結果にSKU単位のバリエーションが表示されるようになり、買い手が探している組み合わせを見つけやすくなります。
• 回遊・購買体験の改善：1つのページの中で価格違い・バリエーション違いを比較・選択でき、少ないステップで購入まで進めます。ページを行き来する手間が減ります。
• レビュー・評価の集約：価格差のために複数ページに分けていた商品を1ページに集約できるため、レビューや評価が分散しにくくなります。
• ページ運用の効率化：入数違い・サイズ違いなどを1ページで扱えるため、似た商品ページが乱立するのを抑えられます。

これらは「買い手にとっての分かりやすさ」と「店舗にとってのページ整理」の両面に効きます。特に、同一商品で細かなバリエーションを多く抱える店舗ほど、集約による恩恵を受けやすい構造です。

SKU移行のデメリット・注意点

一方で、移行に伴うデメリットや注意点も現実的に存在します。メリットとあわせて把握しておくと、対応の優先順位を判断しやすくなります。

• 作業量が増える：SKUごとに在庫・価格・属性を持つため、登録・更新すべきデータ量が増えます。組み合わせの多い商品ほど負荷が大きくなります。
• CSV仕様の変更：登録用と更新/削除用が分離し、SKUレベルの属性列が追加されました。従来の一括更新フローやCSVテンプレートは、そのままでは使えず作り直しが必要になる場合があります。
• URL・商品番号への影響：移行に伴い、商品ページのURLや商品番号の扱いに変化が生じることがあります。外部からのリンクや、広告・SNSに貼っている遷移先の確認が必要になる場合があります。
• 外部ツールの更新が必要：後述のとおり、受注・在庫の一元管理ツールなどは、連携設定の更新をしないと在庫ズレなどの不具合が起きえます。

とくに実務で見落とされやすいのがCSV回りの落とし穴です。SKU単位の一括更新では、カタログIDの桁落ち、属性値の妥当性エラー、ジャンルID変更時に属性の同時更新が必要になる、といったつまずきが起きやすくなります。移行後にいきなり全商品を一括更新するのではなく、少数の商品でCSVの通し確認をしてから広げる、という進め方が安全です。

受注・在庫管理システム（OMS/API）への影響と対応

自店で受注・在庫の一元管理ツール（OMS）や、API連携による在庫同期を使っている場合、SKUプロジェクトの影響は特に注意が必要です。

背景として、楽天のCSV仕様がSKU単位に変わったことで、外部ツールと楽天のあいだでやり取りするデータの形式が変わりました。主要な一元管理ツールはSKUに対応済みとされていますが、ツールが対応していることと、自店の連携設定が正しく更新されていることは別の話です。店舗側で連携設定の更新を行わないと、在庫数が正しく同期されず、在庫ズレ（実在庫と表示在庫の食い違い）が発生するおそれがあります。

在庫ズレは、売り越し（在庫がないのに注文が入る）や機会損失（在庫があるのに売り切れ表示になる）に直結するため、移行のタイミングで見落とすと影響が大きい領域です。対応の目安としては、次を確認しておくとよいでしょう。

1. 利用中のOMS・在庫管理ツールがSKU（バリエーション設定）に対応しているか
2. 楽天とツールの連携設定を、SKU仕様に合わせて更新済みか
3. 移行直後に、少数の商品で在庫数が正しく同期されているかを実データで確認したか

外部ツールを使わず手作業で在庫を管理している店舗でも、SKU数が増えるぶん更新箇所が増えるため、CSV一括更新やAPI連携への切り替えを検討する余地があります。

まとめ：出店者が今すぐ確認すべきチェックリスト

最後に、楽天市場の出店者が確認しておきたい項目を、チェックリストの形で整理します。

• [ ] 自店の移行スケジュール／移行状況を、RMS内のお知らせで確認したか
• [ ] カタログID（JAN等）が全商品で入力されているか（未入力の商品はないか）
• [ ] 必須の商品属性が埋まっているか
• [ ] カタログID・必須属性の猶予期間（約180日とされるが最新はRMSで要確認）を過ぎていないか
• [ ] CSVの一括更新フロー・テンプレートを新仕様に合わせて作り直したか
• [ ] 利用中のOMS・在庫管理ツールがSKU対応済みで、連携設定を更新したか
• [ ] 移行後に在庫数が正しく同期されているかを、少数の商品で実データ確認したか
• [ ] URL・商品番号の変化が、外部リンクや広告の遷移先に影響していないか

SKUプロジェクトは「用語の変更」ではなく、在庫・価格・受注データを扱う単位そのものの転換です。移行の可否だけでなく、移行後にカタログIDやCSV、外部ツールで何を整えるかまで見ておくと、在庫ズレや更新エラーといった実務事故を避けやすくなります。日数や必須化の範囲は変わりうるため、確定した数字はRMS内のお知らせで直接確かめる、という前提で進めるのが安全です。

よくある質問（FAQ）

Q. SKUとは何ですか？ A. Stock Keeping Unit（在庫管理の最小単位）の略です。カラー・サイズなどバリエーションごとの1単位を指し、4色×4サイズなら16SKUになります。

Q. 楽天SKUプロジェクトへの移行は必須ですか？ A. 規約上は強制ではなく任意ですが、未移行だと検索表示や購買体験の面で不利になりやすいため、実質的には早期移行が推奨されています。2023年4月から店舗ごとに順次移行が進んでいます（最新状況はRMSで確認してください）。

Q. 「項目選択肢別在庫」はどうなりますか？ A. 移行後は「バリエーション設定」に名称・仕様が変わります。最大6軸・最大400SKUまで設定でき、価格違いのバリエーションを個別に登録できるようになります。

Q. 移行後にやらなければいけないことは何ですか？ A. カタログID（JAN等）の入力が全商品で必須化され、必須の商品属性の入力も必要になります。移行後およそ半年（約180日）の猶予期間を過ぎると商品情報の更新ができなくなる場合があるとされていますが、正確な期限はRMS内のお知らせで確認してください。

Q. 在庫管理システムはそのまま使えますか？ A. 主要なOMSはSKUに対応済みとされていますが、楽天のCSV仕様が変わったため、店舗側で連携設定の更新が必要です。更新しないまま運用すると在庫ズレが発生するおそれがあります。

参考

• 楽天RMS SKU案内（Gold）: https://www.rakuten.ne.jp/gold/rms/sku/
• 楽天RMSマニュアル SKU（店舗ログイン制）: https://navi-manual.faq.rakuten.net/rms/sku
• 株式会社いつも: https://itsumo365.co.jp/blog/post-19316/
• ジャグー: https://jagoo.co.jp/column/rakuten-skuproject/
• ファイブスプリングス: https://www.5springs.co.jp/blog/sku-project/
• Finner: https://finner.co.jp/media/ec20230905a/
• コマースピック: https://www.commercepick.com/archives/39899
• ECのミカタ: https://ecnomikata.com/ecnews/ecmall/44371/
• stockcrew: https://stockcrew.co.jp/insights/rakuten-sku-inventory-logistics