RAG より Agentic Search の方がよいのか？

本記事の執筆と調査には Anthropic の Claude とそのリサーチ機能を使用しています。また、公開前の数値と出典の照合には OpenAI の GPT-6 Astra を使用し、その指摘を受けて本文と図を修正しています。

---

1. はじめに

先日、RAG の種類（テキスト RAG、GraphRAG、ハイブリッド RAG など）を整理する記事を書きました。
[ローカルLLMで自社専用の「AI税務担当」を作る（続編）─ RAG深掘り]

書いている途中から気になっていたのですが、「そもそも RAG より Agentic Search の方がよい」という話をあちこちで見かけます。ここ一年ほどは「RAG は死んだ」という言い方もよく目にするようになりました。実際、Claude Code はコードベースをベクトル DB でインデックス化していませんし、Deep Research 系の機能は一度の検索で終わらせず、結果を見ながら何度も検索を投げています。ただしこの二つは別の話です。前者は「事前に索引を作らない」、後者は「実行時に検索を繰り返す」で、Deep Research が叩く検索エンジンの側は当然ながら索引を持っています。

一方で、RAG 側も止まっているわけではありません。Anthropic は 2024 年に Contextual Retrieval という改良を出していますし、ハイブリッド検索（BM25 とベクトルの併用）はエンタープライズでは事実上の標準になりつつあります。

この記事では、この論争について、

• そもそも何と何を比べているのか（用語の整理）
• 「Agentic Search の方がよい」という主張はどこから来たのか
• 定量データはどこまで出ているのか
• その代償（コストとレイテンシ）はどれくらいか
• ローカル LLM で成立するのか

を、一次情報と二次情報を区別しながら整理してみます。RAG の種類そのものは前の記事で扱ったので、ここでは深入りしません。この記事だけで読めるようにしてあります。

数値は、可能な範囲で出典と測定条件（モデル、データセット、日付）をセットで示します。断定できる事実と、推定・意見・宣伝的な主張は分けて書くようにしました。調査時点は 2026 年 9 月です。

2. まず用語を整理する

この議論がややこしいのは、用語が業界で揺れているからです。「Agentic RAG」「Agentic Search」「Agentic Retrieval」「Tool-based retrieval」あたりはほぼ同義で使われることもあれば、微妙に違う意味で使われることもあります。

まず、それぞれが何を指しているかを表にしてみます。

用語	何をするか	検索の経路
ナイーブ RAG	文書をチャンク分割して埋め込み、質問と近い top-k を取ってプロンプトに連結	設計時に固定
ハイブリッド検索	BM25（語彙一致）とベクトル（意味一致）を併用し、リランカーで並べ替え	設計時に固定
Contextual Retrieval	チャンクに文書全体の文脈を付けてから埋め込み・索引化	設計時に固定
GraphRAG	知識グラフに関係を符号化してから取得	設計時に固定
Adaptive RAG	クエリの複雑度を分類器で判定し、検索なし／単段／多段に振り分ける	最初に一度だけ分岐
Self-RAG	反射トークンを出すようモデルを fine-tune し、必要時のみ検索・自己批評	実行時に分岐
Corrective RAG (CRAG)	軽量な評価器で取得品質を採点し、閾値未満なら Web 検索などに切り替え	実行時に分岐
Agentic RAG / Agentic Search	エージェントがツール（全文検索、ベクトル検索、ファイル読み、API など）を多段で呼ぶ	実行時に決まる
Deep Research	長時間かけて多段の Web 探索を行い、長文レポートを合成する	実行時に決まる

こうして並べると、これらは対立する別物というより、「検索の主導権をどこまで LLM に渡すか」という一本の軸の上に並んでいる、と見た方が分かりやすいと思います。

Agentic RAG のサーベイとしては、Singh らの「Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG」（arXiv:2501.09136、2025 年 1 月 15 日投稿）が代表的です。用語の定義に迷ったら、まずここを見るのがよさそうです。

ニュアンスの違いとしては、「Agentic RAG＝既存の RAG をエージェント化したもの」「Agentic Search＝そもそもベクトル取得を使わずツールで探しに行くもの」という使い分けを見かけますが、明確な合意があるわけではありません。

この記事では、Agentic Search を「検索の経路を実行時にエージェントが決める構成」という意味で使います。ベクトル検索を使うかどうかは別の軸で、エージェントが持つツールの一つがベクトル検索であっても構いません。「ベクトル DB を使わない」という主張は、この軸とは独立した別の主張として扱います。

なお、この図の並びは各手法の代表的な構成での位置づけです。たとえば Microsoft GraphRAG の DRIFT search は、検索の途中で追加の質問を生成して探索を続ける仕組みを持っており、右側に寄ります。手法の名前で位置が決まるわけではありません。

3. 構造の違い ─ 固定パイプラインか、動的ループか

用語より、構造の違いを絵にした方が早いかもしれません。

ナイーブ RAG は、推論の前に一度だけ検索する固定パイプラインです。

ここでの本質的な制約は、検索が一回きりだという点です。最初の類似度検索が空振りすると、LLM は手元にある不十分なチャンクだけで答えを作るしかありません。しかも、チャンク分割の粒度も、埋め込みモデルも、top-k の k も、質問を見る前に決めてしまっています。

対して Agentic Search は、エージェントがツールを何度も呼ぶ動的ループです。

こちらは、検索結果を見てから次に何を調べるかを決められます。一段目で当たりを付け、二段目で絞り込み、三段目で裏を取る、といった人間に近い調べ方ができます。

その代わり、LLM の推論がループの回数ぶん走ります。ここがそのままコストとレイテンシに効いてきます。この点は後で数字を見ます。

構造の違いを表にすると、次のようになります。

観点	ナイーブ RAG	Agentic Search
検索のタイミング	推論前に一度	推論中に何度でも
経路が決まる時点	設計時	実行時
事前インデックス	必要（更新の運用が要る）	不要にもできる
索引の陳腐化	起こりうる	起こりにくい
LLM 推論の回数	1 回	数回〜数十回
検証可能性	取得チャンクの出所を追う必要あり	grep なら行番号まで返る
モデルへの要求	低い（読めればよい）	高い（ツール使用と多ターンの一貫性）
コスト	小さい	大きい

4. 「Agentic Search の方がよい」はどこから来たのか

この主張の発信源としてよく引かれるのが Anthropic です。

