FitGap
2026-02-13

返品理由の自由記述を構造化し製品改善の優先順位を可視化する方法

ECサイトを運営していると、返品は避けられません。問題は返品そのものではなく、返品理由が分析に使える形で残っていないことです。現場スタッフが受付時に自由記述で入力した内容は、イメージと違った、思っていたものと違う、サイズ感が微妙、といった曖昧な表現ばかりで、色なのか質感なのか寸法なのか、具体的にどこが不満だったのかが読み取れません。返品データがいくら溜まっても、製品改善の優先順位が決められないまま放置される状況が続きます。

この記事は、従業員30〜300名規模のEC事業者で、返品対応やカスタマーサポートを兼務している業務担当者、あるいはEC運営のマネージャーを想定しています。読み終えると、返品理由の自由記述を自動で分類し、どの製品のどの要素に不満が集中しているかをダッシュボードで確認できるワークフローを構築できるようになります。大規模エンタープライズ向けの基幹システム刷新や、個別ツールの網羅的なレビューは扱いません。

なお、本記事で紹介するツールの組み合わせは代表的な一例です。同じ役割を果たす別の製品でも、同様のワークフローを構築できます。

読み終えた時点で、返品理由を5〜10個の改善カテゴリに自動分類し、製品別・カテゴリ別の返品傾向を週次で確認できるダッシュボードの設計と運用手順が手に入ります。

Workflow at a glance: 返品理由の自由記述を構造化し製品改善の優先順位を可視化する方法

  • Step 1: 返品データとサポート履歴を突き合わせて抽出する (ネクストエンジン × Zendesk)
  • Step 2: テキスト分類AIで返品理由をカテゴリに振り分ける (ChatGPT API) (LLM・大規模言語モデル)
  • Step 3: 製品別・カテゴリ別の返品傾向をダッシュボードで可視化する (Looker Studio) (BIツール)

なぜ返品理由の自由記述は分析に使えないのか

入力する側に構造化のインセンティブがない

返品受付の現場では、処理件数をさばくことが最優先です。スタッフはお客様の言葉をそのまま入力するか、短く要約して済ませます。サイズが合わなかった、イメージと違った、という記述は、入力する側にとっては十分な情報ですが、分析する側にとっては何も分かりません。サイズが合わなかったのは、着丈なのかウエストなのか袖丈なのか。イメージと違ったのは、色味なのか素材感なのかシルエットなのか。この粒度の違いが、データとしての価値を決定的に分けます。

データが3つのシステムに散らばっている

多くのEC事業者では、返品理由はネットショップの受注管理システムに、お客様とのやり取りの詳細はカスタマーサポートツールに、製品の仕様情報は商品マスタや社内の管理表に、それぞれ別々に保管されています。返品理由の自由記述だけを見ても、その注文がどの製品のどのSKUで、お客様がサポート窓口でどんな具体的な不満を述べていたかを突き合わせるには、手作業で3つのシステムを行き来する必要があります。この手間が大きすぎるため、誰もやらないまま放置されます。

分析しても改善アクションにつながらない

仮に誰かが時間をかけて返品理由を手動で分類したとしても、それが一度きりの作業で終わってしまえば、翌月にはまた同じ状態に戻ります。継続的に分類し、傾向を追い、製品チームに共有する仕組みがなければ、分析結果は報告書の中で眠るだけです。必要なのは、自動で回り続ける仕組みです。

重要な考え方:自由記述を捨てずに構造化レイヤーを上から被せる

返品理由の入力フォームを選択式に変えるという対策がよく提案されますが、FitGapではこのアプローチだけでは不十分だと考えます。選択肢を用意しても、お客様の本当の不満は選択肢の隙間に落ちます。その他を選ばれて自由記述に戻るか、最も近い選択肢を適当に選ばれて実態と乖離するか、どちらかです。

自由記述は情報量が多い

自由記述には、選択式では拾えない微妙なニュアンスが含まれています。写真と実物の色が全然違う、洗ったら縮んだ、ボタンの位置が高すぎて留めにくい、といった記述は、製品改善の具体的なヒントそのものです。これを捨てるのはもったいない。

構造化は入力時ではなく分析時に行う

入力する人に負担をかけるのではなく、入力された自由記述をAIで後から分類するのが現実的です。テキスト分類AIに返品理由の文章を渡し、あらかじめ定義したカテゴリ(色・素材・サイズ・寸法・デザイン・品質不良・配送破損など)に振り分けます。人間が読んで判断していた作業を自動化するイメージです。

カテゴリは固定せず育てる

最初に設定したカテゴリが完璧である必要はありません。運用しながら、分類結果を月に一度レビューし、新しいパターンが見つかればカテゴリを追加・統合していきます。この育てるプロセスが、返品データの分析精度を継続的に高めます。

