Shopify以外でも返品自動化はできる──W2連携・CSV連携・カスタムAPI連携の3ルートを解説

「返品・交換の自動化ツールはShopify向けだから、自社のカートでは使えない」──EC事業者の方からよく伺う前提です。返品自動化SaaSはShopifyアプリとして提供されているものが目立ち、Web上の導入情報もShopify前提のものが多いためです。

ただ、Recustomerに関して言えばこの前提は正確ではありません。Shopifyは対応しているカートの1つであり、そのほかにW2のECプラットフォームとのAPI連携、注文データのCSV連携、自社基幹システムとのカスタムAPI連携という3つのルートがあります。この記事では、Shopify以外のカート・独自カート・フルスクラッチECで返品自動化を実現する3ルートを、それぞれの向き不向きとあわせて解説します。

Shopify以外のカートでの返品自動化とは

Shopify以外のカートでの返品自動化とは、返品・交換・キャンセルの受付から可否判定、返送手配、返金・在庫戻しまでの処理を、カートの種類に依存しない形で自動化する仕組みです。前提として重要なのは、Recustomerが「Shopifyアプリ」ではなく「注文データを受け取って購入後の業務を処理する独立したシステム」として設計されている点です。

返品対応の自動化に必要なのは、「誰がいつ何をいくらで買ったか」という注文データの入口と、「返送された・返金した」という結果を書き戻す出口の2つです。この入口と出口をつなぐ手段が複数あるため、Shopifyアプリという特定の経路が使えなくても自動化は成立します。

Shopify以外で使える3つの連携ルート

ルート① W2連携：ECプラットフォームとのAPI連携

Recustomerは2024年9月に、ECプラットフォームを提供するW2とのAPI連携を開始しました。対象はOMO／オムニチャネル対応の総合ECプラットフォーム「W2 Unified」と、D2Cリピート通販向けの「W2 Repeat」です。この連携により、購入後の配送追跡と、返品・交換・キャンセル業務を自動化する基盤を利用できます。

カート側とAPIでつながるため、注文データの照合はリアルタイムに行われます。購入者が氏名と注文番号を入力すれば該当注文が自動で特定され、返品ポリシーに沿った受付可否の判定もその場で完了します。

ルート② CSV連携：注文データを取り込む汎用経路

カート側にAPI連携の口がない場合の受け皿になるのが、注文データをCSVで取り込むCSV連携です。Recustomerは2024年2月の「Recustomer 配送追跡」のアップデートで外部連携機能を強化し、フルスクラッチで構築されたECサイトや、多様なカートシステム・ツールを利用している事業者への提供が可能になったことを発表しています。

運用としては、注文データのCSVを定期的に取り込む形になります。取り込み以降の流れ──申請受付、可否判定、返送の集荷手配、進捗管理──はほかのルートと変わりません。カート側の改修が要らないため導入までの期間が短く、まず返品対応の工数を下げたい段階で選びやすいルートです。一方で注文データの反映は取り込み頻度に依存するため、注文直後のキャンセル受付のようにリアルタイム性が要る用途では取り込み設計を詰める必要があります。

ルート③ カスタムAPI連携：基幹システムと双方向でつなぐ

自社で受注管理や在庫管理の基幹システムを持っている企業向けのルートが、カスタムAPI連携です。特徴は双方向であることです。基幹システムから注文データや在庫データをRecustomerに渡すだけでなく、Recustomer側で発生した返品承認・交換確定・キャンセル承認といったイベントをWebhookで自社システムに通知できます。

これにより、基幹側の在庫戻し・返金処理・伝票の取消といった処理を購入者の申請と連動させられます。購入者から見れば「申請したら自動で進む」体験になり、社内では基幹システムへの入力作業がなくなります。独自の業務フローを持つ大規模ECでの実運用実績があるルートです。

3ルートの比較

カスタムAPI連携での効果例

独自の基幹システムを持つ大手EC企業では、カスタムAPI連携によって返品・キャンセル申請の6割以上を無人で処理できる状態になりました。購入者の申請から可否判定、基幹システム側の処理までが自動で流れるため、オペレーターが確認するのはポリシーの例外に当たる案件だけになります。

