問い合わせ対応をAIに任せる｜嘘をつかせないための設計

問い合わせ対応をAIに任せたい。そう考えて情報を集めると、出てくるのは「何％を自動化できた」「対応時間が何割減った」という成功の数字ばかりです。しかし実際に運用を始めて最初にぶつかるのは、効率の話ではありません。AIが、こちらが一度も決めていない条件を、決まったことのように答えてしまう問題です。

この記事では、海外からの問い合わせ対応をAIで自動化している運営の中で実際に起きた事故と、そこから作った線引きを書きます。ツールの比較や「おすすめ○選」は扱いません。導入した後に必ず来る、AIに嘘をつかせないための設計の話です。生成AIで業務のどこが何分減るかという全体像は生成AIで業務効率化した企業事例｜何分減ったかを業務別に解説にまとめています。

結論｜AIに任せてはいけない質問を、先に決める

先に結論を書きます。問い合わせ対応をAIに任せるとき、最初にやるべきなのは「何を自動化するか」ではなく「何を絶対に自動化しないか」を決めることです。

• お金・契約・安全に関わる質問で、手元の資料に書いていない数値や条件は、AIに答えさせない
• 答えられない質問は、無理に答えさせず人に回す経路を先に作る
• この線引きは、精度を上げれば不要になるものではない。設計として最初から持つ

順番が逆になると、事故が起きてから線を引くことになります。実際にそうなった話を書きます。

実際に起きたこと｜AIが存在しない規約を作って顧客に答えた

海外の顧客からの問い合わせに、AIが自動で応答する運用をしていたときのことです。顧客からキャンセルの条件を尋ねられたAIが、「7日以上前なら全額返金、3〜6日前は50%、1〜2日前は25%、当日は返金なし」という趣旨の規約を、そのまま回答として返しました。

問題は、この規約が実在しなかったことです。そういう決まりを作った事実はありません。AIが、業界でよくありそうな条件を組み立てて、確定事項のように答えていました。

気づいてから、過去のやり取りを全部さかのぼって調べました。同じように資料に書いていない数値を推測して答えていた回答が、16件見つかりました。料金の目安を「〜円から」と勝手に答えていたものも含まれます。幸い大きなトラブルには至りませんでしたが、返金や料金の話である以上、相手が信じて行動していたら金銭の争いになる種類の間違いでした。

なぜ起きるのか｜AIは「答えなければ」と考えてしまう

この事故は、AIの性能が低かったから起きたのではありません。むしろ逆です。質問に対して自然な文章を返す能力が高いほど、「わかりません」と答えるより、それらしい答えを作るほうに寄ります。

人間の担当者なら、キャンセル規約を聞かれて資料に載っていなければ「確認してご連絡します」と言います。ここで止まれるのは、間違った条件を伝えたときに何が起きるかを知っているからです。AIはその重さを知りません。「顧客が困っている」「答えを返すのが仕事だ」という方向にだけ働きます。

だから、「間違えたときに損害が出る領域」を人間側があらかじめ指定して、そこだけは答えさせないという形にする必要があります。AIに判断を任せる話ではなく、判断させない範囲を決める話です。

推測させない領域の決め方｜お金・契約・安全の3系統

事故のあと、最優先のルールとして次の形を置きました。この一文が、他のどのルールよりも優先されます。

お金・規約・補償・キャンセル・保険・年齢や資格の条件・安全に関わる項目で、手元の資料に明記されていない数値や条件は、絶対に推測せず人に回す

自社に置き換えるときは、次の3系統で考えると線を引きやすくなります。

1. お金の系統｜価格、割引、追加料金、返金、支払い条件。「だいたいこのくらい」と答えさせない
2. 契約の系統｜キャンセル条件、納期、保証の範囲、責任の所在。後から「そう言われた」と言われる領域
3. 安全・資格の系統｜利用条件、年齢や資格の制限、健康上の注意。間違えると人が傷つく領域

逆に言えば、この3系統の外側は、多少間違えても謝って直せます。営業時間、場所の説明、手続きの流れ、よくある質問への一次回答。ここはAIに任せて構いませんし、間違いを恐れて全部人力に戻すと自動化の意味がなくなります。「どこで間違えても許されるか」を決めることが、そのまま「どこを任せられるか」の答えになります。

ここまでを自社の業務に当てはめる作業は、社外の人間と一緒にやったほうが速く終わります。30分・無料・オンライン可の個別相談では、御社の問い合わせのうち3つを持ってきていただければ、「AIに任せてよい／人が持つべき」に仕分けしてお返しします。売り込みはしません。

AIが止まった日｜あえて代替の応答を作らなかった

