Shuichiro Ogawa
English

ノート · updated 2026-09-27

RAG は使われなくなったのか、何が置き換わり、何が残ったか

「RAG はもう使われなくなった」という噂は、利用の実態としては当たっていない。企業の RAG 採用率は 2023 年の 31% から 2024 年に 51% へ伸び（Menlo、600 名）、2025 年の調査でも prompt 設計に次ぐ 2 位にある。

目次（11）
  1. 噂はコードベースから出た
  2. コードでは索引が負ける
  3. 死亡記事の書き手も、検索を回している
  4. T1v ベンダー一次：RAG は畳まれず、作り替えられている
  5. T2 公的機関と調査：採用の数字と、標準が見ているもの
  6. long context で足りるのはどこまでか
  7. context engineering は RAG を部品に含む
  8. 2026 年の時点で採れる作法
  9. Jev は検索しないが、検索の判定段に入る
  10. 直近の主要アップデート（時系列）
  11. 信頼度の読み方

噂はコードベースから出た

「RAG is dead」という言い回しは、2025 年に何度も繰り返された。 出どころをたどると、ほとんどがコーディングエージェントの話に行き着く。

2025-05-27、Cline の公式ブログが「Why Cline Doesn’t Index Your Codebase」を出した。 同じ週に LlamaIndex が「RAG is dead, long live agentic retrieval」という題の記事を出している。 2025-09-11 には Jason Liu が、Cline の AI 責任者 Nik Pash の講演をもとに「Why I Stopped Using RAG for Coding Agents (And You Should Too)」を書いた。 2025-10-01 には Fintool 創業者の Nicolas Bustamante が「The RAG Obituary: Killed by Agents, Buried by Context Windows」を出した。 Anthropic は 2026-05-14 の公式ブログで、Claude Code が埋め込みの索引ではなく grep で探す理由を説明している。

どれも、コードベースという特定の情報源について書かれている。 噂が本当かどうかは、コードで起きたことがほかの情報源にも当てはまるかどうかで決まる。

コードでは索引が負ける

Anthropic の説明は、索引が古くなることに集中している。 「embedding pipelines can’t keep up with active engineering teams. By the time a developer queries the index, it reflects the codebase as it previously existed weeks, days, or even hours before」。 何千人がコミットし続けるコードベースでは、埋め込みを作り直すより先にコードが変わってしまう。 Claude Code はかわりに「traverses the file system, reads files, uses grep to find exactly what it needs」。 その結果、「There’s no embedding pipeline or centralized index to maintain」。

Cline は理由を 3 つ挙げた。 チャンク化するとコードの論理が切れる（「you’re literally tearing apart its logic」）。 索引は定義上ある時点の写しで、コードはそこからずれていく（「An index, by definition, is a snapshot frozen in time」）。 そして埋め込みを外部に置くことは、競争力の源であるコードを外に出すことになる。

Claude Code の作者 Boris Cherny へのインタビューでは、聞き手の Gergely Orosz が経緯をこうまとめている。 ローカルの vector DB を含む複数の方式を試し、どれも古い索引と権限の複雑さという欠点があった。 「Plain glob and grep, driven by the model, beat everything」。 これは本人の逐語ではなく、聞き手の要約である。

コードで grep が効く理由は、情報源の性質にある。 関数名や型名は一字一句そのまま検索でき、参照を辿れば関連箇所に着く。 意味の近さで探す必要が小さく、しかも中身が数時間単位で変わる。 社内規程や論文や判例のように、言い回しが揺れ、中身がゆっくり変わる情報源には、この条件はそのままでは当てはまらない。

死亡記事の書き手も、検索を回している

Bustamante の記事は、題だけ読むと RAG の終わりを宣言している。 本文の結論は「In hindsight, RAG will look like training wheels. Useful, necessary, but temporary.」で、これは予測である。 同じ記事で、Fintool は現在もチャンク化と埋め込みと BM25 を組み合わせたハイブリッド検索を運用していると書かれている。 agentic search への全面的な移行は、著者が見込む将来として語られているだけだった。

反対側からも声が出ている。 Hamel Husain は「I’m tired of hearing ‘RAG is dead.’」と書き、Ben Clavié と 7 回の公開シリーズを組んだ（2025-07-12）。 Chroma の Jeff Huber は、RAG の生死より先に語そのものを退けた。 「We never use the term rag. I hate the term rag.」。 かわりに Huber が使う語は context engineering で、定義は「the job of figuring out what should be in the context window for any given LLM generation step」である。

