Shopifyと楽天を連携する前に決める業務設計｜RMS・在庫・受注・配送の実務チェック

「shopify 楽天 連携」で調べる人の多くは、Shopifyの商品を楽天市場にも出したい、楽天注文をShopify側で見たい、在庫を二重管理したくない、という課題を持っています。

方向性は自然です。Shopifyは自社EC、ブランド体験、顧客データ、外部連携の中心に置きやすく、楽天市場は日本国内の検索、ポイント経済圏、セールイベント、レビュー、モール内回遊に強いからです。

一方で、楽天連携を「商品をコピーして在庫と注文を同期する設定」とだけ捉えると、あとから次のような問題が出ます。

• Shopify SKUと楽天RMSの商品番号・商品管理番号・SKU管理番号が対応しない
• 楽天の商品ページ必須項目やバリエーションがShopifyの商品構造と合わない
• 楽天側のポイント、クーポン、スーパーSALE、お買い物マラソンの条件が粗利に反映されない
• 楽天ペイの受注処理、出荷連絡、問い合わせ、レビュー対応がShopifyだけでは完結しない
• RMS、OMS、WMSのどこで在庫を引き当てるか曖昧なまま売り越す
• キャンセル、返品、欠品、同期エラーが起きたとき、どの画面で直すか分からない

連携手順やメリットは、FinnerのShopifyと楽天市場の連携方法、Shopify公式ブログのShopifyと「楽天市場」の販売チャネル連携がスタート、OpenLogiのShopifyと楽天市場の連携方法が参考になります。楽天とShopifyの公式発表としては、2020年のRakuten Ichiba Japan Marketplace Opens Up to Shopify Merchantsで、Shopify管理画面から楽天市場店舗の商品登録、在庫、注文管理を支援するサービスが説明されていました。

ただし、販売チャネルやアプリの提供状態、RMS API、OMS/WMSの対応範囲は変わります。この記事では、2026年7月3日時点で確認できる公開情報を前提にしつつ、導入時には必ず最新のShopify App Store、楽天RMS、各OMS/WMS公式情報を確認する前提で整理します。

Shopifyと楽天の連携で最初に決めるべきなのは「どのアプリを入れるか」ではなく、商品・在庫・注文・出荷・粗利の正本をどこに置くかです。

結論：楽天RMSとShopifyの責任分界を先に決める

Shopifyと楽天市場の連携は、1本の同期設定ではありません。

最低でも、次の責任範囲を分けます。

領域	Shopifyに寄せる役割	楽天RMSに残る役割	設計で決めること
商品マスタ	商品名、SKU、画像、バリエーション、メタフィールド	商品管理番号、商品番号、SKU管理番号、楽天カテゴリ、商品ページ項目	どちらを商品正本にし、どの項目を相互参照にするか
在庫	Shopifyロケーション、販売可能数、他チャネル在庫	楽天上の販売可能在庫、倉庫指定、在庫表示	在庫正本をShopify、OMS、WMSのどこに置くか
受注	受注確認、顧客対応候補、会計連携候補	楽天ペイ、支払状態、配送ステータス、モール注文番号	楽天注文をどの状態で取り込むか
出荷	WMS連携、追跡番号、出荷完了、タグ	楽天側の出荷通知、配送条件、納期情報	出荷実績をどこからどこへ戻すか
販促	Shopifyクーポン、会員施策、CRM	ポイント、クーポン、スーパーSALE、お買い物マラソン、RPP広告	販促費を注文・SKU・日次のどの粒度で見るか
CS・レビュー	問い合わせ履歴、顧客メモ、再購入導線	楽天問い合わせ、レビュー、R-messeなど楽天内接点	どの問い合わせをShopify側へ転記・連携するか
会計・粗利	売上、返金、手数料候補、会計連携	楽天側手数料、ポイント原資、クーポン、広告費、入金	モール費用込み粗利をどの台帳で確定するか
監視	同期ログ、Webhook/APIエラー、差分通知	RMSエラー、商品審査、店舗運用アラート	誰がどの画面で直すか

Shopify公式のApps as sales channelsでは、販売チャネルアプリはShopifyのオンラインストアと外部販売面を接続し、カタログを買い手のいる場所へ配信する考え方として説明されています。楽天連携もこの考え方で見ると分かりやすいです。

ただし、楽天市場は単なる外部カートではありません。RMSの商品ページ、楽天ペイ、ポイント、クーポン、広告、レビュー、問い合わせ、イベント参加条件が運用に深く関わります。Shopifyを中心にしても、楽天固有の業務は残ります。

