ハルシネーション対策はプロンプトだけでは足りない　AIに適当なことを答えさせない3つの判断

2026-10-28

生成AIに質問すると、それらしい答えが返ってきます。問題は、それが間違っていても同じ調子で最もらしく返ってくることです。

この現象はハルシネーションと呼ばれ、対策としてよく挙げられるのが、プロンプトの工夫、出力のファクトチェック、自社データを参照させるRAG、そして社員教育です。どれも効きます。ただ、AIを業務の中に組み込むと、これだけでは足りない部分が残ります。

注意したいのは、生成した答えを人が確認せずに利用者へ表示する場面です。社内向けか社外向けかにかかわらず、人が確認する運用か、自動で回答を表示する運用かで、必要な対策が変わります。

この記事では、ハルシネーションの起き方を押さえたうえで、よくある対策の効く範囲と残るものを整理し、設計で決める3つの判断を説明します。Enlyt（エンライト）が自治体向けに開発を進めている、ごみの分別を案内するLINEミニアプリを題材に、一般的な設計の考え方も整理します。正確な案内が必要な領域で、回答を表示する条件を考えるための例です。

ハルシネーションとは

ハルシネーション（Hallucination）とは、生成AIが、事実と違う内容をもっともらしく出力する現象を指します。日本語では、AIの「幻覚」や「妄想」という訳語が当てられることもあります。

押さえておきたいのは、ハルシネーションはAIが材料を持っていないときだけに起きるものではないという点です。次の2つが、どちらもハルシネーションとして扱われます。

米国のNISTが生成AIについてまとめた文書でも、入力から逸脱した出力や、前の発言と矛盾する出力が含まれるとされています。RAGで適切な資料を渡すことは誤回答を減らすための対策になりますが、検索で必要な情報を取り出せないことも、正しい資料を渡しても回答が食い違うこともあります。どこで誤りが生じたかを分けて見る必要があります。

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

生成AIは、質問に続く言葉として自然なものを組み立てて返します。検索した結果や渡された資料を材料にする形もありますが、材料がないときでも、もっともらしく続く文を作って返します。黙るより、続く文を返すほうが起きやすい動き方になっています。

渡した資料と食い違うことは、別の理由で起きます。資料を渡しても、その中のどこを使うかはAIが決めます。関係のない部分を拾うこともあれば、渡した量が多すぎて必要な部分が埋もれることもあります。OpenAIの解説にも、関係のない文脈が多すぎると本来の情報が埋もれてハルシネーションにつながるという説明があります。

見分けがつきにくいという性質

見分けがつきにくいというところが実務で困るところです。確かな材料があって答えたときと、材料がなくて組み立てたときで、文章の調子は同じです。人が自信のないことを言うときのような濁り方をしません。読む側からは、どちらなのか区別しにくい状態になります。

だから「おかしい答えが来たら気づける」という前提が置けません。気づけるのは、答えの内容を自分で判断できる人だけです。知らないことを聞いている人は、返ってきた答えが正しいかどうかを判断できません。

よくある対策と、その効く範囲

対策として挙げられるものを並べると、効く場所がそれぞれ違います。

プロンプトについて補足します。Microsoftは、自社データに回答を限定する設定について、モデルは渡した文書だけに頼ろうと試みるという書き方をしています。同じドキュメントには、システムメッセージはあくまで案内であり、モデルがすべての指示に従うとは限らないという記述もあります。指示は効きますが、保証ではないということです。

この4つを見ていくと、利用者が直接使う画面に出すときに足りないものが見えてきます。人が間に入らない前提で、答えを出さない判断をシステム側に持たせることです。

間違えると実害が出る領域の例

ごみの分別を例にします。不適切な分別が火災などにつながるおそれについて、公的資料で説明されている領域です。

答えが自治体ごとに違う

国は標準的な分別収集区分の考え方を示していますが、実際にどの区分を設け、何をどこに出すかは市町村が決めます。環境省の調査結果概要では「市町村の定める適切な分別区分」という書き方が使われ、通知のほうは「分別収集区分」「不適切なごみ区分」という言い方です。住民向けの案内も、お住まいの地域の捨て方のルールを確認してほしいという形になっています。

つまり、AIが一般的な知識で「これは燃えるごみです」と答えると、その人の自治体では違う、ということが起こり得ます。参照先を限定しないと成り立たない領域です。

分別の誤りが何につながると説明されているか

環境省が2026年9月に公表した調査があります。全国1,741の市町村（事務組合・特別区を含む）を対象に、回収率は100%です。

