「恐れ入りますが、ご用件をもう少し詳しく教えていただけますか」
「いま契約している自動車保険に、車をもう1台追加したいんです」
「自動車保険の新規ご契約をご検討のお客さまは、こちらのページをご覧ください」
「いや、新規じゃなくて、いまの契約に追加を、、、」
夜、スマホの小さなチャット画面に向かって、筆者は誰にも聞こえないため息をつきました。
長野に移住してから、生活の足として車をもう1台買い足すことになりまして。(都会と違って、こちらでは大人1人に1台が基本装備なのです。移住のいきさつは、自己紹介で白状しております。)で、保険会社のサイトを開いて、既存の契約に車を追加する手続きをしようとした訳です。
用件としては、かなり簡単な部類のはずです。契約者は筆者。契約はすでにある。そこに車を1台足したい。必要な情報を並べるフォームが1枚あれば、たぶん5分で終わる。
ところが、サイトのどこを探しても、その入口が見つからない。案内されるのは「AIチャットで質問する」と、ごく限られた電話窓口だけ。かくして筆者は、5分で終わるはずの用件のために、チャットボットとの質問と回答のラリーを、延々と続けることになったのでした。
このラリー、経験のある方なら分かっていただけると思うのですが、地味に消耗するんです。言い方を変えれば伝わるかと思って、「車両の追加」「2台目の契約」「既存契約の変更」と、こちらの語彙を総動員して言い換えてみる。そのたびに、微妙に的を外したFAQページへのリンクが返ってくる。じゃあ電話だ、と番号を探せば、受付は平日の日中だけ。こちとら仕事が終わってから手続きしたいのに、、、と、画面の前で行き場をなくす訳です。
入口を、チャットに絞ってはいけなかった
このとき筆者が消耗した理由は、ボットの頭の悪さではありません。むしろ逆で、応答そのものは丁寧だし、日本語も流暢なんです。
問題は、もっと手前にありました。この用件は、そもそも会話に向いていなかった。
契約変更のような手続きは、必要な項目が最初から決まっています。車検証の情報、使用目的、運転する人の範囲。こういう「項目が決まっている用件」は、一覧できるフォームで上から埋めていくのがいちばん速い。私たちが長年、紙の申込書でやってきたやり方です。
一方で、会話が本領を発揮するのは「何を聞けばいいか、自分でもまだ整理できていない用件」のときです。「こういう場合って保険おりるんでしたっけ?」みたいな、輪郭のぼんやりした相談。これはフォームでは受け止めようがなくて、対話で少しずつ形にしていくしかない。
つまり、用件には「会話が向くもの」と「一覧が向くもの」がある。 当たり前の話に聞こえますよね。でも、AIチャットが賢くなったいま、この当たり前が静かに無視され始めています。「賢い会話AIがあるなら、入口はそれ一本でいいじゃないか」と、フォームや電話の入口を畳んでしまう。窓口の省力化としては、気持ちは分かります。分かりますが、、、ユーザー側から見ると、5分の用件が30分の尋問に化けるのです。

