今更聞けないRAG

あっちでもRAG、こっちでもRAG。

業界にいると、RAGという言葉をたくさん耳にします。

とはいえ、最近はRAGとは言わなくなってきている側面もあり、マーケティング用語と化している側面もあります。RAGが何なのか、理解せずに使っていたりしませんか？今日は今更聞けないRAGについて解説していきたいと思います。

RAGの定義

RAGとは、Retrieval-Augmented Generationの略で、検索拡張生成という意味を持っています。言い換えると、検索結果を利用する拡張された生成です。本来のモデルの能力だと持っていない情報を検索で補い生成出来るようにするということなんですよね。

では、なぜそのようなことが必要でしょうか。それはモデルが作られる方法に関連があります。

Claude, GPT, GeminiなどのLLMモデルは作るときに、世の中から様々な情報を集めてずっと読ませています。イメージでいうと、人間が生まれて、様々なことを経験して学習していく過程に近いです。赤ちゃんは最初、文字の読み方、単語や言語、音の出し方すら分かっていない状態で始まりますが、時間がたつと、いくつかの単語が言えるようになり、会話ができるようになり、それを使ってさらに高度なものを学習していきます。

モデルを生成する際にも同じように、大量の文書をひたすら聞かせてあげていて学習させています。しかし、人間と異なる限界がありますが、モデルは一度学習されると、その段階で脳が固定されリリースされます。したがって、2026年1月1日まで学習をしたのであれば、それ以降に起きたことに関しては何も知りません。実は今の作りのLLMは、人間のように経験したことを元に自ら学習を重ね、進化することもできないのです。初期のLLMでは、定期的に最新の情報を追加して、新しいバージョンを公開してきました。しかし、こういったモデルの学習には天文学的な費用がかかります。

ではどうするのか。そう。インターネット検索を利用すればいい。それがRAGです。

RAGの変化の歴史

RAGとはなにか分かったところまではいいのですが、ではどうやってそれを実装するのでしょうか。これにはいくつかの方法がありますが、実は最初から今までで言うと、かなり大きく変わってきました。ここではそれを踏まえた上で、どういう方向に進んでいるのかを追ってみます。

雰囲気をつかんでもらうために、各時代の処理の流れを簡単な図にしてみます。

第0期：論文としてのRAG（2020年）

RAGという言葉が生まれたのは2020年、Facebook AI Research（現Meta）の論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」です。ChatGPTが出る2年以上前ですね。

この頃のRAGは、今イメージするものとはかなり違います。検索対象はインターネットではなく、Wikipediaを約2,100万件の短い文章に区切ったもの。そして、検索する部分と文章を生成する部分を、ひとつのモデルとしてまとめて学習させていました。

質問「日本の首都は？」
   │
   ▼
質問をベクトル（数値の列）に変換
   │
   ▼
Wikipedia（約2,100万件）から、意味が近い5件を取得
   │
   ▼
生成モデルが、質問 ＋ 5件を読んで回答を生成
   │
   ▼
回答「東京」

※ 学習時は、正しい答えが出るように
   「質問をベクトルにする部分」と「生成モデル」を一緒に更新する

ここで出てくる「ベクトル」は、文章の意味を数百個の数字の並びで表したものです。意味が近い文章ほど数字も近くなるので、「近い数字を探す」ことがそのまま「意味が近い文章を探す」ことになります。この仕組みは、この後もずっと登場します。

ポイントは最後の注記です。検索の仕方まで含めて学習していたので、この時点のRAGは「使い方」というより「モデルの構造」の名前でした。

ただし、この論文には今につながる大事な発見もありました。Wikipediaのインデックスを新しいものに差し替えるだけで、再学習せずに知識を更新できたのです。冒頭で書いた「モデルの脳は固定される」問題への答えは、最初からここにあったわけです。

第1期：Naive RAG（2023年〜）

