返品・交換対応の自動化｜受付〜在庫戻しのシステム化と費用の目安

返品・交換対応の自動化は、①返品特約・返品理由コード・理由ごとの対応表を決める、②受付フォームで注文番号・理由・写真をそろえて受け取る、③条件が明確な判定と返金・在庫反映を自動化し、傷や状態の判断は人が確認する、の流れで進めます。方式は既製の返品ツール・基幹システムとの連携拡張・自社開発の3つで、返品件数と判定パターンの複雑さで選びます。費用は方式によって変わりますが、どの方式でも返品ルールを決める工程が最初に来ます。

「返品・交換の対応を特定の担当者しか処理できない」：EC・卸の属人化

EC・卸で避けて通れない業務のひとつが、返品・交換の対応です。注文とは違い、返品には「受け付ける」「良品か不良品かを判定する」「返金か交換か再出荷かを決める」「在庫データに反映する」という複数の判断が絡みます。判断が続くため、「返品対応は経験のある特定の担当者でないと正しく処理できない」という属人化が起きやすい領域です。

問い合わせ窓口をAIチャットボットで自動化していても、対応できるのは「返品期限は◯日以内です」「送料はどちらが負担しますか」といった定型質問への回答までであることがほとんどです。返品を受け付けたあとの、検品・判定・返金または再出荷の処理・在庫データへの反映という一連の業務は、多くの会社で人手に頼ったままです。

なぜ返品・交換対応は自動化しにくいのか：判断が連続する業務だから

返品・交換対応は単純な定型作業に見えますが、工程の途中に人の判断が何度も挟まるため、属人化しやすい構造をしています。

• 良品/不良品の判定基準が文書になっていない：「この程度の傷なら良品扱い」「この不具合は交換対応」といった線引きが担当者の経験則に依存し、担当者が変わると判断がぶれる
• 返金・交換・再出荷の振り分けルールが曖昧：同じ「サイズが合わない」という申し出でも、在庫の有無や購入経路（自社EC／モール／卸取引）によって取れる対応が変わり、その場その場の判断で処理される
• 在庫データへの反映が遅れる：返品された商品を「良品として在庫に戻す」「廃棄・返品扱いにする」という判定と、その結果を在庫データに反映するタイミングがずれると、在庫連携ツールを入れていても在庫数と実態が合わなくなる

返品対応の手順と判断基準を書き出さないまま、担当者の経験に頼って処理を続ける限り、人を増やしてもこれらの問題は解消しません。

良品として在庫に戻す判定では、賞味期限・使用期限が近いロットでないかの確認も欠かせません。食品卸・理美容材料卸・介護用品卸のように期限管理が重要な業種では、賞味期限・ロット管理の自動化と先出し（FEFO）の方法にある期限・ロット管理の方法とあわせて検討してください。

判定基準が言葉になっていない状態でツールを入れても、迷う場面は減りません。次の3つを文章で決め切ってから、仕組みに落とします。

• 返品特約（受付条件）をサイトに明示する：通信販売にクーリング・オフの制度はないが、特定商取引法では、返品の可否・条件・送料負担を広告に表示していない場合、商品の引渡しを受けた日から8日以内は購入者が送料を負担して返品できると定められている（法定返品権）。「返品不可」も表示していれば有効で、ネット通販では商品ページなどの広告に加えて、注文の最終確認画面にも表示する必要がある。受付条件が曖昧なまま運用している会社は、自動化より前にここを整えるほうが効果が出る
• 返品理由コードを5〜8個に固定する：「不良・破損」「誤配送（自社起因）」「イメージ違い・サイズ違い（購入者都合）」「数量違い」「期限切れ間近」「その他」といった粒度で事前に決める。理由コードが決まると、送料負担・返金方法・在庫の戻し先まで機械的に引けるようになり、自動化できる範囲が一気に広がる
• 理由コードごとに送料負担と対応を紐づける：自社起因（不良・誤配送）は自社負担で交換または返金、購入者都合は購入者負担で返品のみ、といった対応表を作る。この表がないままAIに判断させても、ルールのない状態が再現されるにすぎない

