RAG（ラグ、検索拡張生成）とは生成AIが答える前に、手元の資料やデータベースから関係する文章を探し、それをもとに答える仕組み。わかりやすく、仕組み・身近な例・ファインチューニングとの違い・限界【2026年10月版】

2026年10月8日・日本時間時点の情報です。 RAG（ラグ、検索拡張生成）とは、AIが答える前に、手元の資料やデータベースから関係する文章を探して、それをもとに答える仕組みです。生成AIのもとになるLLM（大規模言語モデル）は、そのままでは学習した範囲の知識で答えます（AWSの説明）。RAGを足すと、学習に入っていない社内の資料や、新しく出た情報も答えの材料にできます。名前は Retrieval-Augmented Generation の頭文字で、「検索（Retrieval）で補強した（Augmented）生成（Generation）」という意味です。

3行まとめ

1. RAG（検索拡張生成）は、AIが答える前に資料を探して、見つけた文章をもとに答える仕組み。AWSは「応答を生成する前に、トレーニングデータソース以外の信頼できる知識ベースを参照」するプロセスと説明している（2026年10月8日に原文確認）。
2. 身近な例は、社内の規程に答えるチャットボット。AWSは「年次休暇はどのくらいあるのか?」に休暇規程の文書を探して答える例を載せている。アップロードした資料に答えるGemini Notebook（旧NotebookLM）も、公式ヘルプによると関連する情報を取得してから答える、同じ流れで動く。
3. RAGでも間違いはゼロにならない。Google Cloudは、探した情報が的外れなら、答えも的外れになりうると書く。原論文はLewisほか（2020年5月22日、arXiv:2005.11401）。

RAGは何をする仕組みか

たとえ話から入ります。試験で「教科書を見てよい」と言われた状態に近い、と考えるとつかめます（筆者のたとえで、公式の説明ではありません）。RAGがない生成AIは、教科書を閉じて、覚えていることだけで答えます。RAGがあるAIは、質問を受けたら先に教科書の該当ページを探し、そのページを読みながら答えます。

公式の原文では、次のように書かれています。

• AWS（Amazon Web Services）は、RAGを、大規模言語モデルの出力を最適化するプロセスで、「応答を生成する前に、トレーニングデータソース以外の信頼できる知識ベースを参照」するものと説明しています（日本語版の訳文）。英語の原文は「Retrieval-Augmented Generation (RAG) is the process of optimizing the output of a large language model, so it references an authoritative knowledge base outside of its training data sources before generating a response」です。
• Google Cloudは、RAGを「従来の情報検索システム（検索やデータベースなど）の長所と、生成大規模言語モデル（LLM）の機能を組み合わせたAIフレームワーク」と説明しています（日本語版の訳文）。英語の原文は「an AI framework that combines the strengths of traditional information retrieval systems (such as search and databases) with the capabilities of generative large language models (LLMs)」です。
• Microsoftは、Azure AI Searchの解説で、RAGを「独自の財産的価値のあるコンテンツの応答を根拠づけることで、LLM機能を拡張するパターン」と書いています（日本語版の訳文。英語の原文は「a pattern that extends LLM capabilities by grounding responses in your proprietary content」）。

3社とも、LLM（大規模言語モデル）に答えさせる前に、LLMの外にある情報を使う、という点で同じです。LLMの意味はLLMとはに書いています。

生成AIだけでは足りない所

AWSは、LLMの既知の課題として、答えがないのに虚偽の情報を示すこと、最新の応答を期待されても古い情報や一般的な情報を示すこと、権限のないソースから答えを作ること、用語の混乱で不正確な答えになること、の4つを挙げています。そして、RAGはこれらの課題のいくつかを解決する1つのアプローチだと書きます。「いくつか」であって、全部ではありません。

原論文はどう書いたか