5分の用件を5分で終わらせる地図 ― チャットボットのUX設計とは・会話設計の3局面
ここで一度、種明かしを挟ませてください。筆者があの夜に味わった消耗には、実はもう名前と設計の型が付いています。地図を先に広げておくと、このあとの話が、ただの愚痴ではなくなるはずです。
チャットボットのUX設計とは
チャットボットのUX設計とは、ユーザーが迷わず用件を果たせるように、ボットとの接点全体——画面の形、会話の流れ、言葉づかい、答えられないときの引き継ぎ——を設計することです。ボタンの色や吹き出しの見た目を整えるUIデザインより、範囲はずっと広い。そしてAIモデルの応答精度とは別のレイヤーの仕事です。精度がどれだけ高くても、UX設計が抜けたボットは使われません。
なぜ「作り方」だけでは使われないのか
チャットボットの構築手順やツール選定は、情報も道具も整ってきました(技術面の全体像はチャットボットの作り方が詳しいです)。ただ、作れることと使われることは別の問題です。UX設計を置き去りにしたボットは、解決率が上がらず、ユーザーは早々に電話や有人チャットに流れ、やがてボットは「本題の前に立ちはだかる壁」として認識されるようになります。
チャットボットのUIは3類型
| 類型 | 主な形 | 向いている場面 | 弱点 |
|---|---|---|---|
| 自由入力型 | 白紙の入力欄に平文で質問 | 輪郭の曖昧な相談・多様な用件 | 何を頼めるか伝わらない |
| 選択肢型(シナリオ型) | ボタンで分岐をたどる | 用件が定型で数が限られる場合 | 想定外の用件を受け止められない |
| ハイブリッド型 | 選択肢で絞り込み+最後に自由入力 | 実務の大半 | 分岐設計の手間がかかる |
実務で選ばれるのは多くの場合ハイブリッド型です。AIプロダクト全般のUI類型と設計原則は、AIのUI/UXデザインで扱っています。
会話設計とは|台本づくりとの違い
会話設計(カンバセーションデザイン)とは、ボットとユーザーのやりとりの流れ・言葉・分岐・例外処理をあらかじめ設計する仕事です。想定問答の台本を一字一句書き上げることではありません。局面ごとに「ここでは何を優先するか」の方針を決めることが本体です。
会話設計の3つの局面
| 局面 | 設計すること | 失敗すると起きること |
|---|---|---|
| 入口 | できること・できないことを会話の前に見せる | ユーザーが白紙の欄の前で固まる |
| 本筋 | 聞き返しで用件を絞り込む | 曖昧な質問に一般論が返り、堂々巡りになる |
| 行き止まり | 答えられないことを正直に伝え、人につなぐ | ごまかしの応答が続き、信頼が壊れる |
局面1|入口 ― できることを先に見せる
よくある用件のボタン、入力例、そして「私は◯◯のご案内ができます」という自己紹介。海外のユーザビリティ調査でも、人間のふりをせず、ボットであることと得意分野を最初に明かすボットのほうがユーザーに好まれると報告されています。入口の設計は、期待値の設計です。
局面2|本筋 ― 聞き返して絞り込む
ユーザーは一発で用件を言い当ててはくれません。調査でも、AIとの対話ではユーザーが何度も言い直しを重ねるのが常態だと観察されています。だから曖昧な質問には、答える前に一往復の聞き返しを挟む。あわせて、ユーザーの言葉と運営側の用語のズレ(「車をもう1台足したい」と「車両追加」)を、選択肢の提示で先回りして翻訳しておくことが効きます。
局面3|行き止まり ― 正直に言って、人につなぐ
どれだけ設計しても、答えられない質問は必ず来ます。AIがそれらしく答えてしまう危うさはハルシネーションの対策で扱われているとおりです。良い行き止まりの台詞には3つの部品が入ります。①何に答えられないかの明示、②代わりの窓口(電話・フォーム・有人チャット)の具体的な案内、③その窓口がいま使えるかどうか(営業時間・混雑)。
よくある失敗4パターン
| 失敗 | 現場で起きること |
|---|---|
| 1. 入口の絞り込み(チャネル強制) | フォームが速い用件まで会話に流し込まれ、手続きが尋問に化ける |
| 2. 一般論の返答 | 「ここでは」の答えを求める質問に、一般知識の正解が返る |
| 3. 聞き返しの欠如 | 曖昧な質問へ推測で長文回答し、外す |
| 4. 出口の欠如 | 「別の言葉でお試しください」の無限ループで、ユーザーが去る |
発注・リニューアル前のチェック項目
これからボットを発注する・作り直す立場なら、仕様書に最低限この4点を落とし込んでおくと、上の失敗をだいたい防げます。①受け持たせる用件の一覧と「会話向き/フォーム向き」の仕分け、②行き止まりのときの引き継ぎ先と台詞、③聞き返しの方針(何往復まで・どの粒度で確認するか)、④会話ログをあとから読める形にすること。
効果測定の指標
見るべき数字は派手なものではありません。自己解決率(ボット内で用件が済んだ割合)、離脱ポイント(どの発話でユーザーが去ったか)、有人への引き継ぎ率、同じ質問の再問い合わせ。絶対的な合格ラインは事業によって違うため、改善の傾向で見ます。数字の裏の「なぜ」を確かめる聞き方は、ユーザーインタビューの考え方が参考になります。
導入・改善の進め方5ステップ
①用件の棚卸しと仕分け(会話向き/フォーム向き)→②3局面の方針決定(入口・本筋・行き止まり)→③プロトタイプを実ユーザーに触ってもらう→④公開してログを観察する→⑤行き止まりのログから直す、の順です。画面全般の設計フローはアプリのUI/UXデザインに詳しくまとまっています。
つまずきどころ ― 「運用すれば良くなる」の落とし穴
「まず公開して、運用しながら育てます」という計画をよく見かけますが、ログから学べるのは、行き止まりが設計されているボットだけです。ごまかしの応答はログ上「回答済み」に見えるため、失敗が数字に出ません。道具を配るだけでは定着しないという構図は、生成AIで業務効率化する方法で書いた話と同じです。
——地図はここまでです。ここからは、筆者があの夜のあとに出会った、もう2つの実話にお付き合いください。
賢いのに、役に立たない ― 炭捨て場事件
もう一つ、筆者にはチャットボット絡みで忘れられない事件がありまして。
家族でキャンプに行ったときの話です。バーベキューを終えて、使い終わった炭をどう始末しようかと、キャンプ場の案内ページにあった問い合わせチャットに聞いてみました。「炭はどこに捨てられますか?」
返ってきた答えは、そのキャンプ場がある自治体の、家庭ごみとしての炭の出し方でした。燃えるごみか埋め立てか、収集日がどうか。丁寧に、行政区のごみ分別ルールを教えてくれる訳です。
いや、知りたいのはそれじゃない……。知りたいのは「このキャンプ場に炭捨て場はあるか。あるなら、どこか」です。 結局、答えは分からずじまいでした。
笑い話みたいですが、これ、チャットボットの失敗としてはかなり本質的だと思っています。おそらくボットは、キャンプ場の所在地を読み取って、その自治体の正しい処理方法を調べ、案内した。AIの動作としては、むしろ上出来です。間違ったことは何ひとつ言っていない。でも、このキャンプ場のチャットボットの挙動としては、間違っている。ユーザーの質問には、ほとんどの場合「ここでは」という見えない枕詞が付いている。このキャンプ場では。この契約では。うちの会社では。その「ここでは」に答えられないボットは、どれだけ物知りでも、その場所に置いておく意味がないのです。
一般知識の正解と、この場所の正解は、別物である。そして、手元の資料に炭捨て場の情報が無かったのなら、正解は一般論で埋めることではなく、「こちらでは分かりかねます。よくある質問か、お問い合わせフォームをご覧ください」と出口へ案内することだったはずです。答えられないと白状する設計のほうが、物知りに振る舞う設計より、その場所のボットとしては正しい。ボットを置く側は、自分たちのボットがどちらの挙動をしているのか、一度確かめてみる価値があります。