Claude Code の創設者である Boris Cherny は、2025 年 5 月の Latent Space ポッドキャストで、ごく初期の Claude Code は RAG を使っていたが、最終的に Agentic Search に落ち着いた、と述べています。「everything を上回った。それも大差で。これは意外だった」という表現も出てきます。

ただし、同じインタビューで、何を指標にしたのかと問われて「これはただの vibes（体感）です。社内の vibes。社内ベンチマークもいくつかありますが、ほとんどは vibes です」と答えています。つまりこれは、公開された定量比較ではありません。Claude Code の社内ベンチマークは公開されていないので、この発言をもって「Agentic Search が RAG に勝つことが証明された」とするのは無理があります。ここは意見として受け取るのが妥当だと思います。

発言の裏付けとは別に、実装は公式ドキュメントで確認できます。Claude Code のツールリファレンスには組み込みツールが一覧で載っていますが、そこにインデックス作成や埋め込み、ベクトル検索に類するツールは存在しません。コードを探すためのツールは次の四つです。

ツール	内容
Glob	ファイル名のパターンでファイルを探す。結果は更新時刻順で 100 件が上限
Grep	ファイルの中身を正規表現で検索する。ripgrep の上に作られており、.gitignore を尊重する
Read	ファイルの中身を行番号付きで返す
LSP	言語サーバによる定義ジャンプ、参照検索、型情報。ただしプラグインを入れるまで無効

そしてドキュメントには、カスタムツールを足したい場合は MCP サーバを接続する、と書かれています。つまり、インデックスを使いたければ外から足す設計になっています。

Anthropic の公式ブログ「Effective context engineering for AI agents」（2025 年 9 月）も、CLAUDE.md のように前もって入れておくものと、glob や grep で必要になった時点で取りに行くもの（just-in-time）を組み合わせるハイブリッドを推奨しています。

理由については、Boris Cherny が Hacker News で、初期の Claude Code は RAG とローカルのベクトル DB を使っていたが Agentic Search の方が総じてうまくいくと分かった、それに加えて構成が単純で、セキュリティ、プライバシー、陳腐化、信頼性の問題がない、と書いています（この投稿自体は解説記事経由で確認した二次情報です）。整理すると次のようになります。

理由	内容
単純さ	索引を持たなければ、埋め込みモデルもベクトル DB も同期パイプラインも要らない
セキュリティ	どこかに置かれた索引は攻撃対象になる
プライバシー	専有コードの埋め込みは、密ベクトルであっても情報を漏らしうる
陳腐化	コードは常に書き換わる。索引はセッション開始時点で既に古い
信頼性	構成要素が増えるほど故障点が増える
検証可能性	grep は具体的なファイルパスと行番号を返すので、結果の正しさを機械的に確かめられる

陳腐化はコード特有の事情です。逆に言えば、更新頻度の低い知識ベースではこの利点は効きません。

もっとも、この設計に異論がないわけではありません。ベクトル DB を開発している Milvus は、grep は無関係なマッチに埋もれてトークンを浪費する、という趣旨の反論を出しており、Claude Code にセマンティック検索を足す MCP プラグイン（Claude Context）を公開しています。

ここが実務上は重要で、デフォルトでインデックスを持たないことと、インデックスを足せないことは別です。数十万行から百万行規模のリポジトリでは、セマンティック検索の MCP サーバを足す運用が紹介されており、プロジェクト自身の評価としてトークン使用量が約 40% 減ったという報告もあります（開発元による評価）。デフォルトの設計と、規模が変わったときの実務は分けて考える必要がありそうです。

5. RAG 側も止まっていない ─ Contextual Retrieval

「RAG は死んだ」側の話をする前に、RAG 側の改良を見ておきます。

Anthropic が 2024 年 9 月に公開した Contextual Retrieval は、各チャンクに文書全体の文脈を 50〜100 トークンほど付与してから埋め込み・BM25 索引化する、という手法です。公式ブログに社内評価の数値が載っています。

手法	top-20 取得失敗率	ベースラインからの削減
ベースライン（埋め込み＋BM25）	5.7%	─
Contextual Embeddings	3.7%	35%
＋ Contextual BM25	2.9%	49%
＋ リランキング	1.9%	67%

出典：Anthropic 公式ブログ。社内評価であり、第三者による再現ではない点は割り引いて読む必要があります。

問題設定としては、たとえば決算資料のチャンクに「revenue grew 3%」とだけ書いてあっても、どの会社のどの四半期か分からない、という話です。文脈を付けておけば、この曖昧さが解消されます。技術仕様書や規程類のように、章立ての中で意味が決まる文書では、同じ問題がよく起きます。

つまり、「素朴なチャンク分割は弱い」は正しいのですが、それは「RAG が使えない」ではなく「RAG の作り方が雑だった」という話でもあります。ここは区別しておきたいところです。

なお同じ記事で Anthropic は、知識ベースが 20 万トークン（およそ 500 ページ）未満なら、RAG を組まずにプロンプトへ全部入れる選択肢もある、とも書いています。規模が小さいなら、そもそも検索の話をしなくてよいわけです。

6. コーディングエージェント各社の実装

実装が分かれているところを見ると、どちらが正解と決まっていないことがよく分かります。

実装	方式	備考
Claude Code	デフォルトではインデックスなし。Glob / Grep / Read、任意で LSP	索引の陳腐化と、索引を持つこと自体のリスクを避ける設計
Aider	tree-sitter で repo map を作りプロンプトに入れる	構造的な要約を渡す方式
Cursor	ハイブリッド。AST 単位のチャンク分割＋独自埋め込み＋ベクトル DB、加えてトライグラム転置索引	大規模リポジトリでの探索コストへの対処と説明

Cursor は公式ブログ「Improving agent with semantic search」（2025 年 11 月 6 日）で、セマンティック検索の効果を報告しています。ただし測り方が二種類あるので、分けて読む必要があります。

指標	測り方	報告値
質問応答の精度	自社のオフライン評価（Cursor Context Bench）	平均 12.5% 向上（モデルにより 6.5〜23.5%）
コード保持率	実利用でのオンライン A/B テスト	0.3% 改善（1000 ファイル超の大規模では 2.6%）
不満を招くフォローアップ	同上	使わない場合に 2.2% 増加

これは一次情報ですが、自社ベンチかつ自社製品の評価であること、いずれも相対値で示されておりベースラインの絶対値が公開されていないことは考慮しておきます。

