楽天CSVで販売期間を一括設定する方法｜日時形式・差分・公開前後の確認

楽天RMSで多数商品の販売期間をCSV更新するときは、現在の商品データをダウンロードして原本保存し、対象商品の販売開始・終了日時だけを現行CSV形式で変更します。まず2〜3商品でテストし、開始前、開始直後、終了直後にログアウト状態のPC・スマートフォンで購入可否を確認してください。

CSV送信に成功しても、セールが正しく始まったとは限りません。商品・SKUのキー、日時の自動変換、販売期間と価格・ポイント・クーポン・在庫のずれ、手動・API・外部ツールによる上書きが事故の原因になります。この記事では、対象抽出、日時の扱い、差分監査、テスト、ロールバック、公開QAを解説します。

販売期間CSVで変えるもの

販売期間は、商品を購入できる開始日時と終了日時を制御する項目です。セール、新商品、予約告知、期間限定販売、終売等で使います。

販売期間を設定しても、次の項目が自動的に同じ期間へそろうとは限りません。

• 販売価格・表示価格
• ポイント倍率
• クーポン
• 商品画像・説明・バナー
• 広告・メルマガのリンク
• 在庫
• 倉庫指定・販売状態
• 配送・最短お届け日

CSVで変更するのは販売期間でも、施策全体は別項目を含むため、開始・終了チェックリストを一つにまとめます。

販売期間の一般的な仕組みと「販売期間前」表示の切り分けは「楽天RMSの販売期間設定」を参照してください。

CSV更新が向く場面

CSVは、同じルールで多数商品を更新するときに向きます。

1〜2商品ならRMS画面で個別確認する方が安全な場合があります。CSVの効率より、影響範囲と復旧難易度で選びます。

CSVを使うための契約・権限、商品・SKUのデータ構造、ファイル形式は現行のRMS・店舗運営Naviを確認してください。

更新前の原本をダウンロードする

販売期間を変更する直前に、対象商品の現行CSVを取得します。

1. 対象商品リストを商品管理番号等で確定する
2. 現行CSV仕様と販売期間項目を確認する
3. 対象商品のデータをダウンロードする
4. 原本を編集せず、日時・対象付きで保存する
5. 商品数、商品・SKUキー、現在値を監査する
6. 複製から編集用ファイルを作る

前日に取得した原本でも、その後に別担当者や外部連携が更新していれば、現在値と一致しません。更新直前の取得時刻を作業票へ記録します。

CSVの安全なダウンロードとExcelで壊さない開き方は「楽天RMSの商品CSVをダウンロードする方法」で解説しています。

商品レベルかSKUレベルかを確認する

SKU対応後は、商品ページ全体の情報と、色・サイズ等の購入単位の情報が分かれます。販売期間項目がどのファイル・階層・キーで管理されるかは、現行CSV仕様を確認してください。

確認するポイントは次のとおりです。

• 商品管理番号だけで更新する項目か
• SKU管理番号も必要な項目か
• 1商品に複数SKUがある場合の行構造
• 商品レベルとSKUレベルの期間が競合しないか
• 新規、更新、削除の指定方法

同じ商品管理番号が複数行あるファイルで、単純に重複削除するとSKU情報を失う可能性があります。逆に、商品単位の項目をSKU行ごとに異なる値へすると、エラーや意図しない結果になる場合があります。

代表的な単一SKU商品と複数SKU商品の両方でテストします。

日時形式を壊さず入力する

販売期間の日時は、表計算ソフトが自動変換しやすい項目です。現行CSV仕様で、列名、入力形式、開始・終了の必須条件、空欄の意味、タイムゾーンを確認します。

起こりやすい変換例です。

安全な方法は、現行マニュアルのサンプル値をそのまま形式テンプレートにし、対象列を文字列として扱い、保存後のCSVをテキストとして再確認することです。

「23:59:59にすべき」「終了日は翌日0時にすべき」と一般化せず、RMSが開始・終了の境界をどう解釈するか確認します。イベントの公式期間とも照合します。

編集対象を最小限にする

編集用CSVには、現行仕様上必要なキー・制御列・更新列だけを含めます。関係ない現在値を含めると、作業中に別担当が変更した情報を古い値へ戻す可能性があります。

作業用の監査表は、アップロードCSVと分けて作ります。

監査表では次を確認します。