うまくいっていたボットの、地味な工夫
悪口ばかりというのもフェアではないので、逆に「お、これは楽だ」と感じたボットの話もさせてください。
どこかのサービスの問い合わせチャットでした。開くと、いきなり自由入力欄が出てくるのではなく、まず「よくあるご用件」がボタンで並んでいる。料金について、手続きについて、不具合について。ぽちっと押すと、また一段細かい選択肢が出る。2〜3回押すころには、用件はかなり絞り込まれていて、最後の最後に「詳しい状況をご記入ください」と平文の入力欄が現れる。
このスタイル、地味ですが、よくできていると思うのです。
まず、ボタンの並びを見た瞬間に「このボットに何を頼めるか」が分かる。次に、選択肢を押していくだけなので、こちらが保険用語や社内用語を知らなくても、向こうの語彙に乗っかって進める。そして、自由に書く場面は「最後のひと言」だけに絞られているから、白紙の欄を前に固まることもない。
とくに二つ目は、地味に見えて大きいと思っています。というのも、問い合わせで詰まる原因の多くは、ユーザー側と運営側で使っている言葉が違うことだからです。ユーザーは「車をもう1台足したい」と言い、運営側はそれを「車両追加(既契約の車両入替・増車)」と呼んでいる。この翻訳を、自由入力のボットはユーザーに押し付けます。「正しい用語で聞き直してくれたら分かるんですけど」という顔をしてくる。選択肢のボタンは、この翻訳を運営側が先回りして済ませておく仕組みなんです。
会話の自由さと、選択肢の道しるべ。二つのいいとこ取りです。全部を会話にする必要も、全部をボタンにする必要もなかった訳です。
会話設計という仕事 ― 台本ではなく、3つの局面
ここまでの3つの体験、実は同じ一つの話をしています。チャットボットの出来を分けるのは、AIモデルの賢さである前に、会話設計の出来だという話です。
会話設計というのは、ボットとユーザーのやりとりの流れ・言葉・分岐をあらかじめ設計する仕事のことです。台本を一字一句書くことではありません。筆者は、大きく3つの局面を設計することだと理解しています。
一つ目は、入口。何ができて、何ができないかを、会話が始まる前に見せておく局面です。さきほどの「よくあるご用件」ボタンがまさにこれです。海外のユーザビリティ調査でも、自分がボットであることと、できることの範囲を最初に明かすボットのほうがユーザーに好まれる、という報告があります。正体を隠して人間のふりをするより、「私はこれが得意な案内係です」と名乗ってしまうほうが、信頼されるのです。
二つ目は、本筋。用件を絞り込んでいく局面です。ここで大事なのは、ユーザーは一発で用件を言い当ててはくれない、という前提に立つことです。ユーザビリティの調査でも、AIとの対話ではユーザーが何度も言い直しを重ねるのが普通で、想定した一本道の流れから外れた途端にボットが立ち往生する、という観察が繰り返し報告されています。人間同士の会話なら「えっと、つまりこういうことですか?」と聞き返しながら進めますよね。ボットも同じで、曖昧な質問には曖昧なまま答えず、一往復の聞き返しを挟む。炭捨て場事件で欲しかったのは、まさにこの一往復でした。「場内の炭捨て場のご案内ですか? それとも一般的な炭の処分方法ですか?」——この確認が1行あるだけで、あのボットは満点だったのです。
三つ目は、行き止まり。答えられないときの局面です。そして白状しますと、筆者はここが会話設計でいちばん大事な場所だと思っています。ボットには必ず答えられない質問が来ます。そのときに、それらしい一般論でごまかすのか、「その内容はこのチャットではお答えできません。平日9時〜17時のこの窓口へどうぞ」と正直に言って人につなぐのか。保険のチャットで筆者が本当に欲しかったのは、賢い応答ではなく、この一言でした。
ちなみに、良い「行き止まりの台詞」には、だいたい3つの部品が入っています。①何にお答えできないかを正直に言う。②代わりの窓口(電話・フォーム・有人チャット)を具体的に示す。③その窓口が「いま」使えるかどうか(営業時間・混雑)まで添える。逆に悪い台詞は、「申し訳ありません。もう一度別の言葉でお試しください」だけを無限に繰り返すやつです。あれはユーザーに「出口はないぞ」と告げているのと同じでして、そっ閉じ一直線です。
会話がうまいボットより、引き際がきれいなボットのほうが、信頼される。 人間の窓口業務と、まったく同じなんだと思います。