LlamaIndex の記事も、本文の見出しは「Naive RAG is dead, agentic retrieval is the future」だった。 死んだとされているのは素朴な構成で、検索そのものではない。 本文は「now agentic strategies are table stakes」と続く。

T1v ベンダー一次：RAG は畳まれず、作り替えられている

主要な提供者は、2025 年を通じて RAG の製品を増やしている。

Google は 2025-11-06、Gemini API に File Search を組み込んだ。 公式の説明は「a fully managed RAG system built directly into the Gemini API」である。 チャンク化、埋め込み、文脈への注入を自動で行い、引用を返す。 課金は初回の索引づけの埋め込みだけで 100 万トークンあたり 0.15 ドル、保存とクエリ時の埋め込みは無料とされる。

OpenAI の File Search は Responses API のホスト型ツールで、「semantic and keyword search」を併用する。 Deep research（2025-02-02）は、インターネット上で多段の調査を行うエージェントとして出た。

Microsoft は Azure AI Search に agentic retrieval を加えた。 定義は「a multi-query pipeline designed for complex questions」である。 複合質問をサブクエリに分解し、並列に実行し、それぞれを semantic rerank する。 課金の単位はクエリからトークンに変わった。 ただし一律に正式提供ではなく、抽出的な最小構成は 2026-04-01 の REST API で GA、LLM によるクエリ計画と回答の合成はプレビューのままである。

グラフを使う検索も製品に入った。 AWS は Bedrock Knowledge Bases の GraphRAG を 2025-03-07 に GA とし、Microsoft Research は LazyGraphRAG を 2025-06 に自社の研究基盤と Azure Local へ統合したと追記している。

Anthropic は検索の周辺を部品として出している。 Citations API は応答中の主張を文書の文字範囲やページに結びつけ、web search tool は 1,000 検索 10 ドルで引用つきの検索を行う。 Google の check grounding は、回答文が与えた事実でどこまで支持されるかを判定する API である。

この並びから見えるのは、RAG の廃止ではなく、検索の組み立てをベンダー側が引き取る動きである。 チャンク化と埋め込みは managed 製品の中に隠れ、表に出る設計の単位は、何度検索するか、何を引用として返すか、に移った。

T2 公的機関と調査：採用の数字と、標準が見ているもの

採用率の推移を方法論つきで示している資料は、Menlo Ventures の調査しか見つからなかった。 2024 年版（米国の IT 意思決定者 600 名、2024-09-24〜10-08）は「RAG … now dominates at 51% adoption, a dramatic rise from 31% last year」と書く。 2025 年版（495 名、2025-11-07〜25）は割合を出していないが、カスタマイズ手法の順位は prompt 設計が首位、RAG が次点である。 同じ 2025 年版は、真にエージェントと呼べる導入は企業で 16%、スタートアップで 27% にとどまるとしている。 Menlo は投資先を持つ VC なので、数字は出典元の主張として読む。

ほかの調査は、RAG について何も言っていない。 LangChain の調査（1,340 件、2025-11〜12）はエージェントの本番導入を 57.3%（前年 51%）とするが、RAG 単独の数字はない。 a16z の CIO 調査（2025-06）の本文には、RAG も retrieval も context engineering も出てこない。 Gartner の Hype Cycle で RAG がどこに置かれたかは、原文が 403 で読めず、第三者の要約しかなかったので本ノートでは扱わない。

標準の側は、RAG を攻撃面として扱い始めている。 OWASP は 2025 年版 Top 10 for LLM に「LLM08:2025 Vector and Embedding Weaknesses」を新設した。 複数の利用者が同じ vector DB を共有する環境での「context leakage between users or queries」を挙げ、「permission-aware vector and embedding stores」を緩和策に置く。 NIST の NCCoE は 2025-07-31、自組織で RAG のチャットボットを作った記録（IR 8579 初期公開草案）を出し、プロンプト注入、ハルシネーション、データ露出、不正アクセスへの対処を書いた。 産総研の生成 AI 品質マネジメントガイドライン（2025-05-26）は、RAG の構成要素を品質管理の対象として明示している。

これらの文書はどれも、RAG が広く配備されていることを前提に、その弱点を埋める側に回っている。 廃れた構成として扱っているものは見当たらなかった。

long context で足りるのはどこまでか

文脈窓が 100 万トークンに届けば検索は要らない、という見方がある。 Anthropic 自身が、条件つきでそれを認めている。 「If your knowledge base is smaller than 200,000 tokens (about 500 pages of material), you can just include the entire knowledge base in the prompt」。 この規模なら prompt caching と組み合わせて全体を入れればよい、というのが 2024-09 の Contextual Retrieval の記事の推奨だった。