2022年11月にChatGPTが登場すると、多くの企業が「自社のデータでChatGPTを使いたい」と考えました。でも、GPTを自社データで再学習させるのは現実的ではありません。

そこで発想が変わります。モデルは一切いじらず、検索した文章をプロンプトに貼り付けて渡せばいい。LLMは渡された文章を読んで答えるのが得意なので、これでかなりうまくいきました。ここでRAGの意味は、「モデルの構造」から「検索結果をプロンプトに入れる設計パターン」に変わります。

処理は「準備」と「質問時」の2段階です。

【準備】事前に1回だけ
社内文書 ─▶ 500文字ずつに分割 ─▶ ベクトル化 ─▶ ベクトルDBに保存

【質問時】
ユーザーの質問「経費精算の締め日は？」
   │
   ▼
質問をベクトル化して、ベクトルDBを検索
   │  意味が近い上位4件を取得
   ▼
プロンプトを組み立てる
   「以下の資料だけを使って答えて」＋ 検索結果4件 ＋ 質問
   │
   ▼
LLMが回答を生成
   │
   ▼
ユーザーに返す

驚くほどシンプルですよね。数十行で「社内文書に答えるAI」のデモが作れたので、LangChainやLlamaIndexといったライブラリ、PineconeやChromaのようなベクトルDBが一気に広まりました。「RAG＝ベクトル検索」というイメージが定着したのはこの頃です。

ちなみに「Naive（素朴な）RAG」という呼び方は、後から振り返って付けられた名前です。実際に業務で使ってみると、精度が出ない問題が次々と見つかりました。

チャンクの境界で文脈が切れる。「上記の条件を満たす場合」の「上記」が、別のチャンクに入ってしまう
型番やエラーコードに弱い。ベクトルは「意味」を表すので、「E-1024」と「E-1025」のような違いの区別が苦手
質問と答えの書き方が違うとヒットしにくい。質問は「締め日は？」、マニュアルは「毎月25日までに申請すること」
上位4件が全部ハズレでも、LLMはそれっぽい答えを作ってしまう

第2期：Advanced RAG（2023年後半〜2024年）

第1期の問題に対して、パイプラインの各段階を改良していったのが第2期です。

ユーザーの質問「E-1024エラーが出た時の対処は？」
   │
   ▼
① クエリ書き換え（LLMが検索しやすい言い方を3つ作る）
   │
   ├─▶ ② ベクトル検索 ……… 意味が近いもの
   ├─▶ ② キーワード検索 …… "E-1024" を含むもの
   │
   ▼  両方の結果をまとめる（候補 数十件）
③ リランキング（質問との関係が強い順に並べ直して、上位5件に絞る）
   │
   ▼
プロンプトに入れて、LLMが回答を生成
   │
   ▼
ユーザーに返す

クエリ書き換えは、「質問と答えの書き方が違う」問題への対策です。ハイブリッド検索は、昔ながらのキーワード検索（BM25というアルゴリズムが定番）を組み合わせて、型番やエラーコードに強くします。リランキングは、ざっくり集めた候補から、質問と本当に関係があるものを選び直す工程です。

文書側の工夫も進みました。Anthropicが2024年に発表した「Contextual Retrieval」は、各チャンクに「これは何の文書の、どの部分か」という短い説明をLLMで付けてから保存する手法です。「上記」が何を指すか分からなくなる問題を和らげます。

MicrosoftのGraphRAG（2024年）は、文書から人物や組織、その関係を抜き出してグラフにしておきます。「この資料全体から何が言えるか」のような、チャンクを数件拾うだけでは答えられない質問に対応するためです。

精度は確実に上がりましたが、パイプラインはどんどん複雑になりました。そして、構造的な限界が残ります。検索は質問ごとに1回、決められた手順で実行されるだけ、という点です。

たとえば「E-1024で再起動しても直らなかったら、次はどうすればいい？」という質問。まず対処手順を調べ、そこに書かれた関連ページをさらに調べる必要があります。人間なら自然に「調べて、読んで、また調べる」をやりますが、決め打ちのパイプラインにはそれができませんでした。

