ハルシネーションの対策｜原因・リスク・事例と、8つの防ぎ方

小学生のころ、漢字の書き取りを自分で採点していました。答え合わせも自分でやりなさい、という宿題です。

私はいつも満点でした。間違えていないからではありません。

書いた字を見て、答えを見て、「これは合っている」と思ったら丸を付けていました。とめもはねも、自分の字は自分には正しく見える。採点者と回答者が同じ人だと、こうなります。

先生が横で見ていて、「これ、違うよ」と言いました。私はそこで初めて、自分が「合っている」と思ったこと自体は何の情報でもないと知りました。

先に一行だけ置きます。LLMとは大規模言語モデルの略で、大量の文章から言葉の続き方を学習したモデルのことです。もっともらしい続きを返す仕組みです。

題材は、レビューの指摘を反映する工程です。前の工程で挙がった指摘を、次の成果物に全部反映したかを確認します。

前置きはさておき、本題に入ります。

今日は、その確認までLLMに任せたら何が起きたかという話をしていこうと思います。

① 教科書どおりに、確認もLLMにやらせる

ハルシネーションとは

ハルシネーションとは、AIが事実でない内容を、事実であるかのような形で出力する現象のことです。日本語では「幻覚」と訳されます。実在しない製品名、存在しない条文、根拠のない数値が典型です。

名前の由来は、入力には無いものを、あるかのように語るという性質です。人が幻覚を見ているときと、外から見た様子が似ているために、この呼び名が付きました。

単なる間違いとの違い

人の間違いとは、性質が2つ違います。

• 自信の度合いが出力に現れない — 確かなことも、でっち上げたことも、同じ調子で書かれる
• 文の形が整っている — 誤りだけが不自然に浮き上がってくれない

実務で困るのは「間違いが混ざる」ことより「見分けにくい」ことです。だから対策も、間違いを減らす側だけでなく、気づける形にする側を用意する必要があります。

ハルシネーションの種類

大きく2つに分けられます。

種類	中身	例
内在的	与えた資料の中身と矛盾する	資料に「3,200時間」とあるのに「2,300時間」と書く
外在的	与えた資料に無いことを付け足す	書かれていない保証条件を、あるかのように書く

対策が効く相手は、主に内在的なほうです。資料と突き合わせれば機械的に見つかります。外在的なほうは、正解の側を持っていないと見つかりません。

どんな場面で起きるか

文章の生成だけではありません。

• 文章 — 出典・数値・固有名詞の捏造
• 要約・翻訳 — 元の文に無い情報の追加、あるいは条件の脱落
• 画像・動画 — 実在しない構造物、指の本数のような整合性の崩れ
• 表やコード — 存在しない項目名・関数名の生成

要約と翻訳での発生が、いちばん見落とされます。元の文があるぶん、出てきたものを疑いにくいためです。

原因1｜学習データの偏りと不足

学習していない領域について問われると、「知らない」と答えるのではなく、近いものから作り出します。専門分野、社内固有の用語、最近の出来事で起きやすいのはこのためです。

原因2｜指示が曖昧

何を答えるべきか、何を答えてはいけないかが指示に書かれていないと、AIは空白を推測で埋めます。

効くのは、してほしくないことを具体的に書くことです。「推測で補わない」「資料に無いことは書かない」「分からない場合は分からないと答える」。禁止のほうが、肯定形の指示より守られやすくなります。

原因3｜仕組みそのものの性質

生成AIは、もっともらしい続きを作る仕組みです。正しさを判定してから出力しているわけではありません。

だから、ハルシネーションは設定や指示で「無くす」ことができません。できるのは、起きる確率を下げることと、起きたときに気づける形にすることの2つです。この線引きは、この記事の後半の主題にも繋がります。

リスク1｜誤った情報をもとに判断してしまう