ところが 1 年後、同じ Anthropic が逆向きの事実を前提に置いた。 「as the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases」。 入るかどうかと、読めるかどうかは別の問題である。

Chroma の Context Rot（2025-07-14）は 18 のモデルでこれを測った。 結論は「model performance degrades as input length increases, often in surprising and non-uniform ways」である。 探す情報と質問の言い回しが似ていないほど、入力が長くなったときの劣化が大きかった。 この結果からは、言い換えの入る問いは長い文脈に丸ごと入れても解決しない、と読める。

Drew Breunig は、長い文脈の失敗を 4 つに分けた（2025-06-22）。 誤りが文脈に入って繰り返し参照される poisoning、文脈に引きずられて学習した知識を使わなくなる distraction、余計な内容が低品質な応答を招く confusion、新しい情報と既存の情報がぶつかる clash である。 Breunig は、プロンプトを複数ターンに分けて与えると平均 39% 落ちたという研究（arXiv:2505.06120）を引いている。

Pinecone はコストの面から、長い文脈は 1 回ごとに高く遅くなると書く。 ただし Pinecone は vector DB の販売元で、定量の比較は示していない。

long context は、小さく安定した知識なら検索の代わりになる。 大きい知識や、言い回しが揺れる問いでは、何を入れるかを選ぶ仕事が残る。

context engineering は RAG を部品に含む

2025 年 6 月、prompt engineering にかわる語として context engineering が広まった。 Tobi Lütke は「the art of providing all the context for the task to be plausibly solvable by the LLM」と書き、Karpathy は「the delicate art and science of filling the context window with just the right information for the next step」と書いた。 語の系譜は 生成AI活用エンジニアリングの系譜とデザイン評価 にまとめてある。

この語の中で、RAG は消えたのではなく、下位の一手になった。 Lance Martin（LangChain）は文脈の操作を write、select、compress、isolate の 4 つに分け、検索は select の一つとして置かれる。 Anthropic は目標を「find the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome」と書き、そのための手として just-in-time の読み込みを挙げる。 エージェントはファイルパスや保存したクエリのような軽い識別子を持ち、必要になった時点で道具を使って中身を読み込む。

同じ記事は、Claude Code をハイブリッドの例として挙げている。 「CLAUDE.md files are naively dropped into context up front, while primitives like glob and grep allow it to navigate its environment and retrieve files just-in-time」。 常に要る少量は先に入れ、残りは実行時に探す。 grep で探すことも、選んで文脈に入れるという意味では検索である。 変わったのは、検索を 1 回だけ事前に行う構成から、エージェントが判断しながら何度も呼ぶ構成への移行だった。

2026 年の時点で採れる作法

一次資料が条件つきで示しているものだけを並べる。

  • 知識が約 20 万トークン未満で安定しているなら、検索しない：全体を入れて prompt caching を使う（Anthropic）。ただし長くなるほど想起は落ちるので、上限いっぱいまで詰めるのは避ける。
  • 大きい文書群には、チャンクに文脈を足し、BM25 と併用し、再順位づけする：Anthropic の自社評価では、上位 20 件の検索失敗率が 5.7% から、文脈つき埋め込みで 3.7%、BM25 の併用で 2.9%、再順位づけで 1.9% に下がった（指標は 1 − recall@20、標本規模は非開示）。初期検索で 150 件を取り、再順位づけで 20 件に絞り、モデルに渡すのは 5 件や 10 件より 20 件がよいとされる。
  • 速く変わり、識別子で引ける情報源は、エージェントに探させる：コードベースが典型である。実行時の探索は事前に取っておくより遅いので、Anthropic は常に要るものを先に入れるハイブリッドを勧めている。
  • 複合質問は分解してから検索する：Azure の agentic retrieval はこれを製品にした。課金がトークン単位になるので、1 問あたりのコストは質問の複雑さで動く。
  • 答えを出典に結びつけて返す：Citations API、search results block、check grounding のように、主張と根拠の対応を出力に含め、あとから検査できる形にする。
  • 検索結果を信用しない：vector DB は利用者ごとに権限で分け、知識ソースに注入や汚染がないか検証する（OWASP LLM08）。

Jev は検索しないが、検索の判定段に入る

