「RAGは死んだ」を正しく読むには、4層に分けて見る

0. シリーズ案内 — ここから「実務セクションM」に入ります

AIのしくみ地図シリーズがF(Foundation) → B(Bridge) → M(Meta・実務) の流れで進むという話を最初の回でしました。この回からがMシリーズです。F1〜F6でLLM・Transformer・ディープラーニング・embedding・attention・gradient descentまでの基礎感覚をつかみ、B1〜B3でプロンプト・エージェント・fine-tuning対RAG対promptの比較をしました。いよいよその上で実務の話を始めます。

Mシリーズの1本目にretrievalを選んだのは、2026年のいま、もっとも解釈が濁っている領域がここだからです。ニュースは毎日「RAGは死んだ」と「RAGはまだ残る」の間を行き来します。プロダクト側も「うちはRAGを使わない」と「うちはRAGを使う」を同じ文の中で混ぜて書きます。論文は「Graph」「Agentic」「Memory」「Doc-to-LoRA」のような別々の単語を同じカテゴリかのように並べます。これをひと塊のまま読んでいると、ずっと混乱します。

この記事のゴールは ひとつ です。「RAG」というひと単語の中に、実際にはまったく性格の違う4つの層が入っているという感覚を持ってもらうこと。その感覚ができれば、ニュース・プロダクト・論文が同じ速度で鮮明になっていきます。

1. 「RAGは死んだ」という言葉がなぜ繰り返し出るのか

まずは空気感から。最近のAIコミュニティでは「RAGは死んだ (RAG is dead)」という言い回しが定期的に回ってきます。AnthropicのClaude Codeがローカルのベクトルデータベースなしで、ただgrepやファイル読み取りのツールだけでコードベースをうまく探索している姿を見て、「ほら、お金をかけてベクトルDBを組んでいたのが無駄に見える」と主張する流れがあります。一方で、Gemini 1.5・Claude 4・GPT-5などのモデルのコンテキストウィンドウが100万トークンまで伸びたことで、「文書まるごと入れればいいのに、なぜ別途検索するのか」という主張も出てきます。

ただ、この一文を平たく受け取ると損をします。死んだと呼ばれているのが 正確に何なのか が重要です。

現場で「死んだ」と呼ばれているのは、ひとつの狭い領域です。「ローカルのベクトルDBをあらかじめ構築しておいて、質問が来たときに一度だけtop-kでchunkを取り出してプロンプト末尾に貼る」 というその一パターン。ここが最近、過大評価されていたよね、という指摘なんです。RAGの他の層は死ぬどころか、いまが全盛期です。Perplexityが毎日Web検索をしながら答える方式、Claude Researchが何度も再検索する方式、Microsoft GraphRAGのように関係グラフを積む方式、Doc-to-LoRAのように文書をそのまま重みに焼き込む方式 — これらは全部、RAGの別の層でいま熱く発展中です。

だから層を分けずに「RAG死んだのか」と問うと、答えはいつも両義的になります。層を分けると問いが変わり、答えが鮮明になります。

この記事は、その層分けを一緒にやってみる記事です。

2. Retrievalをひと塊で見ない訓練

実務で一番よく遭遇する混乱がこれです。誰かがあるプロダクトを見せてくれます。「これRAG使ってるんだって。」その一文だけでは感じがつかめません。ベクトルDBが動いているのか、モデルが検索を何度も呼び出しているのか、グラフ構造があるのか、会社の文書がモデル自体に溶かし込まれているのか — まったく違う動きが、同じひと単語の下にまとめられているからです。

ニュースも同じです。「RAG 2.0リリース」「RAGはもう必要ない」「うちはRAGでハルシネーションを抑えた」 — 同じ単語が3つの文で、3回ぜんぶ違うものを指しています。

この霧を晴らすいちばん単純な方法が 層で分けて見る ことです。4つに分けます。覚える必要はありません。この記事を読み終える頃には自然に手になじみます。まずは名前だけさっと眺めてください。

層	短い名前	やっていること
1層	Embedding基礎検索	質問と文書をベクトルに変換して類似度計算
2層	GraphRAG	文書間の関係をグラフに仕立てて検索
3層	Agentic Retrieval	モデルが検索を道具として何度も呼び出す
4層	Memory Adaptation (Doc-to-LoRAなど)	文書をそのままモデルの重みに埋め込む