明日、自社のボットを5分だけ診てみる
ここまで読んでくださったあなたの会社にも、問い合わせボットの一つや二つ、あるかもしれません。あるいはこれから、発注しようとしているところかもしれません。そこで、筆者がユーザーとしての恨みを込めて編み出した、5分でできる健康診断をお納めください。用意するものは、スマホ1台だけです。
まず、ボットを開いた最初の画面を見ます。何ができるか、見えますか。白紙の入力欄がぽつんとあるだけなら、初対面のユーザーはそこで固まっています。
次に、わざと曖昧に聞いてみます。「料金って変えられますか?」くらいの雑さで。聞き返してくれるか、それとも一般論を長々と返してくるか。ここで長文の一般論が来るボットは、炭捨て場事件を日常的に起こしています。
三つ目に、わざと答えられない質問をぶつけます。見たいのは正答率ではなく、行き止まりの台詞です。ごまかすのか、正直に言うのか。人間への出口(電話番号・窓口・営業時間)は提示されるのか。
最後に、そのボットが受けている用件を眺めて、こう問いかけてみてください。この中に、そもそもフォームのほうが速い用件を、無理やり会話に背負わせているものはないか——と。
4つ確かめるだけで、あなたの会社のボットが「賢いのに役に立たない」側にいるかどうかは、だいたい分かるはずです。直す順番も、たぶんこの逆順です。AIモデルを入れ替える前に、行き止まりの台詞を書き、聞き返しを一往復足し、入口にボタンを並べる。地味な順に、効きます。
作る側に回った自分への、宿題
ところで筆者は最近、AIと一緒にアプリを作る側の人間でもあります。つまり、いつ自分が「炭捨て場事件」の加害者になっても、おかしくない訳です。笑
なので、これは読者のみなさまへの提言であると同時に、自分への宿題でもあります。次に何かの問い合わせ機能を作るときは、賢い応答からではなく、行き止まりの台詞から書き始める。 「できません」を、いちばん丁寧に設計する。
会話できることと、頼れることは、違う。あの夜、スマホの前でため息をついていた筆者に言わせれば——ユーザーが覚えているのは、ボットが何に答えてくれたかではなく、答えられなかったときに、どうしてくれたかなのです。
チャットボットのUX設計のよくある質問
チャットボットのUX設計とは何ですか?
ユーザーが迷わず用件を果たせるように、ボットとの接点全体(画面・会話の流れ・言葉・答えられないときの引き継ぎ)を設計することです。AIモデルの応答精度とは別のレイヤーの仕事で、本文の保険チャットのように、精度が高くても設計が抜けていれば使われません。
チャットボットが使われない・嫌われる主な理由は何ですか?
大きく4つあります。何を頼めるか分からない(入口の失敗)、曖昧な質問に一般論が返る(本筋の失敗)、答えられないときにごまかす・出口がない(行き止まりの失敗)、そしてフォームのほうが速い用件まで会話に流し込まれていること(入口の絞り込み)です。多くはAIの性能ではなく会話設計で改善できます。
自由入力とボタン(選択肢)は、どちらが良いですか?
二択ではなく、組み合わせが実務的です。選択肢で用件を絞り込み、最後に自由入力で詳細を受け取るハイブリッド型が、初めてのユーザーの迷いと、運営側の用語とのズレの両方を減らします。本文で紹介した「よくあるご用件」ボタン→平文入力の順序が典型です。
チャットボットが答えられない質問には、どう対応させればよいですか?
ごまかさずに「答えられない」と明示し、代わりの窓口(電話・フォーム・有人チャット)と、その窓口がいま使えるか(営業時間)まで案内するのが基本です。筆者はこの「行き止まりの台詞」が会話設計でいちばん重要だと考えています。それらしい一般論で埋める設計は、信頼を静かに削ります。
ユーザーにプロンプトの書き方を覚えてもらうべきですか?
問い合わせボットでは、覚えてもらう前提にしないのが安全です。聞き方の工夫は本来運営側が選択肢や入力例で肩代わりできます。一方、社内の業務利用など習熟を前提にできる場面では、プロンプトエンジニアリングの手法を整備する価値があります。
既存のチャットボットを改善するには、何から始めればよいですか?
本文の「5分の健康診断」(入口の見え方・曖昧な質問への反応・行き止まりの台詞・用件の仕分け)で現状を確かめ、直す順番は行き止まり→聞き返し→入口が目安です。AIモデルの入れ替えは、その後で検討しても遅くありません。
この記事は、ARCHECOが運営するメディア「AI・新規事業戦略大学」でお届けしました。ARCHECOは、UI/UXデザインとプロダクト開発を強みに、お客さまと並走しながら「使われるもの」をつくっているチームです。ご相談・お問い合わせはこちらからどうぞ。