ECサイトの構築後に問い合わせが減らない運営は、FAQより先にレビューの不満を読んでいない

ECサイトの構築に費用と時間をかけたのに、問い合わせが一向に減らない。よくある対処は「FAQを追加する」ことですが、それは問題の場所を間違えています。問い合わせが発生している根本は、商品ページやFAQに書かれていない情報が顧客の不安を解消できていないことであり、その情報は多くの場合、すでにレビューや返品理由として手元に蓄積されています。FAQを増やす前にそこを読まなければ、問い合わせ対応の負担は減りません。

ECサイト運営において、問い合わせ内容とレビューの不満は同じ情報源のはずです。しかし実際の現場では、問い合わせ対応とレビュー確認とFAQ更新が別の担当者に分かれており、三者の間に情報の橋がないまま運営が続いています。この記事では、ECサイトの構築後に問い合わせを削減するために、AIで分類すべき情報と人間が修正すべき商品情報の境界を明確にし、FAQ更新の責任をどこに置くかまで整理します。

1.顧客はすでに答えをレビューに書いている。運営側がそこを見ていないだけだ

問い合わせ内容を分析すると、「サイズ感はどうですか」「洗濯できますか」「在庫はいつ戻りますか」といった質問が繰り返されていることに気づきます。これらは商品ページに情報があれば大半が解決できる質問です。なぜ解決されないかというと、商品ページに記載がないか、あっても見つけにくい場所に埋まっているかのどちらかです。

そして、その情報は顧客自身によってすでに書かれています。レビューを読むと「サイズ表より実寸が1cm大きかった」「洗濯したら色落ちした」「在庫復活の通知が来なかった」といった具体的な不満が並んでいます。これはFAQに追加すべき問いと答えがほぼそのまま書かれた資料です。返品理由も同様で、「思っていたより厚みがなかった」「写真と色が違う」という記載は、商品ページのどの情報が不足しているかを示す直接の証拠になります。

放置で発生している損失の種類

• 問い合わせ対応時間：1件10分の対応が月100件あれば、月約17時間が繰り返しの返信に消える
• 返品処理コスト：商品情報の不足で起きた認識ズレが返品率を押し上げ、送料と再出荷コストが積み上がる
• レビュー評価の悪化：同じ不満が解消されないまま星1評価が増え続け、新規顧客の購買判断に影響する

たとえば問い合わせ対応に1件あたり平均15分かかり、同じカテゴリの質問が月に50件繰り返されているとすると、月12時間以上が解消可能な問い合わせへの返信だけに消えていることになります。この状態は「担当者が対応している」ように見えますが、実際には商品情報の不備というECサイトの構築段階に戻る問題が放置され続けているだけです。しわ寄せを受けているのは問い合わせ担当者と、返信を待つ顧客の双方です。

2.AIに分類させてよいのはレビュー不満の「種類分け」まで、直す判断は人間の仕事だ

レビューや問い合わせ内容をAIで分類することは、現状の業務でコストパフォーマンスが高い活用のひとつです。生成AIやテキスト分類ツールに過去6か月分のレビューと問い合わせ内容を入力すると、「サイズ・素材・配送・在庫・返品理由・写真との差異」といったカテゴリごとに件数と主な言及内容を整理できます。担当者が1件ずつ読んで分類する作業が半自動化されるため、分析のための準備時間は大幅に短縮されます。

ただし、AIが分類した結果をそのままFAQに転記するのは止めるべきです。理由は2つあります。ひとつは、AIの分類は文面上の類似性で判断するため、表面的に似た表現でも商品ごとに意味が異なる場合があります。「サイズが違う」という不満が、寸法の記載誤りなのか、個人の体型との差なのか、商品の製造ばらつきなのかは、AIには判定できません。もうひとつは、FAQに書く内容が事実として正確かどうかを人間が確認する必要があるからです。誤情報をFAQとして公開すると、個人情報を入力して購入まで進んだ顧客が後でトラブルになるリスクがあります。

AIに任せてよい範囲と人間が判断する範囲

AIに任せてよいのは、レビューと問い合わせのカテゴリ分類、頻出ワードの抽出、件数の集計、FAQ候補文の下書き生成です。人間が判断すべきなのは、その情報が商品ページに追記すべき事実なのか、FAQに追加すべき問いなのか、それとも商品設計へのフィードバックとして製造側に伝えるべきなのかの振り分けです。この振り分けを誰が行うかを決めずにAIツールだけを入れると、分類結果が出ても次に誰が何をするかが宙に浮いたまま止まります。現場で起きがちな「AIが分類してくれたけど、結局Slackで誰かに聞いている」という状況は、責任者の不在から生まれます。

