生成 AI を業務に入れようとすると、必ず「事実と違うことを、もっともらしく言い切ってしまう」という問題にぶつかります。これがハルシネーションです。社内の調べ物やたたき台づくりなら笑い話で済みますが、顧客への回答や金額の算出に使えば、そのまま事故になります。本記事では、ハルシネーションを業務利用で実用レベルまで抑えるための対策を、原因の切り分けから RAG・出典明示・出力検証・人間協調・評価まで、多層防御の設計として実装視点で整理します。「AI は嘘をつくから怖くて使えない」を、「誤りが起きても被害が出ない仕組みになっているから任せられる」へ変えるための手順書として読んでください。

ハルシネーションとは何か - なぜ起きるのかを分解する

ハルシネーションとは、生成 AI が事実に基づかない情報を、あたかも正しいかのように生成してしまう現象を指します。存在しない法律の条文、実在しない論文の引用、計算が合わない数字、過去の事実の取り違えなど、形はさまざまですが、共通するのは「文章としては自然で、一見もっともらしい」という点です。だからこそ見抜きにくく、業務利用のリスクになります。

なぜ起きるのかは、LLM の仕組みを押さえると腑に落ちます。大規模言語モデルは、与えられた文脈の続きとして「次に来る確率が高い語」を選び続けることで文章を作ります。学習データの中で統計的にありそうな並びを再現しているのであって、その内容が事実かどうかを照合する機能を内部に持っているわけではありません。つまり、知っていることも知らないことも、同じ「それらしさ」の基準で出力されます。人間なら「分からない」と言える場面でも、モデルは確率的に自然な答えで埋めようとしてしまうのです。

この性質を理解すると、対策の方向性が見えてきます。モデルに「事実を分かっていてほしい」と期待しても限界があります。それよりも、外から正しい知識を与え、出力を検証し、確信が持てないときは止める、という外付けの仕組みで補うほうが現実的です。ハルシネーションは生成 AI の不具合というより、確率的に言葉を紡ぐという仕組みに付随する特性であり、設計で付き合っていく対象だと捉えるのが出発点になります。

原因の切り分け - 知識不足・文脈欠落・推論ミスを見分ける

「AI が間違えた」と一括りにして対策を打っても効果は出ません。誤回答の原因は大きく 3 つに分かれ、それぞれ打ち手が違うからです。まずは目の前の誤りがどの種類かを切り分けるところから始めます。

1 つ目は知識不足です。モデルが学習時点で知らない情報、たとえば自社製品の仕様や社内規定、最新の出来事について問われたときに起きます。元になる知識を持っていないので、推測で埋めるしかなく、それらしい嘘が生まれます。これは後述する RAG のように、外部から正しい知識を供給する対策が効きます。

2 つ目は文脈欠落です。必要な情報はモデルに渡せているのに、プロンプトの指示が曖昧だったり、参照すべき文書の中で該当箇所が埋もれていたりして、正しく拾えないケースです。長い文脈の中ほどにある情報を見落とす傾向もここに含まれます。これはプロンプト設計や、渡す情報の絞り込み・構造化で改善します。

3 つ目は推論ミスです。知識も文脈も揃っているのに、多段の計算や論理の組み立ての途中で誤るパターンです。桁の繰り上がりを間違える、条件分岐を取り違えるといった例が典型で、複雑な問いほど起きやすくなります。これは思考過程を段階的に書かせる、計算は外部ツールに任せる、といった対策が向きます。

実務では、誤回答が出たときに「これは知識がなかったのか、渡したのに拾えなかったのか、推論を間違えたのか」を必ず分類する習慣をつけてください。知識不足に対してプロンプトを直しても直らないし、推論ミスに RAG を足しても解決しません。原因と対策を対応づけることが、無駄な打ち手を減らす最短ルートです。

RAG と出典明示で根拠のある回答に寄せる

知識不足が原因のハルシネーションに最も効くのが RAG (Retrieval-Augmented Generation) です。ユーザーの質問に関連する文書を検索で取得し、その内容をプロンプトに添えたうえで回答させることで、モデルが学習していない社内固有の情報や最新情報を、推測ではなく根拠に基づいて答えさせられます。社内 FAQ、規定・マニュアルの問い合わせ、仕様書の横断検索といった業務は、RAG が第一候補になります。RAG の設計と精度向上の手順は RAG 構築の実践ガイド で詳しく扱っているので、本格的に組むならあわせて参照してください。

