チャットボット運用の5つの課題とは？KPI設定と改善の進め方

• 業務効率化
• チャットボット
• 運用
• KPI
• 問い合わせ対応

2026/08/21

• シェア
• Tweet

「導入したのに、問い合わせが減った実感がない」「ログを見ようと思ったまま、3か月経ってしまった」。チャットボットの立て直し相談で最も多いのが、この2つです。

チャットボットは設置した時点では半分しか終わっておらず、成果は導入後の調整でほぼ決まります。そして運用が止まる原因は、担当者の意識ではなく「作業が大きすぎること」にあります。本記事では、運用でつまずく5つの課題と見るべきKPI、会話ログをもとにした改善サイクルの回し方、そして専任担当を置けない場合の最小体制まで解説します。

5つの課題とKPIの一覧は前半に、電話へあふれた問い合わせの扱いは後半にまとめています。急ぐ方は目次からお進みください。

• お問い合わせ
• 資料請求

・チャットボットは導入後が本番になる理由

　・目的が曖昧なまま導入していないか

・チャットボット運用でよくある5つの課題

・運用で見るべき6つのKPI

　・回答率と解決率の違い

　・KGIは何に置くべきか

・改善サイクルの回し方

　・会話ログはどこを見るのか？

　・シナリオは深くしすぎない

　・更新の頻度を決める

・運用体制はどう組めばよいか？

　・専任を置けない場合の最小構成

　・承認フローは軽くする

　・運用代行を使うべきか？

・有人チャットとどう組み合わせるか？

・生成AI型チャットボットの運用で変わる点

・解決できなかった問い合わせはどこへ行くのか？

　・電話のログはFAQ改善の一次データになる

・よくある質問

・まとめ

理由は、利用者の質問が想定どおりに来ないからです。導入前に用意するFAQは、担当者が「聞かれるだろう」と考えた質問で構成されます。実際に運用を始めると、想定していなかった言い回しや、複数の要件が混ざった質問が届きます。

このずれは、ログを見なければ気づけません。回答できなかった質問はエラーとして記録されるだけで、担当者に通知されるわけではないためです。放置すると、利用者は「聞いても答えが返ってこない」と学習し、二度と使わなくなります。

そしてチャットボットは、使われなくなっても止まりません。設置されたまま数字だけが静かに落ちていくため、失敗が表面化しにくい仕組みでもあります。導入から3か月経っても誰も数字を見ていないなら、その時点で運用は始まっていないと考えたほうが正確です。

立て直しの相談を受けると、そもそも何を減らすために導入したのかが決まっていないケースが目立ちます。「問い合わせ対応の効率化」は目的ではなく状態の説明で、これでは成果を判定できません。

決めるべきは、どの問い合わせを、どれだけ減らしたいかです。「営業時間外の配送状況の問い合わせを、電話で受けずに済むようにする」まで具体化すると、載せるFAQも、置く場所も、測る数字も自動的に決まります。

導入済みでも、目的は決め直せます。直近1か月の問い合わせを種類別に集計し、件数の多い上位3つのうちチャットボットで完結しうるものを選んでください。そこに絞って改善すれば、少ない工数でも変化が数字に出ます。全体を良くしようとすると、どこから手をつけるかで議論が止まります。

対象を絞る作業には、もう一つ利点があります。「これは対象外」と決めた用件が明確になるため、対応範囲を利用者に案内できるようになります。範囲を示さないチャットボットは、答えられない質問を集め続けることになります。

相談の内容は多岐にわたりますが、構造としては5つに収束します。

効果測定ができない最大の原因は、導入前の数字を記録していないことです。問い合わせ件数、電話の入電数、メールの受信数を導入前に押さえていなければ、減ったかどうかを示せません。

すでに導入済みで比較対象がない場合でも、打つ手はあります。チャットボットで解決した件数を数え、それが人の対応に回っていたらどれだけの工数だったかを換算する方法です。厳密さは落ちますが、社内で効果を説明する材料にはなります。

使われていない

起動数が少ない場合、原因はチャットボットの中身ではなく設置場所にあります。フッターの隅に小さく置かれていれば、そもそも気づかれません。

設置場所は「迷いが生まれる地点」に置く

改善は導線から着手してください。問い合わせフォームの手前、よくある質問ページ、料金ページなど、迷いが生まれる場所に置くと起動数は変わります。あわせて、最初に表示する文言も見直す価値があります。「ご質問はありますか」より、「配送状況の確認はこちら」のように具体的な用件を出すほうが押されます。

途中で離脱される

