ホーム > 楽天店舗・RMS
楽天のCSVを定期アップロードする方法|毎週・毎月繰り返すファイルを予約する

RMS単体で毎週・毎月のアップロードを予約する機能は確認できないため、WinSCPのスクリプトとWindowsのタスク スケジューラで、パソコンからの転送を定期実行します。楽天側の反映時刻の保証は公開資料で確認できないため、転送後の処理結果と対象商品の更新確認までを運用に含めます。
楽天CSVの定期アップロードと販売期間指定の違い
楽天のCSVを定期アップロードする運用では、ファイルを送る予定と、商品に保存する期間設定を分けて考えます。
| 方法 | 予定しておく内容 | 運用上の確認点 |
|---|---|---|
| 販売期間などの事前設定 | 商品に保存する開始・終了日時 | 対象項目の入力条件と設定内容 |
| CSVの定期転送 | 毎週・毎月のファイル送信 | 今回のデータ、転送結果、楽天側の処理結果 |
商品更新用CSVでは販売期間も更新でき、入力条件はRMSのマニュアルで確認できます。
毎週・毎月の転送予約は、後述のタスク スケジューラで設定します。販売期間を先に保存する方法とは別の仕組みです。
毎週・毎月にくり返すCSV更新の例
くり返す更新は、頻度だけでまとめず、今回変える内容と終了後の状態まで決めておくと管理しやすくなります。
以下は店舗内の運用例であり、すべてを同じCSV形式や同じ設定方法で処理するという意味ではありません。
| 更新の例 | 今回確定する内容 | 戻し・次回更新の考え方 |
|---|---|---|
| 月初の価格 | 対象商品、承認済み価格、適用日 | 恒久改定なら定期的な旧価格への復帰は不要 |
| ポイント変倍 | 対象、倍率、開始・終了日時 | 倍率・期間をCSV入力できる条件は要確認。終了後の状態も確認 |
| 在庫の締め | 数量の基準時点、注文・引当・入荷 | 古い数量へ戻さず、復旧時点の在庫を再計算 |
| 季節の表示 | 商品名や説明文などの変更箇所 | 途中の修正を消さないよう復帰内容を照合 |
| 毎週のセール商品 | 新規対象、終了対象、継続対象 | 旧対象の復帰と新対象の開始を対応付け |
くり返すCSVを回す手順

- 今回の更新を確定します
対象商品、変更項目、適用したい日時を決め、期間限定の場合は終了後の状態も先に確定します。
- 変更前のバックアップを取得します
商品情報ならnormal-item.csv、カテゴリ設定ならitem-cat.csvを保存し、今回の作業と対応付けます。
- 更新用と戻し用を準備します
更新には既存情報をダウンロードして使い、現在の入力仕様に従って必要な項目と必須事項を整えます。
- 対象と版を確認します
同じ商品管理番号のSKUは連続したひとかたまりにし、対象一覧、変更値、日時、承認済みの版を照合します。
- カレンダーに開始と終了を登録します
ファイルの確定、アップロード、結果確認、必要な復帰について、具体的な日時と担当者を割り当てます。
- SFTPで転送します(自動化する場合はここをタスク スケジューラに任せます)
接続先とフォルダを確認し、楽天が認識するファイル名で、今回承認されたファイルをアップロードします。自動化する場合は、この転送だけを予定時刻にバッチが行い、1〜5と7は人が担当します。
- 処理結果を確かめて記録します
転送の成功だけで完了にせず、処理結果と対象商品の更新内容を確認して、実行記録に残します。
エラーが出た場合は反映済みの範囲を確認し、修正対象を決めてから、別版のファイルとして再送します。
戻し用CSVとファイル名の決め方

