AI接客のシナリオ設計｜ユーザー体験を損なわない作り方

AI接客を​導入した​ものの、​「会話が​途中で​止まる」​「ユーザーが​離脱する」と​いう​声は​少なく​ありません。​その​多くは、​AI​その​ものの​性能よりもシナリオ設計の​甘さに​起因しています。​どれほど​高精度な​モデルを​使っても、​会話の​流れが​設計されていなければ、​ユーザー体験は​損なわれます。​本記事では、​AI接客の​シナリオ設計に​おいて​押さえるべき​考え方と、​実装時の​具体的な​ポイントを​整理します。

シナリオ設計が​重要な​理由

AI接客に​おける​会話設計とは、​ユーザーの​発話に​対してどのように​応答し、​どこへ​誘導するかを​事前に​定義する​作業です。​チャットボットや​問い合わせAIは、​ユーザーが​「次に​何を​言うか」を​予測した​設計に​なっていないと、​すぐに​行き詰まります。

シナリオが​不十分な​場合に​起こりがちな​問題は​以下の​通りです。

• 想定外の​質問に​「わかりません」と​返答し、​会話が​終了する
• 選択肢が​多すぎて​ユーザーが​迷い、​離脱する
• 同じ​質問を​繰り返し確認してしまい、​ユーザーが​煩わしさを​感じる
• 問い合わせの​目的を​達成する​前に​セッションが​切れる

これらを​防ぐ​ためには、ユーザーの​目的から​逆算した​会話フローを​設計する​ことが​不可欠です。

なぜ​「設計なし」では​機能しないのか

AI接客ツールの​多くは、​自然言語で​質問を​受け取り、​設定された​情報を​もとに​回答を​生成します。​しかし​「設定された​情報」が​薄かったり、​会話の​つなぎ方が​定義されていなかったりすると、​AIは​毎回ゼロベースで​答えを​探すことになります。​結果と​して、​同じ​質問でも​返答が​変わったり、​文脈を​引き継げずに​的外れな​回答を​返したりします。

特に​問題に​なるのは、ユーザーが​複数の​目的を​ひとつの​発話に​込めてくるケースです。​たとえば​「料金を​確認して、もし予算に​合えば​すぐ​申し込みたい」と​いう​意図は、​「料金確認」と​「申し込み」と​いう​2段階の​フローを​含んでいます。​シナリオが​ない​状態では、​AIは​料金を​答えるだけで​止まり、​申し込みへの​誘導が​発生しません。

また、​ユーザーが​途中で​気が​変わったり、​最初と​別の​話題を​持ち出したりする​ことも​日常的に​起こります。​「戻り」​「話題転換」​「前置きの​ある​質問」と​いった​パターンに​対して​どう​応答するかを​設計しておく​ことが、​離脱防止の​鍵に​なります。

業種別に​見る​「詰まりやすい​ポイント」

シナリオ設計が​特に​重要に​なる​業種・シーン別に、​よく​起きる​問題を​整理します。

業種・シーン	よく​起きる​詰まり
飲食店の​予約受付	「何人で」​「いつ」​「何時」を​別々に​聞かれると​途中で​諦める​ユーザーが​出る
ECサイトの​サポート	注文番号を​聞く​タイミングが​早すぎると​「まだ​決めて​ない」で​離脱される
美容院・サロンの​問い合わせ	メニューが​多いと​最初の​選択肢で​迷い、​そのまま​ウィンドウを​閉じる
BtoBの​サービス資料請求	社名・​担当者名・電話番号を​一度に​聞こうと​すると​途中で​止まる
医療・クリニックの​案内	「受診したい​症状」を​自由入力に​すると​広すぎて​絞り​込めない

いずれの​ケースも、情報収集の​順番と​聞き方の​粒度を​設計段階で​調整する​ことで​大幅に​改善できます。

シナリオ設計の​基本ステップ

1. ユーザーの​目的を​整理する

