ChatGPTやClaudeなどのLLMを使い始めると、「存在しない論文を引用された」「APIの仕様が実際と違う」といった体験にぶつかることがある。
これをハルシネーション（hallucination）——もっともらしいが事実と異なる出力——と呼ぶ。
この記事は、ハルシネーションがなぜ起きるのか、実務でどう減らすかを初心者向けに整理する。

結論：ハルシネーションは「バグ」ではなく構造的な性質

観点	内容	実務での対応
根本原因	LLMは「次のトークンを確率的に予測する」だけで、真偽を検証しない	出力をそのまま信じない設計にする
起きやすい場面	事実確認が必要な質問、マイナーな固有名詞、数値・日付	根拠提示を要求し、外部ソースで検証する
減らし方	RAG・ツール呼び出し・プロンプト設計・人間レビューの組み合わせ	多層防御で「出す前に止める」

覚え方：LLMは「知識を持つデータベース」ではなく「文章を続けるエンジン」だ。だから「自信満々な嘘」が混ざる。

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

ハルシネーションとは、LLMが生成したテキストが文法的にも論理的にも自然に読めるが、事実と一致しない状態を指す。

典型的な例は次のとおりだ。

存在しない論文・書籍・URLを引用する
架空のAPIメソッドやパラメータ名を提示する
人物の経歴や企業の沿革を誤って説明する
コードがコンパイル・実行できないのに「動きます」と断言する

重要なのは、モデルが嘘をついている自覚がない点だ。出力は常に「次に来そうなトークン」を選んでいるだけであり、真偽判定のステップは組み込まれていない。

OpenAIのドキュメントでも、モデルは事実の正確性を保証できないことが明記されている。

原文: "Models can hallucinate and return plausible but incorrect answers"
日本語訳: 「モデルはハルシネーションを起こし、もっともらしいが誤った回答を返すことがある」（出典: OpenAI API documentation）

なぜハルシネーションは起きるのか

ハルシネーションの原因は、大きく4つに整理できる。

1. 次トークン予測という設計

LLMの推論（inference）は、入力テキストをもとに次に来るトークンの確率分布を計算し、1つずつ選んでいく処理だ。
「この文の続きとして自然か」は評価するが、「この文が事実か」は評価しない。

入力: 「2020年ノーベル物理学賞を受賞したのは」
モデルの内部: P(次のトークン) を計算 → もっともらしい固有名詞を生成
問題: 学習データにない・古い・誤った情報でも、文脈に合えば出力される

2. 学習データの限界と偏り

事前学習データには、正確な情報も誤情報も含まれる。
また、学習のカットオフ日より後の出来事や、マイナーな固有名詞はモデルが十分に学習していない場合がある。

データの性質	ハルシネーションへの影響
インターネット上の誤情報	誤った「常識」として学習される
学習カットオフ以降の出来事	存在しない情報を推測で補完する
マイナーな固有名詞	似た名前の別エンティティと混同する

3. 指示への過剰な従順（sycophancy）

「答えを出してほしい」という指示に対し、モデルは不確実でも plausible な回答を生成しがちだ。
「わかりません」と答えるより、もっともらしい推測を返す方が学習上報われたパターンになっている。

4. 長い生成ほど誤りが蓄積する

トークンを1つずつ生成するため、前半の誤りが後半の生成条件になる。
長文・多段階の推論ほど、誤りが連鎖しやすい。

ハルシネーションが起きやすいタスク

実務で特に注意が必要なのは次のタイプだ。

タスク	リスクが高い理由	例
固有名詞の列挙	存在しないエンティティを生成しやすい	「〇〇分野の主要企業10社を挙げて」
数値・統計	もっともらしい数字を捏造する	「市場規模は何兆円か」
引用・出典	架空の論文タイトル・DOIを生成する	「根拠となる論文を3つ」
コード生成	存在しないライブラリ・APIを使う	「〇〇フレームワークで実装して」
日付・バージョン	カットオフ以降の情報を推測する	「最新のリリースノートを要約して」

逆に、創作・要約・文章整形のように「正解が1つない」タスクでは、ハルシネーションというより「創造性」と捉えられる場面もある。
問題になるのは、事実確認が求められる場面で創造的に補完されるときだ。

ハルシネーションを減らす5つの手法

完全にゼロにはできないが、実務で効果が確認されている対策を5つに整理する。

1. 根拠提示を要求する（プロンプト設計）

モデルに「根拠を示せ」「不確実なら不明と答えろ」と明示する。

以下の質問に答えてください。

【ルール】
- 確信が持てない場合は「不明」と答える
- 事実を述べるときは、情報源（公式ドキュメント名・URL等）を併記する
- 推測する場合は「推測：」と明示する