層が上にいくほど、「検索」の概念そのものが変わっていきます。1層は固定のベクトル空間でtop-kを取る行為。4層は「これはもう検索ではなく記憶だ」と言える地点。同じRAGの傘の下にあるのに性格が全然違います。

ここからひとつずつ入っていきます。それぞれの層で「どんなプロダクトがここに入るのか」「この層を選ぶべき状況はいつか」「この層の限界は何か」を順にくっつけていきます。

3. 1層 — Embeddingベースの基礎検索

F5でembeddingの話をしましたよね。文や単語を高次元ベクトルに変換する装置。「意味が近いものはベクトル空間でも近くに置かれる」という性質が肝でした。この性質がretrievalのいちばん基礎の層を可能にします。

1層がやることは直感的です。図書館の司書を思い浮かべてください。司書の前に本が1万冊あります。あなたが「猫の鳴き声の行動学について書かれた本ありますか」と聞いたとき、司書はすべての本を開いて確認したりしません。背表紙の主題タグを見て、関係がありそうな10冊を取り出して見せてくれます。その10冊の中で答えを探せばいい、ということですね。

Embedding ベースのretrievalはまさにこの仕事をしています。

• クエリ(質問)をembeddingモデルでベクトル化します
• すでにベクトル化しておいた文書の断片(chunk)を同じ空間で検索します
• コサイン類似度が高いtop-kを取り出します
• 取り出したchunkをプロンプトに貼り付けてLLMに入れます

保管庫はベクトルDBです。Pinecone、Weaviate、Chroma、pgvectorのようなツールがこの層で動きます。最近はPostgresにpgvector拡張を載せて、既存DBの中で済ませるパターンもよく見ます。

この層の長所は シンプルさ と 予測可能性 です。chunkの品質が良く、embeddingモデルが自分のドメインに合っていれば、そこそこうまく回ります。コストもいちばん安いです。一度ベクトル化してしまえば、以降の検索はほぼタダ同然です。

限界もはっきりしています。chunk同士の関係が消えてしまう んです。同じ文書の中ですぐ隣にあった2つのchunkが、ベクトル空間では赤の他人どうしになります。「AはBの子プロセス」のような構造情報や、「この節は前の節への反論」のような論理関係は、chunkに切った瞬間に飛びます。だから 複数の文書をまたがないと答えが出ない質問 や 構造的な質問 には弱いです。

もうひとつの罠が「embeddingモデルなんてどれも似たようなものでしょ」という誤解です。実際には、英語ベンチマークの上位モデルが、韓国語や日本語のような東アジア言語で急に落ちるケースがよくあります。ドメインも同じで、一般文書向けのembeddingは医療文書やコードで性能がガクッと下がります。chunkサイズも性能を大きく左右します。大きすぎると意味がぼやけ、小さすぎると文脈がなくて空振りします。

「RAG死んだ」という話が主にこの1層を狙った 話だということをここで覚えておいてください。100万トークンのコンテキスト時代に、「小さなコーパスをあらかじめベクトル化してtop-kで取り出す」という単純なワークフローは、わざわざ必要ない状況が増えました。それでも1層が消えるわけではありません。ただ、1層だけを使う設計が減り、1層が「他の層の基礎部品」として組み込まれる方向に動いています。

4. 2層 — GraphRAG、文書と文書の関係まで

1層が「似ている本を探す」だとしたら、2層は「本と本の間に線を引く」です。

Microsoftが2024年にオープンソースで公開した GraphRAG がこの層の代表格です。単純に類似度でchunkを取り出すのではなく、文書の中から エンティティ(人物・会社・概念・プロダクト) を抽出し、そのエンティティ同士の 関係 をグラフ構造で積みます。検索のときは「この質問に関係するノード」だけを探すのではなく、「そのノードにつながっている隣のノード」までも一緒に持ってきます。

例を挙げます。あるIT大手の過去5年分の社内文書10万件を検索するシステムを作るとしましょう。「うちの会社で[Aプロジェクト]がなぜ中止されたのか」という質問が来たとします。