面白いのは、Anthropic は「ベクトル検索は要らない」方向、Cursor は「ベクトル検索を足すと良くなる」方向に、それぞれ一次情報で主張している点です。おそらく、対象リポジトリの規模とツールの応答速度によって最適解が違う、ということなのだと思います。

7. 多段階検索は本当に効くのか

ここからが定量データです。個別の製品ではなく、公開ベンチマーク上で「一回だけ検索する」対「何度も検索する」を比べた結果を見ます。

まず Google の FRAMES です。2 〜 15 件の Wikipedia 記事にまたがるマルチホップ質問 824 問からなるベンチマークで、論文（arXiv:2409.12941、NAACL 2025）に検索方式別のスコアが載っています。

条件	正答率
検索なし	40.8%
BM25 単発（2 文書）	45.2%
BM25 単発（4 文書）	47.4%
多段階検索（5 段、各段 5 クエリ、各クエリ 10 文書）	66.0%
oracle（正解文書を与える）	72.9%

モデルは Gemini-Pro-1.5 です。単発検索は文書を 2 件から 4 件に増やしても 2 ポイントしか伸びないのに対し、多段階検索は 66.0% に達しています。論文の要旨も、検索なしの 0.40 から多段階検索で 0.66 へ、50% 以上の改善と書いています。

ここで条件を確認しておきます。多段階検索の設定は、検索計画の指示を加えたうえで 5 段階、各段 5 クエリ、各クエリ 10 文書です。単発の 4 文書とは、検索の回数だけでなく取得する文書量もプロンプトも違います。したがってこの差を「検索を繰り返したことの効果」とだけ読むのは正確ではありません。読み取れるのは、検索の回数と量と計画をまとめて増やした構成が、単発の少量取得を大きく上回った、というところまでです。

もう一つ、この論文で見落とせないのが oracle 設定です。正解文書を全部与えても 72.9% にとどまり、27.1 ポイントの差が残ります。論文の分析では、oracle 設定での失敗のおよそ 8 割が数値計算、表の読み取り、後処理に関するもので、情報が揃っていても推論でつまずいていることになります。ただし oracle は上限ではありません。同じ論文では、数値推論の一部で多段階検索が oracle を上回っています。oracle は「その実験設定での参照値」であって、越えられない天井として読むべきではなさそうです。

次に OpenAI の BrowseComp です。難問 1,266 問からなる Web 探索ベンチマークで、2025 年 4 月に公開されました。

条件	正答率
GPT-4o（ブラウジングなし）	0.6%
GPT-4o ＋ ブラウジング	1.9%
Deep Research	51.5%

数字の差は大きいのですが、読み方には注意が要ります。前の二つは同じモデルでツールの有無を比べたものですが、Deep Research は別のモデルで、しかも公式に、この種の探索課題に対応する学習を受けていると説明されています。つまり 1.9% と 51.5% の差には、検索の仕方だけでなく、モデルと学習の違いが混ざっています。

したがってこの数字は「多段に探索する仕組みを載せるとこうなる」という検索方式の比較ではなく、「探索そのものを学習させたエージェントシステムが、汎用モデルにツールを渡しただけの構成をどれだけ引き離すか」の例として読むのが正確です。少なくとも、ツールを渡せば勝手に使いこなしてくれるわけではない、という点は読み取れます。

8. 強化学習で検索そのものを学習させる研究

もう少し学術寄りの流れとして、検索の仕方を強化学習で学習させる研究が 2025 年に相次いで出ています。

ここで注意が要るのは、報告のされ方が論文ごとに違うことです。相対改善率（何パーセント良くなったか）で書いている論文と、スコアのポイント差で書いている論文が混在しており、そのまま一つの軸に並べると意味が変わってしまいます。分けて示します。

相対改善率で報告されているもの。

研究	条件	比較相手	改善
Search-R1（arXiv:2503.09516）	Qwen2.5-7B、7 種の QA データセット	各種 RAG ベースライン	+41%（3B 版は +20%）
R1-Searcher（arXiv:2503.05592）	Qwen2.5-7B-Base、LLM-as-Judge	GPT-4o-mini ＋ ReARTeR	HotpotQA +48.2%、2Wiki +21.7%

スコアのポイント差で報告されているもの（R-Search、arXiv:2506.04185、Qwen2.5-7B）。

比較	スコアの変化	差
2Wiki、F1、Vanilla RAG → R-Search	40.5 → 77.7	＋37.2 ポイント
MuSiQue、EM、Search-R1 → R-Search	25.8 → 31.4	＋5.6 ポイント

R-Search の 37.2 と 5.6 はポイント差であって相対改善率ではありません。後者を相対改善率に直すと約 21.7% で、たまたま R1-Searcher の 2Wiki の値と同じ数字になってしまうので、混同しやすいところです。論文本文の「%」表記も紛らわしいため、元のスコアを併記しておくのが安全だと思います。

比較相手も揃っていません。Search-R1 は各種 RAG ベースライン、R1-Searcher は GPT-4o-mini に別手法を組み合わせたもの、R-Search は Vanilla RAG と Search-R1 です。「従来 RAG からの改善」と一括りにすると、この違いが隠れます。

Search-R1 の数値は改訂版（2025 年 8 月時点）の要旨に基づきます。初期版では 26% / 21% / 10% という別の数字が示されていたので、引用する際は版にも注意が必要です。

こうした条件の違いはありますが、7B クラスの比較的小さなモデルでも、検索の使い方を学習させれば検索なしや素朴な RAG の構成から改善する、という方向は複数の独立した研究で一致しています。

これらが示しているのは、検索の使い方そのものが学習によって改善する余地の大きい能力だ、ということです。ただし「学習させれば伸びる」から「学習していないモデルでは使えない」は導けません。追加学習なしのモデルがどこまで通用するかは、これらの論文ではなく、次章以降で見るツール使用のベンチマークの側から判断することになります。

9. 正面から比べた研究 ─ 「キーワード検索で 9 割」

ここまでは「多段階かどうか」の比較でしたが、「ベクトル DB が要るかどうか」を正面から比べた研究もあります。

Amazon の Subramanian らによる「Keyword search is all you need: Achieving RAG-Level Performance without vector databases using agentic tool use」（arXiv:2602.23368、AAAI 2026）です。ベクトル DB とセマンティック検索が、単純なキーワード検索をエージェントに使わせる方式に対してどれだけ上乗せの価値があるのかを検証しています。

