楽天の商品登録を効率化する方法｜企画からイベント申請までの業務設計

楽天の商品登録を効率化するには、入力を速くする前に、商品企画、素材準備、RMS登録、ページ制作、確認、イベント商品申請を一つの工程として設計します。商品情報の正本を一つに決め、各工程の担当・期限・開始条件・完了条件・承認者を明確にすると、二重入力や差し戻しを減らせます。

この記事では、商品登録業務の棚卸し、商品企画マスタ、画像の受け渡し、手動・CSV更新の使い分け、公開前確認、イベント申請から振り返りまでを解説します。RMSの個別操作ではなく、複数担当でも滞留しにくいワークフローを作るための記事です。

商品登録だけを速くしても全体は短くならない

バックヤード業務の効率化は、利益確保・売上アップへつなげるための取り組みです。対象は商品登録だけではなく、画像・動画の準備、ページ制作、イベント商品申請までを含みます。

商品登録の所要時間だけを短縮しても、画像待ち、原価確認待ち、承認待ち、イベント条件の見落としが残れば、公開日は早まりません。見るべきなのは、企画開始から販売可能になるまでのリードタイムです。

まず、直近の商品を3〜5件選び、次を時系列で記録します。

• 誰が、いつ、何を受け取ったか
• 作業を始められなかった理由
• 誰へ何回差し戻したか
• 同じ情報を何回転記したか
• 公開後に何を修正したか
• イベント申請に間に合わなかった理由

作業時間と待ち時間を分けると、改善すべき場所が見えます。

全工程を一枚に並べる

店舗ごとに工程名は異なりますが、基本形は次のとおりです。

工程を「担当者の作業一覧」ではなく、成果物の受け渡しとして定義します。「画像を作る」ではなく「指定サイズ・命名・権利確認済み画像を所定フォルダへ置く」のように完了条件を書きます。

商品企画マスタを情報の正本にする

商品名、原価、販売価格、JAN、商品番号、SKU、仕様、配送、在庫、公開日が、メールやチャット、複数の表へ分散すると、どれが最新か分かりません。商品企画マスタを一つ決め、他の資料はそこから作ります。

最低限、次の項目を持たせます。

1. 社内商品IDと楽天の商品管理番号
2. 商品名、SKU名、JAN等の識別情報
3. 原価、通常価格、販売計画、利益確認
4. サイズ、重量、素材、仕様、注意事項
5. 配送方法、送料区分、出荷リードタイム
6. 在庫数、入荷日、販売開始・終了予定
7. 必要な画像・動画・説明文
8. 権利・法令・表示の確認状況
9. 担当、承認者、期限、現在の状態
10. RMS登録・公開・申請の結果

更新者、更新日時、変更理由も残します。原価や仕様のような重要項目は上書きだけでなく履歴を残し、公開情報との不一致を追跡できるようにします。

工程ごとに開始条件と完了条件を決める

「できたところから進める」運用は、一見速くても差し戻しを増やします。各工程にDefinition of ReadyとDefinition of Doneを置きます。

たとえば商品登録の開始条件は、商品ID、名称、価格、税、在庫、配送、SKU構成、主要属性が承認済みであることです。完了条件は、必須項目の入力、商品・SKUの対応、価格・在庫・配送の照合、テスト表示の記録までとします。

ページ制作の開始条件は、主要画像と訴求根拠が揃っていることです。完了条件は、スマホ表示、リンク、画像代替テキスト、誤字、販売条件の確認まで含めます。

条件を満たさない緊急案件を進める場合は、欠けている情報、暫定値、確定担当、確定期限を記録します。口頭の「あとで直す」にしません。

画像・動画の受け渡しを標準化する

素材の探索と差し替えは、商品登録の大きな待ち時間になります。フォルダ、ファイル名、版、用途を標準化します。

例として、社内商品ID_用途_連番_版のような命名規則を決めます。元データ、編集データ、入稿データを混在させず、使用可否と権利確認の状態を持たせます。

素材依頼には、次を含めます。

• 商品IDとSKU
• 必要なカット・用途・優先順位
• 事実として訴求できる仕様
• 必要サイズ・形式・容量
• 納期と承認者
• モデル、商標、第三者素材等の権利条件
• 修正回数と最終版の置き場所

過去の商品ページを丸ごと複製する場合も、旧価格、旧配送条件、旧キャンペーン、廃止済み表現が残っていないか確認します。なお「imagenavi for 楽天市場」は提供終了しているため、本稿では現行ツールとして推奨しません。

手動・CSV・APIの更新元を混在させない

