社内ドキュメントや製品マニュアルをLLMに聞きたいのに、「知りません」と返されるか、もっともらしいが誤った回答が返ってくる——こうした体験からRAG（Retrieval Augmented Generation）という言葉に出会う人は多い。
この記事は、なぜLLM単体では足りないのか、RAGが何を解決するのかを初心者向けに整理する。
結論：RAGは「LLMに外部の知識を渡す」仕組み
| 観点 | LLM単体 | RAGを加えた場合 |
|---|---|---|
| 知識の範囲 | 事前学習データ＋プロンプト内の情報のみ | 検索で取得した最新・社内ドキュメントを参照できる |
| 情報の鮮度 | 学習カットオフ以降は知らない | インデックスを更新すれば最新情報を反映できる |
| 根拠の明示 | 出典なしで回答しがち | 参照した文書を提示しやすい |
| ハルシネーション | 知らない内容を推測で補完しやすい | 検索結果に基づく回答に寄せられる |
覚え方：LLMは「頭の中の知識だけで答える人」、RAGは「必要な資料を引いてから答える人」に近い。
LLM単体の4つの限界
RAGが必要になる理由を理解するには、まずLLM単体の限界を押さえる。
1. 学習カットオフ（知識の鮮度）
LLMは事前学習時点までの公開テキストで学習している。
学習完了後にリリースされた製品仕様、社内規程、昨日のニュースはモデルの重みの中に存在しない。
例：2024年に学習完了したモデル
→ 2025年にリリースされたAPIの仕様は知らない
→ 「たぶんこうだろう」と推測で回答する（ハルシネーション）
2. 非公開データへのアクセス不可
社内Wiki、顧客データベース、未公開の設計書は事前学習データに含まれない。
プロンプトに全文を貼れば一時的に参照できるが、コンテキストウィンドウの上限があり、大規模なドキュメント群は丸ごと渡せない。
3. ハルシネーション（もっともらしい嘘）
LLMは「次に来そうなトークン」を予測する設計のため、知らない質問に対しても plausible な回答を生成しがちだ。
「わかりません」と答えるより、もっともらしい推測を返す方が学習上報われたパターンになっている。
4. コストとレイテンシ（長いコンテキストの問題）
プロンプトに大量のテキストを直接埋め込むと、入力トークン数が増え、APIコストと応答時間が比例して増える。
何千ページものマニュアルを毎回全部送るのは現実的ではない。
RAGとは何か
RAG（Retrieval Augmented Generation）は、回答を生成する前に、関連する文書を検索してLLMに渡すアーキテクチャだ。
2020年にMeta AI（当時Facebook AI）の研究者が提唱した手法で、現在のエンタープライズ向けAIアプリの標準パターンになっている。
基本的な流れは次の4ステップだ。
[1. インデックス構築]
ドキュメントを分割（チャンク）→ 埋め込みベクトル化 → ベクトルDBに保存
[2. 検索（Retrieval）]
ユーザーの質問を埋め込み → ベクトルDBで類似チャンクを検索
[3. 拡張（Augmentation）]
検索結果をプロンプトに組み込む
[4. 生成（Generation）]
LLMが検索結果を参照しながら回答を生成
原文: "RAG combines the parametric memory of a pre-trained seq2seq model with a non-parametric memory"
日本語訳: 「RAGは事前学習済みモデルのパラメトリックメモリと、非パラメトリックメモリを組み合わせる」（出典: Lewis et al., 2020）
ポイントは、知識をモデルの重みに焼き込まず、外部ストアから動的に取得する点だ。
ドキュメントを更新すれば、モデルを再学習しなくても回答に反映できる。
RAGが解決する問題の対応表
| LLM単体の限界 | RAGによる解決策 |
|---|---|
| 学習カットオフ | インデックスを定期的に更新すれば最新情報を反映 |
| 非公開データ | 社内ドキュメントをインデックスに追加 |
| ハルシネーション | 検索結果に基づく回答＋出典提示で抑制 |
| 長文コンテキスト | 関連部分だけを検索して渡す（必要な分だけ） |
完全にハルシネーションをゼロにはできないが、「知らないことを推測で補完する」頻度は大幅に下がる。
RAGが向いているケース・向いていないケース
RAGが向いているケース
| ユースケース | 理由 |
|---|---|
| 社内FAQ・マニュアル検索 | 非公開ドキュメントを参照する必要がある |
| 製品仕様の問い合わせ対応 | 仕様書が頻繁に更新される |
| 法規制・契約書の照会 | 正確性が求められ、出典提示が必要 |
| カスタマーサポート | 過去の対応履歴・ナレッジベースを活用 |
LLM単体で十分なケース
| ユースケース | 理由 |
|---|---|
| 文章の要約・リライト | 入力テキスト内の情報だけで完結 |
| コード生成（一般的なパターン） | 学習データに十分なコード例がある |
| 創作・ブレインストーミング | 正確性より多様性が重要 |
| 翻訳 | 入力テキストをそのまま変換すればよい |
判断の目安：「答えが特定のドキュメント群の中にある」ならRAG、「一般的な言語能力で処理できる」ならLLM単体。
RAGの全体像（初心者向け）
RAGパイプラインを構成する主要コンポーネントは次のとおりだ。
┌─────────────────────────────────────────────────┐
│ ドキュメントソース │
│ (PDF, Markdown, Webページ, DB等) │
└──────────────┬──────────────────────────────────┘
│ 取り込み・分割
▼
┌─────────────────────────────────────────────────┐
│ チャンク（分割されたテキスト片） │
│ → 埋め込みモデルでベクトル化 │
└──────────────┬──────────────────────────────────┘
│ 保存
▼
┌─────────────────────────────────────────────────┐
│ ベクトルデータベース │
│ (Pinecone, Qdrant, pgvector, Chroma等) │
└──────────────┬──────────────────────────────────┘
│ 類似度検索
▼
┌─────────────────────────────────────────────────┐
│ LLM（回答生成） │
│ プロンプト = 質問 + 検索結果 + 指示 │
└─────────────────────────────────────────────────┘
各コンポーネントの役割を一言でまとめる。
| コンポーネント | 役割 |
|---|---|
| チャンキング | 長文を検索しやすいサイズに分割 |
| 埋め込みモデル | テキストを数値ベクトルに変換（意味の類似度計算用） |
| ベクトルDB | ベクトルを高速に検索するストア |
| LLM | 検索結果をもとに自然言語の回答を生成 |
実装チェックリスト
RAGを初めて設計するとき、次の項目を確認する。
- 対象ドキュメントを特定したか — 何を検索対象にするか（PDF、Wiki、DB等）
- チャンクサイズを決めたか — 一般的には500〜1000トークン程度から試す
-
埋め込みモデルを選んだか — OpenAI
text-embedding-3-small、Cohere、ローカルモデル等 - ベクトルDBを選んだか — 規模・運用コスト・既存インフラとの整合
- プロンプトに「コンテキスト外は答えない」指示を入れたか — ハルシネーション抑制
- 出典（参照チャンク）を回答に含める設計にしたか — 検証可能性の確保
- インデックス更新の運用フローを決めたか — ドキュメント追加・変更時の再インデックス
- 評価用の質問セットを用意したか — 精度改善のベースライン
失敗パターン
パターン1：RAGを入れたのに精度が上がらない
→ 対策：チャンクサイズ・埋め込みモデル・検索件数（top-k）を調整する。検索結果が質問と無関係なら、チャンキング戦略を見直す。
パターン2：検索結果を無視してLLMが推測で答える
→ 対策：プロンプトに「提供されたコンテキストにない情報は『わかりません』と答える」と明記する。温度（temperature）を下げる。
パターン3：インデックスを更新しない
→ 対策：ドキュメント更新時の再インデックス手順を自動化する。古い情報が残ると誤回答の原因になる。
パターン4：すべてをRAGに載せようとする
→ 対策：検索対象を絞る。FAQ、マニュアル、規程など「答えが文書の中にある」ものに限定する。
パターン5：RAGの精度評価をしない
→ 対策：代表的な質問10〜20件と正解を用意し、検索精度・回答精度を定期的に計測する。
まとめ
- LLM単体は学習カットオフ・非公開データ・ハルシネーション・コンテキスト上限という4つの限界がある。
- RAGは回答前に関連文書を検索してLLMに渡すことで、これらの限界を緩和する。
- 「答えが特定のドキュメント群にある」ユースケースではRAGが有効。一般的な言語処理はLLM単体で十分な場合もある。
- 実装時はチャンキング・埋め込み・検索・プロンプト設計・評価の5点をセットで考える。
参考リンク
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020)
- What is RAG? (IBM)
- Retrieval augmented generation (AWS)
- Build a RAG agent with LangChain (LangChain Docs)
- Prompt engineering (OpenAI Docs)
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。