「RAG は死んだ」 の先 — Kuba Rogut (Turbopuffer) が説く agentic retrieval と 「正しい 100 万トークン」

AI Engineer Europe 2026 (London) / 講演約 11 分

ジェフ・ディーン / Jeff Dean (Kuba Rogut が引用) · 10:00 「兆のトークンが一度に要るのではない。 必要なのは 『正しい 100 万トークン』 だ」

AI Engineer Europe 2026 (London) での講演 「RAG is dead, right??」 (講演約 11 分、 動画公開 2026-06-09、 AI Engineer 公式チャンネル)。 講師は Kuba Rogut (Turbopuffer の deployed engineer)。 Turbopuffer はオブジェクトストレージ上に第一原理から構築された全文検索 + ベクトル検索のデータベース。 「RAG は死んだ」 という X (旧 Twitter) のミームを起点に、 検索が一度きりのベクトル DB 呼び出しから、 エージェントが反復的に文脈を探す agentic retrieval へ移った、 という流れを Cursor / Claude Code の実例で解く。

「RAG は死んだ、 だろ?」 — 2025 年末から 2026 年初頭にかけて X に溢れたこのミームを、 Kuba Rogut は皮肉まじりに掲げる。 だが Google 検索ボリュームを見ると、 2025 年半ばに RAG の検索量はむしろ跳ね上がっている。 「Twitter よ、 これでも見てろ」。 talk の主張は単純 — RAG は死んでいない。 「一度きりのベクトル検索」 という素朴な RAG が、 ツールを使って反復的に探す agentic retrieval へ姿を変えただけ。

RAG とは、 agentic search とは

まず用語を整理する。 多くの人が RAG Retrieval-Augmented Generation。 多くの人は 『コーパスを埋め込み、 ベクトル検索して LLM に渡すだけ』 の単純なベクトル検索だと捉えるが、 Kuba は retrieval を広く取る — ベクトル検索だけでなく、 全文検索 (BM25)、 grep / glob / 正規表現、 各種フィルタを含む。 augmented generation は結果を LLM に渡す部分 を 「コーパスを埋め込んでベクトル検索し、 LLM に渡すだけ」 の単純なベクトル検索だと思っている。 Turbopuffer の捉え方では、 retrieval (検索) はベクトル検索だけではない — 全文検索 (BM25)、 grep / glob、 正規表現、 基本的なフィルタまで含む。 augmented generation はそれを LLM に渡す部分。

agentic search エージェント検索。 多くの人は Claude Code / Codex のような 『ファイルシステムを grep する』 挙動を指して使うが、 Kuba の定義はより広い — エージェントに一連のツールを与え、 段階的・反復的に文脈を見つけて推論させること。 ファイルを読み、 必要なものが見つかったか判断し、 満足するまで探し続ける、 というループ も同様。 多くの人は Claude Code / Codex のような 「ファイルシステムを grep する」 挙動を指して使う。 だが本質は、 エージェントに一連のツールを与え、 段階的・反復的に文脈を見つけて推論させること。 Claude Code ならファイルを読み、 必要なものが見つかったか判断し、 見つからなければまた探す、 を満足するまで繰り返す。

Cursor の事例 — Merkle ツリーと意味検索の効き目

Turbopuffer の顧客で agentic search を巧くやっている例として、 Kuba は Cursor を挙げる (Turbopuffer の最初期顧客の一社)。 Cursor は新しいコードベースを開くとコードを chunk・parse・embed して意味検索可能にする。 巧いのは Merkle ツリー 暗号学的ハッシュ木。 Cursor はチームが開く複数コードベースの類似度を Merkle ツリーで計算し、 十分似ていれば既存データをコピーして、 変更されたファイルだけ再 chunk・再 embed する。 100 人のチームが同じコードベースを開くたびに全再構築するコストを避ける。 Turbopuffer 上で安全に行う でチーム内の重複コードベースを検出する点。 100 人のチームはたいてい同じ 1〜数個のコードベースを開く。 毎回 re-chunk・re-embed・再アップロードするのは高い。 そこで Merkle ツリー (暗号ハッシュ木) でコードベースの類似度を計算し、 十分似ていればデータをコピーして変更ファイルだけ更新する。 Turbopuffer がこれを安全に支える。