• 対象件数が企画書と一致する
• 対象外商品がない
• 開始が終了より前である
• 空欄・異常な過去年・遠い未来がない
• 同じキーへ複数の異なる期間がない
• イベント期間と一致する
• 変更前の値を復旧できる

フィルターで非表示になった行を含めてコピーする事故にも注意します。最終ファイルは別担当者が件数と日時を確認します。

2〜3商品でテストアップロードする

本番対象が数百件でも、最初は代表的な2〜3商品だけを更新します。

テスト対象には次を含めます。

• 単一SKUの通常商品
• 複数SKUの商品
• 現在販売中、期間前、期間終了等、異なる状態の商品

テスト手順です。

1. 少数ファイルをアップロードする
2. CSV処理状況を確認する
3. エラーログを確認する
4. RMSの商品編集画面で日時を確認する
5. ログアウトした公開画面で表示を確認する
6. 意図した時刻境界で購入可否を確認する
7. 元の値へ戻すテストも行う

エラー0件でも、別の値へ変換されて登録された可能性があります。処理結果とRMS画面、公開画面を三段階で確認します。

一括更新前の差分監査

テスト合格後、本番ファイルを作成します。原本と本番CSVをキーで比較し、販売期間以外の意図しない差分がないことを確認します。

最低限の監査項目です。

1. 企画対象件数
2. CSV行数
3. 商品管理番号のユニーク件数
4. 商品＋SKUキーのユニーク件数
5. 開始日時ごとの件数
6. 終了日時ごとの件数
7. 空欄・重複・形式エラー件数
8. 更新対象外列の差分件数

集計値が一致しなければ送信しません。対象追加・除外があった場合は、口頭だけで済ませず企画書とCSVの両方を更新します。

開始前・開始直後・終了直後のQA

販売期間は予約した時点では最終確認できないため、時刻ごとの担当を決めます。

開始前

• 対象商品が意図せず購入できないか
• 告知・広告リンクが早く公開されていないか
• 価格、ポイント、クーポン、画像が準備済みか
• 在庫、配送、審査等の条件を満たすか

開始直後

• 「販売期間前」等が消え、購入できるか
• セール価格・ポイント・クーポンが一致するか
• SKUごとの在庫と価格が正しいか
• PC・スマホ・検索・広告のリンク先が正しいか

終了直後

• 購入不可または通常販売へ戻ったか
• 通常価格、ポイント、画像へ戻ったか
• 広告・バナー・メルマガの終了表示が整合するか
• 注文済み商品の受注・出荷に影響がないか

確認はログイン状態だけでなく、購入者と同じログアウト状態で行います。キャッシュを避けるため別ブラウザ・端末も使います。

手動・API・外部ツールの競合を防ぐ

同じ商品を複数経路で更新すると、正しいCSVが後から上書きされます。

セール準備中は、販売期間の更新元を一つに決めます。外部連携を止める場合は、再開時に古いデータを送らないか確認します。

処理失敗時の自動再試行があると、手動修正後に古い値が再送される場合があります。ジョブのキューとログまで確認します。

ロールバックを準備する

本番アップロード前に、戻すファイルと判断者を決めます。

• 変更前の原本
• 対象商品だけを変更前値へ戻すCSV
• 戻し操作の担当者
• 中止判断の期限
• 広告・バナー停止の連絡先
• 影響を受けた注文の確認方法

問題時に全商品データを丸ごと上書きすると、他の正しい更新まで戻す可能性があります。対象キーと販売期間だけを戻せるファイルを用意します。

ロールバック後も、CSV処理、RMS画面、公開画面、注文を確認して完了とします。

よくある質問

販売期間はCSVで一括設定できますか？

現行のCSV商品一括編集で対応する項目・ファイルを確認してください。SKU対応後の列名、粒度、日時形式は店舗運営Naviを優先します。

開始・終了日時はどの形式で入力しますか？

仕様変更や表計算ソフトの変換があるため、現行CSVマニュアルの形式を使ってください。タイムゾーンと境界時刻も確認します。

CSV処理が成功なら公開確認は不要ですか？

必要です。RMSへ登録された値、ログアウトした公開画面、開始・終了時刻の購入可否まで確認します。

販売期間終了で価格も自動で戻りますか？

販売期間と価格・ポイント・画像は別管理の場合があります。自動で戻ると決めつけず、終了直後のチェックリストで確認してください。