RAGという名前は、Patrick Lewisらが2020年5月22日にarXivへ投稿した論文（NeurIPS 2020採択）から来ています。NVIDIAの公式ブログ（2025年1月31日）は、Lewisを「lead author of the 2020 paper that coined the term」（この語を作った2020年の論文の筆頭著者）と紹介しています。要旨によると、この論文はRAGを「事前学習した記憶（parametric memory）と、外部の記憶（non-parametric memory）を組み合わせて文章を作るモデル」と呼びました（要旨の言葉を筆者が訳しました）。論文では、前者が事前学習したseq2seqモデル、後者がWikipediaのベクトル索引です。

論文は、この組み合わせのモデルをファインチューニングして、質問応答などの課題で評価した研究です。いま製品やクラウドの説明で言われるRAGは、既にあるLLMに検索の結果を渡す組み立て方を指すことが多く、同じ名前でも範囲が少し違います。本記事で「RAG」と書く時は、後者（AWS・Google Cloud・Microsoftの説明の範囲）を指します。

身近な例：社内の資料に答えるチャットボットと、同じ流れで答えるGemini Notebook

社内の規程に答えるチャットボット

AWSの解説は、人事に関する質問に答えるチャットボットを例にしています。従業員が「年次休暇はどのくらいあるのか?」と入力すると、システムは年次休暇のポリシー文書と、その従業員の過去の休暇記録を取得して返す、という流れです（日本語版の訳文）。この文書は質問と関連性が高いので返される、とAWSは書いています。LLM単体では、会社の休暇規程は学習していません。RAGなら、規程を探して渡せます。チャットボットそのものの種類はチャットボットとはに書いています。

Gemini Notebook（旧NotebookLM）に資料を入れて質問する

NotebookLM（ノートブックLM）は、2026年7月16日にGoogleが「Gemini Notebook」へ改称しました（Google公式ブログ「NotebookLM is now Gemini Notebook」の日付はJul 16, 2026。改称の経緯はNotebookLMのログイン方法にあります）。筆者は2026年10月8日1時55分、ログインせずに公式サイト notebook.google を開きました。画面には「回答は、常にユーザーが提供した情報に基づいて生成されます」と書かれています。

公式ヘルプ（1時56分に開いた日本語版）には、もう少し仕組みに近い説明があります。ノートブックに多くのソースが含まれている場合、「Gemini Notebook はまず質問に基づいて最も関連性の高い情報を取得してから、その情報を使用して回答を作成します」と書かれています。探してから答える、というRAGの流れと同じです。ただし、筆者が確かめた範囲では、このヘルプと公式サイトの画面には「RAG」「検索拡張」という語がありませんでした（ページの文字を保存し、その語を検索して0件でした。英語版のヘルプと、英語の「Frequently asked questions」のページも「RAG」は0件で、どちらも「retrieves the most relevant information」と、取得してから答える流れを書いています）。Googleが内部でRAGと呼んでいるかどうかは、ヘルプからは分かりません。

使い方や無料の範囲はNotebookLMの解説にあります。

RAGの仕組み：資料を用意する段階と、質問に答える段階

AWS・Google Cloud・Anthropicの説明を合わせると、RAGは2つの段階に分けて考えられます。

1. 資料の準備

文書（PDF、Web、データベース等）
  ↓ 小さく分ける（チャンク）
  ↓ 文章を数字の並び（ベクトル）に変える（エンベディング）
  ↓ 検索できる形で保管する（ベクトルデータベース）

