「LLMが平気な顔をして嘘をつく」――この現象は『ハルシネーション』と呼ばれ、LLM導入を検討する企業が最も警戒する問題です。ハルシネーションを完全にゼロにすることは現時点では技術的に困難ですが、発生率を大幅に低減し、業務で安全に活用できる水準まで「管理」することは十分に可能です。本記事では、ハルシネーションが発生するメカニズム、3つの典型パターン、5つの対策手法、そしてユースケースごとのリスク判断フレームワークまでを、実装コード付きで解説します。

ハルシネーションとは何か――LLMが「嘘をつく」メカニズム

ハルシネーションとは、LLMが事実と異なる情報を、まるで真実であるかのような自然な文章で生成してしまう現象のことです。存在しない論文を引用したり、架空の人物を著名な研究者として紹介したり、計算式の途中経過が合っているのに最終結果だけ間違っていたりと、形態は多岐にわたります。

この現象の根源は、LLMの動作原理そのものにあります。LLMは「文脈から最も確率の高い次のトークン」を逐次的に予測して文章を生成する仕組みで、内容が事実かどうかを検証する機構は組み込まれていません。つまり、LLMにとって「もっともらしい文」と「事実として正しい文」は区別されず、学習データに類似のパターンがあれば確率分布上で選ばれてしまうのです。

【LLMの生成とハルシネーションの発生フロー】

ユーザー質問
    |
    v
[文脈理解] --> 学習済みパラメータから類似パターンを検索
    |
    v
[次トークン確率計算] --> 上位候補を確率で選択
    |
    +----> 学習データに正確な情報が存在 --> 正しい回答
    |
    +----> 学習データに情報なし/曖昧
              |
              v
         それっぽい単語を高確率で選択 --> ハルシネーション発生

※LLMは「分からない」を選ぶのが苦手。空白を埋めようとする本能がある。

ハルシネーションの3つのパターン

実務でよく観測されるハルシネーションは、大きく3つのパターンに分類できます。パターンごとに検出難易度と対策が異なるため、まずは自分たちのユースケースでどのパターンが出やすいかを把握することが対策の第一歩です。

  1. 事実の捏造――存在しない論文タイトル、架空の統計値、実在しない人物の発言などを生成するパターンです。「2023年のマッキンゼーの調査によると…」と書かれていても、その調査自体が存在しないケースがあります。
  2. 知識の混同――複数の事実を誤って組み合わせるパターンです。実在する会社AのCEOを会社BのCEOとして紹介したり、似た名前の2つの論文を混ぜて引用したりします。
  3. 推論の飛躍――前提からは導けない結論を生成するパターンです。「AならばBである」と仮定した後に、「したがってCである」と論理的に接続しない結論を出してしまいます。
パターン具体例発生頻度検出難易度リスク度
事実の捏造存在しない論文の引用中中(検索で確認可)高
知識の混同別会社のCEO名を混ぜる中高(部分的に正しい)高
推論の飛躍前提と結論が噛み合わない低〜中中中

ハルシネーション対策の5つの手法

ここからは実務で効果のある対策を5つ紹介します。いずれも単独で完璧ではなく、複数を組み合わせることで相乗効果を発揮します。

  1. RAG(外部知識ソースの参照)――信頼できる社内ドキュメントや最新情報を検索して根拠としてLLMに渡します。最も効果の高い対策で、発生率を一桁削減することも珍しくありません。
  2. プロンプトエンジニアリング――「出典を必ず明示せよ」「不明な場合は『不明』と答えよ」といった指示を明示的に組み込みます。低コストで一定の効果があります。
  3. 出力の検証パイプライン――生成された内容を別途ファクトチェックする仕組みを組み、自動的に危険な回答を弾きます。
  4. Temperature/Top-pの調整――Temperatureを0.2以下に下げることで創造性を抑制し、学習データに忠実な応答に寄せられます。
  5. 複数モデルのクロスチェック――異なるモデルに同じ質問を投げ、回答が一致するかを検証します。コストは倍増しますが、重要な判断には有効です。

出力検証パイプラインの実装例として、LLMに自己検証させるアプローチをご紹介します。同じモデルまたは別モデルに「この回答に事実誤認はないか」を検証させる手法で、LLM-as-Judgeの応用です。

from openai import OpenAI
client = OpenAI()