最初に​「この​AI接客を​通じて​ユーザーが​達成したい​ことは​何か」を​明確にします。​購入サポート、​FAQ対応、​予約受付など、​目的に​よって​会話の​構造は​大きく​変わります。​目的が​複数ある​場合は、​優先度を​付けて​設計に​反映させましょう。

目的整理の​具体的なやり方：

まず、​「ユーザーが​AIと​会話を​始める​直前に​何を​していたか」を​想像する​ことから​始めます。​商品ページを​見ていた、​料金表を​見ていた、​問い合わせフォームの​前で​迷っていた​——それぞれ動機が​異なります。

• 商品ページから​チャットを​開いた​ユーザー → 購入を​検討しているが、​決め手が​足りない​状態
• トップページの​ポップアップから​入ってきた​ユーザー → サービス全体を​まだ​知らない​状態
• FAQ閲覧後に​チャットを​開いた​ユーザー → 自己解決を​試みたが​答えが​見つから​なかった​状態

この​「入口の​文脈」に​応じて​シナリオの​入り口メッセージを​変えると、​会話の​出だしから​的確に​なります。​WayBotでは、​ページ単位で​ウィジェットの​初期メッセージを​変える​設定が​できる​ため、​この​観点を​活かしやすい​構成に​なっています。

また、​目的を​整理する​際には​「何を​達成すれば​成功か」を​数値で​定義しておくと、​後の​シナリオ評価に​役立ちます。​たとえば​「予約の​完了」​「資料請求フォームへの​誘導」​「担当者への​電話アポ」など、​明確な​ゴールを​設定して​おきましょう。

2. 主要な​会話パターンを​洗い出す

実際に​寄せられた​問い合わせ履歴や​カスタマーサポートの​ログを​参照し、​頻出する​質問や​流れを​抽出します。​新規導入の​場合は、​担当者への​ヒアリングや​競合サービスの​FAQを​参考にします。

洗い出した​会話パターンは​以下のように​分類すると​整理しやすくなります。

分類	内容の​例
主要フロー	購入・​申し込み・​予約など、​ゴールに​直結する​会話
サポートフロー	配送状況確認・​返品・​変更など、​よく​ある​問い合わせ
離脱フロー	「やっぱり​いい」​「人に​話したい」などの​中断パターン
エラーフロー	理解できなかった​場合・想定外の​入力への​対応

会話パターンの​洗い出し方：実践的な​手順

新規導入の​場合に​ログが​ない​場合でも、​以下の​手順で​質問パターンを​収集できます。

1. スタッフへの​ヒアリング：電話や​メールで​月に​何件来るか、​どんな​内容が​多いかを​聞く。​「よく​ある​質問トップ10」を​挙げて​もらうだけで​設計の​8割が​決まることも​多い。
2. 問い合わせフォームの​過去メール確認：件名や本文から​テーマを​分類し、​頻度順に​並べる。
3. Googleビジネスプロフィールの​レビュー確認：​「〇〇が​分かりにくかった」​「〇〇を​電話で​聞いた」など、​潜在的な​疑問が​埋まっている​ことがある。
4. 競合他社の​FAQページ確認：同業他社が​公開している​FAQは、​業界共通の​疑問点を​ほぼ網羅している​ことが​多い。

これらを​組み合わせると、​初回設計でも​30〜​50パターン程度の​質問・回答の​たたき台を​作る​ことができます。

バリエーション表現の​収集も​忘れずに

同じ​内容でも、​ユーザーに​よって​言い方は​違います。​「営業時間は？」​「何時まで​開いてる？」​「今日は​営業してますか？」は​すべて​同じ​意図です。​ひとつの​意図に​対して​3〜5通りの​言い​換えを​用意しておくと、​AIが​意図を​正しく​捉えやすくなります。

3. 分岐と​復帰を​設計する

会話は​一本道では​ありません。​ユーザーは​シナリオの​途中で​話題を​変えたり、​前の​ステップに​戻ったりします。​その​ため、​各ステップに​「戻る」​「やり直す」​「担当者に​繋ぐ」などの​復帰ルートを​用意しておく​ことが、​ユーザー体験の​維持に​つながります。

