RMS（Rakuten Merchant Server）は、楽天市場に出店する店舗が、商品・在庫、受注・配送、購入者対応、販促、分析などを管理する店舗運営基盤です。少数の修正は画面、大量更新はCSV、他システムとの継続的な連携はRMS WEB SERVICE（API）や対応する外部サービスを検討すると、業務に合う方法を選びやすくなります。

この記事では、RMSで扱える業務の範囲と、画面・CSV・API・外部ツールの役割分担を整理します。特に、商品・SKUの更新、在庫連携、受注・配送、購入者対応、外部連携時の権限と認証情報に焦点を当てます。

RMS機能の全体像：楽天市場の店舗運営を業務別に管理する基盤

RMSは、楽天市場の店舗運営に必要な複数の業務を、店舗向けの管理画面から扱うシステムです。商品やページの設定、SKU単位の在庫・価格・販売状態、受注や発送完了報告、購入者からの問い合わせ、販促施策、売上・アクセス分析などが主な対象になります。機能の概要は、楽天市場の店舗運営Naviでも確認できます。

機能はメニュー名ではなく、業務単位で見ると役割を整理しやすくなります。

業務	RMSで扱う主な内容
商品・在庫	商品情報、SKU、価格、在庫数、納期、販売期間、公開・非公開状態
受注・配送	受注データ、注文確認、発送完了報告、帳票、配送情報
購入者対応	R-Messeによる問い合わせ管理、注文関連の連絡、メール送信
販促・分析	クーポン、R-Mail、売上・アクセス分析、販促効果の確認
連携・自動化	CSV一括編集、RMS WEB SERVICE、サービススクエアの外部サービス

ただし、表示されるメニューや利用できる操作は、R-Loginの利用者権限、スタッフの有効期限、オプションの申込状況、契約状態によって変わります。担当者の画面に機能が見当たらない場合は、機能が存在しないと判断する前に、権限と申込状況を確認してください。

商品・在庫を更新するRMS機能と、画面・CSV・APIの選び方

RMSの商品管理では、商品共通情報、商品オプション、SKU情報を分けて扱います。色やサイズなど在庫を分けるバリエーションはSKUで管理し、価格・在庫数・納期などもSKU単位で設定します。シングルSKUの商品でもSKU情報は必要です。

在庫数は販売を制御するための値であり、物理倉庫にある数量と必ずしも同じではありません。通常は在庫が0になると注文受付が止まりますが、在庫切れ時の注文受付を有効にすれば、在庫が0でも注文を受けられます。この場合は、実際の調達・発送予定と納期表示が一致しているかを確認します。

「倉庫指定」は、物流倉庫やRSLの入庫先を指定する設定ではありません。商品やSKUを販売表示するかどうかを制御する項目です。商品を編集した結果、意図せず公開状態が変わる場合もあるため、価格や説明文だけを変更したつもりでも、商品・SKUの販売状態を確認してください。詳しくは商品・SKU・在庫に関する公式案内を参照できます。

少数変更は画面、大量・定期更新はCSV、他システム連携はAPIを検討する

更新方法は、変更量と連携の必要性で選びます。目安は次のとおりです。

状況	向いている方法	理由
数商品だけを修正する	RMS画面	変更対象を確認しながら更新しやすい
多数の商品・SKUをまとめて修正する	CSV一括編集	同じ項目をまとめて処理しやすい
倉庫・基幹システムなどと定期連携する	RMS WEB SERVICE（API）や対応外部サービス	毎回のファイル作成・投入を減らしやすい

在庫変動が多い店舗では、更新頻度だけでなく、どのシステムを正しい在庫の基準にするかを決めます。倉庫側とRMS側の双方から更新すると、後から保存された値で上書きされる可能性があるためです。自動連携を導入する場合も、反映間隔、処理の遅れ、エラー時の再処理、手作業による臨時更新の扱いをあらかじめ決めておきます。

CSV一括編集で確認したい行構造・空欄・更新競合

商品CSVは、商品・オプション・SKUの行構造を保ったまま編集します。同じ商品管理番号に属するSKU行は連続させ、途中に別の商品を挟まないことが重要です。商品共通情報、オプション、SKU情報を別の行として扱うため、行構造を崩すと意図しない商品・SKUに更新が適用されるおそれがあります。

列を省略することと、列を空欄にすることは同じではありません。 空欄が既存値の削除や初期値への復帰として扱われる項目があるため、変更しない列を一律に空欄にしてアップロードするのは避けます。RMSから取得したテンプレートを基に、変更対象の列だけを編集してください。

