同じ質問に何度も答える現場をAIチャットで支える

「その質問、今週だけで8回目です」という現場

問い合わせ対応の負担が大きい現場は、たとえばこんな状態です。カスタマーサポートの担当者が3人。午前中の電話とメールが一段落する頃には昼を過ぎていて、その内容を見ると「営業時間は何時までか」「返品はどうすればいいか」「ログインできない」といった、答えが決まっている問い合わせが半分以上を占めている。責任者としては、繁忙期に増える件数を人員で吸収しきれず、かといって新規採用の余裕もない。定型的な質問に人の時間が削られ、本当に丁寧に対応すべき込み入った相談が後回しになる——この構造が、多くの現場で起きています。

中小企業庁の中小企業白書でも、人手不足を経営課題として挙げる中小企業は高い水準で推移していることが示されています。人を増やすことで対応量を伸ばす前提そのものが、多くの企業で成り立ちにくくなっている。だからこそ、決まった答えを返す部分を仕組みに任せ、人は判断が必要な問い合わせに集中する、という発想が現実味を帯びてきます。問い合わせのチャットボットにAIを組み合わせる話は、この文脈で検討する価値があります。

AIチャットは「全部答える箱」ではない

最初に誤解を解いておきたいのは、AIチャットボットを入れれば問い合わせ対応が丸ごと自動化される、という期待です。これは実態と合いません。

顧客対応の問い合わせは、大きく三つに分かれます。答えが一意に決まる定型質問、状況によって答えが変わる準定型の質問、そして個別の事情を汲んで判断が要る相談です。AIチャットが力を発揮するのは主に一つ目、そして条件を絞り込めば二つ目の一部です。三つ目まで任せようとすると、間違った案内を自信たっぷりに返してしまい、かえって信頼を損ないます。

問い合わせの種類	例	AIチャットの向き	人の関与
定型（答えが一意）	営業時間、送料、返品手順	向いている	ほぼ不要
準定型（条件で変わる）	「この商品は〇〇に使えるか」	条件整理まで	最終確認を人が
個別判断	クレーム、契約の例外対応	向かない	人が対応

この切り分けをせずに導入すると、後述する「現場が使わない」問題に直結します。まず自社の問い合わせログを1〜2週間分見て、この三分類でどのくらいの比率かを数えるところから設計が始まります。

動かせる粒度で導入手順を書く

抽象的に「AIを活用する」で終わらせず、実際に何を入力し何が出て誰が確認するかまで書きます。

過去の問い合わせを集める。メール、電話メモ、チャット履歴から直近1〜2ヶ月分を集め、質問文と回答をセットで一覧にします。ここが素材です。個人情報は削除しておきます。
上位の質問を抽出する。件数の多い順に並べ、上位20〜30項目を選びます。問い合わせの多くは一部の質問に集中しているため、この上位だけで相当数をカバーできます。
想定問答（FAQ）を確定する。各質問に対する正式な回答を、責任者が文章として確定します。ここは人が決める工程で、AIに作らせた下書きをそのまま使ってはいけません。
AIチャットに読ませる形にする。確定したFAQを、チャットボットが参照する知識として登録します。近年のツールは、この登録済み文書の範囲内で回答を組み立てる設定ができるものが多く、勝手な推測を抑えられます。
社内でテスト会話を回す。担当者が実際の顧客になったつもりで質問し、返答が正確か、答えられない質問で暴走せず「担当者におつなぎします」と引き渡せるかを確認します。
有人への切り替え導線を必ず作る。AIが答えきれない場合に、人へバトンタッチする経路を用意します。ここが欠けると、顧客が袋小路に入ります。
一部の窓口で先行公開し、ログを見る。全面公開の前に限定範囲で動かし、実際の会話ログを毎日確認します。誤答があればFAQを直す。この修正の反復が精度を作ります。

手順の要は3と6です。回答内容を人が確定すること、そして人への逃げ道を用意すること。この二つを飛ばした導入は、ほぼ確実に不信を生みます。