特に​**エスカレーション​（有人対応への​切り​替え）​**の​タイミングは​重要です。​AIが​対応できないと​判断した​際に、​スムーズに​有人チャットや​電話へ​誘導できる​導線を​必ず設けてください。

分岐設計の​具体的な​考え方

分岐は​大きく​2種類あります。

• ユーザー主導の​分岐：ユーザーが​選択肢を​選ぶ、​または​自由入力で​別の​話題を​出す
• システム主導の​分岐：AIが​回答できない・​ゴールに​到達した・エラーが​発生したなどの​条件で​自動的に​分岐する

それぞれに​対して​「次に​どこへ​行くか」を​定義します。​ユーザー主導の​場合は​メニュー選択や​発話内容に​よって​分岐先が​変わります。​システム主導の​場合は​以下のような​条件を​設定します。

条件	推奨する​分岐先
3回連続で​意図を​認識できなかった	エスカレーション提案​（有人・電話誘導）
ユーザーが​「わからない」​「難しい」と​発言	選択肢を​絞り​込んで​再提示、​または​担当者連絡案内
ゴール到達​（申し込み完了など）	完了メッセージ＋次の​アクション案内​（確認メールの​案内など）
セッション開始から​一定​時間経過・操作なし	「引き続きご不明な​点が​あれば​お声が​けください」など​離席メッセージ

エスカレーション設計の​ポイント

エスカレーションは​「AIが​負けを​認める」のではなく、​「より​よい​対応を​提供する​手段」と​して​設計します。​以下の​点を​意識してください。

• エスカレーションの​提案は​「〇〇に​ついては​スタッフが​詳しく​ご案内できます」のように、​有人対応の​価値を​伝える​言い方に​する
• 電話番号・​メールアドレス・​有人チャットの​リンクは、​エスカレーション提案と​同じ​メッセージに​含める​（別ステップに​すると​離脱する）
• 有人対応の​受付時間外の​場合は​「〇〇時〜〇〇時に​お電話ください」と​明示するか、​メールフォームへ​誘導する

4. 応答文の​質に​こだわる

会話設計に​おいては、​応答の​内容だけでなく文体・長さ・​タイミングも​重要な​要素です。​以下の​点を​意識して​応答文を​作成します。

• 一文を​短く​保つ：長い​文章は​読まれに​くく、​次の​行動を​促しにくい
• 選択肢は​3つ以内に​絞る：多すぎると​選べずに​離脱されやすい
• 肯定的な​言い回しを​使う：「できません」より​「〇〇と​いう​方法が​あります」
• ユーザーの​言葉を​引用する：​「先ほど​ご質問いただいた​〇〇に​ついて」など、​文脈を​引き継ぐ

応答文を​書く​際の​具体的な​原則

読みやすい​チャット応答文には、​紙の​マニュアルや​長文メールとは​異なる​ルールが​あります。

まず、1メッセージに​含める​情報は​1〜2個までを​原則にします。​「営業時間は​10〜19時です。​定休日は​火曜日です。​また、​祝日は​特別営業と​なります。​詳しくは​ウェブサイトを​ご確認ください」のように​複数の​情報を​一度に​詰め込むと、​ユーザーは​読み飛ばします。​「営業​時間：10〜19時​（火曜定休）」のように​要点を​1行で​伝え、​補足が​必要なら​次の​メッセージに​分けます。

次に、問い​かけで​終わらせるを​意識します。​回答を​返した​後に​「ご不明点は​ありますか？」で​終わるだけでは​受動的すぎます。​「配送の​詳細に​ついては、​注文番号が​あるとより​正確に​ご案内できます。​注文番号は​お手元に​ありますか？」のように、​次の​アクションへ​誘う​問い​かけに​すると​会話が​続きます。

また、ネガティブワードの​言い​換えも​重要です。

使いが​ちな​表現	改善後の​表現
「対応できません」	「〇〇と​いう​形で​ご対応が​可能です」
「わかりません」	「詳しくは​担当者から​ご案内します」
「そちらは​管轄外です」	「〇〇部門を​ご案内します」
「お待ちください」​（返答なし）	「確認中です。​数秒お待ちください」

