ECのCS問い合わせデータをBigQueryに集約して商品改善に活かす

はじめに：問い合わせは商品改善の宝の山なのに埋もれている

ECサイトを運営していると、お客さまから毎日のように問い合わせが届きます。

「サイズ感が分からないので教えてほしい」
「届いた商品の色がイメージと違った」
「注文した数量と違うものが届いた」
「ラッピングに対応していますか」

こうした問い合わせは、その場で1件ずつ丁寧に返信して、それで終わりになっていないでしょうか。返信すれば対応としては完了です。けれど、問い合わせの中身そのものは「お客さまが何でつまずいたか」を直接教えてくれる、とても貴重な情報です。

たとえば「サイズ感が分からない」という質問が月に何十件も来ているなら、それは商品ページの寸法表記が足りていないサインかもしれません。「色がイメージと違った」が多い商品は、写真の見せ方を見直す価値があります。一件ずつ見ていると気づけないこうした傾向は、まとめて眺めてはじめて見えてきます。

問題は、問い合わせデータがあちこちに散らばっていることです。メールはメールソフトの中、チャットはチャットツールの中、電話はメモ書きの中。これでは「先月どんな質問が多かったか」を振り返るのも一苦労です。

この記事では、散らばったCS問い合わせをBigQueryに集約し、AIで分類・要約して、商品やFAQ、商品説明文の改善につなげるという考え方を紹介します。実装の細部よりも、全体の流れと勘どころを押さえることを目的とした構想メモとして読んでください。

まず問い合わせデータを一か所に集める

最初のステップは、バラバラの問い合わせを一つのテーブルにまとめることです。集約先としてBigQueryを選ぶ理由は、テキストの大量保存が得意で、後述するAIによる分析までひとつの場所で完結できるからです。

集めたい代表的な経路は次のようなものです。

問い合わせメール（カスタマー窓口の受信ボックス）
サイト上のチャット・チャットボットのログ
問い合わせフォームの送信内容
電話対応のメモ（手入力でも構いません）

これらを一度に完璧につなぐ必要はありません。まずは件数の多い経路ひとつ、たとえばメールかフォームから始めるのが現実的です。

集約するときは、最低限こんな項目をそろえておくと後の分析が楽になります。

カラム	内容
`received_at`	問い合わせを受け取った日時
`channel`	メール／チャット／フォームなどの経路
`body`	問い合わせ本文（テキスト）
`order_id`	分かれば注文番号（商品との突合に使う）
`product_id`	分かれば対象商品

order_id や product_id がひも付いていると、「この商品にどんな問い合わせが多いか」を商品単位で見られるようになります。最初は空でも構いませんが、入れられるなら入れておくと後で効いてきます。

集約の進め方

経路ごとにエクスポート方法は違います。フォームならスプレッドシートに溜めてからBigQueryへ取り込む、メールなら定期的にCSVで書き出して読み込む、といった地道な方法でも十分にスタートできます。大事なのは、自動化を最初から目指しすぎず、まず「一か所に溜まっている状態」を作ることです。

溜まりはじめれば、それだけで「今月は先月より問い合わせが2割増えた」といった件数の推移が見えるようになります。これは集約の最初のごほうびです。

AIでカテゴリ分類と要約をする

テキストが溜まったら、次は中身を分類していきます。問い合わせ本文をそのまま人が全部読むのは大変ですが、BigQueryではテーブルのテキストカラムをそのままAI（Gemini）に渡して、分類や要約をさせることができます。

やりたいことは、たとえば次のような処理です。

各問い合わせを「サイズ・寸法」「品質・不良」「配送」「在庫・再入荷」「返品・交換」などのカテゴリに振り分ける
長い本文を1〜2文の要約に縮める
「不満なのか／単なる質問なのか」といった温度感を判定する

これらをSQLの中でAI関数に任せれば、何百件・何千件の問い合わせでも一括で処理できます。

生成系のAI関数は、名称・引数・呼び出し方（ML.GENERATE_TEXT / AI.GENERATE など）が版によって変わります。実際に書く前に、必ず最新の公式ドキュメントで現行の関数名と構文を確認してください。ここでは「テキストカラムをAIに渡して結果を新しい列として受け取る」という考え方だけ押さえておけば十分です。

イメージとしては、こんな流れのクエリになります（関数名・引数は版によって異なるため、骨組みとして読んでください）。

-- ※関数名・引数は最新の公式ドキュメントで要確認
SELECT
  received_at,
  channel,
  body,
  -- 問い合わせ本文をAIに渡してカテゴリを判定させる想定
  ai_classify_result AS category,
  -- 同じく本文を1〜2文に要約させる想定
  ai_summary_result  AS summary