Shopifyと楽天連携でできること・できないこと

過去の公式連携や解説記事では、Shopify商品を楽天へ出品し、在庫や注文を扱えることがメリットとして説明されてきました。一方で、現在のApp Store上で旧Rakuten Ichibaアプリが提供されていない表示である以上、導入では「公式アプリが使える前提」から始めるのは危険です。

現実的には、公式アプリ、国内OMS、WMS、API、CSVを組み合わせて、どこまで自動化するかを決めます。

領域	自動化しやすいこと	残りやすいこと	判断ポイント
商品登録	Shopify商品から楽天向け商品データを作る	楽天カテゴリ、商品属性、商品ページ作り込み、審査対応	RMS必須項目とShopify商品構造が合うか
在庫同期	SKU単位で楽天表示在庫を更新する	安全在庫、セット品、予約、イベント中の販売制限	在庫正本と引当タイミングを決めているか
受注取込	楽天注文をShopifyまたはOMSへ取り込む	楽天ペイの状態、保留、キャンセル、同梱、問い合わせ	出荷可能条件をどこで判定するか
出荷連携	WMSへ出荷指示し、追跡番号を戻す	配送方法差分、日時指定、ギフト、同梱不可	RMSとWMSの二重処理を避けられるか
販促	売価や一部キャンペーン条件を台帳化する	ポイント、クーポン、スーパーSALE、お買い物マラソン、広告	販促費を粗利へ反映できるか
CS・レビュー	注文情報や顧客メモを参照する	楽天問い合わせ、レビュー返信、モール規約対応	Shopify CRMへ何を渡すべきか
レポート	売上、注文、在庫を集計する	楽天手数料、ポイント原資、広告費、入金差分	注文単位か日次・月次集計か

「できること」は接続方式で変わります。重要なのは、できないことをRMS運用として残すのか、OMSやWMSで吸収するのか、独自APIやCSVで補うのかを先に決めることです。

先に決めるべきRMS vs Shopifyのシステムオブレコード

Shopifyと楽天のどちらを正本にするかは、商品、在庫、注文で分けて考えます。

データ	Shopify正本が向くケース	楽天RMS正本が向くケース	実務上の落としどころ
商品マスタ	Shopify本店が中心で、楽天は追加販路	楽天売上が大きく、商品ページ改善をRMS中心で回す	共通SKUとJANは共通台帳、楽天固有項目はRMSに残す
商品ページ	ブランド表現、画像、説明をShopify中心に作る	楽天SEO、レビュー、イベント訴求、商品属性が重要	Shopifyの商品情報をベースに、楽天用ページ項目を別管理する
SKU・バリエーション	Shopify variantを各販路へ配る	楽天SKUプロジェクト対応後のSKU管理番号を重視	Shopify SKUと楽天SKU管理番号の対応表を持つ
在庫	Shopify、Amazon、楽天、自社ECを少数運用	楽天販売量が大きく、RMS側調整が頻繁	多くはOMS/WMSを在庫正本にし、ShopifyとRMSへ配信する
注文	Shopify Ordersを受注ハブにしたい	楽天ペイ処理とモール対応をRMS中心で行う	OMSを受注ハブにし、Shopifyは自社EC注文と分析に寄せることもある
出荷	ShopifyからWMSへ流す	楽天注文の出荷処理をRMS/OMSで行う	出荷実績の戻し先をShopify、RMS、OMSで一意にする
粗利	Shopifyと会計を中心に見る	楽天店舗別の損益をRMS・広告・入金から見る	モール費用込み粗利は別台帳で確定する

小規模でShopify本店が中心なら、Shopifyを商品・在庫の正本に置き、楽天固有項目を補完する構成でも始められます。

しかし、楽天、Amazon、Yahoo!ショッピング、実店舗、卸、複数倉庫が絡むなら、Shopifyをすべての正本にするより、OMSやWMSを受注・在庫の正本にする方が崩れにくいことがあります。在庫連携の基本は、Shopify在庫連携の設計方法で整理しているように、どの数字を正とし、どのイベントで動かすかを決めることです。

SKU・商品番号・バリエーション・商品ページ項目のマッピング

楽天連携で最初に崩れやすいのは、SKUと商品番号です。

Shopifyでは商品にVariantがあり、SKUやbarcodeを持てます。楽天RMSでは、商品管理番号、商品番号、SKU管理番号、システム連携用SKU番号、商品属性、カテゴリ、商品ページ項目が絡みます。既存RMS商品を後からShopifyと連携する場合、楽天側の管理番号を変えにくいこともあります。