文体に​ついては、​サービスの​トーンに​合わせます。​カジュアルな​ECサービスでは​「〜ですよ！」​「〜​しちゃいましょう」なども​自然ですが、​医療・​金融・​法律系では​「〜で​ございます」​「〜を​おすすめします」と​いう​丁寧な​表現を​維持します。​ただし、​どちらの​場合も過度に​機械的・​マニュアル的な​文体は​避けるのが​ポイントです。

よく​ある​設計ミスと​その​対処法

AI接客の​シナリオ設計では、​以下のような​ミスが​繰り返されがちです。

1. 想定問答が​少な​すぎる：主要フローしか​設計せず、​少し​外れた​質問で​詰まる。​対処：ログや​ヒアリングを​基に、​最低でも​主要フロー×3〜​5パターンの​派生を​用意する。

2. ゴールが​曖昧なまま​設計する：​「とりあえず会話できれば​いい」と​いう​設計は、​ユーザーを​目的地に​連れて​行けない。​対処：各シナリオに​「この​フローの​ゴール​（ゴール到達の​定義）」を​明文化する。

3. テストが​少ない：設計者自身が​試すだけでは​偏りが​生じる。​対処：実際の​ユーザーに​近い​属性の​人間に​試して​もらい、​詰まった​ポイントを​記録・改善する。

4. リリース後に​放置する：ユーザーの​行動は​変化する​ため、​初期設計が​永続的に​機能するとは​限らない。​対処：定期的に​会話ログを​確認し、​離脱が​多い​ステップや​未対応の​質問を​シナリオに​反映する。

よく​ある​設計ミスの​掘り下げ

ミス1：想定問答が​少な​すぎる

最初の​シナリオで​「主要な​流れだけ​作って​公開する」ことは​少なく​ありません。​しかし​実際の​ユーザーは、​想定された​動線を​そのままた​どる​ことは​ほとんど​ありません。​「まず料金だけ聞いて、​後で​プランを​確認したい」​「一般的な​使い方ではなく​自社の​特殊な​ケースに​使えるか​聞きたい」など、​斜め方​向からの​質問が​多く​来ます。

対処と​しては、​主要フローの​ゴールから​逆算して​「この​ゴールに​至るまでに、​ユーザーが​持ちうる​疑問は​どれだけ​あるか」を​列挙します。​最低でも​ゴールひとつに​対して​10〜15個の​質問パターンを​想定すると、​設計の​網羅性が​高まります。

ミス2：ゴールが​曖昧なまま​設計する

「なんとなく​質問に​答えられる」状態と​「ユーザーの​目的達成を​支援できる」​状態は​別物です。​シナリオの​ゴールが​「会話が​成立する​こと」だと、​導線が​薄くなります。

た​とえば、​美容サロンの​AI接客で​あれば​「予約の​完了」が​ゴールです。​ゴールが​明確で​あれば、​「メニューの​説明」​「スタッフ紹介」​「空き時間確認」​「予約フォームへの​誘導」と​いう​会話の​流れが​自然に​決まります。​逆に​「スタッフが​対応しやすいように​情報を​集める​こと」も​ゴールの​一形態です。​この​場合は、​名前・連絡先・​来店希望日時を​取得して​スタッフに​渡す流れを​設計します。

ミス3：テストが​少ない

設計者本人が​テストする​場合、​「自分が​想定した​質問」​しかしない​傾向が​あります。​特定の​表現でしか​質問しない、​選択肢の​順番に​影響される、​知識バイアスで​「これは​常識だから​聞かないはず」と​省略する​——これらが​抜け漏れを​生みます。

改善策と​して​有効なのは、実際の​ユーザーに​近い​第三者に​3〜5人テストして​もらうことです。​テスト後に​「どこで​迷ったか」​「何を​聞いたら​答えが​返って​こなかったか」を​口頭で​ヒアリングすると、​設計者が​気づかなかった​穴が​見えてきます。

ミス4：リリース後に​放置する

