「チャットボットを導入したのに、思ったほど答えられていない」──導入後、最初にぶつかる壁はほぼこれです。そして多くの現場で、次の一手が「AI がもっと賢くなるのを待つ」か「もっと高性能な製品への乗り換え検討」になってしまいます。どちらも、レバーの位置を間違えています。チャットボットの回答精度を上げる主戦場は、AI のチューニングではなく、ナレッジと運用です。答えられなかった質問を記録し、原因で分類し、ナレッジを直し、直ったことを確かめて、この一連を回し続ける──精度改善の正体は、この地道な業務プロセスです。逆に言えば、AI の専門知識がなくても、自社の業務を知っている担当者が今日から着手できます。この記事では、その手順を 5 つのステップに分けて、記録の取り方から運用サイクルへの固定までを具体的に解説します。
- 導入直後の回答精度は AI の性能ではなく渡したナレッジ(資料)の質と量で決まる ── 初日に低いのは異常ではなく出発点
- 精度改善の手順は 5 ステップ ── 記録する → 分類する → 直す → 確かめる → 回し続ける
- 答えられなかった質問の原因は 「資料にない / 資料が古い / あるが見つけられない / そもそも任せない領域」の 4 つに分かれ、打ち手がそれぞれ違う
- 合格ラインは「全問正答」ではなく「先月より答えられる範囲が広い」 ── 答えられない質問はゼロにならない前提で、受け皿とセットで設計する
なぜ導入直後のチャットボットは「思ったほど答えられない」のか
まず、期待とのギャップがなぜ生まれるのかを構造で押さえておきます。ここが腹落ちしていないと、改善の努力が「AI への失望」に化けてしまうからです。生成 AI 型のチャットボットは、マニュアル・規定・対応ログといった知識源の資料をもとに回答を組み立てます。つまり、資料に書いていないことは答えられず、資料が古ければ古い答えを返します。導入直後の精度は AI の性能ではなく、その時点で渡せた資料の質と量の写し絵です。この仕組みの技術的な背景は「社内ナレッジをAIに回答させる仕組み(RAG入門)」で解説しているとおりで、どの方式を選んでも「知識源への依存」という性質からは逃れられません。
もう 1 つのギャップの源は、想定した質問と、実際に来る質問のズレです。導入前に社内で用意する想定問答は、どうしても「社内の言葉」で書かれます。ところが実際のお客様は「解約したい」ではなく「もう使わないんですけどお金かかりますか」と書きます。社内マニュアルはそもそも業務手順を記述するための文書であって、お客様の質問に答えるために書かれていません。この 2 つのズレ──資料の穴と、言葉のズレ──は、導入前にどれだけ準備しても完全には潰せません。実際の質問が入ってきて初めて、どこを直せばいいかが見えるのです。だから導入直後に答えられない質問が出るのは、設計ミスではなく、改善の材料が手に入り始めた状態だと捉えてください。ここからが本番です。
精度改善の考え方 ── 直すのは AI ではなく、ナレッジと運用
「精度を上げる」と聞くと、AI モデルの調整やパラメータの変更といった専門作業を想像しがちですが、実務で動かせるレバーは 3 つで、いずれも AI の専門知識を必要としません。①ナレッジの中身(資料の追加・更新・書き方)──効果がもっとも大きい主レバーです。②答えられないときの受け皿(有人への切り替え・フォームへの誘導)──精度そのものではなく、精度が届かない領域の体験を守るレバーです。③運用サイクル(誰が・いつ・何を見るか)──①と②を継続させ、精度を「上がり続ける」状態にするレバーです。この記事の 5 ステップは、この 3 つのレバーを手順に落としたものです。
着手の前に、「精度が低い」という言葉を一段だけ分解しておくと、後の作業が楽になります。現場で「答えられていない」と呼ばれる現象は、実際には 未回答(答えを持っていないと返す)、誤答(違う答えや古い答えを返す)、ミスマッチ(答えは資料にあるのに探し当てられない)の 3 種類が混ざっています。どれが多いかで直す場所が変わるため、まとめて「精度が低い」と括ったままでは打ち手が定まりません。なお、チャットボットの精度改善はサポート自動化全体の一部です。どの業務領域から自動化に着手するかという全体像は「カスタマーサポートの自動化はどこから始めるか ── 4つの領域と進め方」で整理していますので、位置づけを確認したい方はあわせてご覧ください。
精度改善の 5 ステップ
ここから、冒頭のロードマップに沿って各ステップの実務を具体化します。特別なツールは前提にしません。会話ログが見られる環境なら、スプレッドシート 1 枚で回り始めます。
ステップ 1: 答えられなかった質問を記録する
改善の原料は「答えられなかった質問」です。まず、これを取りこぼさず記録する仕組みを作ります。拾う対象は 3 種類あります。
- ①ボットが答えを持っていなかった質問 ── 「わかりませんでした」系の応答で終わった会話。多くの製品で会話ログから抽出できます。
- ②答えたが、解決しなかった質問 ── 回答の直後に有人へ切り替わった、フォームや電話に流れた、と推測できる会話。誤答・ミスマッチはここに潜みます。
- ③会話が途中で切れた質問 ── 回答の途中でお客様が離脱した会話。回答が長すぎる・的外れ、のサインであることが多い箇所です。
会話ログの機能が弱い製品を使っている場合でも、代替手段はあります。電話やメールで受けた問い合わせに「チャットボットで解決しなかった用件か」を 1 項目足して記録してもらうだけで、②の実態はかなり掴めます。電話側の問い合わせ記録の取り方・集計の仕方は「入電数を分析して削減につなげる5ステップ」で詳しく解説しており、同じ物差しで揃えるとボット経由と電話経由を横並びで見られるようになります。
ステップ 2: 原因を 4 つに分類する
集めた質問を、1 件ずつ「なぜ答えられなかったのか」で分類します。原因は、実務上ほぼ次の 4 つに収まります。
| 分類 | 状態 | 見分け方 | 打ち手 |
|---|---|---|---|
| A. 資料にない | 答えの根拠がナレッジに存在しない | 資料を検索しても該当箇所がない | ナレッジを追加する |
| B. 資料が古い | 根拠はあるが内容が現状と違う | 回答は返るが中身が誤り・旧情報 | ナレッジを更新する |
| C. あるが見つけられない | 根拠はあるのに回答に使われない | 人が探せば資料に書いてある | 書き方・構造を直す |
| D. 任せない領域 | 個別の契約照会・クレームなど | 正しい答えが「人が対応する」になる | 受け皿(導線)を直す |
この分類の効能は、直す場所が 1 件ごとに確定することです。A と B はナレッジの中身の仕事、C は書き方の仕事、そして D はそもそも精度の仕事ではありません。D に該当する質問──たとえば個別の契約内容の照会や、感情的な対応が必要なクレーム──は、どれだけナレッジを足しても解決せず、答えるべきでもありません。ここで必要なのは、有人チャットやフォームへ迷わずつながる導線です。D を精度の問題として数えないことが、改善を挫折させないコツでもあります。分類は週に 1 回、直近のログをまとめて 30 分で付ける程度で十分です。
ステップ 3: ナレッジを直す ── 追加・更新・書き換え
分類ができたら、件数の多い順に直します。ここで大事なのは、量ではなく的です。問い合わせは少数の用件に集中する性質があるので、上位の数件を直すだけで体感は大きく変わります。直し方は分類に対応して、A は追加、B は更新、C は書き換え(または構造の整理)です。追加・書き換えの際は、次の 3 点を意識すると AI が答えに使いやすいナレッジになります。
- ①お客様の言葉で書く ── 見出しや冒頭に、社内用語ではなく実際の質問に出てきた言い回しを入れます。「解約手続き」だけでなく「利用をやめたい場合」も並記する、といった具合です。ステップ 1 の記録が、そのまま言い回しの辞書になります。
- ②1 トピック 1 まとまりで書く ── 複数の話題が 1 つの長文に混ざっていると、必要な部分だけを取り出しにくくなります。「料金」「解約」「営業時間」のように、トピックごとに区切って書きます。
- ③結論から書く ── 手順や条件の前に、まず答えを置きます。人にとって読みやすい構成は、AI にとっても引用しやすい構成です。
逆に、避けたいのは「答えられなかったから」と関連しそうな資料を丸ごと投げ込むことです。ナレッジの総量が増えるほど、似た記述が衝突して C(あるが見つけられない)を誘発することがあります。足すのは、答えられなかった質問に対応する分だけ──これが原則です。
ステップ 4: 直ったことを、同じ質問で確かめる
ナレッジを直したら、必ず「答えられなかった実際の質問」をそのままぶつけて、今度は答えられることを確認します。ここで役立つのが、ステップ 1 の記録をテスト質問セットに昇格させる方法です。答えられなかった質問のうち代表的なもの 10〜20 問を一覧にしておき、ナレッジを直すたびに流します。このとき、元から答えられていた代表質問も数問混ぜてください。ナレッジの追加や書き換えが、これまで正しく答えられていた質問に影響していないか──いわば「直したら別の場所が壊れていないか」の確認です。テスト質問セットは一度作れば使い回せて、月ごとの「答えられる範囲の広がり」を測る物差しにもなります。
ステップ 5: 週次・月次の運用サイクルに固定する
ステップ 1〜4 を 1 回やって終わりにせず、定例の業務に固定します。目安として、週次 30 分でログの確認と分類(ステップ 1〜2)、月次 1〜2 時間でナレッジの修正・検証と傾向の振り返り(ステップ 3〜4)という頻度が、無理なく回る出発点です。あわせて 2 つだけ決めてください。1 つは担当者の名前です。「みんなで見る」は「誰も見ない」と同じ結果になります。もう 1 つは見る数字で、未回答・解決しなかった会話の割合と、同じ質問の再発の有無、の 2 つで十分です。数字は精度そのものより「サイクルが回っているか」を映す計器として使います。商品・料金・規定が変わったときにナレッジも同時に更新する、という業務フローへの組み込みまでできれば、精度は「上げるもの」から「上がり続けるもの」に変わります。
精度改善でやりがちな 3 つの間違い
最後に、この運用を続けてきた立場から、挫折の原因になりやすい 3 つの間違いを挙げておきます。いずれも善意と真面目さから起きるものです。
どれだけナレッジを整えても、答えられない質問は必ず残ります。新しい質問は次々に生まれ、D 領域(任せるべきでない質問)もなくなりません。全問正答を基準にすると、改善しているのに「まだダメだ」という評価が続き、取り組み自体が萎みます。合格ラインは「先月より答えられる範囲が広い」に置き、答えられない質問は受け皿の設計で守る──この二段構えが健全です。
「知識が多いほど賢くなるはず」と、社内の資料を手当たり次第に追加していくと、重複や矛盾した記述が増え、かえって的確な回答を妨げることがあります。ナレッジは蔵書量を競うものではなく、問い合わせに対応する範囲を、最新の状態で保つものです。足すのは答えられなかった質問に対応する分だけ・古くなったら直すか消す、を守ってください。
精度改善は 1 回の作業ではなく反復です。担当者の名前と、週次 30 分の枠を決めずに始めると、導入直後の熱があるうちは回り、数ヶ月で止まります。止まった瞬間から、ナレッジと現実の差は開き始めます。逆に、小さくても止まらない仕組みにしておけば、精度は放っておいても上がり続けます。体制まで含めて「導入」だと考えてください。
なお、問い合わせ削減の打ち手はチャットボットの精度改善だけではありません。FAQ の整備や導線の見直しなど、全体の選択肢と組み合わせ方は「コールセンターの問い合わせを削減する方法【完全ガイド】」で体系的に整理しています。精度改善で得た「よく聞かれる質問」の記録は、そのまま他の打ち手の材料にもなります。
コルットの場合 ── 「育てる運用」を当社が代行する設計
最後に、当社の AI チャットボット「コルット」が、この記事の 5 ステップをどう扱っているかを紹介します。コルットは HP にタグ 1 行で設置する記述式(自由入力)のチャットボットで、マニュアル・規定・対応ログなどの社内資料を知識源にするため、一問一答 FAQ の作り込みは不要です。どの問い合わせがコール数を増やしているかを可視化・分析する機能を備えており、本記事のステップ 1〜2(記録と分類)にあたる材料が運用の中で手に入ります。そして標準プランでは、ナレッジの整備・更新の代行と月次の改善提案まで含めており、ステップ 3〜5 の「育てる運用」を自社で抱え込まずに回せる設計です。まずは 2 ヶ月の無料モニターで、自社の実際の問い合わせにどこまで答えられるか・どう育っていくかを、費用をかけずに確かめられます。
「コルット」はお手元のマニュアルや対応ログをもとに当社がナレッジを整備し、導入後の更新・改善提案まで伴走します。答えられなかった質問がどう減っていくかを、実データでご確認ください。
コルットを無料で試してみる →よくある質問
問い合わせは少数の用件に集中するため、件数の多い質問から直せば、サイクルの 1〜2 巡目(週次運用なら数週間)で「前は答えられなかった質問に答えている」場面を確認できます。ただし体感の早さは、ログの量と直す的の絞り方に依存します。効果を確かめる物差しとして、ステップ 4 のテスト質問セットを最初に作っておくことをおすすめします。
必要ありません。5 ステップの作業の中心は、ログを読む・原因を分類する・資料を直すという業務知識の仕事で、AI モデルに触れる工程はありません。むしろ、自社の問い合わせとお客様の言葉を知っている人が適任です。技術的な仕組みを把握しておきたい場合は、RAG 入門の記事で概要を掴んでおくと、ベンダーとの会話がスムーズになります。
ゼロにはなりません。新しい質問は常に生まれ、個別の契約照会やクレームのように、そもそも AI に任せるべきでない領域も残ります。目指すのはゼロではなく、「答えられる範囲が広がり続けている」状態と、答えられないときに有人対応やフォームへ迷わずつながる受け皿の 2 つです。この 2 つが揃っていれば、答えられない質問が残っていても、お客様の体験は損なわれません。
電話・メールで受けている問い合わせの記録が、ログの代わりになります。実際に多い用件の上位からナレッジを整え、テスト質問セットも実際の問い合わせの言い回しから作れば、ボットのログが貯まる前から同じサイクルを回せます。また導入前・検討中の段階であれば、無料トライアルの期間に本記事のステップ 1〜4 を小さく回してみると、製品の善し悪しと運用の負荷を同時に確かめられます。