生成AIは、知らないことを知らないと言わずに、もっともらしく答えることがある。存在しない判例、ありもしない社内規程、数字の合わない集計。これがハルシネーションだ。
実際に、業務上の損害になった例もある。2023年6月22日、ニューヨークの連邦地裁のP. Kevin Castel判事は、ChatGPTが作った架空の判例を引用した書面を出した弁護士らの法律事務所に5,000ドルの制裁金を科した。書面には、実在しない判決が6件含まれていた。カナダでは2024年、Air Canadaのチャットボットが運賃の払い戻しについて規程と違う案内をした件で、紛争解決の審判所が航空会社の責任を認めた。チャットボットは別の存在だという会社の主張は退けられ、審判所は、Air Canadaは自社サイト上のすべての情報に責任を負うと述べた。
ここでは、ハルシネーションがなぜ起きるのかを押さえたうえで、業務で使えるAIにするための設計と運用の打ち手を整理する。AIを本番に持っていく全体の進め方はAIのPoC止まりを抜け出すに、現場に入ってAIを実装する職種についてはFDEとは？に書いた。
ハルシネーションとは
米国の国立標準技術研究所（NIST）は、2024年7月に公開した生成AIのリスク管理の文書「NIST AI 600-1」で、この現象を「作話（confabulation）」と呼んでいる。生成AIが、誤った内容や事実と違う内容を自信を持って示す現象で、入力から外れた出力や、同じ会話の中で前の発言と矛盾する出力も含む。俗に「ハルシネーション」と呼ばれているもの、という位置づけだ。
NISTの文書は、危険の中心を、誤りそのものより、利用者がそれを信じて行動してしまうことに置いている。答えの口調に自信があるほど、人は疑わなくなる。さらに、生成AIはもっともらしい理由づけや出典まで付けることがあり、それが人をいっそう信じ込ませる。
業務で問題になるハルシネーションは、私の見方では3つの形に分けられる。
| 形 | 例 | 気づきやすさ |
|---|---|---|
| 存在しないものを作る | 架空の判例、存在しない論文、ない製品の型番 | 調べれば分かるが、調べないと気づかない |
| 実在するものを取り違える | 別の会社の数字、古い版の規程、似た名前の人の経歴 | 実在するぶん、気づきにくい |
| 根拠から外れて補う | 渡した文書に書いていないことを、書いてあるかのように答える | 文書を読み直さないと気づかない |
ハルシネーションの原因
原因1：次の言葉を予測する仕組みそのもの
NISTの文書は、作話は生成モデルの作られ方から自然に生じる結果だと説明している。生成AIは、学習データの統計的な分布に近い出力を作るように作られ、たとえばLLMは文の次に来る言葉を予測する。この予測は正確で一貫した出力も生むが、事実と違う出力や内部で矛盾する出力も生みうる。NISTは、長い文章を自由に書かせる場面や、高度に文脈や専門知識に依存する分野で、とくにこの傾向が問題になるとしている。
原因2：わからないと言うより、当て推量が得をする
2025年9月4日、OpenAIの研究者らは論文「Why Language Models Hallucinate」を公開した。論文は、学習と評価の仕組みが、わからないと認めることより当て推量を評価しているために、言語モデルはハルシネーションを起こすと論じている。
たとえとして使われているのは、試験を受ける学生だ。正解に1点、空欄や「わからない」に0点という採点では、自信がなくても何か書いたほうが点が上がる。論文によると、言語モデルの主要な評価の多くもこうした正誤の2択で採点されており、モデルはいつも「試験を受けている」状態に置かれている。論文は、評価の側で、自信がないときに答えを控えることを罰しない採点に変える必要があると提案している。
この指摘は、AIを業務に入れる側にもそのまま当てはまる。社内で精度を測るときに「正しく答えた割合」だけを見ると、わからないときに黙るAIより、当てずっぽうで答えるAIのほうが良く見えてしまう。
原因3：業務の側にある原因
モデルの外にも原因はある。私の見方では、業務でのハルシネーションの多くは、次の3つのどれかから始まる。
- 答えに要る情報を渡していない。社内の規程や最新の数字を渡さずに聞けば、モデルは学習した記憶から答えるしかない
- 渡した情報が古い、または矛盾している。旧版と新版の規程が両方入っていれば、どちらで答えるかは運になる
- 質問の範囲が広すぎる。「この契約で問題になりそうな点は」のような開いた問いは、根拠のない補完を招く
ハルシネーション対策：設計で減らす5つの打ち手
ハルシネーションをゼロにする方法は今のところない。だから、出にくくする設計と、出ても気づける設計を重ねる。
| 打ち手 | 中身 | 効く原因 |
|---|---|---|
| 1. 根拠の文書を渡す | 社内文書やデータベースから関係する部分を探して、質問と一緒に渡す（RAG） | 原因1、原因3の1 |
| 2. わからないと言わせる | 根拠に答えがないときは「わからない」と返すよう指示し、その答えを正しい振る舞いとして評価する | 原因2 |
| 3. 出典を示させ、機械で確かめる | 答えに使った文書と箇所を返させ、その文書が実在し、引用した文が本当にそこにあるかをプログラムで照合する | 原因1、原因3の2 |
| 4. 問いと答えの形を絞る | 自由な文章ではなく、決まった項目や選択肢で答えさせ、形が合わない答えははじく | 原因3の3 |
| 5. 元データを整える | 古い版の文書を外し、どの文書が正本かを決めてから検索の対象にする | 原因3の2 |
1つ目の根拠を渡す方法は、2020年にPatrick Lewisらが示した「Retrieval-Augmented Generation（RAG）」が元になっている。論文は、外部の文書を検索して生成に使うことで、記憶だけに頼るモデルより、具体的で事実に沿った出力になったと報告した。ただし、RAGを入れてもハルシネーションは消えない。検索が外れた文書を拾えば答えも外れるし、文書に答えがないときに、それらしく埋めることもある。だから2つ目と3つ目を組み合わせる。
3つ目は、私がいちばん効くと考えている打ち手だ。存在しない判例も、ない社内規程も、「その出典は実在するか」「その文は出典に本当にあるか」を機械で照合すれば止められる。人がすべての出典を開いて確かめるのは続かないが、プログラムなら全件を確かめられる。
運用で抑える：誤りの重さで、人の確認を分ける
設計でどれだけ減らしても、誤りは残る。残る誤りをどこで止めるかを、用途ごとに決める。私は、誤りが出たときの影響で3段階に分けることを勧めている。
| 段階 | 用途の例 | 人の確認 |
|---|---|---|
| 軽い | 社内の下書き、議事録の要約、アイデア出し | 使う人が読んで直す。確認の記録は要らない |
| 中くらい | 社内の問い合わせへの回答、社内向けの資料、検索の補助 | 出典を常に示す。誤りの報告を受け付け、定期的に抜き取りで確かめる |
| 重い | 顧客や取引先に出る文章、契約・法務・医療・お金に関わる判断 | 出典を確かめたうえで担当者が確認してから使う。確認した人を記録する |
Air Canadaの件が示したのは、顧客に向けたAIの答えは、会社の答えとして扱われうるということだ。顧客に直接答えるAIは、少なくとも「重い」の段階で設計する。
運用では、次の3つも決めておく。
- 誤りを集める窓口。使う人が「この答えは違う」と報告できる仕組みを作り、報告された誤りを試験用の問題として貯める
- 測り方。正答率だけでなく、誤答率と「わからない」と答えた率を分けて測る。わからないと答える率が少し上がっても、誤答率が下がるなら良い変化と見る
- 見直しの間隔。元の文書やモデルを変えたら、貯めた問題でもう一度試す
AIの成果を何の数字で測るかはKPI設計から始めるAI導入で、人とAIの仕事の分け方はAI×人間の業務ワークフロー設計術で扱った。
導入前のチェックリスト
業務にAIを入れる前に、次の7項目を確かめる。
- 用途ごとに、誤りが出たときの影響を「軽い・中くらい・重い」で決めたか
- 答えに要る社内の情報を、AIに渡す仕組みがあるか
- 渡す文書から古い版を外し、正本を決めたか
- 根拠がないときに「わからない」と答えるよう設計し、それを正しい振る舞いとして扱っているか
- 答えに出典が付き、その出典を機械で照合しているか
- 「重い」用途に、担当者の確認と記録があるか
- 誤りを報告する窓口と、貯めた誤りで再試験する仕組みがあるか
ハルシネーションは、AIの性能が上がれば自然に消える問題ではなく、業務の側で受け止める設計が要る問題だと私は考えている。どの業務にどの深さの確認を置くかを決め、実装し、運用に乗せるところまでを一緒に進めたい場合は、私たちのサービスを見てほしい。