• チャンク：Anthropicは、資料を「通常は数百トークンまでの」小さな文章の塊に分けると説明しています（原文: smaller chunks of text, usually no more than a few hundred tokens）。
• エンベディング：AWSは、埋め込み言語モデルという別のAI技術が、データを数値表現に変換してベクトルデータベースに保管すると説明しています。意味が近い文章が近い数字になるので、言葉が違っても意味で探せます。埋め込みのモデルには対応する言語があります。Google Cloudのモデル一覧は、text-embedding-005 を「Specialized in English and code tasks.」（英語とコードの作業向け）として対応言語を English と書き、多言語向けのモデルを別に載せています。日本語の資料なら、日本語に対応したモデルかを公式の説明で確かめてから選ぶ、というのが筆者の提案です。
• ベクトルデータベース：Google Cloudは、ベクトルデータベースがドキュメントを高次元空間のエンベディングとして保存し、意味の近さに基づく検索を速く正確にすると書きます。

2. 質問への回答

質問 → 質問も数字に変える → 近い文章を探す（Retrieval）
  → 探した文章を質問に添えてLLMへ渡す → LLMが答えを作る（Generation）

AWSの日本語版は、この段階を「関連情報を取得する」「LLM プロンプトの拡張」と呼んでいます。質問とあわせて探した文章をLLMに渡すだけなので、LLMを作り直す必要はありません。

AWSは、元の資料が古くなった時の対処にも触れています。資料と、その数字表現を非同期で更新し続ければよく、自動のリアルタイム処理でも、定期的なまとめ処理でもよい、という説明です。

主要なツールの例

自分でRAGを組む時に使うツールの例です。各社の公式ページの文言を、2026年10月8日に確かめました。

選び方や比較はベクトルデータベースとはに詳しく書いています。

コードを書かずに試したい人は、まずGemini Notebookのように資料を入れて質問する画面を触る方が早い、というのが筆者の提案です。

検索の質を上げる工夫

基本の流れだけだと、探す部分で取りこぼしが出ます。公式が挙げる工夫を3つ書きます。

ハイブリッド検索

Google Cloudは、意味で探す検索（セマンティック検索）とキーワード検索を一緒に使う「ハイブリッド検索」と、検索結果の並びを採点し直す再ランク付け（re-ranker）を挙げます。Anthropicは、意味で探す方法は正確な一致を取りこぼすことがあり、「Error code TS-999」のようなエラーコードを探すにはキーワード検索のBM25が向く、と例を挙げています。

文脈つきの検索（Anthropic）

Anthropicは、資料を小さく分けると、その塊だけでは何の話か分からなくなる問題を指摘しました。たとえば「会社の売上は前の四半期より3%増えた」という塊だけでは、どの会社か分かりません。そこで各塊に説明の一文を足してから保管する「Contextual Retrieval」を2024年9月19日に発表し、検索の失敗が49%減り、再ランク付けと組み合わせると67%減ったと書いています（Anthropic自身の測定）。

探す対象と回数をAIに決めさせる方法

Microsoftは、Azure AI Searchに2つのやり方があると書きます。1つは、ハイブリッド検索と意味による並べ替えを使う「Classic RAG pattern」で、もう1つは、LLMが探し方を計画して複数の情報源を探す「Agentic retrieval」です。取得した日のページでは、agentic retrievalの質問の計画づくりに「preview」（試験提供）の表示がありました。

RAGと、ファインチューニング・資料を丸ごと渡す方法の違い

AIに自分の資料を知らせる方法は、RAGのほかに2つあります。

3つ目の数字は2024年のものです。モデルが一度に読める量は変わっている可能性があるので、そのまま今の目安にはできません。Google Cloudも、長いコンテキストウィンドウに収まらない量を渡したい時や、性能を上げたい時に、トークンを減らして時間と費用を抑えるRAGを使う、と説明しています。AnthropicとGoogle Cloudの説明は、資料が少なければ丸ごと渡し、多ければRAGにするという向きで一致しています。ファインチューニングの費用や手順はファインチューニングの解説にあります。

AWSの説明はRAGの利点として、費用対効果、最新の情報を渡せること、出典を示せてユーザーの信頼を高められること、開発者が情報源を制御して直せること、を挙げます。

RAGを入れても間違いが残る理由

RAGは「入れれば正しく答える」仕組みではありません。公式の原文に、それを示す文があります。

