ハルシネーションとは？LLMが誤る原因と誤回答を減らす実装

サポートボットが規約にない例外を作ってはいけません。レポート作成アシスタントが合計値をでっち上げてもいけません。モデルを使って行動を選び、ツールを呼び出すソフトウェアであるエージェントも、変更すべき顧客レコードを推測で選んではいけません。実装上の目標は、根拠のない回答や操作をアプリケーションの外に出さないことです。

2026年10月17日に検証済みです。 リンク先のモデル開発元のガイダンス、APIドキュメント、研究事例、裁判記録と照合しています。以下の事例は出典のある観察結果です。検証コードと週間チェックリストは実装上の提案であり、本番運用の実績ではありません。

ハルシネーションとは？LLMで起きる理由

LLMのハルシネーションとは、誤った内容や根拠のない内容が、回答としてもっともらしく生成されることです。LLMは大規模言語モデルの略で、テキストに含まれるパターンから言語を生成するように学習したモデルを指します。別の場面では正しい内容でも、与えた文書に裏づけがなければ、その文書に基づく回答としては根拠を欠いています。

モデルは、机の上の資料をもとに説明文を仕上げる、腕のよい書き手だと考えてみてください。欠けている段落を、説得力のある文章で補うことはできます。しかし、その段落の内容が自社の記録に含まれるべき事実だとは限りません。

もっともらしい文章の予測は、事実確認とは別の処理です

2025年9月5日に公開されたOpenAIの言語モデルがハルシネーションを起こす理由についての研究記事では、事前学習は個々の記述に真偽のラベルが付いていない状態で、テキストを予測することを学ぶと説明されています。出現頻度が低く、規則性のない事実は、パターンから復元するのが特に困難です。その後の学習で振る舞いは改善されますが、流暢さが正確さの保証に変わるわけではありません。

開発者が取るべき方針は明確です。製品の規約、アカウントの状態、在庫情報は、アプリケーションが読み取れる正式な情報源で管理します。モデルが記憶している回答をデータベース代わりにすると、避けられるはずの失敗を招きます。

情報の不足や古さが、回答の穴を生みます

顧客が必要とする事実を、モデルが一度も受け取っていない場合があります。アップロードした文書が古い、検索で別の製品エディションの資料が取得される、アカウント情報の照会に失敗するといったことも起こります。AnthropicのClaudeが誤った回答をする理由の説明でも、最新情報の欠落が混乱の原因として明記されています。

ここでは、2つの失敗を分けて考える必要があります。アシスタントが架空の規約を作ったなら、生成の失敗です。失効した規約を正確に繰り返したなら、情報源の管理の失敗です。顧客に誤った回答が届く点は同じでも、プロンプトを変えるだけでは、古い文書も壊れたアカウント照会も直せません。

「必ず答える」という圧力が、推測を促します

OpenAIは、正答率だけで評価すると、不確かさを認めるよりも推測するほうが報われる場合があると指摘しています。回答を完了すればすべて成功、人への引き継ぎはすべて失敗と数える指標では、自社でも同じ問題を起こしかねません。

確実な配達日を知りたい顧客に必要なのは、正式な配送予定情報です。配送業者がまだ予定を提示していなければ、何の情報が不足しているかを具体的に説明することが、有用な結果になります。テストでも運用ダッシュボードでも、その結果を適切に評価しましょう。

ハルシネーションの事例：検出すべき4つの誤り

アプリケーションで何を検証すべきかに沿って、失敗を分類します。分類には重なりもありますが、小規模なチームでも、どこに検証を加えるべきかが具体的になります。

事実の捏造： 博士論文の例は、OpenAI自身の研究報告に記載されています。人名を知っていても、欠けている論文タイトルを正しく補えるとは限りません。業務に置き換えれば、似た製品に備わっているという理由で、自社製品にもその機能があると作り上げるようなものです。

数値の誤り： 同じ報告にある誕生日の例は、精密に見える日付でも根拠にはならないことを示しています。アプリケーションでは、根拠のない数値と計算ミスを区別してください。数量は記録から取得し、合計は通常のコードで計算します。モデルには、その計算結果を受け取って説明させます。