ただし、RAG を入れればハルシネーションがなくなるわけではない点に注意が必要です。検索が無関係な文書を引いてくれば、それを根拠にした誤回答が生まれます。逆に正しい文書を渡しても、モデルがその内容を無視して自分の推測で答えてしまうこともあります。RAG は「正しい知識を渡す」までしか保証せず、「渡した知識だけで答える」かどうかは別の制御が要ります。

そこで重要になるのが出典明示です。回答の各記述に対して、どの文書のどの箇所を根拠にしたかを併記させる設計にします。出典を必ず示すよう指示すると、モデルは渡された文書の範囲内で答えようとする傾向が強まり、根拠のない作文が減ります。さらに、出典が提示されていれば、利用者や検証側が「本当にその文書にそう書いてあるか」を後から確認でき、誤りを検知する手がかりになります。

あわせて有効なのが、根拠が見つからないときに無理に答えさせない設計です。「渡した文書に該当する記述がなければ、推測せず『分かりません』と答えてください」という方針をプロンプトとシステム側の両方で徹底します。業務利用では、間違った答えを出すよりも「分からない」と正直に言ってくれるほうが、被害がはるかに小さいことが多いからです。知識を与える RAG、根拠を示す出典明示、答えを控える設計の三点をセットにして、はじめて「根拠のある回答」に寄せられます。

出力検証とガードレール - 自己検証と外部チェック

知識を与えても推論ミスや拾い損ねは残るため、出てきた答えをそのまま信じず、出力を検証する層を別に設けます。これがガードレールの考え方です。検証には大きく、モデル自身に確かめさせる自己検証と、外部の仕組みで機械的に照合する外部チェックの二系統があります。

自己検証は、生成した回答を別のプロセスで点検させる方法です。たとえば、回答とその根拠文書を渡して「この回答は根拠文書だけで裏づけられるか、矛盾はないか」を判定させる、あるいは答えを出す前に思考過程を段階的に書かせて飛躍がないか自分で確認させる、といった工夫が該当します。一発で答えさせるより、生成と検証を分けるほうが誤りに気づきやすくなります。ただし検証も同じ LLM が行う以上、検証側もまた間違える可能性は残るので、自己検証だけに頼り切らないことが大切です。

外部チェックは、出力をプログラムで機械的に検証する層です。数値計算は LLM に暗算させず計算ツールに渡して結果を埋め込む、日付や金額や型番のフォーマットを正規表現や定義済みスキーマで突き合わせる、参照先の文書 ID が実在するか照合する、といった具体的な検査を組み込みます。事実の真偽そのものは機械では判定しきれませんが、「形式として明らかにおかしい出力」や「存在しないものを指している出力」は確実に弾けます。誤りのうち機械で検出できる部分を外部チェックに任せ、判断が要る部分を自己検証や人間に回す、という役割分担が効率的です。

ガードレールを設計するときのコツは、検出したあとの挙動まで決めておくことです。検証に失敗したら、再生成させる、人間に回す、あるいは「確認中」として出力を保留する、といった分岐をあらかじめ用意します。検証して終わりではなく、おかしいと分かった出力を外部に出さない流れまで作ってこそ、ガードレールが機能します。

人間協調で許容できないミスを止める設計

どれだけ層を重ねても、ハルシネーションをゼロにはできません。だからこそ、誤りが許容できない場面では人間が確認して止める設計、いわゆる Human-in-the-Loop を最後の砦として組み込みます。ポイントは「全部を人が見る」のではなく、「見るべきところに絞って人を入れる」ことです。

設計の起点は、用途をリスクの大きさで分類することです。社内向けのたたき台生成やアイデア出しのように、人が必ず後で手を入れる低リスク用途では、AI の出力を比較的そのまま使ってかまいません。一方、顧客への回答、契約や金額に関わる算出、医療・法務・会計のように誤りが直接損害につながる高リスク用途では、AI 単独で確定させず、人間のレビューを必須にします。同じ AI 機能でも、出力の使われ方によってかける手当ては変えるべきです。