• 1層(embedding)で解くと: 「Aプロジェクト 中止」に近いchunkをtop-10で取り出してプロンプトに入れます。うまくいけば中止の公示がひとつ引っかかりますが、なぜ中止になったのかの文脈 — 以前に社内のどの部署と摩擦があったのか、どの意思決定会議で決まったのか — は別の文書に散らばっていて、取りこぼしやすいです。
• 2層(GraphRAG)で解くと: Aプロジェクト というエンティティノードから出発して、つながっている隣のノード(意思決定会議、責任者、利害関係部署、代替プロジェクト) まで一緒に取ります。中止の文脈がひとまとまりで揃います。

GraphRAGが特に強い領域はいくつかあります。

• 複数の文書をまたぐ質問: 「この人物はどの会社を渡り歩いてきて、いまはどこにいるか」のように、答えがひとつの文書には無く、複数の文書を紐付けないと出てこない質問。
• 組織・系統・関係の追跡: 人物関係、会社の買収系譜、プロダクトのバージョン系譜、法律条項の参照関係のようなもの。
• 全体構造の把握質問: 「このコーパス全体で核になるテーマは何か」のような要約級の質問。GraphRAGはcommunity detectionでグラフをクラスタリングして、全体像を取り出せます。

限界 も明確です。グラフを積むコストがそれなりに大きい。エンティティ抽出、関係抽出、クラスタリング — ぜんぶLLM呼び出しが走る前処理です。文書がよく変わる動的コーパスではグラフを組み直し続けないといけないので負担が大きい。そして 関係情報がスカスカなコーパス — 例えば、互いに独立したFAQの集合 — では、グラフ層を積んでも得るものがあまりありません。

2層を「1層の代替」として読まないことが大事です。GraphRAGの内部でもノード間の類似度計算にembeddingを使う実装が多い。1層は下にそのまま残り、2層がその上に関係レイヤーを重ねる構造です。

5. 3層 — Agentic Retrieval、モデルが検索を道具として使う

1層と2層までは「一度検索する」という前提を共有していました。質問が来るとシステムが関連情報をひとまわし取り出し、それをプロンプトに貼ってモデルが答えを作る。モデルは検索結果を 受け身で受け取る 側でした。

3層はこの前提をひっくり返します。

Agentic retrieval は モデルが検索を自分で道具のように呼び出す 方式です。B1で扱ったtool useを覚えていますか。モデルに関数をいくつか持たせて「必要なら呼び出して」と指示するパターン。agentic retrievalはそのパターンの中に検索関数を入れるということです。

実際の動きはこんな感じです。

1. ユーザー: 「昨年のQ4のうちのチームのOKR達成率を分析して。」
2. モデル: (内部判断) この質問に答えるにはOKR文書が必要だ → search("2025 Q4 チーム OKR") を呼び出す
3. 検索結果を受信: OKRの原本文書の要約が返ってくる
4. モデル: この文書を見ると評価結果が別にあるようだけど無いな → search("Q4 OKR 評価結果") をもう一度呼ぶ
5. 結果を受信 → 満足 → 答えを組み立ててユーザーに返す

ここでのポイントは、検索が 複数回起こりうる こと、そして 2回目の検索語は1回目の結果を見たうえでモデルが作る ということです。これが「agentic」という言葉の意味です。検索の主体が、人が事前に書いたスクリプトから、モデル側に移動しています。

どこですでに使われているのか。あなたが毎日触っている道具のほとんどがここです。

• Perplexity: 質問に答える前にWeb検索を何度も回します。検索語の組み立て、検索回数、どの結果を見るかをモデルが決めます。
• Claude Research (Anthropic): 深い質問には複数のクエリを繰り返しながらソースを集めます。
• ChatGPT Browse / GPT-5 search: 似た構造です。
• Claude Code: これはWeb検索ではなくファイル検索。grep、glob、read のようなローカルツールを呼び出してコードベースを自分で探索します。ベクトルDBなしでもうまく回るのはこの働きのおかげです。

3層が強いポイントは 想定外の質問 です。1層・2層は開発者があらかじめ「この質問にはこの検索をする」をある程度設計しておかないといけません。3層はモデルが状況を見て検索戦略をその場で組むので、シナリオが多様な環境でもよく耐えます。もうひとつ、再検索 ができます。最初の結果が足りなければキーワードを変えてもう一度入っていく。人がGoogle検索のときにやる、あの動きです。

