📚 全体地図を見る
「RAG は死んだのか」に、私が自分の言葉で答えるなら
0. シリーズ案内 — 今回は M9、私の立場を打つ回
この記事は20編のうち19本目です。M1 で私が retrieval を四つの層に分けて見ようという地図を描いて、その後 M2 (long-context と memory)、M3〜M8 を経て評価・運用・組織の観点まで一周しました。その文脈の上で、今回の M9 は少し性格が違います。今回は 私、テイラー本人の立場を打つ回 です。
理由は単純です。「RAG は死んだのか」という質問を、ここ数ヶ月ずっと繰り返し受けてきました。技術ブログのコメントで、Twitter の DM で、Threads で、講演会場で。私が RAG ベースのシステムを実務で運用してきたことを知っている人たちが「本当に死んだのか、テイラーはどう考えているのか」と聞いてくるんです。その質問があまりに頻繁なので、今回を機会に 一度にまとめて答えておく 回を書くことにしました。
だから、この記事はこれまでの記事とトーンが少し違います。他人の理論紹介ではなく「私の考えはこうです」を中心に進めます。根拠は M1〜M8 で積み上げた層構造と実務観察でしっかり受けて、立場の表明は自分の言葉でやります。一度読み終えたら 読者の方が「私は RAG のどの層を使っていて、どこに動くべきか」をそれぞれ判断できるように するのが、この記事の目標です。
1. 「RAG は死んだ」というヘッドラインが、なぜ毎年繰り返されるのか
まず観察から始めます。「RAG is dead」という文章は2023年にも回って、2024年にも回って、2025年にも回って、2026年のいまも回っています。一度二度死んで蘇ったわけではなく、毎年「死んだ」という話が周期的に噴き出します。そうしながら RAG 関連の論文・製品・カンファレンスセッション数は同じ期間ずっと増えてきました。死んだというのに、なぜこれほど生きているのか。
私が見てきたパターンはこうです。「RAG 死んだ」という文章が周期的に出てくるのは、三つのきっかけのどれかが繰り返されるからです。
一つ目、コンテキストウィンドウが拡張されるとき。 2024年に Gemini 1.5 が100万トークンを見せて一度噴き出し、その後 Claude と GPT 系も長いコンテキストに追いついてきてまた噴き出しました。「もう文書を丸ごと入れればいいのに、なぜ retrieval を使うのか」という主張がそのたびに回ります。
二つ目、新しいパラダイム製品が出るとき。 Claude Code がベクトル DB なしに grep とファイルツールでコードベースを探索するのが話題になったとき、一度大きく噴き出しました。Perplexity や Claude Research がウェブをリアルタイムで検索しながら答える方式が注目を浴びるときも似たような主張が出てきます。
三つ目、既存の RAG 実装が大きく失敗した事例が共有されるとき。 誰かがベクトル DB に会社の文書を大量に入れたのに幻覚が減らなかった、検索結果がおかしくて使いものにならなかった、こういう経験談が共有されると「RAG は過大評価ではなかったか」という反応が回ります。
この三つのきっかけには共通点があります。どれも「RAG」という一つの単語の下に、実は全く違う複数の構造が混ざっているという事実を無視するとき に出る反応です。M1 で私が敷いた4層地図をもう一度取り出せば、この混乱の大半は解けます。だから今回の記事でも、その地図を軸に使います。
ついでに、もう一つ観察を添えます。「RAG 死んだ」を一番強く主張する人たちのうち、かなりの数が 自分の作ったシステムが1層に留まっています。1層でうまくいかなかった経験を元に、RAG 全体への判定を下しているわけです。逆に、2〜4層で働く人たちは「RAG は死ぬどころか、これから始まる」側に立っています。同じ単語を使っていますが、指しているものが違うんです。
2. 私の答え — 「死んだのは1層だけ。2〜4層はむしろ拡張中」
本題に入ります。私の答えはこれです。
「RAG は死んだ」は半分だけ正しい。死んだのは1層で、2〜4層はむしろ全盛期に向かっている。
もう少し解くとこうなります。
- 1層(単純 embedding + 一回きり retrieval) — 実戦での競争力をほぼ失った。この層だけを使う設計は最近ほとんど生き残れません。この層については「死んだ」という言葉が半分くらい当たります。ただし完全に消えたわけではなく、他の層の下部部品 として溶け込んでいく途中です。
- 2層(GraphRAG) — むしろ伸びています。エンタープライズ文書の関係推論需要が明確になり、Microsoft GraphRAG がその需要の象徴になりました。
- 3層(Agentic Retrieval) — 完全に主流になりました。Perplexity、Claude Research、ChatGPT Browse、Claude Code がすべてこの層で動いています。「RAG = 一度検索すること」という昔の公式がここで崩れました。
- 4層(Memory Adaptation、Doc-to-LoRA) — まだ論文段階ですが方向は明確です。2025〜2026年に実務進入が始まりました。
四つの層を一つずつ見ると、「死んだのか」という問い自体があまりにも粗い問いだということがはっきりします。どの層の話かを選んでから、別々に答えないといけない問いです。ここからは、それを一層ずつ私の立場を付けて解いていきます。
M1 を読まずに来られた方のために、一行で復習します。RAG という傘の下には四つの層がある。1層はベクトル類似度で top-k を取る基礎検索。2層は文書間の関係をグラフで捉える検索。3層はモデルが検索を道具として呼び出す agentic 方式。4層は文書をそもそもモデルの重みに溶かす記憶方式。 これが前提です。この前提を共有した上で、私の答えを解いていきます。
3. 1層がなぜ競争力を失ったか — 私が見る三つの理由
1層から行きます。私は最近、「ベクトル DB を作って top-k を取ってプロンプトに貼り付ける」単純構造だけで終わらせる設計は、2026年いま、あまり売れないと見ています。理由を三つに整理できます。
一つ目、コンテキストウィンドウ拡張が1層の需要を食い込んだ。 小規模文書 — 長いマニュアル一冊、論文数編、会議録数十件 — は、いまやプロンプトに丸ごと入れても良くなりました。Gemini や Claude 系の長いコンテキストモデルが手軽に使えるようになったからです。昔は「入れる場所がないから top-k で絞らないといけない」が1層の存在理由の一つでしたが、その部分が消えました。100万トークンのプロンプトが高いとはいえ、「うまく切って top だけ入れる」より「いったん全部入れてモデルに探させる」の方が精度面でよく勝ちます。1層の単独使用の大義名分がここで一つ削れました。
二つ目、一度検索して top-k をプロンプトに乗せる方式は、複雑な質問に弱い。 これが実務で一番見た失敗パターンです。「A プロジェクトがなぜ中断され、その影響は何だったか」のような多段階の質問が入ってきたとき、1層は「A プロジェクト中断」に近い chunk をいくつか取って入れて終わります。次のステップ — 「この中断の影響を追跡するにはどの文書をまた見るべきか」 — をシステムが自分でできません。人がコードを書いて「一回目の検索の後に二回目の検索を回す」をハードコードしない限り、1層の一回きり構造はここで詰まります。
三つ目、幻覚抑制効果が限定的です。 2023〜2024年には「RAG を付けると幻覚が消える」という神話がありました。実務を回してみればわかりますが、これは誇張です。見当違いの chunk が retrieval 結果に上がってくると、モデルはその見当違いの情報を根拠に きれいに間違った答え を作ります。そして retrieval 結果が自分の既存記憶と衝突するとき、モデルが retrieval を無視して既存記憶で答える失敗もよくあります。だから1層単独では幻覚防止装置の役割が弱いです。1層単独設計の最後のセリングポイントだったこの効果が崩れたのが決定的です。
この三つが合わさると、結果は明確です。1層だけを使う設計は、2026年の実戦でほぼ競争力を失いました。 私は新規プロジェクトで1層だけを敷こうとする人に「そこで止まってはダメ」と止めます。それが私の立場です。
ただしここで注意すべきは、1層自体が消えるという話ではないという点です。1層は 他の層の下部部品 として生き続けています。2層の GraphRAG 内部でもエンティティ類似度計算に embedding を使います。3層の agentic retrieval でも検索ツールの内側に1層インデックスが敷かれる場合が多いです。4層でさえ「どの文書を LoRA に溶かすかを選ぶ」事前段階で embedding を使います。1層は土台として残りますが、単独商品としての生命は終わった というのが私の表現です。
この区別をきれいにしないと「RAG 死んだ」論争がずっと滑ります。死んだのは 「1層単独設計」 で、1層技術自体は生きています。
4. 2層がむしろ伸びる理由 — GraphRAG が教えてくれること
1層から2層に上がると、雰囲気がガラッと変わります。ここはむしろ伸びています。
GraphRAG は2024年初めに Microsoft がオープンソースで公開した方式ですが、これを2025〜2026年にエンタープライズが本格的に取り上げていくのが、いまの流れです。なぜ伸びているのかを、私は三つに見ています。
一つ目、エンタープライズ文書は関係推論が本質的に必要です。 会社の内部文書がどんな構造か一度思い浮かべてください。人事ポリシー文書は組織図とつながっていて、組織図はプロジェクト文書とつながっていて、プロジェクト文書は契約書とつながっています。「この部署がなぜこのプロジェクトを中断したか」に答えるには、最低三つの文書を交差させる必要があります。1層では解けません。エンタープライズ顧客がこれを肌で感じるようになった、ということです。だから GraphRAG の需要が急増しています。
二つ目、法律・医療・技術のような関係密度が高いドメインで効果がすぐ出ます。 法律文書は条項同士が参照関係で複雑に絡んでいます。医療文書は症状・診断・薬物の間の関係が核心で、技術文書はバージョン・依存関係・API リファレンスが互いに絡み合います。こういうドメインでは GraphRAG が1層より 質問一回で取りこぼす文書数 を目に見えて減らしてくれます。私はこういう事例を何度か観察しましたが、before 状態では関連条項の半分以下しか捕まえられなかったのが、GraphRAG 導入後には80%以上に上がるケースが実務で繰り返されました。
三つ目、「コーパス全体要約」が新しく可能になりました。 1層は top-k を取る構造なので、「この文書全体を貫くテーマは何か」のような全体要約質問に弱いです。GraphRAG は community detection でグラフをクラスタリングして、全体テーマを捉えられます。これがエンタープライズ側から見て「最初から必要だったけれど作る方法がなかった機能」なので、需要が大きいです。
私の立場を言うと、2層はこれから数年間さらに大きくなります。 特に文書がよく変わらないコーパス(法律、内部マニュアル、長期間溜まった技術文書)では、基本オプションとして定着すると見ています。いま「RAG 死んだのか」を聞く方のうち、この層の動きを見落としている方がかなりいますが、2層は競争力を失うどころか 始まったばかりの市場 です。
非自明なポイントを一つ。GraphRAG を導入したからといって1層を捨てるわけではありません。2層は1層の上に乗る 追加レイヤー です。2層導入が「RAG を捨てて別のことをした」ではなく「RAG をもう一段積み上げた」として読むべきです。ここが混同されると、2層の成長が1層の死として誤解釈されます。
5. 3層は完全なパラダイム転換 — 「一度検索」公式が壊れた地点
3層は、私が「RAG という単語の意味が変わった地点」と呼ぶ層です。
伝統的に RAG と言うと、人々の頭の中に描かれる絵があります。「質問が入る → 検索を一度回す → top-k を取る → プロンプトに貼る → モデルが答える」この順序。検索は 一度 起きて、モデルは検索結果を 受動的に 受け取ります。
3層はこの絵をひっくり返します。
Agentic retrieval では、モデルが検索を 道具のように呼び出します。質問を受けるとモデルが「これを解くには何を検索すべきか」を自ら判断して検索関数を呼びます。一回目の結果を見て「これだけでは足りない」と思えばクエリを変えてまた呼びます。三回、四回呼ぶこともあります。検索の主体が 人が組んだパイプラインからモデルに移動 します。
私がなぜこの層を「パラダイム転換」と呼ぶかというと。この構造では 「RAG = 一度検索」という伝統的な公式が完全に壊れます。検索は n 回起きることができ、検索語はモデルが途中で変え、いつ検索を止めるかもモデルが決めます。これはもはや前の世代 RAG と同じ動作ではありません。形は検索ですが、行動はエージェントです。
どこですでに動いているか。私たちが毎日使っている製品です。
- Perplexity — 質問一つにウェブ検索を何度も回します。検索語の構成、何度回すか、どの結果を見るか、全部モデルが判断します。
- Claude Research — 深く掘る質問に、複数のクエリを繰り返しながらソースを収集します。人が時間をかけて検索するのを代わりにやる方式です。
- ChatGPT Browse / GPT-5 search — 似た構造です。
- Claude Code — ウェブの代わりにファイル検索です。
grep、glob、readのようなローカルツールをモデルが自ら呼び出しながらコードベースを探索します。これが Anthropic が「ベクトル DB なしでもうまく動く」と言う理由です。Claude Code は1層をスキップして3層に直接行った事例です。
この四つの製品を一行でまとめるとこうです。「RAG 死んだ」という主張を生んだ製品たちが、実は RAG の3層で全盛期を謳歌している。表面的には「ベクトル DB を使わないから RAG ではない」と見えるかもしれませんが、レイヤー視点で見るとこれは RAG の別の層です。検索という動作はまだ核心で、モデルがその検索の主体になっただけです。
私の立場は明確です。3層は死んでおらず、死ぬどころか過去2年で一番速く成長した AI パターン です。「RAG 死んだ」を3層まで含めて言うなら、その主張は間違っています。現象を真逆に読んでいます。
非自明なポイント。3層が主流になるにつれて、1層・2層は3層の 道具 として編入されています。Claude Research の中でも、複雑な質問ではベクトルインデックスを道具として呼び出します。Perplexity のウェブインデックスも内部的に巨大な embedding/lexical インデックスです。だから「3層が1層を代替する」ではなく「3層が1層を吸収して自分の道具として使う」が実際の構造です。
6. 4層はまだ論文段階だが方向は明確 — Memory Adaptation
4層に上がると、「これは検索なのか」という問いが揺らぎ始めます。
1層・2層・3層は全部 「文書を毎回入力として渡す」 という前提を共有していました。embedding で取ろうが、グラフで捉えようが、エージェントで呼び出そうが、結局 retrieval 結果がプロンプトに入って一度読まれて消える構造でした。
4層はこの前提を捨てます。
Doc-to-LoRA が代表研究です。名前の通り「文書を LoRA 重みに変換する」アプローチです。会社専用文書を事前学習データとして使って小さな LoRA アダプタを作り、推論時にそのアダプタを乗せるだけで、モデルが該当文書の内容を「記憶」した状態になります。プロンプトに文書を入れなくても答えます。
私が4層について言いたいのは二つです。
一つ目、まだ論文段階の色が濃いです。 Doc-to-LoRA 系研究が2024〜2025年に大量に出て、実務進入は2025年後半から始まりましたが、2026年のいま、この層をプロダクションに安定して乗せた事例はまだ多くありません。学習コスト、更新周期、権限分離のような実務課題がまだ整理されていないからです。私も実験的にしか使っていません。
二つ目、方向は明確です。 特定の条件が合う文書 — ほとんど変わらず、大量に反復参照され、権限分離要求が少ない — で、4層が1〜3層より有利な組み合わせが出てきます。会社専用の API スペック数百ページ、社内コーディングスタイルガイド、固定された製品マニュアルのような資産がその例です。こういう資産を毎クエリにプロンプトに入れるトークンコストが積もると大変な額になります。それを LoRA で一度溶かしておけば、コストと遅延の両方で勝ちます。
私の立場はこうです。4層はまだ主流ではなく、2026年のいま、すべてのチームに勧めません。ただし2027〜2028年頃にはエンタープライズの「当然のオプション」として入ってくると見ています。 この層があることを知っているだけでも、retrieval 設計の選択肢が広がります。「どの文書は retrieval に置いて、どの文書は retrieval の外に抜くか」という配分思考が可能になるからです。
非自明なポイント。4層が広がると、long-context vs RAG の論争が 「どちらか一つ」ではなく「文書ごとに違う配置」 の問題に再構成されます。これが retrieval 論議の最大の変化です。いまも「long context で十分か、RAG が必要か」と二項対立で聞く人が多いですが、2〜3年以内にその問いが「この文書はどの層に配置するか」に変わるはずです。
7. 「RAG は死んだ」と言う人たちは何を見ているのか
ここでちょっと反対側に行ってみます。「RAG は死んだ」を主張する人たちは、何を見てそう言っているのか。私が観察したパターン三つをまとめます。
パターン1 — 1層だけ使って失敗した経験。 一番よくあるケースです。会社の文書をベクトル DB に大量に入れて単純 top-k 検索を回したけれど、精度が期待に届かず、幻覚もそのままで、だから「RAG はいまいち」という判定を下すパターン。この方々が言う RAG は事実上1層を意味します。私もこの意見には半分同意します。1層単独設計は死にました。 ただし、この方々が見落としているのは、それが RAG 全体の判定につながってはいけないという点です。2〜4層が残っています。
パターン2 — 「long context が RAG を代替する」という主張。 これはもう少し理論的な主張です。「100万トークンを超えるコンテキストがあれば全部入れれば良いのに、なぜ検索をするのか」という論理。この論理は一地点では合いますが(小さいコーパスでは合います)、拡張して「だから RAG は必要ない」に行くと間違った二項対立になります。次のセクションでこの主張を本格的に反論します。
パターン3 — 特定のパラダイム製品を見て「これが RAG の死だ」と解釈するケース。 Claude Code がベクトル DB なしにうまく動くのを見て「ほら、RAG は要らない」と言うパターンが一番多いです。これは私が先に言った通り、3層を1層の死として誤解しているんですが、3層も RAG だ という事実を見落とすとこういう解釈が出てきます。検索が何度も起きて、モデルが主体になっただけで、retrieval という本質はそのままです。
この三つのパターンをまとめると結論が出ます。「RAG 死んだ」を主張する人たちが共通して見落としているのは「RAG という言葉は、層によって違うものを指す」という事実です。 1層だけ見て全体を判定したり、long context で置き換えられると錯覚したり、3層を RAG の外に押し出しながら判定したり。この三つのミスのどれかです。
私はこれを悪意ある主張だとは見ていません。用語が混乱しているせいが大きいです。RAG という単語自体が2020年に登場してから中身が拡張され続けてきたのに、人々の頭の中の絵はまだ2022〜2023年バージョン(1層)に留まっていますから。現実が動いた速度に言説が追いついていない状態です。だから、こういう記事を書くのが必要なんです。
8. long context が RAG を代替できるか — 私の答え: いいえ
この質問は一セクション丸ごと割いて答えます。一番よく受ける質問ですから。「Gemini はすでに2M トークンだ。Claude は200K を超えたし。だったら全部入れれば良いのに、なぜ retrieval をするのか」この論理への私の答えは 「いいえ」 です。三つの理由を挙げます。
理由1 — コスト。
長いコンテキストはタダじゃないです。1M トークンのプロンプトを一回回すコストは、ユーザーあたりクエリあたりで計算すると無視できない数字が出ます。10人の社内ツールなら良いですが、10万人が使う製品で毎クエリに1M を入れると計算が合いません。私はこれを実際にプロダクションで回して諦めるチームを何個も見ました。「long context ですべて解決する」というアイデアは、pilot 段階までは魅力的で、scale 段階で壁にぶつかります。
retrieval の経済合理性がここで蘇ります。全体コーパスから関連のある部分だけを取って、10K〜50K トークンだけをモデルに入れるのがコスト面で確実に有利です。「quality-per-dollar」を計算すると retrieval が勝つ地点がかなりあります。
理由2 — Lost in the middle。
M2 で長く扱った主題ですが、ここでまた取り出す必要があります。モデルが長いコンテキストを受けたとき 中間部分の情報を無視する傾向 がまだあります。2024〜2025年にかけてかなり改善されましたが、完全に消えたわけではありません。ベンチマークを見ると、コンテキストの前方と後方の情報はモデルがよく探しますが、中間に埋もれた情報は取りこぼす割合がまだ残っています。
だから100万トークンを丸ごと入れても、モデルが実際に活用するのは一部です。「全部入れても使わないのに、なぜ入れるのか」が retrieval 擁護論理のもう一つの軸になります。関連のある情報を前方に集中させて入れるのがモデル性能をさらに引き上げるという証拠が積み上がり続けています。
理由3 — リアルタイム知識更新が不可能。
これが私が一番大事だと思う理由です。Long context アプローチは「この文書たちをプロンプトに全部入れる」というモデルですが、文書が リアルタイムで変わる 環境ではこのモデルは回りません。
例を挙げます。カスタマーサポート AI を作るとしましょう。FAQ、製品マニュアル、ポリシー文書が毎日更新されます。新製品発売、価格変更、ポリシー更新。Long context で全部入れるとすると、プロンプト自体が毎日変わらないといけません。そうするとプロンプトキャッシングが壊れ、応答遅延が生まれ、コストも毎回また爆発します。逆に retrieval 構造ではインデックスだけ更新すれば良いです。リアルタイム性が必要な環境では retrieval は long context が代替できない役割を果たします。
ウェブ検索はもっと極端です。ウェブは毎秒変わります。Perplexity や Claude Research が毎回ウェブ検索を回す理由がこれです。全体のウェブをモデルに学習させたり long context に入れるのは原理的に不可能です。リアルタイム知識が必要な限り、retrieval は絶対に消えません。
この三つの理由をまとめると、私の結論はこうです。Long context は retrieval を代替せず、retrieval の範囲を狭めます。 昔 retrieval が担当していた領域のうち「小さな静的コーパス」の部分は long context に抜けました。それは認めないといけません。でも「大規模・動的・リアルタイム」という残りの領域は retrieval が引き続き持っていきます。そしてその領域は時間が経つほどさらに大きくなっています。「死ぬどころか、自分の領域を守っている」状態が正確な表現です。
9. 実務者がいまやるべき3つの判断
ここまで来た読者の方は、もう「RAG 死んだのか」という問いに振り回される必要がありません。代わりに、実務者としてやるべき判断があります。三つに整理します。
判断1 — あなたのシステムはいま何層か?
まず診断からです。あなたが運用または設計している retrieval システムが、どの層にあるかを一度正確に打ってみてください。次の質問で測れます。
- ベクトル DB に chunk を入れておいて top-k で一度だけ取ってプロンプトに貼る構造なら → 1層
- エンティティ・関係を抽出してグラフ構造を乗せているなら → 2層
- モデルが検索関数を自ら呼び出して何度も繰り返せるなら → 3層
- 特定の文書を学習でモデルに溶かしてプロンプトから抜いたなら → 4層
ほとんどの場合、一つの層ではなく複数の層の混合のはずです。「主に1層 + 部分的に3層」のような形。大事なのは主力の層がどこかです。主力が1層なら、この記事の次の判断を必ずやってください。
判断2 — 次にどの層に動く余力があるか?
現在の層から一段上げる余力があるかを計算してみます。余力は主に三つの軸で決まります。
- エンジニアリングリソース — 2層・3層を導入するには、設計・実装の工数が1層よりずっと大きいです。
- 運用コスト — 3層は検索呼び出しが重なってトークンコストが増えます。4層は学習コストがかかります。
- ドメイン適合性 — すべてのドメインにすべての層が合うわけではありません。関係密度が低い FAQ 性コーパスに GraphRAG を積むのは過剰です。
余力があれば一層ずつ上げてください。私は1層にいるチームにいきなり4層に行こうとは言いません。通常、1層 → (必要なら)2層 → 3層 が一番現実的な経路です。3層になれば1〜2層が自然に道具として編入されます。
判断3 — 4層まで行く必要があるか?
この問いは多くのチームに「いいえ」が答えです。4層はまだ運用負担が大きく、利益が出る条件が限定的です。ほとんどのチームは 2〜3層混合 が答えです。
4層が必要な条件をもう一度挙げると:
– 反復参照される大型の静的文書があり、
– 文書更新周期が週単位以上に遅く、
– ユーザーごとの権限分離が単純で、
– プロンプトトークンコストが累積すると意味あるほど大きくなるスケール。
この四つの条件が全部合うプロジェクトでなければ、4層はまだ先送りしても構いません。その代わり「4層が存在する」ことを知っているだけで設計の選択肢が広がります。いますぐ持っている武器にはしなくても、これから1〜2年以内に取り出せるカードとして頭に置いておいてください。
10. 2年後、この問いはどう変わっているか — 私の予測
M9 を書きながら、私が最後に置いておきたい言葉はこれです。2028年頃には「RAG は死んだのか」という問い自体が消えるはずです。
なぜなら、その頃になると、この問いがあまりに 曖昧で 使えなくなるからです。2026年のいまもすでに曖昧ですが、2〜3年さらに経つと、人々がこの問いを口に出さなくなります。代わりに、もっと正確な問いに取って代わられるはずです。
私の予測では、こんな問いがその場所を占めるはずです。
- 「うちのチームの文書にはどの層が合うのか?」
- 「この文書は retrieval に置いて、あの文書は LoRA に溶かす方がコスト面で有利か?」
- 「このエージェントの検索呼び出し回数は適正か、過剰か?」
- 「long context と retrieval の境界は、うちのワークロードでどこあたりか?」
全部 層単位の問い です。「RAG 全体が死んだのか生きているのか」のような粗い問いは、こういう細かい問いに場所を譲るはずです。どんな技術用語でも成熟するとそうなります。「データベースは死んだのか」のような問いをいま誰もしませんよね。代わりに「OLTP は何を使う? OLAP は何を使う? ベクトル DB は何を使う?」と聞きます。RAG もそうやって細分化されて定着します。
だから私の最終立場はこうです。「RAG 死んだのか」という問いは2026年基準では半分だけ正しい。そして2028年頃になるとその問い自体が消える。 その時までに実務者ができる最善は、自分のシステムがどの層にいるかを正確に打って、層単位で動く習慣をつけることです。
11. 実務者チェックリスト — いま5分で自分の retrieval システムを診断する
最後にチェックリストを一つ差し上げて終えます。この記事を閉じる前に5分だけ取って、直接答えてみれば、ご自身のシステムの位置がはっきりします。
現在状態診断
– [ ] うちのシステムにベクトル DB や embedding インデックスがあるか?(あれば1層要素保有)
– [ ] 文書間の関係を明示的に抽出してグラフ構造で保存しているか?(あれば2層)
– [ ] モデルが検索関数を自ら呼び出せる構造か?(そうなら3層)
– [ ] 特定のドメイン文書を fine-tuning や LoRA でモデルに溶かしているか?(そうなら4層)
– [ ] 上記4つのうち、主力の層がどこかを一行で書けるか?
失敗パターン自己点検
– [ ] 1層だけを使っているが、複雑な質問で性能が出ない問題が繰り返されているか?(2〜3層に動く時点)
– [ ] 応答に幻覚が混じるのに、RAG が防いでくれると漠然と信じているか?(出典検証装置の追加が必要)
– [ ] embedding モデルがうちの言語・ドメインに合うか、最後にテストしたのはいつか?(6ヶ月以上前なら、また見る時)
– [ ] プロンプトに入れるトークン量が一クエリあたりいくらかわからない状態か?(わからないとコスト爆発リスク)
次のステップ決定
– [ ] 現在の層から次の層に上げる余力が、エンジニアリング・コスト・ドメイン適合性の三軸で合うか?
– [ ] 2〜3層混合がうちの最終目標か、それとも4層まで必要か?
– [ ] long context で代替できる部分があるか? あれば、その部分だけを retrieval から抜けるか?
この三つのブロックに答えを書いてみてください。答えが出ない項目があれば、それが来月勉強したり整理する課題です。RAG に対する感覚は 「死んだのか生きているのか」を判定すること で作られるのではなく、自分のシステムの層構造を正確に打って動く感覚 で作られます。その感覚さえあれば、言説が何と揺さぶってもブレません。
一行で締め: 「RAG は死んだのか」という問いへの私の答えは、死んだのは1層だけで、2〜4層はむしろ拡張中で、2年後にはその問い自体が消えるはずだ、ということです。これからは「うちのシステムは何層か」だけを聞いてください。
毎週月曜日、AIトレンドニュースレター配信中
会員登録すると、毎週月曜日に「今週のAI・バイブコーディング最新情報」をお届けします。
バナー広告なし・本当に役立つ情報だけを厳選するクリーンなAI専門メディアです。
FAQ
Q1. うちの会社はまだ1層なのですが、いますぐ3層にジャンプするのは正しいですか?
ほとんどの場合違います。1層を飛ばして3層に行くと、検索呼び出しの主体だけがモデルに変わって、基底の検索品質はそのままです。むしろ問題がモデルの内側に隠れてデバッグがさらに難しくなります。私はたいていこう勧めます。1層をまず、ちゃんと(embedding モデルのドメイン調整、chunk 戦略のチューニング、evaluation セットの確保)回しておいて、その上に3層を乗せてください。1層が貧弱なまま3層を乗せるのは、泥の上に屋根を載せるのと同じです。
Q2. 「RAG は死んだ」を主張する記事を読むと説得力があるように見えるのですが、私は何を見落としているのでしょうか?
ほぼいつも 層の区別が抜けているから です。その記事が主張する「RAG」が具体的にどの層を指しているかを一度チェックしてみてください。ほとんど1層を指しているはずです。1層への批判は合っていることが多いです。ただしその批判を2〜4層まで拡張すると間違います。記事を読むときに「この人が言う RAG は何層か」を心の中でタグ付けする習慣を付ければ、こういう混乱が早く整理されます。
Q3. 2〜3層混合に行こうとしているのですが、どこから勉強を始めれば良いですか?
3層から手を付けるのをお勧めします。理由は、3層がいま一番よく使われていて学習資料も多く、実際の製品(Perplexity、Claude Research、Claude Code)を直接使いながら感覚がつかめるからです。Anthropic の「How we built Claude Code」のような公式エンジニアリングポストが良い出発点です。3層への感覚がつかめた後に2層(GraphRAG 公式サンプルを回してみる)に進めば、二つの層がどう組み合わさるかが自然に見えます。
- ◀ 前の編: M8. OMX・OMC の実際の位置
- 今の編: M9. 「RAG は死んだのか」 — テイラー本人の答え (19/20)
- ▶ 次の編: M10. シリーズ総仕上げ地図(準備中)
ニュースレターのご案内
毎週月曜日の朝に、AI・LLM・エージェント関連の実務整理を一通お届けしています。RAG のように「死んだのか生きているのか」論争がよく回る主題を、層単位で解いて整理する仕事を続けています。こうした判断地図を腰を据えて積み上げていきたい方は、ぜひ ニュースレター登録(無料・30秒) からどうぞ。
著者: バイブコーディング テイラー(Lovable公式アンバサダー)
運営: テイラーの隠れ家(shuntailor.net)
「RAGは死んだのか?」への答の位置にある編です。前後編のリンクは記事下部のマップ上の現在地ボックスで確認してください。
テイラー本人の答: 1層ローカルvector DB一発retrievalは競争力を失った。2〜4層はむしろ拡張中。long contextがRAGを置換できない理由。
ソースリスト
- テイラー知識百科事典 — 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編は、ウィキの蓄積と公式論文・公式ドキュメントを根拠に整理した体系的学習カリキュラムです。