効き目も Cursor のブログから引く (Kuba が紹介する社内ベンチの数字)。 意味検索を与えると、 モデル横断で平均 12.5〜13.5% の回答精度向上、 Composer モデル (Composer 2 以前) では約 24% の向上。 オンライン A/B テストでは大規模コードベースで約 2.6% のコード保持率向上、 不満足なリクエストが約 2.2% 減少。 数字が小さく見えるのは、 意味検索が全クエリで発火するわけではないため (発火しないクエリも分母に入る)。

Claude Code は意味検索を使わない — 「キャッシュ計算」 という捉え方

対照的に Claude Code はベクトル検索を使わない。 Boris Cherny (Claude Code の生みの親) によれば、 初期の Claude Code は RAG とローカルのベクトル DB を試したが、 うまくいかなかった。 Turbopuffer が内面化した重要な見方は、 埋め込みと意味検索は一種の キャッシュ計算 (cache compute) 埋め込み・意味検索を 『前もって計算してキャッシュしておく投資』 と捉える見方。 Claude Code 流の per-session 探索 (毎回 grep→read→判断→反復) は、 同じ理解を 10 人 × 10 日 × 10 エージェントが毎回ゼロから再計算してトークンを浪費する。 Cursor 流は前払いで一度 index 化し、 実行時は軽量ツールで引くだけ。 上流コストは一度きりで、 以後はトークン・時間・コストを節約する だということ。 Claude Code 流の探索は per-session — 「メタデータフィルタの仕組みは?」 と問うたびに grep・read・評価・反復でファイルを探し直す。 10 エージェント × 10 日 × 10 開発者が同じ問いを繰り返せば、 毎回同じ手順を踏み直してトークンを食う (1 サブステップで 6,000 トークンでも積み上がる)。

Cursor 流は逆で、 前払いの index 化コストを一度払えば、 実行時は軽量ツールで 「メタデータはどうフィルタされる?」 と引くだけ。 結果を即得て、 トークン・時間・コストを節約する。 Turbopuffer 社内でも、 Claude Code の重いユーザーだった面々が、 速さ (Composer 2 + 意味理解) を理由に Cursor へ乗り換え始めた、 と明かす。

RAG から agentic retrieval へ — 「正しい 100 万」

洗練された顧客はもはや 「一度ベクトル検索して文脈に放り込む」 素朴な RAG をやらない。 エージェントが何度も呼び出し、 複数ステップで推論し、 必要に応じて意味検索や全文検索を使い、 そのユースケースに必要なものだけ取ってくる。 retrieval はもう一度きりの VectorDB 呼び出しではなく、 反復的になっている。 Kuba は Google の ステージド検索 (staged retrieval) 巨大なコンテキスト窓があっても、 兆トークンを一度に渡すのではなく、 軽量な仕組みで段階的に正しい 100 万 (あるいは 10 万・1 万) トークンへ絞り込む考え方。 Jeff Dean の 『兆を一度にではなく、 正しい 100 万を』 という言に Kuba が共感を寄せる。 Turbopuffer の顧客は兆トークンを格納するが、 肝心なのは 『正しい部分集合』 を取り出すこと に言及する Jeff Dean の言を引く — コンテキスト窓が兆トークンに達しても、 必要なのは兆を一度にではなく、 軽量な仕組みで 「正しい 100 万」 に絞り込むこと。 Turbopuffer の顧客は兆トークンを格納するが、 肝心なのは 「正しい 10 万・1 万・100 万」 を取り出して窓に渡すことだ、 と締める。

編集所見

この talk の値打ちは、 「RAG は死んだ」 という煽りミームを 「retrieval が一度きりの呼び出しから反復的な agentic retrieval へ進化した」 という地味な技術的事実に置き換えたこと。 Kuba の枠組みで効いているのは 「埋め込み = キャッシュ計算」 という捉え方 — Claude Code の per-session 探索 (毎回ゼロから grep) と Cursor の前払い index 化を、 トークンの会計で対比する。 ベクトル DB 屋 (Turbopuffer) のポジショントークではあるが、 Claude Code が意味検索を使わない事実 (Boris Cherny) も正直に併置し、 「どちらが正義か」 ではなく 「キャッシュを前払いするか、 実行時に都度払うか」 のトレードオフとして提示する点が誠実。 harness 論 や Claude Code 系の記事と並べると、 「文脈をどう運ぶか」 という 2026 年の中心課題の検索側からの一枚になる。