TypeSafe AI の Jev（TypeSafe AI の Jev は何を保証し、何を保証しないか）は、テキストを生成せず、型づけられた判断と確率だけを返すモデルである。 自分では何も検索しない。 それでも公式 cookbook には、RAG の部品として使う例が 4 本ある。

1 本目は再順位づけである。 判例コーパス CLERC の 40 クエリで、BM25 が 3,565 件から 30 件に絞った候補を、Noul の質問「Could this candidate passage be from that cited precedent?」で並べ直した。 正解が 1 位に来た割合は 5% から 18%、上位 10 件に入った割合は 38% から 62% に上がり、1,200 回の呼び出しで 0.0645 ドルだった（jev-1.12）。 比較の相手は BM25 の並び順だけで、埋め込み検索や専用の再順位づけモデルとは比べていない。 候補の 30 件には 40 クエリすべてで正解が入っており、公式自身が「Re-ranking only ever sees the passages that make the shortlist」と限界を書いている。

2 本目は passage の選別で、検索と生成のあいだに 4 つの質問を置く。 関連しているか、使える証拠を含むか、質問の前提と矛盾するか、回答系を操作しようとしているか。 閾値で除外、証拠、矛盾の 3 つに振り分け、矛盾する証拠は別のブロックとして生成モデルに渡す。 標本は Supabase の認証ドキュメント 81 件と 6 クエリで、注入の検出について公式は「Nothing here is a security boundary」と明記している。

3 本目は引用の検査である。 引用文を文字列一致で探し、見つからなければ捏造、見つかれば Choice で支持、矛盾、無関係のどれかを判定し、確信度 0.8 未満を人の確認に回す。 4 本目は行単位の意味検索で、文書の各行に ID を振って Choice で順位をつけ、同時に Noul で答えがそもそも文書にあるかを判定する。 Choice の確率は合計 1 なので、答えがなくても 1 位は出る。その穴を Noul で埋める設計になっている。

この 4 本に共通するのは、検索の外側にある判断を Jev に渡していることである。 候補を集めるのは BM25 や埋め込みで、Jev はその結果が関連しているか、証拠になるか、信用してよいかを判定する。 判断が関数呼び出しになったとき、デザインの何が動くか は、基準への当てはめは部品として降りていき、基準そのものを書く仕事が残ると論じた。 RAG の判定段はその当てはめの典型で、関連性の質問文が基準にあたる。 再順位づけの 5% から 18% は、質問文を 1 本だけ書いた場合の結果で、公式も実際の用途では質問を複数置くと書いている。

逆向きの依存もある。 Jev 自身が長い文脈で精度を落とす。 状態に入れられるのは公式ドキュメント上で 3 万 2,000 トークン前後で（64k と書くページもあり、公式内で食い違っている）、独立実装は「Jev suffers from context rot」と報告し、公式は「Include only the context relevant to the current questions」と指示している（Jev をどう使うか、どこで使わないか）。 Jev を使うには、その前段で何を渡すかを選ぶ必要がある。 つまり Jev は検索を不要にするのではなく、検索があることを前提に置いている。

typia のメンテナは、数百の関数からターンごとに要るものを選ぶ用途で、埋め込み検索ではなく Jev を採った（Jev をどう使うか、どこで使わないか）。 候補ごとに独立した Noul を並べ、多すぎればグループを選んでから個別を選ぶ 2 段にしている。 候補の集合が小さく固定されているなら、検索を飛ばして判定だけで選べる、という例である。

直近の主要アップデート（時系列）

  • 2024-09-19 Anthropic Contextual Retrieval。20 万トークン未満なら全体を入れる推奨
  • 2024-11-18 OWASP Top 10 for LLM 2025 版。LLM08 Vector and Embedding Weaknesses を新設
  • 2024-11-20 Menlo 調査。RAG 採用 51%（前年 31%）
  • 2025-01 Anthropic Citations API
  • 2025-02-02 OpenAI Deep research
  • 2025-03-07 AWS Bedrock Knowledge Bases GraphRAG GA
  • 2025-05-07 Anthropic web search tool（2025-09-10 に web fetch 追加）
  • 2025-05-26 産総研 生成 AI 品質マネジメントガイドライン
  • 2025-05-27 Cline「Why Cline Doesn’t Index Your Codebase」
  • 2025-05-29 LlamaIndex「RAG is dead, long live agentic retrieval」
  • 2025-06-19〜27 Lütke、Karpathy、Martin、Willison、Breunig が context engineering を論じる
  • 2025-07-12 Hamel Husain と Ben Clavié「Stop Saying RAG Is Dead」
  • 2025-07-14 Chroma Context Rot（18 モデル）
  • 2025-07-31 NIST NCCoE IR 8579 初期公開草案
  • 2025-09-11 Jason Liu「Why I Stopped Using RAG for Coding Agents」
  • 2025-09-29 Anthropic「Effective context engineering for AI agents」
  • 2025-10-01 Bustamante「The RAG Obituary」
  • 2025-11-06 Google Gemini API File Search
  • 2025-12-09 Menlo 2025 年版。カスタマイズ手法は prompt 設計が首位、RAG が次点
  • 2026-03-04 Pragmatic Engineer の Boris Cherny インタビュー
  • 2026-04-01 Azure AI Search agentic retrieval の最小構成が GA
  • 2026-05-14 Anthropic「How Claude Code works in large codebases」