はっきり言うと、AIに問い合わせへの返品可否や個別の例外対応を判断させるのは危険です。返品理由の分類や傾向の把握はAIが担えますが、「この注文は返品を受け付けるか」という個別判断はビジネスポリシーと顧客との信頼関係に直結するため、人間が責任を持つ範囲です。AIが誤判定した場合に顧客への説明ができなくなるリスクがあり、過去の対応データに偏りがあれば特定条件の顧客だけが不利になる構造的問題も生じます。

3.FAQ更新が止まる組織は、更新の責任者と更新タイミングが決まっていない

ECサイトの構築段階でFAQページを作成した後、その内容が更新されていないケースは珍しくありません。補助金を活用して初期構築を行った事業者でも、立ち上げ後のFAQ運用ルールが設計されていないため、半年後には古い情報が残り続ける状態になります。「誰が確認したのか分からない」という状況でFAQが公開されていれば、顧客が参照した情報と実際の対応が食い違い、問い合わせがさらに増えるという逆効果になります。

FAQ更新の運用で確認すべき判断基準は次の3点です。まず更新責任者を1人に決める。複数人で共有すると全員が「誰かがやる」と思い、誰もやらない状態になります。次に更新のトリガーを決める。月次のレビュー確認時、同じ問い合わせが月5件以上になった時、商品仕様が変更になった時、といった条件を事前に決めておくと更新漏れが防げます。最後に更新後の確認フローを決める。AIが下書きを作成し、担当者が事実確認し、責任者が承認してから公開する、という最低限の流れを設計しておかないと、AI出力をそのまま公開してしまうリスクが残ります。

陥りやすい落とし穴として、FAQ・チャットボット・問い合わせフォーム・有人対応を一度に刷新しようとするケースがあります。全工程を同時に変えると、どこで回答品質が変わったのかが特定できなくなります。チャットボットが返した回答を誰も確認しなくなり、エスカレーションのルールが曖昧なまま有人対応の件数だけが減って「改善した」と見なされる。しかし実際には顧客が諦めて問い合わせをやめているだけで、レビューの評価が下がり始めてから気づく、というのが典型的な経緯です。

4.最初に潰す1工程は、過去3か月の問い合わせとレビューをAIで分類してFAQと照合することだ

ECサイトの構築後にAI活用を始めるとき、最初に手を付けるべき工程はレビュー分析と問い合わせ内容の分類です。商品ページの全面リライト、AIチャットボットの導入、自動返信の設定は、このステップの後に行う判断です。どの情報が不足しているかを把握せずに施策を打つと、直す場所を間違えるからです。

具体的な手順は次の流れです。まず過去3か月の問い合わせ内容と購入者レビューをCSVまたはテキストでエクスポートし、生成AIに「カテゴリ別に分類して件数と主な言及を一覧にしてください」と入力します。次に分類結果と現在のFAQを並べて、FAQに記載がないカテゴリや件数が多いのに回答が薄いカテゴリを特定します。そのカテゴリについて、商品ページに情報を追記すべきか、FAQに問いとして追加すべきかを担当者が判断します。AIはここで修正候補の文案を下書きします。最後に責任者が確認して公開する。この一連の流れを2週間以内に1商品カテゴリで完結させるのが最初の検証です。

先送りした場合に積み上がる損失は、問い合わせ対応時間だけではありません。同じ不満がレビューとして蓄積されると、新規顧客の購買判断に影響し、広告費をかけてサイトに来た訪問者が商品ページで離脱する確率が高まります。ECサイトの費用対効果は流入数だけでなくCVRに直結しており、商品情報の不備による離脱は広告費の回収効率を直接下げます。個人情報を入力して購入まで進む顧客の信頼は、商品ページとFAQの情報の質に支えられています。

弊社で相談を受ける場合、最初に確認するのは「過去3か月の問い合わせ上位5カテゴリが何で、現在のFAQと商品ページのどこに対応する情報があるか」です。ここが整理できていない状態でチャットボットや自動返信の設計に進む依頼には、まず業務フローの整理から入ることを提案します。レビュー分析の設計、FAQ更新の責任フロー、AIが下書きして人間が確認する運用設計、商品情報修正の優先順位付けまで、現場で実際に使われる形に落とし込む支援を行っています。最初の2週間で1カテゴリの問い合わせ分類とFAQ照合を完結させることが、全体の運用改善の起点になります。