着眼点

検索ボリュームという反証

「RAG は死んだ」 という言説に対し、 Kuba は X のミーム量ではなく Google 検索ボリュームを当てる — 2025 年半ばに RAG の検索量は跳ね上がっている。 言説の体感 (SNS) と実需の指標 (検索量) を対置して通説を崩す手つきは、 一次データで煽りを冷ます好例になっている。

「キャッシュ計算」 がツール選択を分ける

Claude Code (per-session 探索) と Cursor (前払い index 化) のどちらが速いかは、 「同じ理解を何度引き出すか」 で決まる。 同じ問いを多人数・多日にわたり繰り返す現場では、 一度の index 化が効き、 一回限りのタスクでは per-session 探索で十分。 Turbopuffer 社内で Claude Code から Cursor へ乗り換える人が出た、 という現場証言が、 この会計を裏づける。

動画の構成

  • (00:00) 自己紹介 (Kuba、 Turbopuffer の deployed engineer)、 Turbopuffer とは
  • (00:46) 「RAG は死んだ」 ミーム vs Google 検索ボリュームの逆説
  • (01:31) RAG の定義 — retrieval はベクトル検索だけでなく全文検索・grep・regex・フィルタ
  • (02:17) agentic search の定義 — ツールで段階的・反復的に探して推論する
  • (03:02) Cursor の事例 — コードベースの index 化、 Merkle ツリーでの重複検出
  • (04:41) Cursor の意味検索の効果 — 回答精度 +12.5〜13.5% / Composer +24% / A/B の保持率・不満足
  • (06:08) Claude Code はベクトル検索を使わない (Boris Cherny)
  • (06:29) 埋め込み = キャッシュ計算、 per-session 探索 vs 前払い index 化のトレース比較
  • (08:43) RAG から agentic retrieval へ — 反復的で、 必要なものだけ取る
  • (10:00) Jeff Dean 「正しい 100 万トークン」 / ステージド検索

関連リンク

KR

クバ・ロガット

Kuba Rogut

Turbopuffer (検索 / retrieval) / 講演では deployed engineer と自己紹介

用語集

RAG (Retrieval-Augmented Generation)
検索で取った文脈を LLM に渡して生成させる手法。 多くの人は 「ベクトル検索 → LLM」 の単純形を指すが、 Kuba は retrieval を広く取り、 全文検索 (BM25)・grep / glob・正規表現・フィルタを含める。 「RAG は死んだ」 のは素朴な一度きりの形であって、 retrieval 自体ではない。
agentic search / agentic retrieval
エージェントに一連のツールを与え、 段階的・反復的に文脈を見つけて推論させる検索。 一度きりの VectorDB 呼び出しではなく、 必要に応じて意味検索・全文検索を繰り返し、 そのタスクに要るものだけ取る。 Claude Code / Cursor の探索がその例。
キャッシュ計算 (cache compute)
埋め込み・意味検索を 「前もって計算してキャッシュしておく投資」 と捉える見方。 Claude Code 流の per-session 探索は同じ理解を毎回ゼロから再計算してトークンを浪費し、 Cursor 流は前払いで index 化して実行時は軽量に引く。 上流コストは一度きり。
Merkle ツリー
暗号学的ハッシュ木。 Cursor はチームが開く複数コードベースの類似度を Merkle ツリーで計算し、 十分似ていれば既存データをコピーして変更ファイルだけ再 chunk・再 embed する。 全再構築のコストを避ける仕組みで、 Turbopuffer 上で安全に行う。
ステージド検索 / 「正しい 100 万」
巨大なコンテキスト窓があっても、 兆トークンを一度に渡すのではなく段階的に 「正しい 100 万 (10 万・1 万) トークン」 へ絞る考え方。 Jeff Dean の 「兆を一度にではなく、 正しい 100 万を」 に Kuba が共感する。 Turbopuffer の顧客は兆トークンを格納するが、 肝心なのは正しい部分集合の取り出し。
comment is stripped from the HTML output. */}