FROM
  `your_project.cs.inquiries`

実際にはAI関数の呼び出し部分が入りますが、構造としては「元のテキスト列の隣に、カテゴリ列と要約列が増える」という形になります。これだけで、ずらりと並んだ生の問い合わせが、集計できるデータに変わります。

コストには気をつける

AIによるテキスト処理は、処理した分量に応じた課金が発生します。数千件をいきなり全件処理する前に、まず数十件だけで試して、分類の精度とコスト感をつかんでおくのがおすすめです。一度処理した結果はテーブルに保存しておけば、何度も再処理せずに済みます。生成AIを使ったテキスト分析の進め方は、BigQueryのAI関数でテキストを分析する記事で詳しく触れています。

多い不満を商品・FAQ・説明文の改善につなげる

分類と要約ができたら、ここからが本題です。カテゴリ別に件数を集計すれば、「どこでお客さまがつまずいているか」が一目で分かります。

SELECT
  category,
  COUNT(*) AS inquiry_count
FROM
  `your_project.cs.inquiries_classified`
WHERE
  received_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  category
ORDER BY
  inquiry_count DESC

上位に並んだカテゴリが、改善の優先順位そのものです。よくあるパターンと打ち手を並べると、こんなふうに整理できます。

多い問い合わせ	考えられる原因	改善の打ち手
サイズ・寸法	商品ページに寸法情報が足りない	寸法表・着用例・実寸の追記
品質・不良	写真と実物のギャップ	写真の差し替え、注意書きの追加
配送	納期や送料の説明が分かりにくい	配送ページ・FAQの見直し
在庫・再入荷	入荷予定が分からない	再入荷通知の導線を用意
返品・交換	手順が分かりにくい	返品ポリシーの明確化

打ち手の方向性は、大きく3つに分けて考えると動きやすくなります。

商品そのものの改善：不良やギャップが多いなら、仕様や仕入れ、写真を見直す
FAQの強化：質問が定型的なら、FAQに足してお客さまが自己解決できるようにする
商品説明文の改善：購入前に知りたかった情報が不足しているなら、説明文に先回りで書いておく

特にFAQと商品説明文の改善は、効果を測りやすいのが利点です。改善した商品やページについて、翌月以降その種類の問い合わせが減ったかどうかを、同じBigQueryのテーブルで追えます。「説明文を直したら、サイズに関する問い合わせが前月比で減った」と数字で確認できると、改善のサイクルが回りはじめます。

特定の商品に問い合わせが集中しているなら、product_id で絞り込んで深掘りします。問い合わせが多い商品は、裏を返せば関心が高い商品でもあります。説明を整えるだけで、離脱していた購入希望者を取りこぼさずに済むかもしれません。在庫や売れ行きの観点とあわせて見たい場合は、GA4とBigQueryで在庫回転と不良在庫を見る記事も参考になります。

個人情報の取り扱いには十分注意する

問い合わせ本文には、お客さまの氏名・住所・電話番号・メールアドレスといった個人情報が含まれていることがあります。ここは慎重に扱う必要があります。

⚠️ PII（個人を特定できる情報）の取り扱いに注意してください。問い合わせ本文には氏名・連絡先・住所などが混ざることがあります。分析の目的に照らして本当に必要な項目だけを保存し、不要な個人情報は取り込み時にマスキングや削除を検討してください。アクセス権限は担当者に限定し、自社のプライバシーポリシーや関連法令に沿った運用になっているかを必ず確認しましょう。判断に迷う場合は、保存・分析の前に社内の責任者に相談してください。

分析で見たいのは「どんな内容の問い合わせが多いか」という傾向であって、個々のお客さまが誰かではありません。氏名や連絡先を落としてしまっても、カテゴリ分類や要約には支障がないケースがほとんどです。必要最小限のデータで分析する、という原則を最初に決めておくと安心です。

まとめ

CS問い合わせは、お客さまが自分の時間を使って「ここでつまずいた」と教えてくれている、貴重なフィードバックです。一件ずつ返信して終わりにするのはもったいない情報です。

この記事で紹介した流れを振り返ると、次のようになります。

バラバラの問い合わせを、まずBigQueryに一か所に集める
AI関数でカテゴリ分類と要約をして、集計できるデータに変える
多いカテゴリを起点に、商品・FAQ・商品説明文を改善する
改善後に問い合わせが減ったかを、同じデータで追いかける
その間、個人情報の取り扱いには細心の注意を払う

最初から完璧な仕組みを作る必要はありません。件数の多い経路ひとつを集約し、数十件をAIで試しに分類してみるところから始めれば十分です。手元に溜まっていく問い合わせデータが、商品改善のヒントの宝庫に変わっていきます。