第3期：Agentic RAG（2024年〜）

転機は、LLMが「ツールを使える」ようになったことです。2023年にOpenAIがFunction callingを公開し、ほかのモデルも続きました。これで検索を「決め打ちの手順」ではなく、「モデルが使える道具」として渡せるようになります。いつ、何を、何回検索するかは、モデル自身が決めます。

第2期の最後に出てきた質問だと、処理はこう流れます。

ユーザーの質問
「E-1024で再起動しても直らなかったら、次はどうすればいい？」
   │
   ▼
LLM「まず対処手順を調べよう」
   │  ツール呼び出し ─▶ 社内Wikiを検索「E-1024 対処」
   ▼
結果：手順書A「再起動で直らない場合は設定を確認（手順書Bを参照）」
   │
   ▼
LLM「手順書Bも読まないと答えられない」
   │  ツール呼び出し ─▶ 手順書Bを開いて読む
   ▼
結果：手順書B「timeout の値が短すぎると発生する」
   │
   ▼
LLM「今の設定値も確認しておこう」
   │  ツール呼び出し ─▶ grep "timeout" config/
   ▼
結果：config/app.yml に timeout: 5
   │
   ▼
LLM「これで答えられる」
   │
   ▼
ユーザーに返す
「timeout が5秒と短いのが原因です。手順書Bの推奨値に変更してください」

第1期と1行で並べると、違いがはっきりします。

第1期：質問 ─▶ 検索 ─▶ LLM ─▶ 回答
第3期：質問 ─▶ LLM ─▶ 検索 ─▶ LLM ─▶ 読む ─▶ LLM ─▶ grep ─▶ LLM ─▶ 回答

第1期は「検索してから、LLMに聞く」でした。第3期は「LLMに聞いて、LLMが必要なら検索する」です。主語が入れ替わり、検索はパイプラインの一部から、モデルが使う道具のひとつになりました。

この形だと、第2期で残った問題も自然に解けます。対処手順を検索して読み、足りなければ関連ページをまた検索する。人間がやっていた「調べて、読んで、また調べる」を、モデルがループの中でやってくれます。

2024年11月にはAnthropicがMCP（Model Context Protocol）を公開しました。社内Wiki、Slack、DB、GitHubなどをツールとしてつなぐ共通の規格で、「どこを検索させるか」を後から差し替えやすくなりました。

象徴的なのがClaude Codeです。Claude Codeはコードをベクトル化してDBに入れたりはしません。人間の開発者と同じように、grepで文字列を探し、ファイルを開いて読み、足りなければまた探します。

開発者のBoris Cherny氏はXで、初期のClaude CodeはローカルのベクトルDBを使ったRAGだったが、エージェント的な検索の方が概ねうまくいくとすぐに分かった、と述べています。理由として挙げられていたのは、仕組みがシンプルなこと。そしてセキュリティ、プライバシー、インデックスが古くなる問題、信頼性の面でも有利なことでした。

何十年も前からあるgrepが、少なくともコード検索ではベクトル検索を上回ったわけです。これはベクトル検索が不要になったというより、モデルが賢くなり、検索の「やり方」まで任せられるようになった結果です。

並行して：ロングコンテキストと「RAGは死んだ」論

同じ頃、もうひとつの流れがありました。モデルが一度に読める量（コンテキストウィンドウ）の急拡大です。2024年2月にGoogleが発表したGemini 1.5は、100万トークンを扱えました。長編小説なら数冊分です。

そうなると、こんな発想が出てきます。

ユーザーの質問
   │
   ▼
マニュアルを丸ごとプロンプトに入れる（数十万トークン）＋ 質問
   │  ※ 検索はしない
   ▼
LLMが回答を生成
   │
   ▼
ユーザーに返す

