楽天SKUプロジェクトとは　基本編 2023年度版 | 商品登録代行 専門店

楽天市場では現在SKUプロジェクトが進行中です。SKUプロジェクトによって商品の検索がしやすくなり、お客様にとっての利便性向上が期待されます。早い店舗ではすでに2023年4月から移行が始まっており、まだ移行が行われていない店舗についても移行時期が通達済で、今後順次移行が行われます。
初稿：2023/7/30
追記：2023/11/22 2024/01/31

そもそもSKUとは

SKU（Stock Keeping Unit）は、在庫管理上で非常に重要な役割を果たす単位です。SKUは商品やアイテムの最小単位であり、一つの商品が異なる特性やバリエーションを持っている場合、それぞれの特性に対応するために使用されます。これにより、商品の一元的な管理や在庫追跡がスムーズに行えるようになります。

例えば、パーカーという商品を考えてみましょう。このパーカーは色とサイズの2つの特性で変化します。具体的には、黒とグレーの2つの色と、S・M・Lの3つのサイズがあります。この場合、1つのパーカー商品には合計で6つの異なるバリエーションが存在します。それぞれの組み合わせが個別のSKUとして扱われ、在庫管理や商品識別に使用されます。

さらに、衣類だと色やサイズが異なっても価格は同一である場合が多いですが、例えば清涼飲料水の場合、同じ銘柄であっても350mL入り・500mL入り・1.5L入りのように容量の違いによって価格が異なる場合が多いです。この例だと、1つの商品で価格の異なる3つのSKUが紐づいているということになります。

SKUは以下のように役立ちます：

• 在庫管理: 各SKUに対して在庫数を追跡することで、特定の商品バリエーションが在庫切れになった場合や再注文が必要な場合を正確に把握できます。
• 注文処理: 顧客が特定の色やサイズを注文した場合、正確なSKUを使用して該当の商品をピッキングし、迅速な発送を行うことができます。
• 在庫の回転率: SKUごとの売上と在庫回転率を追跡し、人気のある商品バリエーションと在庫が滞っている商品を特定できます。
• 価格設定: 各SKUに異なる価格を設定し、顧客に選択肢を提供します。例えば、大きなサイズの商品には追加の料金を設けることができます。
• 商品情報管理: SKUを使用して商品の詳細情報を整理し、ウェブサイトやカタログで正確な情報を提供できます。

総じて、SKUは在庫管理と顧客サービスの効率性を向上させ、多様な商品ラインナップを効果的に管理するための貴重なツールとして使われています。商品が多様性を持つ場合、正確なSKUの設定と管理はネットショップ運営においてとても重要な要素です。

わかりやすく 楽天SKUプロジェクト

これまで楽天市場では、パーカーの例のように価格が同じであれば1つの商品ページ上で扱うことができましたが、清涼飲料水の例のように価格が異なる場合は1つの商品ページ上で扱うことができませんでした。

SKUプロジェクトはこの点を改善し、価格の異なるSKUのバリエーションを同一の商品ページ上で表現することが可能になります。

これによって、お客様にとっては商品ページ上で異なるサイズ等を比較検討しやすくなりますし、店舗としてもせっかく商品ページを訪れたお客様を他店舗に流出させることなく別のバリエーションを提案しやすくなります。

このほかにも、これまで色×サイズのように2軸までしか表現できなかったのが3軸以上の設定が可能になる、検索結果画面上に商品の他のバリエーションが表示されることで商品ページへの遷移が促進される、検索結果がより適切なものとなるよう従来のタグIDがジャンルごとの商品属性に移行される等の変化もあります。

楽天SKUプロジェクト 店舗で必要な対応

SKUプロジェクトの移行後は同一商品の価格の異なるバリエーションをひとつの商品ページ上にまとめることが可能になりますが、SKUをまとめずにこれまでどおりの商品ページ単位で運用を続けることも可能です。

