AIが自信満々に嘘をつく問題
ミドリ： タツヤさん、この前ChatGPTに「東京タワーの高さは？」って聞いたら正しく答えたんですけど、ちょっとマイナーな質問をしたら完全にデタラメを返してきて……。しかもめちゃくちゃ自信満々に。
タツヤ： 典型的なハルシネーションだね。LLMは「次に来る確率が高いトークンを予測する」仕組みだから、知らないことでも文法的に正しい文章を生成できてしまう。
ミドリ(thinking)： つまり「知らない」って言えないんですか？
タツヤ： 正確に言うと、LLMには「知っている」「知らない」の区別がない。学習データにあったパターンを基に、もっともらしい文章を組み立ててるだけ。だから存在しない論文を引用したり、架空の法律を解説したりする。
ミドリ： 社内でAIを業務に使おうとしてるんですけど、それだとまずいですよね？
タツヤ(nodding)： まずい。特に法務・医療・金融の領域でハルシネーションが起きると、下手すれば損害賠償レベルの問題になる。でも安心して。実践的な対策を7つ組み合わせれば、ハルシネーション率は99%削減できる。
ハルシネーションが起きる4つの原因
ミドリ(thinking)： 対策の前に、なぜ起きるのかを知りたいです。
タツヤ： 大きく4つの原因がある。
| 原因 | 説明 | 具体例 |
|---|---|---|
| 学習データの限界 | カットオフ日以降の情報を知らない | 「2026年のノーベル賞受賞者は？」→架空の人物を回答 |
| 知識の欠落 | マイナーな情報は学習データに含まれない | 「X社の2025年Q3の売上は？」→もっともらしい数字を捏造 |
| 文脈の混同 | 複数の情報を混ぜてしまう | AさんとBさんの経歴を混同 |
| 指示の曖昧さ | プロンプトが不明確だと推測で補う | 「最新の情報を教えて」→古い情報を「最新」として回答 |
ミドリ： 全部「本当は知らないのに、パターンで埋める」ってことですね。
タツヤ： そう。だから対策の基本は「LLMが推測で埋めなくていい状況を作る」こと。順番に7つのテクニックを見ていこう。
テクニック1：RAG（検索拡張生成）
ミドリ： RAGって最近よく聞きますけど、何ですか？
タツヤ： Retrieval-Augmented Generationの略。LLMが回答を生成する前に、外部のデータベースから関連情報を検索して、その情報をプロンプトに含める仕組みだ。
ミドリ(thinking)： つまりカンニングペーパーを渡してあげるってこと？
タツヤ： いい例えだね。LLMが「知ってる知識」で答えるんじゃなくて、「今渡された資料」を基に答える。これだけでハルシネーション率が70〜80%減るというデータがある。
タツヤ： 実装のポイントは3つ。
- チャンク分割の最適化 — ドキュメントを500〜1,000トークン程度に分割。大きすぎるとノイズが増え、小さすぎると文脈が失われる
- ベクトル検索の精度 — 埋め込みモデルの選定が重要。日本語ならmultilingual-e5-largeやCohere Embed v3が好成績
- リランキング — 検索結果を関連度で並び替えて、上位3〜5件だけをLLMに渡す
ミドリ： RAGだけで70%減るなら、これが最優先ですね。
テクニック2：Grounding（事実に基づく制約）
タツヤ： RAGで情報を渡した上で、「渡した情報の範囲内だけで回答しろ」と明示的に指示する。これがGrounding。
あなたは以下の資料のみを参照して回答してください。
資料に記載されていない情報については
「この情報は資料に含まれていません」と回答してください。
推測や一般知識に基づく回答は禁止です。
【参考資料】
{retrieved_documents}ミドリ： 「知らないなら知らないと言え」って指示するわけですね。
タツヤ： そう。これだけで「なんとなくもっともらしい回答を生成する」パターンが大幅に減る。RAGとセットで使うのが基本。
テクニック3：Citation（出典明示）
ミドリ： 回答の根拠を示させるってことですか？
タツヤ(nodding)： その通り。「回答の各ステートメントに対して、参考にした資料の該当箇所を引用してください」と指示する。
タツヤ： 効果は2つある。
- ユーザーが検証できる — 出典があれば、人間が素早くファクトチェックできる
- LLMの精度が上がる — 出典を求められると、LLMは根拠のない回答を生成しにくくなる。一種のセルフチェック効果がある
ミドリ： 出典を求めるだけで精度が上がるって面白いですね。
タツヤ： 実際、Citationを要求するだけでハルシネーション率が30〜40%減少するという研究がある。コストゼロで効果がある対策だ。
テクニック4：Temperature調整
ミドリ(thinking)： Temperatureって何ですか？
タツヤ： LLMの出力のランダム性を制御するパラメータ。0に近いほど確定的（毎回同じ回答）、1に近いほど創造的（毎回違う回答）になる。
| Temperature | 用途 | ハルシネーションリスク |
|---|---|---|
| 0.0 | ファクトチェック、データ抽出 | 最低 |
| 0.3 | ビジネス文書、Q&A | 低い |
| 0.7 | 記事作成、ブレスト | 中程度 |
| 1.0 | 創作、アイデア出し | 高い |
ミドリ： 事実を答えてほしいときはTemperature低め、ってことですね。
タツヤ： そう。社内ナレッジQ&AならTemperature 0〜0.2で十分。これだけで「創造的に嘘をつく」パターンが消える。
テクニック5：Self-Consistency Check
ミドリ： セルフコンシステンシーチェック？ 難しそうな名前ですね。
タツヤ： やってることはシンプル。同じ質問をLLMに複数回投げて、回答が一致するか確認する方法。
ミドリ： 3回聞いて、3回とも同じ答えなら正しい可能性が高い、と。
タツヤ： まさにそれ。実装例を見せよう。
import collections
def self_consistency_check(question, n=5, threshold=0.6):
answers = []
for _ in range(n):
response = call_llm(question, temperature=0.7)
answers.append(extract_answer(response))
# 最も多い回答を選択
counter = collections.Counter(answers)
most_common, count = counter.most_common(1)[0]
if count / n >= threshold:
return most_common, count / n # 回答と信頼度
else:
return "回答にばらつきがあります。人間の確認が必要です。", 0ミドリ： APIコストが5倍になりませんか？
タツヤ： なる。だから全リクエストには使わない。「重要度の高い回答」や「ユーザーが確認を求めたとき」に限定して使うのが現実的。
テクニック6：Chain-of-Verification（検証連鎖）
ミドリ： これは何ですか？
タツヤ： Meta（旧Facebook）が2023年に発表した手法。LLM自身に「自分の回答を検証する質問」を作らせて、それに答えさせることで矛盾を検出する。
タツヤ： 流れはこう。
- LLMが回答を生成する
- LLMに「この回答を検証するための質問を3つ作って」と指示
- 各検証質問にLLMが回答する
- 元の回答と検証回答に矛盾がないか確認する
- 矛盾があれば回答を修正する
ミドリ： AIにセルフツッコミさせるわけですか。
タツヤ： うまい表現だね。この手法でハルシネーション率が最大50%改善したという報告がある。特に事実関係の誤りに強い。
テクニック7：Human-in-the-Loop（人間による確認）
ミドリ： 最後は人間の確認ですか。結局そこに戻るんですね。
タツヤ： ゼロリスクを目指すなら必須。ただし「全部人間が確認する」だと効率化の意味がない。ポイントはリスクベースで確認レベルを分けること。
| リスクレベル | 確認方法 | 例 |
|---|---|---|
| 高（法的・金銭的影響） | 専門家レビュー必須 | 契約書、医療情報、財務データ |
| 中（業務への影響） | 担当者のスポットチェック | 顧客向けメール、提案書 |
| 低（内部利用） | 自動チェック＋例外時のみ人間確認 | 社内FAQ、議事録要約 |
ミドリ： リスクが低いものまで全部確認してたら時間がいくらあっても足りないですもんね。
タツヤ： そう。自動化の効果を最大化しつつ、致命的なミスだけは確実に防ぐ。このバランスが重要。
7つのテクニックの組み合わせ方
ミドリ： 7つ全部やる必要があるんですか？
タツヤ： 全部やる必要はない。ユースケースによって組み合わせを変える。
| ユースケース | 推奨テクニック | 期待ハルシネーション削減率 |
|---|---|---|
| 社内ナレッジQ&A | RAG + Grounding + Citation + Temperature調整 | 95%以上 |
| カスタマーサポート | RAG + Grounding + Citation + Human-in-the-Loop | 98%以上 |
| レポート・分析 | RAG + Chain-of-Verification + Self-Consistency | 90%以上 |
| コード生成 | Temperature調整 + Self-Consistency + テスト実行 | 85%以上 |
ミドリ： 社内ナレッジQ&Aなら4つの組み合わせで95%以上防げるんですね。
タツヤ： しかもRAG + Grounding + Citation + Temperature調整の4つは、実装コストが比較的低い。まずこの4つから始めて、必要に応じて追加するのがおすすめ。
ハルシネーションの測定方法
ミドリ： 効果を測定するにはどうすればいいですか？
タツヤ： 3つの指標で測る。
- Faithfulness（忠実度） — 回答が参照情報に忠実かどうか。RAGASフレームワークで自動測定できる
- Factual Accuracy（事実正確性） — 回答に含まれる事実の正確率。ゴールドスタンダードとの比較で測定
- Hallucination Rate（幻覚率） — 全回答のうち、事実と異なる情報を含む回答の割合
タツヤ： 具体的なツールだと、RAGAS（RAG評価）、DeepEval（LLM評価全般）、TruLens（トレーシング＋評価）がおすすめ。どれもオープンソースで無料で使える。
ミドリ： 定量的に測れるなら、改善の効果も見えますね。
まとめ：段階的に防御層を積み重ねる
ミドリ： 今日の話をまとめてもらえますか？
タツヤ： ハルシネーション対策の本質は「LLMが推測で埋めなくていい環境を作る」こと。7つのテクニックを段階的に導入して、防御層を積み重ねるのが正しいアプローチだ。
ミドリ： まずはRAG + Grounding + Citation + Temperature調整の4つから始めるんですね。
タツヤ： そう。この4つだけで95%のハルシネーションを防げる。残りの5%を潰すために、ユースケースに応じてSelf-Consistency、Chain-of-Verification、Human-in-the-Loopを追加する。完璧を目指すんじゃなくて、許容リスクに応じた対策を取ることが大事だよ。
ミドリ： AIは万能じゃないけど、正しく使えば十分信頼できるツールになる、ってことですね。
タツヤ(nodding)： その通り。ハルシネーション対策は「AIを使わない理由」を潰す作業でもある。正しい対策を入れて、自信を持ってAIを業務に活用していこう。
次のアクション
自社のAI活用にハルシネーション対策を取り入れましょう。
- 現在のAIシステムで発生しているハルシネーションの事例を収集・分類する
- RAG + Grounding + Citation + Temperature調整の4つを優先的に導入する
- ハルシネーション対策の設計・実装サポートは、Shimanto AI SolutionsのAI品質改善コンサルティングへ