ハルシネーションはAI英会話で何が起きているのか。事実でない英語が返る仕組みと止め方を分解した

AI英会話で練習していて、返ってきた英語がどうも怪しいと感じたことはないだろうか。

存在しないイディオムを「よく使う表現だ」と紹介してきたり、聞いてもいない出典を堂々と挙げてきたりする。

これがハルシネーションと呼ばれている現象だ。

やっかいなのは、間違っている英語ほど自然で自信たっぷりに返ってくることだ。

学習者は正解を知らないから聞いているのであって、返ってきた英語の真偽をその場で判定できるなら、そもそも練習する必要がない。

この記事では、AIの部品を売っている会社の公式ドキュメントだけを材料にして、ハルシネーションが何であり、どういう仕組みで止められているのかを分解する。

サービスの順位づけやおすすめはしない。仕組みの話だけをする。

【結論】ハルシネーションはAI英会話の副作用であり、部品を足して抑えるものだ

先に答えを置く。

ハルシネーションは、言語モデルの性能が足りないから起きる故障ではない。

言語モデルが「持っていない情報についても、もっともらしい文を作れてしまう」という性質そのものから出てくる副作用だ。

だから各社の公式ドキュメントは、モデルを賢くする話ではなく、周りに部品を足して抑える話としてこれを扱っている。

抑え方	やっていること	公式での呼び名
①出典に縛る	検証可能な情報源につないで、そこから答えさせる	グラウンディング／RAG
②入口と出口を検査する	本番のモデルの前後に別の検査を挟む	ガードレール
③推測を禁じる	「分からないなら聞き返せ、推測するな」と指示文に書く	プロンプトの条文
④人間を挟む	影響の大きい動作の前で処理を止めて承認を待つ	ヒューマン・イン・ザ・ループ
⑤後から測る	出力が出典に沿っているかを別のAPIで判定する	グラウンデッドネス検出

⇒ ハルシネーションは「無くなるもの」ではなく「減らす対象」として設計されている。

この前提を持っているかどうかで、AI英会話の使い方は大きく変わる。

ハルシネーションとは何か｜公式ドキュメントの定義を2社ぶん並べる

まず、言葉の定義を公式から取る。

グーグルのGrounding overview は、グラウンディングの利点を列挙する中で、ハルシネーションを「the model generates content that isn’t factual」＝モデルが事実でない内容を生成する事例、と定義している。

マイクロソフトのGroundedness detection は、同じものを「ungroundedness」という語で説明している。

「Ungroundedness refers to instances where LLMs produce information that is non-factual or inaccurate from what was present in the source materials.」＝与えた資料にあった内容から見て、事実でない、あるいは不正確な情報を作ってしまうこと、という定義だ。

会社	使っている語	定義の軸
Google Cloud	hallucinations	事実でない内容を生成すること
Microsoft	ungroundedness	与えた資料と合っていない内容を出すこと
OpenAI	hallucinating inaccurate information	言語モデルの限界のひとつとして列挙

この2つの軸のずれは重要だ。

「世の中の事実と違う」ことと、「渡した資料と違う」ことは、別の測り方になる。

マイクロソフトはさらに、望ましい状態のほうも定義している。「A grounded response adheres closely to the given information, avoiding speculation or fabrication.」＝与えられた情報に忠実で、憶測や捏造を避けた返答、というものだ。

OpenAIのSafety best practices は、「Understand and communicate limitations」という見出しの下で、不正確な情報のハルシネーションを言語モデルの限界の筆頭に挙げている。

そのうえで、モデルが自分の用途に適しているかを検討し、利用者の期待を適切に調整せよと書いている。

AI英会話でハルシネーションが起きやすいのはどこか

起きる場所には、仕組みから説明できる偏りがある。

マイクロソフトのGroundedness detection は、RAGを説明する前置きとして、言語モデルの知識の範囲をこう書いている。

「LLMs can reason about wide-ranging topics, but their knowledge is limited to the public data that was available at the time they were trained.」＝知識は学習した時点で入手できた公開データに限られる。

つまり、学習データの外側を聞かれたときが、いちばん危ない。