返品理由を自動分類して製品改善ダッシュボードを回す

ステップ 1:返品データとサポート履歴を突き合わせて抽出する(ネクストエンジン × Zendesk)

週に一度、月曜の午前中に実施します。担当はEC運営の業務担当者です。

ネクストエンジンから直近1週間の返品・キャンセル注文データをCSVでエクスポートします。注文番号、SKU、返品理由の自由記述、返品日が含まれます。次に、Zendeskで同じ期間のサポートチケットを検索し、返品に関連するやり取りをCSVでエクスポートします。お客様が電話やメールで述べた具体的な不満が記録されています。

この2つのCSVを注文番号またはお客様のメールアドレスをキーにして突き合わせます。Google スプレッドシートのVLOOKUP関数で十分です。突き合わせた結果、1行に注文番号、SKU、返品理由(自由記述)、サポートでの詳細コメントが並ぶ一覧表ができます。サポートへの問い合わせがない返品も多いので、その場合は返品理由の自由記述だけが残ります。

この突き合わせが重要な理由は、返品理由欄にはイメージと違ったとしか書かれていなくても、サポートチケットには写真で見た色より暗かった、生地がもっと柔らかいと思ったといった具体的な記述が残っていることが多いからです。両方を合わせることで、分類の精度が大きく上がります。

ステップ 2:テキスト分類AIで返品理由をカテゴリに振り分ける(ChatGPT API)

ステップ1で作成した一覧表のテキストデータを、ChatGPT APIに渡して分類します。担当は同じ業務担当者です。

具体的には、Google スプレッドシートからGoogle Apps Scriptを使ってChatGPT APIを呼び出します。プロンプトには、以下の返品理由テキストを読み、次のカテゴリから最も適切なものを1つ選んでください、という指示と、カテゴリ一覧(色味の相違、素材・質感の相違、サイズ・寸法の不一致、デザイン・形状の不満、品質不良・初期不良、配送時の破損・汚損、商品説明との相違、その他)を記載します。返品理由とサポートコメントを連結したテキストを入力として渡し、カテゴリ名を返してもらいます。

1件あたりの処理は数秒で完了し、週100件程度であれば数分で全件の分類が終わります。分類結果はスプレッドシートの新しい列に自動で書き込まれます。

注意点として、分類結果の精度は最初から完璧ではありません。最初の2〜3週間は、分類結果を目視で確認し、明らかな誤分類があればプロンプトを調整します。たとえば、サイズが大きすぎたという記述がデザイン・形状の不満に分類されてしまう場合は、プロンプトにサイズや寸法に関する記述はサイズ・寸法の不一致に分類してくださいという補足を追加します。この調整を3回ほど繰り返せば、90%以上の精度で安定します。

ステップ 3:製品別・カテゴリ別の返品傾向をダッシュボードで可視化する(Looker Studio)

ステップ2で分類済みのスプレッドシートをLooker Studioに接続し、ダッシュボードを作成します。初回の設定は1〜2時間で完了します。担当はEC運営のマネージャーまたは業務担当者です。

ダッシュボードには3つのグラフを配置します。1つ目は、返品カテゴリ別の件数を示す棒グラフです。どのカテゴリの返品が最も多いかが一目で分かります。2つ目は、SKU別の返品率ランキングです。特定の商品に返品が集中していないかを確認します。3つ目は、週次の推移を示す折れ線グラフです。施策を打った後に返品が減ったかどうかを追跡します。

このダッシュボードを毎週月曜の午後に製品チームと共有します。共有方法はLooker StudioのURLをSlackやメールで送るだけです。製品チームは、色味の相違が特定のSKUに集中していれば商品写真の撮り直しを検討し、サイズ・寸法の不一致が多ければサイズガイドの改善を検討する、といった具体的なアクションにつなげます。

スプレッドシートのデータが毎週追記されるため、Looker Studioのダッシュボードも自動的に最新データを反映します。一度設定すれば、週次の運用はステップ1のCSVエクスポートと突き合わせ(約30分)とステップ2のAPI実行(約10分)だけで回ります。

この組み合わせが機能する理由

ネクストエンジン:複数モールの返品データを一元管理できる

EC事業者の多くは、楽天市場、Amazon、Yahoo!ショッピング、自社サイトなど複数のチャネルで販売しています。ネクストエンジンはこれらの受注データを一元管理しているため、チャネルをまたいだ返品データを1か所から取得できます。個別のモール管理画面からそれぞれCSVを出す手間がなくなります。弱みとしては、返品理由の自由記述フィールドの文字数に制限がある場合があり、長い記述が途中で切れることがあります。そのため、サポートチケットとの突き合わせが補完として重要になります。

Zendesk:返品に関する詳細なやり取りが構造化されて残る