限界もあります。コストとレイテンシ です。検索1回がモデル呼び出し1回を誘発し、さらに検索結果をモデルに入れ直さないといけないので、トークンと時間が掛け算で増えます。そして、モデルが検索を 呼びすぎたり呼ばなすぎたり する失敗パターンもよくあります。このバランス取りがagentic retrieval設計の大きな宿題のひとつです。

3層は「検索をよりうまくやる」層ではなく 「検索の呼び出しの主体を、人からモデルに移す」層 だ、というのが正しい捉え方です。下の層(embedding・graph)の基礎ができていないと、3層で呼び出す主体だけが変わっても結果は良くなりません。

6. 4層 — Memory Adaptation、retrievalを重みに溶かす

ここから「これ、検索なのか?」という感覚が揺らぎはじめます。

1・2・3層はすべて 「文書を毎回、入力として渡す」 という前提を共有していました。形が違うだけで。embeddingで取り出したchunkをプロンプトに貼るにしても、グラフの隣まで一緒に貼るにしても、モデルが道具として呼び出して貼るにしても、その文書は プロンプトに入って一度読まれたら消える んです。

4層はこの前提を捨てる層です。

代表的な研究が2024年末から盛り上がっている Doc-to-LoRA です。名前のとおり「文書をLoRAの重みに変換」するアプローチです。LoRAはモデル全体を再学習せず、軽い重み差分だけを乗せるfine-tuning手法なんですが(B3で扱いました)、これをretrieval代わりに使います。

流れを比喩で解くとこうです。会社に新人を入れたとしましょう。

• 1〜3層の方式: 質問が来るたびにマニュアルを開いて該当ページを見せて答えさせる。効果はあるけど、毎回マニュアルを取り出さないといけません。
• 4層の方式: マニュアルを新人の頭に埋め込んでおく。学習が終われば、マニュアル無しでもその内容を知っている状態になります。プロンプトにマニュアルを入れる必要が無い。

技術的には、会社の文書をあらかじめ訓練データとして入れ、小さなLoRAアダプタ を学習させます。推論時にはそのLoRAをモデルに乗せるだけで、モデルはその領域の内容を「記憶」した状態で答えます。プロンプトに文書を入れなくて済みます。

どんな状況で使うか が大事な層です。これは1〜3層のように「基本設定」ではなく、「特定の状況を別の層に切り出す選択肢」 として理解しておいたほうが、ずれが少ないです。

4層が合う状況:
– 同じ文書を 繰り返しプロンプトに入れる コストが大きいケース。例: 会社専用のAPIスペック数百ページを、開発者全員が毎日何十回もクエリする。
– 文書が ほとんど変わらない 静的な資産。例: 法規、社内のコーディングスタイルガイド、固定された製品マニュアル。
– 応答の遅延 を極限まで縮めたい環境。毎回文書を読む時間がないリアルタイムサービス。

4層が合わない状況:
– 文書が 毎日変わる 動的コーパス。学習を頻繁に回さないといけないのでコストが逆に大きくなります。
– 最新性 が重要な情報。昨日追加されたニュースを今日モデルに反映するには再学習が必要。
– 権限分離 が必要なケース。ユーザーごとに見られる文書が違うなら、LoRAをユーザーごとに持つことになるので運用が複雑化します。

4層の本当の意味はこう読んだほうがいいです。「ある文書はretrievalに残し、ある文書はretrievalの外に切り出してモデルに溶かす」 という配置の問題ができる。long-context対RAGの論争が「どちらか一方」ではなく「文書ごとに別の配置」の問題に組み替わります。この組み替えが、2025年以降のretrieval議論における最重要な変化です。

7. 4層を1枚に並べて比較する表

ここまで出てきた4層を1画面に置いてみます。覚える必要はなく、ニュースを読むときに頭の中からこの表を取り出せるといいな、くらいでいいです。