いちばん実害が出るのがこれです。存在しない条文や、実在しない仕様を前提に見積もりや稟議が進むと、誤りが見つかるのは、後戻りできない段階になってからです。

リスク2｜誤情報が社外へ出る

資料、提案書、公開する文章に混ざると、訂正の手間より、信用の回復のほうに時間がかかります。実在の人物や企業について誤った記述を出せば、名誉に関わる問題にもなります。

リスク3｜法的な問題につながる

実際に、存在しない裁判例を引用した書面が提出され、問題になった事例が国内外で報じられています。出典が示されていない引用は、そのまま使わないでください。個別の案件の法的な判断は、弁護士など専門家に確認する経路を先に決めておきます。

リスク4｜セキュリティ上の穴になる

存在しないライブラリ名や設定項目が生成され、それをそのまま導入しようとして、攻撃者が用意した同名のものを取り込んでしまう経路が知られています。

生成された名前は、公式の一覧で存在を確かめてから使ってください。

実際に起きている例

報じられているものを型で整理すると、次の3つに集約されます。

• 存在しない判例・論文の引用 — 書式が正しいので、出典として通ってしまう
• 実在の人物についての誤った経歴・事件の記述 — 名前が実在するため、確かめられずに広まる
• 医療・金融のような、誤りが直接損害になる領域での誤回答

3つに共通するのは、答えの正しさを読み手が確かめられない領域だという点です。確かめられる領域では、ハルシネーションは起きても被害になりません。

対策1｜指示文に「分からないときの答え方」を書く

最初にやることです。「資料に無い場合は、無いと答える」を明示的に指示に入れてください。書いていないと、AIは空白を埋めにいきます。

あわせて、参照した箇所を引用させると、確認の手間が下がります。

対策2｜ファクトチェックの担当と手順を決める

「必ず確認する」だけでは運用に乗りません。誰が、何を、どこで確かめるかまで決めます。

• 数値と固有名詞 — 元の資料と1件ずつ突き合わせる
• 出典 — 実在するかを公式の場所で確かめる
• 結論 — 業務を知っている人が読む

全部を人が読む形にすると、続きません。確認する対象を種類で絞るほうが、運用は残ります。

対策3｜RAG（検索拡張生成）で、根拠になる資料を渡す

RAGは、答える前に社内資料や検索結果を参照させる仕組みです。学習していない領域を、その場で渡した資料で埋めます。

ただし万能ではありません。渡した資料が古ければ古い答えが返り、資料に無いことを問われれば、やはり作り出します。RAGを入れたから確認は不要、とはなりません。

対策4｜グラウンディングと、出典の提示を必須にする

グラウンディングは、答えを外部の確かな情報に紐づける考え方です。実装としては、出典の提示を必須にするのがいちばん手軽で効きます。

出典が出せない答えは、業務に流さない。この一線を運用ルールに書くだけで、混入はかなり減ります。

対策5｜ファインチューニングと、分野特化のモデル

自社の文書で追加学習させると、用語の扱いと文体は安定します。ただし、事実の正しさが保証されるわけではありません。

費用と手間がかかるため、まずRAGと指示文で足りるかを確かめてから検討してください。

対策6｜ガイドラインとマニュアルを整える

個人の注意力に頼らない形にします。書くのは4点です。

• そのまま使ってよい用途と、確認が要る用途
• 確認する項目と、確認する人
• 出典が無い答えの扱い
• 誤りが見つかったときの報告先

対策7｜複数のモデルで突き合わせる

同じ質問を別のモデルにも投げ、答えが割れたところだけ人が見ます。全件を人が読むより現実的です。

ただし、両方が同じように間違えることもあります。一致したから正しい、とは言えません。

対策8｜答えが決まっている検査は、AIに投げない

最後に、いちばん確実な対策を1つ。答えが一つに決まる確認は、AIではなくプログラムで行ってください。

