ヒアリング対話の設計と状態管理

聞くべきことを聞き漏らさない質問フローと、会話の状態をどう管理するかの設計

対話設計ヒアリング状態管理質問フローUX
読了時間: 8分

はじめに

AI接客アドバイザーの心臓部は、お客様との対話です。ここが雑だと、いくら賢いレコメンドエンジンを積んでも「見当違いの提案をするAI」になってしまいます。

この記事では、モーターサイクル用品を扱うECサイトの接客AIで、聞くべきことを聞き漏らさない質問フローと、会話の状態をどう管理したかを解説します。自由な会話でありながら、必要な情報は確実に集める。その両立が設計の肝でした。

何を聞くべきかを決める

ヒアリング項目の定義

まず「良い提案をするために最低限これだけは知りたい」という項目を洗い出しました。ベテラン店員が接客の冒頭で確認していることを言語化した形です。

これらを必須項目あれば良い項目に分け、必須が揃った時点で提案に進める設計にしました。全部を無理に埋めようとしないのがコツです。

聞きすぎないという判断

ヒアリング設計で一番悩んだのは、どこまで聞くかの線引きです。情報は多いほど提案精度は上がりますが、質問が増えるほどお客様は面倒に感じて離脱します。

そこで、必須項目が揃えばAIの判断で提案フェーズに移るようにし、残りの情報は提案後の会話でゆるやかに補う方針にしました。

会話の状態を管理する

ステートで充足状況を追う

対話型のヒアリングで難しいのは、「今どこまで聞けたか」を見失わないことです。LLMは前の発言を都度読み直せますが、それだけに頼ると同じことを二度聞いたり、聞き漏らしたりします。

そこで、ヒアリング項目の充足状況を**ステート(状態)**として明示的に持たせました。会話のたびに、回答から読み取れた情報でステートを更新し、まだ空いている項目を次の質問の候補にします。

状態を更新するAPI設計

対話は、役割を分けた複数のAPIで制御しています。会話の各ターンでステートを読み書きすることで、LLMの気まぐれに左右されず、確実にヒアリングを進められます。

対話APIの役割分担
start

セッションを初期化し、空のステートと最初の質問を返す

message

ユーザー発言を受け取り、update-stateで充足状況を更新。次の質問を生成

update-state

発言から抽出した用途・好み・予算などをステートに反映

recommend

必須項目が揃ったら提案生成へ。ステートを検索条件に変換

ステートを別管理にしたことで、「何を聞いて何が残っているか」がコード側で常に把握できます。デバッグや改善もしやすくなりました。

抽出のゆらぎに備える

お客様の発言は自由なので、「週末に遠出する」のような曖昧な表現も来ます。これをLLMに解釈させて用途「ツーリング」に変換するわけですが、当然ゆらぎが出ます。

対策として、抽出結果には確信度の考え方を持たせ、曖昧なままステートを断定しないようにしました。自信がなければ「長距離ツーリング向けということでよろしいですか?」と確認を挟み、誤った前提のまま提案が進むのを防いでいます。

対話体験を磨く

一問一答にしない

質問を機械的に一つずつ返すと、フォーム入力と変わらず味気なくなります。そこで、お客様の発言に軽く共感や補足を添えてから次の質問に移るようにしました。

質問の返し方
BEFORE
味気ない一問一答

「予算はいくらですか?」だけを繰り返す

AFTER
接客らしい応答

「長距離ツーリングなら快適性が効いてきますね。ご予算の目安はありますか?」

ちょっとした一言があるだけで、「話を聞いてもらえている」感覚が生まれます。ここはLLMの得意分野なので、積極的に活かしました。

途中離脱に強くする

対話の途中で離脱されても、次に来たときに続きから再開できるよう、ステートはセッションに紐づけて保持します。ゼロからやり直させないだけで、体験は大きく変わります。聞き取った内容を無駄にしない配慮が、地味ながら効いてくる部分です。

まとめ

ヒアリング対話の設計で意識したのは、次の3点です。

  1. 項目の明確化 — 必須とオプションを分け、聞くべきことを定義する
  2. ステート管理 — 充足状況を明示的に持ち、聞き漏らしと二度聞きを防ぐ
  3. 接客らしさ — 聞きすぎず、共感を添え、離脱にも強くする

こうして集めた要件を、次はどう提案に変えるか。根拠のある提案を作るナレッジベースとRAGの仕組みは「商品マスタ×RAGで『根拠ある提案』を作る」で、システム全体像は「AI接客アドバイザー — 対話型の商品診断・レコメンド」で解説しています。