層	核の動作	代表ツール	Latency	コスト	更新しやすさ	合う作業
1. Embedding基礎検索	top-kベクトル類似	Pinecone, pgvector, Weaviate	非常に低	非常に低	容易(chunk追加)	定型FAQ、単発回答
2. GraphRAG	関係グラフ照会	Microsoft GraphRAG, LangChain Graph	低	前処理大、照会低	中(グラフ再構築)	複数文書をまたぐ質問、系譜追跡
3. Agentic Retrieval	モデルが検索を複数回呼ぶ	Perplexity, Claude Research, Claude Code	中〜高	中〜高(呼出累積)	容易(ツールのみ更新)	想定外質問、Web探索、コード探索
4. Memory Adaptation	文書を重みに学習	Doc-to-LoRA研究、fine-tune API	非常に低(プロンプト不要)	学習コスト大	困難(再学習必要)	静的文書の繰り返し、会社専用知識

この表の読み方のコツがひとつ。層が上にいくほど「検索」という瞬間が消えていく方向 です。1層はクエリごとに検索を1回、2層は依然として1回だが構造がリッチ、3層は複数回繰り返し、4層はそもそも検索が起きません(代わりに学習が一度起こる)。検索行為がだんだん「モデル内部」へ移動していく流れ、と見てもいいです。

もうひとつ。層はお互いを排除しない です。4層を使うからといって1層が消えるわけではない。会社のコア知識は4層に埋め込み、動的な文書は1層に置き、複雑な質問は3層のエージェントが1層を繰り返し呼ぶ — こういう 混合構成 が実際のプロダクションの基本です。

8. 「いまのこのニュース・このプロダクトは何層か」を問う訓練

層の構造を頭に入れたら、練習が必要です。実際の記事やプロダクトを見るたびに「これ何層の話だ?」と心の中で問う訓練。いくつかの例を一緒に解いてみます。

例1. 「AnthropicのClaude Codeがベクトルデータベース無しでコードベースをうまく探索する」という記事を読んだ。何層?

→ 3層(agentic retrieval)の話です。Claude Codeは grep、glob、read のようなツールをモデルに持たせ、モデルが「いまこのファイルを見るべきだ」を判断して呼び出します。1層(ベクトルDBにあらかじめ入れる)を飛ばして3層に直行した事例です。「RAGが死んだ」が、この文脈でよく出てきます。正確に言えば「ここでは1層が必要なかった」が正しい。

例2. 「Perplexityが新モデルで回答品質が上がった」というリリースノートを読んだ。何層?

→ 主に3層ですが、1層にもまたがります。Perplexityはモデルが複数の検索クエリを作って回し、結果を統合します(3層)。同時にWebインデックス自体は巨大なembedding/lexicalインデックスで構築されています(1層系)。だから「回答品質」の改善は、モデルのエージェンティックな判断が良くなったのか、それとも基盤のインデックス品質が良くなったのかを分けて読む必要があります。

例3. 「MicrosoftがGraphRAGオープンソース2.0を発表」というニュース。何層?

→ 2層の話です。関係グラフを乗せる層。これは1層の代替という意味ではなく、1層の上にグラフ構造層がよりリッチになる、という意味です。

例4. 「この会社は自社の法律文書10万ページでLoRAを学習して専用モデルを作った」という事例。何層?

→ 4層です。静的で、権限が社内に閉じた大型の法律文書は4層の典型的な適用例です。毎回法律文書10万ページをretrievalで取り出すより、モデルに埋め込んでおくほうがコストとレイテンシの両面で有利。

この練習に慣れると、ニュースの流れる速度が変わります。「RAG 2.0」「RAG is dead」「うちはRAG使わない」のようなマーケティング文が混乱の種にならなくなる。「この人がRAGと言うとき、何層を指しているのか」 だけ見ればOKです。

9. 層を混ぜる現実 — プロダクションのパターン

純粋に1層だけ使うプロダクトは稀です。実際のプロダクションでは層を組み合わせます。よく出るパターンをいくつか示します。

パターンA — 1層フィルタ + 3層refine

ユーザーが質問します。まず1層のembedding検索で関係がありそうな文書100件を素早く取ります(安くて速いので)。その100件をモデルに渡して、3層のagentic retrievalで「この中で本当に関係があるものはどれか」をもう一度絞ります。最後に残った10件くらいだけがプロンプトに入ります。

長所: 1層の低コストと3層の精度を両方使える。短所: 呼び出しが入れ子になり、設計が複雑になる。

パターンB — 2層 + 3層

GraphRAGで作ったグラフをツールで包みます。モデルは graph_query(entity, depth) のような関数を呼び出して関係の隣を受け取ります。質問に応じてモデルが深さを調整できるようになります。