• 学習時点より後のこと＝新しい試験制度、最近変わった単語の使われ方。
• 公開されていないこと＝そのアプリ独自のカリキュラム、自分の過去の学習履歴。
• そもそも答えが存在しないこと＝「この表現はネイティブの何%が使うか」のような、確かめようのない問い。

加えて、OpenAIのPrompt engineering が書いている通り、モデルの生成は non-deterministic（非決定的）だ。

同じ質問を2回しても同じ答えが返る保証はない、という意味になる。

⇒ 1回目に正しく答えたからといって、2回目も正しいとは限らない。

これは同じガイドが冒頭で述べている性質であって、不具合ではない。

ハルシネーションは英語学習でどんな形をとるか

公式ドキュメントが示している例は、英語学習の場面にそのまま置き換えられる。

マイクロソフトのGroundedness detection は、検出が効く典型例として、資料に「The Battle of Hastings occurred in 1066.」とあるのに出力が「1065」になっている、という年号のずれを挙げている。

同じページには、資料の患者名が「Jane」なのに出力が「Kevin」になっている例も載っている。

どちらも固有名詞と数字という、確認しないと気づけない種類のずれだ。

公式が挙げるずれの型	AI英会話での現れ方	学習者が気づけるか
年号・数値のずれ	試験の形式や設問数を違う数で説明する	気づきにくい
固有名詞のずれ	存在しない辞書名や著者名を出典として挙げる	気づきにくい
資料にない主張の追加	「ネイティブはこう言う」と根拠なく断言する	ほぼ気づけない
要約時の捏造	自分の発話ログを要約させると言っていない内容が混ざる	読み返せば気づける

英語そのものの誤りより、英語にまつわる「事実」の誤りのほうが厄介だ。

文法の形は他の教材と照合すれば分かるが、「この言い方はイギリスでは古い」といった説明は、照合先を持っていないと検証できない。

ハルシネーションを抑える①｜グラウンディングで出典に縛る

いちばん基本的な対策が、答えの出どころを固定してしまうことだ。

グーグルのGrounding overview は、グラウンディングを「the ability to connect model output to verifiable sources of information」＝モデルの出力を検証可能な情報源につなぐ能力、と定義している。

そのうえで、特定のデータ源へのアクセスを与えると出力がそのデータに結びつき、「reduces the chances of inventing content」＝内容をでっち上げる可能性が下がる、と書いている。

公式が挙げる利点は3つだ。

• ハルシネーション（事実でない内容の生成）を減らす。
• 回答を自分のデータ源に固定する。
• 監査可能性を与える＝出典へのリンクが付く。

3つ目が、学習者にとっていちばん実用的だ。

出典リンクが付いている機能は、後から自分で確かめられる。逆にリンクが1本も出てこない説明は、確かめる手段が用意されていない。

この「資料を取ってきてプロンプトに差し込む」やり方を、OpenAIのPrompt engineering は retrieval-augmented generation（RAG） と呼んでいる。

同じガイドは、RAGを使う理由を「学習データの外にある独自データへアクセスさせるため」「回答を、有益だと判断した特定の資料の範囲に制限するため」の2つとして挙げている。

⇒ 教材や辞書のデータを持っているサービスは、そこに縛れる。持っていなければ、モデルの記憶に頼るしかない。

ハルシネーションを抑える②｜ガードレールで入口と出口を検査する

2つ目は、本番のモデルの前後に別の検査を挟む方法だ。

OpenAIのGuardrails and human review は、ガードレールを「入力・出力・ツールのふるまいを自動で検証するもの」と定義し、用途別に4種類を整理している。

公式が挙げる用途	使う仕組み	AI英会話での使いどころ
本番モデルが動く前に、許可しない要求を止める	Input guardrails	学習と関係ない相談をはじく
最終出力がシステムを出る前に検証・伏字化する	Output guardrails	根拠のない断定を出す前に止める
関数ツールの呼び出しの引数や結果を検査する	Tool guardrails	辞書検索に渡す語を検査する
影響の大きい動作の前で止める	ヒューマン・イン・ザ・ループ承認	学習履歴の書き換えなどの前で止める

入力側のガードレールは、本体が動く前に走る「速い検証」として設計されている。