要旨の結論は、エージェント的なキーワード検索が、従来の RAG に対して性能指標の 9 割超を、常設のベクトル DB なしで達成した、というものです。内訳は論文の結果表にあります。

指標	比較対象の RAG に対する到達率（平均）
Faithfulness（根拠との整合）	94.52%
Context recall（必要な文脈を拾えたか）	88.05%
Answer correctness（回答の正しさ）	91.48%

この数字の読み方には注意が要ります。これは絶対的な正答率ではなく、比較した RAG 構成を 100 としたときの比率です。

そして、平均が 9 割台だからといって「RAG の方が常に上」ではありません。同じ論文では、データセットによってはエージェント側が RAG を上回る結果も報告されています（FinanceBench がその例です）。優劣はデータセットによって変わる、というのが実際のところです。

この論文が示しているのは「キーワード検索の方が精度が高い」でも「RAG の方がまだ上」でもなく、この実験の範囲では多くの指標で比較対象の RAG に近い性能が、常設のベクトル DB なしで得られた、ということです。そのうえで論文は、実装が単純でコストが安く、知識ベースの更新が頻繁な場面で有用だと述べています。

「RAG は死んだ」という言い方とはかなり違いますし、逆に「やはり RAG が上だ」という結論にもなりません。ベクトル DB を持つかどうかは、精度で一律に決まる話ではなく、対象データと運用条件で決める話だ、と読むのが妥当だと思います。

10. 代償 ─ トークンとレイテンシ

ここまでは Agentic Search に有利な数字が多く並びましたが、当然ながら代償があります。

Anthropic の公式エンジニアリング記事「How we built our multi-agent research system」（2025 年 6 月）には、この点の数字が明記されています。

項目	数値
マルチエージェント構成の性能（社内評価）	単一の Claude Opus 4 に対して +90.2%
エージェントのトークン消費	通常のチャットのおよそ 4 倍
マルチエージェントのトークン消費	通常のチャットのおよそ 15 倍
性能のばらつきを説明する割合（BrowseComp 上）	3 要因（トークン使用量、ツール呼び出し数、モデル選択）で約 95%、うちトークン使用量単独で約 80%

いくつか留保が要ります。90.2% は同社の社内評価であって、公開ベンチマークの結果ではありません。4 倍と 15 倍も、同社の環境で観測されたトークン消費量であって、どの構成でもこの倍率になるという法則ではありません。

分散の内訳についても、公表されているのは「3 要因で約 95%、うちトークン使用量単独で約 80%」までで、残り 15 ポイントをツール呼び出し数とモデル選択にどう分けるかは示されていません。

そのうえで、性能のばらつきの 80% がトークン使用量と相関する、というのは示唆的です。ただしこれは分散の説明であって因果の分解ではないので、「性能向上の大部分は賢さではなく物量から来ている」とまで言い切ることはできません。実際、同じ記事にはモデルを新しくした効果がトークン予算を倍にした効果を上回った例も出てきます。読み取れるのは、トークンを使う構成ほど成績が良い傾向が強く出ており、コストと性能を切り離して考えにくい、という程度です。

Anthropic 自身も、全エージェントが同じコンテキストを共有するタスクや、依存関係が強く絡み合うタスクは今日のマルチエージェントには向かない、と述べています。コーディングのような密結合のタスクは不得手だという位置づけです。

レイテンシについては、前段の結果に依存するステップは並列化できず、この直列部分が待ち時間になります。逆に、互いに独立した検索や調べ物は並列に走らせられます。実際、同じ記事のマルチエージェント構成は、サブエージェントとツール呼び出しを並列化することで速度を稼いでいます。各段の処理時間が同程度なら、直列部分の段数にほぼ比例して応答時間が伸びる、という見方になります。

Anthropic の整理は、こうしたコストに見合うのは高価値なタスク（法務のデューデリジェンス、競合調査、学術文献のレビューなど）に限られる、というものです。これは実務的な線引きとして納得できるものだと思います。

11. 長コンテキストがあれば RAG は要らないのか

RAG 不要論のもう一つの流れが、「コンテキストウィンドウが十分に長くなったのだから、全部入れればよい」というものです。

これについては、Google DeepMind らの「Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach」（arXiv:2407.16833、EMNLP 2024 Industry Track）が比較的バランスの取れた検証をしています。リソースが十分にあるなら長コンテキストが平均品質で RAG を一貫して上回るが、RAG の大幅に低いコストは明確な利点として残る、というのが結論で、両者を使い分ける Self-Route という手法を提案しています。

もう一つよく引かれるのが「Lost in the Middle」（Liu ら、TACL 2024）で、長い文脈の中央に置かれた情報の利用率が落ちる U 字カーブを報告しています。ただしこれは 2023 年当時のモデルでの結果です。現行世代のモデルでは中央の扱いが改善しているという指摘もあり、そのまま現在に当てはめるのは危ういと思います。

コスト面については「RAG は long-context の 8 〜 82 倍安い」といった数字を見かけますが、これらは個人ブログやベンダー記事の主張で、測定条件が明確でないものが多いです。桁感の参考程度にとどめるのがよさそうです。

この論点について、実証されていることと意見にとどまることを分けると、次のようになります。

主張	位置づけ
検索の回数・取得量・計画をまとめて増やした構成が、単発の少量取得を上回る	FRAMES で実証。検索回数だけの効果ではない
ベクトル DB なしでも RAG に近い性能が出る	AAAI 2026 の論文で実証。優劣はデータセットによって変わる
長コンテキストは品質で有利だがコストが高い	EMNLP 2024 で検証
長い文脈の中央は使われにくい	2023 年モデルでは実証。現行世代は要検証
grep 系の検索はコードでは有効	実装事例として確認できる。公開された定量比較は限定的
ベクトル DB はもう要らない	意見。反例（Cursor）が一次情報で存在する
RAG は完全に不要	意見・宣伝の域

12. ローカル LLM で Agentic Search は成立するか

Agentic Search はモデルのツール使用能力と、多ターンにわたる一貫性に強く依存します。ローカルで動く量子化済みモデルでどこまでいけるのか、公開されている数字を見てみます。

まず BFCL v3 です。v3 では多ターン・多ステップの評価が加わっており、総合スコアは多ターンを含む全カテゴリの平均です。

モデル	BFCL v3
GLM-4.5（355B MoE）	77.8
GLM-4.5-Air（106B）	76.4
Claude Opus 4	74.4
GPT-4.1	68.9