ただし、SKUをまとめない場合であっても、下記の作業は必須となります。

必須商品属性の入力（タグIDからの移行）

従来のタグID

商品属性を7桁の数字の「タグID」で入力していたのに変わって、より具体的な「実際の値」で入力する形に変更になります。

これまでは、RMSの「タグID」欄で「ID検索」ボタンを押すと別ウィンドウが開き、該当するタグID項目にチェックを入れていく形でした。元の画面のタグID欄には、1011174/1013847/1019478…のような半角数字が設定されます。（詳しくは、過去記事「楽天市場　タグID設定がまだ？売上に結びついてない1つの要因では？」をご覧ください）

タグIDの設定は流入獲得のために重要ですが、半角数字での入力はミスが生じやすく不便なのが難点でした。

タグIDに代わる商品属性

SKUプロジェクトに伴い、商品編集画面はタブ式に変更になっています。タグIDの代わりとなる商品属性は「製品情報」タブから入力します。

最上部の「ジャンルID」は従来の「全商品ディレクトリID」です。選択した「ジャンルID」によって商品属性の入力項目は変わります。この例ではジャンルIDは「食品 > 精肉・肉加工品 > 馬肉 > 赤身」となっており、商品属性（見出しの表記は「商品仕様」）の欄にはシリーズ名・ブランド名・原産国／製造国・総個数・総重量などが表示されています。

最下部には自由入力行も用意されており、予め設定されている項目以外に入力したい商品属性がある場合に利用可能です。

従来のタグIDと異なり、コード番号ではなく実際の値を入力していく形となります。例えば日本製の商品であれば「原産国／製造国」の欄に「日本」と記入します。

楽天市場商品属性の定義

商品属性には必須項目・任意項目があります。楽天市場のRMSにそれぞれの商品属性パターンが掲載されているので自店舗の該当商品属性を確認する必要がありますが、実際1つ1つの属性を確認するとあまり斜に構えて敬遠するというよりは、どの程度の物が入っているのかを必ず確認する必要があります。結局楽天の検索対策になる物なので避けては通れませんし、そもそも商品属性（タグID)の対応をしないということは今後選択肢としてはありえない形となってきます。また、選択式と記述式がありますが、商品属性はそれぞれ専門性を帯びた物に変わってきましたので、自店舗で売られている商品の属性であれば選択も容易であると思います。

但し、やはり数が多い場合や選択が多い商品などは1つ1つかなり時間がかかる物なので、外注や外部システムに頼る事を検討された方が良いかと思います。

こちらは「精肉」の例です。「1 シリーズ名」〜「5 総重量」の5項目が必須、「6 オーガニック認証期間・基準」以降は任意となります。

ジャンルごとの商品属性定義書は店舗運営Naviからダウンロードできます。また、商品属性登録に関するガイドラインもぜひ一度ご確認ください。

すでに登録済のタグIDは、一部を除いて自動で商品属性の登録値へ自動変換されます。

移行に伴う措置

SKU移行前に入力されていたタグIDは、原則として自動で商品属性へと変換されます。移行に伴ってすべてリセットされ0から入力し直しということにはならないのでご安心ください。

但し、商品属性のうち入力必須となっているものがタグIDからの自動移行だけでは全て埋まらないケースが多々あります。商品属性の移行期間として、SKU移行から180日間は必須商品属性が未入力でも商品の登録・更新を行うことができます。180日を過ぎると未入力の状態では登録・更新ができなくなるため、まずは必須項目を優先として商品属性の設定を進めていきましょう。180日間＝約半年間というのはまだまだ…と思っていても意外とあっという間に過ぎてしまいます。

必須だけの商品属性をまずは入れていくという事も重要です。必須であれば、商品の選択肢も商品タイトル等でも判別できる部分が多いはずなので、もし商品が大量となっている場合でも、CSVを使って縦作業を実施することで工数の削減にも寄与できます。また、そんな時間ないよって場合は、商品登録ドットコムまで 楽天市場 商品属性 の必須登録のお見積りをご依頼下さい。