AI接客は​導入後の​運用で​品質が​決まると​いっても​過言では​ありません。​最初は​対応できていた​質問も、​サービス改定や​キャンペーン開始で​古くなります。​また、​ユーザーの​言葉は​季節や​流行で​変化します​（新機能の​発表後に​「〇〇機能は​使えますか？」と​いう​質問が​急増するなど）。

放置していると、​未対応の​質問が​積み​上がり、​ユーザー満足度が​下がります。​月に​一度​程度は​ログを​確認し、​「AIが​答えられなかった​質問の​上位10件」を​確認して​シナリオに​追加する​サイクルを​作る​ことを​推奨します。

見落と​されが​ちな​設計ミス

上記4つに​加えて、​現場で​よく​見られる​見落としを​補足します。

• 初回挨拶が​長すぎる：​「こんに​ちは！​私は​AIアシスタントの​〇〇です。​ご質問が​あれば​なんでも​どうぞ！」のような​長い​挨拶は、​早く​答えを​得たい​ユーザーには​邪魔に​映ります。​初回メッセージは​端的に、​かつ​「何が​できる​AIか」を​一言で​伝える​設計が​有効です。
• 選択肢ボタンと​自由入力を​混在させすぎる：​「ボタンを​押しても​いいし自由に​入力しても​いい」と​いう​設計は、​どちらを​使えば​いいか​ユーザーが​迷います。​基本は​ボタン選択に​統一し、​自由入力が​必要な​場面​（名前・​日付など）だけテキスト入力を​促す設計の​ほうが​シンプルです。
• 「その他」​ボタンを​最後の​逃げ道に​している：​「その​他」を​押した​ユーザーに​自由入力させるだけでは、​エスカレーション機会を​逃します。​「その​他」の​先にも​「よく​ある​追加質問」を​数パターン用意しておくか、​「より​詳しい​ご相談は​こちら」と​して​担当者連絡先に​誘導しましょう。

継続的な​改善の​仕組みを​作る

シナリオ設計は​一度​完成したら​終わりでは​ありません。​AI接客の​品質を​維持・​向上させるには、​以下のような​運用サイクルを​設ける​ことが​効果的です。

• 月次で​ログを​確認し、​未解決件数と​離脱ポイントを​記録する
• 未対応の​質問を​カテゴリ別に​集計し、​優先度の​高い​ものから​シナリオに​追加する
• 季節・​キャンペーン・​新サービスの​タイミングに​合わせて​応答内容を​更新する

問い合わせAIの​精度は、​こうした​継続的な​シナリオ更新に​よって​着実に​向上します。

運用サイクルの​具体的な​設計

継続的な​改善を​「やろうと​思えば​できる」​状態ではなく​「自然に​回る​仕組み」に​するには、​担当者・​頻度・​確認項目を​具体的に​決めて​おく​必要が​あります。

推奨する​運用サイクルの​例：

タイミング	実施内容	担当
毎週	未対応質問の​数と​内容を​確認、​急増している​質問が​あれば​その​週中に​追加	運用担当者
月次	離脱ポイントの​確認・応答の​改善・​不要な​シナリオの​整理	運用担当者＋管理者
キャンペーン前	関連する​質問の​追加・価格変更の​反映・​期間限定フローの​追加	担当者
季節の​変わり目	季節商品・​繁忙期対応・​休業案内の​更新	担当者
半年〜1年ごと	シナリオ全体の​棚卸し・​不要な​フローの​削除・構造の​見直し	管理者

ログ確認で​見るべき​指標：

ログを​確認する​際には、​以下の​観点を​持つと​改善の​優先度が​つけやすくなります。

• 未解決率：全セッションの​うち、​ゴール未達成で​終了した​割合。​これが​高い​ほど​シナリオの​網羅性に​課題が​ある。
• 再質問率：同じ​ユーザーが​同じ​意図の​質問を​繰り返している​割合。​応答が​的外れな​サインと​判断できる。
• 離脱ステップ：どの​メッセージの​タイミングで​会話が​止まるかを​確認する。​特定の​ステップで​離脱が​集中している​場合は、​その​メッセージの​内容・​選択肢・文量を​見直す。
• エスカレーション到達率：​エスカレーションまで​進んだ​会話の​割合と、​その後の​対応完了率。​エスカレーションが​多すぎる​場合は​シナリオが​薄い、​少な​すぎる​場合は​エスカレーション導線が​機能していない​可能性が​ある。

