ホーム > 商品リサーチ・JAN
楽天で型番商品の品揃えを増やす方法|売れ筋・ニッチ商品と在庫回転の設計

楽天市場で型番商品の品揃えを増やすときは、商品数を一律に増やしません。高回転の売れ筋で売上の土台を作り、関連商品、利益商品、競合の少ないニッチ商品を小さなカテゴリ単位で追加します。残すかどうかは、売上だけでなく粗利、在庫回転、欠品、返品まで見て決めます。
型番商品は、同じJAN・メーカー型番の商品を複数店舗が扱うため、品揃えの広さだけでは差がつきません。在庫、価格、配送、商品情報の正確さも同時に整える必要があります。この記事では、追加候補の選び方、商品構成、発注、ページ整備、テスト、撤退基準を解説します。
型番商品の品揃え戦略とは
型番商品は、メーカー型番やJANコード等により、他店舗の商品と比較されやすい商品です。型番商品を主に扱う店舗の商品設計では、在庫回転率の高い売れ筋商品を準備し、販売機会が少ないニッチ商品の品揃えも拡充して、店舗全体の売上を伸ばす考え方が有効です。
ここで重要なのは、売れ筋とニッチ商品の役割を分けることです。
- 売れ筋商品:安定したアクセスと販売数を作る
- 利益商品:店舗の粗利額を確保する
- 関連・補完商品:同時購入や回遊を増やす
- ニッチ商品:競争の少ない検索需要を拾う
- 新商品:将来の売れ筋候補を検証する
すべての商品へ同じ在庫数・広告費・更新工数を配分せず、役割に合わせて投資します。
型番・JAN管理と商品戦略の違い
メーカー型番、JAN、SKUを正しく管理することは土台ですが、コードを登録しただけでは品揃え戦略になりません。
| 領域 | 主な目的 |
|---|---|
| 型番・JAN管理 | 同一商品の識別、仕入・在庫・ページ情報の一致 |
| 品揃え戦略 | どの商品群へ在庫と販促を配分するか決める |
コード管理が誤っていると、価格比較、在庫連携、受注、広告、商品分析が別商品として混ざる可能性があります。一方、コードが正しくても、低回転商品ばかり増やせば在庫資金を圧迫します。
型番とJANの役割、表記揺れの整理は「型番・JANコードから商品を探す方法と型番管理」で確認してください。
売れ筋とニッチ商品を組み合わせる

売れ筋だけに集中すると、競合との価格競争、仕入制限、欠品の影響を受けやすくなります。ニッチ商品だけを増やすと、1商品当たりの販売頻度が低く、在庫とページ管理の負担が大きくなります。
組み合わせは、カテゴリ単位で考えます。たとえば家電部品なら、本体の売れ筋、交換部品、対応アクセサリー、旧型対応品を一つのまとまりとして設計します。
| 役割 | 期待する効果 | 主なリスク |
|---|---|---|
| 売れ筋 | 販売数・集客の土台 | 価格競争、欠品 |
| 利益商品 | 粗利額の確保 | 流入不足 |
| 関連商品 | 客単価・回遊向上 | 対応関係の誤表示 |
| ニッチ商品 | 競合の少ない需要獲得 | 長期滞留 |
| 新商品 | 将来需要の先取り | 実績不足、返品 |
売れ筋の販売履歴から、同時に探される型番、代替品、消耗品を見つけると、無関係な商品を増やすより回遊を作りやすくなります。
追加候補を7項目で評価する
仕入先のカタログにある商品をそのまま全登録せず、候補を比較します。
- 検索需要:楽天内検索、関連語、問い合わせに需要があるか
- 競合:販売店舗数、価格、在庫、配送、レビューに勝ち目があるか
- 粗利:原価、手数料、広告、ポイント、配送を引いて残るか
- 仕入条件:最低発注数、納期、掛率、返品可否はどうか
- 在庫リスク:サイズ、保管、使用期限、モデル変更の影響はどうか
- 運用負荷:商品ページ、SKU、問い合わせ、検品が複雑でないか
- 関連性:既存顧客や売れ筋から回遊させられるか
候補表には、感覚的な「売れそう」ではなく、根拠の取得日と出所を残します。検索件数が見えない場合は、関連キーワード、競合レビュー数、問い合わせ、仕入先の販売傾向など、複数の代理指標を使います。
一般的な需要・競合・価格の調べ方は「ECリサーチのやり方」も参考にしてください。
在庫回転と欠品を同時に管理する
商品数の拡大では、欠品と過剰在庫の両方を防ぎます。
在庫回転率は、一定期間の売上原価を平均在庫金額で割る考え方です。現場では商品単位の販売数、在庫数、在庫日数、発注リードタイムも併用します。
発注点の基本 = 発注リードタイム中の予測販売数 + 安全在庫
例として、1日平均2個売れ、入荷まで7日、安全在庫6個なら、単純な発注点は20個です。ただし、イベント、季節、仕入先休業、販売変動を加味します。
売れ筋は、欠品による機会損失と検索・販売実績への影響を重視します。ニッチ商品は、初回仕入を小さくし、取り寄せや仕入先在庫連携が可能か検討します。
| 商品役割 | 初回在庫 | 発注の焦点 |
|---|---|---|
| 売れ筋 | 需要と納期に応じて厚め | 欠品回避、イベント前倒し |
| 利益商品 | 粗利と販売頻度で調整 | 粗利額と在庫資金の両立 |
| ニッチ | 小ロット | 滞留回避、仕入先連携 |
| 新商品 | テスト数量 | 返品・初期需要の確認 |
在庫金額だけでなく、棚の占有、検品時間、モデルチェンジ、保証対応もコストとして記録します。
型番商品ページを正確に整える
型番商品は比較しやすい分、仕様の誤りが返品・低評価につながります。仕入先資料、メーカー公式情報、商品現物を照合します。
- メーカー名、ブランド名
- 正式なメーカー型番
- JANコード
- 色、サイズ、容量、セット内容
- 対応機種・非対応機種
- 新旧モデルの違い
- 保証、付属品、輸入・国内正規品等の条件
- 在庫、発送予定、配送方法
似た型番を同じページへまとめる場合は、SKUごとの差が選択前に分かるようにします。互換性が確認できない商品を「対応」と断定せず、メーカー確認先を示します。
商品名へ型番を入れるだけでなく、検索結果の画像、価格、送料、最短お届け日が競合と比べてどう見えるか確認します。価格だけで勝てない場合は、在庫、即納、セット内容、保証、説明の正確さで選ばれる条件を作ります。
小カテゴリでテストする手順