出典：GLM-4.5 の論文（arXiv:2508.06471）Table 3。開発元による自己申告値です。第三者集計では GLM-4.5 が 76.7 という値も出ており、1 ポイント程度の差は測定条件で動きます。

オープンウェイトの上位がクローズドの上位と並んでいるのは注目に値します。

次に τ-bench です。こちらは顧客対応のドメインで、方針文書に従いながらユーザーとやりとりしてツールを使う設定です。BFCL とはタスクも採点方法も違うので、両者のスコアを引き算して「多ターンになると何ポイント落ちる」と読むことはできません。別々の物差しとして見てください。

モデル	τ-bench Retail	τ-bench Airline
GLM-4.5（355B）	79.7	60.4
gpt-oss-120b	67.8	49.2
gpt-oss-20b	54.8	38.0

出典：gpt-oss の論文（arXiv:2508.10925）と GLM-4.5 の論文。gpt-oss-120b は reasoning=high の値です。いずれも開発元の自己申告値です。

128GB 級のマシンで動く例としては、gpt-oss-120b（MXFP4 で 61GB 程度）や 70B クラスの 4bit があります。GLM-4.5 の 355B は載りません。ただし搭載可否は重みのサイズだけでは決まりません。KV キャッシュは文脈長と同時実行数に比例して増えますし、実行時のバッファも要ります。多段検索では文脈が伸びるので、重みが収まっても文脈長を欲張ると足りなくなります。

さらに厳しいのが、ユーザーと協調しながらツールを使う設定です。τ²-bench（arXiv:2506.07982、2025 年 6 月）は、エージェントとユーザーの双方が共有環境を操作する Telecom ドメインを追加したもので、論文では 4 モデル（gpt-4.1、gpt-4.1-mini、o4-mini、claude-3.7-sonnet）が評価されています。gpt-4.1 の pass^1 は Retail 74%、Airline 56% に対し、Telecom は 34% まで落ちます。他の 3 モデルは Telecom で 50% 前後、claude-3.7-sonnet は 49% です。

同じ論文で、エージェントが自分で全部やる設定から、ユーザーに手順を案内させる設定に変えると、pass^1 が gpt-4.1 で 18 ポイント、o4-mini で 25 ポイント落ちたと報告されています。ツールがあり知識もあるのに、部分的な情報しか持たない相手とやりとりすること自体が大きなボトルネックになる、というのがこの論文の主張です。

まとめると、ローカルで動く中型モデルのツール使用は BFCL v3 の総合スコアで見る限り実用域に入ってきていますが、ユーザーと協調しながら進める設定では、フロンティア系のモデルでも成績が大きく落ちる条件がある、ということになります。

量子化の影響も見ておきます。「Flat Score, Amplified Failures」（arXiv:2607.27275、2026 年 7 月）は τ²-bench で、2 つのオープンウェイトのモデル系列（それぞれ dense と MoE）と 2 ドメインの 8 セルに、Qwen-3.5 の追加 2 セルを加えた計 10 セルを、16bit、8bit（重みのみ）、4bit（AWQ）で比較しています。

まずスコアです。10 セルすべてで信頼区間がゼロを含み、多重比較の補正を通る変化はどこにもありませんでした。そのうえで論文は、10 セル中 7 セルについて、±7.5 ポイントを許容幅とする同等性検定（TOST）を通ったと報告しています。この 7 セルには、後述するプロセス上の悪化が最も大きかったセルも含まれます。残る 3 セル（いずれも Gemma-4）は区間が許容幅より広く、「同等だと確認できた」ではなく「差を検出できなかった」だけだと明記されています。この区別は引用するときに落としやすいところです。

一方、プロセスを見ると話が変わります。存在しないツール名を呼ぶ失敗が、最も増えたセル（Gemma-4-31B、telecom）で次のように動きました。

指標	16bit	4bit
ツール名の誤りの割合（エージェントの全ツール呼び出しに占める比）	19.5%	38.3%
誤呼び出しの件数（456 エピソード合計）	649 件	1,646 件

割合は約 2 倍ですが、4bit ではエピソードあたりの呼び出し回数自体も増えるため、件数では約 2.5 倍になります。論文が挙げている 2.5 倍はこの件数の比です。別に出てくる「1 タスクあたり +17.6 ポイント」は、タスクごとの誤り率の増加分で、こちらは別の指標です。同じ現象を違う物差しで測った数字なので、並べて引用するときは注意が要ります。

構造として重要なのは、新しい種類の失敗がほとんど増えていないことです。4bit の誤呼び出し 1,646 件のうち、16bit では一度も出なかったツール名は 3 件（0.18%）だけでした。つまり、そのモデルが元々出していた失敗を、量子化が頻度だけ増やしている、ということになります。

なぜスコアが平らなままかというと、このベンチマークが 1 エピソードあたり 10 回の失敗を許容しており、エージェントが失敗から回復してしまうからです。既存の実行ログを、失敗が 2 回を超えたエピソードは失敗とみなす条件で採点し直すと、スコアの差は 1.3 ポイントから 16.7 ポイントに開きます。

これは上限を 2 回に設定してエージェントを走らせ直した結果ではなく、同じログの採点をやり直した分析です。論文自身も、決定的な確認には上限を絞った再実行が必要だと書いています。とはいえ方向としては、リトライの余地が少ない使い方をするなら、ベンチマーク上の「無害」は当てにならない、ということになります。

だからこの論文の実務的な含意は、量子化方式の優劣ではありません。実際、ここで使われた 4bit は AWQ 系で、AWQ でもプロセス上の失敗は増えています。論文が挙げているのは、量子化する前に、対象ドメインでそのモデルが元々どれくらいツール名を間違えるかを測っておけば、危険なモデルかどうかを事前に選別できる、という方法です。元の誤り率がほぼゼロなら 4bit にしても安全な見込みが高い、というわけです。

8bit についても触れておきます。同じ論文は、有意なスコア低下はどのセルにもなく、telecom のツール名の誤りも 8bit では動かなかったと報告しています。ただし「何も起きない」わけではありません。名目上 9.7 ポイント上がったセルがありますし、Gemma-4 MoE の retail では、4bit と同程度の引数エラーの増加（+1.40 ポイント、有意ではない）が 8bit の時点ですでに出ています。論文はここから、安全な精度の境界もモデルとチャネルの組み合わせによる性質であって、普遍的な定数ではないと述べています。