検索しなければ、チャンク分割もベクトルDBも要りません。ここで「RAGは死んだ」という声が上がりました。

ただ、実際にはそう単純ではありませんでした。

毎回100万トークンを読ませると、コストも待ち時間も大きい
長い文章の真ん中あたりにある情報を見落としやすい。2023年に「Lost in the Middle」として論文で報告されている
会社の全文書は、100万トークンにはとても収まらない

結局、両者は対立するものではなく、組み合わせるものに落ち着きました。検索で候補を絞り、絞った資料は長いコンテキストでじっくり読ませる。第3期のエージェントがgrepで見つけたファイルを丸ごと読めるのも、コンテキストが長くなったおかげです。

なぜ「RAG」と言わなくなったのか

ここで冒頭の話に戻ります。最近RAGと言わなくなってきたのは、RAGがなくなったからではありません。当たり前になりすぎて、わざわざ名前を付ける必要がなくなったからです。

第1期には「RAGシステム」と呼べるものがはっきりありました。チャンク分割、ベクトルDB、プロンプトへの貼り付け。それ自体がひとつの製品でした。

第3期では、検索はツールのひとつにすぎません。Web検索も、grepも、MCP経由のSlack検索も、「外から情報を取ってきて生成に使う」という意味では全部RAGです。でも、誰もそれを「RAG」とは呼びません。

議論の中心も移りました。2025年頃から広まった「コンテキストエンジニアリング」という言葉がそれです。限られたコンテキストに、何を、いつ、どれだけ入れるか。検索はその手段のひとつ、という位置づけです。

ひとつ実用的なヒントを。製品の説明に「RAG搭載」と書いてあったら、「どの時代のRAGですか？」と聞いてみてください。ベクトル検索で上位数件を貼るだけなのか、ハイブリッド検索やリランキングまでやっているのか、エージェントが自分で調べに行くのか。同じ「RAG」でも、中身はまったく違います。

これから：「何を検索するか」から「何を覚えておくか」へ

では、この先はどこに向かうのでしょうか。私は、検索の次は「記憶」だと考えています。

第3期のエージェントには弱点があります。毎回ゼロから調べることです。Claude Codeに作業を頼むと、コードベースをgrepして読み、状況を把握してから作業します。賢いですが、セッションが終わるとその理解は消えます。毎朝記憶を失う、とても優秀な新入社員のようなものです。

しかも、本当に必要な情報の多くはgrepしても出てきません。「この関数はなぜこう書かれているのか」「前に同じ方法を試してダメだった」「このチームではこう決めた」。こうした判断の経緯は、コードにはほとんど書かれていないからです。

そこで、エージェントが経験したことを記憶として残し、次に活かす仕組みが広がっています。いちばん素朴な形は、Claude CodeのCLAUDE.mdのように、プロジェクトのルールを書いておくファイルです。ChatGPTやClaudeのメモリ機能も同じ方向です。

タスク開始
   │
   ▼
記憶から、今回のタスクに関係するものを呼び出す
   「認証まわりは前回、トークンの有効期限で事故が起きている」
   │
   ▼
エージェントが作業（第3期と同じく、検索やツールを何度も使う）
   │
   ▼
今回わかったことを、記憶に書き込む
   │
   ▼
次のタスクの「記憶から呼び出す」で使われる

よく見ると、これも「検索して、生成に使う」なのでRAGの一種です。違うのは、検索する対象が「世界の情報」から「自分たちの経験」に変わったこと。そして、読むだけでなく書き込む工程があることです。

冒頭で、LLMは人間のように経験から学習を重ねられない、と書きました。RAGは「学習後の新しい情報を知らない」という問題を、再学習なしで解きました。記憶は「経験から学べない」という問題を、同じく再学習なしで解こうとしています。

RAGという言葉は消えつつあります。でも、モデルの外に知識を置いて、必要なときに取り出すという発想そのものは、形を変えて広がり続けています。