FEATURED ARTICLE / EC・通販のAI接客
EC接客AIはRAGとファインチューニング、どちらで作るべきか？ 電話・Webの海外事例から考える
ECの電話・Web接客AIでRAGとファインチューニングをどう使い分けるか。商品情報、価格・在庫、注文状況の扱いと海外3事例を整理します。
最初に押さえること
商品説明やFAQはRAG、価格・在庫・注文状況はECのAPIで確認します。ファインチューニングは、接客の振る舞いを改善したい段階で検討します。
商品情報を「覚えさせる」だけでは更新に追いつきにくい
ECでは新商品や販売終了、価格、在庫、送料、キャンペーン条件が変わります。モデルにサイトの内容を学習させても、学習後の変更はそのままでは反映されません。誤った価格を案内した際に、どの情報を根拠に答えたかも追いにくくなります。
RAGは質問に関係する商品説明やFAQ、返品規定をその都度探し、その内容を使って回答を作る方式です。ただし、RAGを導入するだけで情報が最新になるわけではありません。元データの更新を検索対象へ反映する仕組みと、古いページを除外する運用が必要です。検索結果が不十分なら、断定せずに確認や有人対応へ切り替えます。
特に価格や在庫は、文書検索の結果にあった数字をそのまま読むより、商品IDを特定してAPIで照会する方が確実です。返金や注文変更は、回答を作るだけでなく実際の処理が必要なため、権限と実行条件を決めたシステム連携が欠かせません。
| 答えたい内容 | 主な情報源 | 応答の扱い |
|---|---|---|
| 素材、サイズ、使い方、返品規定 | 承認済みの商品情報・FAQを検索 | 根拠と適用条件を確認して回答 |
| 現在の価格、在庫、配送予定 | EC・在庫・配送システムのAPI | 応答時点の値を取得して案内 |
| 注文状況、変更、返金 | 本人確認後の注文APIと業務ルール | 確認と処理結果を分けて伝える |
| 接客の口調、聞き返し方 | 指示文・会話設計。必要なら学習例 | 実際の会話で品質を評価して調整 |
海外事例① Carter’s：電話の定型対応をAIに任せ、Webにも展開
米国の子供服ブランドCarter’sは、注文追跡、価格調整、返金などを扱う音声AIを導入し、後にWebチャットへも広げました。提供会社PolyAIによると、有人担当者に届く電話量は37%減少し、繁忙期の季節採用を60%削減。Webチャットでは会話の80%を有人対応なしで解決したと報告しています。
電話での注文追跡と、Webでの贈り物探しを同じ窓口設計で扱いつつ、必要なら人へ引き継いでいます。これは定型問い合わせの処理を減らした成果であり、AIが電話販売をすべて完結させたという数字ではありません。
海外事例② Rohlik：電話・Web・アプリを注文システムにつないだ
欧州のネットスーパーRohlikは、電話、Web、アプリなどでAI接客を提供しています。提供会社ElevenLabsは、電話の着信の90%をAIが対応し、注文状況の確認、注文内容の変更、クレジット付与などを基幹システムと連携して行うと説明しています。アプリなどでは、会話から商品を探し、カートを作り、購入へ進む使い方も紹介されています。
「90%対応」は「90%解決」と同義ではありません。この事例が示すのは、商品知識を回答するだけでは接客が完結しないという点です。現在の注文を読み取り、許可された操作を実行できて初めて、顧客の用件を終えられます。
海外事例③ Pepper：Webのサイズ相談を購買につなげた
米国のアパレルブランドPepperは、サイズやフィットの質問に答え、関連商品も提案するWeb接客AIを導入しました。提供会社Gorgiasは、AIが関わった販売会話の購入率は19%、平均注文額は18%増と報告しています。複雑なフィッティング相談には人が対応します。
この数値はAIが関わった会話の成果です。サイト訪問者全体の購入率が19%になったことや、売上増加がすべてAIによることを意味しません。接客の評価では、会話した人だけの購入率に加え、サイト全体の購入率や返品率も確認する必要があります。
EC接客AIの実装は、三つの情報を分ける
導入時は「AIに何を知ってほしいか」より先に、「どの情報をどこから確認するか」を決めます。説明用の資料と変動する数値、会話中に実行できる処理を分けると、回答の根拠と運用責任を確認しやすくなります。
米国EC事業者Redmondの事例では、詳しい商品質問には承認済みの資料を検索し、商品データはストアの仕組みから取得しています。回答に根拠となる記事へのリンクを添え、必要に応じて人へ引き継ぐ構成です。
電話では、検索やAPI照会に時間がかかると会話の間が空きます。Webで正しい回答ができたとしても、その構成をそのまま電話に移すだけでは十分ではありません。よく聞かれる質問の検索速度、聞き返し、割り込み、処理待ちの案内も実際の通話で確かめます。
- 説明用の情報：商品説明、サイズ表、返品規定、FAQを承認済みの情報源から検索し、出典と更新日を管理する
- 変動する情報：価格、在庫、配送、注文履歴をECのAPIで取得し、取得できなければ推測で補わない
- 会話と実行のルール：追加で聞く項目、本人確認、注文変更や返金の権限、有人引き継ぎの条件を定める
ファインチューニングは、回答の根拠が整った後に検討する
RAGとAPIをつないだ後も、「サイズ相談で必要な質問を飛ばす」「電話で説明が長すぎる」「例外時の引き継ぎ方がばらつく」といった課題が残ることがあります。まず指示文と会話手順を調整し、それでも同じ失敗が繰り返され、良い応対例を十分に用意できるならファインチューニングを比較します。
評価では、誤った商品・金額の案内、根拠なしの断定、有人引き継ぎ率、用件の解決率、購入率、平均注文額、返品率を用件別に追います。Web接客はAIと会話した人だけでなく対象訪問者全体で比較します。電話は「AIが応対した件数」と「人を介さず解決した件数」を分けて集計します。
EC接客AIの出発点は、商品情報を探せること、変動する数字を照会できること、必要な操作を安全に実行できることです。その三つを整えたうえで、接客の振る舞いを磨く順番が現実的です。
よくある質問
ECサイトの全ページをファインチューニングに使えば、RAGは不要ですか？
商品や規約の変更は学習後に自動反映されません。更新される事実はRAGやAPIで確認し、ファインチューニングは接客の振る舞いに繰り返し課題が残る場合に検討します。
電話とWebの接客AIで同じ情報源を使えますか？
商品情報や注文APIは共通化できます。ただし電話では待ち時間、聞き返し、割り込みなどを含めて会話品質を別に検証します。
参考資料・この記事の位置づけ
海外事例の成果は各提供会社が掲載した公表値です。企業やチャネルごとに「対応」「解決」「購入」の定義が異なるため、数値を横並びの性能比較には使用していません。本文の導入順は資料を踏まえたContactXの提案です。
- Microsoft：RAGとファインチューニングの使い分け
変化する情報にはRAG、振る舞いや文体の変更にはファインチューニングを使い分ける説明。
- Google Cloud：RAGとファインチューニングの選び方
更新頻度の高い情報を扱う方法を確認するための資料。
- PolyAI：Carter’sの導入事例
電話量、季節採用、Webチャットの公表値。
- ElevenLabs：Rohlikの導入事例
電話・Web・アプリでの対応範囲と注文システム連携の公表資料。
- Gorgias：Pepperの導入事例
AIが関わった販売会話の購入率と平均注文額の公表値。
- Shopify：RedmondのAIコマースエージェント事例
承認済み商品情報の検索、ストアデータ取得、有人引き継ぎの構成例。