楽天SKUプロジェクト移行後の在庫管理・物流最適化｜商品属性登録・倉庫指定・WMS連携の実務

楽天SKUプロジェクトとは — 移行後に残る3つの課題

楽天SKUプロジェクトは、従来の「商品ページ単位」の管理体系を「SKU（Stock Keeping Unit）単位」に転換する楽天市場の構造改革です。2023年4月に開始され、店舗ごとに段階的な移行が進みました。移行後の仕組みでは、たとえばカラー3色×サイズ3種のTシャツは「9 SKU」として個別に在庫・価格・画像を管理できるようになり、最大6軸のバリエーション設定が可能になっています。

SKUプロジェクトの主な変更点

移行完了後に残る3つの課題

多くの店舗は「商品属性の登録」と「バリエーション設定の移行」を終えた段階です。しかし、以下の3つの課題が未対応のまま残っているケースが多く見られます。

1. 在庫管理の粒度変更への対応——商品ページ単位でざっくり管理していた在庫を、SKU単位で正確に追跡する運用への切り替えが必要です。とくに複数モールで販売する場合、モール間の在庫同期がSKU単位に変わるため、ズレが生じやすくなります。
2. SKU倉庫指定の未活用——移行後に使えるようになった「SKU倉庫指定」機能を活用している店舗は少数です。この機能を使えばSKUごとに出荷倉庫を切り替えられるため、複数拠点での在庫分散が柔軟に設計できます。
3. 外部システム（WMS・OMS・発送代行）との連携不備——CSV仕様の変更により、既存のデータ連携フローが動かなくなるケースがあります。とくに発送代行を利用している店舗では、SKU体系と倉庫側のSKUマッピングの整合性確認が必要です。

2024年の日本国内のBtoC-EC（消費者向け電子商取引）市場規模は、26.1兆円（前年24.8兆円、前々年22.7兆円、前年比5.1%増）に拡大しています。また、2024年の日本国内のBtoB-EC（企業間電子商取引）市場規模は514.4兆円（前年465.2兆円、前々年420.2兆円、前年比10.6%増）に増加しました。

出典：経済産業省「令和6年度 電子商取引に関する市場調査の結果を取りまとめました」（2025年8月）

SKU移行で変わる在庫管理の5つのポイント

SKUプロジェクトの移行後、在庫管理の実務で具体的に何が変わるのかを5つのポイントに整理します。「何となく移行した」状態から「SKU単位の在庫管理を使いこなす」状態へ引き上げるための確認リストとして活用してください。

ポイント1：SKU単位の在庫数管理

移行前は商品ページ単位で「在庫あり/なし」を切り替える運用が可能でしたが、移行後はSKUごとに個別の在庫数を設定・管理する必要があります。カラー×サイズで9SKUある商品なら、9つの在庫数をそれぞれ正確に入力しなければなりません。手動更新ではミスが発生しやすいため、CSVの一括更新やAPI連携による自動化が現実的な解決策になります。

ポイント2：商品属性の正確な登録

移行日から180日以内が商品属性登録のガイドライン適用に向けた準備期間とされ、未登録のまま181日目以降に入ると罰則加点（ペナルティ）の対象になり得ます。属性情報は楽天内検索のフィルタリングに使われるため、正確かつ網羅的な登録がSEO面でも重要です。「ブラック」「黒」「BK」のような表記揺れは検索漏れの原因になるため、自社内で属性値の命名規則を統一してください。

ポイント3：マルチモール在庫同期のSKU対応

楽天市場とAmazon・Yahoo!ショッピング・自社ECを並行運営している店舗では、在庫同期のSKUマッピングを見直すことが欠かせません。楽天のSKU体系が変わったことで、既存の在庫連携ツール（OMS・一元管理ツール）が正しくSKUを紐づけられなくなるリスクがあります。ネクストエンジンやCROSS MALLなどの主要OMSは楽天SKUプロジェクトに対応済みですが、連携設定のアップデートを店舗側で行っていない場合は在庫ズレが生じます。とくにAmazonと楽天では同じ商品でもSKUコードの付け方が異なるため、モール横断のSKU対応表を一度整備しておくと、その後の同期トラブルを大幅に減らせます。