シナリオ追加の​優先順位の​付け方

改善候補が​複数出てきた​場合、​すべてを​同時に​対応するのは​非効率です。​以下の​基準で​優先度を​判断します。

1. 頻度が​高い：件数が​多い​未対応質問ほど、​対応した​ときの​効果が​大きい
2. ゴールに​直結する：申し込みや​購入に​関わる​流れで​詰まっているなら、​最優先で​対応する
3. 対応コストが​低い：単純な​FAQの​追加は、​数分で​対応できる​ため即時対応を​推奨する
4. クレームに​つながっている：ユーザーが​困惑・​不満を​示した​会話は、​信頼性への​影響が​大きいため優先度を​上げる

更新作業を​軽く​する​工夫

シナリオ更新が​「面倒な​特別作業」に​なると、​後回しに​なります。​更新を​習慣化する​ための​工夫を​紹介します。

• テンプレートを​用意する：Q&Aの​追加フォーマットを​決めて​おくと、​担当者が​迷わずに​追加できる
• FAQ台帳を​別途管理する：シナリオとは​別に​「Q&A一覧スプレッドシート」を​持ち、​更新の​際は​そちらを​編集して​シナリオに​反映する​流れに​すると​管理が​シンプルに​なる
• 更新履歴を​残す：いつ、​何を、なぜ​変更したかを​記録しておくと、​後から​設計の​意図を​把握しやすくなる

よく​ある​質問​（FAQ）

Q：シナリオの​数は​どれくらいから​始めれば​よいですか？

A：最初は​「主要フロー3〜​5本・​エラーフロー1本・​エスカレーションフロー1本」の​計5〜7本程度で​リリースして、​実際の​ログを​見ながら​追加するのが​現実的です。​最初から​完璧な​シナリオを​作ろうと​して​公開が​遅れるより、​少ない数でも​早く​公開して​実データを​集める​ほうが​最終的に​良質な​シナリオに​仕上がります。

Q：​自由入力と​ボタン選択は​どちらを​使うべきですか？

A：用途に​よります。​「どんな​用件か」​「いつが​希望か」などの​幅​広い​入力を​受け取る​場面では​ボタン選択が​適しています​（認識ミスが​減り、​ユーザーの​手間も​省ける）。​一方、​名前・​メールアドレス・​注文番号など​決まった​形式の​情報は​テキスト入力が​必要です。​組み合わせと​して、​まず選択肢で​絞り​込んでから​詳細を​テキスト入力させる​流れが​使いやすい​シナリオに​なります。

Q：AIが​変な​回答を​してしまった​場合、​どう​対処すれば​よいですか？

A：まず、​そのやり取りを​ログで​確認し​「どの​発話に​対してどの​応答が​返ったか」を​把握します。​次に、​その​発話パターンに​対する​正しい​応答を​シナリオに​追加します。​万が​一ユーザーから​直接クレームが​あった​場合は、​有人対応で​丁寧に​フォローしつつ、​シナリオ修正を​優先的に​行います。​WayBotでは​会話ログを​管理画面から​確認でき、​問題の​あった​会話を​特定しやすい​設計に​なっています。

まとめ

AI接客の​シナリオ設計は、​ユーザーの​目的の​整理・会話パターンの​洗い出し・分岐と​復帰の​設計・応答文の​最適化と​いう​段階を​踏むことで、​実用的な​品質に​仕上げる​ことができます。​また、​リリース後の​継続的な​改善を​運用に​組み込むことが、​長期的な​ユーザー体験の​維持に​つながります。​AIWAY Groupでは、​こうした​接客AIの​導入から​運用・​シナリオ改善まで​一貫して​支援しています。​詳細は​お気軽に​ご相談ください。