def verify_answer(question: str, answer: str) -> dict:
    verify_prompt = f"""以下の回答について、事実誤認や根拠のない主張が
含まれているかを厳密に検証してください。形式はJSON。

質問: {question}
回答: {answer}

出力形式: {{"has_hallucination": true/false, "reasons": ["..."]}}"""
    resp = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": verify_prompt}],
        response_format={"type": "json_object"},
    )
    return resp.choices[0].message.content
手法効果実装コスト対応パターン適したユースケース
RAG高中〜高事実捏造・知識混同社内QA、ナレッジ検索
プロンプト工夫中極低全般あらゆるアプリ
出力検証中〜高中事実捏造・推論飛躍重要判断を含む回答
Temperature調整低〜中極低推論飛躍定型タスク
クロスチェック高高(コスト倍)全般医療、金融、法務

ハルシネーションを「許容できる」ユースケースの判断

ハルシネーションのリスクは、ユースケースによって「許容可能」か「致命的」かが大きく異なります。アイデア出し、ブレスト、草稿作成、創作活動といった場面では、むしろ多少の創造性がプラスに働くことすらあります。一方、法律文書の作成、医療診断の補助、金融レポートの数値根拠といった場面では、1件のハルシネーションが企業の信用や人の安全に直結します。

判断に迷ったら「人間のレビューが必ず入るか」「誤りの影響範囲はどこまで広がるか」という2つの問いで判断してください。次のフローチャートが意思決定を助けてくれるはずです。

Q1. 出力は最終成果物として外部に出ますか？
├── No (社内ドラフト) --> リスク低。LLM単独運用OK
└── Yes
     |
     v
Q2. 誤りが人命・金銭・法的責任に直結しますか？
├── Yes --> LLM単独運用NG。RAG+人間レビュー必須
└── No
     |
     v
Q3. 人間のレビュー工数は確保できますか？
├── Yes --> LLM+人間レビューで可
└── No  --> RAG+自動検証パイプラインを必須化

ハルシネーション率の測定方法

対策の効果を定量的に把握するには、ハルシネーション率を測定する仕組みが必要です。基本的な流れは、正解データを含むテストケースを用意し、LLM出力と照合することです。大量のテストケースを人力で確認するのは非現実的なので、LLM-as-Judge方式で自動化するのが実用的です。

import json
from openai import OpenAI
client = OpenAI()

def measure_hallucination_rate(test_cases):
    hits = 0
    for case in test_cases:
        answer = client.chat.completions.create(
            model="gpt-4o-mini",
            messages=[{"role": "user", "content": case["question"]}],
        ).choices[0].message.content
        judge = client.chat.completions.create(
            model="gpt-4o",
            messages=[{"role": "user",
                       "content": f"正解:{case['expected']}\n回答:{answer}\n"
                                  "事実誤認あり=1, なし=0 のみ返答"}],
        ).choices[0].message.content.strip()
        if judge == "1":
            hits += 1
    return hits / len(test_cases)

まとめ――ハルシネーションは「排除」ではなく「管理」する

  • ハルシネーションはLLMの生成原理に由来し、完全排除は現時点では困難
  • 典型パターンは「事実捏造」「知識混同」「推論飛躍」の3種類
  • RAG・プロンプト工夫・出力検証の組み合わせで発生率を大幅削減できる
  • ユースケースごとに許容度を設計し、高リスク領域は人間レビュー必須
  • 対策の効果はLLM-as-Judgeで定量測定し、継続改善する

DE-STKでは、業務ユースケースに応じたハルシネーション対策設計、RAGパイプライン構築、評価自動化まで一貫して支援しています。「どこまで対策すれば安心して本番投入できるのか」の基準づくりからご相談ください。

よくある質問

Q. LLMのハルシネーションとは何ですか?

LLMが事実と異なる情報をもっともらしく生成する現象です。LLMは確率的に次のトークンを予測する仕組みであり、内容の真偽を判断しているわけではないため、存在しない論文の引用や架空の統計データの生成などが起こります。

Q. ハルシネーションを完全になくすことはできますか?

現在の技術では完全な排除は困難です。ただし、RAG(外部知識ソースの参照)、プロンプトの工夫、出力検証パイプラインの構築により、発生率を大幅に低減できます。重要なのは「排除」ではなく「管理」の考え方で、許容可能な水準まで下げる設計を目指すことです。

Q. ハルシネーション対策で最も効果的な方法は何ですか?

RAG(検索拡張生成)が最も効果的な対策の一つです。LLMに外部の正確な情報ソースを参照させることで、事実に基づいた回答を生成させます。加えて、出典の明示を求めるプロンプト設計と、出力の自動検証を組み合わせることで効果が高まります。