信頼度の読み方

  • T1v ベンダー一次：Anthropic、Google、OpenAI、Microsoft、AWS、LlamaIndex、Pinecone、Cohere、TypeSafe の公式資料。機能、価格、設計理由の一次権威として扱った。Contextual Retrieval の数字は自社評価で、標本規模は開示されていない。LlamaIndex の題の断定、Cohere の「state-of-the-art」、Pinecone の「RAG は廃れていない」という結論は、コーパス側で販促として分けた。
  • T2 公的機関と調査：OWASP、NIST、産総研は RAG を攻撃面と品質管理の対象として扱う一次資料である。採用率は Menlo の 1 系列しかなく、発行者が投資先を持つ VC である点を割り引く必要がある。Gartner と McKinsey は原文に到達できず、検索要約に出た「McKinsey が RAG 51% と報告」は Menlo の数字の誤帰属と判断して採っていない。
  • T3 個人の私見：Karpathy、Willison、Breunig、Martin、Huber、Husain、Bustamante、Liu は権威を確認できたが、いずれも私見である。Huber と Bustamante は検索インフラや検索製品の当事者でもある。Cherny の発言は X の本体に到達できず、インタビューの聞き手による要約だけを使った。

一致しているのは、素朴な 1 回きりの検索が退き、検索がエージェントの道具になったという方向である。 割れているのは、それを「RAG の死」と呼ぶか「RAG の進化」と呼ぶかで、これは主に語の定義の違いである。

関連ノート: TypeSafe AI の Jev は何を保証し、何を保証しないか、Jev をどう使うか、どこで使わないか、判断が関数呼び出しになったとき、デザインの何が動くか、生成AI活用エンジニアリングの系譜とデザイン評価、エージェンティックコーディング：オーケストレーションパターンの現在地（2026）、LLM-as-a-Judge の最新潮流：中核研究53件の文献地図と創造性評価の独立章。

未検証事項

  • [要一次検証: 取得不能 x.com 402、xcancel 451、threadreaderapp 未掲載] Boris Cherny の X 投稿「Early versions of Claude Code used RAG + a local vector db」の逐語と日付。本文ではインタビューの聞き手による要約だけを使った。
  • [要一次検証: 取得不能 gartner.com の press release と記事ページが 403、原文書は購読限定] Gartner Hype Cycle for AI 2025 での RAG、AI agents、vector DB の位置。
  • [要一次検証: 取得不能 mckinsey.com 本体と PDF が 2 回タイムアウト] McKinsey State of AI 2025 の RAG に関する記述。
  • [要一次検証: 本文未到達 p.21〜47 未読] NIST AI 600-1 の §3 後半に retrieval や RAG の語があるか。p.1〜20 にはない。
  • [要一次検証: 本文未到達 WebFetch 403、検索スニペットのみ] OpenAI Deep research の発表ページ本文。
  • [要一次検証: 本文未到達 取得結果が要約中心] Pinecone の記事の「lost in the middle」の逐語。
  • [要一次検証: 未試行 一次論文の照合は予算外] Breunig が引く「平均 39% 低下」の元論文（arXiv:2505.06120）。本文では Breunig の引用として帰属させた。
  • [要確認: 記載なし 各ページに日付がない] TypeSafe の cookbook 4 本、OpenAI File Search、Anthropic search results block の公開日。
  • [要確認: 未試行 時間予算] UK AISI、Stanford HAI AI Index 本編、日本 AISI の評価観点ガイドでの RAG の扱い。

参照文献

すべて 2026-09-27 にアクセス。

ベンダー一次情報（T1v）

公的機関と調査（T2）

個人の私見（T3）

書いた人：小川 修一郎（Design Researcher / Consultant） 経歴を見る →