RAG（検索拡張生成 / Retrieval-Augmented Generation）は、質問に関係する自社の文書やデータをまず検索し、その中身を「根拠」としてLLMに渡してから答えさせる仕組みです。モデルそのものを学習し直さなくても、社内規程・製品仕様・FAQといった「そのモデルが知らない情報」に答えられるようになり、しかもどの文書を根拠にしたかを示せるのが最大の利点。本章では、RAGが何をしているのか、なぜ効くのか、どこでつまずくのかを、図を交えて全体像から押さえます。
FIG.1 RAG ＝「検索（Retrieval）」して「生成（Generation）」する2段構え。LLMは検索結果を根拠に答える
01RAG が解こうとしている問題
LLM（ChatGPT や Claude、Gemini など）は、学習に使われた大量のテキストから「もっともらしい続き」を作る仕組みです。だからこそ、学習データに入っていない情報──たとえばあなたの会社の就業規則、昨日更新した製品マニュアル、特定顧客の契約内容──は本来知りません。それでも質問されると、知っているかのようにそれらしい嘘（ハルシネーション）を作ってしまうことがあります。
RAGはここに、ひと手間を挟みます。質問に関連しそうな文書を先に検索して取り出し、その本文をプロンプトに同梱してからLLMに答えさせるのです。LLMは「自分の記憶」ではなく「目の前に渡された資料」を読んで答えるので、知らないことを当てずっぽうで埋める余地が減り、根拠も示せるようになります。
02基本フロー：取り込み → 検索 → 生成
RAGは大きく、事前に文書を準備する「取り込み（インデックス作成）」と、質問が来てから動く「検索 → 生成」に分かれます。地味ですが、品質はこの各段の積み重ねで決まります。
取り込み（事前準備）
文書を扱いやすい長さの断片（チャンク）に分割し、各チャンクを埋め込み（embedding＝意味を表す数値ベクトル）に変換して、ベクトルDBに格納・索引化しておきます。一度作れば、質問のたびに作り直す必要はありません。
検索（質問が来たら）
質問文も同じ方法で埋め込みに変換し、意味が近いチャンクをベクトル検索で数件取り出します。型番や条文番号など完全一致が大事な場合は、キーワード検索も併用します（後述のハイブリッド検索）。
生成（根拠つきで回答）
取り出したチャンク（＝根拠）と元の質問を一緒にプロンプトへ入れ、LLMに「この根拠だけを使って答えて」と指示します。回答にはどの文書のどこを使ったかの引用を付けさせるのが定石です。
つまり、検索エンジンと生成AIを直列につないだ仕組み、と捉えると分かりやすいです。「賢いモデルを選ぶ」よりも「適切な根拠を渡せるか」のほうが、結果に効きます。
03埋め込みとベクトル検索のイメージ
RAGの心臓部は「意味の近さで探す」ベクトル検索です。文章を多次元空間の点（ベクトル）に変換しておくと、意味が似た文章どうしは空間内で近くに配置されます。質問もベクトル化して、その近くにある点（チャンク）を拾えば、表現が違っても意味が合う文書を取り出せます。
FIG.2 質問とチャンクを同じ意味空間に置き、近いものを関連文書として取り出す
キーワード検索（完全一致で探す従来型）と違い、ベクトル検索は「有給休暇」と「年次有給」のような言い換え・表記ゆれに強いのが特徴です。一方で、型番「RX-200」や「第15条」のように文字どおりの一致が重要なものは取りこぼすことがあり、ここを補うのが次のハイブリッド検索です。
04なぜファインチューニングより RAG なのか
「自社向けAI」を作る方法には、モデル自体を追加学習するファインチューニングもあります。両者は対立ではなく役割分担ですが、まず社内知識に答えさせたいだけなら、多くの場合RAGのほうが手軽で安全です。
| RAG（検索で根拠を渡す） | ファインチューニング（追加学習） |
|---|---|
| 得意：最新・固有の事実知識を反映 | 得意：口調・出力形式・専門タスクの癖を覚えさせる |
| 更新は索引（文書）を入れ替えるだけ | 更新には再学習が必要 |
| 根拠を引用できる（検証可能） | なぜそう答えたかは不透明になりがち |
| 文書を消せばその知識も即時に消える | 学習済み内容を後から消すのは難しい |
実務では「事実知識はRAG、振る舞いはファインチューニング」と組み合わせることもあります。ただし最初の一歩としては、再学習を伴わず、文書を差し替えるだけで内容を最新化できるRAGから始めるのが扱いやすいです。
05検索が9割：精度を上げる定番手法
RAGがうまく答えられないとき、原因のほとんどは生成ではなく検索（関連文書をちゃんと取り出せているか）にあります。2026年時点で定番になっている改善の打ち手は次の3つです。
ハイブリッド検索
ベクトル検索（意味）とキーワード検索（BM25＝完全一致）を並行で走らせ、両方の結果をRRF（順位を融合する手法）で1つに統合する。言い換えにも型番にも強くなる。
再ランキング
まず広めに20〜50件を取り、リランカー（質問と各文書を突き合わせて関連度を採点するモデル）で並べ直し、上位5〜10件だけをLLMに渡す。最も費用対効果が高い改善とされる。
メタデータ絞り込み
部署・製品・年度・文書種別などのタグで検索範囲を事前に限定し、ノイズを減らす。人事規程なら「適用会社」「改訂版」を必ず持たせたい。
FIG.3 広く拾って（再ランキングで）厳しく絞る。長すぎる文脈はかえって精度とコストを悪化させる
さらに新しい工夫として、各チャンクに「この断片は何の文書のどの部分か」という短い説明を付けてから索引化するコンテキスト付き検索（Contextual Retrieval）があります。Anthropic の検証では、この手法で検索の取りこぼしが約49％減り、再ランキングと併用すると約67％減ったと報告されています。いずれも「LLMを変える前に、まず検索を直す」という方向性を裏づける結果です。
06RAG の限界と正しい注意点
RAGは万能ではありません。仕組み上どうしても残る限界を、最初に正しく理解しておくと運用で慌てません。
- 検索がズレると回答もズレる：見当違いの文書を渡せば、LLMはそれを根拠にもっともらしく間違えます。精度は検索品質に強く依存します。
- 渡していないことは答えられない：根拠に含まれない事項は「分からない」と言わせる設計が必要。放置すると、足りない部分を推測で埋めてしまいます。
- 引用の捏造に注意：それらしい出典を作ってしまうことがあるため、引用が実在し結論を本当に支えているかの確認が要ります。
- 権限・機密の設計が必須：検索段階でユーザーの閲覧権限に応じて対象を絞る（アクセス制御）必要があります。実務で最も怖いのは幻覚よりも「見えてはいけない情報が回答に出る」事故です。
RAGの品質は、モデルの賢さよりも 「どんな根拠を、誰に対して、どう渡すか」 で決まる。
07評価とツール：どこから始めるか
改善を回すには「当てずっぽうの感想」ではなく数値が要ります。最初に用意したいのは、社内の実際の質問に近い評価用Q&Aセット（まず30〜100問でも十分価値あり）。RAG評価の定番であるRAGASなどのフレームワークは、正しい根拠を取り出せた割合（コンテキスト再現率）や、取り出した根拠の的確さ（コンテキスト適合率）を測ってくれます。「検索が取れているか」と「回答が合っているか」を分けて見るのがコツです。
道具立ては要件に応じて選べばよく、小さく始めるなら次のような構成が扱いやすいです（いずれも料金・提供形態は変わりやすいので公式で最新を確認してください）。
- ベクトルDB：まずは PostgreSQL の拡張 pgvector でも実用十分（単一ノードのため数千万ベクトル規模が目安）。さらに大規模・高負荷になったら Pinecone・Weaviate・Qdrant・Milvus などの専用サービスへ移行する流れが一般的。
- キーワード検索：Elasticsearch / OpenSearch（ハイブリッド検索の片側を担う）。
- 組み立て：LangChain / LlamaIndex などのフレームワークで検索〜生成をつなぐ。
- 評価・監視：RAGAS＋自前の評価セット。本番では質問・検索クエリ・ヒット文書・回答・コスト・遅延をログに残す。
近年は、エージェント（自律的に複数回の検索や絞り込みを判断するLLM）が検索戦略そのものを組み立てるエージェント型RAG（Agentic RAG）も広がりつつありますが、土台は本章の「検索して根拠を渡す」基本形です。まずここを固めることが、応用への近道になります。
08本章の流れ
この先は、RAGの部品を一つずつ掘り下げます。埋め込みとベクトル検索の基礎、文書をどう切るかのチャンク設計、そして検索品質の改善へと進みます。RAGは「検索が9割」──まずは本章で押さえた全体像を地図として、各部品の役割を確かめていきましょう。
