RMS APIは、楽天市場の店舗運営で使うRMSの外部連携用WEB SERVICEです。自社開発なら申請→アプリ登録→利用設定→接続確認、外部製品なら提供企業との契約と承認が起点になります。
RMS APIとは何か
RMS APIは、楽天市場の店舗運営で使うRMSの外部連携用WEB SERVICEを指します。RMSは、楽天市場の店舗運営に使う管理システムで、会員向けの買い物画面や他サービスの管理画面とは別です。店舗側の業務を自動化・省力化するために、受注、在庫、商品、問い合わせなどのデータを外部システムとやり取りします。()
RMS WEB SERVICEとしての意味
RMS APIは、RMSに登録された店舗データを読み書きするためのAPI群です。たとえば、受注情報を取り込んで出荷処理へ回したり、在庫数を更新したり、商品情報を一括で変更したりできます。楽天市場の店舗運営に必要な処理を、手作業ではなくシステム連携で進めるための入口だと考えると分かりやすいです。()
楽天会員向けAPIや他のRMS表記との違い
「RMS」という言葉は、楽天市場の店舗運営システムを指す場合もあれば、別サービス名やログイン画面の名称として見える場合もあります。ここで扱うRMS APIは、あくまで楽天市場の店舗運営向けです。楽天会員向けの公開APIや、購入者向けサービスとは用途も前提も異なります。店舗運営の文脈で言うRMS APIは、売る側の業務を動かすためのAPIです。()
RMS APIの導入区分と申請の流れ
導入の考え方は、自社で開発するか、外部製品を使うかで分かれます。どちらもRMS側のデータに接続しますが、最初に必要な手続きが違います。()
自社開発と外部製品で何が違うのか
自社開発では、利用したいAPIを選び、RMSで申請し、アプリを登録し、認証情報を受け取り、必要な機能を有効化します。つまり、店舗側で導入作業を進める前提です。
一方、RMSサービススクエアの参加企業が提供するアプリや連携製品は、提供企業との契約後に店舗データへのアクセスを承認する流れが中心です。通常は、店舗がAPIごとの細かな設定を一つずつ行う必要はありません。外部製品は、RMS本体の標準機能とは分けて契約・費用・操作窓口を確認します。(、)
利用申請から接続確認までの流れ
自社開発の場合は、次の順で進めます。
- 使うAPIのリファレンスを確認する
- RMSのWEB APIサービスから利用申請する
- アプリ登録を行う
- 自動発行されたserviceSecretとライセンスキーを確認する
- 必要なAPI機能を利用設定する
- 約10分置いて接続を確認する
ここで大事なのは、設定直後にすぐ本番連携が安定するとは限らないことです。反映待ちのあいだに通信確認を急ぐと、まだ有効化されておらず失敗したように見えることがあります。()
RMS APIで使う認証情報と有効期限
RMS APIでは、一般的なログインIDやパスワードではなく、ライセンスキーとserviceSecretを使います。ライセンスキーはAPI利用に使う認証情報で、serviceSecretはそれと組み合わせて認証する情報です。serviceSecretは期限なしで、店舗のRMS上には表示されない外部製品側の管理情報として扱われます。()
注意したいのは、注文情報や個人情報を扱う対象APIでは、ライセンスキーに90日の有効期限が付くことです。対象には楽天ペイ受注API、購入商品API、購入申込API、問い合わせ管理APIなどが含まれます。期限の7日前から通知が届き、期限切れになるとAPI処理はエラーになります。さらに、期限切れのまま1年以上放置すると、該当サービス情報が自動削除されます。キーの更新後は、連携先システム側の更新も必要です。()
また、有効なキーがすでに2件あると新しいキーの発行でエラーになります。不要になったキーを整理してから更新する運用が必要です。外部製品のキーは、一度停止すると再開できない場合があるため、どのシステムがどのキーを使っているかを先に確認しておくと安全です。()
RMS APIで扱える主な機能
RMS APIは、単一の機能だけを指すのではなく、受注・在庫・商品・画像・カテゴリ・問い合わせ・通知など、店舗運営に必要な複数のAPI群で構成されています。まずは何のデータを動かしたいかで、見るべきAPIが変わります。()
受注・在庫・商品・問い合わせ・通知のAPI
店舗運営でよく見るAPIは、次のように整理できます。
| 用途 | 主なAPI |
|---|---|
| 受注 | RakutenPayOrderAPI、PurchaseItemAPI、ReserveAPI |
| 在庫 | InventoryAPI 2.0、InventoryAPI 2.1 |
| 商品 | ItemAPI 2.0、ItemBundleAPI、ProductAPI |
| 画像 | CabinetAPI |
| ジャンル・属性 | NavigationAPI 2.0 |
| カテゴリ | CategoryAPI 2.0 |
| 店舗・ページ | ShopAPI、ShopPageAPI |
| クーポン | CouponAPI |
| 問い合わせ | InquiryManagementAPI |
| 通知 | System Event Notification Service |
この中で、店舗運営の出発点としてまず確認したいのは、受注・在庫・商品です。受注は発送までの処理をつなぎ、在庫は売り越しや在庫差異の抑制に直結し、商品はページ更新や販売条件の変更に効くからです。()
店舗運営でまず見るべきAPIとInventoryAPI 2.1の上限
RMS APIを小さく始めるなら、まずは受注連携と在庫更新、次に商品更新を押さえるのが現実的です。これだけでも、日々の店舗運営の連携を組み立てやすくなります。
在庫系では、InventoryAPI 2.1に件数上限があります。確認できる範囲では、在庫数範囲などによる取得は最大1,000件、指定SKUの一括取得も最大1,000件、一括登録・更新は最大400件です。これは在庫APIの個別仕様であって、RMS API全体の共通上限ではありません。()
RMS APIの運用上の注意点
導入の可否を判断するときは、「使えるか」だけでなく、「いつ使えるか」「何を扱うか」「どこまで自前で管理するか」まで見ておく必要があります。APIは設定した瞬間に全て安定稼働するわけではありません。()
利用設定後すぐに使えるのか
利用設定を済ませても、反映には少し時間がかかります。RMSの案内では、接続確認まで約10分置く流れが示されています。したがって、設定直後にエラーが出ても、まずは反映待ちかどうかを切り分けるのが先です。
また、外部製品やRMSサービススクエアを使う場合は、API利用条件と外部製品の費用を分けて考える必要があります。RMS本体の設定だけで完結する話ではなく、提供企業との契約やアクセス承認が別にあります。(、)
個人情報を扱うときに何に注意するのか
注文情報や問い合わせ情報を扱うAPIは、個人情報を含む前提で考える必要があります。認証情報を安易に共有しないことはもちろん、権限管理と保存範囲の設計を先に決めます。
RMSの公開案内でも、受注情報や問い合わせ情報を扱うAPIではライセンスキーに有効期限があり、期限切れで処理がエラーになることが示されています。つまり、セキュリティと期限管理は切り離せません。()
制限応答や再試行はどう考えるか
現時点で確認できる資料では、RMS APIの制限応答時の具体的な再試行回数や待機時間までは断定できません。したがって、レート制限の数値を前提にした設計を、確認なしで決め打ちしないことが大切です。
実務上は、まず反映待ち、キー期限切れ、アクセス許可状態、連携先の更新漏れを切り分けます。API自体の失敗に見えても、原因は認証情報や設定反映のことが少なくありません。細かな再試行設計は、各APIの現行仕様を確認したうえで決めるのが安全です。()
RMS APIを使うときの実務イメージ
RMS APIの価値は、API名そのものより、日々の店舗運営でどの作業をつなげられるかにあります。受注、在庫、商品更新のどれを自動化するかで、効果の出方が変わります。
受注連携や在庫更新はどう役立つのか
受注連携は、注文データを外部システムへつなぐ起点になります。出荷指示やステータス更新を別システムへ渡しやすくなります。
在庫更新は、売り越しや在庫差異の抑制を狙いやすくなります。複数店舗を運営しているなら、在庫を同じ基準で扱えること自体が大きなメリットです。InventoryAPI 2.1のようなAPIを使えば、在庫数やリードタイムの更新をまとめて扱えます。()
商品更新や問い合わせ管理はどの場面で使うのか
商品更新は、価格変更、説明文の修正、販売開始日の切り替えなど、商品ページの変更が多い店舗で効きます。手動更新のままだと、モールごとに反映漏れが起きやすいからです。
問い合わせ管理APIは、購入後の連絡や問い合わせ対応を業務フローに載せたいときに使います。個人情報を扱うため、導入時は権限管理と保存範囲の設計を先に固めておくべきです。()
まとめ
RMS APIは、楽天市場の店舗運営で商品・在庫・受注などを外部システムから扱うための連携手段です。自社開発なら申請・アプリ登録・利用設定・接続確認、外部製品なら提供企業経由の承認が基本になります。
まずは受注・在庫・商品を中心に見て、注文情報や個人情報を扱うAPIではライセンスキーの期限管理も必要です。外部製品の費用はAPI利用条件と切り分けて考え、設定直後は反映待ちがあることも前提にしておくと、導入判断を誤りにくくなります。