公式は、本体を動かすコストやリスクが高すぎるときはブロッキング実行を、待ち時間を優先するなら並列実行を選べ、と使い分けまで書いている。

見落としやすいのが、ガードレールが走る範囲だ。

同じページの「Workflow boundaries matter」には、入力側は連鎖の最初のエージェントにしか走らず、出力側は最終出力を作るエージェントにしか走らない、と明記されている。

そのうえで「Put validation next to the tool that creates the side effect.」＝副作用を起こすツールのすぐ隣に検証を置け、と結論している。

人間の承認については、手順が4段で書かれている。処理がツールを実行せずに中断を記録し、再開可能な state が返り、アプリ側が承認か却下を決め、新しい会話ではなく同じ処理を state から再開する、という流れだ。

なお、有害な内容の検出については、OpenAIがModeration API を無料で提供していると Safety best practices に書かれている。ただしこれは安全性の検査であって、事実かどうかの検査ではない。

ハルシネーションを抑える③｜音声では「推測するな」という条文で止める

音声の会話になると、対策は指示文の条文として現れる。

OpenAIのPrompting GPT-Live が公開しているひな型には、推測を禁じる行が繰り返し出てくる。

• 「Do not guess the result while waiting.」＝裏の処理を待っている間に結果を推測するな。
• 「Delegate before giving an answer that depends on backend work.」＝裏の処理に依存する答えは、先に委譲してから言え。
• 「If an important name, date, or number is unclear, ask about that part.」＝重要な名前・日付・数字が不明瞭なら、その部分を聞き返せ。
• 「Use the user’s correction. Do not guess the missing value.」＝利用者の訂正を使え。欠けた値を推測するな。
• 「Do not guess the caller’s language from their name or location.」＝名前や場所から相手の言語を推測するな。

同じガイドは、裏の処理が確認する前に「終わった」と言い切ることを明確に禁じている。

「It must not promise a booking, guess a price, or claim an action has finished before the backend confirms it.」という一文がそれだ。

これは、ハルシネーションの中でも特に被害が出やすい「まだ確定していないことを確定したように言う」型を、正面から止めにいっている。

ただし、ガイド自身がプロンプトの限界も書いている。

「Prompts do not guarantee exact capture.」＝プロンプトは正確な聞き取りを保証しない。

だから公式は、条文を書くだけで終わらせず、権限やツール実行の確認をアプリ側で強制しろと繰り返している。

ハルシネーションは検出できるのか｜グラウンデッドネス検出という測り方

出てしまった後に測る仕組みも、製品として存在する。

マイクロソフトのGroundedness detection は、言語モデルの返答が「提供した資料に基づいているか」を確かめ、非事実または捏造された出力のリスクを下げるものだと説明されている。

この機能には、速度と説明のしやすさを釣り合わせる2つのモードがある。

モード	公式の説明	向いている場面
Non-Reasoning mode	オンライン用途向けの高速検出。詳しい説明なしで、grounded／ungrounded の2値を返す	待ち時間が効くリアルタイム用途
Reasoning mode	検出した ungrounded な部分について詳しい説明を返す	開発とデバッグ、原因の把握

さらに、検出の感度を調整するための軸が2つ用意されている。

• ドメイン＝Medical（医療・科学など正確さが決定的な内容向け）と Generic（カスタマーサポートや業務文書など一般向け）。
• タスク＝Summarization（生成した要約を原文と突き合わせる）と QnA（質問への回答をナレッジベースと突き合わせる）。
• 訂正機能（プレビュー）＝ungrounded な内容を検出するだけでなく、グラウンディング元に基づいて自動で直す。

公式が挙げる用途のひとつに、教育分野のQnAがある。

「Educational QnA」として、学業上の質問や試験対策の問い合わせへの回答が事実として正確かを確認し、学習を支えると書かれている。

⇒ 英語学習のQ&Aは、公式が想定している検査対象の中に入っているということだ。

ただし注意すべき点がある。検出の基準はあくまで「グラウンディング元の資料」であって、世界の真実ではない。

渡した資料が古ければ、その古さに忠実な答えが「grounded」と判定されうる。

ハルシネーションを前提にした使い方｜学習者側でできること