令和7年度（2025年4月から2026年3月）に、廃棄物処理の過程でリチウムイオン電池などに起因すると疑われる火災事故等は39,282件でした。この件数には発煙・発火も含まれます。このうち、職員または消防隊による消火が行われたものが9,456件です。

同じ調査では、火災事故等が発生したごみ区分も集計されています。多い順に不燃ごみ、可燃ごみ、粗大ごみです。

この表は、ごみ区分に関する複数回答の集計です。原典ではこのグラフに総数が示されておらず、39,282件の内訳として比較できるものではありません。

環境省は、リチウムイオン電池等が市町村の定める適切な分別区分に排出されず、ごみ処理施設の破砕機等で衝撃が加わった際に発火し、火災事故につながるケースが多いと考えられる、と説明しています。2025年4月に出た通知には、市町村が住民に注意喚起すべき内容として、こう書かれています。

リチウム蓄電池等の発火危険性を知らずに、誤って不適切なごみ区分に排出した場合、結果として、「火災事故の原因となり、市町村のごみ・資源物の収集、処分が停止する危険性がある」ため、住民に対して注意喚起を行うこと。

環境省通知　環循適発第2504151号

同じ通知には、火災が起きた場合は施設や車両の被害に加えて作業員に危害が及ぶ危険性がある、という記述もあります。消防庁の調査でも、令和7年（2025年1月から12月）に、廃棄されたリチウムイオン電池等を回収中のごみ処理関連施設から出火した火災は106件、塵芥車（ごみ収集車）からは107件でした。消防庁がリチウムイオン電池等から出火した火災として集計した1,297件には、この213件は含まれていません。

これらの統計は、AIの誤った回答を原因として集計したものではありません。読み取れるのは、正確な分別の案内が要る領域だということです。案内する側がAIであっても、求められる正確さは変わりません。

ごみ分別のルールは変わる

もう1つの事情は、分別のルールが改定されることです。プラスチックに係る資源循環の促進等に関する法律では、市区町村がプラスチック使用製品廃棄物の分別の基準を定め、住民への周知に努めることとされています。環境省の普及啓発ページでは、再商品化計画の認定を受けた市区町村が認定日とあわせて公表されており、分別収集の体制が順次広がっていることが確認できます。

区分が増える日を境に、それまで正しかった案内が正しくなくなります。学習した時点の知識で答える形だと、ここで遅れます。しかも遅れていることが外から見えません。もっともらしい答えが返ってくるので、古いままだと気づけないのです。

設計で決める3つのこと

利用者が直接使う画面にAIの答えを出すとき、決めることは3つに整理できます。

3つ目が、解説で省かれやすいところです。前の2つは動くものを作るために要りますが、3つ目は人が間に入らない場面で使えるかどうかを分けます。

以下では、写真や品目名から分別区分と出し方を案内するアプリを想定し、この3つを検討するときの観点を説明します。自治体ごとにルールが異なり、写真だけでは必要な条件を確認できないこともあるため、参照する情報と回答を表示する条件を分けて考えます。

1　参照先を、自治体の分別データに限る

回答の材料には、対象の自治体が確認した分別データを使います。自治体と、ルールが適用される時点をそろえ、別の自治体や改定前の情報が混ざらないようにします。インターネット検索を必要としない用途なら、その機能を持たせない構成も選択肢になります。

参照先を限定する方針は、AIへの指示だけでなく、検索対象や接続先、設定を変更できる権限にも反映します。何を参照できるかを、運用を含めて管理するためです。

設計例として、判定の流れを次の4段階に分けて考えます。

参照したルールやデータの版を記録しておくと、誤りが報告されたときに、品名の読み取り、ルールの取得、分別データの不足を切り分けやすくなります。

2　取り出せたことと、当てられることを分ける

2段階目で何か取り出せても、それで根拠が足りたとは言えません。ここが先の「適用の条件」です。

見た目や名前が似ていても、素材や大きさ、電池が入っているかどうかで出し方が変わります。似た品目のルールが見つかったことと、そのルールをこの品目に当ててよいことは、別の判断です。

そのため、取り出したルールをその品目に適用してよいか確認する段階を設けます。写真だけでは必要な条件が分からない場合は、利用者に追加の確認を求めるか、判定を保留する条件を決めます。候補を取得できたことだけで回答を表示しないよう、何を確認できたら進めるのかを具体化します。

3　止める条件を決めておく