商品属性を入力する重要性

もちろん、必須項目だけでなく任意項目も可能な限り入力するに越したことはありません。お客様が楽天市場でキーワード検索を行う際、商品名や説明文だけでなく商品属性の情報も参照して検索結果が表示されることが店舗運営Navi内に明記されています。商品属性を丁寧に入力することは商品がお客様の目に触れるチャンスを増やすことに直結します。

例えば上記の馬肉の例でいえば、産地（都道府県）は任意項目になっています。しかし、この欄に「熊本」と入力しておくことで他の地域ではなく熊本産の馬肉にこだわって検索しているお客様に見つけてもらえる可能性が高まります。

SKUまとめに伴う「旧商品」の対応

これまで複数ページで展開していた商品を1ページに集約した場合、元商品ページの扱いに注意が必要です。移行後360日間は「旧商品」に注文が入らないよう、注文ボタンを非表示にする・倉庫に入れる・商品ページ自体を削除する等何らかの対応を行います。こうした対応を行わずに元商品ページからも注文可能な状態のままにしておくと、「不適切な検索対策」として違反行為と見なされてしまいます。意図せずにペナルティの対象となってしまうことがないようご注意ください。

ブックマークや過去の購入履歴を辿って購入される可能性を考えると、元商品ページそのものを削除するよりも、注文ボタン非表示の状態かつ新ページの案内を掲載して一定期間残しておくことが望ましいです。

注文ボタンは商品編集画面の「販売・価格」タブ – 販売設定 – 注文・予約ボタン の欄で非表示に設定することができます。

SKU画像のガイドラインへの適応

SKUプロジェクトに伴って、ひとつの商品に紐づく各SKUにSKU画像が設定されます。例えば、バニラ・チョコレート・ストロベリーの3種類があるアイスクリームの場合、商品画像には3種類のアイスの集合写真、それぞれの種類（SKU）ごとにバニラ・チョコレート・ストロベリーの写真を設定するといったイメージです。

SKU画像は、商品ページ上で特定のSKUを選択した場合や、検索画面で例えば「アイス チョコレート」のように特定のSKUのみが該当するような絞り込みを行った際に使用されます。

商品属性をSKU画像も商品第一画像と同様に商品画像登録ガイドラインの対象となるため、文字入れや枠線・背景色についての規定を守って作成する必要があります。

また、複数のSKUが紐づいた商品の場合、商品第一画像には最安値の仕様を文字または画像で含める必要があります。350mL入り・500mL入り・1.5L入りの3種類がある清涼飲料水の場合、最安値の350mLの商品画像もしくは「350mL」の文字を必ず商品第一画像に含めないといけません。

RMSの商品登録画面では「ページデザイン」タブにSKU画像の設定欄があります。

CSV一括更新ファイルの変更

これまではCSV一括更新はitem.csv（商品） / select.csv（項目選択肢別在庫） / item-cat.csv（カテゴリー） の3種類のファイルで行っていましたが、SKUプロジェクト移行後は使用するCSVファイル形式が変更になります。

item.csvとselect.csvは廃止となり、代わりにnormal-item.csv(商品・SKU・商品オプションの登録・更新) / item-delete.csv（商品・SKU・商品オプションの削除）を使用する形となります。item-cat.csvはこれまでと変更ありません。

また、これまではデータの追加(n)/更新(u)/削除(d)をコントロールカラムで指定する形でしたが、今後は商品管理番号・SKU管理番号をキーとして追加・更新を行います。normal-item.csvを使用した場合は商品管理番号・SKU管理番号が存在しなければ新規登録、存在する場合は更新、item-delete.csvを使用した場合は商品管理番号・SKU管理番号をキーとして削除という形になります。

また、これまでのitem.csvは1商品につき1行でしたが、normal-item.csvでは商品レベル行・商品オプションレベル行・SKUレベル行に分けて入力する形となります。

