RAG（Retrieval-Augmented Generation）は、LLMが回答を作る前に外部の情報を探し、その内容を回答に使えるようにする仕組みです。

たとえば、LLMが学習していない社内マニュアルや、公開されたばかりの製品情報について答えさせたい場合があります。RAGでは、質問に関係する資料を検索し、見つけた内容をLLMへ渡してから回答を生成します。

大まかな違いは次のように考えると分かりやすいです。

普通のLLM

質問
↓
LLMが入力された情報や学習済みの知識を使う
↓
回答
RAG

質問
↓
関連する情報を探す
↓
見つけた情報をLLMへ渡す
↓
LLMがその情報を使って回答

RAGの仕組みを見ていくと、Chunking、Embedding、Vector Search、ANN、Vector DBといった用語も出てきます。この記事では、まずRAGそのものを理解したうえで、それらがどこに位置するのかを順番に見ていきます。

以下の説明と参照先は、2026年9月22日時点の内容を基準にしています。

なぜRAGを使うのか

社内資料や新しく公開された情報など、LLMの学習データの外にある情報を使いたい場面があります。

たとえば、次のような情報です。

  • 社内マニュアルや社内Wiki
  • 非公開の製品仕様
  • 更新頻度の高いドキュメント
  • モデルの学習後に公開された情報

こうした情報を毎回人が探してプロンプトへ貼り付ける代わりに、必要な情報を検索してLLMへ渡す部分まで仕組みにしたものがRAGです。

Microsoft Learnでも、RAGは関連するコンテンツを取得し、それをモデル入力に含めることで、取得した情報に基づく応答を生成する仕組みとして説明されています。

Microsoft Foundry での拡張生成 (RAG) とインデックスの取得 - Microsoft Foundry

取得拡張生成 (RAG) でインデックスと接地データを使用して、生成 AI アプリの応答精度を向上させる方法について説明します。

https://learn.microsoft.com/ja-jp/azure/foundry/concepts/retrieval-augmented-generation

learn.microsoft.com

Google Cloudでも、情報検索システムと生成LLMを組み合わせるAIフレームワークとしてRAGが説明されています。

検索拡張生成（RAG）とは

検索拡張生成（RAG）は、LLM と外部のナレッジベースを組み合わせて出力を改善します。Google Cloud で詳細をご確認ください。

https://cloud.google.com/use-cases/retrieval-augmented-generation?hl=ja

Google Cloud · cloud.google.com

具体例：製品マニュアルから回答する

例として、LLMの学習後に公開された製品について質問するとします。

製品マニュアルには、次の記述があります。

最大メモリは384GB

ユーザーが次のように質問します。

この製品の最大メモリはいくつ？

RAGを使うと、処理は次のようになります。

ユーザーの質問
「この製品の最大メモリはいくつ？」
        ↓
関連する製品マニュアルを検索
        ↓
「最大メモリは384GB」
という箇所を取得
        ↓
質問と取得した情報をLLMへ渡す
        ↓
LLM
「最大メモリは384GBです」

ここでLLMそのものを再学習しているわけではありません。

必要な情報をそのリクエストのContextとして追加し、LLMはそのContextを材料に回答を作ります。

この「必要な情報を探す → LLMへ渡す → 回答を作る」という流れがRAGの中心です。

RAGは3つの処理で考えると分かりやすい

RAGはRetrieval-Augmented Generationの略で、日本語では「検索拡張生成」などと訳されます。

名前の通り、大きく3つの処理に分けられます。

Retrieval
必要な情報を外部から取得する
        ↓
Augmentation
取得した情報をLLMの入力へ追加する
        ↓
Generation
LLMがその情報を使って回答を生成する

Retrieval

質問に関係する情報を探す部分です。

検索対象は、Webページ、PDF、社内文書、データベース、APIなどさまざまです。

Augmentation

Retrievalで取得した情報を、LLMへ渡すContextへ追加します。

先ほどの例では、質問と一緒に「最大メモリは384GB」というマニュアルの記述を渡している部分です。