長所: 構造情報を動的に活用できる。短所: グラフ構築コスト + エージェント運用コストが両方かかる。

パターンC — 4層のシステム知識 + 1層の動的文書

会社専用の製品マニュアル・コーディングガイド・スタイルガイドのようにほぼ変わらない文書は、4層のLoRAでモデルに溶かします。毎日変わるチケット・レポート・ダッシュボードは、1層のベクトルDBで保管して必要なときだけ取り出します。

長所: 静的知識はプロンプトから消えるので、トークン予算に余裕ができる。動的知識は最新性を維持できる。短所: 運用パイプラインが2つに分かれる。

パターンD — 100万トークンのコンテキスト + 1層の事前フィルタ

最近熱いパターンです。Gemini 1.5やClaude 4のような1M+コンテキストを活用します。全コーパス1000万トークンの中から1層のembeddingで100万トークンほどを絞り、そっくり丸ごとモデルに入れます。その中ではコンテキストウィンドウが勝手に全部処理してくれます。「chunkを切り分ける」負担がぐっと減ります。

長所: chunk品質の問題から解放される。短所: APIコストがクエリあたりそこそこ大きい。

ここで見えてくるポイントがあります。層は選択ではなく配置 だということ。「うちは何層を使うか」ではなく、「どの文書をどの層に、どの質問をどの経路で」 が正しい問いです。

この配置感覚が、retrieval設計における実務の核です。

10. ここでよくある勘違い3つ

最後に、この主題を見る読者が陥りがちな勘違いを3つだけ押さえておきます。

勘違い1 — 「context windowが大きくなったからRAGは要らない」

長く書けばこうです。「いまやGeminiは1M、Claudeは200k、GPTは200k+だ。文書を全部プロンプトに入れればいいのに、なぜ別途検索するのか。」

この発言は、小さなコーパス と 大きなコーパス を混同したときに生まれる勘違いです。本1冊(30万トークン)、長い論文数本(50万トークン)くらいならもう入れられます。でも会社全体のWiki(5000万トークン)、コードベース全体(数千万トークン)、顧客問い合わせの履歴(数億トークン)は、依然として丸ごと入りません。量が合わないと検索は残ります。そして お金と時間の問題 もあります。1Mトークンを毎クエリで入れるのは、コストもレイテンシも重い。「関係ある部分だけ取り出して入れる」というretrievalの役割は当面残ります。

勘違い2 — 「RAGを付けたからハルシネーションが消えた」

RAGを使うとハルシネーションが減るのは本当ですが、消えません。理由は2つ。

第一に、retrievalの結果が 不正確な場合がある 。見当違いのchunkが上がってくると、モデルはその見当違いの情報を根拠に、きれいに間違った答えを作ります。RAGは「外部情報をうまく入れる工程」であって「外部情報が正しいことを保証する仕組み」ではありません。

第二に、モデルは 受け取った情報を無視して自分の記憶で答える ことがあります。特にretrieval結果がモデルが元から知っていた内容と衝突すると、モデルが検索結果を無視する失敗がよく起こります。

だからRAGを付けたからといって、出典表示のない回答をそのまま信じてはいけません。出典提示・引用・検証のような装置が別途必要です。

勘違い3 — 「embeddingモデルなんて大同小異」

1層の基礎を敷くときに「OpenAI text-embedding-3-smallでもBGEでも、違いは誤差の範囲でしょ」と流す人が多い。これが致命的になることがあります。

言語ごとに性能差が大きい。英語ベンチマーク上位のモデルが日本語や韓国語で変に振る舞うケースがあります。ドメインごともそう。一般文書のembeddingがコードや医療文書ではガクッと落ちます。chunkサイズとの相互作用もあります。長いchunkに強いモデルと、短いchunkに強いモデルがあります。

retrievalデバッグの半分以上が 1層の問題 から出てきた、というのが自分の経験です。上位層を派手に飾る前に、1層でembeddingモデルが自分の言語・ドメインに合っているか、chunkは適切に切れているかを先に確認するのが順序です。

11. M9で再び扱う問い — 「で、RAGは本当に死んだのか」