他にも入力形式の変更や入力項目の廃止などさまざまな変更点があるため、店舗運営Navi内にある詳しい説明をぜひご確認ください。

商品レベル行とSKUレベル行とは

SKUプロジェクト移行後の商品登録用CSVファイル（normal-item.csv）では、商品レベル行・商品オプションレベル行・SKUレベル行の3タイプの行があります。

どの入力項目がどのレベル行に属するか、詳しくは店舗運営Navi内のマニュアルをご参照ください。

商品レベル行・商品オプションレベル行・SKUレベル行のどれを入力する場合でも、商品管理番号（URL）は必須です。

同じ行に異なる行タイプの項目を混在させることはできません。例えば商品名と価格を更新する場合、×のように1行でまとめることはできません。○のように商品レベル行とSKUレベル行に分けて記載する必要があります。また、SKUレベル行の更新時はSKU管理番号が必須となります。

× （間違った例）

○（正しい例）

CSV更新時に下記のようなエラーが出た場合、それぞれのレベル行が正しく区別して記載されているか確認してください。

1）商品レベル行には、商品レベルに該当するカラムのみ入力してください。
2）skuレベル行には、skuレベルに該当するカラムのみ入力してください。

SKUまとめ作業

楽天は、これまで複数ページで販売していたSKUを1ページに集約することを推奨しています。集約しないことでのペナルティは現状ありませんが、集約したほうが検索順位等でメリットが生じる可能性は大いに考えられます。可能なかぎりSKUのまとめ作業を行ったほうがよいでしょう。

ただし、まとめてよいSKUの組み合わせには規定があります。例えば、同じジャンルのSKU同士はまとめてOKですが、ビールとチューハイのように異なるジャンルのSKUをまとめるのはNGです。また、新品と中古のように商品状態が異なるもの、正規品と並行輸入品のように販売経路が異なるものをまとめるのもNGです。詳しくは店舗運営Naviに掲載されているSKUのまとめ方に関するガイドラインを参照してください。

SKUをまとめる場合、申請することによって集約前の商品ページに蓄積されていたレビューを集約先の商品ページに移管することができます。お気に入り登録については残念ながら付け替えることはできません。

ランキングについては集約先の順位が適用されるため、よりランキング順位の高いページへ集約するのがおすすめです。集約すること自体は順位に関係なく、例えば実績が合算されることでランキングが上がるということはありません。

スーパーSALEイベント商品申請対策

スーパーSALEでのイベント商品申請を行う場合、SKU移行に伴う変更点に注意が必要です。

合否判定について、1商品の全SKUが合格条件を満たす必要があります。例えば容量の異なる3つのSKUを1商品に統合した場合、2つが条件を満たしていても1つが割引率を満たしていなければ不合格になってしまいます。

特に注意したいのが販売実績の初期化です。SKU管理番号を変更した場合や新規で追加したSKUは販売実績が初期化されてしまうため、これまで販売実績を十分積み重ねてきた商品であっても統合することでリセットとなってしまいます。スーパーSALEへの申請を視野にいれる場合、統合のタイミングに十分注意が必要です。

また、在庫切れによって販売実績が不足する場合、SKU単位ではなく商品ページ全体として審査不合格となってしまいます。

割引サーチ・半額サーチに関しても同様に、半額アイコンを表示するためには全SKUが50%以上の割引率である必要があります。これまで異なる割引率を設定していた商品を統合する場合にはその点も考慮が必要です。

楽天市場 SKUプロジェクトの第二の難所はSKU統合 まとめ　作業？！