Generation

LLMが質問と取得した情報を読み、最終的な回答を生成します。

この3段階までを見ると、RAGは単なる検索機能ではなく、検索結果をLLMの生成へつなぐ構成だと分かります。

RAGで使える検索方法

RAGのRetrievalでは、目的に応じて複数の検索方法を利用できます。

Microsoft Learnでは、RAGで利用するIndexとしてKeyword、Semantic、Vector、Hybrid Searchが紹介されています。

代表的には次のような方法があります。

  • キーワード検索
  • 全文検索
  • Vector Search
  • Hybrid Search
  • SQLによる検索
  • Knowledge BaseやAPIからの取得

RAGで重要なのは、検索方法そのものよりも、取得した情報をLLMのGenerationへ渡して利用することです。

この中でも、意味が近い文章を探しやすいことからVector SearchはRAGでよく使われます。

文書を検索しやすい状態へ準備する

Vector Searchを使うRAGでは、質問を受け取る前に文書を検索しやすい状態へ準備しておくのが一般的です。

AWSのRAG解説では、文書を分割し、Embeddingを作成してVector Databaseへ保存した後、質問に対して関連する情報を取得し、そのContextをLLMへ渡す流れが紹介されています。

https://docs.aws.amazon.com/prescriptive-guidance/latest/retrieval-augmented-generation-options/what-is-rag.html

docs.aws.amazon.com

大まかには、事前準備と質問時の処理に分かれます。

事前準備

PDF / Markdown / Webページ / 社内文書
↓
Chunking
↓
Embedding
↓
Index / Vector DB

質問されたとき

ユーザーの質問
↓
検索
↓
関連するChunkを取得
↓
ContextとしてLLMへ追加
↓
回答生成

ここから先は、この流れの中に出てくるChunking、Embedding、Vector Searchを順番に見ていきます。

Chunkingは長い資料を検索しやすくする

Chunkingは、長い文書を検索しやすい単位へ分割する処理です。

たとえば100ページのPDF全体を1つのデータとして扱うよりも、章や段落などを基準に小さく分けておいたほうが、質問に関係する箇所だけを取り出しやすくなります。

100ページのマニュアル
        ↓
Chunking
        ↓
Chunk 1: 製品概要
Chunk 2: CPU仕様
Chunk 3: メモリ仕様
Chunk 4: ストレージ仕様
...

ユーザーがメモリについて質問した場合、検索では「メモリ仕様」に近いChunkを優先して取得できます。

Chunkingは、RAGで検索精度やContextの使い方に影響する重要な前処理です。

Embeddingは文章の意味を比較できる形にする

Embeddingは、文章などを数値の並びで表現する仕組みです。

最初から「高次元ベクトル」と考えるよりも、文章同士の意味の近さをコンピューターが比較できる形へ変換すると考えると分かりやすいです。

たとえば、次の2つの文章があります。

「この製品の最大メモリは？」
「搭載できるRAMの上限」

使っている単語は異なりますが、意味は近い内容です。

Embedding Modelは、それぞれを数値のベクトルへ変換します。

文章
↓
Embedding Model
↓
[0.12, -0.84, 0.33, ..., 0.71]

意味が近い文章は、Embedding空間でも近い位置になるように表現されます。

Google CloudのBigQueryドキュメントでも、Embeddingはテキストや音声などの対象を表す高次元の数値ベクトルとして説明されています。

エンベディングとベクトル検索の概要  |  BigQuery  |  Google Cloud Documentation

https://docs.cloud.google.com/bigquery/docs/vector-search-intro?hl=ja

Google Cloud Documentation · docs.cloud.google.com

Vector Searchは意味が近い情報を探す

文書と質問をEmbeddingへ変換すると、ベクトル同士の距離や類似度から意味の近い情報を探せます。

質問
「この製品の最大メモリは？」
        ↓
Embedding
        ↓
Vector Search
        ↓
「最大メモリは384GB」
を含むChunkを取得

キーワードが完全に一致していなくても、意味的に近い情報を探せるのがVector Searchの特徴です。