またこの実験の 8bit は重みのみの量子化で、活性値と KV キャッシュは 16bit のままです（4bit の条件も同様に重みのみ）。8bit を選ぶ補助的な根拠にはなりますが、どのモデルでも 8bit なら安全だ、と読める書き方は避けたほうがよさそうです。

量子化方式による差については、長文の入力と出力を扱うタスクを対象にした研究（arXiv:2505.20276、EMNLP 2025）が、8bit は精度をほぼ保つ（0.8% 程度の低下）のに対し 4bit 系は大きく落ちることがあり、bitsandbytes の nf4 が最も悪く最大 59% の低下を観測した、と報告しています。ただしこれは長文脈タスクでの結果で、著者自身もモデル、タスク、量子化方式への依存が大きいと述べています。一般的な結論として広げるのは避けるべきです。

以上をまとめると、実務上言えるのは「量子化を落とすなら、最終的な成功率だけでなく、不正なツール名、引数のエラー、再試行の回数を、自分が使うモデルと量子化方式で測る」ということです。集計スコアだけ見ていると、ツール呼び出しの失敗が増えていることに気づけません。

最後に速度です。多段検索は推論を何回も回すので、生成速度がそのまま待ち時間になります。

これは 1 段あたり出力 400 トークンと仮定した概算で、実測ではありません。参考にした生成速度は、M4 Max 128GB で 70B の 4bit がおよそ 18 〜 20 tok/s、M3 Max 128GB で Llama 3.3 70B がおよそ 7 tok/s、RTX 4090 二枚で 70B がおよそ 21 tok/s といったあたりで、いずれも個人ベンチや掲示板の報告です（二次情報）。

20 tok/s のマシンで 5 段回すと生成だけで 100 秒、10 段なら 200 秒です。ここに検索そのものの時間とプロンプト処理が乗ります。ローカルで Agentic Search をやるなら、段数を制限する仕組みは事実上必須だと思います。

13. ベンチマークの数値を読むときの注意

この記事を書きながら実感したのですが、この分野のベンチマーク数値は引用の仕方を間違えやすいです。気づいた落とし穴を挙げておきます。

落とし穴	内容
τ-bench と τ²-bench の混同	名前が似ていますが別物です。τ²-bench は双方向制御の設定を追加した後継で、Telecom ドメインを持ちます。数値を同じ表に並べると誤解を招きます
別ベンチのスコアを引き算する	BFCL と τ-bench はタスクも採点方法も違います。「BFCL は高いのに τ-bench が低いから多ターンで落ちる」といった読み方はできません
ベンチ名から中身を推測する	BFCL v3 は多ターンの評価も含みます。版ごとに何を測っているかは変わります
自己申告値と第三者集計の差	モデル開発元が自分で測った値と、第三者が測った値は一致しません。GLM-4.5 の BFCL v3 は 77.8 と 76.7 の両方が流通しています
ベンチマークのフォーク	τ-bench の Airline ドメインには正解データの誤りが指摘されており、修正版がいくつか存在します。どの版で測ったかによって値が変わります
版によるスコアの変動	Search-R1 のように、論文の改訂で報告値が変わることがあります
時期による陳腐化	τ²-bench の論文（2025 年）では Telecom は最難関で 34 〜 50% でしたが、2026 年の第三者リーダーボードでは 99% 台のモデルも出ています。1 年前の「難しい」は今の「難しい」ではありません
LLM-as-Judge の評価	FRAMES や R1-Searcher など、評価に LLM を使っているものがあります。判定側のモデルが変われば値も動きます
集計サイトの未検証値	実在しないモデル名や将来日付の値が混ざっていることがあります。一次情報に当たるのが安全です

ベンチマークのバージョンも動きます。BFCL はすでに v4 が出ており、エージェント的な評価が加わっています。数値を引用するときは、ベンチマーク名だけでなく版と測定者を書いておくのがよさそうです。

14. 見落としやすい論点 ─ セキュリティとアクセス制御

精度とコストの話に寄りがちですが、方式選択に効いてくる論点がもう二つあります。

一つはプロンプトインジェクションです。Agentic Search はその場で外部の文書や Web ページを読み込んで、その内容に基づいて次の行動を決めます。読み込んだ内容に指示文が仕込まれていた場合、それがそのまま次のツール呼び出しに影響しうる、という構造的な問題があります。事前にインデックス化する RAG でも同じ問題は起きますが、Agentic Search は読む対象が実行時に決まるぶん、攻撃面が広くなります。

もう一つはアクセス制御です。grep のようにファイルシステムを直接叩く方式は、OS のファイル権限がそのまま効きます。ただしこれは、検索プロセスを動かしているユーザーの権限が効くという意味です。共有のサーバーで広い権限を持つプロセスとして動かせば、依頼した人ごとの閲覧権限は自動では守られません。利用者ごとに権限を効かせたいなら、利用者の権限で実行するか、権限チェックを別に設ける必要があります。

一方、ベクトル DB に索引を作る方式では、誰がどのチャンクを見てよいかという情報を索引側にも持たせて同期し続ける必要があります。社内文書のように権限が細かく分かれている対象では、どちらの方式でもここが実装上の重い部分になります。

索引そのもののリスクもあります。第 4 章で見たとおり、Claude Code が RAG をやめた理由として挙げられているのは精度だけではなく、索引が攻撃対象になること、専有コードの埋め込みが密ベクトルであっても情報を漏らしうること、が並んでいます。埋め込みから元のテキストを部分的に復元できるという研究もあり、ベクトル DB に何を入れるかは、精度とは別に判断する必要があります。

これらの論点は精度の議論とは独立していて、しかも用途によっては精度より優先されます。方式を決めるときには、精度・コスト・レイテンシに加えてこれらも並べて検討する必要があると思います。

15. 使い分けの基準

ここまでの材料を、判断の流れとして整理してみます。

図の最初の分岐に 20 万トークンという数字を置いていますが、これは Anthropic が Contextual Retrieval の記事で挙げていた目安であって、普遍的な基準ではありません。実際には、使うモデルの文脈長の上限、回答を書くための余白、その長さで精度が保てるか、そして入力を処理する時間（ローカルではここが効きます）を見て決めることになります。目安として置いた数字だと考えてください。

言葉にすると、次のようになります。