少数の商品を初めて登録するなら、RMS画面で項目の意味と反映を確認しながら進める方法が向きます。大量の定型変更にはCSVが有効ですが、全件上書き、列ずれ、文字コード、商品とSKUの粒度違いに注意が必要です。APIや外部システムを使う場合は、契約、対象機能、同期方向、失敗時の再実行を確認します。

同じ項目を複数経路から更新すると、最後に動いた処理が別担当の変更を戻すことがあります。項目ごとに更新元を決めます。

CSVによる大量変更は「楽天CSV一括編集の安全な進め方」も参照してください。

依存関係から日程を逆算する

公開希望日だけを置くのではなく、イベント申請締切、審査、ページ完成、素材完成、撮影、商品確定の順に逆算します。

1. 販売開始日・イベント対象期間を決める
2. 現行の申請締切と審査条件を確認する
3. 申請可能な商品ページ完成日を置く
4. QA・修正の予備日を確保する
5. 登録、素材、商品確定の期限を逆算する
6. 各工程に担当とバックアップ担当を置く

イベント商品申請のメニュー、期限、審査条件は変更される可能性があります。過去案件の締切を流用せず、対象イベントごとにRMS・店舗運営Naviで確認します。

イベント申請を独立したチェック工程にする

商品ページが公開できたことと、イベントへ申請できることは同じではありません。申請前に、対象条件、価格表示、販売実績の扱い、在庫、配送、商品状態、申請期間を確認します。

申請台帳には、イベント名、対象商品、申請者、申請日時、申請時の価格・在庫、結果、差し戻し理由、再申請期限を残します。申請後に価格やページを変更する場合、その変更が審査や対象資格へ影響しないか確認します。

一つの商品を複数イベントで使う場合も、過去の判定を今回へ流用しません。イベントごとの要件を読み、根拠ページや画面の確認日を記録します。

公開前QAを担当者の記憶に頼らない

商品登録者と確認者を可能なら分け、次をチェックリスト化します。

• 商品名、商品番号、SKU、JANの対応
• 価格、二重価格、ポイント、クーポンの整合
• 在庫、販売期間、購入上限
• 送料、配送方法、出荷リードタイム
• 商品属性、選択肢、バリエーション
• 画像、動画、リンク、スマホ表示
• 法令・権利・注意事項
• テスト購入までの導線
• 広告・カテゴリ・特集ページからのリンク

公開後も実際の商品ページを確認します。RMS上の保存成功だけで完了にせず、反映遅延やキャッシュを考慮して確認時刻を記録します。

商品登録の基本操作は「楽天市場の商品登録方法」で確認できます。

リードタイムと手戻りを測る

効率化を「忙しさが減った気がする」で評価せず、次の指標を月次で比べます。

短縮のために確認を省き、公開後修正や問い合わせが増えれば効率化ではありません。削減できた時間を商品企画、販促、分析へ振り向けられたかも確認します。

最初の2週間で整える手順

一度に全商品へ導入せず、新商品1カテゴリで試します。

1〜3日目

直近案件の工程、待ち、差し戻しを棚卸しし、成果物と責任者を決めます。

4〜7日目

商品企画マスタ、素材命名、開始・完了条件、QA表を作り、1商品で通します。

8〜10日目

詰まった工程と重複入力を修正します。自動化は、標準化できた反復作業だけを対象にします。

11〜14日目

3〜5商品へ広げ、リードタイム、差し戻し、公開後修正を比較します。運用自動化の考え方は「楽天運営を自動化する方法」も参考にしてください。

よくある質問

商品登録業務はどこから自動化すべきですか？

まず情報の正本、項目定義、承認、例外処理を決めます。そのうえで、形式が一定で件数が多く、失敗を検知・復旧できる転記や更新から自動化します。判断が未整理のまま自動化すると、誤りも高速に広がります。

商品企画マスタはExcelやスプレッドシートで十分ですか？

小規模なら十分な場合があります。重要なのはツール名ではなく、正本が一つで、権限、履歴、必須項目、商品・SKUの識別、更新元が明確なことです。件数や同時編集が増えたら専用管理を検討します。

画像が間に合わなくても商品登録を先に進めてよいですか？

登録用の確定情報が揃っていれば並行作業は可能です。ただし仮画像や未確定仕様を公開しないよう、状態と公開条件を分け、最終素材の担当・期限・承認を記録してください。

イベント商品申請の締切はどこで確認しますか？

対象イベントの現行案内、RMS、店舗運営Naviで確認します。メニュー名、締切、審査項目は変わり得るため、過去の手順書だけで判断せず、確認日と根拠を申請台帳へ残してください。