項目	Shopify側	楽天RMS側	設計方針
商品の親	Product	商品管理番号、商品URL	URLやレビューに影響するため、既存楽天商品は慎重に扱う
SKU	Variant SKU	SKU管理番号、システム連携用SKU番号、商品番号	受注・在庫・出荷で使う共通キーを先に決める
JAN・型番	barcode、metafield	JAN、カタログID、商品属性	商品審査、検索、外部連携に使うため台帳化する
バリエーション	色、サイズ、容量などのOptions	SKU単位、商品属性、選択肢	Shopifyの色・サイズ表記と楽天の属性を対応させる
商品説明	title、body、画像、metafield	商品名、キャッチコピー、PC/スマホ説明文、販売説明文	楽天用の訴求、検索語、イベント文言を別管理する
価格	price、compare-at price	通常価格、イベント価格、クーポン対象	価格差と粗利差を販売施策として管理する
配送条件	shipping profile、metafield	送料、配送方法、納期、倉庫指定	出荷システムと同じ分類にする

対応表には、少なくとも次を持たせます。

台帳項目	用途
Shopify product ID / variant ID	Shopify内の一意キー
Shopify SKU	自社EC、WMS、会計で使う候補キー
楽天 商品管理番号	楽天商品ページを特定するキー
楽天 商品番号	店舗側の商品識別、外部連携の候補キー
楽天 SKU管理番号 / システム連携用SKU番号	SKU単位の在庫・受注・連携で使うキー
JAN / 型番 / 原価	商品審査、出荷、粗利、会計で使う補助キー
販売チャネル状態	Shopify本店、楽天、Amazon、Yahoo!、実店舗の販売可否
同期方式	アプリ、OMS、WMS、API、CSV、手動のどれで更新するか

この台帳がないまま連携すると、楽天で売れた注文がShopify側のどのvariantか分からない、出荷後に追跡番号を戻せない、返品後にどのSKUへ在庫を戻すべきか分からない、という問題が起きます。

在庫同期、受注取り込み、出荷連携の基本フロー

在庫、受注、出荷は同じ連携に見えますが、実際には別の業務です。

業務	起点	主な処理	正本候補	注意点
在庫同期	入荷、出荷、棚卸、返品検品	販売可能数をShopify/RMSへ反映	WMS、OMS、Shopify	楽天へ全量を出さず、安全在庫を残す
受注取込	楽天注文発生、楽天ペイ状態更新	注文をOMS/Shopifyへ取り込む	RMS、OMS、Shopify	未確定・保留注文を出荷対象にしない
出荷指示	出荷可能判定	WMS、倉庫、シッピーノなどへ出荷依頼	OMS、WMS	RMSとWMSへ二重送信しない
出荷実績戻し	倉庫出荷完了	追跡番号、配送会社、出荷日を戻す	WMS、OMS	Shopify、RMS、顧客通知の戻し先を決める
返品・キャンセル	顧客依頼、楽天側処理	返金、検品、在庫復帰、会計補正	RMS、OMS、会計	返品受付だけで販売可能在庫に戻さない
欠品対応	在庫差分、出荷不可	代替、分納、キャンセル、連絡	OMS、CS台帳	楽天側の納期・キャンセル規定を確認する

物流寄りの自動化では、Shopify App Storeのシッピーノのように、Shopifyだけでなく楽天、Amazon、Yahoo!ショッピングなどの主要モール受注を一元化し、FBAマルチチャネルサービスやロジザードZEROなどへ出荷依頼できるツールがあります。受注・在庫・出荷を国内モール横断で見る場合は、GoQSystemやネクストエンジン自動連携のようなOMS連携も選択肢になります。

ただし、アプリを入れるだけでは、在庫正本は決まりません。Shopifyから物流倉庫へ出荷依頼するのか、OMSで楽天注文とShopify注文をまとめるのか、WMSが全チャネルの在庫を持つのかを先に決めます。

ポイント・クーポン・イベント価格・手数料を含めた損益設計

楽天連携をAmazon連携の焼き直しにしてはいけない理由は、楽天の販促設計が運用と利益に深く入り込むからです。

楽天では、ポイント、クーポン、スーパーSALE、お買い物マラソン、RPP広告、レビュー、店舗内回遊、買い回り需要が売上に影響します。Shopify本店の通常価格と楽天のイベント価格を同じ粗利で見てはいけません。