RAGでは、この検索結果をContextとしてLLMへ渡します。

Embedding Modelは検索用の表現を作り、LLMは取得した情報を使って回答を生成します。役割が異なるため、それぞれ別のモデルを組み合わせる構成が一般的です。

ANNは大量のベクトルを高速に探す方法

Vector Searchのデータ量が増えると、すべてのベクトルと毎回比較する処理には時間がかかります。

そこで使われるのがANN（Approximate Nearest Neighbor、近似最近傍探索）です。

ANNは、すべてを総当たりで比較する代わりに、近い候補を効率よく探すことで検索を高速化します。

Google CloudのBigQueryドキュメントでは、Vector Indexを使う検索ではANNを利用し、Indexを使わない場合はBrute Forceで全レコードとの距離を測定する構成が説明されています。

使用向量搜索来搜索嵌入  |  BigQuery  |  Google Cloud Documentation

https://docs.cloud.google.com/bigquery/docs/vector-search

Google Cloud Documentation · docs.cloud.google.com

RAGとの関係は、次のように考えると分かりやすいです。

RAG
└─ Retrieval
   └─ Vector Search
      └─ ANN

ANNは、Vector Searchを大規模なデータで高速に動かすために使われる探索手法です。

LLM・RAG・検索技術の位置関係

ここまでに出てきた用語を役割ごとに並べると、位置関係が見えやすくなります。

用語何か主な役割
LLMモデル入力されたContextを理解し、推論や生成を行う
Embedding Modelモデルテキストなどを意味比較に使えるベクトルへ変換する
Vector Search検索手法ベクトルの近さから関連情報を探す
ANN探索手法大量のベクトルから近い候補を高速に探す
Vector DBデータストアベクトルを保存し、検索しやすくする
RAGシステム構成外部情報を取得し、その情報をLLMの生成へ利用する

RAGという大きな流れの中で、検索方法としてVector Searchを使い、その検索を支える要素としてEmbedding ModelやVector DB、ANNが入るイメージです。

AI AgentとRAGの関係

AI Agentの説明の中でRAGという言葉を見かけることもあります。

AI Agentは、LLMだけでなく、検索、API、ファイル操作、コード実行など複数のToolを使い分けながら処理を進めるシステムとして構成できます。

その中でRAGは、必要な情報を取得してLLMへ渡す仕組みとして利用できます。

AI Agent
├─ LLM
├─ RAG
│  ├─ 社内文書
│  ├─ マニュアル
│  └─ Knowledge Base
├─ Web検索
├─ API
└─ その他のTool

たとえばAgentが「まず社内ドキュメントを検索したほうがよい」と判断し、その検索結果を使って回答する場合、情報取得の部分にRAGを組み込めます。

RAGはAI Agentの一機能として使うこともできますし、Agentを使わずにRAG単体の質問応答システムを作ることもできます。

画像やExcelを扱う場合

RAGを理解するときは、「AIが外部ファイルを扱う処理」との違いも知っておくと分かりやすくなります。

たとえば、1枚の画像をモデルへ直接渡して内容を判定する処理は、マルチモーダルモデルへの直接入力です。Excelをアップロードして、そのファイルのセルを集計する処理もファイルの直接解析です。

RAGでは、情報の集合から質問に必要な部分をRetrievalし、その結果をLLMへ渡します。

処理位置付け
渡された画像を直接認識するマルチモーダルモデルによる直接入力
渡されたExcelを直接解析するファイルの直接解析
大量の文書から関連箇所を検索しLLMへ渡すRAG
画像をEmbedding化して類似画像を検索するVector Search
類似画像を検索し、その結果をLLMへ渡して回答するRAGとして構成できる

ファイル形式よりも、「必要な情報を検索し、その結果をGenerationへ使っているか」という処理の流れを見ると理解しやすくなります。

基礎を確認できる一次資料

RAGの基礎を確認する資料として、Microsoft LearnにはBeginner向けの入門モジュールがあります。

Introduction to retrieval-augmented generation concepts - Training