3点を決める作業はシステム投資にあたらず、業務側の意思決定です。ここを決めれば返品受付の大半は条件分岐で処理でき、AIに任せるのは「申し出の文章から理由コードと必要情報を読み取る」部分に絞り込めます。

AIで自動化できる範囲とできない範囲を切り分ける

返品・交換対応の自動化を考えるときは、「AIチャットボットによる問い合わせ回答」と「返品受付後の業務フロー」を別の工程として扱います。

「返品期限や送料といった定型質問」への自動応答は、生成AIによるカスタマーサポート自動化で対応できる領域です（生成AIのカスタマーサポート自動化｜失敗する3つの原因にある一次対応の自動化と同じ考え方です）。一方で、返品を受け付けたあとの「良品/不良品の判定基準を決め、記録として残す」「返金・交換・再出荷の振り分けルールを明文化する」「判定結果を在庫データへ正しく反映する」という工程は、問い合わせ対応の自動化とは別に設計が必要です。

すべてを一律にAI任せにはできません。申請から一定日数以内・未使用・外箱あり、といった条件が明確な判断はルール化・自動化できますが、微妙な傷や状態の判断が必要なケースは、最終的に人が確認する工程を残します。ここを混同して「全自動化」を目指すと、かえって担当者が対応に迷う場面が増えます。

B2B卸の場合、返品対応にかかる工数は得意先ごとの採算にも関わります（取引先別の実質収益の出し方｜儲かっていない得意先の見つけ方にあるとおり、返品対応費は得意先別の実質収益を圧迫する取引コストの1つです）。返品対応のルールを決めて処理を効率化すると、問い合わせ対応の手間が減るうえ、得意先別の採算も改善できます。

受付〜返金〜在庫戻しの流れを、実務の粒度で分解する

返品対応を仕組みに落とすときは、工程を「受付」「判定」「返金・再出荷」「在庫反映」の4つに割り、それぞれで必要な情報と担当を決めます。

• 受付：注文番号・理由コード・数量・開封の有無・不良箇所の写真を、最初のフォームでそろえて取得する。写真があると後工程の差し戻しが減るため、不良・破損の理由コードでは写真を必須項目にする
• 判定：良品として再販できるか、不良として仕入先へ返すか、廃棄かの3分岐。写真と理由コードで機械的に振り分けられるものと、現物を見ないと決まらないものを最初から分ける
• 返金・再出荷：クレジットカードは売上確定前のオーソリ取消か確定後の返金処理かで購入者側への反映日数が変わり、締め日をまたぐと翌月の返金として見える場合がある。日数の目安を受付時に案内すると、「返金されていない」という二次問い合わせが減る
• 在庫反映：良品戻しは通常の在庫に、判定待ちの現物は別ロケーション（返品保留）に置き、在庫数と実態のずれを防ぐ。判定前の現物を通常在庫に戻すと、在庫差異の主な原因になる

モール（楽天・Amazon）経由の注文は、返品受付の窓口・期限・送料負担のルールがモール側の規約で決まっているため、自社ECと同じ運用にはそろえられません。チャネルごとに対応表を分け、「自社ECの条件」「モールの条件」を並べて持つ形にすると、担当者が変わっても判断がぶれません。

AIで進める返品・交換対応整理の進め方（4フェーズ）

返品・交換対応も、いきなり全ての判断をシステム化せず、段階を踏んで進めると手戻りを抑えられます。

①現状の把握では、直近の返品・交換の件数と内訳（理由別・チャネル別）を洗い出し、どの判断が担当者の経験則に依存しているかを特定します。「特定の担当者しか対応できない」原因の多くは、この段階で、判定基準が言葉になっていないことだと分かります。