項目	Shopify本店	楽天市場	粗利設計で見ること
売価	通常価格、会員価格、クーポン	通常価格、イベント価格、クーポン対象価格	チャネル別売価を別列で持つ
値引き	クーポン、定期購入、LINE施策	店舗クーポン、イベント連動値引き	値引き原資をSKU別に控除する
ポイント	Shopifyポイントアプリや会員特典	通常ポイント、ポイント変倍、モール施策	ポイント原資を販促費として見る
広告	Google、Meta、SNS、メール	RPP、TDA、イベント露出	注文単位が難しければ日次・SKU別で配賦する
手数料	決済手数料、アプリ費用、送料	出店料、販売手数料、決済、システム利用料など	モール費用込み粗利を別台帳で作る
配送費	自社EC送料、送料無料条件	楽天配送条件、日時指定、モール内期待値	送料無料施策を粗利に入れる
返品率	Shopify CS、返金、交換	楽天返品、レビュー、問い合わせ	返品・再販可否をSKU別に見る

楽天連携で売上だけをShopifyに取り込んでも、ポイント・クーポン・広告・手数料を引いた粗利が見えなければ、運用判断には使えません。

月次で見るべきなのは、売上高だけではありません。SKU別に、楽天売上、販売数量、値引き、ポイント原資、クーポン、広告費、モール手数料、送料、返品、粗利、在庫回転を並べます。楽天ではイベント時に売上が伸びても、粗利が薄くなることがあります。連携設計では、受注を取り込むだけでなく、損益を説明できる粒度まで戻す必要があります。

キャンセル・返品・欠品・同期エラーの監視設計

楽天RMS、Shopify、OMS、WMSをつなぐと、通常注文よりも例外処理の方が重要になります。

例外	起きること	最初に見る画面	運用ルール
SKU未対応	楽天注文がShopify variantやWMS商品に紐づかない	OMS、SKU対応表	商品番号・SKU管理番号を補正して再取込する
在庫差分	Shopifyでは在庫あり、楽天では欠品、または逆	WMS、OMS、RMS	在庫正本を確認し、安全在庫と表示在庫を補正する
欠品注文	楽天注文は入ったが出荷できない	OMS、RMS、CS台帳	代替、分納、キャンセル、顧客連絡の判断基準を決める
出荷戻し失敗	倉庫は出荷済みだがRMSへ追跡番号が戻らない	WMS、OMS、RMS	二重出荷を止め、出荷実績だけ再送する
キャンセル	楽天側でキャンセル済みだがShopify/OMSに残る	RMS、OMS	出荷前後で在庫復帰と返金処理を分ける
返品受付	顧客から返品依頼がある	RMS、CS台帳	受付、返金、検品、再販可否を別イベントにする
レビュー・問い合わせ	商品不満や配送遅延が楽天側に残る	RMS、R-messe等	Shopify CRMへ転記する条件を決める
API/CSVエラー	商品・在庫・受注の更新が止まる	連携ログ、OMS、WMS	エラー分類、担当者、再実行手順を決める

APIやWebhookで独自連携する場合は、Shopify API連携の設計方法やShopify Webhookの実装設計で扱っているように、再実行、重複排除、ログ、監視を先に設計します。楽天側のAPIやCSVも同じで、更新に失敗したとき、どの注文・SKU・商品ページが止まっているかを確認できる台帳が必要です。

公式アプリ、国内OMS、WMS、API、CSVの選び方

連携方式は、件数、商品数、倉庫、既存RMS運用、必要な復旧性で選びます。

方式	向いているケース	向かないケース	導入前に確認すること
公式販売チャネル系アプリ	Shopify商品を楽天へ出し、最小構成で始めたい	既存RMS商品が多い、アプリ提供状態が不明、複数モールがある	現在App Storeで提供中か、RMS要件、既存商品連携可否
国内OMS	楽天、Amazon、Yahoo!、Shopifyの受注・在庫をまとめたい	Shopifyをすべての正本にしたいだけの小規模運用	受注取込、在庫同期、出荷実績戻し、楽天SKU対応
WMS・3PL連携	倉庫作業、棚卸、返品検品、追跡番号戻しが重要	店舗担当がRMSだけで完結させたい	出荷指示の起点、在庫正本、返品検品ステータス
Shopify API / カスタムアプリ	独自商品台帳、粗利管理、会計、監視まで作りたい	保守担当やログ設計がない	API権限、レート制限、再実行、バージョン管理
楽天RMS API	RMSの商品、在庫、受注に直接連携したい	楽天以外も同じ方式で扱いたい	ライセンスキー、利用API、SKUプロジェクト対応、RMS権限
CSV一括編集	初期移行、既存商品棚卸、定期的な商品更新	毎日の受注・在庫同期	CSV項目、商品管理番号、SKU管理番号、手戻り時の復旧
手動運用	商品数・注文数が少ない検証段階	日次で注文・在庫が動く本番運用	手動更新の担当者、締め時間、ダブルチェック