【質問】
（ここに質問）

Anthropicのドキュメントでも、モデルに不確実性を認識させるプロンプト設計が推奨されている。

2. RAG（検索拡張生成）で外部知識を渡す

社内ドキュメントや公式ドキュメントを検索してからモデルに渡す手法だ。
モデルが「知っていること」だけでなく「渡された根拠」に基づいて回答するようになる。

[ユーザーの質問]
     ↓
[ベクトル検索] → 関連ドキュメントのチャンクを取得
     ↓
[プロンプト] 質問 + 検索結果をコンテキストに含める
     ↓
[LLM] コンテキスト内の情報に基づいて回答

RAGでも100%防げるわけではない（検索結果にない情報を推測する場合がある）が、根拠のある回答に寄せやすい。

3. ツール呼び出し（Function Calling / MCP）で事実を取得する

モデルに「計算機」「Web検索」「データベース問い合わせ」などのツールを使わせ、外部システムから事実を取得してから回答させる。

ツールの例	防げるハルシネーション
計算機	算術の誤り
Web検索	最新情報・固有名詞の誤り
DB/API照会	社内データの捏造
コード実行	動かないコードの提示

OpenAIの Function Calling や Anthropic の Tool Use は、このパターンを標準化している。

4. 構造化出力と検証パイプライン

出力を JSON スキーマで縛り、プログラム側で検証する。

{
  "answer": "回答テキスト",
  "confidence": "high | medium | low",
  "sources": ["URL1", "URL2"],
  "needs_verification": true
}

confidence: low や needs_verification: true の場合は人間レビューに回す、といったゲート設計が有効だ。

5. 人間レビュー（Human-in-the-Loop）

最終的な安全弁は人間の確認だ。特に次の出力はレビュー必須とする。

顧客向けにそのまま送る文章
法務・医療・金融に関わる内容
外部公開する技術ドキュメント
自動化パイプラインの最終出力

温度（temperature）とハルシネーションの関係

temperature は出力のランダム性を制御するパラメータだ。

temperature	挙動	ハルシネーションへの影響
低い（0〜0.3）	もっとも確率の高いトークンを選びやすい	安定するが、誤情報も一貫して出る
高い（0.7〜1.0）	多様なトークンを選びやすい	創造性は上がるが、誤りも増えやすい

事実確認が必要なタスクでは temperature を低く（0〜0.3程度）設定するのが一般的だ。
ただし、低くしてもハルシネーションは消えない。あくまで「ブレを減らす」効果にとどまる。

実装チェックリスト

事実確認が必要なユースケースかを事前に分類し、ハルシネーションリスクを評価する
プロンプトに「不明と答える」「根拠を示す」ルールを含める
社内・公式ドキュメントがある場合は RAG で根拠を渡す
数値・日付・固有名詞はツール呼び出しまたは外部APIで検証する
出力に confidence や sources フィールドを含め、低信頼度は人間レビューに回す
事実系タスクでは temperature を 0〜0.3 に設定する
本番投入前に代表例10件以上でハルシネーション率を計測する
ユーザー向けUIに「AIの回答は誤りを含む可能性があります」の注意書きを表示する

失敗パターン

パターン1：LLMの出力をそのまま顧客に送る
→ 対策：人間レビューまたは自動検証パイプラインを挟む。特に固有名詞・数値は外部ソースと照合する。

パターン2：RAGを入れたのにハルシネーションが減らない
→ 対策：検索精度（チャンクサイズ・埋め込みモデル）を見直す。プロンプトに「コンテキストにない情報は答えない」と明記する。

パターン3：「最新情報を教えて」にカットオフ以降の内容を信じる
→ 対策：Web検索ツールを組み込むか、学習カットオフ日をユーザーに明示する。

パターン4：コードを生成させてそのまま本番デプロイする
→ 対策：必ずテスト実行・lint・型チェックを通す。存在しないimportやAPIは実行時に検出される。

パターン5：ハルシネーション対策を「プロンプト1行追加」で済ませる
→ 対策：RAG・ツール・検証・人間レビューの多層防御を設計する。単一対策に依存しない。

まとめ

ハルシネーションはLLMの「次トークン予測」という設計に起因する構造的な性質であり、完全には消せない。
起きやすいのは固有名詞・数値・引用・コード・最新情報など、事実確認が必要なタスク。
減らすには、根拠提示のプロンプト設計、RAG、ツール呼び出し、構造化出力＋検証、人間レビューを組み合わせる。
実務では「LLMの出力を信じない」前提でパイプラインを設計する。

参考リンク

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。