品揃え拡大は、一度に数百商品を登録せず、小さく検証します。
ステップ1:カテゴリを一つ選ぶ
既存の売れ筋と関連し、仕入・保管・問い合わせを管理しやすいカテゴリを選びます。
ステップ2:役割別に候補を選ぶ
売れ筋、利益、関連、ニッチ、新商品の候補を分けます。既存商品と同じ型番の重複登録がないか確認します。
ステップ3:初回数量と限界損失を決める
何個売れなければ撤退するか、値下げや返品で回収できるかを仕入前に決めます。
ステップ4:ページと回遊を用意する
型番・仕様を正確に登録し、カテゴリ、関連商品、比較表から到達できるようにします。
ステップ5:一定期間を測る
アクセス、転換率、販売数、粗利、在庫回転、問い合わせ、返品を確認します。楽天ランキングを需要変化の補助に使う場合は「楽天ランキングの定点観測」も参照してください。
残す・育てる・撤退する基準
テスト後は、商品を三つに分けます。
残す
販売頻度は低くても、粗利が残り、在庫負担が小さく、既存カテゴリの品揃え価値を高める商品です。
育てる
アクセスまたは転換率に改善余地があり、在庫・粗利条件が良い商品です。画像、商品属性、検索語、関連導線、広告を一つずつ試します。
撤退する
一定期間で販売がなく、粗利改善の余地が小さく、保管・返品・問い合わせ負担が大きい商品です。後継型番への切替、在庫処分、販売停止を計画します。
撤退基準は、導入後に都合よく変えないよう、テスト開始前に決めます。売上がある商品でも、返品と広告費を含めて赤字なら「売れ筋」とは呼べません。
月商目標より利益とキャッシュを見る
月商1,000万円といった商品設計の目標が語られることもありますが、月商は店舗ごとの原価率や固定費を表しません。目標は自社の利益構造へ置き換えます。
確認する順番は次のとおりです。
- 商品別・カテゴリ別の売上
- 原価、販売手数料、広告、値引き、ポイント、配送費
- 商品別粗利と粗利額
- 平均在庫と在庫回転
- 発注支払と入金の時期
- 返品・廃棄・値下げ見込み
品揃えを増やして月商が上がっても、在庫支払が先行し、キャッシュが不足することがあります。仕入枠は、売上目標ではなく、回収期間と最大損失を含めて決めます。
よくある質問
型番商品は何点まで増やせばよいですか?
一律の正解はありません。カテゴリ別に、粗利、在庫回転、運用負荷、欠品率を測り、管理できる範囲で段階的に増やします。
売れないニッチ商品も残す意味がありますか?
在庫負担が小さく、関連購入や専門店としての選択理由を作るなら意味があります。長期滞留と運用コストが価値を上回る場合は撤退します。
メーカーの全商品を登録してもよいですか?
重複、需要、粗利、仕入条件、保管、返品、ページ作成負担を評価してから選びます。全登録を先に行うと、在庫と情報更新の負担が膨らみます。
月商が増えれば品揃え拡大は成功ですか?
売上だけでは判断できません。広告、値引き、配送、返品を引いた粗利と、在庫資金・回転まで確認してください。
店舗の「次の一手」を一緒に進めるなら
運営代行・ECコンサル・AIツールまで、現場を知るチームがワンストップで伴走します。
西尾 勝太株式会社ラクダ 代表
楽天SOY 2年連続受賞 / 楽天NATIONSリーダー店舗 / 楽天NATIONS AIエバンジェリスト
楽天市場の月商を5年で200万円→2億円に伸ばした現場の実践者。売れるECの方程式にAIを重ね、EC事業者の「次の一手」に伴走しています。