数値が合っているか、必須項目が埋まっているか、指摘が全部反映されているか、採番が飛んでいないか。これらは正解の側を機械が持てるので、確率で当てにいく必要がありません。AIに任せるのは、答えが一つに決まらない部分だけにします。（この線引きが、この記事の後半の主題です）

あわせて見るリスク管理

ハルシネーション対策だけを切り出しても、片手落ちになります。次の3つと一緒に設計してください。

• AIセキュリティ — 外部の文章に仕込まれた指示（プロンプトインジェクション）への備え
• 権限の設計 — AIが呼べる処理を読み取りだけに絞り、送信や削除には承認を挟む
• AIガバナンス — 入れてよい情報の線引き、記録の保存、責任者の設定

構成はこうでした。

→ 指摘が一覧として溜まる
→ 次の工程で、それを反映した成果物を作る
→ 全部反映したかを確認して、報告する

3つ目も、LLMにやらせました。同じ文脈を持っているので、いちばん詳しいはずだからです。

そして、判定の精度を上げるために、判定役をもう一段重ねることも検討していました。よくある構成です。

報告は、いつも良好でした。 「指摘はすべて反映しました」と返ってきます。

ここまでは、教科書どおりです。
確認させていた項目は3つでした。指摘を全部反映したか、書式が正しいか、識別子を採番したか。3つとも、答えが決まっている問いです。

確認項目	答えの決まり方	当時の担当
指摘を全部反映したか	決まっている	LLM
書式が正しいか	決まっている	LLM
識別子を採番したか	決まっている	LLM

ここから先は、その教科書に沿って組んだあとの話です。対策の8つ目——答えが決まっている検査をAIに投げない——を、当時の私は知りませんでした。

上の表の3項目は、どれも答えが決まっている問いです。それを確率で答える道具に任せていました。この記事の後半で扱うのは、そのときに何が起きていたかです。

② そのとおりに回して、拾い漏れが混ざる

ところが、後から成果物を読むと、反映されていない指摘が混ざっていました。

そして、その回の報告には「すべて反映しました」と書いてありました。

嘘をついているわけではありません。両方とも、もっともらしい文章として成立しているだけです。

→ 指摘を拾い漏らす
→ 「拾いました」と報告する

この2つは、同時に成立します。

③ そして、判定の入力が出力だと気づく

構造を見直すと、単純な話でした。

私は、成果物を作った当人に、成果物の検査をさせていました。

漢字の書き取りと同じです。採点者と回答者が同じなら、採点はもう情報を持ちません。

判定役を重ねる案も、よく考えると同じでした。重ねた判定役も、もっともらしさを返します。 数が増えるだけで、確からしさは増えません。

④ 原因は「答えが決まっている検査を、確率的な道具に投げていた」こと

原因を一つに絞ると、これでした。

「指摘を全部拾ったか」は、答えが決まっている問いです。

一覧に載っている項目が、成果物に含まれているかどうか。含まれているか、いないか。 解釈の余地がありません。

答えが決まっている問いを、もっともらしさを返す道具に投げていたのが誤りでした。

そして、この誤りは内容の良し悪しの判定とは別です。「この設計は妥当か」はLLMに向いています。「全部あるか」は向いていません。

⑤ 直してみる — 判定を一切LLMに渡さない

やったことは3つです。

1. 網羅性の確認を、コードの文字列一致に置き換えた。
未解決の指摘を全件取り出し、それぞれに付いている識別子が、次の成果物の本文に文字列として含まれているかを検査します。含まれていなければ落とす。それだけです。

判定を一切LLMに渡していません。 重ねるのではなく、外しました。

2. 比較の前に、空白を正規化した。
表記ゆれで落ちるので、空白を除去してから比較します。全角空白も対象に含めています。 日本語で運用すると混ざるからです。

地味です。ただ、ここを外すと運用が止まります。