もうひとつ、運用していると必ず来る場面があります。AIのサービス側が混雑して、応答が返らなくなる日です。実際に、外部のAIサービスが過負荷になり、こちらの自動応答が軒並み反応しなくなったことがあります。

このとき普通に考えつくのは、「ただいま混み合っております。後ほどご連絡します」のような代替の自動応答を用意しておくことです。しかし、これは作らないと決めました。

• 顧客から見ると「このシステムは壊れている」という印象だけが残る。信頼の損失のほうが大きい
• 代替応答を返した直後に人間が正規の返信をすると、同じ相手に二重に返信することになり会話が破綻する
• 答えられないときに担当者へ通知が飛ぶ経路が動いていれば、人が対応すればいい

実際、止まっている間の問い合わせは通知経由で人が拾いました。「AIが止まったら人に戻る」だけの設計のほうが、中途半端に何か返すより顧客体験が良いという判断です。復旧は通常数十分で終わります。

ここで言いたいのは、障害対策として何もするなということではありません。「不具合が起きたときに、AIに何をさせないか」も設計に含めるということです。止まったときの振る舞いを決めていないと、現場が慌てて場当たりの応答を足し、あとで会話が壊れます。

「人に回す」を設計に組み込む｜線を引くだけでは足りない

「答えさせない」と決めても、そこで会話が止まっては顧客が困ります。答えない代わりに、必ず人へ渡る道を先に作っておく必要があります。

• 渡し先を決める｜誰の、どの画面に通知が来るのか。全員宛は誰も見ないのと同じです
• 渡す条件を決める｜上の3系統に触れたとき、何度か聞き返しても意図が取れないとき
• 渡したあとの文面を決める｜顧客側には「担当者が確認してご連絡します」と伝わる形にする
• 渡った件数を見る｜多すぎるなら線が厳しすぎ、ゼロが続くなら線が機能していない可能性があります

渡された件数を後から眺めると、「本当は答えられたはずなのに人に来ている質問」が見えてきます。そこはAI側の守備範囲を広げれば減ります。逆に、お金や契約の質問がきちんと人に来ているなら、線は正しく効いています。

それでも自動化する価値はどこにあるか

ここまで事故の話を続けましたが、だから自動化をやめるべきだ、とは考えていません。実際に運用を続けています。

問い合わせの多くは、営業時間、場所、手続きの流れ、既に案内済みの内容の確認です。この層に24時間ですぐ一次回答が返るようになると、担当者が本当に判断すべき問い合わせに時間を使えるようになります。特に相手と時差がある場合、翌朝まで待たせないだけで話が前に進みます。

価値が出るのは、「全部任せる」ではなく「任せる範囲を決めて任せる」という形にできたときです。線を引かないまま入れると、最初の数週間は快適で、そのあとに冒頭のような事故が来ます。順番を逆にしないでください。

「どこまで任せるか」を最初の一歩でどう決めるかは、AIエージェントとは？中小企業が最初に任せる仕事を「戻せるか」で選ぶで任せる仕事の選び方から解説しています。

よくある質問

AIの精度を上げれば、推測して答える問題はなくなりますか？

減らせますが、ゼロにはできないという前提で設計してください。文章を作る仕組みである以上、資料にない部分を埋めようとする動きは残ります。精度で解く問題ではなく、「答えさせない範囲を決める」で解く問題だと考えたほうが安全です。

どのくらいの規模の会社から意味がありますか？

問い合わせが1日に数件でも、内容が繰り返しなら効果はあります。判断の目安は件数より「同じ説明を何度も書いているか」です。逆に、毎回内容が違って個別判断が要る問い合わせばかりなら、自動化の効果は小さくなります。

最初から完璧なルールを作る必要がありますか？

いいえ。お金・契約・安全の3系統だけ先に決めて、残りは運用しながら足していくのが現実的です。この3つを最初に押さえておけば、他の間違いは謝って直せる範囲に収まります。

まとめ

• 問い合わせ対応をAIに任せるとき、先に決めるのは「何を自動化しないか」
• 実際に、AIが存在しないキャンセル規約を作って顧客に回答した。過去ログを調べたら同種の推測回答が16件あった
• 線を引くのはお金・契約・安全の3系統。ここは資料に書いていなければ答えさせず、人に回す
• この3系統の外側は間違えても謝って直せるので、任せてよい
• AIが止まったときの代替応答はあえて作らない。中途半端に返すより、人に戻すほうが顧客体験が良い
• 「答えさせない」と決めたら、必ず人へ渡る道を同時に作る

自社の問い合わせのどこまでを任せられるかは、実際の問い合わせを3つ見れば大枠が決まります。30分・無料・オンライン可の個別相談で、「AIに任せてよい／人が持つべき」の仕分けまでを一緒にやります。