2026年9月14日時点の公開ドキュメントを根拠に、なぜRAG（Retrieval-Augmented Generation）が必要になるのかを、LLM単体の限界から初心者向けに整理します。前段の「ハルシネーション」「次トークン予測」とつながる話です。
この記事のゴールは、「RAG＝なんとなく精度が上がる魔法」ではなく、「モデルに足りない知識を、検索してプロンプトへ足す設計」として説明でき、プロンプト改善やファインチューニングといつ使い分けるかを選べる状態になることです。
結論：足りないのは「記憶」か「振る舞い」か
| 観点 | 押さえる事実 | 設計で先に決めること |
|---|---|---|
| RAGの正体 | 回答前に関連文書を検索し、プロンプトへ入れてから生成する | 「何を検索対象にするか」を先に決める |
| LLM単体の限界 | 学習以降の事実・非公開知識・社内文書は重みの中に無い | その知識が必須ならRAG候補 |
| ハルシネーション | 知らない内容を推測で埋めやすい | 根拠なしの断言を禁止する |
| 使い分け | 文脈不足はRAG、書式・口調・手順のブレは別レバー | 失敗原因を分けてから手を打つ |
| 限界 | 無関係な文脈を大量に渡すと精度が下がることもある | 検索品質も評価する |
迷ったら次の一文で十分です。
RAGはモデルを賢く書き換える手法ではなく、必要な資料を引いてから答えるための仕組みである。
1. RAGとは何か（名前の分解）
確認できる事実
- OpenAI の精度最適化ガイドは、RAG を次のように定義しています。回答前にコンテンツを Retrieve（検索） し、プロンプトを Augment（補強） してから Generate（生成） する、という流れです（Optimizing LLM Accuracy）。
- 目的は、ドメイン固有の文脈をモデルへ渡してタスクを解けるようにすることです。多くの大規模な導入でも、プロンプト設計と RAG だけで進められた例があると同ガイドは述べています。
原文: "RAG is the process of Retrieving content to Augment your LLM’s prompt before Generating an answer."
日本語訳: 「RAGとは、回答を生成する前にコンテンツを検索してLLMのプロンプトを補強するプロセスである。」（出典: OpenAI — Optimizing LLM Accuracy）
実務解釈
初心者向けの覚え方は次のとおりです。
質問
↓
関連文書を検索（Retrieval）
↓
見つかった抜粋をプロンプトに足す（Augment）
↓
LLMが回答を生成（Generate）
LLM単体は「頭の中の知識だけで答える」。RAGは「必要な資料を開いてから答える」に近い、という対比で十分です。埋め込みやベクトルDBの詳細は後続トピックです。まず「なぜ検索を挟むのか」だけを固めます。
2. LLM単体の限界（ここがRAGの入口）
確認できる事実
OpenAI の同ガイドは、精度改善を「文脈の最適化」と「LLMの振る舞い最適化」の2軸で整理しています。文脈側が必要になる典型は次の3つです。
- 学習データに無かった知識が要る
- 知識が古くなっている
- 非公開・社内固有の情報が要る
原文: "You need to optimize for context when 1) the model lacks contextual knowledge because it wasn’t in its training set, 2) its knowledge is out of date, or 3) it requires knowledge of proprietary information."
日本語訳: 「次の場合は文脈の最適化が必要だ。(1)学習セットに無かったため文脈知識が足りない、(2)知識が古い、(3)非公開情報が必要。」（出典: OpenAI — Optimizing LLM Accuracy）
Anthropic も、高度なモデルでも事実誤認や文脈矛盾（ハルシネーション）が起きうると明示し、許可された「わからない」回答や引用による接地を推奨しています（Reduce hallucinations）。
実務解釈
LLM単体で詰まりやすい場面を表にします。
| 限界 | 何が起きるか | 典型例 |
|---|---|---|
| 学習カットオフ | 学習以降の事実を知らない | 昨日更新した仕様・料金・リリースノート |
| 非公開知識 | 社内・契約・製品内部の文書が無い | 社内FAQ、設計書、運用手順 |
| 推測による補完 | 知らないのに自信ありげに書く | 存在しないAPI名・条文・数値 |
| コンテキスト窓 | 全文書を毎回貼れない | 数百ページのマニュアル |
「プロンプトに全部貼ればよい」は、量が少ないうちは有効です。文書が増え、質問ごとに必要な箇所が変わる段階で、検索（RAG）が現実的な選択肢になります。
3. RAGが解決すること／しないこと
確認できる事実
- OpenAI は、RAGで渡す文脈が間違っているとモデルは答えようがなく、無関係な文脈が多すぎると本質が埋もれてハルシネーションを誘発しうると整理しています（同ガイドの Retrieval / LLM 評価表）。
- 同ガイドの実験例では、問題の性質によっては RAG を足しても精度が上がらず、かえって下がるケースもあると報告されています。文脈不足ではない失敗に RAG を当てると、ノイズになる、という教訓です。
実務解釈
| RAGが効きやすい | RAGだけでは足りない／別レバー |
|---|---|
| 最新・固有の事実を根拠付きで答えたい | 出力フォーマットや口調が毎回ブレる |
| 「この文書のどれを見たか」を示したい | 複雑な手順を安定して実行させたい |
| 学習に無い社内知識を参照したい | タスク自体の学習（例示の蓄積）が要る |
OpenAI のたとえは分かりやすいです。試験で正解するには、(A) 授業で何度も見て覚えた知識（learned memory）か、(B) 教科書をその場で引く（in-context memory）か、です。RAGは主に (B) 側。振る舞いの一貫性はプロンプトやファインチューニング側の話です。
4. いつRAGを足すか（初心者の判断フロー）
失敗した回答を1件ずつ見て、次のどちらかに振り分けます。
評価で間違えた
├─ 正しい資料が無い／古い／非公開 → 文脈不足 → RAG（または静的に資料を渡す）候補
└─ 資料はあるのに書式・手順・口調が崩れる → 振る舞い不足 → プロンプト／例示／FT候補
実務の最小ステップは次のとおりです。
- まずプロンプトだけで評価セット（20問以上が目安）を作る
- 失敗を「知識不足」と「振る舞い不足」に分ける
- 知識不足なら、対象文書を決め、検索→抜粋→生成の最小パイプラインを組む
- 検索結果の妥当性と、最終回答の正しさを別々に見る
- 無関係チャンクが多いなら、検索側を直す（生成プロンプトだけいじらない）
実装チェックリスト
問題の切り分け
- 「モデルが嘘をつく」ではなく「必要な文脈が無い／古い」と説明できる
- 失敗例を文脈不足と振る舞い不足に分けた
- 失敗コスト（人が直す／金銭影響／安全）をざっくり決めた
RAGを足す前
- 対象コーパス（FAQ・マニュアル・仕様など）の範囲を1行で書いた
- プロンプト単体の評価セットを先に持っている
- 「全部を毎回プロンプトに貼る」案の限界（量・鮮度・権限）を確認した
RAGを足したあと
- 検索結果が質問に対して妥当かを見る観点がある
- 根拠のない断言を禁止する指示をプロンプトに入れた
- 無関係な長文を大量投入していない
- 「RAGを入れたから正解」と評価なしで断言していない
失敗パターン
パターン1：RAG＝万能薬だと思う → 対策: 文脈不足かどうかを先に診断する。書式ブレには別レバー。
パターン2：関係ない文書を大量に渡す → 対策: 検索結果を絞る。OpenAI ガイドも過剰ノイズを警告している。
パターン3：検索品質を見ずに生成だけ直す → 対策: Retrieval と LLM の失敗を分けて直す。
パターン4：出典を出さず「社内文書によると」だけで終わる → 対策: 参照箇所や引用を必須にする（Anthropic の grounding 手法と同趣旨）。
パターン5：評価セットなしで「精度が上がった」と言う → 対策: 小さな質問セットで前後比較する。
参考リンク
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。