高リスク用途で効くのが、確信度による振り分けです。RAG で十分な根拠が取れた、検証も通った、という出力は自動で進める一方、根拠が薄い・検証に引っかかった・前例のない問い合わせといった出力だけを人間のチェックに回します。すべてを人手にすると AI を入れた意味が薄れますが、危ない出力だけを選んで人に見せれば、確認の負荷を抑えつつ重大なミスを止められます。AI が処理量を担い、人が判断の質を担保するという分担です。

レビューを差し込む際は、確認しやすい形で出力を見せる工夫も効きます。回答だけでなく根拠とした出典を並べて提示すれば、レビュアーは「この文書に本当にそう書いてあるか」を素早く照合でき、確認の精度と速度が上がります。人間協調は、AI を信用しないための仕組みではなく、AI に任せられる範囲を安全に広げるための仕組みだと捉えると、設計の勘所が掴めます。

評価ハーネスで誤回答率を継続的に下げる

ここまでの対策は、入れて終わりにすると効果が分かりません。「対策で本当に誤回答が減ったのか」「モデルやプロンプトを変えたら良くなったのか悪くなったのか」を数値で測れる仕組み、すなわち評価ハーネスを用意して、継続的に改善を回すことが業務利用では不可欠です。評価の組み方は LLM 評価ハーネスと LLMOps の進め方 で具体的に解説しているので、運用に乗せる段階で参照してください。

評価ハーネスの中心は、評価セットです。実際に来そうな質問と、その正解 (または正解とみなせる条件) をペアにしたデータを用意し、システムの出力を自動で採点できるようにします。ハルシネーション対策の文脈では、「根拠に基づいているか」「出典が正しいか」「分からないときに分からないと答えられているか」といった観点を、回答の正確性とは別に測れるよう分けて設計するのがコツです。検索は取れているのに回答が誤るのか、そもそも検索が外しているのか、といった切り分けが指標から読み取れるようになります。

評価が回ると、勘ではなくデータで判断できるようになります。プロンプトを変えた、検索方式を変えた、モデルを更新したといった施策のたびに評価セットを通せば、誤回答率が下がったかどうかがすぐ分かります。改善のつもりが別の質問で悪化していた、という見落としも防げます。

さらに重要なのが、運用で実際に出た失敗を評価セットに取り込む循環です。本番でユーザーが投げた質問と、そこで起きた誤回答のログを定期的に振り返り、典型的な失敗ケースを評価セットに追加していきます。こうして評価セットが現場の難所を反映するほど、対策の優先順位が現実に即したものになります。データと評価を軸に改善を回し続けるこの進め方は、AI 駆動開発 の考え方そのものでもあります。ハルシネーション対策は一度の設計で完成するものではなく、誤回答率を定点観測しながら少しずつ下げ続ける運用としてこそ実を結びます。

業務で安全に使う AI 駆動開発のハルシネーション対策

ここまでの対策をまとめると、ハルシネーションへの向き合い方は「一発でなくす」ではなく「複数の層で取りこぼしを減らす多層防御」だということに尽きます。原因を知識不足・文脈欠落・推論ミスに切り分け、知識は RAG で供給し、根拠は出典明示で示し、出力は自己検証と外部チェックで点検し、許容できないミスは人間協調で止め、全体の誤回答率は評価ハーネスで継続的に下げる。どれか 1 つでも有効ですが、業務利用で実用水準に届かせるには、用途のリスクに応じてこれらを組み合わせることが鍵になります。

実装の進め方としては、いきなり全部を作り込むのではなく、まず用途を低リスクと高リスクに分けるところから始めるのが現実的です。低リスク用途で RAG と出典明示を入れて運用し、評価セットで誤回答率の基準値を取る。そのうえで、被害が大きい高リスク用途にだけ出力検証と人間協調を厚く重ねる。こうして「守るべきところに守りを集中させる」設計にすれば、過剰な作り込みを避けつつ安全に AI を業務へ広げられます。

FIXIT は AI 駆動開発のクリエイティブスタジオとして、RAG や AI エージェントの開発 を実プロジェクトで構築・運用し、ハルシネーション対策を含む業務利用の設計に取り組んできました。生成 AI を業務に入れたいが誤回答のリスクが怖い、PoC は動いたが本番で誤りを止められる設計に作り込めていない、といった課題があれば、発注検討の前にAI 駆動開発の発注検討ガイドをダウンロードして、対策の全体像と進め方の整理にお役立てください。