CSVをExcelで開く場合は、商品管理番号やSKU管理番号の先頭ゼロ、大文字・小文字、長い識別子が自動変換されないよう、文字列として取り込みます。アップロード後は完了メールだけで判断せず、正常件数・エラー件数・ログを確認し、RMS画面と商品ページで反映結果を確認します。現行の項目形式は商品CSVのデータ形式、一括登録の注意点は一括登録・変更の案内で確認できます。

外部の在庫データを連携する場合の考え方

倉庫やメーカーなど、外部にある在庫データをRMSへ反映する場合は、RMS WEB SERVICEとInventoryAPI 2.1を使った連携を検討できます。InventoryAPI 2.1では、商品管理番号とSKU管理番号を基に、在庫数、出荷リードタイム、配送リードタイムを取得・登録更新・削除できます。1回の処理上限として、取得は最大1,000件、一括登録・更新は最大400件と案内されています。

外部システムから在庫情報を取得してRMSへ更新する構成は可能ですが、Googleスプレッドシートを中継する仕組みがRMS標準機能として提供されているわけではありません。スプレッドシートを使う場合は、対応する外部サービスまたは自社開発の連携仕様として、契約条件、対象項目、実行間隔、エラー時の扱いを確認します。

在庫APIを使う場合も、連携できることと安全に運用できることは別です。倉庫側の在庫確定時刻、RMSへの反映遅延、注文発生と在庫更新が重なる時間帯、在庫差異が出た場合の優先データを決めてから自動化します。APIの機能範囲は、RMS WEB SERVICEの案内と在庫API 2.1の公式案内で確認できます。

受注・配送・購入者対応でRMSにできること、外部システムに分かれること

RMSでは、受注データのダウンロード、注文確認や発送完了報告のCSVアップロード、受注明細票やお買い上げ明細書の作成などを行えます。購入者対応では、R-Messe、注文詳細からの問い合わせ、あんしんメルアド簡易送信、販促用のR-Mailを使い分けます。

一方で、送り状発行、倉庫への出荷指示、複数モールの在庫調整、同梱などは、配送会社・OMS・物流サービス側の機能と分担する場合があります。RMSにある受注情報を、配送や物流の処理まで同じ画面で完結できると考えず、注文の確定、出荷指示、送り状作成、発送結果の反映をどのシステムが担当するか整理してください。

受注CSVは商品CSVとは別のサービスです。ファイル形式、申込状況、アップロード対象が異なるため、商品一括編集用のCSVと同じ手順・認証情報で扱わないようにします。

発送完了報告・帳票・配送会社連携の役割分担

RMSでは、発送日、配送会社、伝票番号などを含む発送完了報告を登録できます。受注明細票は梱包や配送伝票の確認に、お買い上げ明細書は注文内容を商品に同封する資料として使います。ただし、受注明細票は複数注文を商品単位で集約するピッキングリストと同じものではありません。

配送会社との連携では、RMS側の設定だけでなく、配送会社側の契約・顧客コード・認証情報・送り状作成環境を分けて確認します。たとえばヤマト運輸のB2クラウド連携では、集荷契約、顧客コード、B2クラウドAPI認証情報が前提になります。RMSで配送会社や伝票番号を管理できても、配送会社との契約や送り状発行環境が自動で用意されるわけではありません。

発送完了報告をCSVで更新する場合は、追加登録と既存情報の修正を区別します。発送明細IDを空欄にすると新しい発送完了報告として追加されるため、既存の発送情報を修正する際にIDを落とさないよう注意してください。

OMS・物流サービスを使う場面と、同梱処理で確認すべきこと

OMS（Order Management System）は、注文の取り込み、受注処理、在庫調整、出荷指示などをまとめて扱うシステムです。BOSSなどのOMSを利用する場合、RMSは楽天市場側の注文・商品情報を管理し、OMSは複数チャネルの受注や倉庫への出荷指示を担う、というように役割を分けて考えます。RSLへの出荷連携にも、BOSSなどのOMSを介する構成が必要です。

複数注文を1件にまとめる同梱処理については、現時点では、RMS標準機能だけで実施できるか、利用中のOMSや物流サービスで注文統合できるかを確定できません。導入前に、利用するOMS・物流サービスの仕様と、RMS側の受注・発送完了報告の扱いを確認してください。

同梱を検討する際は、次の処理をどこで行うかを確認します。

