--- title: "チャットボットの失敗パターンと原因｜使われない・誤回答・放置を防ぐ回答精度の設計" url: "https://www.issoh.co.jp/column/details/19377/" published: 2026-11-05 updated: 2026-11-05 categories: ["Webシステム"] publisher: "株式会社一創" --- # チャットボットの失敗パターンと原因｜使われない・誤回答・放置を防ぐ回答精度の設計 チャットボットの失敗は、利用者に使われない、質問に答えられない、公開後に放置される、効果が費用に見合わない、の4つの型にほぼ集約されます。生成AI型ではこれに、もっともらしい誤回答と、指示を上書きされるプロンプトインジェクションが加わります。カナダでは航空会社のチャットボットが誤った運賃規定を案内し、2024年に会社側へ支払いが命じられました。この記事では、失敗の型ごとの原因、生成AI型に特有のリスク、公開前に回答精度を測る手順、失敗したボットを立て直すか見送るかの判断基準を、チャットボットの受託開発会社の視点で整理します。 ## まとめ：チャットボットの失敗は回答範囲の線引きと改善担当の不在から起きる 失敗したチャットボットを分解すると、ツールの性能より手前の決めごとが欠けている例が大半です。何に答えて何に答えないかを決めないまま公開すると、利用者は何でも聞き、答えられない質問が積み上がります。答えられなかった質問を誰が週に何回見直すかが決まっていなければ、精度は公開日から上がりません。 生成AI型では、誤回答の責任は設置した会社が負うという前提で設計します。参照した文書を示せない回答は返さない、契約や料金のように誤りが損害に直結する質問は人に回す、公開前に実際の問い合わせで正答率を測る、の3つを公開の条件にしてください。問い合わせが月100件に満たず、個別判断の質問が中心の窓口なら、チャットボットを入れないほうが失敗しません。 ## チャットボット導入が失敗する4つの型と原因：使われない・答えられない・放置・費用倒れ 従来型・生成AI型を問わず起きる失敗を、原因と合わせて4つに分けます。導入手順の全体は[チャットボット導入の進め方と方式の選び方](https://www.issoh.co.jp/column/details/15312/)で扱っているため、ここでは失敗の原因に絞ります。 ### 利用されない失敗：設置場所と答えられる範囲が利用者に伝わっていない状態 利用率が低いボットの多くは、問い合わせが発生するページに置かれていません。トップページの右下にだけ置き、注文確認や解約手続きのページには無い、という配置です。利用者は困った画面で聞きたいので、問い合わせの多いページから順に設置します。 もう1つの原因は、何を聞けるかが分からないことです。最初の画面で「配送・返品・会員登録について答えます」と範囲を示し、よく聞かれる質問を3〜5個ボタンで並べると、自由入力で外れた質問をされる割合が下がります。 ### 答えられない失敗：FAQの粒度と言葉が実際の質問とずれている状態 社内の担当者が作ったFAQは、社内の言葉で書かれがちです。利用者は「解約」と言わずに「やめたい」「止めたい」と書き、製品の正式名ではなく通称で聞きます。登録した質問文と実際の質問がずれていると、シナリオ型もAI型も正しい回答にたどり着けません。 FAQの元にするのは、過去3か月分のメール・電話・問い合わせフォームの実文です。同じ意味の言い換えを1つの回答に束ね、1つの回答に複数の手続きを詰め込まず、答えが1つに決まる単位まで分けます。 ### 放置される失敗：未回答ログを見る担当者と見直しの頻度が決まっていない 公開直後の正答率が最も低く、そこから未回答の質問をFAQに戻すことで上がっていきます。この改善を誰の業務にも入れていないと、ボットは公開日の精度のまま止まります。導入プロジェクトの担当者が異動し、管理画面のログインIDだけが残っている状態は珍しくありません。 見直しは週に1回、30分で回せる量に絞ります。体制の決め方は後半の運用章で具体的に示します。 ### 費用倒れの失敗：問い合わせ件数と定型質問の比率を測らずに導入を決めた場合 チャットボットが減らせるのは、毎回同じ答えになる定型質問の対応だけです。月の問い合わせが200件で、そのうち定型が3割なら、ボットが吸収できるのは最大でも月60件です。そこから回答できなかった分を引くと、有人対応の削減は月数十件に留まります。 導入前に件数と定型比率を数えず、他社事例の削減率を前提に投資を決めると、この計算が後から合わなくなります。公表事例の数字をそのまま自社に当てはめられない理由は[AIチャットボット導入事例と自社に当てはめる判断基準](https://www.issoh.co.jp/column/details/15806/)で詳しく扱っています。 ## 生成AI型チャットボットに特有の失敗：誤案内の責任とプロンプトインジェクション 生成AI型は、登録していない質問にも文章で答えられる反面、事実と異なる内容を自然な文で返すことがあります。従来型にはなかった失敗の型として、2つを押さえます。 ### Air Canada事件：チャットボットの誤案内で会社側に812カナダドルの支払い命令 2022年11月、祖母を亡くした利用者がAir Canadaのウェブサイトでチャットボットに忌引運賃を尋ねました。ボットは、搭乗後でも航空券の発行日から90日以内に申請すれば割引を受けられると案内しましたが、実際の規定では事後の申請は認められていませんでした。 ブリティッシュコロンビア州の民事紛争解決審判所は2024年2月14日、会社側に計812.02カナダドル（損害650.88、利息36.14、手数料125）の支払いを命じています。[審判所の判決文（2024 BCCRT 149）](https://decisions.civilresolutionbc.ca/crt/crtd/en/525448/1/document.do)の段落27では、チャットボットは自社ウェブサイトの一部であり、情報が静的なページから来たかチャットボットから来たかで違いはないと判断されました。正しい情報が別のページにあったという会社側の主張も退けられています。ボットの回答は会社の公式な案内として扱われる、という前提で設計してください。 ### もっともらしい誤回答：OWASPが誤情報リスクとして挙げる原因と対策 生成AIは、参照すべき文書が見つからなくても、それらしい文章を作って答えることがあります。セキュリティ団体OWASPの[LLMアプリケーションのリスク一覧（2025年版）のLLM09「誤情報」](https://genai.owasp.org/llmrisk/llm092025-misinformation/)は、まさにAir Canadaの件を事実誤認の例に挙げています。 同じ項目が対策として挙げるのは、信頼できる文書を検索して回答に使う構成（RAG）、重要な情報への人による確認、出力の自動検証、画面上でAIが生成した回答だと明示して限界を伝えることなどです。プロンプトの書き方や検出APIまで含めた実装は[AIハルシネーション対策の実装と運用](https://www.issoh.co.jp/tech/details/8017/)にまとめています。発注側として確かめるべきは、ベンダーがこのうちどれを実装しているかです。 ### プロンプトインジェクション：指示の上書きで想定外の回答や操作を引き出される 利用者が「これまでの指示を無視して」と書き込み、ボットに本来答えない内容を答えさせたり、権限外の操作をさせたりする攻撃です。OWASPの[LLM01「プロンプトインジェクション」](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)は、サポート用チャットボットに指示を注入して非公開のデータを照会させ、メールを送信させる場面を攻撃例に挙げ、生成AIの性質上、確実な防止策があるかは明らかでないと明記しています。 だからこそ、注入される前提で被害を限定する設計が要ります。ボットに渡す権限を必要最小限にし、予約の取り消しや返金のような操作は人の承認を挟み、外部の文書は信頼できない入力として扱ってください。攻撃の種類と対策コードは[プロンプトインジェクションの攻撃例と対策](https://www.issoh.co.jp/tech/details/1535/)で解説しています。社内データに触れるボットほど、この設計が失敗を分けます。 ## 失敗を防ぐ回答精度の設計：公開前に決めておく範囲・根拠・評価・引き継ぎ ここからは、前の2章で挙げた失敗を公開前に潰すための設計です。4つとも、ツールを選ぶ前に文書で決められます。 ### 答えてよい範囲と答えない質問のリストを公開前に文書で決める手順 最初に作るのは、ボットが答える質問の範囲と、答えずに人へ回す質問の一覧です。答えない側には、契約内容・請求額・個別の補償可否・医療や法律の判断のように、誤ると損害や法令違反につながる質問を入れます。 範囲外の質問が来たときの返答も決めておきます。「その内容はチャットではお答えできません。担当者がメールで回答します」のように、断ったうえで次の窓口を示す文面です。生成AI型では、この一覧をシステムへの指示（システムプロンプト）と回答前のチェックの両方に入れます。指示だけでは前章の注入で上書きされるためです。 ### 根拠のある回答だけを返す設計：参照元の表示と「分からない」と答える条件 生成AI型の誤回答を減らす最も確実な手段は、参照した社内文書が見つからないときに答えさせないことです。検索で十分に関連する文書が見つからなかった場合は「該当する情報が見つかりません」と返し、有人窓口を案内します。 回答の末尾には、参照したFAQやマニュアルのページ名とリンクを表示します。利用者が元の文書で確かめられ、誤りがあったときにどの文書が原因かを運用担当者が追うことも可能です。Air Canadaの件のように、規定のページとボットの回答が食い違う状態を放置しないための仕組みでもあります。 ### 公開前の評価：実際の問い合わせ100件で正答率と誤答の重さを測る方法 公開前に、過去の問い合わせから100件程度を抜き出し、ボットに同じ質問を投げて判定します。判定は正答・不正答の二択ではなく、誤答の重さで分けるのがコツです。 | 判定 | 内容 | 公開の扱い | | ---- | -------------- | ------------- | | 正答 | 根拠の文書と一致する回答 | そのまま公開 | | 回答拒否 | 分からないと答え有人へ案内 | 件数が多ければFAQを追加 | | 軽い誤答 | 案内先のページ違いなど | 公開前に修正 | | 重い誤答 | 料金・期限・規定を誤って案内 | 1件でも出たら公開を延期 | 回答拒否は失敗ではありません。避けるべきは重い誤答で、1件でも出たらその分野をボットの範囲から外すか、参照文書を直してから再評価します。RAG構成で検索と生成を分けて測る指標は[RAG評価の指標と運用への組み込み](https://www.issoh.co.jp/tech/details/15935/)で解説しています。 ### 有人への引き継ぎ条件：誤答の影響が大きい質問と不満の兆候を人に回す基準 引き継ぎの条件は、質問の種類と会話の状態の2つで決めます。種類では、範囲外リストに当たる質問をボットが受けた時点で人に回してください。状態では、同じ質問の言い換えが2回続いた、「担当者」「電話」と書かれた、回答に「役に立たなかった」が押された、のいずれかで切り替えます。 引き継ぐときは、それまでの会話を担当者に渡し、利用者に同じ説明を繰り返させないことが条件です。渡す情報と引き継ぎの構成は[チャットボットでヘルプデスクを一次受けする設計と有人引き継ぎ](https://www.issoh.co.jp/column/details/17486/)で詳しく扱っています。 ## 公開後に失敗させない運用：未回答ログの週次見直しと4つの指標の決め方 公開した日がボットの精度の最低点です。上げていく仕組みを、指標と体制の2つに分けて決めます。 ### 見る指標：自己解決率・未回答率・有人引き継ぎ率・誤答の報告件数 毎週見る数字は4つです。ボットの回答で会話が終わった割合（自己解決率）、分からないと答えた割合（未回答率）、人に引き継いだ割合、利用者や担当者から報告された誤答の件数です。利用回数だけを追うと、答えられずに離脱した会話も成果に数えてしまいます。 優先度が最も高いのは誤答の報告件数です。自己解決率が上がっていても、誤答が出ているなら範囲の見直しを先にします。未回答率は下げる対象ですが、0に近づけようと範囲外の質問にまで答えさせると、重い誤答が増える点に注意してください。 ### 週30分の見直し体制：担当者・FAQ更新の承認者・作業の順番 体制は、ログを見てFAQを直す運用担当者と、回答内容を承認する業務部門の責任者の2人で組みます。運用担当者だけで料金や規定の回答を書き換えると、今度は担当者の思い込みが誤答の原因になります。 1. 誤答の報告を確認し、原因の文書を直すか範囲から外す 2. 未回答の質問を件数順に並べ、上位5件のFAQを追加する 3. 引き継ぎの多い質問を見て、ボットで答えるか人に残すかを決める 4. 規定や料金の改定予定を業務部門に確認し、参照文書を先に更新する 4つ目を入れておくと、規定が変わったのにボットだけ古い案内を続けるという、Air Canadaの件と同じ型の失敗を防げます。 ## 失敗したチャットボットを立て直す判断と導入を見送るべき場面の言い切り すでに失敗している場合、ツールを替えるべきか、作り直すべきか、やめるべきかを条件で分けます。 ### 作り直しで立て直せる場面：原因がツールではなくFAQと範囲にある場合 未回答の質問を並べたときに、FAQに載っていない質問や言葉のずれが大半なら、ツールを替えても結果は同じです。この場合は、前章の手順で範囲を決め直し、過去の問い合わせからFAQを作り直します。費用をかけずに改善できる、最も多いケースです。 設置場所を問い合わせの多いページへ移す、最初の画面に答えられる範囲を出す、の2つだけで利用率が変わることもあります。乗り換えを考えるのは、これらを試した後で十分です。 ### 作り替えや自社構築を検討する場面：社内データの参照と誤答の管理が要る場合 「注文した商品はいつ届くか」「契約の更新日はいつか」に答えられないことが失敗の原因なら、FAQをいくら増やしても解決しません。受注や会員のデータを本人確認のうえで照会する仕組みが必要で、SaaSの設定画面だけでは組めないことが大半です。参照元の表示、回答拒否の条件、誤答の記録と承認の流れを自社の規定に合わせて作り込みたい場合も同じです。 この段階では、これまでの未回答ログと誤答の記録がそのまま要件の材料になります。一創の[AIチャットボット開発サービス](https://www.issoh.co.jp/service/ai/chatbot/)では、既存ボットのログを分析したうえで、社内システムとの連携範囲と回答精度の評価方法を含めた構成をご提案します。 ### チャットボットを入れないほうがよい場面：月100件未満で個別判断が中心の窓口 月の問い合わせが100件に満たず、その多くが見積もりや個別の事情の相談のように毎回答えが変わる窓口では、チャットボットは入れないと判断します。吸収できる定型質問が少なく、FAQの整備と週次の見直しにかかる工数のほうが大きくなるためです。 この規模なら、よくある質問のページを整え、問い合わせフォームの項目を見直すほうが確実に効果が出ます。ボットを置くかどうかは、問い合わせ件数が増えて定型比率を数えられるようになってから決めても遅くありません。 ## よくある質問 チャットボットの失敗について、導入を検討中の担当者や、すでに運用している担当者から寄せられることの多い質問に答えます。 ### チャットボットの導入で最も多い失敗は何ですか？ 多いのは、公開後に改善されず放置される失敗です。公開直後のボットは答えられない質問が多く、未回答の質問をFAQに戻す作業で精度が上がっていきます。この見直しを誰の業務にも入れていないと、利用者は答えられない体験を繰り返して使わなくなります。導入前に、週1回30分の見直し担当者と、回答内容を承認する業務部門の責任者を決めてください。 ### チャットボットが使われない原因は何ですか？ 主な原因は、設置場所と答えられる範囲の伝え方です。トップページにだけ置き、注文確認や解約手続きのような問い合わせが発生するページに無いと、困った利用者の目に入りません。最初の画面で何に答えるかを示し、よく聞かれる質問を3〜5個ボタンで並べると、利用のきっかけが生まれ、範囲外の質問も減ります。 ### 生成AIのチャットボットが間違った回答をしたら誰の責任になりますか？ 設置した会社の責任として扱われる前提で考えてください。カナダのAir Canadaの件では、2024年2月に審判所が、チャットボットも自社ウェブサイトの一部であり、その情報に会社は責任を負うと判断し、計812.02カナダドルの支払いを命じました。日本の法的な扱いは個別の事案によりますが、料金・期限・規定のように誤りが損害につながる質問は、ボットの範囲から外して人に回す設計が安全です。 ### チャットボットの回答精度はどうやって測ればよいですか？ 過去の問い合わせから100件程度を抜き出し、ボットに同じ質問をして判定します。判定は正答・回答拒否・軽い誤答・重い誤答の4つに分け、料金や規定を誤って案内する重い誤答が1件でも出たら、その分野を範囲から外すか参照文書を直してから再評価します。公開後は自己解決率・未回答率・有人引き継ぎ率・誤答の報告件数を毎週確認してください。 ### 失敗したチャットボットは別のツールに乗り換えるべきですか？ 先に原因を確かめてください。未回答の質問がFAQに無い内容や言葉のずれによるものなら、ツールを替えても同じ結果になるため、範囲とFAQの作り直しが先です。乗り換えや作り直しを検討するのは、注文状況や契約内容のように社内システムのデータを参照して答える必要がある場合や、回答の根拠表示と誤答の管理を自社の規定に合わせたい場合です。 ## 関連記事 - [チャットボット導入の進め方とは？手順・費用相場・シナリオ型とAI型の選び方](https://www.issoh.co.jp/column/details/15312/)：失敗を避けたうえで導入を進めるときの全体の手順 - [AIチャットボット導入事例｜業種・用途別の効果とメリット・デメリット、自社に当てはめる判断基準](https://www.issoh.co.jp/column/details/15806/)：効果が出た事例と出なかった事例を分ける前提条件 - [チャットボットは無料でどこまで使える？無料プランの上限と有料・自社構築への切り替え基準](https://www.issoh.co.jp/column/details/19212/)：失敗のリスクを抑えて無料枠で効果を測る方法 - [チャットボット比較｜シナリオ型・AI型・生成AI型の違いと選び方【2026年】](https://www.issoh.co.jp/column/details/15395/)：失敗の型と関係する方式ごとの違い - [AIチャットボットの作り方｜生成AI＋RAG・ノーコード・受託開発の方式選定と実装手順](https://www.issoh.co.jp/tech/details/15343/)：作り直しや自社構築に進むときの方式選定 --- 出典: [チャットボットの失敗パターンと原因｜使われない・誤回答・放置を防ぐ回答精度の設計]()（株式会社一創）