架空の引用： United States v. Cohenの2024年3月20日付意見書には、当時Google Bardという名称だったGoogleの生成AIアシスタントから、実在しない3件の判例が得られた経緯が記されています。そのうちの1件は、United States v. Figueroa-Florezとされていました。事件名や引用の書式がもっともらしくても、実在する法的根拠を指してはいませんでした。

ツール引数の誤り： Berkeley Function Calling Leaderboardの著者らは、指定された利率5%に対してannual_interest_rate: 5を渡した呼び出しと、正しい小数表記である0.05を示しています。どちらの値も数値型です。型の検証だけでは区別できません。これは引数の意味に関する誤りです。ツール呼び出しの誤りがすべて事実の捏造に当たるわけではありませんが、実行前の確認で併せて扱うべき問題です。

ハルシネーション対策：顧客に届く前に誤りを減らすには

生成の前後に、根拠の取得と検証を組み込みます。そのうえで、どちらかが欠けた場合にシステムがどう振る舞うかを決めます。検証の仕組みは開発側、正とする情報源とエスカレーション先は運用側が責任を持ちます。

最新で、質問に合った情報源を使います

検索拡張生成（RAG）は、外部の資料を検索し、関連する箇所をモデルに渡す手法です。書き手に、執筆の根拠となる資料を渡す役割を果たします。AnthropicのContextual Retrievalの解説では、検索した文章の文脈を保つ重要性が示されています。抜粋だけでは、どの企業、期間、対象について述べているのかが抜け落ちる場合があるためです。

サポート機能では、正式な規約をまとめた資料群を定め、製品、地域、適用開始日、アクセス権限のメタデータを付けます。生成前にそれらの項目で絞り込んでください。キャンセル規定は例外条件と一緒に取得します。条件から切り離された段落を根拠にすると、誤った約束につながるおそれがあります。

アカウントの現在の状態は、アプリケーションのデータベースやサービスから取得します。この顧客の注文が発送済みかどうかは、文書検索で代用するのに適した情報ではありません。照会に失敗した場合は、一般知識で黙って穴埋めせず、情報を取得できない状態として返します。

まずはシンプルな検索フローから始めましょう。複数の情報源をまたいで追加検索が必要な質問には、モデルが次の検索手順を選べるエージェンティックRAGを使います。追加検索にも停止条件と同じ情報源の検証が必要です。

原因を切り分けるうえで役立つのは、正しい根拠がモデルに届いていたかどうかです。回答と一緒に情報源のIDとバージョンを保存し、検索での取りこぼしなのか、生成時に根拠のない内容を付け足したのかを、運用担当者が見分けられるようにします。

「わからない」をアプリケーションの状態として定義します

Anthropicのハルシネーションを減らすガイドでは、不確かさを認められるようにすること、原文の引用を根拠にすること、出典を示すこと、裏づけのない主張を削ることが推奨されています。この方針を、アプリケーションの応答仕様に落とし込みます。

モデルの応答には、answered、needs_clarification、insufficient_evidenceのような明示的な状態を用意します。答えがないのに必須フィールドを埋めさせ、架空の回答を要求してはいけません。画面上では、それぞれの状態を役立つ案内に変換します。要点を絞った確認質問、不足している記録の説明、取得済みの情報を添えた担当者への引き継ぎなどです。

指示の例は次のとおりです。「与えられた規約とアカウントの記録だけを使用してください。記録から答えを確定できない場合は、不足している情報を示してください。類似事例から適用対象かどうかを推測してはいけません。」答えやすい質問だけでなく、根拠が欠けている状況でもこの指示をテストします。

答えがわからない状態は、安全上の理由による拒否、ツールのタイムアウト、権限のない要求とは別です。適切な担当者が対処できるよう、ログでも区別してください。

引用をコードで検証できる形にします

引用は、アプリケーションがすでに把握している根拠を指すようにします。検索時に情報源のIDを割り当て、サーバー側でそのIDを承認済みURLに対応づけます。モデルの記憶から参考文献一覧やリンク先URLを作らせることは避けてください。

検証する観点は、次の3つに分けます。

• 実在性： 引用した情報源のIDが、このリクエストに渡した、利用権限のある資料に含まれていること。
• 引用の正確さ： 回答に使用したものと同じバージョンの情報源に、引用文が実際に存在すること。
• 主張の裏づけ： その箇所が、この顧客の状況における主張の根拠になっていること。

