2026年9月13日時点の公開ドキュメントを根拠に、LLMの**ハルシネーション（もっともらしい嘘）**がなぜ起きるのか、実務でどう減らすかを初心者向けに整理します。前段の「次のトークン予測」「プロンプトの基本の型」とつながる話です。

この記事のゴールは、「モデルが嘘をついている」ではなく「真偽検証なしで次の語を並べている」と説明でき、減らし方をプロンプト／根拠付与／検証の層で選べる状態になることです。

結論：消えない性質なので、設計で止める

観点	押さえる事実	設計で先に決めること
正体	文法的に自然でも事実と一致しない出力が起きうる	「そのまま本番決定に使うか」を先に決める
原因	次トークン予測であり、真偽判定のステップが組み込まれていない	知識DBと生成器を混同しない
起きやすい場	固有名詞・数値・日付・存在しない文献・社内専用知識	根拠のない断言を禁止する
減らし方	不確実なら断る／引用で接地／検索・RAG／人手確認	1手法に頼らず多層防御にする
限界	完全ゼロは期待しにくい	失敗コストが高い処理は人間が最終判断

迷ったら次の一文で十分です。

ハルシネーションはバグというより、次トークン予測という仕組みから来る構造的な性質である。

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

確認できる事実

Anthropic の公式ガイドは、高度な言語モデルでも、事実と異なる、または与えられた文脈と矛盾するテキストを生成しうると説明し、これを hallucination と呼んでいます（Reduce hallucinations）。
典型例は次のとおりです。
- 存在しない論文・URL・API名・バージョンを自信満々に書く
- 渡していない社内ルールを「ある」前提で答える
- 数値・日付・人名を取り違える
- コードが動かないのに「動きます」と断言する

原文: "Even the most advanced language models, like Claude, can sometimes generate text that is factually incorrect or inconsistent with the given context."
日本語訳: 「Claudeのような最先端の言語モデルでも、事実として誤り、または与えられた文脈と矛盾するテキストを生成することがある。」（出典: Anthropic — Reduce hallucinations）

実務解釈

重要なのは、モデルに「嘘をつく意図」があるわけではない点です。出力は常に「次に来そうなトークン」の選択であり、真偽チェックは別工程として足す必要があります。

質問・指示
  ↓
次トークンを確率的に選ぶ（繰り返し）
  ↓
自然で自信ありげな文章
  ↓
（ここには自動の事実検証がない）

2. なぜ起きるのか（次トークン予測との接続）

確認できる事実

LLM は入力の続きとして次のトークンを予測する生成器です。前段記事で見た「百科事典ではなく予測器」という見方が、そのままハルシネーションの説明になります。
OpenAI の精度最適化ガイドは、文脈不足・古い知識・社内固有情報の欠如があると精度が落ちうること、そして retrieval（検索で根拠を足す）と fact-checking を組み合わせて精度を上げる流れを示しています（Optimizing LLM Accuracy）。
同じガイドでは、誤った文脈や無関係な文脈を大量に渡すと、かえってハルシネーションを誘発しうる、と整理しています。

実務解釈

起きやすい条件を初心者向けにまとめると次のとおりです。

条件	何が起きやすいか
学習に無い／古い事実を聞く	もっともらしい推測で埋める
固有名・数値・出典が必須	形だけ整った偽情報が混ざる
根拠なしで「断言せよ」と促す	不確実でも言い切る
無関係な長文を大量に渡す	本当に必要な根拠が埋もれる

「自信の強さ＝正しさ」ではありません。流暢さと正確さは別物です。

3. まず効く減らし方（プロンプト層）

確認できる事実

Anthropic の公式ガイドが挙げている基本策は次です。

「わからない」と言ってよいと明示する
直接引用で接地する（長文では先に原文抜粋→その後に分析）
主張ごとに根拠引用し、見つからなければ主張を取り消す

原文: "Allow Claude to say "I don't know": Explicitly give Claude permission to admit uncertainty. This simple technique can drastically reduce false information."
日本語訳: 「Claudeに『わからない』と言ってよいと許可する。不確実さを認める許可を明示するだけで、誤情報を大幅に減らせる。」（出典: Anthropic — Reduce hallucinations）

同ガイドは、これらの手法で大幅に減らせても完全にはなくならないとも明記しています。重要判断では必ず人間側の検証が必要です。

実務解釈（そのまま使える指示例）

次のルールで答えてください。
1. 渡した資料に根拠がない事実は断言しない。
2. 確信が持てない場合は「わからない」と書く。
3. 事実を述べるときは、資料からの短い引用を添える。
4. 引用できない主張は削除する。

プロンプトだけで足りる領域（下書き・言い換え・要約のたたき台）と、足りない領域（監査・金銭・法務・本番設定変更）を最初に分けます。

4. 根拠を外から足す（RAG・ツール・評価）

確認できる事実

OpenAI の精度ガイドは、プロンプト改善の次に、必要な文脈を検索して渡す RAG（Retrieval-Augmented Generation）が精度向上の中心手段だと説明しています。大規模導入でも prompt + RAG だけで十分な例が多い、としています。
同ガイドは「fact-checking step（事実確認ステップ）を加えてハルシネーションを見つける」ことも精度向上の手順に含めています。
Anthropic 側の発展技として、同一プロンプトを複数回走らせて不一致を見る（Best-of-N）、外部知識を使わず渡した文書だけ使う、などの手法が挙げられています。

実務解釈（層で選ぶ）

層	やること	向く場面
プロンプト	不確実なら拒否・引用必須	すぐ試せる最初の一手
根拠付与	文書貼付・検索・RAG	社内文書・仕様・FAQ
ツール	計算・API・DB照会	数値・在庫・最新状態
検証	別モデル／ルール／人手	失敗コストが高い出力
学習	fine-tuning（最終手段寄り）	文体・形式の一貫性が主目的のとき

初心者がやりがちなのは「いきなり fine-tune」です。多くの場合、先にプロンプトと根拠付与を詰めた方が速いです。

5. 実装チェックリスト

定義と境界

「流暢＝正確」ではない、とチームで共有した
失敗コストが高い処理を一覧にした（金銭・権限・対外公表など）
その処理は LLM 単独決定にしない方針を書いた

プロンプト

「わからないと言ってよい」を明示した
根拠のない断言を禁止した
長文作業では「先に引用→後で分析」にした

根拠と検証

社内事実はプロンプト内か検索／RAGで渡している
重要出力に引用または出典欄がある
同じ入力を2回試し、揺れが大きい項目を洗い出した
本番前に人手レビューのゲートがある

進め方

プロンプト未検証のまま fine-tune に行っていない
「根拠を増やせば必ず良くなる」と思い込んでいない（ノイズ過多も危険）

失敗パターン

パターン1：自信満々の出力をそのまま公開する → 対策: 失敗コストでゲートを分ける。高リスクは引用必須＋人手確認。

パターン2：「正確に答えて」とだけ書く → 対策: 不確実時の振る舞い（拒否・確認質問・引用必須）を明示する。

パターン3：関係ない長文を全部突っ込む → 対策: 検索結果を絞る。必要箇所だけ渡す。OpenAI ガイドも過剰ノイズを警告している。

パターン4：存在しないURLや論文を信じ切る → 対策: リンクは必ず実在確認。引用できない主張は捨てる。

パターン5：評価なしで「直った」と言う → 対策: 10〜50件の小さな評価セットを先に作る。減ったかどうかを測る。

参考リンク

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