離脱は、どの階層で起きているかを見ないと対処できません。1問目で閉じられているなら選択肢の文言、3問目以降で落ちているならシナリオの深さが原因です。

階層は3つまでに抑える

シナリオ型では、選択肢をたどる回数が増えるほど離脱します。目的の答えまで3クリック以内で到達できるかを目安に設計してください。分類を細かくするほど親切に見えますが、利用者にとっては自分の用件がどの分類か判断する負担が増えます。

回答精度が低い

「分かりません」が返る原因は、質問が想定外なのではなく、同じ意味の別の言い方に対応できていないことがほとんどです。「解約」で登録した回答を、利用者は「退会」「やめたい」「キャンセル」で探します。

未回答になった質問のログを週次で見て、言い換えを追加していく作業が精度を上げます。新しいFAQを増やすより、既存のFAQに表記ゆれを足すほうが効果は早く出ます。

見当違いの回答は「引っ張られている」のが原因

見当違いの回答が返る場合は、原因が逆になります。似た単語を含む別のFAQに引っ張られている状態で、この場合はキーワードを足すのではなく、紛らわしいFAQ側の記述を絞る必要があります。片方に「※お支払い方法の変更については別項目」と補足を入れるだけで解消することもあります。

質問文は利用者が口にする形で登録する

登録した質問文の書き方も精度に影響します。「配送状況について」のような名詞止めより、「注文した商品が今どこにあるか知りたい」のように利用者が口にする形で登録するほうが当たります。管理する側の分類名で登録すると、利用者の言葉と噛み合いません。

改善が進まない

兼務の担当者に「時間があるときに見てください」と依頼する運用は、まず続きません。ログを見る作業は緊急性がないため、常に後回しになります。

作業を週30分に切り分ける

対処は、時間を確保するのではなく、作業を小さくすることです。週に1回、未回答の質問リストの上位5件だけを見る、という形にすれば15分で終わります。全部を見ようとするから着手できなくなります。

指標は多く取れますが、実際に改善へつながるのは数個です。

回答率は「何かを返せたか」、解決率は「利用者の用が足りたか」を測ります。この2つは連動しません。すべての質問に何かしら答えられていても、その内容で解決していなければ、利用者は結局電話をかけます。

改善の順序としては、回答率を先に上げてから解決率に取り組むのが効率的です。返答できていない状態では、内容の良し悪しを評価するデータが集まりません。

なお解決率は、回答の末尾に「解決しましたか」と1問置くだけで取れます。押してもらえる割合は高くありませんが、押された低評価だけを追うだけでも改善対象は絞り込めます。

チャットボット単体の数字ではなく、問い合わせ対応全体の変化に置いてください。起動数が増えても、電話が減っていなければ業務は軽くなっていません。

現実的なKGIは、有人対応が必要だった問い合わせの件数です。チャットボットで完結した分だけこの数字は下がるため、投資に対する成果を説明しやすくなります。

季節変動には注意してください。前月比だけで判断すると、繁忙期に入っただけで悪化したように見えます。可能であれば前年同月と比べ、それが難しければ3か月移動平均で追うと傾向がつかめます。

改善は「会話ログを見る」「直す」「測る」の3つを回すだけです。難しいのは内容ではなく、続ける仕組みのほうにあります。

見る箇所は3つに絞ってください。未回答で終わった質問、低評価がついた回答、そして離脱が起きた地点です。

未回答の質問は、そのまま追加すべきFAQの候補になります。同じ内容が複数回出ていれば優先度が高い証拠です。低評価がついた回答は、内容が間違っているケースより、説明が抽象的で行動に移せないケースのほうが多く見られます。

離脱地点は、シナリオ型で特に重要です。同じ階層で繰り返し落ちているなら、その選択肢の文言が利用者の言葉になっていません。

ログを見る際は、件数の多い順だけでなく、直近1週間に初めて出てきた質問にも目を通してください。新しい質問は、商品やサービス側で何かが変わった合図であることがあります。仕様変更やキャンペーン開始の直後は、この種の質問が集中します。

会話ログには個人情報が入り込むことがある点にも注意が必要です。利用者が氏名や電話番号を入力してしまうケースは珍しくありません。閲覧できる担当者の範囲と保存期間を、運用開始時に決めておいてください。

分類を増やすと、利用者はどの選択肢を選べばよいか迷います。階層は3つまでを目安にし、それ以上細かくしたい場合はフリー入力を併用する構成が扱いやすくなります。

出口の設計も忘れないでください。どの階層からでも「担当者につなぐ」へ抜けられるようにしておくと、行き止まりによる不満を防げます。この出口へ流れた件数は、自動化しきれていない用件を教えてくれる貴重なデータでもあります。