回答を表示しない場合と、そのときに返す案内を先に決めておきます。

たとえば、対応を決めておきたいのは、写真から品目を特定できない場合です。手作りの工作、複数の素材を組み合わせたもの、何かの部品だけが写っているもの。こうしたものは、分別データのどの品目にも当てはまらないことがあります。ここで「燃えるごみに出してください」と返してしまうと、中に電池が入っていた場合に、本来その自治体が避けようとしている出し方を案内することになります。

判定できないと答えるのは、親切ではないように見えるかもしれません。ただ、分からないものを分からないと返すほうが、使う人にとっても自治体にとっても安全です。間違った案内を信じて出すより、窓口で聞いてもらったほうがよい場面があります。

出力側では、生成された分別区分を自治体が定める一覧と照合し、一覧にない区分を表示しない処理が考えられます。AIへの指示と、システム側での照合は分けて設計します。自治体のルールに応じ、本体・キャップ・ラベルなど出し方が異なる部分を分けて示す方法もあります。必要な条件を確認できた場合は案内をまとめ、確認できない場合は保留や窓口案内に切り替える、という条件を決めておきます。

なお、定義済みの区分から選ぶことと、正しい区分を選ぶことは別です。区分名の照合だけでは、一覧の中から誤った区分を選ぶ可能性が残ります。表示前の適用条件の確認と、運用中の評価・改善を分けて考えます。

間違いが見つかったあと、どこを直すか

設計で止めても、間違いはゼロになりません。残るのは、見つかったときに何を直すかという話です。

運用中の誤りを受け取る方法として、判定結果の近くに評価や報告の入口を置く設計が考えられます。利用者の報告は、そのまま正解として扱わず、自治体のルールなどと照合して確認します。原因を切り分けることで、見直す場所が変わります。

分別ルールの改定や登録漏れは、原則としてデータ側で直します。それ以外の誤りは原因を切り分けて、必要な箇所を変更して検証します。

原因を切り分けず、変更内容を記録しないまま指示文を足していくと、影響を追いにくくなります。指示文もデータも版を管理し、変更前後を比べて、必要なら戻せる形にしておきます。

変更後は、同じ評価条件で改善前後を比べます。改善した箇所だけでなく、ほかの品目や条件で悪化していないかを見るためです。修正の対象になった例に加え、未知の入力や条件の違う例も確認すると、影響を判断しやすくなります。

評価では、正しい回答、誤った回答、判定保留を分けて見ます。根拠不足を適切に保留できたのか、答えられる入力まで保留したのかも確認します。保留をすべて誤りと同じ扱いにすると、回答できる範囲と止める条件のどちらを改善すべきかが分かりにくくなります。

ほかの業務でも同じことが言えるか

ごみの分別は分かりやすい例ですが、同じ性質を持つ領域はほかにもあります。答えが組織ごとに違い、しかも変わるものです。

どの領域でも、決めることは同じ3つです。参照先をどこまでにするか。取り出した根拠を当ててよいかをどう確かめるか。根拠が足りないときに何を返すか。Enlytでは、この3つを要件を固める段階で決めるようにしています。

既製のAIサービスで足りるのか、個別に作る必要があるのかという手前の判断は、フィジビリティスタディとはでも扱っています。

よくある質問

RAGを入れればハルシネーションは解決しますか

RAG（Retrieval-Augmented Generation）は、関連する情報を取り出してAIに渡し、回答の根拠を補う作り方です。誤回答を減らすために使えますが、必要な情報を取得できないことも、正しい情報を渡しても回答が食い違うこともあります。RAGを採用する場合も、参照範囲、情報を適用する条件、回答を保留する条件を具体的に設計し、評価する必要があります。

プロンプトで「知らないことは答えないで」と書けば足りませんか

効きますが、守られる保証にはなりません。Microsoftは、自社データに回答を限定する設定について、モデルは渡した文書だけに頼ろうと試みるという書き方をしています。システムメッセージは案内であり、モデルがすべての指示に従うとは限らないとも書かれています。人が確認してから世に出す使い方なら指示で足りる場面もありますが、利用者が直接使う画面では、止める条件をシステム側に持たせる必要が出てきます。

参照先を限定すると、答えられる範囲が狭くなりませんか

狭くなります。そのうえで狭くする判断をすることがあります。ごみの分別は、自治体が定めた区分の中からしか正解が出ない領域です。範囲の外から答えを拾ってくると、もっともらしいけれどその自治体では間違っている答えになります。逆に、調べものの幅を広げたい用途なら、参照先を広く取るほうが合います。何を間違えたら困るかで決まります。