最初の2つは、比較的単純なコードで検証できます。最後の観点には、業務ルール、信頼できる構造化フィールド、または主張と根拠の対応を確認する別のレビューが必要です。文書の中に「対象」という語があるだけでは、特定の顧客が対象になるとは証明できません。

Anthropicの引用機能のドキュメントでは、根拠の位置を確認しやすくする、文書と紐づいた引用が説明されています。情報源をたどれると回答の監査に役立ちますが、その情報源が最新か、正式なものか、正しく解釈されているかまでは確定しません。

構造化出力を使い、値そのものも検証します

構造化出力は、使用できるフィールドと値の型を定義したスキーマに、応答を従わせる仕組みです。アプリケーションでの検証を実装しやすくなります。ただし、OpenAIのStructured Outputsガイドは、出力には依然として誤りが含まれうることを明示しています。また、応答仕様に適切な代替処理がなければ、想定に合わない入力がハルシネーションを引き起こす可能性も警告しています。

ツール呼び出しでは、実行前に操作内容、必須引数、単位、許容値、レコードの実在、呼び出し元の権限を検証します。テナントと認証済みユーザーの特定は、アプリケーションのコードで行います。必要に応じて、アクセスを許可されたレコードの中からモデルに選ばせることはできます。しかし、モデルが提示した顧客IDを、アクセス権限の証拠として扱ってはいけません。

ツール呼び出しが成功した場合も、顧客には結果を正確に伝える必要があります。ツールが保留状態やエラーを返したのに、キャンセルが完了したと伝えてはいけません。最終メッセージは、ツールが返したステータスを正として作成します。操作を制限する仕組み全般については、当サイトのAIエージェントのガードレール実装ガイドで解説しています。

ハルシネーションの検出：実行できる検証コード

対象を限定した事実フィールドなら、モデルが提案した値を承認済みの記録と照合し、回答文はアプリケーション側で組み立てます。そのフィールドについては、自由文が一貫しているように見えるかを確認するよりも、強い保証を得られます。

以下のPythonコードで使うのは、説明用のサポート規約テストデータであり、実際の業務規約ではありません。verify_answer.pyとして保存し、python3 verify_answer.pyで実行してください。標準ライブラリだけを使用し、APIは呼び出しません。

# Records must be filtered for the caller's access and policy scope
# before reaching this function. These are illustrative fixtures.
records = {
    "support-policy": {
        "text": "The support channel for this workspace is email.",
        "current": True,
        "fields": {"support_channel": "email"},
    }
}


def validate(result, sources):
    keys = {"status", "field", "value", "source_id", "quote"}
    if not isinstance(result, dict) or set(result) != keys:
        return False
    if result["field"] != "support_channel":
        return False
    if result["status"] == "unknown":
        return all(result[k] is None
                   for k in ("value", "source_id", "quote"))
    if result["status"] != "answered":
        return False
    if not all(isinstance(result[k], str)
               for k in ("value", "source_id", "quote")):
        return False
    source = sources.get(result["source_id"])
    if source is None or source["current"] is not True:
        return False
    quote = result["quote"].strip()
    return (
        bool(quote)
        and quote in source["text"]
        and result["value"]
        == source["fields"].get(result["field"])
    )


proposal = {
    "status": "answered",
    "field": "support_channel",
    "value": "chat",
    "source_id": "support-policy",
    "quote": "The support channel for this workspace is email.",
}

if not validate(proposal, records):
    print("Hold: evidence or value check failed.")
elif proposal["status"] == "unknown":
    print("I cannot confirm the support channel from these records.")
else:
    print(f"Your support channel is {proposal['value']}.")

提案された回答がchatの場合、引用文が本物でも検証に失敗します。値がemailであれば、この限定的な検証には通ります。回答を確定する根拠は信頼できるフィールドであり、引用文の一致だけではありません。

この検証の限界も押さえてください。 このコードでは、自由形式の説明が真実か、規約の管理責任者が正しい事実を入力したか、前段のアクセス権限フィルターが機能したかは確認できません。unknownの分岐で検証するのは、許可された応答形式に従っているかどうかであり、本当に回答を控える必要があったかどうかではありません。それらは別の検証と評価テストで扱います。影響の大きい定型的な事実は、信頼できるデータをテンプレートに埋め込めば、生成そのものが不要になる場合もあります。