2020年のShopify公式ブログでは、楽天連携に楽天店舗URL、RMS APIライセンスキー、SMTP ID、SMTPパスワードなどが必要と説明されていました。また、アプリを通して新規商品を作成する必要があること、既にRMSに登録されている商品を連動できないこと、Shopifyを通して作成した商品のみ注文情報や在庫連動の対象になることも注意点として挙げられていました。

この種の条件は、運用に直撃します。既存の楽天店舗があり、商品ページ、レビュー、検索順位、商品管理番号を守りたい場合、単純にShopifyから再出品する方式は合わない可能性があります。既存RMS運用を前提に、OMSやCSVで商品台帳を合わせ、受注・在庫・出荷だけを連携する方が現実的なこともあります。

導入前チェックリスト

実装やアプリ契約の前に、次のチェックを済ませます。

チェック	確認すること	未確認のまま進めた場合
App Storeの現行状態	Rakuten Ichiba系アプリ、OMS、WMSアプリが現在提供中か	旧記事どおりに進めて導入できない
RMS権限	API、CSV商品一括編集、受注、商品、在庫、メール関連権限	連携設定や商品更新が途中で止まる
商品対応表	Shopify SKU、楽天商品管理番号、商品番号、SKU管理番号	注文・在庫・返品が商品に紐づかない
商品ページ項目	楽天カテゴリ、商品属性、キャッチコピー、説明文、画像	出品・審査・検索で詰まる
在庫正本	Shopify、OMS、WMS、RMSのどこを正式在庫にするか	売り越し、欠品、二重更新が起きる
受注正本	楽天ペイ/RMS、OMS、Shopify Ordersのどこで処理するか	出荷漏れ、二重出荷、キャンセル漏れが起きる
出荷戻し	配送会社、追跡番号、出荷日をどこへ戻すか	楽天側の配送通知や顧客連絡が遅れる
販促台帳	ポイント、クーポン、イベント価格、広告費をどう記録するか	売上は伸びても粗利が説明できない
返品・欠品	返金、検品、再販可否、在庫復帰のルール	不良品を販売可能在庫に戻す
監視	同期エラー、SKU未連携、在庫差分、出荷戻し失敗の通知先	問題が静かに積み上がる

このチェックリストは、連携方式を選ぶためのものです。すべてを自動化する必要はありません。件数が少ない段階では、商品登録はCSV、受注はOMS、在庫はWMS、粗利はスプレッドシートで始める判断もあります。逆に、商品数が多くイベント頻度も高いなら、APIやOMS連携を前提にしないと運用が回りません。

まとめ

Shopifyと楽天市場の連携は、楽天にも商品を出す設定ではありません。

実務で崩さないためには、次を先に決める必要があります。

1. Shopifyと楽天RMSのどちらを商品・在庫・注文の正本にするか
2. Shopify SKU、楽天商品管理番号、商品番号、SKU管理番号をどう対応させるか
3. 楽天の商品ページ項目、カテゴリ、商品属性、バリエーションを誰が管理するか
4. 在庫正本をShopify、OMS、WMS、RMSのどこに置くか
5. 楽天注文をどの状態で取り込み、どこから出荷指示を出すか
6. ポイント、クーポン、スーパーSALE、お買い物マラソン、広告、手数料を粗利にどう反映するか
7. キャンセル、返品、欠品、同期エラーをどの画面で直すか
8. 公式アプリ、国内OMS、WMS、API、CSVのどれを、どの業務に使うか

旧公式アプリの情報だけを見て導入判断するのは危険です。2026年7月3日時点では、少なくともApp Store上のRakuten Ichiba (JP)は提供されていない表示です。だからこそ、導入時は最新のShopify App Store、楽天RMS、OMS/WMS公式情報を確認し、使える接続方式を前提に業務フローを組み直す必要があります。

Bitlightでは、Shopifyと楽天RMSの連携を、アプリ導入だけで終わらせません。商品番号・SKU対応表、在庫正本、受注取込、出荷実績戻し、ポイント・クーポン・イベント価格、モール手数料込み粗利、返品・欠品・同期エラー監視まで整理し、公式アプリ、国内OMS、WMS、API、CSVのどれを使うべきかを実務フローとして設計します。