　続々と楽天市場の店舗様、商品登録ドットコムの店舗様の楽天市場 SKUプロジェクト（新SKU）への移行となってまいりました。そして、そして、2023年の年末の足音も聞こえる中、年末前に対応したいお客様の駆け込みが徐々に増えてまいりました。すでに結構スケジュールが埋まりつつあります（汗。楽天市場 SKUプロジェクト において商品属性も、勿論楽天SEOに関わる部分ですし捨てる作業ではありません・・・ただ、商品ページ統合については、検索やRPP等でせっかく商品ページに入ってきたお客様を別のページに回遊させずに選択肢で選ばせる事ができるメリットが最大のポイントとなります。適合する店舗様は至急で検討されると良いと思います。

例1：
　複数価格や複数種類で価格違いなどの商品がある場合に、価格違いはいままでは別ページになっていた商品を1つのページで見せる事ができます。勿論あまりにも違う商品ラインナップをまとめると逆に迷ってしまう可能性もあるので、取捨選択やお客様目線で購入しやすい構成にする必要性があります。また今までのECモールサイトでは、多数の商品を出して露出を上げるという考え方がありましたが、商品によっては戦略としては間違えありません。但し、サイトでは必ず売れ筋とそうでない商品がありますので、売れ筋に対して、アクセス、レビュー、売上を集める事で、検索では有利になりますし、必然的に露出も増えていくので、今回の楽天SKUプロジェクトにおける商品ページの統合の機会に一部戦略の見直しや商品展開のさせかたのテストなどをするのも有効だと思われます。

例2：今まで項目選択肢ではなくオプション側に「+500円」などと入れて金額追加をしたり、別商品を作って同梱専用品としたり苦労されていた店舗では、追加費用も今回の楽天市場SKUプロジェクト（新SKU）では加算対応ができるようになりました。受注後の価格変更は作業的にも、作業者の不可的にも大きく軽減ができずクレームやミスが一緒になくなります。

楽天市場 SKUプロジェクト 第三の難所？ カタログID設定

　カタログIDも必須ながら重要なポジションであり、JANがあるのにカタログIDを無しにするのはそろそろ限界になりつつあります。JANを設定することで価格競争にさらされますが、型番品番扱いの店舗さんはこれは時代の流れとして取られて取り組むべき作業となっています。（商品価格ナビと連携されているのでここに露出があります。楽天のRMSアクセス解析で確認可能なので実際の流入も確認可能。）入れる事によるメリットの方が大きいです。2つ目のメリットとして、楽天がJANコードの情報として保持している情報から自動的にタグ補完をするとの事ですがこちらはどこまで埋まるかは未確認です。また、カタログID入力にも問題があり、Amazonなでへ出店されている店舗でも案外、楽天市場のSKU＝JANコードで管理されている店舗さんが少なかったりして、そもそも、楽天SKUとJANコードが紐づいてない場合は、この作業から実施しないといけません。メーカーや卸屋さんからこれらの情報を貰える場合はもらって対応しつつ、もらったとして自社の管理している商品コードとJANが紐づいてないなのでの問題がある場合はやはりこの作業も必要です。もし紐づけられてない中途半端な情報がある場合は、どのように整理するのかを含め方針を決める必要があります。

楽天SKUプロジェクトをローコストで解決できるかも？

　楽天SKUプロジェクトでは、既存で設定されているタグIDが基本的には消えてしまいます。というより仕様そのものの変更により使えません。但し、楽天側でもある程度対策してくれていて、単品商品（SKUが複数でない）については、タグIDが既存設定されている場合はある程度、自動変換が行われます。弊社で確認している限りはまあまあの確率で自動変換されているので、0から楽天SKUプロジェクトを対応するよりはよっぽど楽にはなります。但し、だからと言って、必須事項が全部埋まるわけではないので、新SKU以降後は必ずすべての商品に対して「商品属性」の必須項目がどこまで埋まっているかの確認が必須事項となります。以降後6ヶ月の猶予しかないので、それまでに徐々にでも進めておく必要性があります。

タグIDの内容はある程度使い回せる