正しい回答と、適切な回答保留を評価するテスト

評価テスト（eval）とは、期待する振る舞いに照らしてアプリケーションを繰り返し検証するものです。顧客に影響する失敗を軸に設計し、モデル、プロンプト、検索インデックス、ツールのスキーマ、規約を変更したときに実行します。

結果は、根拠のある正答、根拠のない回答、適切な回答保留、不要な回答保留、不正な操作の提案に分けて記録します。平均値だけを見ると、改善が根拠の質を高めた結果なのか、単に回答を断る回数が増えた結果なのかがわかりません。

値の完全一致、情報源が対象資料に含まれるか、必須フィールド、権限、ツールの結果は、通常のコードで検証します。ある箇所が言い換えた主張を裏づけるかなど、言語の解釈が必要な評価にはモデルを使い、人が確認した事例で判定の基準を調整します。LLMを評価者にする手法で使うモデルも誤ることがあり、独立した事実の情報源にはなりません。

Promptfooは評価ツールで、モデルで判定するアサーションには、参照回答に照らした事実の正確さと、与えたコンテキストへの忠実さを評価するものがあります。この区別は有用です。回答が古い文書と一致していても、現時点では誤りという場合があるためです。合格の条件を定義したら、Promptfooのガイドを参考にテスト環境を構築してください。

各テストのトレースには、リクエスト、取得した根拠、提案された引数、実行したツールの結果、最終回答をまとめて残します。失敗したとき、その記録から修正箇所を特定できます。文章に対するモデルの評価が高くても、引用の欠落や不正な引数は明確に不合格とします。

ハルシネーション対策で過信しやすいこと

RAGを使っても、すべての回答が正しくなるわけではありません。 有用な文章を取得しても読み違えることはありますし、古い文章を正確に引用してしまうこともあります。検索と生成は別々にテストし、情報源の管理責任者を決めてください。

コンテキストウィンドウが大きくても、情報源の選別は必要です。 Anthropicのコンテキストエンジニアリングのガイダンスでは、コンテキストが増えると、情報の想起能力や精度が低下する場合があると警告しています。関連する規則、その例外、必要なアカウント情報を含めましょう。すべての文書をプロンプトに詰め込むだけでは、情報を最新に保つ方針にはなりません。

別のモデルが「正しそうだ」と答えるだけでは、検証は成立しません。 レビューする側に、実際の根拠と明確な判定基準を渡します。独立した根拠がないまま意見が一致しても、裏づけのない同じ前提を引き継いでいる可能性があります。

正しい形式のJSONでも、内容の正確さは保証されません。 スキーマによって情報源IDや数値の引数を必須にすることはできます。それでも、その情報源が存在するか、数値の意味が正しいかは、アプリケーションで確かめる必要があります。

把握すべき限界は、手元の情報源では答えられない質問、検証できないフィールド、安全に取り消せない操作です。どの業務フローにも一律に当てはまり、本番投入の可否を判断できるハルシネーション率はありません。

小規模チームが今週から取り組めるチェックリスト

機能が顧客に事実に基づく約束をしたり、業務レコードを変更したりするなら、すぐに対策に着手しましょう。一方、資料の下書きを作るだけで、責任者がすでに情報源と照合して確認しているなら、まず評価用のケースを整え、そのレビューを改善してから複雑な自動化の仕組みを検討します。確定的な照会処理ですでに正式な値を返せるのであれば、モデル自体が不要な場合もあります。

以下は着手するための提案です。1週間の作業で本番運用の信頼性が確立することを示すものではありません。

月曜日の最初の一手は、最近の誤回答を1件取り上げ、処理のトレース全体を保存することです。根拠がなかったのか、古かったのか、読み違えたのか、根拠を使わずに処理が進んだのかを特定します。その失敗を検出できる最小限の検証を加え、恒久的な回帰テストのケースにしてください。

LLMのハルシネーションに関するよくある質問

信頼できるAIワークフローを構築するための実践ガイドは、ニュースレターに登録してお受け取りください。