判定できないという答えが多いと、使われなくなりませんか

答えられる入力まで保留する状態が続けば、使いにくくなります。そのため、誤りや保留の報告を受け取り、入力の扱い、参照データ、適用条件のどこに原因があるかを見直します。適切に保留した件数と、回答できるはずだった件数を分けて確認すると、改善する場所を判断しやすくなります。

正解率は何%ですか

正解率は、対象品目、写真の条件、正解とするルール、保留の数え方によって変わります。導入前の評価では条件を明示し、正しい回答、誤った回答、判定保留を分けて確認します。対象の自治体のデータを使い、危険な誤案内やルール改定前後も含めて確かめることが、判断材料になります。

ファインチューニングで覚えさせるのとは違うのですか

違います。ファインチューニングはAIに追加の学習をさせて、モデル自体に覚えさせる方法です。二択ではなく組み合わせることもありますが、向く場面が違います。内容が変わり続けるものや組織ごとに違うものは、答えるたびに参照する形のほうが追いやすくなります。答え方や文体を寄せたいときは学習させる形が向きます。今回のアプリでは、改定される分別ルールを答えるたびに参照する方法を採っています。

入力したデータが学習に使われるのが心配です

どのAIを使い、どういう契約で使うかによって条件が変わるところです。入力したものが提供元側で保存されるのか、学習に使われるのか、どこに保存されるのかは、使うサービスごとに確認することになります。設計の段階で決めておく項目のひとつとして扱っています。

既製のAIチャットボットでは足りないのですか

足りる場合があります。標準機能や設定、連携機能で、必要な参照範囲と回答を止める条件を満たせるかを確認します。個別開発を検討するのは、既製サービスやその拡張では、必要な連携・検証・運用条件を満たせない場合です。連携が必要だというだけで、個別開発になるわけではありません。

AIを活用したアプリのことはEnlytにご相談ください

Enlytでは、生成AIを業務に入れたいが間違った答えが返ってきたときが心配だという段階からの相談を受けています。

相談の場では、答えの材料になるデータが社内にそろっているか、答えられないときに誰が受けるか、ルールが変わったときに誰が直すか、といったあたりをうかがっています。この3つが決まると、作るものの形はかなり絞れます。

自治体・地域向けの取り組みはEnlyt 地域コネクトにまとめています。公共機関や自治体での活用、災害時の稼働なども想定した設計などにも力を入れております。今回例としてご紹介した、自治体向けのAIゴミ分別LINEミニアプリも各自治体で導入しやすい形に整備しております。その他、住民への情報提供やコミュニケーションなどに活かせるアプリ・システムをご検討の場合にもお気軽にお問い合わせください。

この記事で参照した資料

• NIST「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile（NIST AI 600-1）」（入力から逸脱した出力や、前の発言と矛盾する出力も含まれるとされていること）
• Microsoft Learn「Azure OpenAI On Your Data」（自社データに限定する設定の書き方と、システムメッセージが案内であること）
• OpenAI「Optimizing LLM accuracy」（関係のない文脈が多すぎるとハルシネーションにつながること）
• 環境省「市町村におけるリチウムイオン電池等の処理状況調査結果（令和7年度実績）及び関連事例集の公表について」（2026年9月29日公表。火災事故等の件数と、発生したごみ区分の集計）
• 環境省「市町村におけるリチウム蓄電池等の適正処理に関する方針と対策について（通知）」（環循適発第2504151号、2025年4月15日）
• 消防庁「リチウムイオン電池等から出火した火災の調査結果の公表（令和7年）」（2026年3月26日公表。別添1）
• 環境省「リチウム蓄電池関係（概要）」（住民向けの案内が地域のルールの確認という形になっていること）
• 環境省・経済産業省「市区町村によるプラスチック使用製品廃棄物の分別収集・再商品化」（分別の基準の策定と周知、再商品化計画の認定状況）

制度や統計、各サービスの仕様は更新されます。この記事の内容は2026年10月時点で各機関の公開ページに掲載されていたものです。分別のルールはお住まいの自治体の案内をご確認ください。

久保 利彦

株式会社Enlyt代表取締役CEO。 50名規模・億円単位の開発プロジェクトにおけるPM経験を持つ実行型リーダー。 「作れるか」ではなく「事業として回り続けるか」を重視した開発を信条とし、クライアントの中長期的な成長に寄り添う支援を行っている。

View More