ポイント4：SKU単位の販売実績分析

SKU移行後は、商品ページ単位ではなくSKU単位で売上・転換率（CVR）・在庫回転率を分析できるようになります。「Tシャツ」の売上を見るだけでなく「Tシャツ×ブラック×Mサイズ」の売れ行きを個別に追跡できるため、死に筋SKUの早期発見と在庫圧縮が可能になります。SKU設計の基本的な考え方と採番ルールについては商品コード・SKU設計の実務ガイドで体系的に解説しています。

ポイント5：CSV仕様変更への対応

SKU移行後のCSVは「登録・更新用CSV」と「削除用CSV」に分離されました。従来のコントロールカラム方式は廃止されており、既存のCSVテンプレートやマクロをそのまま使うとエラーになる可能性があります。とくに発送代行にCSV連携でデータを送っている店舗は、CSV項目のマッピングを更新する必要があります。EC物流におけるCSV連携とAPI連携の違いについてはEC物流のAPI連携とCSV連携の違いを解説を参照してください。

SKU倉庫指定を活用した物流最適化

SKUプロジェクト移行後に追加された「SKU倉庫指定」は、物流コストの最適化に直結する機能です。従来は商品ページ単位でしか出荷倉庫を指定できませんでしたが、移行後はSKU単位で倉庫を切り替えられるようになりました。

SKU倉庫指定の活用シナリオ

SKU倉庫指定が効果を発揮する代表的なシナリオを3つ紹介します。

STOCKCREWとの組み合わせ設計

SKU倉庫指定を活用する際、楽天以外のモールにも対応した発送代行を組み合わせると物流設計の自由度が大幅に向上します。STOCKCREWは初期費用0円・固定費0円の完全従量課金で、楽天・Amazon・Yahoo!・Shopifyの出荷を1拠点から一元管理できます。

• 楽天以外のモール出荷に追加料金なし——RSLでは2025年6月の値上げ以降、他モール出荷に追加料金が発生するようになりました。STOCKCREWはモール不問の一律料金です
• SKU単位の在庫管理に対応——WMS上でSKUごとの入出庫・在庫数をリアルタイムに管理。楽天のSKU体系とのマッピングもスムーズに行えます
• AMR 110台による自動化——SKU数が増えてもピッキング効率を維持できる倉庫オペレーション

RSLとSTOCKCREWの料金・サービスを全8サイズで比較した記事はRSLとSTOCKCREWを徹底比較【2026年版】にまとめています。楽天出店者の物流設計全般は楽天市場×発送代行の実務ガイドで解説しています。

どのSKUをどの倉庫に置くかの判断軸

SKU倉庫指定を使いこなすうえで悩みやすいのが、「どのSKUをどの倉庫へ振り分けるか」という配置の設計です。判断軸はおおむね3つに整理できます。1つ目は出荷頻度で、回転の速い売れ筋SKUほど出荷効率の高い倉庫・ゾーンに集約すると、ピッキングの移動距離を短縮できます。2つ目はサイズと重量で、かさばる大型SKUは保管単価の安い地方倉庫へ、小型で出荷の多いSKUは消費地に近い拠点へ置くと、保管費と配送費のバランスが取りやすくなります。3つ目は販売チャネルで、楽天専用の主力SKUはRSL、複数モールで共通して売るSKUは外部3PLへ寄せると、モールごとの送料・手数料の最適化につながります。

これらの軸は固定ではなく、シーズンやセールのたびに売れ筋が入れ替わるため、SKU別の販売実績を見ながら定期的に配置を見直すことが効果を高めます。配置のルールを社内で明文化しておくと、担当者が替わっても同じ基準で運用を続けられます。

WMS・OMS・発送代行との連携設計

SKUプロジェクトの移行は、楽天RMS内の設定変更だけでは完結しません。外部のWMS（倉庫管理システム）・OMS（受注管理システム）・発送代行とのデータ連携フローを見直すことが欠かせません。連携は次の3層で考えると整理しやすくなります。

連携設計の確認チェックリスト

以下のチェックリストに沿って、自社の連携状況を確認してください。

