問い合わせ対応へ生成AIを導入するとき、「事実と異なる回答を顧客へ伝えてしまわないか」という不安は避けて通れません。
営業時間や操作方法の案内であれば訂正できても、返品条件、契約内容、料金、注文状況などを誤れば、顧客との信頼や実際の取引に影響します。文章が自然であるほど、利用者が誤りに気づきにくいことも問題です。
一方、ハルシネーションを理由に生成AIを一切使わないと決める必要もありません。重要なのは、AIにすべてを任せることではなく、何を根拠に、どこまで回答し、判断できないときにどう止まるかを仕組みとして決めることです。
この記事では、OpenAIやGoogleの研究・公開情報を参考に、ハルシネーションが起きる理由と、問い合わせ対応で誤回答を減らすための設計をお伝えします。
ハルシネーションとは何か
ハルシネーションとは、生成AIが事実ではない内容を、もっともらしい文章として出力する現象です。
問い合わせ対応では、次のような形で現れる可能性があります。
- ナレッジに記載されていない返品期限を作る
- 実際には存在しない設定画面や操作手順を案内する
- 別の商品や契約プランの条件を混ぜて回答する
- 注文情報を確認せず、一般的な配送日数から到着予定を断定する
- 存在しないヘルプページやURLを提示する
単に知らないことが原因とは限りません。質問が曖昧である、参照情報が古い、検索結果に必要な条件が含まれていない、会話履歴を誤って解釈した、といった状況でも誤回答は起こります。
また、回答の自信と正しさは別です。断定的で読みやすい文章であっても、根拠がなければ業務上の回答としては扱えません。
OpenAIの研究から分かる、モデルが推測する理由
OpenAIが2025年9月に公開した「Why language models hallucinate」は、ハルシネーションを事前学習と評価方法の両面から説明しています。
言語モデルは、大量の文章から次に続く語を予測することで学習します。正しい事実だけを保存し、必要なときにそのまま取り出すデータベースではありません。頻出するパターンは学びやすい一方、出現頻度が低い事実や、規則性から推測しにくい情報では誤りが残ります。
もう一つの論点が、推測を促す評価です。
正解なら1点、不正解や「分からない」は0点という評価では、確信がなくても答えた方が高得点になる可能性があります。論文では、誤った断定を「分からない」という回答より重く扱い、適切な不確実性の表明を評価する必要性が示されています。
問い合わせ対応にも同じ考え方を応用できます。AIがすべての質問へ返答することを成功とせず、根拠が足りないときに回答を保留できることも、正しい動作として評価する必要があります。
モデルの改善と残る誤回答
モデルの事実性は改善されています。OpenAIのGPT-5発表では、Web検索を有効にした実利用に近い評価で、GPT-4oより事実誤りを含む可能性が約45%低く、推論時にはOpenAI o3より約80%低かったと報告されています。
ただし、OpenAIは同じ発表やハルシネーション研究の中で、誤回答が完全になくなったとは説明していません。ベンチマーク上の改善率を、自社の問い合わせにおける正答率として読み替えることもできません。
Googleも、Geminiを含むモデルの事実性とグラウンディングに関する研究を続けています。2026年8月のGoogle Researchの研究では、評価対象となった最新モデルの事実誤りについて、情報を学習していないことだけでなく、内部に保持している情報を適切に想起できないことも主要な要因になり得ると報告されています。
より新しいモデルを選ぶことは重要です。しかし問い合わせ対応では、自社の商品、契約、運用、顧客ごとの情報をモデルが事前に正しく知っているとは限りません。モデルの内部知識だけに頼らず、回答時に必要な根拠を取得する仕組みが必要です。
RAGの効果と情報不足の問題
RAGは、質問に関連する文書を検索し、その内容を生成AIへ渡して回答させる方法です。FAQやナレッジベースを参照させることで、自社固有の情報に基づく回答を作りやすくなります。
ただし、RAGを導入しただけでハルシネーションがなくなるわけではありません。
Google Researchの「Sufficient Context」に関する研究では、検索結果が質問に関連しているかだけでなく、回答に必要な情報が十分に含まれているかを確認する考え方が示されています。
例えば「この商品は返品できますか」という質問に、一般的な返品手順だけが取得されても、対象商品の除外条件、購入日、開封状態、販売地域が分からなければ回答には不十分です。関連文書が見つかったことを理由に、モデルが不足部分を補ってしまえば、根拠付きに見える誤回答になります。
研究では、回答前に情報の十分性を確認すること、不足時に追加の文書を取得・再順位付けすること、信頼度などに応じて回答を保留することが対策として挙げられています。
「ナレッジへ接続した」と「その質問へ回答できる情報が揃った」は、分けて考える必要があります。
問い合わせ対応で誤回答を減らす7つの設計
1. AIが回答してよい範囲を決める
最初からすべての問い合わせを自動回答の対象にしません。
営業時間、公開済みの操作手順、一般的な商品情報など、回答根拠と完了条件が明確な領域から始めます。返金の承認、契約変更、法的な判断、セキュリティ事故、重大な苦情などは、人による確認を中心にします。
対象範囲外の質問には推測で答えず、AIが対応できる範囲を短く説明して人へ引き継ぎます。
2. 承認済みのナレッジを参照元にする
AIへ文書を渡す前に、参照元を業務上信頼できる状態にします。
- 記事ごとに管理者と更新日を決める
- 古い記事、重複記事、矛盾する記事を見直す
- 商品、プラン、地域、対象者などの適用条件を明記する
- 例外条件を別の記事へ分断しすぎない
- 公開情報と社内向け情報のアクセス権を分ける
AIが誤ったように見えても、原因がナレッジの古さや矛盾にある場合があります。モデルの調整と情報整備を切り分けて考えることが大切です。
OpenAIも、企業データを検索して回答と出典を結び付けるKnowledge Retrievalの構成を公開しています。どの製品を使う場合でも、信頼できる参照元を用意する考え方は共通します。
3. 回答に必要な情報が十分かを確認する
検索結果が取得できたかだけではなく、質問へ答えるための条件が揃ったかを確認します。
条件が不足している場合は、商品名、契約プラン、購入日、利用環境などを追加で質問します。それでも判断できなければ、回答を生成せずに有人対応へ切り替えます。
この判定は、単純な類似度のしきい値だけでなく、必要条件の有無、文書の更新日、適用範囲、複数文書の整合性などを組み合わせて設計します。
4. 個別情報は業務システムから取得する
注文状況、配送予定、契約内容、在庫、請求金額などは、ナレッジだけでは回答できません。
これらを言語モデルに推測させず、APIや業務システムから構造化された値として取得します。AIは取得した情報を読みやすく説明する役割に限定します。
住所変更、解約、返金などの操作を行う場合は、情報の参照と更新を分け、本人確認、権限、確認画面、確定操作を用意します。文章を正しく生成できることと、業務処理を実行してよいことは別の判断です。
5. 回答の根拠を表示・記録する
担当者向けの回答案には、参照したナレッジの記事名や該当箇所を表示します。顧客向けの回答でも、操作手順や規約などは確認できるURLを添えると、利用者自身が内容を確かめられます。
Gemini APIのGoogle Searchによるグラウンディングでは、回答と検索結果の対応情報を受け取り、文章中の主張へ引用を表示できます。また、Google Cloudには、生成された回答が与えた根拠にどの程度裏付けられているかを確認するCheck grounding APIも用意されています。
ただし、引用が付いているだけで正しいとは限りません。引用先が古い、対象条件が異なる、文章の一部しか裏付けていない場合もあります。根拠の有無と、根拠の妥当性を分けて評価します。
6. 回答保留と有人切替を成功として設計する
AIが分からないときに、無理に会話を続けさせません。
「回答に必要な情報が不足しているため、担当者へ引き継ぎます」と伝え、問い合わせ内容、確認済みの条件、参照したナレッジ、回答できなかった理由をチケットへ残します。
有人対応へ切り替えた後に、顧客が同じ内容を最初から説明し直す状態は避けます。AIの回答率を高めることより、適切なタイミングで止まり、必要な情報を人へ渡せることを優先します。
7. 過去の問い合わせで評価し、運用後も監視する
一般的なベンチマークだけで、自社の問い合わせ対応に使えるかは判断できません。過去のチケットから、質問、必要条件、正しい回答、参照すべきナレッジ、有人対応が必要かどうかを持つ評価データを作ります。
確認する指標は正答率だけではありません。
| 指標 | 確認する内容 |
|---|---|
| 誤回答率 | 事実と異なる内容を回答した割合 |
| 根拠一致率 | 回答内容が参照元で裏付けられている割合 |
| 適切な回答保留率 | 情報不足時に推測せず止まれた割合 |
| 有人切替の完全性 | 必要な情報を保持して担当者へ渡せた割合 |
| 解決率 | 顧客が追加の問い合わせなく解決できた割合 |
通常の質問だけでなく、曖昧な表現、複数の商品が該当する質問、例外条件、古い情報、誘導的な質問も評価に含めます。モデル、プロンプト、ナレッジ、業務ルールを変更したときは、同じ評価データで再確認します。
リスクに応じてAIの役割を変える
問い合わせごとに誤回答時の影響は異なります。リスクに応じて、自動回答、担当者支援、有人対応を分けると、導入範囲を判断しやすくなります。
| リスク | 問い合わせ例 | AIの役割 |
|---|---|---|
| 低 | 営業時間、公開済みの操作手順、一般的な商品情報 | 根拠を確認できた場合に自動回答 |
| 中 | 注文状況、契約内容、アカウント固有の案内 | システム参照後に回答、または担当者向け回答案 |
| 高 | 返金判断、契約変更、法的判断、重大な苦情、セキュリティ | 情報収集と引き継ぎに限定し、人が回答 |
低リスクの問い合わせで精度と運用方法を確認し、評価結果を見ながら対象を広げます。すべての問い合わせで同じ自動化率を目指す必要はありません。
ナレッジと業務フローの改善
誤回答を減らすには、モデルだけでなく、問い合わせ対応全体を確認する必要があります。
問い合わせの多い内容に対応する記事が存在しない、同じ内容を複数の部署が異なる基準で回答している、担当者が別システムを何度も検索している、といった状態では、AIも安定した回答を作れません。
反対に、問い合わせを分類し、回答根拠を明確にし、必要な顧客情報を取得できるようにすると、その改善は人による対応にも役立ちます。AI導入は、これまで担当者の経験に依存していた判断や情報を見直す機会にもなります。
KIRIKOMIのお問い合わせ対応 AI活用診断では、蓄積された問い合わせデータから、AIによる自動回答だけでなく、担当者支援、FAQ・ナレッジ整備、システム連携、業務フロー改善の候補を確認します。
まとめ
ハルシネーションは、最新の生成AIでも完全にはなくなっていません。しかし、問い合わせ対応での誤回答リスクを、そのまま受け入れる必要はありません。
重要なのは、AIに正解を期待するだけでなく、正しい情報へ到達し、根拠を確認し、判断できないときに止まる仕組みを作ることです。
- 回答範囲を限定する
- 承認済みナレッジを整備する
- 情報の十分性を確認する
- 個別情報は業務システムから取得する
- 回答根拠を表示・記録する
- 回答保留と有人切替を用意する
- 実際の問い合わせで継続評価する
AIを信用するかどうかという二択ではなく、AIが参照する情報、回答できる範囲、判断できない場合の流れを企業側が管理できるかが、問い合わせ対応への導入を考えるうえで重要です。
現在のナレッジや問い合わせデータで、どこまでAIを活用できるか分からない場合は、お問い合わせフォームからご相談ください。
参考資料
- OpenAI「Why language models hallucinate」
- OpenAI「Introducing GPT-5」
- Google Research「Empty shelves or lost keys? Recall is the bottleneck for parametric factuality」
- Google Research「Deeper insights into retrieval augmented generation: The role of sufficient context」
- OpenAI「Knowledge Retrieval: Trusted, cited answers from your data」
- Gemini API「Grounding with Google Search」
- Google Cloud「Check grounding with RAG」