精度が出ない・現場が使わないとき、どこを疑うか

導入したのに期待した効果が出ない、ということも起こります。原因はだいたい絞り込めます。

一つ目は、知識のもとが整っていないケース。FAQが古い、表現が曖昧、社内でも回答が人によって違う。この状態のままAIに読ませても、出てくる答えは元の曖昧さをそのまま反映します。精度の問題に見えて、実は元データの問題であることが多い。まず人間が読んで迷わない回答文になっているかを疑います。

二つ目は、質問の言い回しの幅を想定していないケース。顧客は「返品」を「返す」「キャンセル」「交換」など様々な言葉で尋ねます。登録した質問文が一通りだと、少し違う聞き方で拾えなくなる。実際のログを見て、拾えなかった質問を追加していく作業が要ります。

三つ目は、現場の担当者が使わないケース。これは顧客ではなく社内の話です。有人対応との切り替えが面倒だったり、AIの誤答のフォローが担当者の負担になっていたりすると、担当者は「結局自分で答えたほうが早い」と判断してチャットを避けます。導入時に、担当者にとってどこが楽になるのかを具体的に設計しないと、確認の手間だけが増えます。効果を測るときは、削減できた件数だけでなく、担当者の手間が実際に減ったかを本人に確認するのが確実です。

手を出さないほうがよい範囲

AIチャットに任せるべきでない領域があります。クレーム対応と、契約・料金の例外的な判断です。

クレームは、顧客がすでに感情的になっている場面が多く、定型的な返答はかえって火に油を注ぎます。ここは謝意と傾聴が要り、AIの守備範囲を外れます。料金や契約の例外対応も同様で、「特別に対応してほしい」という相談に機械が線引きすると、後で人が覆せずトラブルになります。

これらは技術的に不可能だからではなく、間違えたときの損失が大きすぎるから外す、という線引きです。AIチャットの入口で「この内容は担当者が承ります」と早めに人へ渡す設計にしておくほうが、結果的に顧客満足を守れます。守備範囲を欲張らないことが、この仕組みを長く使えるかどうかを分けます。

内製で始めるか、外部に頼むかの分かれ目

判断の分かれ目は、社内にログを整理し回答を確定できる人がいるかどうかです。

FAQの上位項目が明確で、回答も社内で決まっていて、ツールの設定を試せる担当者が一人でもいるなら、まずは内製で小さく始められます。市販のチャットボットツールには、文書を読ませて回答させる機能を備えたものが増えており、限定範囲であれば専門家なしでも試せます。

一方で、問い合わせの種類が多岐にわたる、回答が部署ごとにばらついていて統一に調整が要る、あるいは基幹システムと連携して顧客ごとの情報を返したい——こうした要件が入ると、設計と運用の難度が上がります。この場合は、進め方の設計と初期のログ検証だけでも外部の力を借りたほうが、遠回りを避けられます。外部に頼むかどうかは「作れるか」ではなく「回答内容の整理と修正の反復を、社内で続けられるか」で判断すると外しません。

効果を決めるのは公開後の修正の量

AIチャットの導入で成否を分けるのは、ツールの性能でも初期の完成度でもありません。公開したあとに、答えられなかった質問を拾ってFAQを直し続ける、その反復の量です。

導入時点のFAQは、どれだけ丁寧に作っても実際の顧客の聞き方の全部はカバーできません。公開して初めて、想定していなかった質問と言い回しが見えてきます。それを毎日のログから拾い、回答を足し、外すべき範囲を外す。この地道な運用を数週間続けたチャットは、定型質問の入口として機能します。逆に、作って放置したチャットは、少し外れた質問で沈黙し、顧客を有人窓口に押し戻すだけの飾りになります。

先に手順の3と6を要と書いたのは、この修正の反復を回すための土台だからです。人が回答を確定していれば直す基準が明確になり、人への切り替え導線があれば誤答が顧客に届く前に止まる。この二つが揃った状態で運用の反復を回せるかどうかが、問い合わせ対応をAIで支えられるかの実際の分岐点です。