この記事は入門編なので、ここで単答はしません。M9で「RAGは死んだのか」という問いを本格的に扱う予定です。その代わり、4層観点からの短いプレビューだけ渡します。

• 1層は役割が縮小している。 小さなコーパス + 大型コンテキストの組み合わせでは、1層単独の使用根拠が弱くなりました。ただし、大きなコーパスの事前フィルタとしてはいまも生きています。
• 2層は特定コーパスでだんだん重要になっている。 関係情報が重要な技術・法律・医療文書ではGraphRAGが強くなっています。
• 3層は主流になりつつある。 Perplexity・Claude Research・Claude Codeが示す方向がこちら。「モデルが検索を道具として使う」というパターンは消えません。
• 4層はニッチだが伸びている。 会社専用知識・静的な大型文書で静かに増えています。

だから「死んだか」という単答は正解になりません。正しい問いは 「自分の状況でどの層がボトルネックで、どの層に仕事を配置するか」 です。この感覚が手になじむと、RAG議論ぜんたいが穏やかに見えます。

---

一文で締めます。 「RAG」というひと単語の中には、互いに非常に違う4つの層があり、その層を分けて見たときだけ、「RAG死んだ」のような文もプロダクト説明も論文解釈も、同時に鮮明になる。この4層マップを持ち歩いてください。

---

次に読む

• M2 — Long-contextとMemoryは同じ話なのか — 100万トークンコンテキストは本当にRAGを代替するのか、そして「memory」という単語が最近のプロダクトで実際に指しているものを扱います。
• M9 — RAGは本当に死んだのか [準備中] — 今回の4層視点を持って、本格的な答えを探しに行きます。

シリーズの最初から: F1 — LLMとは何か · F5 — Embeddingの感覚 · B3 — Fine-tuning vs RAG vs Prompt

FAQ

Q1. 4層のうちどこから勉強すべきですか?

1層からです。embeddingとベクトル検索の一行を自分の手でコードに落としてみると、上の層の話がずっと早くくっついてきます。LangChainのチュートリアルから10行のvector retrievalサンプルを先に回し、次に2層(GraphRAG公式サンプル)、3層(Claude Codeでコードベース探索を観察)、4層(LoRAの基礎学習の実習)の順で上がっていく、を推奨します。順序を飛ばすと「4層がなぜ存在するか」の感覚がつきません。

Q2. うちのプロダクトにどの層を使うべきか、どう決めますか?

3つの問いを順番に投げてみてください。(1) コーパスサイズはコンテキストウィンドウに入るか — 入るならあえてretrievalを使わなくてよい。(2) 文書はよく変わるか — 頻繁に変わるなら4層ではない。1〜3層から選ぶ。(3) 質問はひとつの文書で完結するか、複数の文書をまたぐか — 複数をまたぐなら2層か3層が必要。この3つの答えが出れば、組み合わせはほぼ自動で決まります。

Q3. Claude CodeやPerplexityの内部構造をもう少し深く知りたい。

どちらのプロダクトも公式ブログ・エンジニアリングポストで手がかりをけっこう公開しています。Anthropicの「How we built Claude Code」ポストが3層のagentic retrievalパターンをよく説明しています。Perplexityは公式ブログで検索クエリの組み立て方を一部明かしています。今回の記事の4層マップを持って、それらの記事を再読してみると、得られるものがぐっと増えます。

---

ニュースレターのご案内

毎週月曜日の朝、AI・LLM・エージェント関連の実務整理を1通お届けしています。こういう技術地図を落ち着いて積み上げたい方は、購読どうぞ。

ニュースレター登録(無料・30秒)

---

著者: バイブコーディング テイラー(Lovable公式アンバサダー)
運営: テイラーの隠れ家(shuntailor.net)

ソースリスト

• テイラー知識百科事典 — AIのしくみ地図カテゴリ（本シリーズ20編全編）
• AIのしくみ地図 エントリーマップ — 全体構造 + 3つの読み方
• “Attention Is All You Need” (Vaswani et al., 2017)
• Anthropic · OpenAI · Google 公式ドキュメント
• mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown — 易しい解説のリファレンス

---

著者: バイブコーディング テイラー (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ「AIのしくみ地図」20編は、ウィキの蓄積と公式論文・公式ドキュメントを根拠に整理した体系的学習カリキュラムです。