3. 検査に落ちたら、状態を一切書き換えずに終了する。
半分だけ反映された状態が、いちばん厄介だからです。落ちた場合は保存処理に進まず、終了コードで異常を返します。 呼び出している側は、それを見て差し戻します。

シェルの終了コードが、そのまま差し戻しの門になっています。

そして、この方針を文書に明記しました。

モデルは、書式の検証も、識別子の採番も、網羅性の確認もしない。
置き換えた結果を数字で置いておきます。確認1回あたりの所要は数秒から数ミリ秒へ、費用はゼロに、判定の揺れもゼロになりました。

項目	LLMに確認させる	コードで検査する
所要	数秒	数ミリ秒
費用	課金あり	ゼロ
同じ入力での再現性	揺れる	常に同じ

⑥ あとで知った — 同じ線引きを、別の場所でも引いていた

素朴な対処のつもりでしたが、同じ線を、別の担当者が別の場所で引いていました。

プロダクト側の出力検証です。そこには、こう書かれていました。

「これはプログラムによる検証であり、LLMの呼び出しはゼロ」

検査している内容も具体的です。

→ 置き換え忘れの穴埋め語が残っていないか
→ やり方の説明で終わっていないか（実行するのではなく手順を語り出す癖）
→ 曖昧な委譲が入っていないか（「適宜」「必要に応じて」）
→ 未実装のまま例外を投げるだけの塊が混ざっていないか

どれも、答えが決まっています。 そして、どれもLLMに聞けば「問題ありません」と返ってきうる項目です。

面白いのは、違反の扱いを2つに分けていることでした。実行そのものを失敗にする構造的な違反と、警告だけ足して先へ進めるソフトな違反。止めるべきものと、進めてよいものを分けています。

私が1箇所でやったことを、別の担当者が別の層で同じようにやっていました。 相談したわけではありません。同じ壁に当たると、同じ場所に線を引くのだと思います。

新しい理屈は、ひとつも要りませんでした。

記録に残っている実例

開発中のツールの修正履歴に、この問題がそのまま残っています。

2026年2月27日の修正。 判定結果を文字列から取り出す処理で、取り出せなかったときの既定値を1語だけ変えました。

“`

• const verdict = verdictMatch ? verdictMatch[1].toUpperCase() : ‘PASS’;

+ const verdict = verdictMatch ? verdictMatch[1].toUpperCase() : ‘FAIL’;
“`

それまでは、判定が読み取れなかったとき、通していました。 判定していないことと、合格したことが、同じ扱いになっていた。1語です。 直した行数は1行でした。

この既定値が `PASS` のままだと、書式が崩れるたびに検査が素通りします。検査が動いていない状態と、全部合格している状態は、ログの上では区別がつきません。

同じ設計思想は、2026年2月2日の決定にも残っています。抽出役の出力はJSONのみに強制し、崩れたら計画全体から1件だけタスクを作る形に落とす。文脈にはこう書かれています。「LLMは時々マークダウンや説明を足す」。 足されることを前提に、外側で剥がしています。

⑦ 何が変わったか

LLMに聞くことが減りました。

“`
前：作らせる → 確認させる → 報告を読む
後：作らせる → コードで検査する → 落ちたら差し戻す
“`

確認の工程が、速くて安くなりました。 文字列比較なので、待ち時間も課金もありません。

⑧ 現場で使うなら、この2枚

表1：LLMに判定させてよいか

判定	LLM	コード
この設計は妥当か	向いている	不可
この文章は読みやすいか	向いている	不可
指摘を全部拾ったか	向いていない	文字列一致
必須項目が埋まっているか	向いていない	存在確認
識別子の採番	向いていない	採番処理
禁止語が残っていないか	向いていない	パターン照合

判定の答えが決まっているなら、コードに渡してください。

表2：検査を入れる場所

場所	何を見るか	落ちたら
取り込みの直前	網羅性・書式	状態を書き換えずに終了
出力の直後	穴埋め語・未実装の塊	構造的なら失敗、軽微なら警告
保存の直前	整合性	保存しない