状況	向いている構成
知識ベースが小さく、文脈に収めても余裕がある	そのままプロンプトに入れる
安定した知識ベース、定型的な Q&A、コスト最優先	ハイブリッド RAG（文脈付与＋リランカー）
一回の検索では根拠が揃わない多段の調べ物	Agentic Search
資料の更新が頻繁で、索引の鮮度が問題になる	Agentic Search、または索引更新の運用込みの RAG
ベクトル DB の運用コストを避けたい	エージェント＋キーワード検索（ある比較実験では RAG に近い性能）
出典を行単位まで示す必要がある	Agentic Search（grep 系は位置が返る）
権限管理が細かい社内文書	利用者の権限で実行する検索ツール系、または索引側での権限管理
モデルの多ターン性能が不足している	Adaptive RAG や CRAG のような段数を絞った構成

コスト・レイテンシ・精度のトレードオフをまとめると、おおむね次の順に、精度と引き換えにコストが増えていきます。

構成	相対コスト	精度の伸びしろ	主なリスク
プロンプトに全部入れる	中〜大	高い（規模が小さいうちは）	規模が増えると破綻する
ナイーブ RAG	小	低い	一回の検索の空振り
ハイブリッド RAG ＋ リランカー	小〜中	中	索引の陳腐化、権限同期
Adaptive / CRAG	中	中〜高	分岐の判定ミス
Agentic Search	大	高	レイテンシ、ツール使用の失敗、インジェクション
マルチエージェント	特大	高	コスト、密結合タスクに不向き

相対コストの欄をあえて倍率で書いていないのは、第 10 章の 4 倍・15 倍がトークン消費量の観測値であって、金額の倍率ではないからです。実際の費用は、モデルの単価、キャッシュの効き方、並列化の度合いで変わります。

16. 現実的な着地点はハイブリッド

こうして見ていくと、RAG と Agentic Search は二者択一ではなく、RAG をエージェントのツールの一つとして持たせる形に収束していくのではないかと思います。

実際、エンタープライズではハイブリッド検索（BM25 とベクトルの併用にリランキングを重ねる構成）の採用が急速に増えているという調査もあります。VentureBeat の VB Pulse 調査では、ハイブリッド検索の採用意向が四半期で 10.3% から 33.3% に増えた一方、長コンテキストで済ませられるという回答は 15.5% から 3.5% に減ったと報じられています（二次情報）。

段階的に進めるなら、次の順序が現実的だと思います。

段階	やること	期待できること
1	文脈付与＋ BM25 ＋ベクトル＋リランカーで、まず良い RAG を作る	取得失敗率の低下（Anthropic の社内評価では 5.7% → 1.9%）
2	その RAG を検索ツールとしてエージェントに渡し、全文検索や直接参照のツールを足す	多段の調べ物への対応
3	出典の一致率とハルシネーション率で、1 と 2 を比較評価する	どちらが要るのかを自分のデータで判断できる

段階 1 を飛ばして段階 2 に行くと、エージェントに渡すツールの品質が低いまま、推論の回数だけが増えます。

ここでの段階 1 を「必ずベクトル RAG を作る」と読む必要はありません。Claude Code のように grep だけで組み立てる構成もありますし、Amazon の研究のようにキーワード検索だけでかなりのところまで届く場合もあります。前提になるのは、用途に合った検索・参照の手段を先に用意しておくことで、ベクトル RAG はその選択肢の一つです。言い換えの幅が大きい文書ではベクトル検索が有効な場面が多く、識別子や記号で引ける文書なら全文検索だけで足りる場面もあります。もっとも、言い換えへの対処はベクトル検索だけの手段ではなく、クエリを書き換えたり同義語で展開してからキーワード検索にかける方法もあります。

いずれにせよ、良い検索手段は Agentic Search と対立するものではなく、その土台になる、というのがここまで調べた実感です。

17. まとめ

• 「RAG は死んだ」は誇張です。ただし「事前チャンク分割と top-k だけの素朴な RAG は劣勢」は、複数の公開ベンチで裏づけられています。
• 検索を繰り返し、量と計画を増やした構成が単発の少量取得を上回ることは、FRAMES で 47.4% 対 66.0% という形で確認できます。ただしこの二つは取得文書数もプロンプトも違うので、検索回数だけの効果ではありません。
• BrowseComp の 1.9% 対 51.5% は、検索方式の比較ではなくシステムの比較です。Deep Research は探索そのものを学習した別のモデルなので、この差を多段検索の効果として引用するのは誤りです。
• ベクトル DB を外してもかなりのところまで届く、という研究（AAAI 2026）があります。指標の平均で比較対象の RAG の 9 割前後、データセットによってはエージェント側が上回ります。ベクトル DB を持つかどうかは、精度だけで一律に決まる話ではありません。
• 強化学習で検索を学習させた研究群でも改善が一貫して報告されていますが、相対改善率とポイント差、比較相手が論文ごとに違うので、横並びにはできません。
• 代償は大きく、Anthropic の報告ではエージェントは通常のチャットの約 4 倍、マルチエージェントは約 15 倍のトークンを消費します。同社の環境での観測値であり、どの構成でも成り立つ倍率ではありません。性能のばらつきは 3 要因で約 95%、うちトークン使用量単独で約 80% が説明されると報告されていますが、これは相関の話で、因果の分解ではありません。
• Anthropic が Claude Code でベクトル DB をやめたのは事実で、公式ドキュメントのツール一覧にも索引系のツールはありません。ただし精度の優位を示す公開された定量比較はなく、本人も判断は主に体感だったと述べています。挙げられている理由には、単純さ、セキュリティ、プライバシー、陳腐化、信頼性が含まれます。一方で Cursor は、セマンティック検索を足すと改善すると一次情報で報告しています。方式は用途と規模で分かれます。
• ローカル LLM のツール使用は中型モデルでも実用域に入ってきていますが、ユーザーと協調しながら進める設定では難易度が上がります。量子化は集計スコアを保ったままツール呼び出しの失敗を増やすことがあるので、最終的な成功率だけでなく失敗の種類まで、自分の環境で測る必要があります。
• 精度とコストだけでなく、プロンプトインジェクションとアクセス制御も方式選択の判断材料になります。
• 現実的な着地点は、用途に合った検索・参照の手段を用意したうえで、それをエージェントのツールの一つとして持たせる形だと思います。ベクトル RAG はその選択肢の一つで、全文検索だけで足りる場面もあります。