ここまでの仕組みは、ほぼすべて開発者側の話だ。

では利用者側に何ができるかというと、公式ドキュメントの設計思想をそのまま真似ることになる。

Safety best practices は、入出力の範囲を狭めること、特に信頼できる情報源から引くことで、アプリ内で起こりうる問題の幅が狭まると書いている。

同じページは、可能な場合はバックエンドの検証済み資料から返すほうが、新しく生成した内容を返すより安全だとも述べている。

公式の考え方	学習者側での置き換え
信頼できる情報源に範囲を狭める	自分で辞書やコーパスの本文を貼ってから聞く
検証済み資料から返す	「この文の範囲で説明して」と資料を限定する
出典リンクで監査可能にする	出典が出る機能を優先して使う
不明なら推測せず聞き返す	曖昧な答えには「どの資料に基づくか」を聞き返す
限界を理解し期待を調整する	事実の確認は別の手段で取る前提で使う

⇒ AI英会話は「話す練習の相手」としては強く、「事実の出典」としては弱い、と役割を分けて使うのが仕組みに合っている。

Safety best practices が、問題を報告する手段を用意し、それを人間が監視すべきだと書いているのも同じ発想だ。

最後の検算を人間が持つ、という線は、公式ドキュメントの側から引かれている。

ハルシネーションについてのよくある質問

Q. ハルシネーションは新しいモデルになれば無くなるのか。 A. 公式ドキュメントは、無くなるものとしてではなく、グラウンディング・ガードレール・承認・検出といった周辺の仕組みで減らす対象として扱っている。本記事で確認した一次ソース6本を検索した範囲では、無くなると書いた記述は0件だった。

Q. 出典リンクが出れば信用していいのか。 A. グーグルはグラウンディングの利点として「出典へのリンクによる監査可能性」を挙げている。リンクは確かめる手段であって、正しさの保証ではない。リンク先を開いて確かめて初めて検算になる（出典）。

Q. 同じことを2回聞いて答えが揃えば正しいのか。 A. 揃わないほうが普通だ。公式が生成を non-deterministic と書いている。揃ったことは、正しさの根拠にはならない。

Q. 「分からないときは分からないと言って」と頼めば止まるか。 A. 方向としては公式の条文と同じだ。ただし同じガイドが「Prompts do not guarantee exact capture.」と書いており、指示だけでは保証されない。

Q. 英文法の指摘と、英語にまつわる事実の説明は、同じ危なさか。 A. 危なさの種類が違う。文法の形は他の教材と照合できるが、「どの地域で古い言い方か」のような説明は照合先を自分で持たないと検証できない。後者のほうが確かめにくい。

Q. ハルシネーションを機械で判定する方法はあるのか。 A. ある。マイクロソフトはグラウンデッドネス検出として製品化しており、grounded／ungrounded の2値を返す高速モードと、理由を説明するモードの2つを用意している（出典）。ただし判定の基準は渡した資料であって、世界の真実ではない。

まとめ｜ハルシネーションは止めるものではなく、囲うものだ

もう一度整理する。

• ハルシネーションの定義は公式で2軸ある。事実でない内容の生成（Google）と、渡した資料と合わない出力（Microsoft）だ。
• 起きやすいのは学習データの外側。知識は学習時点の公開データに限られると公式が明記している。
• 抑え方の柱はグラウンディング（RAG）。出力を検証可能な情報源につなぎ、出典リンクで監査できるようにする。
• もうひとつの柱がガードレールと人間の承認。入力側・出力側・ツール側で走る範囲が違うので、副作用の隣に検証を置くのが公式の結論だ。
• 音声では「推測するな・聞き返せ」という条文で抑えるが、公式自身がプロンプトでは保証されないと書いている。

⇒ AI英会話でハルシネーションが出たとき、責めるべきはモデルの賢さではなく、そのサービスが周りに何を足したかだ。

出典が出るか、資料を限定できるか、あやふやなときに聞き返してくるか。この3点は、外から見て分かる手がかりになる。

そして最後の検算を人間が持つという設計思想は、公式ドキュメントの側から書かれているものだ。

※本記事の一次ソースはすべて2026-09-16に各公式ドキュメントで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。