Learn how retrieval-augmented generation (RAG) grounds generative AI responses in relevant information.

https://learn.microsoft.com/en-us/training/modules/rag-fundamentals/

learn.microsoft.com

Microsoft FoundryのRAG概説では、Index、Embedding、Keyword Search、Vector Search、Hybrid SearchがRAGの構成の中でどこに位置するのか確認できます。

Microsoft Foundry での拡張生成 (RAG) とインデックスの取得 - Microsoft Foundry

取得拡張生成 (RAG) でインデックスと接地データを使用して、生成 AI アプリの応答精度を向上させる方法について説明します。

https://learn.microsoft.com/ja-jp/azure/foundry/concepts/retrieval-augmented-generation

learn.microsoft.com

EmbeddingとVector Searchの関係はGoogle CloudのBigQuery資料で確認できます。ANNとBrute Force Searchの違いも同じ資料群で説明されています。

エンベディングとベクトル検索の概要  |  BigQuery  |  Google Cloud Documentation

https://docs.cloud.google.com/bigquery/docs/vector-search-intro?hl=ja

Google Cloud Documentation · docs.cloud.google.com

AWS Prescriptive Guidanceでは、Chunking、Embedding、Vector Database、Retriever、LLMを組み合わせた典型的なRAG構成が説明されています。

https://docs.aws.amazon.com/prescriptive-guidance/latest/retrieval-augmented-generation-options/what-is-rag.html

docs.aws.amazon.com

RAGという名称の出発点として、Patrick Lewisらが2020年に発表した論文があります。

Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

Large pre-trained language models have been shown to store factual knowledge in their parameters, and achieve state-of-the-art results when fine-tuned on downstream NLP tasks. However, their ability to access and precisely manipulate knowledge is still limited, and hence on knowledge-intensive tasks, their performance lags behind task-specific architectures. Additionally, providing provenance for their decisions and updating their world knowledge remain open research problems. Pre-trained models with a differentiable access mechanism to explicit non-parametric memory can overcome this issue, but have so far been only investigated for extractive downstream tasks. We explore a general-purpose fine-tuning recipe for retrieval-augmented generation (RAG) -- models which combine pre-trained parametric and non-parametric memory for language generation. We introduce RAG models where the parametric memory is a pre-trained seq2seq model and the non-parametric memory is a dense vector index of Wikipedia, accessed with a pre-trained neural retriever. We compare two RAG formulations, one which conditions on the same retrieved passages across the whole generated sequence, the other can use different passages per token. We fine-tune and evaluate our models on a wide range of knowledge-intensive NLP tasks and set the state-of-the-art on three open domain QA tasks, outperforming parametric seq2seq models and task-specific retrieve-and-extract architectures. For language generation tasks, we find that RAG models generate more specific, diverse and factual language than a state-of-the-art parametric-only seq2seq baseline.

https://arxiv.org/abs/2005.11401

arXiv.org · arxiv.org

現在のRAGは適用範囲が広がっているため、原論文と各ベンダーの現在のドキュメントを分けて読むと、技術の変化も追いやすくなります。

RAGの流れをまとめる

RAGを初めて理解するときは、まず次の流れを押さえると十分です。

ユーザーの質問
        ↓
必要な情報を検索する
        ↓
関連する情報を取得する
        ↓
LLMのContextへ追加する
        ↓
LLMが回答を生成する

Vector Searchを使う一般的な構成まで含めると、次のようになります。

外部データ
   ↓
Chunking
   ↓
Embedding
   ↓
Index / Vector DB
   ↓
Vector Search
   ↓
関連する情報を取得
   ↓
LLMのContextへ追加
   ↓
回答生成

最初は、この中心の流れを押さえれば十分です。

RAGの中心にあるのは、LLMが回答する前に必要な外部情報を取得し、その情報を使って回答するという考え方です。

この流れを理解してから、検索部分を詳しく見ていくと、Chunking、Embedding、Vector Search、ANN、Vector DBがそれぞれ何のためにあるのかもつながって見えるようになります。