「落ちたら」の列を空欄にしないでください。 落ちたあとの挙動を決めていない検査は、警告を出すだけの飾りになります。

表3：正規化で落ちやすい表記ゆれ

ゆれ	例	対処
全角と半角の空白	識別子の前後	両方とも除去
全角と半角の数字	3 と ３	片方へ寄せる
括弧の種類	[F3] と ［F3］	片方へ寄せる
前後の改行	—	除去

1行目を外すと、日本語の運用では必ず落ちます。 実際、最初の実装では半角空白しか除去しておらず、検査が通らない事例が続きました。

補：置き換えで動いた数字

項目	前	後
1件あたりの所要	数秒	数ミリ秒
1日の確認回数	数十回	数十回
課金	あり	0円
判定の揺れ	あり	0件
検査項目	3件	3件
落ちたときの挙動	続行	停止

ところで、6行のうち効いたのは最後の1行です。「落ちたら止める」と決めるまで、警告は出ていたのに誰も見ていませんでした。

運用では、次の5件に名前を付けて配りました。名前が付くと、会議の中で指差せるようになります。

1件目、「拾い漏れと、拾いましたという報告は両立する」。 矛盾ではありません。報告は作業の記録ではなく、その場で作られた文章だからです。

2件目、「網羅性の判定は、LLMに渡さない」。 何件あるべきかを知らない相手に、全部あるかを聞いています。答えは必ず返ってきますが、根拠はありません。

3件目、「退屈で決定的な方法で、コードが検査する」。 文字列一致で足ります。面白くない方法ほど、同じ入力に同じ答えを返します。

4件目、「判定を重ねても、確からしさは増えない」。 3回聞けば3つの回答が出るだけです。増えたのは回答の数であって、確からしさではありません。

5件目、「精度が上がっても、この性質は消えない」。 モデルが良くなるほど、報告の文章も上手くなります。見分けにくくなる方向に進みます。

この5件は、1枚に印刷して配れる分量に収めています。増やすと、誰も覚えません。

⑨ この考え方が効き続ける理由

LLMは、これからも賢くなります。それでも、この線引きは動きません。 賢さの問題ではなく、答えが決まっている問いを確率的な道具に投げているという構造の問題だからです。

→ もっともらしさを返す → 「拾いました」ももっともらしい
→ 拾い漏れも同時に成立 → 報告が情報を持たない
→ 情報を持たない → 重ねても増えない

LLMを判定に重ねる設計は、判定の数を増やしているのであって、確からしさを増やしていません。

そして、外すと副産物があります。速くて、安くて、結果が毎回同じです。 文字列一致には揺らぎがありません。同じ入力なら、同じ判定が返ります。

ただし、正直に書いておきます。この方式は、識別子を必ず本文に書かせるという運用に依存しています。 書かれなければ検査は通りません。運用の規律を、検査が要求する形になっています。 そこを窮屈だと感じる人はいるはずで、私もときどき感じます。

置き換えたあとの数字です。確認1件あたりの所要は数秒から数ミリ秒へ、費用は0円、同じ入力に対する判定の揺れも0件になりました。文字列の比較には揺らぎがありません。

運用してからの数字を足しておきます。検査は1日に数十回、落ちた回数は月に2回、落ちた原因は2回とも識別子の書き忘れでした。なお、書き忘れは人ではなくモデル側で起きています。ただし、検査があるので本番には届いていません。

関連して、社内で共有されていた観察を1件引いておきます。深い調査を自動で回す機能について、「出典が多く付いていて情報源を辿りやすい一方で、調査の統合過程で判断軸がブレ、最終的な分析や結論が怪しいケースが多い」。

ところで、これも同じ構造です。工程を重ねるほど、途中で判断軸が入れ替わる。 出典が多いことは、結論が正しいことを保証しません。ただし、辿れること自体には価値があります。辿れるかどうかと、正しいかどうかは別の軸です。

