ハルシネーションとは何か：発生メカニズムと業務利用での抑え方
ハルシネーションとは、生成AI（LLM：大規模言語モデル）が、事実と異なる内容や根拠のない内容を、もっともらしい文章として出力する現象です。結論から言うと、ハルシネーションは不具合ではなく、LLMの生成の仕組みに由来する性質であり、現状の技術ではゼロにできません。したがって業務で使う際の正しい問いは「どうすれば起きないか」ではなく、「起きても損害が出ない業務設計になっているか」です。
本記事では、定義、発生メカニズム、業務上の影響が大きい場面、抑える手段、そして「ゼロにならない」前提での業務設計を順に整理します。
ハルシネーションの定義：単なる誤りとの違い
通常のソフトウェアの誤りは、バグとして再現・修正できます。ハルシネーションは性質が異なります。
| 観点 | 通常のバグ・入力ミス | ハルシネーション |
|---|---|---|
| 再現性 | 同じ条件で再現することが多い | 同じ質問でも出力が変わることがある |
| 見た目 | 明らかにおかしい結果になりやすい | 文体・構成が自然で、正しく見える |
| 原因 | コードやデータの欠陥 | 確率的な文章生成という仕組みそのもの |
| 対処 | 修正すれば解消 | 低減はできるが、ゼロにはならない |
とくに厄介なのは「確信をもって間違える」点です。人間の担当者であれば「わかりません」「確認します」と言う場面でも、LLMは指示の仕方によっては流暢な回答を作り出します。
ハルシネーションの主な種類
- 事実の誤り：存在しない統計、誤った日付、実在しない人物や企業の情報
- 引用の捏造：実在しない論文・判例・URL・条文番号を、それらしい書式で提示する
- 指示からの逸脱：与えた資料に書かれていない内容を、資料に基づくかのように述べる
- 論理の飛躍：個々の文は正しいが、結論が前提から導けない
発生メカニズム：なぜLLMはもっともらしく間違えるのか
LLMの基本動作は、「これまでの文章の続きとして、次にどの語が来る確率が高いか」を繰り返し予測して文章を組み立てることです。この仕組みから、ハルシネーションが起きる主な原因は3つに整理できます。
原因1：確率的生成――「正しさ」ではなく「もっともらしさ」を出力する
LLMは事実のデータベースを参照して答えているのではなく、学習した言語パターンから続きを生成しています。「もっともらしい文章」と「正しい文章」は多くの場合一致しますが、一致しない場面では、もっともらしい方が出力されます。
原因2：知識の欠落・古さ――知らないことを「知らない」と言いにくい
学習データに含まれない情報（自社の内部資料、直近の出来事、ニッチな専門領域）については、モデルは答えの材料を持っていません。それでも文章の形を整えて出力しようとするため、周辺知識から「それらしい答え」を補完してしまいます。学習データにはカットオフ（知識の締め日）があり、それ以降の情報はそもそも持っていません。
原因3：指示の曖昧さ――質問の側が誤りを誘発する
- 前提が誤っている質問（「〇〇法第XX条の内容を教えて」と、存在しない条文を尋ねる）
- 出力形式だけを厳密に指定し、「わからない場合は不明と書く」という逃げ道を与えない指示
- 長い文脈の中で、重要な条件が埋もれてしまう入力
原因1と2はモデル側の性質ですが、原因3は使う側が改善できる領域です。抑え方の多くはここに集中します。
業務上の影響が大きい場面
ハルシネーションの影響度は、「間違いに気づきにくい」かつ「間違いのコストが大きい」場面で高くなります。
| 場面 | 起きやすい誤り | 影響 |
|---|---|---|
| 数値・計算 | 桁の誤り、存在しない統計、集計の取り違え | 見積・報告資料の信頼性低下、意思決定の誤り |
| 固有名詞 | 実在しない取引先・製品名、人名や肩書の誤り | 顧客対応・営業資料での信用毀損 |
| 法令・規約 | 条文番号や要件の誤り、改正前の内容の提示 | コンプライアンス違反、契約上のトラブル |
| 引用・出典 | 実在しない論文・判例・URLの提示 | 資料の差し戻し、対外発信での訂正対応 |
| 社内ルール・手順 | 存在しない社内規程を「ある」と回答 | 現場の誤運用、問い合わせ対応の混乱 |
逆に、下書き・アイデア出し・要約・言い換えのように、人が内容を確認する前提の用途では、ハルシネーションの実害は小さく抑えられます。リスクは「AIが間違えること」自体より、「確認されないまま外に出ること」にあります。
なお、機密情報や個人情報をAIに入力する際のルールについては、中小企業の生成AI利用ルールの作り方で整理しています。ハルシネーション対策と利用ルールは、セットで設計するのが基本です。
抑える手段：4つのアプローチ
手段1：根拠の提示を求める・与える
- 回答とあわせて根拠となる箇所（資料名・該当部分）を示させる
- 「与えた資料に書かれていないことは『記載なし』と答える」と明示する
- 「わからない場合は推測せず、わからないと答える」を指示に含める
これだけでも、引用の捏造や資料外の補完はかなり減らせます。追加コストがほぼ不要なため、最初に取り組むべき手段です。
手段2：RAGで社内資料・最新情報を参照させる
RAG（Retrieval-Augmented Generation：検索拡張生成）とは、質問に関連する文書を検索して取り出し、その内容を材料としてAIに回答させる方式です。原因2の「知識の欠落・古さ」に直接効きます。
ただしRAGは万能ではありません。検索で関連文書を取り出せなかった場合や、資料自体が古い・矛盾している場合には、RAGを使っても誤った回答が出ます。詳しい判断軸はLLM/AIをプロダクトに組み込む際のアーキテクチャ判断軸で整理しています。
手段3：検証工程を業務フローに組み込む
- 人による確認：数値・固有名詞・法令・引用は、必ず一次情報（原典・社内システム）と突き合わせる
- 二重チェック：重要度の高い成果物は、別の担当者、あるいは別のAIによる検証を挟む
- 確認の記録：誰がどの資料と照合したかを残し、責任の所在を曖昧にしない
「AIが出したものを確認する」作業は、ゼロから作るより速いものの、ゼロにはなりません。確認にかかる工数を含めて、AI導入の効果を見積もる必要があります。
手段4：用途を限定する
すべての業務にAIを使うのではなく、ハルシネーションの影響が小さい用途から始め、影響が大きい用途は段階的に広げます。
| 影響度 | 用途の例 | 運用方針 |
|---|---|---|
| 低 | 議事録の要約、文面の下書き、アイデア出し | 担当者の目視確認で運用 |
| 中 | 社内問い合わせ対応、資料のたたき台作成 | 根拠提示＋RAG＋抜き取り確認 |
| 高 | 対外的な数値報告、法令判断、契約関連 | AIは補助に限定し、専門家・責任者が最終判断 |
「ゼロにはならない」前提での業務設計
ハルシネーション対策の成否は、モデルの性能より業務設計で決まります。経営者・推進担当者が押さえるべき判断基準は次の4点です。
- 誰が最終責任を持つか：AIの出力を採用した人が責任を負う、というルールを明文化する
- どの出力を必ず一次情報と照合するか：数値・固有名詞・法令・引用を「必須確認項目」として定義する
- 誤りを検知したときの経路：現場が誤りを報告し、プロンプトや参照資料の改善につなげる仕組みを持つ
- AIに任せない領域の線引き：判断の影響が大きい領域を、あらかじめ「補助のみ」と決めておく
こうした業務設計は、ツールを入れるだけでは整いません。自社の業務のどこにハルシネーションのリスクが潜んでいるかは、現場の業務を見ながらでないと判断が難しい部分もあります。中小企業のAI活用の全体像と進め方で示したように、まず1業務から小さく導入して運用ルールごと固める進め方が現実的です。社内に判断できる人材がいない場合の選択肢は「社内にAIがわかる人がいない」問題の構造と3つの解決パターンで整理しています。
よくある質問
Q. 最新のモデルを使えばハルシネーションはなくなりますか？
減る傾向はありますが、なくなりません。モデルの性能向上は発生頻度を下げますが、生成の仕組みが変わらない限り、ゼロを前提にした業務設計は引き続き必要です。
Q. RAGを入れれば解決しますか？
社内資料に基づく回答では大きく改善しますが、検索精度や資料の品質に依存します。根拠提示と人による確認の併用が基本です。
Q. どの程度の確認工数を見込むべきですか？
用途の影響度によって異なります。下書き用途は軽い目視確認、対外資料や法令関連は一次情報との照合を必須とする、といった段階的な設計が目安です。
まとめ
- ハルシネーションは、LLMの確率的な生成の仕組みに由来する性質で、ゼロにはならない
- 主な原因は「確率的生成」「知識の欠落・古さ」「指示の曖昧さ」の3つで、使う側が改善できるのは主に指示の設計と参照資料の整備
- 影響が大きいのは、数値・固有名詞・法令・引用のように、間違いに気づきにくくコストが大きい場面
- 抑える手段は、根拠提示・RAG・検証工程・用途の限定の4つで、組み合わせて使う
- 成否を分けるのは、誰が確認し、誰が責任を持つかという業務設計である