• 注文を統合した後の受注金額・決済状態
• 送料やクーポンの扱い
• 発送完了報告と伝票番号の登録方法
• 購入者への注文統合・発送連絡
• キャンセル、返品、個別発送が発生した場合の分離方法

なお、RMSの商品・SKUにある「倉庫指定」は公開・非公開の設定であり、物理倉庫への出荷指示ではありません。販売状態と物流処理を混同しないことが前提です。

購入者対応の自動化は在庫連携と別に設計する

購入者対応の自動化は、在庫連携とは別の業務として設計します。R-Messeは購入者からの問い合わせ管理、R-Mailは販促メルマガ、あんしんメルアド簡易送信は受注関連のメール送信であり、それぞれ目的が異なります。

在庫情報の取得にはInventoryAPI 2.1を使えますが、問い合わせ対応にはInquiryManagementAPIなど別のAPIや権限が関係します。在庫APIが使えるからといって、問い合わせの取得・返信やメール送信まで同じ方法で自動化できるとは限りません。

外部連携で問い合わせ対応を組み込む場合は、問い合わせの取得範囲、返信可否、未返信・完了状態の更新、返信内容の人による確認、個人情報の保管場所を確認します。メールを送信しただけでR-Messeの未返信状態が自動的に変わるとは限らないため、確実な状態管理が必要な場合はR-Messe画面または問い合わせ管理APIの仕様を確認してください。

販促・分析・運営支援に使えるRMS機能

RMSには、店舗運営の改善を支える販促・分析・支援機能もあります。商品や受注を直接更新する機能とは目的が異なるため、「施策を実行する機能」と「結果を確認する機能」を分けて見ると活用しやすくなります。

主な用途は次のとおりです。

• R-Karte：売上、アクセス、転換率、客単価、流入元、商品別実績、販促効果などの分析
• RaCoupon：定額・定率・送料無料などのクーポン設定と配布
• R-Mail：購入履歴や会員属性などで対象を絞った販促メルマガ
• AI支援：問い合わせ回答の作成・校正や、商品バナー作成の補助
• RMSアプリ：売上確認、商品編集、在庫・価格・販売期間の一部更新、R-Messe対応

R-KarteとRaCouponで売上・アクセス・施策結果を確認する

R-Karteでは、目的に応じて店舗カルテ、商品分析、流入元・検索キーワード分析、販促効果測定、リアルタイム売上などを使い分けます。売上だけでなく、アクセス数、転換率、客単価、商品別の実績、流入元、クーポンなどの施策結果を同じ期間・指標で比較することが重要です。

RaCouponでは、開始・終了日時、対象商品、割引内容、公開範囲、利用回数、会員ランクなどの条件を設定します。特定の購入者向けに配布する場合は限定公開を選ぶなど、公開範囲を確認してから登録します。対象外の商品がエラーとして除外される場合もあるため、登録後はエラー一覧と実際の配布条件を確認してください。

分析では、RMSの売上指標と、決済確定額や銀行への入金額を同じものとして扱わないようにします。施策の効果を判断するときは、クーポンの条件・実施期間と分析データの対象期間をそろえます。機能概要は楽天市場の公式案内で確認できます。

R-Mail、AI支援、RMSアプリは日常業務を補助する

R-Mailは販促メルマガ、問い合わせ回答支援AIは購入者対応、商品バナー作成支援AIはクリエイティブ作成を補助する機能です。生成された回答や画像は、商品条件、返品条件、価格、納期、ブランド表現などを人が確認してから使用します。

RMSアプリでは、売上確認、商品名・キャッチコピー・価格・在庫・販売期間などの一部編集、R-Messe対応、受注の確認などができます。ただし、ブラウザ版RMSの全機能を代替するものではありません。複雑な商品設定、CSV一括編集、詳細な権限設定、APIや外部サービスの管理などは、PC版の画面や別の管理機能を前提に考えます。

アプリの対応OSや機能範囲は更新される可能性があります。外出先での確認・軽微な修正にはアプリ、大量更新や複雑な設定にはブラウザ版というように、業務の性質で使い分けてください。対応範囲は公式のRMSアプリ案内で確認できます。

CSV・API・外部サービスを使う前に確認すること

CSV一括編集、RMS WEB SERVICE、サービススクエアは、いずれも店舗運営を効率化できますが、仕組みと責任範囲が異なります。

