ハルシネーションとは？ 10分でわかりやすく解説

UnsplashのAlessio Ferrettiが撮影した写真  

ハルシネーションとは、生成AIが事実に反する内容や根拠のない内容を、もっともらしく出力してしまう現象です。問題は、単なる誤字や計算ミスと違って、見た目だけでは誤りだと気づきにくい点です。

業務で先に押さえたい論点は三つあります。第一に、ハルシネーションは現行の生成AIで起こり得る前提で扱うこと。第二に、医療、法務、金融、セキュリティのように判断ミスの影響が大きい場面では、人手確認を外さないこと。第三に、対策はプロンプト改善だけでなく、根拠提示、外部データとの照合、出力監視、利用ルールを組み合わせて設計することです。

ハルシネーションとは何か

定義

ハルシネーションは、生成AIが誤った内容を自信をもって提示したり、入力内容と整合しない出力を返したりする現象を指します。NISTのGenerative AI Profileでは、この現象を confabulation と呼び、hallucination はその通称として扱っています。

実務上は、「もっともらしいが、裏づけがない」「出典や引用が本当らしく見えるのに実在しない」「同じ対話の中で前後の回答が矛盾する」といった出方をまとめてハルシネーションとして捉えると整理しやすくなります。

単なる誤回答との違い

現れ方

ハルシネーションは、テキスト生成だけに限られません。代表的な現れ方を挙げると次のとおりです。

なぜ起こるのか

生成AIは、外界の事実を直接理解しているのではなく、学習データの統計的な傾向をもとに次の出力を予測します。そのため、問いに対する正解を参照しているのではなく、「もっともらしい続き」を選んだ結果として誤りが生じることがあります。

加えて、次の条件が重なるとハルシネーションは起こりやすくなります。

1. 根拠として参照すべき外部データに接続されていない
   モデル内部の知識だけで答えようとすると、最新情報や固有情報で誤りが出やすくなります。
2. 質問が曖昧で、前提条件が不足している
   対象期間、組織名、文脈が不明確だと、モデルが不足分を補ってしまいます。
3. 領域固有の判断が必要である
   医療、法務、金融、セキュリティなどは、用語の厳密さと例外条件の管理を外しにくい領域です。
4. 不確実でも答えを出すような評価や運用になっている
   「わからない」と返す設計が弱いと、推測のまま回答しやすくなります。

ハルシネーションが危険になる場面

ハルシネーションの影響は、間違った文章が一つ出ること自体より、その出力を人やシステムが信じて次の処理に進んでしまうことです。OWASPでも、誤った内容を権威ある文体で返すことと、それを過信することの組み合わせが大きなリスクとして扱われています。

NISTも、医療のような重大な意思決定に生成AIを組み込む場面では、誤った要約や引用が誤判断につながり得るとして、監視と検証の必要性を明示しています。

ハルシネーション対策の方法

対策の軸は、「発生しにくくする」「発生しても広げない」「見つけたら修正できるようにする」の三段階です。単一の手法で抑え込むより、設計・運用・監視を重ねた方が再現性が高まります。

1. 根拠を持たせる

もっとも効果が出やすいのは、モデルを信頼できる外部データに接続し、回答の根拠を持たせることです。検索連携、RAG、社内ナレッジベース参照、公式ドキュメント限定検索などがここに含まれます。

• 回答に使うデータ源を限定する
• 参照元を表示し、利用者がたどれるようにする
• 最新性が必要な質問では、都度検索やデータ照合を行う

Google Cloudでも、groundingはモデル出力をデータソースに結びつけ、ハルシネーション低減と監査性の向上に役立つ考え方として整理されています。

2. 不確実なときに断定させない

モデルが自信のない場面で推測を続けるほど、ハルシネーションは増えます。そのため、回答不能時の扱いを先に決めておくことが欠かせません。

• 根拠が見つからない場合は「不明」と返す
• 回答条件が欠けている場合は追加情報を求める
• 数値、法令、製品仕様は出典なしで断定しない

評価設計でも、「空欄より推測回答の方が得」という状態を避けた方が、事実性の改善につながります。

3. 出力を検証する

重要業務では、生成AIの出力をそのまま本番処理に流さず、別工程で検証します。NISTのGenAI Profileでも、出力に含まれる出典や引用をレビューし、継続的に監視することが推奨されています。

• 別モデルやルールベースで整合性チェックを行う
• 引用、URL、製品名、条文番号、版数を機械的に照合する
• 人が確認すべき論点をチェックリスト化する

4. 人間の監督を外さない

生成AIを単独の意思決定者として扱うより、下書き作成、候補提示、要約補助のような補助用途に置いた方が事故の範囲を抑えやすくなります。NISTは、評価や運用の文脈で、人による監督の役割と責任分担を明確にするよう求めています。

• 最終承認者を人に固定する
• どの業務はAIに任せ、どこから先は人が判断するかを分ける
• 訂正、差し戻し、エスカレーションの流れを定義する

5. 監視と改善を継続する

導入時の精度が高くても、データ更新、運用変更、利用者層の変化で誤り方は変わります。公開後の監視を置かないと、導入直後には見えなかった失敗が蓄積します。

• 誤回答、ニアミス、ユーザー報告を記録する
• 誤りが起きた質問パターンを分析する
• モデル更新時は再評価を実施する

ハルシネーションをゼロにできるか

現時点の生成AIで、ハルシネーションを常にゼロへ固定するのは簡単ではありません。OpenAIも、事実に基づかない出力を減らすことを未解決の課題として扱っています。

そのため、実務では「ゼロ件を前提に使う」よりも、「起こる可能性を前提に、根拠付け・検証・監視・人手確認を設計する」という考え方の方が運用しやすくなります。

研究・実装の現在地

grounding と RAG の普及

現在の対策で中心になっているのは、モデル単体の記憶に頼らず、外部情報に回答を結びつける手法です。特に社内検索、FAQ、サポートボット、業務文書要約では、groundingやRAG（Retrieval-Augmented Generation）を前提にした設計が採用されやすくなっています。

評価と監視の重視

「どのモデルが高性能か」だけでなく、「どの条件で誤るか」を継続的に測る流れが強まっています。導入前テストだけで終わらせず、公開後も誤回答、出典不整合、利用者からの訂正報告を追跡する運用が広がっています。

説明可能性と監査性の整備

出力理由そのものを完全に説明することは難しくても、どの資料を参照したか、どこで人が介在したか、どの判定で差し戻したかを追跡できる仕組みは整えやすくなっています。実務では、抽象的な「説明可能性」より、根拠提示と監査ログの方が先に効く場面が少なくありません。

まとめ

ハルシネーションは、生成AIがもっともらしい誤情報を出す現象です。問題の中心は、誤りそのものより、その出力が信じられて次の判断や処理に使われることです。

対策では、外部データに根拠を持たせること、不確実なときに断定させないこと、出典や引用を検証すること、人間の監督を残すこと、導入後も監視を続けることが軸になります。生成AIを安全に使うには、「便利だから任せる」ではなく、「誤る前提で管理する」という姿勢が必要になります。