RAG (Retrieval-Augmented Generation) とは 2026年版：ローカルLLM で RAG を組む仕組みと埋め込みモデル・ベクトルDB・LLM の役割分担

結論：RAG は「LLM に外部の文書を渡してから答えさせる」仕組みです。

ユーザーの質問を埋め込みモデルでベクトル化し、ベクトルDB から関連度の高い文書片を上位 K 件取り出し、それを LLM のプロンプトに差し込んでから生成させます。ローカル運用で必要な役者は「埋め込みモデル（数百 MB〜数 GB）」「ベクトルDB（Chroma / Qdrant など）」「本体 LLM（Q4 で 5〜40 GB）」の 3 つ。埋め込みと LLM を同時にロードするので、VRAM または Unified Memory は 16GB でギリギリ、24〜32GB あれば実用ラインです。

RAG はハルシネーション抑制と社内文書検索には効きますが、数値計算や複数文書の統合推論には向きません。

「RAG って結局なにをしている仕組みなのか」「エージェントや Function Calling とはどう違うのか」「ローカルLLM で RAG を組むには何が要るのか」。この 3 つは Claude Code や Cursor でエージェント運用を始めた人が最初にぶつかる質問です。

この記事はランキングでも比較記事でもなく、RAG そのものの概念解説記事です。実装したくなったら「ローカルRAG PC 構成ガイド 2026年版」「ローカルLLM 向け埋め込みモデル比較 2026年版」「ローカルLLM 向けベクトルDB 比較 2026年版」へ進んでください。

本稿は「そこに進むための土台」の位置付けです。

RAG の一言定義

RAG は Retrieval-Augmented Generation の略です。日本語だと「検索拡張生成」です。

一言で言えば 「LLM に、答えるための材料を先に検索して渡してから生成させる」仕組み です。

素の LLM は学習済みパラメータの中に閉じ込められた知識しか使えません。学習後に発生した出来事、公開されていない社内文書、あなたの Obsidian ノートの中身は答えられません。RAG は「その質問に関連しそうな文書」を外部の検索基盤（ベクトルDB）から取り出します。プロンプトに差し込んでから LLM に渡します。LLM は差し込まれた文脈を読んで、その内容に基づいて答えます。

RAG が解決する問題は 3 つあります。

1. ハルシネーション抑制：LLM に「知らないなら知らないと言え」「差し込まれた文書だけを根拠にせよ」と指示できるので、それらしい嘘の頻度が減ります
2. 知識の更新：モデルを再学習しなくても、ベクトルDB に文書を追加するだけで新しい知識を扱えます
3. プライベート文書の検索：社内 Wiki や個人ノートなど、モデルの学習データに含まれていない情報も扱えます

3 つのコンポーネントが何をするか

RAG は次の 3 つのコンポーネントで組み立てます。

1. 埋め込みモデル (Embedding Model)

役割は 「テキストを数値ベクトルに変換する翻訳器」。「東京の首都機能」も「都心の行政機関」も、意味が近ければ近いベクトルに写ります。出力ベクトルの次元数はモデルによって違います。多いほど表現力は上がりますが、ベクトルDB の容量と検索速度を食います。

埋め込みモデル	次元数	サイズ	特徴
multilingual-e5-large	1024	約 2.2 GB	多言語、日本語含む定番
bge-m3	1024	約 2.3 GB	多言語 + 疎密ハイブリッド
ruri-large	1024	約 1.3 GB	日本語特化、軽量
EmbeddingGemma	768	約 300 MB	Google 製、超軽量

日本語ドキュメントを扱うなら ruri または multilingual-e5 が定番、英語混在なら bge-m3 を選ぶケースが多いです。埋め込みモデル別の精度差は「ローカルLLM 向け埋め込みモデル比較 2026年版」で扱っています。

2. ベクトルDB (Vector Database)

役割は 「ベクトル同士の類似度で高速に検索するデータベース」。文書を埋め込みモデルでベクトル化して保存します。質問ベクトルとの内積やコサイン類似度が高い順に、上位 K 件を返します。

ベクトルDB	特徴	向き
Chroma	Python でも数行で動く、SQLite ベース	個人・小規模プロトタイプ
Qdrant	Rust 製、フィルタ機能豊富	中規模〜本番運用
Weaviate	GraphQL 対応、モジュール豊富	ハイブリッド検索
pgvector	PostgreSQL 拡張	既存 RDB に統合したい
Milvus	分散対応	数千万件以上の大規模

個人ノート・小規模社内文書なら Chroma、100 万件超のスケールを想定するなら Qdrant 以降、が2026 年時点の相場感です。詳細は「ローカルLLM 向けベクトルDB 比較 2026年版」を参照してください。

3. 本体 LLM (Generation Model)

役割は 「検索されてきた文書を材料に、質問への回答文を生成する」。ここは通常のローカルLLM そのものです。Llama 3.3 70B / Qwen 2.5 14B / Gemma 3 27B などから選びます。

RAG での LLM に求められる能力は 2 つあります。

• 長文コンテキストの理解：8K 以上のトークンを差し込むケースが多いので、コンテキストウィンドウが 32K 以上あると安心
• 指示追従：「差し込まれた文書のみを根拠にせよ」の指示を守れるか

大きいモデルほど指示追従は良くなりますが、埋め込みモデルと同居させるので VRAM または Unified Memory を食う 点に注意が必要です。

RAG のパイプライン：質問から回答までの流れ

図のイメージはこうです。

【事前準備（インデックス作成）】
  文書 → チャンク分割 → 埋め込みモデル → ベクトル → ベクトルDB に保存