関連して、AI駆動開発で自作基盤とネイティブ機能を分ける話と、プロンプトエンジニアリングを属人化させない話を別に書いています。チャットボットはまず分類器から作る話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。

この判断を実際の案件で使う場面については、生成AIの実装のページに整理しています。

---

検算といえば、学生のころ答案を見直して間違いを見つけたことが、一度もありません。 自分で自分を検算するのは、たぶん人間にも向いていません。

以上です。

ハルシネーション対策のよくある質問

ハルシネーションとは何ですか？

AIが事実でない内容を、事実であるかのような形で出力する現象のことです。日本語では幻覚と訳されます。人の間違いと性質が2つ違います。1つは、確かなこともでっち上げたことも同じ調子で書かれるため、自信の度合いが出力に現れないこと。もう1つは、文の形が整っているため、誤りだけが浮き上がってくれないことです。

ハルシネーションを完全に防ぐ方法はありますか？

ありません。生成AIはもっともらしい続きを作る仕組みで、正しさを判定してから出力しているわけではないからです。できるのは2つです。起きる確率を下げること（指示文に分からないときの答え方を書く、RAGで根拠になる資料を渡す）と、起きたときに気づける形にすること（出典の提示を必須にする、数値と固有名詞を元資料と突き合わせる）です。

ハルシネーションが起こる原因は何ですか？

3つあります。学習データの偏りと不足（学習していない領域では、知らないと答えるのではなく近いものから作り出します）、指示が曖昧なこと（何を答えてはいけないかが書かれていないと空白を推測で埋めます）、そして仕組みそのものの性質です。3つ目があるため、設定や指示だけで無くすことはできません。

RAGを入れればハルシネーションは防げますか？

減りますが、防げるわけではありません。RAGは答える前に社内資料や検索結果を参照させる仕組みで、学習していない領域をその場で渡した資料で埋めます。ただし、渡した資料が古ければ古い答えが返り、資料に無いことを問われればやはり作り出します。RAGを入れたから確認は不要、とはなりません。

業務でハルシネーション対策をするなら、何から始めればよいですか？

2つからです。1つは、指示文に「資料に無い場合は無いと答える」と明示し、参照した箇所を引用させること。もう1つは、答えが一つに決まる確認をAIに投げないことです。数値が合っているか、必須項目が埋まっているか、採番が飛んでいないか。これらは正解の側を機械が持てるので、確率で当てにいく必要がありません。

LLMとは何ですか？

大規模言語モデル（Large Language Model）の略で、大量の文章から言葉の続き方を学習したモデルです。文章を読んで、次に来る言葉としてもっともらしいものを返します。もっともらしさを返す仕組みであることが、この記事の主題に直結します。

LLMに自分の作業をチェックさせてもいいですか？

網羅性の確認には使えません。指摘を全部反映したかを自己申告させると、拾い漏れと「全部拾いました」という報告が同時に成立します。嘘をついているのではなく、もっともらしい文章として両方が成立してしまうためです。

LLMを判定役にする設計はどうですか？

内容の良し悪しには使えますが、網羅性には向きません。判定を重ねても、それぞれがもっともらしさを返すだけだからです。数え上げや突き合わせのように答えが決まっている検査は、コードで文字列を比較したほうが速く、確実で、安価です。

文字列一致で検査すると、表記ゆれで落ちませんか？

落ちます。だから正規化を挟みます。実装では空白を除去してから比較しており、全角空白も対象に含めています。日本語で運用すると全角空白が混ざるためです。地味ですが、これが実地の勘所です。

検査に落ちたとき、どうすればいいですか？

状態を一切書き換えずに終了します。半分だけ反映された状態が最も厄介だからです。実装では、検査に落ちた場合は保存処理に進まず、終了コードで異常を返します。呼び出している側がそれを見て差し戻します。