Zendeskはチケット単位でお客様とのやり取りを管理するため、返品に関する問い合わせの全文が時系列で残ります。タグやカスタムフィールドで返品チケットを絞り込めるため、CSVエクスポートも効率的です。一方で、すべての返品客がサポートに問い合わせるわけではありません。サポートへの問い合わせなしに返品される案件は、ネクストエンジン側の自由記述だけが情報源になります。Zendeskの導入コストは小規模チームにとってやや高めですが、すでにカスタマーサポートツールとして導入済みの企業であれば追加コストなしで活用できます。

ChatGPT API:プロンプト調整だけで分類ロジックを柔軟に変更できる

専用のテキスト分類AIを開発・学習させるには、大量の教師データと機械学習の専門知識が必要です。ChatGPT APIであれば、プロンプトに分類ルールを日本語で書くだけで動作します。カテゴリの追加や統合もプロンプトを書き換えるだけで対応でき、専門的なスキルは不要です。トレードオフとしては、API呼び出しごとに従量課金が発生します。ただし、週100件程度の返品理由分類であれば、月額のAPI費用は数百円程度に収まります。また、APIにデータを送信するため、個人情報を含むテキストは送らないよう、事前に注文番号やお客様名を除去する運用ルールが必要です。

Looker Studio:無料でスプレッドシートから直接ダッシュボードを作れる

Looker StudioはGoogleが提供する無料のBIツールで、Google スプレッドシートをデータソースとして直接接続できます。有料のBIツールと比べて機能は限定的ですが、棒グラフ、折れ線グラフ、表の表示であれば十分です。共有もURLを送るだけで、閲覧者にライセンスは不要です。弱みとしては、データ量が数万行を超えると表示速度が遅くなることがあります。返品データの週次蓄積であれば、年間でも数千行程度なので問題になりません。

Recommended tool list

ToolRolePricingImplementation timeNotes
ネクストエンジン複数モールの返品・受注データを一元管理しCSVで抽出する月額課金導入済みの場合は即日、新規導入の場合は1〜2週間楽天市場・Amazon・Yahoo!ショッピングなど主要モールとの連携設定が必要。返品理由の自由記述フィールドが有効になっているか事前に確認する。
Zendesk返品に関するサポートチケットの詳細履歴を管理・抽出する月額課金導入済みの場合は即日、新規導入の場合は1〜2週間返品関連チケットにタグを付けるルールを設定しておくと、CSVエクスポート時の絞り込みが効率的になる。
ChatGPT API返品理由の自由記述テキストをあらかじめ定義したカテゴリに自動分類する従量課金1〜2日Google Apps Scriptからの呼び出しで実装する。個人情報を含むテキストはAPI送信前に除去する運用ルールを設ける。プロンプトの調整に最初の2〜3週間を見込む。
Looker Studio分類済みの返品データをダッシュボードで可視化し製品チームと共有する無料枠あり1〜2時間Google スプレッドシートをデータソースとして直接接続する。棒グラフ・折れ線グラフ・表の3つを配置すれば基本的な分析は十分。

結論:返品理由は溜めるだけでなく分類して初めて改善に使える

返品データは多くのEC事業者がすでに持っている資産です。足りないのはデータの量ではなく、自由記述を構造化して傾向を読み取る仕組みです。ネクストエンジンで返品データを集め、Zendeskのサポート履歴で補完し、ChatGPT APIで自動分類し、Looker Studioで可視化する。この4つのツールを組み合わせれば、週40分の運用で返品理由の傾向を継続的に追跡できます。

最初の一歩として、直近1か月分の返品データをCSVでエクスポートし、ChatGPT APIで分類を試してみてください。10件でも分類してみれば、自由記述の中に埋もれていたパターンが見えてきます。そこから、週次の運用に拡張していくのが最も確実な進め方です。

Mentioned apps: ChatGPT, ネクストエンジン, Zendesk, Looker Studio

Related categories: BIツール, LLM・大規模言語モデル, カスタマーサポートツール, ネットショップ受注管理システム(OMS)

Related stack guides: 監査時にガイドライン対応の証跡をすぐ提出できる体制を4つのツールで構築する方法, KPI改善と現場の不満が食い違うとき定量データと定性フィードバックを統合して施策の真の効果を判断する方法, ツール導入後の社内問い合わせ対応が特定の社員に集中する属人化を解消し安定したサポート体制を構築する方法, AIエージェントの開発データと本番データの乖離を防ぎ精度低下と手戻りをなくす方法, AIの判断結果を人が検証・承認してから業務に反映する仕組みをつくり誤判定トラブルを防ぐ方法

サービスカテゴリ

AI・エージェント

汎用生成AI・エージェント
LLM・大規模言語モデル
エージェントフレームワーク
エージェントオートメーション基盤

ソフトウェア(Saas)

オフィス環境・総務・施設管理
開発・ITインフラ・セキュリティ
データ分析・連携