• Google Cloudは、RAGでは検索の仕組みが非常に重要で、探した情報が関連性のないものなら、「生成はグラウンディングされていても、トピックと無関係なものや不正確なものになる可能性があります」と書いています（原文: your generation could be grounded but off-topic or incorrect）。
• AWSは、RAGを課題の「いくつか」を解決する1つのアプローチと位置づけています。
• 国の指針も、期待という言い方です。総務省が掲載するAI事業者ガイドライン（第1.2版）の脚注27は、RAG（検索拡張生成）の活用等により、ハルシネーションの抑制や出力過程・根拠の透明性向上等が「期待されている」と書きます（LLMとはでも同じ脚注を扱っています）。

原因は、資料の分け方が悪くて文脈が切れる（Anthropic）、意味で探す段階で取りこぼす（Anthropic）、探せても的外れ（Google Cloud）、といった所にあります。そもそもハルシネーションとは何か、使う人がどう確かめるかはハルシネーションの原因と対策に書いています。

RAGの失敗を調べた研究は、このサイトでも紹介しています（RAG Collapse）。

始め方の目安（筆者の提案）

1. まず、資料を入れて質問できるサービス（Gemini Notebook など）で、手持ちの資料に質問してみる。RAGと同じ考え方の動きを、設定なしで確かめられる。
2. 答えに出典が付くか、出典の文章が本当にその答えを支えているかを、毎回開いて見る。RAGでも的外れは残る。
3. 社内の資料を使う時は、資料の置き場所と、使うAIサービスのデータの扱いを公式の説明で確かめてから渡す。AWSは、権限のレベルに応じて機密情報の取得を制限できると説明している。
4. 自分で組む時は、LangChain・LlamaIndex・Haystack・Difyなどの公式の手順から始め、検索の質（資料の分け方、ハイブリッド検索）を直す所から手を入れる。

筆者が開いた公式画面で分かったこと

2026年10月8日の1時55分から1時56分にかけて、Playwrightでヘッドレス（画面を出さない）のChromiumを使い、ログインせずに3つのページを1280×800と390×844の大きさで開きました。

• notebook.google（Gemini Notebookの公式サイト）：画面に「回答は、常にユーザーが提供した情報に基づいて生成されます」と出ていました。Cookieの同意の表示が下に出ましたが、押していません。
• Gemini Notebookのヘルプ（日本語）：ソースが多い時に「最も関連性の高い情報を取得してから」回答を作る、という説明を確認しました。
• AWSの日本語版「RAG とは何ですか?」：年次休暇の質問を例にした説明を確認しました。

Gemini Notebookの公式サイトとヘルプは、保存した文字で「RAG」「検索拡張」を検索して、どちらも0件でした。AWS・Google Cloud・Microsoftのページには、この語での定義がありました。

この記事が確かめきれていない点

• Gemini Notebookの内部がRAGで作られているかは、ヘルプの説明から分かる範囲を超えます。本記事は、ヘルプの文言が「取得してから回答」という流れと同じ、という所までを書いています。
• 原論文は要旨を読みました。論文の本文（実験の細部）は、本記事の説明に使っていません。
• 各ベクトルデータベースやフレームワークの性能・料金は確かめていません。公式ページの紹介文だけを載せています。
• Anthropicの「約20万トークン」と「検索の失敗が49%・67%減」は、2024年9月19日の記事の数字です。いまのモデルや環境で同じになるかは確かめていません。

この記事が当たった資料

出典は、frontmatterの出典の一覧にあるとおりです。AWS・Google Cloud・Microsoftの3社は、英語版と日本語版の両方を2026年10月8日に取得して読みました。2026年8月27日の訂正（AWS解説からの引用の体裁の修正）は、訂正の欄に残しています。各サービスの機能や料金は更新されるので、実装を決める時は公式ドキュメントの最新版を見てください。