1. OMS/一元管理ツールのSKU対応バージョンを確認——ネクストエンジン・CROSS MALL・GoQSystem等の主要OMSは楽天SKU対応済みですが、バージョンアップが必要な場合があります。設定画面でSKU連携が有効になっているか確認してください
2. SKUマッピングの整合性を検証——楽天RMS上のSKU IDと、WMS/発送代行側の商品コードが正しく紐づいているかをテスト出荷で検証します。マッピングミスは誤出荷の原因になります
3. 在庫同期の頻度とタイミングを設定——SKU数が増えると在庫同期の処理量が増加します。API連携の場合は呼び出し回数の上限（Rate Limit）に注意し、CSV連携の場合は新仕様のCSVフォーマットに対応しているか確認してください
4. 受注データのSKU情報を確認——楽天からダウンロードする受注CSVにSKU情報が含まれていることを確認し、発送代行への出荷指示データにSKU単位の情報が正しく渡っているか検証します
5. 返品・在庫戻しのフローを再設計——SKU単位の在庫管理では、返品時の在庫戻し先もSKU単位で正確に行う必要があります。「カラー違い」の返品在庫を別SKUに誤って戻すミスが起きやすいため、戻し作業のルールを明文化してください

令和３年６月に閣議決定された「総合物流施策大綱（2021年度～2025年度）」においても、取り組むべき施策として「物流DXや物流標準化の推進によるサプライチェーン全体の徹底した最適化（簡素で滑らかな物流の実現）」が挙げられたところです。

出典：国土交通省「物流標準化」

API連携とCSV連携の選択基準

SKU数が500未満で更新頻度が1日1回程度であればCSV連携で十分運用できます。一方、SKU数が500を超える場合やリアルタイムの在庫同期が求められる場合はAPI連携への移行が向いています。両者の違いを次の表に整理しました。

STOCKCREWはAPI連携に対応しており、楽天RMSからの受注データを自動で取り込んで出荷指示を生成できます。CSV連携にも対応しているため、SKU数や運用体制に合わせて段階的に移行できる点が実務上のメリットです。外部連携の詳細はSTOCKCREWの外部連携ページにまとめています。なお、OMSやWMSを新規に導入する際は、国の補助金を活用できる場合があります。

令和7年度補正予算事業から、「デジタル化・AI導入補助金（旧：IT導入補助金）」と名称を変更しました

出典：中小企業庁「デジタル化・AI導入補助金2026の公募要領を公開しました」

商品マスタの整備とSKU設計の全体像についてはEC事業者のための商品管理ガイドとSKU設計もあわせて確認すると、登録段階での手戻りを防げます。

SKU移行後のよくあるトラブルと対策

SKU移行後に実際に発生しやすいトラブルと、その対策をまとめます。事前に把握しておくことで、売上機会の損失や顧客クレームを防げます。

トラブル1：在庫ズレによる「在庫あり」表示の誤り

SKU単位の在庫管理に移行した直後は、在庫同期のタイミングのズレにより「楽天では在庫あり表示なのに実在庫がゼロ」という事態が起きやすくなります。対策としては、在庫同期の頻度を最低でも1時間に1回に設定し、セール期間中はリアルタイム同期に切り替えることを推奨します。楽天スーパーSALE時の物流対策については楽天スーパーSALEの出荷急増に備える物流設計で解説しています。

トラブル2：商品属性の未入力による登録エラー

移行日から180日以内が商品属性登録の準備期間とされ、181日目以降は未登録だと罰則加点（ペナルティ）の対象になり得ます。検索順位や売上に影響するため、早めの登録が安全です。対策として、RMSの「商品属性未入力一覧」を定期的にチェックし、漏れなく登録を完了してください。

トラブル3：CSVフォーマットの不一致

移行前のCSVテンプレートをそのまま使い続けると、アップロードエラーが発生します。とくに「コントロールカラム」を使った従来方式は廃止されているため、楽天が提供するSKU対応の新CSVフォーマットをダウンロードして使い直してください。自作マクロやRPA連携がある場合は、出力フォーマットの更新も必要です。最新のCSV仕様は楽天市場の店舗運営Navi（RMS）に掲載されているSKU移行後のCSV登録ガイドで確認できます。