【クエリ時（毎回）】
  ユーザー質問 → 埋め込みモデル → 質問ベクトル
              → ベクトルDB で類似検索 → 上位 K 件のチャンク
              → LLM プロンプトに差し込み → 生成 → 回答

順を追うと以下の 5 ステップです。

1. 事前準備：手元の文書を数百〜千字程度のチャンクに分割し、埋め込みモデルでベクトル化してベクトルDB に保存します
2. 質問受信：ユーザーから質問が来たら、同じ埋め込みモデルで質問をベクトル化します
3. 類似検索：質問ベクトルと最も距離が近いチャンクをベクトルDB から上位 K 件（3〜10 件が多い）取り出します
4. プロンプト組み立て：システムプロンプト + 取り出したチャンク + 元の質問 を連結して、LLM のコンテキストに差し込みます
5. 生成：LLM が差し込まれた文脈を読み、質問に対する回答を生成します

再ランキング（Reranker）を挟むケースもあります。ベクトル検索は速いが精度がやや落ちるため、上位 K 件を出したあとに cross-encoder（bge-reranker など）で並び直すと精度が上がります。ただし cross-encoder は各クエリ×文書ペアを毎回計算するので遅いです。K が大きいとレイテンシが伸びます。

ローカルで組むときの VRAM / Unified Memory 目安

RAG を回すと 埋め込みモデルと本体 LLM を同時にロード することになります。ざっくり以下の目安です。

ローカル構成	埋め込み	本体 LLM (Q4)	合計目安	KV キャッシュ余裕
16 GB (VRAM / Unified)	300 MB (EmbeddingGemma)	8B (5 GB)	6 GB	ギリギリ
24 GB	2 GB (bge-m3)	14B (9 GB)	11 GB	8K context ならOK
32 GB	2 GB	27B (17 GB)	19 GB	32K context 可
48 GB 以上	2 GB	32B (19 GB)	21 GB + 大量 KV	128K context 可
64 GB 以上 (Mac / Pro GPU)	2 GB	70B Q4 (40 GB)	42 GB + 大量 KV	32K〜

KV キャッシュはコンテキスト長に比例します。RAG は「文書チャンクを大量に差し込む」ため長文コンテキスト前提です。context_length × 層数 × hidden_dim × 2 バイト程度食う点は覚えておくべきです。詳しくは「ローカルLLM のコンテキスト長・VRAM・KV キャッシュ 2026年版」で扱っています。

実際にどのハードを買うかは「ローカルRAG PC 構成ガイド 2026年版」を参照してください。24GB VRAM の RTX 4090 / RTX 5090 32GB / Mac Studio 48GB あたりが実用ラインの候補になります。

RAG が向いていない用途

RAG は万能ではありません。以下の用途では本質的にうまくいきません。

• 数値計算・集計：ベクトル検索は「意味的に似た文書」を返す仕組みで、「売上を合計する」のような正確な計算は担当外です。Function Calling で計算関数を呼ぶ方が正しい
• 複数文書の統合推論：「A の資料と B の資料を突き合わせて矛盾を指摘せよ」のような、複数文書をまたぐ推論はチャンク単位検索と相性が悪い。Long-context モデル + プロンプトへの全文差し込みや、Agent 型 RAG の領域
• 時系列変化の追跡：「先月と今月の差分」のような時系列クエリは、ベクトル距離では表現しづらい
• 完全な網羅性が必要な用途：上位 K 件しか見ないので「該当する文書を全部挙げよ」タイプの質問は苦手

RAG は「知識の外部化」と「ハルシネーション抑制」に強く、「計算」と「網羅」には弱い、と役割で捉えるのが正確です。

RAG と Function Calling / Agent の関係

近い概念との整理をしておきます。

概念	何をする仕組みか
RAG	外部文書を検索して LLM に差し込み、それに基づいて回答させる
Function Calling	LLM が「この関数を呼びたい」と決めて、外部の関数（計算・API・DB クエリ）を実行させる
Agent	上記を組み合わせ、LLM が「次に何をするか」を自分で決めながらタスクを完遂する

RAG は Agent の中で「知識取得ステップ」として組み込まれることが多いです。Function Calling で「ベクトルDB 検索関数を呼ぶ」形で実装されることもあります。3 者は積み上げて併用できる関係にあります。実際の Agent 型システムでは同時に使われるのが普通です。

まとめ：RAG を組むには何を用意するか

RAG をローカルで動かしたい場合に必要なものは、次の 4 点です。

1. 本体 LLM を動かせる GPU または Mac（VRAM/Unified Memory 24GB 以上が実用ライン）
2. 埋め込みモデル（multilingual-e5 / bge-m3 / ruri など、300 MB〜2.3 GB）
3. ベクトルDB（Chroma で始めて、規模に応じて Qdrant 等へ移行）
4. 文書チャンク分割 + パイプライン制御コード（LangChain / LlamaIndex または自前）

このうち一番コストがかかるのはハード（本体 LLM 側）です。RAG のために新しく PC を組むなら、コンテキスト長を伸ばせる 24〜48GB VRAM 級か、Mac Studio 48〜128GB 級が候補になります。実装ステップに進む前に「本当に RAG が必要か（Long-context モデル + 全文差し込みで済まないか）」を検討するのも Phase 0 の見立てとしては筋がいい選択です。

---

あなたに合うPCを診断する

用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。

→ 診断スタート

関連記事

• ローカルRAG PC 構成ガイド 2026年版
• ローカルLLM 向け埋め込みモデル比較 2026年版
• ローカルLLM 向けベクトルDB 比較 2026年版
• ローカルLLM のコンテキスト長・VRAM・KV キャッシュ 2026年版