注目したいのは、この企業がカートを乗り換えていない点です。既存のカートと基幹システムを残したまま、購入後の業務プロセスだけをRecustomerに寄せています。連携で自動化できる範囲の全体像はRecustomerと連携できるシステム一覧にまとめています。

どのルートでも共通して使える機能

連携ルートが違っても、返品・交換・キャンセル業務そのものの機能は共通です。

• 返品ポリシーに基づく可否の自動判定：購入日からの経過日数、対象商品、返品理由などの条件をストアごとに設定できます
• 佐川急便・ヤマト運輸の自動集荷：申請完了と同時に集荷依頼が送信され、購入者は伝票を書く必要がありません。QRコード提示による伝票レス返送も選べます
• 購入者向けのセルフサービス画面：氏名と注文番号の入力から申請完了まで購入者が自分で完結できます
• 申請の進捗管理：受付・承認・返送中・返金完了といったステータスを管理画面で一覧できます

集荷にかかる費用の負担（購入者・店舗）は、ストアの設定で選択します。返送手段ごとの違いは返品の返送を自動化する方法、返品送料の考え方はEC返品の送料負担の決め方で解説しています。

よくある質問

Q. 利用中のカートが対応しているか分かりません。

カートがAPI連携に対応していない場合でも、CSV連携またはカスタムAPI連携で導入できる可能性があります。利用中のカート・OMS・基幹システムの構成をお知らせいただければ、どのルートが適しているかをご提案します。

Q. CSV連携でもリアルタイムに返品を受け付けられますか？

購入者からの申請受付そのものは常時可能です。ただし判定に使う注文データはCSVの取り込みタイミングで更新されるため、取り込み直後の注文についてはデータ反映を待つ必要があります。出荷前キャンセルのようにリアルタイム性が求められる業務では、取り込み頻度の設計をあわせて検討します。

Q. カスタムAPI連携には自社の開発工数がどれくらい必要ですか？

連携する範囲によって変わります。注文データの受け渡しだけであれば限定的ですが、返品承認イベントを受けて基幹システム側の在庫・会計処理まで連動させる場合は基幹側の実装が必要です。要件整理の段階からRecustomer側で仕様のすり合わせを行います。

Q. フルスクラッチのECサイトでも導入できますか？

導入できます。2024年2月の配送追跡のアップデートで外部連携機能を強化し、フルスクラッチで構築されたECサイトや多様なカートシステムを利用している事業者への提供が可能になっています。

Q. 途中で連携ルートを切り替えられますか？

切り替えられます。CSV連携で運用を開始してから、範囲を広げるタイミングでカスタムAPI連携に移行する進め方も可能です。返品ポリシーの設定や購入者向け画面はそのまま引き継げます。

Q. モール店舗と自社ECを併用している場合はどうなりますか？

自社ECの連携ルートとは別に、楽天市場・Yahoo!ショッピングなどのモール店舗の注文も同じ管理画面で扱えます。モールを含む多店舗運営の構成はモール多店舗の返品対応を一元化する連携構成で解説しています。

まとめ

返品自動化はShopify限定の話ではありません。W2 Unified／W2 RepeatとのAPI連携、注文データのCSV連携、基幹システムとのカスタムAPI連携という3つのルートがあり、独自カートやフルスクラッチECでも自動化は成立します。どのルートでも、返品ポリシーに基づく可否判定と佐川急便・ヤマト運輸の自動集荷は同じように使えます。カートを乗り換えずに購入後の業務だけを自動化できるかどうかは、現行のシステム構成を確認すれば判断できます。

出典・参考文献

• Recustomer、ECプラットフォームを提供するW2とAPI連携を開始（PR TIMES、2024年9月5日）
• 購入後に新たな顧客接点を創造する「Recustomer 配送追跡」がアップデート（PR TIMES、2024年2月）

関連記事

• Recustomerと連携できるシステム一覧【2026年版】
• ecforceの返品・交換対応を自動化する方法
• OMS連携で返品・交換はどこまで自動化できる？
• Shopify×ロジレス×佐川急便の王道連携構成
• EC返品対応の基本と効率化の考え方