方法	役割	向いている場面
CSV一括編集	店舗側でファイルを作成・編集し、商品情報などをまとめて更新する	大量の商品・SKUを一度に更新する
RMS WEB SERVICE	外部システムがRMSの注文・商品・在庫などをAPIで取得・更新する	継続的なシステム連携や自動化を行う
サービススクエア	外部企業の製品や委託サービスを探して契約する	自社開発をせず、既製サービスを導入する

サービススクエアの製品はRMS標準機能ではありません。費用、契約期間、対象データ、サポート窓口、無料トライアル終了後の条件などを製品ごとに確認します。外部サービスを使う場合も、RMS側のアクセス許可と、提供企業側の仕様・障害対応を分けて確認してください。

外部連携の前に対象データ・更新時刻・失敗時の処理を決める

外部連携を導入する前に、何を自動化するかを項目単位で決めます。商品CSVには販売開始日時・販売終了日時やSKUの表示価格が含まれますが、これらを特定のAPIや外部ツールから更新できるかは、連携先の対応範囲によって変わります。APIの名称が存在することだけで、すべての商品項目を更新できるとは判断できません。

セールや期間限定販売の前後に連携を使う場合は、次の点を確認します。

• 注文、在庫、商品、販売期間、表示価格のうち、どの項目を扱えるか
• 即時処理か、一定間隔の予約実行か
• RMSへの反映までにどの程度の遅延があるか
• エラー時に再処理できるか、重複更新を防げるか
• CSVやRMS画面での臨時更新と競合しないか
• 更新後に商品ページ、在庫数、販売状態をどこで確認するか

販売開始・終了日時や価格は、更新の遅れが販売機会や誤販売につながる可能性があります。利用するAPIや外部サービスの対応項目と実行タイミングを確認し、少数商品で検証してから対象を広げます。

アクセス許可と認証情報は最小権限で管理する

外部システムへ注文・商品・在庫データへのアクセスを許可する前に、アクセス対象と契約条件を確認します。自社開発では、RMS WEB SERVICEの利用申請、アプリ登録、必要なAPIの利用設定、認証情報の管理が必要です。サービススクエアの外部製品では、提供企業との契約後に店舗データへのアクセスを承認します。

確認項目は次のとおりです。

• 取得・更新できるデータ項目と、読み取り・書き込みの別
• 追加APIの承認が必要か
• 連携を停止・否認した場合の業務への影響
• 外部サービスの契約終了時にデータや設定がどうなるか
• 注文情報や個人情報をどこで保管し、誰が閲覧できるか
• エラーや障害が起きたときの問い合わせ先

RMSへのログイン情報、SFTPのパスワード、APIのライセンスキー、serviceSecretは別物として管理します。担当業務に必要な範囲だけを許可し、利用者の異動や契約終了時には権限を見直します。注文情報・個人情報を扱う対象APIでは、ライセンスキーに90日の有効期限が設定される場合があるため、期限通知と更新担当も決めておきます。

自動化後も店舗側に残る確認業務

自動化によって、ファイル作成、アップロード、在庫転記、定型的な受注処理などの反復作業を減らせる可能性があります。ただし、自動化は店舗側の確認をなくすものではありません。

少なくとも次の確認は残ります。

• 商品ページの公開・非公開状態
• 在庫数や納期の差異
• CSV・APIの処理結果とエラー
• 注文統合、キャンセル、返品などの例外処理
• 問い合わせの未返信・完了状態
• アクセス権限と認証情報の有効期限

導入前に、「どの作業を減らしたいのか」「失敗時に誰が対応するのか」「最終確認をどの画面や帳票で行うのか」を決めてください。自動処理の対象範囲を一度に広げるより、少数の商品や限定した業務で反映結果を確認し、例外処理まで運用できることを確かめてから拡張する方が安全です。認証情報は社内手順書、チャット、問い合わせ文面、生成AIへの入力にそのまま載せないでください。

まとめ

RMSは、楽天市場の店舗運営に必要な商品・在庫、受注・配送、購入者対応、販促、分析を業務別に管理する基盤です。少数の変更は画面、大量の更新はCSV、他システムと継続的に連携する業務はRMS WEB SERVICEや対応する外部サービスを検討します。

選定時は、更新量だけでなく、RMSと外部システムの役割、反映タイミング、CSVの空欄やSKU行構造、更新競合、アクセス許可、認証情報の管理まで確認してください。特に同梱や物流処理、販売期間・価格の自動更新は、RMS標準機能だけで決めつけず、利用するOMS・物流サービス・APIの対応範囲を確認することが重要です。