トラブルを未然に防ぐ運用チェック

これら3つのトラブルは、いずれも移行直後の運用設計を整えておくことで大半を防げます。具体的には、在庫同期の頻度をカレンダーに落とし込んでセール期だけリアルタイム同期に切り替える、商品属性の未入力一覧を週1回チェックする、CSVテンプレートを新フォーマットに統一して旧テンプレートを社内から撤去する、という3点をルール化しておくと効果的です。担当者が複数いる店舗では、誰が・いつ・どの作業を行うかを一覧にして共有しておくと、引き継ぎ時の抜け漏れも防げます。移行は一度きりの作業ですが、SKU単位の在庫管理は日々の運用そのものであり、仕組みとして回す体制づくりが品質を左右します。

モデルケース：3,000SKUの楽天店舗が在庫ズレを解消するまで

ここまでの内容を、アパレル雑貨を扱う中規模の楽天店舗を想定したモデルケースで整理します。実在の店舗ではなく、本記事で解説した条件を組み合わせた例です。

このケースの前提と導入前の課題

カラー・サイズ・入数の組み合わせで約3,000SKUを扱う店舗を想定します。SKUプロジェクトへの移行自体は完了していたものの、在庫はCSVを1日1回アップロードして更新する運用のままでした。その結果、人気カラーのMサイズが売り切れても楽天上は「在庫あり」のまま表示され、受注後に欠品が判明してキャンセル・お詫び対応が発生する、という在庫ズレが繰り返されていました。さらにAmazonにも同一商品を出品していたため、SKUコードの対応付けがあいまいで、二重販売のリスクも抱えていました。

取り組んだ3つの打ち手

第一に、楽天RMSとAmazonのSKUを1枚の対応表に棚卸しし、一元管理OMS側のマッピングを修正しました。第二に、在庫同期をCSVの日次バッチからAPI連携に切り替え、受注のたびに在庫が即時反映される状態にしました。第三に、SKU倉庫指定を使って、回転の速い売れ筋SKUを出荷効率の高いゾーンへ、動きの鈍いSKUを別ゾーンへ分けて配置しました。

結果として得られたもの

在庫同期が即時化されたことで「在庫あり表示なのに欠品」というキャンセルが大きく減り、お詫び対応の工数も圧縮されました。モール横断のSKU対応表を整えたことで二重販売の不安も解消し、SKU単位の販売実績が見えるようになったことで、死に筋SKUの早期の見切り・在庫圧縮にもつながりました。このモデルが示すのは、SKU移行の本当の効果は「設定の完了」ではなく、在庫同期・マッピング・倉庫配置という運用面まで作り込んで初めて表れる、という点です。

まとめ：SKU移行後の在庫・物流を最適化する3ステップ

楽天SKUプロジェクトの移行は「商品ページの設定変更」で終わりではありません。在庫管理・物流オペレーション・外部システム連携の3つの領域で、SKU単位への最適化を進めることが求められます。

1. 在庫管理をSKU単位に精緻化する——商品属性を網羅的に登録し、SKUごとの在庫数をリアルタイムに追跡できる体制を構築してください。マルチモール運営の場合は在庫同期ツールのSKU対応状況を確認しましょう
2. SKU倉庫指定で物流コストを最適化する——SKU単位の倉庫指定を活用し、サイズ別・売れ筋別の在庫配置を見直してください。RSLと外部3PLの併用設計も検討に値します
3. WMS・OMS連携のSKU対応を完了する——連携チェックリスト5項目を順に確認し、テスト出荷でSKUマッピングの正確性を検証してください

楽天市場の出店コスト全体は楽天市場の出店費用・手数料を徹底解説【2026年版】で把握できます。EC物流全体の仕組みは発送代行完全ガイドで体系的に整理しています。SKU移行を機に在庫管理から出荷までを一気通貫で見直したい場合は、まず現状の在庫同期の頻度とSKUマッピングの整合性を点検し、ボトルネックがどこにあるかを切り分けるところから始めると、打ち手の優先順位が明確になります。STOCKCREWでの物流体制づくりを相談したい場合は、お問い合わせまたは資料ダウンロードからご連絡いただけます。