#27 「生成AIが見せる幻想ハルシネーションとその対策RAGについて解説」
デデデータ!!〜“あきない”データの話〜第17回「生成AIが見せる幻想ハルシネーションとその対策 - RAG自律型エージェント元年 - 」話の台本・書き起こしをベースに、テキストのみで楽しめるようにnote用に再構成したものです。podcastで興味を持った方により、理解していただくために一部、リファレンスをつけています。
生成AIと“人間の揺らぎ”の交点
AIは、人間の仕事を根こそぎ奪う脅威なのだろうか。
昔から「ボーカロイドが台頭したら歌手が不要になるのでは」という声があった。AIナレーターが登場したときも、同じ議論があった。だが実際、宇多田ヒカルの声の震えや、ライブ会場で生まれる熱気は、今なおファンを魅了している。美空ひばりのAIの「それっぽい声」では物足りない。あの細やかな振動や人間臭さは、単なる数値パラメータでは測れない個性だと感じる。いわば、本物の歌手や声優にしか宿らない“揺らぎ”だ。
しかし、生成AIにはまぎれもない実用価値がある。たとえば業務効率化。仮のナレーションや原稿の下書きならば十分すぎるほど使えるし、質問応対をAIに任せれば24時間対応ができる。AIが苦手な部分と得意な部分をきちんと切り分けることで、人間のクリエイティビティを引き立てる可能性が広がる。
今回は、私が日々感じている「生成AI動向」と「ハルシネーション問題」と「RAG(リトリーバル・オーグメンテッド・ジェネレーション)」の展望を語りたい。膨大な非構造データをどう処理し、どう活かすか。そこにAI導入の成否がかかっていると考えている。（この台本は、2024年5月時点のものであり、RAG全盛期の時である）
第一章：AIがうそをつく？――ハルシネーションの罠
生成AIを触っていて一番驚くのは、堂々と間違った情報を返してくるケースがあることだ。これをハルシネーション（幻覚）と呼ぶ。
たとえば「渋谷のおすすめカフェを教えて」と投げかけると、存在しない店舗や適当な住所をいとも簡単に返してくる。「すみません、知らないので答えられません」とAIが回答してくれればいい。だが、生成AIはあくまで“それっぽさ”を高めることに特化しているので、たとえ事実と違っていても確信めいた調子で語ってしまう。
「AIは完璧」「AIを信用しすぎるのは危険だ」という二つの極端が、しばしば議論に上る。私が見てきた現場でも、このハルシネーションに気づかず大変な目に遭うことがある。
企業がAIを導入する際に「とにかく楽をしたい」「AIなら全部やってくれる」と思い込む人がいるが、そこに落とし穴が潜む。
AIの間違いを人間がフォローする仕組みづくり。具体的には、問合せ内容を限定して回答の根拠を明示させるようにする、クローズドクエスチョン化といった一工夫が欠かせない。
幻のカフェ情報に振り回された経験はないか？
少し前、ある人が「AIを使って社内レクリエーションで行くカフェを探しました！」と大はしゃぎしていた。URLも掲載されていたが、怪しげなサイトへリンクしていて、場所が実在しない。結局、付近を歩き回る羽目になった。彼はAIが出してきた情報を一ミリも疑わず、「これが未来だ！」と信じていた。
そのとき強く感じた。AIの回答には「身内に虚言壁のある天才がいる」くらいの警戒心を持ったほうがいい。天才肌ゆえに膨大な情報を持っているが、ときどきとんでもないホラ話を言う。そんなイメージだ。
学習データにない情報は平気で捏造する。だからこそ、事前に信頼できるソースを指定してやる必要がある。でもどうやって？
第二章：RAGとは何か――幻覚抑止の切り札
ハルシネーションを防ぐ方法の一つにRAGがある。
Retrieval-Augmented Generationの略だ。
生成AIが回答を組み立てる際、無制限にネット情報を拾ってくるのではなく、事前に用意されたデータベースから必要な文章を検索して参照させる。これにより「これは公式ドキュメントに書かれている情報です」「このページにこう書かれています」という根拠を提示できるようになる。これがRAGという技術だ。
たとえば社内規約のページやマニュアルをベクトルデータベース化する。従来のデータベースはテーブル形式が基本だったが、RAG用には意味ベースの検索が必要になる。たとえば「返品対応について知りたい」と入力すると、返品ポリシーを記した項目を“文脈”から判断して見つけ出す。データベース内の文章をベクトルで表現して、「似ている文書」を検索する。
ここで「AIが推測した結果」でなく「明示的に参照した文書」へ回答を限定する。これがRAGの肝。幻覚を大幅に抑え、企業として回答の正確性を担保しやすくなる。
RAGを導入した顧客サポートの事例
ある企業の顧客サポート部門でRAGを導入したことがある。従来はFAQが膨大で、マニュアルから該当ページを探すのに時間がかかっていた。顧客から「製品の電源が入らない」という問い合わせが来るたび、人間オペレーターがつぶさにマニュアルを読みあさっていた。
そこでRAGを組み合わせた生成AIを入れ、「この問い合わせに関連するマニュアルを検索し、その引用範囲に基づいて回答を作りなさい」と指示した。
すると回答に信頼度が生まれた。なぜなら、裏付け文書が提示されるからだ。単なる“それっぽい”情報でなく、「このマニュアルの第○章、第×ページに記載がある」という根拠付き。結果、問い合わせ対応の満足度もアップ。なによりオペレーターの負荷が大幅に削減できた。（今最もおおい生成AI活用のユースケース）
第三章：企業での生成AI活用――非構造データが鍵
私はDXプロジェクトに携わる中で、企業内には膨大な「非構造データ」が埋もれていると実感している。PDF、画像、音声、議事録、メールなど。これらは検索性が低く、活用されないまま放置されがち。
生成AIを導入すれば、一見バラバラに見える資料から重要な知見を統合できる。が、そのためには「RAG用のベクトルデータベース」に格納する下準備が要る。つまり、非構造データを構造化し、文脈検索ができるようにする。
たとえばアパレル企業なら、商品画像とテキスト説明をセットでベクトル化する。
すると「春物のジャケットで通気性が高く、オフィスカジュアルで使える商品を探してる」という検索にも対応可能。従来のキーワード検索とは異なり、概念的に近い商品を発見しやすくなる。
一度やらかしたことがある非構造データの整理ミス
PDFや画像、Excelを無造作にクラウドへ投げ込むだけでは、RAGが使い物にならなかった。過去に経験した失敗談だ。すべての資料を単に「DATA」フォルダに放り込んでいたため、検索効率が酷かった。
AIは文書の意味を解析してくれるとはいえ、重複する情報や冗長な文面が大量に混在していると、誤った部分を拾う恐れが大きくなる。そこで重要なのは、文書単位でのタグ付け。営業資料には「営業」「製品概要」などのタグを付し、FAQには「問い合わせ」「トラブルシューティング」といった分類を与える。そこから全文を分割し、ベクトル化する。こういった一手間が大切。
「AIだからデータを適当に突っ込んでも全部やってくれる」という期待感。それが最大の落とし穴だと思う。AIは魔法ではない。地道にデータ整理が必要なのだ。
第四章：自社LLMか、外部モデル＋RAGか
最近、「自社専用のLLMを構築したい」という企業が増えている。オープンAIやGoogleのモデルを使うのも一つの手だが、社外へ渡したくない機密情報があるとか、業種特化の知識を学習させたいという要望があるからだ。
コストは下がりつつある。3000万～数千万円程度の予算で、自社LLMを構築することも可能になってきた。ただし、運用やメンテナンスの負荷は決して小さくない。一方、「大規模モデルは外部サービスに任せ、企業側はRAGをうまく組み合わせる」という戦略もある。
私が推奨するのは、機密性と予算のバランスを見て決めること。
社内データを大量に扱い、絶対に社外流出を避けたいなら自社LLM。
少量の非構造データをさくっと活用したいだけなら、既存のAPIを使ってRAGを載せるほうが楽。どちらにしても、データの整備と「プロンプトエンジニアリング（適切な問いの設計）」がカギになる。（最近では、AIエージェントの機能も増えているので、この点ハードルが一気に下がった）
第五章：今後の生成AIトレンド予測――デバイス、クラウド、マルチモーダル
生成AIは、スマホやウェアラブル、クラウドあらゆるデバイスへ組み込まれていくと予想している。AppleのVision ProなどXRデバイスに組み込まれる日も近い。
「写真を撮るだけで、部屋のレイアウトを提案してくれる」「位置情報から、次に行くべき店を予測してくれる」など、多様なマルチモーダル活用が加速。私は、音声・映像・文章の垣根がますます薄れていくと見ている。
AIが勝手に先回りして提案する世界。たとえば自動車が走行データを蓄積し、「ドライバーが好きそうなスポット」「訪問しそうな取引先」をレコメンドする。かつてのナビのように、目的地を手動入力する必要がほとんどなくなる。
ただし、ユーザーが本当に望むプライバシー配慮や自律性も忘れてはならない。勝手に何でもかんでも提案してきたら鬱陶しいし、AIがデータを勝手に収集しすぎると不安も大きい。便利さと安心感のバランスが重要だ。
第六章：10のAIサービス予言
いま、私が面白いと思うサービス領域を箇条書きする。あと2年もすれば実現しそうなものばかりだ。
お買い物エージェント
家族の嗜好やアレルギーを学習し、レシピと連動して食材を自動注文。調理手順までまとめて提案。旅行エージェント
旅行レビューやSNS投稿を解析。サウナ、アニメ、歴史など細やかな趣味に合わせたプランを自動生成。金融ポートフォリオ診断
家計簿や決済履歴を読み込み、最適な金融商品をレコメンド。無駄なサブスクを指摘してくれるかもしれない。3D住宅設計
キーワードと予算を入れると、自動でオフィスや新築住宅プランを3D化。設計士を補助するDXに。美容師AIサポート
自分の写真と理想スタイルを合成し、ヘアカット後の姿をシミュレート。得意な美容師も検索。自動車のドライブサポーター
毎日の走行ログから、ルーティン外の訪問先を提案。Teslaあたりなら近いうちにやりかねない。部屋のコーディネート提案
スマホで部屋をスキャンし、最適な配置や買い換え推奨アイテムを提示。引越しの面倒も激減。アパレルバーチャル試着
自分の3Dモデルに服を着せ替え、オンライン購入まで一気に実行。ZOZOSUITが一歩進んだ世界。教育×脳波データ
脳波や集中度をリアルタイム解析し、学習コンテンツを最適化。疲れたら休みを入れる、そんな“相棒”AI。バーチャルパートナー
好きな俳優やアイドルを模した“XR空間の恋人”を作り、デート体験を楽しむ。需要があるのか疑問だが、意外と盛り上がるかもしれない。
第七章：データ整理がすべての起点
ここまでいくつかのトレンドやサービスを列挙した。いずれにせよ、前提となるのは「企業内に散在するデータをどう扱うか」。どんなに最新の生成AIを導入しても成果が出にくい。
重複、冗長、誤記載、整合性のないフォーマットが混ざると、AIが大混乱を起こして誤回答を連発する恐れがある。だからこそベクトルデータベースへの格納、文書分類、タグ付け、メタ情報付与が必須。
そしてRAGと組み合わせることで、「この問い合わせの答えはどの文書を参照しているのか」をトレースできる。ブラックボックスになりがちなAIの出力も、かなり透明性が高まる。
終章：行動を起こすのは、今
繰り返しになるが、データ整備を後回しにしてはいけない。AIの力を借りるなら、まずは紙資料やPDF、画像、メール、そんな非構造データを洗い出し、RAGで使える形へ落とし込むところから始めたい。
ハルシネーションを起こさずに回答精度を高めるコツは、狭い範囲のクエリに対し、確実な一次情報を参照させること。そして、定期的にモデルをアップデートし、誤回答をフィードバックして学習し直すこと。対話による追加質問、プロンプトエンジニアリングの工夫も重要。
この地道なステップこそ、生成AIを“幻想のおもちゃ”で終わらせず、立派なビジネスツールとして育てる礎だと思う。企業側が本気で取り組めば、応用の幅は際限なく広がる。
2年後、予想した10のAIサービスがどこまで実現するか。5年後、どんな世界が普通になっているか。常に楽しみながら、手を動かしながら学び続けたい。データとAIと人間が共鳴し合う世界。私はそれこそが、次のステージのDXだと信じる。
専門用語解説
1. ハルシネーション（Hallucination）
生成AIが、事実として存在しないデータや誤った情報をあたかも本当のことのように答えてしまう現象。質問に対して「わかりません」と言わず、“それっぽい”回答を優先してしまうがゆえに起こる。とくにChatGPTなどの大規模言語モデルで問題視される。
モデルの学習目的が「次に来そうな単語を予測する」ことであり、正確な知識の真偽を検証するわけではない。
企業利用では、誤情報が致命的な影響を与える場合もあるため、対策が必須。
2. RAG（Retrieval-Augmented Generation）
Retrieval-Augmented Generation の略称。生成AIが文章を生成する際に、外部のデータソース（ベクトルデータベースなど）から関連情報を検索（Retrieval）して、その情報をもとに文章を生成（Generation）する仕組み。
RAGの目的
ハルシネーション（幻覚）を抑えること
回答の根拠や出典を明示しやすくすること
専門領域や機密領域のデータを、安全かつ正確に活用すること
具体例
企業内のFAQデータベースやマニュアルをベクトル化し、該当箇所だけを参照して回答させる。
医療・金融分野など、公開されていない独自データを使いたいが、ハルシネーションを起こすリスクを抑えたいときにも有効。
3. LLM（Large Language Model）
大規模言語モデルの総称。ChatGPTやGPT-4、BERT、LLAMAなどが代表例。膨大な文章データを学習し、自然な文章生成や高度な理解を可能にする。数十億～数千億のパラメータを持ち、汎用的にいろいろな分野の質問に対応できる。あくまで確率的に最適な単語を予想する仕組みであるため、真偽の検証は別途必要。
4. プロンプトエンジニアリング（Prompt Engineering）
生成AIに渡す「指示文（Prompt）」を最適化する手法。どのように質問を投げるか、どういう追加情報を与えるかで回答の質が大きく変わる。
具体的な工夫
明確に「使用可能なデータソース」「解答のフォーマット」「必要な根拠」を指定する。
追加のプロンプトを使い重層的に情報を引き出す。
不要なハルシネーションを防ぐため、わからない場合は「わからない」と答えるよう促す。
5. ベクトルデータベース（Vector Database）
画像、テキスト、音声などの非構造データを、高次元ベクトル（数値列）に変換して格納・検索できるデータベース。RAGの検索パートでよく使われる。
目的
単純なキーワード検索とは異なり、“意味的”に近い文書や類似情報を素早く検索できる。
AIが生成する埋め込みベクトルをそのまま使い、類似度（コサイン類似度など）で近い文書を見つけ出す。
6. マルチモーダル（Multimodal）
テキストだけでなく、画像や音声、動画、センサー情報など、複数の異なるデータ形式を扱う仕組み。生成AIが文字情報＋画像情報を同時に解釈できるようなケースを指す。
7. 非構造データ（Unstructured Data）
あらかじめ行や列などのフォーマットが決まっていないデータ。メール、画像、PDF、議事録、SNS投稿、動画などが典型。従来のテーブル形式データベースでは扱いにくいため、AIを活用するためには、前処理やメタ情報付与、ベクトル化などのプロセスが必要。
8. 自律型エージェント（Autonomous Agent）
人間の介入なしでタスクを遂行し、学習・意思決定するシステム。RAGと組み合わせて、問い合わせ対応やデータ分析、営業支援を“自動運転”のようにまわす事例が増えつつある。
目標指向：設定されたゴールを達成するために最適な行動を自動で選択。
適応性：環境や入力の変化に合わせて学習・進化する。
対話性：ユーザーや別のシステムとやりとりをしながら情報を更新。
まとめ
ハルシネーション ＝ AIの幻覚 → 誤情報に要注意
RAG ＝ 外部検索を組み込んで幻覚を減らす仕組み
LLM ＝ 大規模言語モデル。専門特化か汎用かを選ぶ場面が増加
プロンプトエンジニアリング ＝ 質問設計でAIの精度が激変
ベクトルデータベース ＝ 意味検索の基盤技術。非構造データを生かす要
マルチモーダル ＝ 画像/音声/文章を一体で扱う、次世代AIのキーワード
自律型エージェント ＝ 指示なしでもタスク遂行。今後の自動化エンジン
参考論文
Retrieval-Augmented Generation for Knowledge-Intensive NLP
https://arxiv.org/abs/2005.11401
おまけ：検索エンジンとRAGのアプローチの違い
RAG検索（Retrieval-Augmented Generation）は、従来の検索エンジンとは違い、「検索して結果を一覧で見せるだけ」ではなく、「見つけた情報を組み合わせて回答を生成する」点が大きな特徴だ。言い換えると、RAG検索はまずAIがクエリに合う文書をベクトル検索で見つけ、その内容を要約・統合して回答を生成する仕組み。
従来の検索エンジンはキーワードマッチングが中心で、入力されたクエリと各Webページや文書の単語の一致度をランキングし、関連性が高いページのリンクを提示する。ユーザーはそのリンク先を自分で確認し、必要な情報をまとめる必要がある。いわば、検索エンジンは「最適と思われる複数の候補」を示すだけで、実際に“答え”を作るのは利用者の作業になる。
一方、RAG検索では検索（Retrieval）と生成（Generation）が一体となって動作する。まずはベクトルデータベースなどを用いて、意味的に近い文書やテキスト断片を検索し、その結果をもとに生成AIが要約や回答文を生成する。たとえば企業内のFAQやマニュアルを参照させ、「質問への最適解」を一つの文章として提示できる。ユーザーがわざわざ個々の文書を読み比べなくても、最終的な答えをすぐに得られるのが大きな特徴だ。
たとえば、社内問い合わせの事例を考えてみる。従来の検索エンジンでは「新商品の返品規約を教えて」という質問をすると、ファイルサーバやナレッジベースから「返品規約」というキーワードを含む文書をいくつか提示するだけ。社員はそのリンク先をすべて開いて該当箇所を探し、必要に応じて要約を作る必要があった。情報源が多数あるほど手間がかかり、見落としも起こりやすい。
一方でRAG検索の場合、まずクエリ（質問）に近い文書をベクトル検索でピンポイントに探し出す。たとえば「〇〇規約.pdf」や「返品FAQ.docx」などのファイル内テキストを意味的に解析して、最も関連性の高い部分を抽出。次に、生成AIがその抽出部分をもとに回答をひとつの文章としてまとめて返してくれる。つまり、社員は「返品規約について詳しく知りたい」と聞くだけで、必要な項目を簡潔に整理した回答を即座に得られる。そのうえ回答の末尾に「情報源：〇〇規約.pdfの3ページ目」など引用が付けられる設計にすれば、裏付けを確認するのも容易だ。
このように、RAG検索は従来の「リンク一覧を受け取って自力で読み解く」段階を大幅に削減し、「検索＋要約＋引用提示」をワンストップで実現する。企業の問い合わせ対応やFAQ検索に導入すると、回答の効率化と正確性の向上が期待できる。ハルシネーションを防ぎやすいよう検索対象を公式文書に限定する運用も行いやすい。これが、従来型の検索エンジンとは一線を画すRAG検索の強みといえる。