情報の位置づけについて

この記事で扱った情報の分類をまとめておきます。

分類	内容
一次情報	Anthropic 公式ブログ（Contextual Retrieval、multi-agent research system、context engineering）、Claude Code 公式ドキュメントのツールリファレンス、Latent Space のインタビュー書き起こし、OpenAI（BrowseComp、gpt-oss）、Cursor 公式ブログ、arXiv 論文各種
一次情報だが自己申告値	各モデルのベンチマークスコアのうち、開発元自身が公表しているもの（BFCL v3、τ-bench の値）
一次情報だが社内評価	Anthropic の Contextual Retrieval の失敗率、マルチエージェントの 90.2%、Cursor の 12.5%
測り方が混在している値	強化学習系の改善（相対改善率とポイント差、比較相手が論文ごとに異なる）
二次情報	Hacker News 投稿の引用、個人ベンチによる生成速度、コスト比較の一部、業界動向の調査記事、Claude Code の現行実装に関する解説
筆者の概算	図 11 のローカル所要時間の試算、図 12 の判断フロー、第 15 章のトレードオフ表

ベンチマークの数値は測定条件によって動きますし、集計サイトには未検証の値が混ざっていることもあります。実際に採用を検討する際は、自分の用途に近いデータで測り直すのがよいと思います。

参考資料

情報源を種類別に分けて示します。

公式ドキュメント、公式ブログ

• Anthropic, "Introducing Contextual Retrieval"（2024年9月。取得失敗率 5.7% → 1.9% の社内評価） https://www.anthropic.com/news/contextual-retrieval
• Anthropic, "How we built our multi-agent research system"（2025年6月。90.2%、トークン約15倍、性能のばらつきの要因分析） https://www.anthropic.com/engineering/multi-agent-research-system
• Anthropic, "Effective context engineering for AI agents"（2025年9月。just-in-time な文脈取得） https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Claude Code Docs「Tools reference」（組み込みツールの一覧。Glob、Grep、Read、LSP。索引系のツールは存在しない） https://code.claude.com/docs/en/tools-reference
• OpenAI, "BrowseComp: a benchmark for browsing agents"（2025年4月） https://openai.com/index/browsecomp/
• Cursor, "Improving agent with semantic search"（2025年11月6日。Cursor Context Bench による評価） https://cursor.com/blog/semsearch
• Berkeley Function Calling Leaderboard（BFCL。現行は v4） https://gorilla.cs.berkeley.edu/leaderboard.html

研究論文（検索方式の比較・評価）

• Krishna et al., "Fact, Fetch, and Reason: A Unified Evaluation of Retrieval-Augmented Generation"（FRAMES。NAACL 2025） https://arxiv.org/abs/2409.12941
• Wei et al., "BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents" https://arxiv.org/abs/2504.12516
• Subramanian et al., "Keyword search is all you need: Achieving RAG-Level Performance without vector databases using agentic tool use"（Amazon。AAAI 2026。ベクトルDBなしで RAG の9割超） https://arxiv.org/abs/2602.23368
• Li et al., "Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach"（Self-Route。EMNLP 2024 Industry Track） https://arxiv.org/abs/2407.16833
• Liu et al., "Lost in the Middle: How Language Models Use Long Contexts"（TACL 2024） https://arxiv.org/abs/2307.03172
• Singh et al., "Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG" https://arxiv.org/abs/2501.09136

研究論文（検索を学習させる）

• Jin et al., "Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning"（数値は改訂版準拠） https://arxiv.org/abs/2503.09516
• Song et al., "R1-Searcher: Incentivizing the Search Capability in LLMs via Reinforcement Learning" https://arxiv.org/abs/2503.05592
• Zhao et al., "R-Search: Empowering LLM Reasoning with Search via Multi-Reward Reinforcement Learning" https://arxiv.org/abs/2506.04185

研究論文（ツール使用とローカル実行）

• Barres et al., "τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment"（Telecom ドメイン、双方向制御） https://arxiv.org/abs/2506.07982
• Zeng et al., "GLM-4.5: Agentic, Reasoning, and Coding (ARC) Foundation Models"（BFCL v3、τ-bench の自己申告値） https://arxiv.org/abs/2508.06471
• OpenAI, "gpt-oss-120b & gpt-oss-20b Model Card"（τ-bench の自己申告値） https://arxiv.org/abs/2508.10925
• DeepSeek-AI, "DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models" https://arxiv.org/abs/2512.02556
• "CoreThink: A Symbolic Reasoning Layer to reason over Long Horizon Tasks with LLMs"（BFCL v3 の multi-turn スコアの言及） https://arxiv.org/abs/2509.00971
• Jang et al., "Flat Score, Amplified Failures"（2026年7月。4bit 量子化とツール呼び出しの失敗） https://arxiv.org/abs/2607.27275
• Mekala et al., "Does quantization affect models' performance on long-context tasks?"（EMNLP 2025） https://arxiv.org/abs/2505.20276

一次情報（インタビュー書き起こし）

• Latent Space, "Claude Code: Anthropic's Agent in Your Terminal"（2025年5月。書き起こしがあり、Boris Cherny の発言と「主に体感だった」という補足を原文で確認できます。該当は45分30秒あたり） https://www.latent.space/p/claude-code

二次情報（技術ブログ、業界動向）

• Vadim Nicolai, "Claude Code Doesn't Index Your Codebase. Here's What It Does Instead."（Boris Cherny の Hacker News 投稿の引用を含む） https://vadim.blog/claude-code-no-indexing/
• Milvus Blog「Why I'm Against Claude Code's Grep-Only Retrieval?」（grep 方式への反論と Claude Context の紹介） https://milvus.io/blog/why-im-against-claude-codes-grep-only-retrieval-it-just-burns-too-many-tokens.md
• zilliztech/claude-context（Claude Code にセマンティック検索を足す MCP サーバ） https://github.com/zilliztech/claude-context
• VentureBeat「The retrieval rebuild」（VB Pulse 調査。ハイブリッド検索の採用意向 10.3% → 33.3%）
• ローカル環境での生成速度（tok/s）に関する個人ベンチおよび掲示板の報告（複数、2025〜2026年）

前の記事

• [ローカルLLMで自社専用の「AI税務担当」を作る ─ QLoRAとRAGで税務知識を追加する]

• [ローカルLLMで自社専用の「AI税務担当」を作る（続編）─ RAG深掘り