②PoC（概念実証。小規模に試して効果を確認する工程）では、全件を対象にせず、一部の返品理由カテゴリに絞ってAIによる一次振り分けを試します。定型的な条件（未使用・期限内・外箱あり等）で機械的に判定できるケースと、人の目での確認が必要なケースを、どの程度の精度で切り分けられるかを確かめます。

③実装では、PoCで見えた振り分け精度を踏まえ、対象範囲を広げます。判定基準を明文化したうえで、返金・交換・再出荷の振り分けと、その結果を在庫データへ反映する連携設計まで行います。

④運用は、返品理由の傾向が季節や商品によって変わることを見込んだ工程です。判定基準の見直しや、在庫反映の精度を定期的に確認する保守体制を維持します。

在庫データへ反映した数字が現物と合っているかは、最終的には定期的な実地棚卸で確かめます。棚卸の作業時間を減らす方法は実地棚卸（現物確認）をAI画像認識で効率化する方法に手順があります。

返品・交換対応をどう自動化するか：3つの選択肢を比較する

返品・交換対応を自動化する方式は、主に3つあります。自社に合わない方式を選ぶと、導入後に「独自ルールに対応できない」「想定外の改修費がかさむ」という事態になるため、最初に全体像を比べます。

既製ツールは早く始められる一方、食品の期限管理や卸の得意先別ルールのように業種特有の判定基準が多い場合は対応しきれないことがあります。基幹・受発注システムとの連携拡張は、Shopifyと基幹システムを連携する3つの方法と費用と同じ考え方で、CSV連携からAPI連携まで自社の要件に応じた方法を選べます。在庫データへの反映まで一体で管理したい場合は、複数モールの在庫連携を自動化する方法で触れたマスタ統合の課題とも関わります。自社開発は自由度が高い反面、返品ポリシーを見直すたびに改修コストがかかるため、変更の多い運用には向きません。

どの方式が向いているか：返品件数と判定パターンの複雑さで見る

目安として、月間の返品件数が少なく判定パターンも単純であれば、既製ツールの基本機能で多くのケースをカバーできます。良品/不良品の判定基準が得意先や商品カテゴリによって細かく分かれている、在庫データへの反映まで一体で管理したい、といった要件があるなら、基幹システムとの連携・拡張を検討します。自社開発が選択肢に入るのは全社システムを作り替える必要がある場合に限られ、その際も改修コストの見込みを事前に確かめることが欠かせません。

費用と期間の目安

金額は前掲の3方式の比較表が目安です。ここでは、どの方式を選んでも共通してかかる工程と、期間の目安を補足します。いずれも市場の一般的な水準であり、特定サービスの確定価格ではありません。

返品対応の投資判断では、削減できる時間のほかに2つの数字を数えると精度が上がります。基本になるのは、返品1件あたりの処理時間（受付から在庫反映までの実測）×月間件数です。そこに、在庫差異による欠品・過剰在庫の発生頻度と、返品対応の遅れによる低評価レビューの件数を加えると、投資の判断材料がそろいます。

まとめ：返品・交換対応は「問い合わせ回答」の先の業務フローまで見て設計する

返品・交換対応は、問い合わせへの自動応答で完結しません。返品を受け付けたあとの判定基準・振り分けルール・在庫反映まで含めて、はじめて属人化しない対応体制になります。「特定の担当者しか正しく処理できない」状態が続いているなら、原因は担当者の能力より、判断基準が文書になっていないことにある可能性があります。

着手の手順は、①返品特約と理由コードを決める、②理由コードごとの送料負担と対応表を作る、③一部の理由コードに絞って一次振り分けを試す、の3段です。①②は業務側の意思決定で、ここが決まっていれば、どの方式を選んでも導入後の手戻りを小さくできます。

自社ECで返品を受けている場合は、返品特約と理由コードの案づくり、受付フォームの項目設計、返品条件の掲載まで、awaiがサイトの改修と保守運用の中で受け持ちます。