戻し用CSVは更新用と同時に準備し、楽天の受付名を守りながら、版と置き場所で取り違えを防ぎます。
商品更新用は先頭をnormal-item、商品削除用は先頭をitem-deleteにする必要があります。
カテゴリ登録用は必ずitem-cat.csvとし、日時や版をファイル名へ追加せず、保管フォルダで区別します。
| 用途 | ファイル名の例 | 版 | 店舗側の置き場所の例 |
|---|---|---|---|
| 商品情報の更新 | normal-item202611010900.csv | v01 | 作業ID/更新/v01 |
| 終了時の戻し | normal-item202611080900.csv | v01 | 作業ID/戻し/v01 |
| 商品情報の削除 | item-delete202611010900.csv | v01 | 作業ID/削除/v01 |
| カテゴリの登録・変更 | item-cat.csv | v02 | 作業ID/カテゴリ/v02 |
| 変更前の控え | normal-item.csv | 取得時点 | 作業ID/変更前 |
表の日時や版、置き場所は店舗内の管理例であり、ファイル名に日時を入れても実行予約にはなりません。
承認済みファイルは上書きせず、修正時は版を進め、今回使う更新用と戻し用の組み合わせを記録します。
変更前の控えはそのまま復旧に使うとは限らず、実行前に、その後の価格改定や注文による変更も照合します。
CSV定期アップロードのカレンダーと処理状況
カレンダーには送信予定だけでなく、結果確認と復帰も登録し、処理の遅延時に対応する担当者を決めます。
| 登録する予定 | 決めておく内容 |
|---|---|
| ファイル確定 | 対象、変更値、使用する版、確認担当 |
| アップロード | 年月日、時刻、日本時間、実行担当 |
| 結果確認 | 確認担当、処理結果と商品表示の確認 |
| 終了時の復帰 | 戻し用CSV、実行前の照合、代替担当 |
| 異常時の対応 | 連絡先、再送・修正・中止の判断担当 |
RMSの「CSVファイルダウンロード画面」の最上部には、システム全体の処理状況が表示されます。
| 処理状況 | 表示されるメッセージ |
|---|---|
| 正常 | 10分以内に完了見込みです。 |
| やや遅延 | アクセス集中により、処理完了まで10分以上かかる見通しです。 |
| 遅延 | アクセス集中により、処理完了まで大幅に時間がかかる見通しです。 |
これは全店舗に同じ内容が表示される目安であり、自店が送信したCSVの処理完了を示す表示ではありません。
「正常」の表示を根拠に反映時刻を確約せず、アップロード予定と、実際に更新を確認した日時を分けて残します。
SFTPの接続設定とフォルダの扱い
商品CSVの転送は専用サーバーへSFTPで行い、送信したファイルとログの控えは店舗側にも保存します。
WinSCPの接続設定は次のとおりで、楽天GOLDの接続設定とはサービスの用途を分けて扱います。
| 項目名 | 設定内容 |
|---|---|
| セッションの保存名(S) | 店舗で管理しやすい任意の名称 |
| 転送プロトコル(F) | SFTP |
| ホスト名(H) | upload.rakuten.ne.jp |
| ポート番号(R) | 22 |
| ユーザ名(U)・パスワード(P) | 商品一括登録サービスの申込完了画面で表示された情報 |
ユーザー名が不明な場合は、RMSの「SFTP/FTPサーバ用パスワード変更」で確認できます。
パスワードが不明な場合も同じ画面で新しく発行し、大文字・小文字・数字を含む8文字ちょうどで設定します。
| フォルダ・確認事項 | 確認できる扱い |
|---|---|
| ritem/logs/以下 | 保存された日から7日後に自動削除 |
| ritem/download/以下 | 保存された日から7日後に自動削除 |
| 上記へ店舗がアップロードしたファイル | 同じく削除対象 |
| 商品CSVのアップロード先 | RMSの管理画面内の案内から確認 |
| 取り込み対象CSVの処理直後の削除条件 | 公開情報では確認できません |
7日後の削除は指定されたフォルダの保存期間であり、アップロードしたCSVが処理直後に消えるという説明ではありません。
ファイルが消えたことだけで成功と判断せず、ログやダウンロードデータは、削除前に店舗側へ確保します。
前回のCSVの使い回しと同時編集を防ぐ方法
前回のCSVは作業項目の参考にとどめ、今回投入する値は最新情報から作成して、他の更新と重ならないようにします。
| 起こり得る事故 | 防ぐための運用 |
|---|---|
| 前月の価格で今月の改定を上書き | 最新情報と今回の承認価格を照合 |
| 前回の対象商品をそのまま更新 | 今回の追加・終了・継続対象を確認 |
| 古い在庫数量を再投入 | 基準時点を記録し、最新数量から作成 |
| 修正前のファイルを再送 | 旧版を使用対象から外し、修正版を明示 |
| 別担当者の変更を上書き | 同じ商品・項目を更新する作業時間を調整 |
CSVの処理中もRMS画面やAPIから編集できますが、複数経路で更新すると、最後に処理された情報が反映されます。
カテゴリ登録用CSVの「表示先カテゴリ」に、店舗内カテゴリに存在しない名前を入れると、新規カテゴリとして登録されます。そのため、カテゴリ名の変更中に古い名前のCSVを処理すると、変更前の名前でカテゴリが新しく作られる場合があります。
item-cat.csvの「u」は優先度の更新だけに有効で、紐付け先の変更は「d」で解除後、「n」で登録します。
カテゴリの削除・解除を伴う作業では、変更前の情報を確保し、他担当者によるカテゴリ編集も予定表で調整します。
タスク スケジューラでCSV転送を自動化する手順と注意点
WinSCPのスクリプトでopenによる接続とputによるアップロードを設定し、起動時に/scriptでスクリプト、/logでログ保存先を指定します。転送用バッチを作り、Windowsのタスク スケジューラから起動するよう登録します。骨組みは次の3つです。接続先のホスト名・ユーザー名・アップロード先フォルダは、RMSのFTP/SFTPの案内で自店の値を確認して置き換えます。
- WinSCPのスクリプト(例:upload.txt):1行目に
open sftp://<ユーザー名>@<接続先ホスト>/、2行目にput <パソコン側のCSV> <アップロード先フォルダ>/、3行目にexitを書きます。 - 転送用バッチ(例:upload.bat):
winscp.com /script=upload.txt /log=upload.logの1行で、スクリプトを実行してログを残します。 - タスクの登録:
schtasks /create /tn "楽天CSV週次" /tr "<upload.batのフルパス>" /sc WEEKLY /d MON /st 09:00のように、名前・起動するバッチ・予定をまとめて指定します。
schtasksで週・月の実行予定を指定する例は次のとおりです。
| 起動する予定 | スケジュール指定例 |
|---|---|
| 毎週月曜日の午前9時 | /sc WEEKLY /d MON /st 09:00 |
| 毎月1日の午前9時 | /sc MONTHLY /d 1 /st 09:00 |
これは転送用バッチの起動予定を指定する部分であり、楽天側の反映時刻を予約する設定ではありません。
WinSCPの終了コードは、エラーなどで中断した場合が1、それ以外が0です。終了コードと転送ログで成否を確認し、0でも楽天側の処理結果と商品への反映は別に確認します。
Macでは、Cyberduck CLIのduckコマンドで--uploadを使うスクリプトを作り、launchdのStartCalendarIntervalで曜日・日・時・分を設定します。Appleの時刻指定ジョブの資料では、予定時刻にスリープしていた場合は復帰後に実行されますが、電源が切れていた場合は次の予定時刻まで実行されないと説明されています。
定期転送で特に起きやすいのが、予約した時点のCSVが実行時には古くなっている問題です。在庫や価格は予約後にも変わるため、送信用フォルダには「次回の実行で送ってよい承認済みの1ファイル」だけを置き、前日までに最新の内容で作り直します。item-cat.csvのようにファイル名が決まっているCSVは、毎回同じ名前で上書きされるため、承認した日時と担当者を別の記録に残し、送信用フォルダに置く直前に版を照合します。
自作する場合は、次の運用も必要です。
- 認証情報を平文のスクリプトや共有フォルダへ置かず、安全な保管方法を選びます。
- 実際の実行アカウント、保存済み接続設定、作業フォルダ、ファイルのアクセス権で試します。手動では成功するのにタスクでは失敗する場合は、この順で、タスクを実行するアカウントで接続設定とフォルダが見えているかを確認します。
- 電源・スリープ・通信状態を確認し、未実行や送信失敗に気づく通知を用意します。
- ログと終了結果を保存し、楽天側の結果確認が未実施の作業も追えるようにします。
CSV定期アップロードの実行の記録
実行の記録には、日時・ファイル名・件数・エラー・担当を残し、次回の更新と再送判断に使える形にします。
| 記録項目 | 残す内容 |
|---|---|
| 日時 | 送信予定、実際の送信、結果確認、復帰の日時 |
| ファイル名 | 実際の転送名、版、店舗側の保存場所 |
| 件数 | データ行数、対象商品数、対象SKU数を区別 |
| エラー | メールの件数、ログの内容、対象行、修正状況 |
| 担当 | 作成者、実行者、確認者、異常時の判断担当 |
| 結果 | 更新を確認した範囲、未確認の範囲、再送ファイル |
メールのエラー件数は登録できなかったレコード数であり、ログには登録できなかった項目の理由が出力されます。
例えば一行に4つのエラーがある場合、メールではエラー1件、ログでは4行のエラー内容となります。
件数が一致しないことだけで処理異常とせず、行数と理由を分けて記録し、次回のCSV作成にも修正内容を引き継ぎます。
よくある質問(FAQ)
毎週同じCSVをそのまま送ってもよいですか
同じ作業でも対象や値が変わるため、今回の最新情報と照合し、内容を確定してから送信する運用を勧めます。
特に在庫は注文や入荷で変わるため、前回の数量を再送せず、基準時点を決めて作成します。
新しい商品登録も定期アップロードで行えますか
RMSのマニュアルでは、CSV商品一括編集機能で通常購入商品の新規登録・更新・削除ができると案内されています。ただし、くり返しの転送に新規の商品登録を混ぜると、商品管理番号の誤りで意図しない商品が増えても気づきにくくなります。
本記事の定期転送は、登録済み商品の更新に絞る運用を勧めます。新しい商品登録は別の作業として人が転送し、商品ページの表示まで確認してから、次回以降の更新対象に加えます。
ファイル名に日時を入れれば予約できますか
ファイル名に入れた日時は管理用の識別情報であり、その日時に取り込みを始める予約指定にはなりません。
商品更新用はnormal-itemで始め、カテゴリ登録用はitem-cat.csvという指定を守ります。
サーバーからファイルが消えたら成功ですか
ファイルが消えたことだけでは成功と判断できないため、処理結果と対象商品の変更内容を確認します。
ritem/logs/とritem/download/以下には7日後の自動削除があるため、記録を別に保存します。
メールとログのエラー件数が違うのはなぜですか
メールは登録できなかったレコード数、ログは項目ごとのエラー理由を示すため、件数が異なる場合があります。
記録では両者を別欄に残し、エラー理由を確認してから、修正する行と再送範囲を決めます。
月に一度しか使わなくても料金はかかりますか
CSV商品一括編集機能は月額11,000円(税込)で、利用の有無にかかわらず基本料金が発生します。
月の途中から利用を開始しても満額の請求となるため、定期運用を始める月と申込状況を確認します。
店舗の「次の一手」を一緒に進めるなら
AI社員アプリ・運営代行・ECコンサルまで、現場を知るチームがワンストップで伴走します。
西尾 勝太株式会社ラクダ 代表
楽天SOY 2年連続受賞 / 楽天NATIONSリーダー店舗 / 楽天NATIONS AIエバンジェリスト
楽天市場の月商を5年で200万円→2億円に伸ばした現場の実践者。売れるECの方程式にAIを重ね、EC事業者の「次の一手」に伴走しています。
西尾勝太のブログを読む