戻り道も用意しておくと親切です。選択肢を1つ前に戻せない設計では、選び間違えた利用者は最初からやり直すことになり、その多くはそこで離脱します。

導入直後の3か月は週次、その後は月次に落とすのが現実的な進め方です。初期は想定とのずれが大きく、直す箇所が集中して出るためです。

ずれが収まってきたら、更新のきっかけを業務側に埋め込みます。新商品の発売、料金改定、キャンペーン開始といったタイミングでFAQを見直すルールにしておけば、担当者の意識に依存せず更新されます。運用が止まる原因のほとんどは、この「きっかけ」を決めていないことにあります。

理想は専任担当を置くことですが、多くの現場でそれは難しいはずです。

必要な役割は3つに絞れます。ログを見て改善案を出す人、FAQの内容を承認する人、そして数字を月次で報告する人です。1人が兼ねても構いませんが、誰がやるかは明示してください。

作業時間は週30分を確保できれば回ります。未回答リストの上位5件を確認し、言い換えを追加するだけなら、その範囲で収まります。まとまった時間を取ろうとするから着手できません。

定例の場も用意してください。月に1回、15分でも数字を共有する時間があると、運用が組織の目に触れます。誰も見ていない指標は、いずれ更新されなくなります。

FAQの追加に何段階もの承認が必要な仕組みは、運用開始から数か月で止まります。表記ゆれの追加や誤字の修正まで承認を求める必要はありません。

料金や契約条件など、間違えると影響が大きい内容だけ承認対象にし、それ以外は担当者の判断で更新できるようにしてください。更新の速さが精度に直結する領域では、慎重さがそのまま機会損失になります。

社内に時間が取れない場合、ベンダーの運用サポートや代行サービスを使う選択肢があります。ログ分析とFAQ修正を任せられるため、立ち上がりは確実に速くなります。

ただし、丸ごと任せる形はおすすめしません。どの問い合わせが増えているかという情報は、チャットボットの改善だけでなく、商品説明やWebサイトの改善にも使える資産だからです。外に出したままでは、その気づきが社内に残りません。

現実的な線引きは、作業は任せて判断は自社に残す形です。月次で「増えている質問」「未回答が多い領域」の報告を受け、どこを直すかは自社で決めてください。報告の内容が数字の羅列だけになっているなら、質問の中身まで出してもらうよう依頼する価値があります。

チャットボットだけで完結させようとすると、対応できない質問が行き止まりになります。有人チャットへの切り替え口を用意しておくと、この行き止まりを回避できます。

切り替えのタイミングは、自動で判定する設計にしてください。同じ質問が2回続けて未回答になった、利用者が「担当者につないで」と入力した、といった条件で切り替わる形が扱いやすくなります。利用者が自分でボタンを探す必要がある設計は、その前に離脱されます。

注意したいのは、有人チャットの待ち時間です。切り替えたあと数分待たされると、チャットボットで完結した場合より満足度が下がります。対応できる人員がいない時間帯は、有人チャットへの切り替えを出さず、フォームや電話へ案内するほうが親切です。

営業時間外の扱いも決めておいてください。夜間に有人チャットへ切り替わっても誰も出られないなら、その時間帯は問い合わせフォームへ誘導する設計に変えます。時間帯によって出口を変えるだけで、行き止まりによる不満はかなり減らせます。

有人チャットへ切り替わった件数と内容は、自動化できていない領域を示すデータでもあります。定期的に中身を確認し、定型化できるものが混ざっていればFAQへ戻してください。

生成AIを使うタイプでは、シナリオを組む作業は減りますが、運用そのものがなくなるわけではありません。むしろ確認すべき点が変わります。

最も重要なのは、参照させる情報源の管理です。生成AI型は与えられた資料をもとに回答を組み立てるため、資料が古ければ古い回答が出ます。シナリオ型では「答えられない」で済んだ場面が、生成AI型では「もっともらしい誤答」になる点に注意が必要です。

回答の揺れも確認対象です。同じ質問でも表現が毎回変わるため、料金や条件のように一字一句が重要な内容は、生成に任せず固定の回答を返す設計にしておくほうが安全といえます。

期待値の設定も運用の一部です。「AIだから何でも答えられる」と案内すると、答えられない領域に質問が集中し、評価が下がります。対応範囲を最初に明示するほうが、結果として満足度は保てます。

チャットボットの運用を語るとき、見落とされやすいのがこの点です。解決できなかった質問は消えるわけではなく、その多くは電話に流れます。

