AIに社内マニュアルや専門資料を読み込ませて回答させる技術として、「RAG（Retrieval-Augmented Generation：検索拡張生成）」が注目を集めています。AIがもっともらしい嘘を出力する「ハルシネーション（幻覚）」に悩む企業にとって、手元の正確な文書を検索して回答を生成させるRAGは、課題を一挙に解決する特効薬のように見えるかもしれません。
しかし結論から言えば、RAGを導入するだけでAIの誤答がなくなるとは保証できません。
RAGは回答精度を高めるための有力なアプローチですが、必要な資料を取り逃したり、古い版の文書を選択したり、資料の記述を読み違えたりすることによって、依然として誤答が発生します。
本記事では、RAGがどのような仕組みで知識を参照しているのかを整理したうえで、なぜ幻覚を完全に防ぐことができないのか、その論理的な原因と限界を中学生でも理解できる平易な言葉で解説します。
なぜAIはもっともらしい嘘をつくのか？言語モデルの特性とRAGの役割
大規模言語モデル（LLM）がもっともらしい嘘をついてしまう根本的な理由は、その基本設計にあります。LLMは人間のように「事実」を記憶し、真偽を確かめながら話しているわけではありません。膨大な文章データをもとに、ある単語（トークン）の次にどの単語が来る確率が高いかを計算し、その確率分布に基づいて次の言葉をサンプリング（選択）して文章を生成しています。
そのため、文法や論理展開が極めて自然であっても、内容の真偽については一切考慮されていない文章が出力されることがあります。特に自社の就業規則や特定製品の最新仕様といった「学習データに含まれていない固有の知識」を問われた場合、モデルは統計的な言葉のつながりに引きずられ、自信満々に架空の事実を捏造してしまいます。
この問題を解決するためにモデルを追加学習させようとすると、大きな壁に直面します。巨大な言語モデルの全パラメータを再学習させるには莫大な計算コストと時間がかかります。LoRAなどのパラメータ効率学習（PEFT）を用いて一部の重みだけを調整する手法もありますが、日々改定される社内規程や製品在庫のように頻繁に変わる事実情報をモデルの重みに直接焼き込み続ける運用は現実的ではありません。
そこで考案されたのが「RAG（検索拡張生成）」です。RAGの基本思想は、知識をモデルの記憶（重み）に無理に覚え込ませるのではなく、外部の信頼できるデータベースから必要な文書を検索し、それを「参考資料」として手元に置いた状態で回答を作成させることにあります。
この手法の有効性は、Lewisらの代表的な論文（NeurIPS 2020）によって体系的に示されました。Lewisらは、事前学習済みの配列変換モデル（BART）と密ベクトル検索（DPR）を組み合わせることで、知識集約型自然言語処理タスクにおいて高い精度を達成できることを実証しました。そして何より、モデルの全パラメータを再学習することなく、外部文書を差し替えるだけで最新の知識を反映できるという利点を明らかにしました。
例えるなら、従来のLLMが「教科書を持ち込めない記憶頼みの試験」を受けていたのに対し、RAGは「図書館から関連する本を探し出して机の上に並べ、それを見ながら答案を書くオープンブック形式の試験」に変える仕組みだと言えます。
RAGの基本処理フロー：事前準備と質問処理の3ステップ
一般的な文書参照型プロンプト結合方式のRAGは、大きく「事前のインデックス化」と「質問後の3ステップ」に分かれます。
RAGを導入しても、AIのニューラルネットワークの重みが動的に書き換わるわけではありません。検索エンジンと言語モデルを連携させ、適切な文書を抜き出してプロンプト（指示文）の中に埋め込んでいるだけです。その具体的な処理フローは次のとおりです。
1. 事前のインデックス化（準備工程）
業務文書を検索可能な形に変換して蓄積しておく前処理です。
- 文書の分割（チャンク化）：長い業務マニュアルをそのまま検索にかけると精度が落ちるため、意味のまとまりごとに分割します。チャンク長は設計によりますが、設定例として「1チャンクあたり500文字程度」の段落単位で区切る手法が一般的です。
- ベクトル化（埋め込み表現の生成）：分割した各テキストを、専用のモデルを用いて意味を表す数値の列（ベクトル）に変換します。
- データベースへの登録：生成されたベクトルを、類似度を高速に計算できるベクトルデータベース（ベクターDB）に保存し、索引を作成します。
2. 質問後の3ステップ（リアルタイム処理）
ユーザーが質問を入力した瞬間に、システム内部で以下の3段階が順次実行されます。
- ステップ1：検索（Retrieval）
質問文を即座にベクトル化し、ベクターDB内で質問の意味に近い文書チャンクを探し出します。設定例として、類似度が高い上位3〜5件程度のチャンクを候補として抽出します。
- ステップ2：入力構成（Augmentation）
検索された文書チャンクを取り出し、ユーザーの質問文、および「提示された資料の内容に基づいて回答してください」といったシステム指示文と結合して、LLMへ送信するプロンプトを組み立てます。
- ステップ3：生成（Generation）
プロンプトを受け取ったLLMが、与えられた参考資料の記述を手がかりにして最終的な回答文を生成し、ユーザーに提示します。
このように、RAGは「検索で資料を取り出し、プロンプトに貼り付けて読ませる」手順を踏むため、回答の成否は「検索が正しい資料を持ってこられたか」と「LLMがその資料を正しく読めたか」の両方に依存しています。
失敗はどこで起きるのか？4つの独立した失敗パターンと説明図の読み方
RAGがどのような段階で失敗し誤答を生むのか、その構造を整理したのが次の概念図です。
説明図の読み方と注意点
この図を読み解くうえで、重要な前提がいくつかあります。
第一に、図に示された「検索」「選択」「生成」「引用」の各段階は、必ず一本の避けられないドミノ倒しのようにエラーが増幅していく連鎖ではありません。ある段階で軽微なノイズが含まれていても言語モデルが正しく無視して正答できる場合もあれば、検索が完璧であっても生成の段階だけで誤答が生じる場合もあります。各段階において、それぞれ独立した失敗パターンが個別に、あるいは複合して発生し得る構造として捉える必要があります。
第二に、「選択」とは検索で得られた候補チャンクの中から、プロンプトに含める情報を絞り込んだり優先度順に並べ替えたりする処理を指します。これは前節で説明した「入力構成」の工程と整合する処理です。
第三に、「引用」という表示は、すべてのシステムで独立したプログラム部品として実装されているとは限りません。生成された回答が本当に元資料に依拠しているかを客観的に測定するための、評価・検証上の概念整理として位置づけられています。
各段階で発生する具体的な失敗パターン
GaoらによるRAGのサーベイ論文（arXiv 2023）でも整理されているように、外部文書を検索してモデルに統合するシステム全般において、検索から生成に至る各段階に固有の課題が存在します。
- 検索の失敗（取り逃し）
質問文の表現と文書内の記述が異なっていたり、キーワード一致だけで文脈が拾えなかったりすると、回答に必要な核心文書が検索結果から漏れてしまいます。必要な資料が届かなければ、根拠に基づく回答を作成することは難しくなります。
- 選択の失敗（版の不一致・ノイズの混入）
検索結果の中に、過去に失効した古いマニュアルや施行前の改定案が紛れ込む場合があります。施行日や有効期限、版数の管理が不十分な場合、システムは日付の前後関係を判断できず、古い情報をプロンプトへ投入してしまいます。また、無関係なノイズが多く選ばれると、モデルの判断を狂わせる原因になります。
- 生成の失敗（資料の誤読・推論の飛躍）
正しい資料が入力されていても、言語モデルが文章中の但し書きを見落としたり、資料に書かれていない因果関係を勝手に補完したりして誤った結論を導くことがあります。
- 引用の失敗（無根拠な参照表示）
回答文中に参照リンクが付与されていても、そのリンク先の資料が回答内容を論理的に支持していない現象です。
このように、RAGは外部資料を検索して利用する仕組みであるものの、資料の取り逃し、古い情報の選択、資料の誤読などが生じるため、導入するだけで誤答がなくなるとは保証できません。
資料があっても間違える理由：推論の飛躍と「中央の見落とし」
「正しい資料さえ渡せばAIは正しく答える」とは限りません。正解の根拠が目の前にあっても誤答が生まれる主因として、「推論の飛躍」と「中央の見落とし」があります。
事実の正確性・資料への忠実性・推論の飛躍の違い
AIの出力を評価する際は、以下の3つを区別する必要があります。
- 事実の正確性：現実の客観的な事実と合致しているか。
- 資料への忠実性：与えられた資料の記述に厳密に従っているか。
- 推論の飛躍：資料に書かれた事実を超えて、勝手な仮定を付け足していないか。
例えば、製造工場の運行管理に関する架空のシナリオを考えます。
提示された資料の記述（架空例）： 「本日10時15分、第2工場の主要製造ラインが設備点検のため緊急停止した。」
この資料をもとに「製品Aの出荷予定はどうなりますか？」と問われた際、LLMが次のように答えるケースがあります。
誤った回答例： 「主要ラインが緊急停止したため、本日予定されていた製品Aの出荷は遅延します。」
これは推論の飛躍です。資料には「ラインが停止した」としか書かれておらず、在庫の有無や出荷への影響は記載されていません。AIが「工場停止＝出荷遅延」と勝手に文脈を補完してしまったのです。資料に忠実な回答は次のようになります。
適切な回答例： 「資料には第2工場のライン停止は記載されていますが、在庫状況や出荷への影響についての記載はないため判断できません。」
同様に、架空の勤務規程で「コアタイムは11時から15時とする」とだけ書かれている資料に対し、AIが「始業時間は一般的な9時となります」と勝手な推測を補うのも推論の飛躍の典型です。
長文の中央部で精度が落ちる「Lost in the Middle」現象
さらに、提示する資料が長くなった際に発生する構造的な課題があります。
複数の文書をプロンプトに詰め込むと、入力文は長大になります。このとき、正解根拠がどこに配置されているかによって精度が大きく変動します。
Liuらによる研究論文（TACL 2024）では、複数の言語モデル（MPT-30B-Instruct、LongChat-13B、GPT-3.5-Turbo-16kなど）を対象に、複数文書QAやKey-Value取得タスクを用いて検証が行われました。その結果、長い入力文書群の中央部に正解根拠が存在する場合、冒頭や末尾に存在する場合と比較して回答精度が著しく低下する傾向（Lost in the Middle現象）が報告されています。
評価対象となったモデル群において、入力系列の中央に埋もれた情報を適切に抽出する能力が低下する傾向が確認されたのです。
なお、この現象は評価対象となったモデル群や特定タスクにおける傾向報告であり、すべてのモデルの内部注意機構を一律に断定するものではありません。最新アーキテクチャでの緩和度合いは調査が継続中ですが、「関連資料をただ大量に詰め込めばよいわけではない」という実務上の重要な示唆を与えています。
規程の誤読と引用リンクの罠：AIがもっともらしく間違う具体例
言語モデルは、複雑な条件分岐や例外規定が絡み合う規程の解釈でつまずきがちです。典型的な誤読の例と、「引用リンクの罠」を検証します。
規程の誤読：条件の混同と見落とし
次の架空事例で設定した規程をもとに考えます。
出張旅費規程 第7条（この架空事例で設定した規程）： 「第7条（交通費の精算）交通費の精算には原則として領収書の添付を必須とする。ただし、自動券売機等で領収書が発行されない1,500円未満の近距離交通費（電車・バス）に限り、乗車区間および運賃を記載した出張精算書の提出をもって領収書に代えることができる。」
この規程に対し、「タクシーを利用したが領収書を紛失した。運賃1,200円は領収書なしで精算できるか？」と質問したとします。するとAIは、次のように誤答することがあります。
AIの誤った回答： 「はい、精算可能です。出張旅費規程第7条により、1,500円未満の交通費については、乗車区間と運賃を記載した出張精算書を提出すれば領収書に代えることができます。」
この誤答の原因は次の3点です。
- 不発行と紛失の混同：自動券売機等での「不発行」という客観的条件を、利用者の「紛失」と取り違えた。
- 交通手段の限定条件の見落とし：例外が「電車・バス」に限定されている条件を見落とし、タクシーに適用した。
- 金額条件への過度な着目：「1,200円は1,500円未満である」という数値条件の一致だけに引きずられた。
引用リンクの存在は「読んだ証拠」にならない
回答末尾に「［出典：出張旅費規程 第7条］」と表示されていても、鵜呑みにしてはいけません。引用の検証には3段階の区別が必要です。
- リンクの実在：提示されたURLやパスが実在するか。
- システムの取得・参照：検索エンジンが実際にその資料をヒットさせ、プロンプトに入力したか。
- 回答内容の論理的裏付け：引用元の文章が、AIの回答内容を論理的・事実として支持しているか。
多くの誤答では、1と2を満たしていても3の論理的裏付けが破綻しています。AIが条文を誤読したまま、無根拠に引用ラベルを貼り付けているのです。
Gaoらによるベンチマーク「ALCE」の論文（EMNLP 2023）でも、各種LLMを検証した結果、言語モデルが回答中に引用文献の参照リンクを提示していても、その引用が回答文の内容を論理的・事実として完全に支持しているとは限らず、引用精度や支持率に無視できない不備が生じることが示されています。
精度を高める現実的な改善策と運用の工夫
RAGの限界を克服し実用精度を高めるには、技術改善と運用の両面からのアプローチが必要です。ただし、これらは「万能の保証」ではなく、リスクを軽減するための改善策および評価対象です。
1. 検索と選択の強化
- ハイブリッド検索：意味を捉えるベクトル検索と、型番や専門用語を捉えるキーワード検索（BM25等）を併用し、検索漏れを防ぎます。
- リランキング（再順位付け）：初期検索の候補を精密なモデルで再計算し、核心文書を最上位に並べることで「中央の見落とし」を緩和します。
- メタデータ管理：版数、施行日、失効日、対象部門をメタデータとして付与し、現行有効な文書のみを機械的にフィルタリングします。
2. 生成制御と事後検証
- 回答保留（Abstention）の指示：プロンプトで「資料に明確な根拠がない場合は推測せず、『資料に記載がないため不明』と回答すること」を徹底し、推論の飛躍を抑制します。
- 自動照合（NLI）：回答生成後、自然言語推論モデル等を用いて回答文が参照資料から論理的に導出されているかを自動照合します。
3. 人間による確認（Human-in-the-loop）
確率的な不確実性をゼロにできない以上、人間の確認作業が不可欠です。原文を参照し、適用条件、除外規定、数値が質問者の条件に合致しているかを人間が照合します。RAGは「自律的な決定者」ではなく「調査アシスタント」として位置づける必要があります。
実務でよくある3つの疑問（FAQ）
- Q1. ファインチューニングを行えばRAGは不要ですか？
不要にはなりません。 ファインチューニングは文体や手順の体得に適していますが、頻繁に改定される業務マニュアルの事実情報をすべて追加学習で追従させることは困難です。文書の差し替えで知識を更新できるRAGとの併用が実務上の基本です。
- Q2. コンテキスト長が広がれば検索は不要ですか？
検索は不可欠です。 膨大な文章を一度に入力すると「中央の見落とし」のリスクが高まり、API費用や応答待ち時間も悪化します。必要な箇所を絞り込んで渡す検索・選択工程は依然として重要です。
- Q3. 誤答事故を防ぐ最低限の運用ルールは何ですか？
「AIの回答文だけを根拠にした業務判断を禁止する」ことです。 出力に添えられた根拠資料のリンクを人間が開き、条件の合致を照合することを必須プロセスとすることが最大の安全策です。
まとめ：過信を防ぎ実務で成果を出すために
RAGは、言語モデルを「記憶頼みの回答者」から「手元の信頼できる資料を参照して答える調査員」へと進化させる優れた技術です。社内の知識集約型タスクの効率を大きく引き上げる力を持っています。
しかし、資料を参照できることと、内容を完璧に理解し推論の飛躍なく判断できることとの間には隔たりがあります。必要な資料の取り逃し、古い版の混入、条件の誤読、無根拠な引用といった失敗は、RAGを導入するだけでゼロになるわけではありません。
RAGを「幻覚を止める特効薬」として過信するのではなく、仕組みと限界を正しく理解すること。そして、適切な検索改善と人間による原文確認を組み合わせることこそが、生成AIを実務で安全に役立てるための確実なアプローチです。