特にアパレル系やカラー・サイズを多様するような店舗さんでは、移行先の商品属性でも同様の値が入る事になることから、楽天CSVにて「新SKU前のCSVデータ」を保持しておいて、そのデータを使って、商品属性を埋めていく方法です。ある程度CSVを使っているスタッフであれば対応可能かと思います。1つの問題として、簡単であるべき「カラー・サイズ」でさえ自動で移行はされません。あくまで単品商品のみ自動処理されます。つまり項目選択肢別在庫設定をされているような店舗さんでSKUが複数に分かれる場合においては、それぞれのSKU毎に商品属性を入れる必要があります。この部分だけでもかなりの数をいれる事が想像されます。なので、手で入れるとなるとかなりの時間も工数も費用も発生していきます。前述しておりますように、簡易に実施する場合であれば、新SKU前にタグIDを保持して、そのタグIDを新SKU側の商品属性にCSVにて入れる形が簡易移行ができるかと思います。また、商品属性を全部気合で入れる！・・・だとコストも時間もかかるので、一旦簡易でできる部分だけをタグIDから「商品属性」に移行して、その後余った部分は腰を据えて実施という形でも良いとおもいます。ただ、やはり楽天SEOにも検索順位としても影響度が大きい、検索順位のスコアに関わる部分であれば速攻やっておきたい、、、ただコストもかけたくない、そんな贅沢な要望については、全部は対応できませんが、簡易移行は速攻やりたい！そんな店舗さんはお声がけください。楽天市場SKUプロジェクトの商品属性の簡易対応致します。

楽天SKUプロジェクトとは　基本編 2023年度版　まとめ

現在進行中の楽天SKUプロジェクトによって、これまで別ページで展開していたSKUをひとつの商品ページに集約することが可能になります。これによって利用者の利便性が高まるのとともに、店舗としても自店内でのバリエーションをお客様に見せやすくなります。SKUプロジェクトに伴って、タグIDの移行やSKU画像の設定、CSVファイルの形式変更等の対応が必要になります。また、複数のSKUをひとつの商品ページに集約する場合、どのページに集約するべきか等検討が必要な点があります。きちんとした形で対応するのは手間がかかりますが、ぜひ可能な限り対応することをおすすめします。

　現在、商品登録ドットコムでは、楽天SKUプロジェクトに関連したご依頼として、商品属性（タグID・商品属性の設定代行）の再設定及び、今回の楽天SKUプロジェクトを期にタグID（商品属性）を見直したいというご質問とご相談が多数ございます。その中でも、タグID（商品属性）は今後検索に関してもインパクトがあり、逆に、楽天SEO対策の主軸となりうる流れとなってきますので、特に今回の楽天市場における楽天SKUプロジェクトについては、各店舗とも対応が求められる部分となります。また、いままではタグID（商品属性）がは選択肢式で対応しているタグを選ぶ形になりましたが、今後は楽天SKUプロジェクトにおいて記述式も入ってきますので、単に選択すればよかったこれまでのタグIDがとはまた別の認識をもって対応する必要があります。

　そんな大変は、商品属性の設定代行 商品登録代行 商品登録外注 のご相談はお気軽にお声がけください。

商品属性の設定代行　ご依頼のヒント　おまけ

　AI式や機械式での商品属性決めの場合のほとんどが、商品名、商品説明文（PC用商品説明文・PC用販売説明文・スマホ系商品説明文）、選択肢名などに商品属性に関連する文言やワードが入ってないと当然設定ができません（これは自動系でも当然同様です、品番や画像からは判断はできません）。商品属性を依頼する際は、事前に商品ページ内の不足項目を埋めるか、それにヒントとなる別資料を頂くなどをする必要があるありますのでご注意が必要な部分です。AIは万能ではありませんし、事前準備はAIであっても人間系であっても結局は必要な部分となります。当社でも機械処理時にAIを使った選別作業は取り入れておりますが、完全体ではありません、結局はAIを使っても最終的な部分では間違っているか否かを目視チェックが必要となり人間系は欠かせません。

tel:050-1746-5247