チャットボットの解決率だけを追っていると、この流出が見えません。導入後に電話が減っていないなら、チャットボット内の数字がいくら良くても、業務全体としては改善していないことになります。

急いでいる利用者は、そもそもチャットボットを使いません。電話が集中してあふれ呼が出ている窓口では、この層の不満が特に大きくなります。当社が50〜70代の男女241名に実施した調査では、自動応答全般への受容度は31.6%にとどまる一方、用途を特定したシーン別では70.5%が肯定的でした（出典: 消費者調査）。任せる用件の切り出し方によって、受け止めは大きく変わります。すべてをチャットボットに寄せようとせず、電話で受けたほうが早い用件は電話で受ける設計のほうが、結果的に評価は上がります。

逆方向の活用もできます。電話でどんな用件が多いかが分かれば、それはチャットボットに載せるべきFAQの優先順位そのものです。

IVR（自動音声応答）で用件別に振り分けておけば、どの種類の問い合わせが何件来ているかを件数として把握できます。チャットボットの会話ログだけを見ていると、「チャットボットを使う人」の傾向しか見えません。電話側のデータを合わせることで、はじめて問い合わせ全体の姿がつかめます。

実際に、日本予防医薬株式会社ではDHK CANVASと生成AI、RPAの連携によって電話対応を効率化し、年間3,800時間の削減につながりました（出典: 日本予防医薬株式会社の導入事例）。前橋市の国民健康保険課でも、電話対応の自動化で年間約550時間を削減しています（出典: 前橋市の導入事例）。文字と音声のどちらで受けるかを用件ごとに設計すると、片方だけでは届かない範囲まで自動化できます。音声側の適性はボイスボットと相性が良い業務で整理しています。

FAQそのものの整理についてはナレッジベースとは？でも解説しています。

Q. チャットボットの運用にはどれくらいの工数が必要ですか？

A. 導入直後の3か月は週30分、その後は月1時間程度を確保できれば回ります。未回答リストの上位5件を確認して言い換えを追加する範囲なら、この時間で収まります。まとまった時間を取ろうとすると、かえって着手できなくなります。

Q. 回答率が上がりません。何から手をつければよいですか？

A. 未回答で終わった質問のログを見て、既存FAQへの言い換え追加から始めてください。新しいFAQを増やすより、「解約」に対して「退会」「やめたい」といった表記ゆれを足すほうが効果が早く出ます。利用者は登録した正式名称では検索しません。

Q. チャットボットの効果はどう測ればよいですか？

A. チャットボット単体の起動数ではなく、有人対応が必要だった問い合わせ件数の変化で測ります。起動数が増えても電話が減っていなければ、業務は軽くなっていません。導入前の問い合わせ件数を記録していない場合は、解決件数を工数に換算する方法で代替できます。

Q. シナリオ型とAI型はどちらが運用しやすいですか？

A. 運用の手間はどちらもかかりますが、内容が違います。シナリオ型は選択肢と階層の設計に手間がかかり、AI型は参照させる資料の鮮度管理が中心になります。料金や契約条件など一字一句が重要な内容は、AI型でも固定の回答を返す設計にしておくと安全です。

Q. 導入して1年経ちますが、誰も更新していません。どうすべきですか？

A. 更新のきっかけを業務側に埋め込むところから立て直してください。新商品の発売、料金改定、キャンペーン開始といったタイミングでFAQを見直すルールにすれば、担当者の意識に依存しません。あわせて、承認が何段階も必要な仕組みになっていないかも確認してください。

Q. チャットボットを入れれば電話は減りますか？

A. 文字で完結する定型の用件については減ります。ただし本人確認が必要な手続きや、急いでいる利用者の問い合わせは電話に残ります。電話側でどの用件が多いかを集計し、文字と音声のどちらで受けるかを用件ごとに設計すると、全体として減らせます。

チャットボット運用の成否は、ツールの性能ではなく「未回答のログを毎週見る人がいるか」で決まります。着手するなら、週30分で未回答リストの上位5件を確認し、言い換えを追加するところから始めてください。

そのうえで、チャットボットで解決できなかった問い合わせがどこへ流れているかも確認する価値があります。電話に残っている用件を集計すれば、次に自動化すべき範囲が見えてきます。株式会社電話放送局では、電話側の用件の切り分けから自動応答の設計まで伴走しています。問い合わせ全体の効率化にお悩みの方は、導入事例もあわせてご覧ください。

DHK CANVAS

【本資料は、下記の関心をお持ちの方におすすめです】
・シナリオ型とAIエージェント型の比較軸を整理したい
・ボイスボットを成功させる運用設計

監修者情報

• シェア
• Tweet