Claude Code のようなコーディングエージェントに「リトライの上限はどこで決めている？」と聞くと、エージェントは自分で grep を打ち、候補のファイルを開いて答えを探します。
あらかじめ文書をベクトルにしておき、質問に近いものを引いて渡す RAG とは、探す順番がまるで違うやり方です。
このように、モデルが道具を繰り返し呼んで自分で情報を探す方式を、エージェント型検索（agentic search）と呼びます。
Anthropic は Claude Code の初期に RAG を試したうえでこの方式に落ち着き、一方の Cursor は埋め込み検索を足したほうが正答率が上がったと報告しています。
両者の言い分を並べると、自分のコードやメモを AI に探させるときに索引を用意すべきかどうか、判断の材料がそろいます。
エージェント型検索は探す手順ごとモデルに任せる方式
基本の形の RAG では、質問が来た時点で検索の仕組みが候補を選び、その結果をまとめてモデルに渡します。
モデルが目にするのは選ばれた数件だけで、検索のやり直しには関わりません。
エージェント型検索では、何で検索し、どれを開き、もう一度探すかをモデル自身が決めます。
Anthropic は 2025年9月29日のエンジニアリングブログ Effective context engineering for AI agents で、これを「just in time」の取得と呼んでいます。
データを先に全部処理しておく代わりに、ファイルパスや保存したクエリのような軽い手がかりだけを持っておきます。
そして必要になった時点で、道具を使って中身を読み込むという説明でした。
人も情報を丸ごと覚えるのではなく、フォルダやブックマークのような整理の仕組みを頼りに必要なときに取り出している、と同記事は人の認知になぞらえていました。
以下は、エージェント型検索の 1 周を書き下した擬似コードです。
# 擬似コード:「リトライの上限は？」を探す 1 周
Grep "retry|リトライ|backoff" -> 候補ファイルのパス 6 件
Read docs/retry-policy.md -> 上限の記述なし
Grep "max_attempts"（対象は *.py） -> 2 件
Read src/client.py -> 上限 5 回の定義を見つけて回答1 回目で外れても、モデルが結果を読んで検索語を変え、次の一手を選び直せるところがこの方式の持ち味です。
二つの方式を並べると、次の表のようになります。
| 観点 | RAG（埋め込み検索） | エージェント型検索 |
|---|---|---|
| 事前の準備 | 文書を分けてベクトル化し、索引を作る | 要らない（ファイルがあればよい） |
| 検索語を決めるのは | 質問文そのもの、または前処理 | モデル |
| 探す回数 | 1 回で候補を返す | 足りなければ何度でも |
| 速さ | 速い | 遅い（道具を何往復も呼ぶ） |
| 情報の鮮度 | 索引を作り直すまで古いまま | いまのファイルをそのまま読む |
| 言い換えへの強さ | 意味の近さで拾える | モデルが類語を足して補う |
事前に索引を作って引く RAG の基本の流れは、別の記事で整理しました。
Claude Code は CLAUDE.md を先に読み、残りを grep で探す
Claude Code の公式ドキュメント「How Claude Code works」は、作業の流れを「文脈を集める・手を動かす・結果を確かめる」の 3 段の繰り返しとして説明しています。
文脈を集める段で使われるのが、ファイル名のパターンで探す Glob、ファイルの中身を正規表現で探す Grep、ファイルを開く Read といった道具です。
2026年10月時点の ツールの一覧（Tools available to Claude） によると、Grep は ripgrep の上に作られていて、既定ではヒットしたファイルのパスだけを返します。
Glob の結果は更新日時の順に並び、上限は 100 件です。
パスを先に受け取ってから、どれを開くかをモデルが選ぶので、関係の薄いファイルの中身で文脈を埋めずに済みます。
なお同じページによると、macOS・Linux・WSL では Glob と Grep が既定の道具から外れ、Bash 経由の find と grep で探す扱いになっていました。
先の Anthropic の記事は、Claude Code を二つの方式を混ぜた「ハイブリッド」の例として挙げています。
CLAUDE.md は最初から文脈に入れておき、それ以外のファイルは glob や grep でその都度取りに行くという分担です。
この分担で、古くなった索引の問題や複雑な構文木の扱いを避けられる、と同記事は書いていました。
探す作業そのものをサブエージェントに預ける道もあります。
公式ドキュメントのサブエージェントのページによると、組み込みの Explore は書き込みのできない探索専用のエージェントで、探した結果をメインの会話に持ち込まないために使われます。
Anthropic が索引より道具での検索を選んだ理由
Claude Code のリードエンジニアとして出演した Boris Cherny 氏は、2025年5月7日公開のポッドキャスト Latent Space で、ごく初期の版は RAG を使っていたと話しています。
Voyage の埋め込みでコードベースに索引を張る、既製の RAG だったそうです。
いくつかの検索の道具を試した末に glob や grep で探させる方式へ落ち着いた理由として、同氏は次の三つを挙げていました。
- 性能: ほかの方式を大きく上回った。ただし根拠は社内のベンチマークも一部あるものの、主に使った感触だったと本人が断っている
- 鮮度: 索引を作る工程が要り、コードが変わると索引とずれていく
- 安全: 索引をどこかに置く必要があり、機密性の高いコードを外部に預ける負担を抱える
その代わりに待ち時間とトークンを多く払うことになる点も、同氏は認めていました。
同じ考え方は、Anthropic が 2025年9月29日に公開した Building agents with the Claude Agent SDK にも書かれています。
埋め込みを使う意味検索はエージェント型検索より速いことが多い一方で、正確さ、保守のしやすさ、中身の見通しでは劣る、という整理です。
そのうえで、まずエージェント型検索から始め、速さや言い換えの幅が必要になったときだけ意味検索を足すよう勧めていました。
埋め込み検索を足して良くなった例もある
反対側の報告として、Cursor は 2025年11月6日のブログ Improving agent with semantic search で、意味検索の効果を数字で示しています。
自社の評価用データ Cursor Context Bench では、grep などに加えて意味検索を使えるようにすると、質問への正答率が平均で 12.5%、モデルごとには 6.5〜23.5% 上がったそうです。
利用者を二つに分けた A/B テストでも、エージェントが書いたコードが残る割合は 0.3% 上がり、1,000 ファイル以上の大きなコードベースでは 2.6% 上がりました。
意味検索を外した側では、不満を示す追加の依頼が 2.2% 増えたとしています。
Cursor の結論は、grep と意味検索を組み合わせたときに最も良い結果が出る、というものでした。
ただし Cursor は、エージェントが実際に探し回った記録を使って自前の埋め込みモデルを学習させていて、市販のモデルをそのまま使う場合とは条件が違います。
もう少し小さな規模では、Zenn に 2026年10月4日に投稿された 個人の計測記事 が参考になります。
書き手が溜めてきた 104 本の Markdown ノートに 20 問を用意し、正解のノートが検索結果の上位 5 件に入る割合を、まず検索の仕組みだけで比べたものです。
| 検索の仕組み（単体） | 上位 5 件に正解が入る割合 |
|---|---|
| grep（キーワードで検索） | 0.666 |
| BM25（キーワードで検索） | 0.402 |
| 日本語向けの埋め込み ruri-v3-310m（質問文で検索） | 0.941 |
検索の仕組みだけで比べると、同義語や日英の表記ゆれで grep が取りこぼし、埋め込みがはっきり勝っています。
ところが Claude Code の claude -p に「grep で探して」「埋め込みで探して」と指示を分けて解かせると、結果は変わりました。
10 問を 3 通りの指示（grep・埋め込み・両方の併用）と 4 つのモデルで解かせた計 120 回で、正解のノートを読めた割合は grep が 0.99、埋め込みが 0.95 と、ほとんど差が出ていません。
記録を見ると、grep を指示されたエージェントは リトライ|retry|backoff のように日英の類語を OR でつないで投げ、README の索引も読んで当たりを付けていたそうです。
検索の仕組みが落とした言い換えを、モデルの側が検索語の工夫で拾っていたことになります。
検索の仕組み単体の点数と、エージェントに使わせたときの到達率は別物だと分かる結果でした。
差が出たのは費用のほうで、埋め込みを指示した回は grep の回の 0.35〜0.53 倍で済んでいます。
grep の回は毎回およそ 29KB の README の索引を読んでいて、これが費用の差の主な原因だったとされています。
計測した本人も、104 ノートの結果は一般化できないこと、判定は正解のノートを開いたかどうかで答えの正しさまでは見ていないことを断っていました。
どちらを選ぶかは量と変わりやすさで決まる
ここまでの一次情報を並べると、選び方の目安はおおよそ三つに分かれます。
全部渡せる量なら探さなくてよい
Anthropic は 2024年9月の Contextual Retrieval の記事 で、知識が 20 万トークン（約 500 ページ）より小さければ、検索を挟まずに全部をプロンプトに入れてよいと書いています。
毎回同じ文書を渡すならプロンプトキャッシュで速さと費用の負担を抑えられる、というのが同記事の補足でした。
数字は当時のモデルを前提にしたものですが、小さいなら探さずに渡すという順番はいまも変わりません。
変わりやすいものや外に出せないものは道具で探させる
コードのように毎日変わるものには、索引を作り直す手間と、索引がずれる危険がついて回ります。
社外に預けられない文書では、索引を置く場所そのものが悩みの種になります。
埋め込みを手元で計算すれば外に預けずに済みますが、作り直しの手間までは消せません。
この二つに当てはまるなら、いまのファイルをその場で読むエージェント型検索のほうが合っています。
量が多く言い換えが多いなら埋め込みを足す
1,000 ファイルを超えるようなコードベースや、同じことを違う言葉で書いた文書が多い場面では、意味検索を足す価値が出てきます。
速さや言い換えの幅が要るときに足す、という Anthropic の勧めとも食い違いません。
Zenn の計測のように、届く割合は同じでも費用が半分前後に下がるという効き方もあります。
Anthropic は、法務や金融のように中身が変わりにくい文書では、一部を先に渡してから自律的に探させるハイブリッドが合うかもしれない、とも書いていました。
エージェント型検索の落とし穴
便利な反面、エージェント型検索には決まった弱点があります。
遅く、トークンを食う
道具を何往復も呼ぶぶん、計算済みの結果を引く方式より時間がかかることは、Anthropic 自身が認めています。
Zenn の計測でも、grep の回は索引の読み直しで入力トークンが膨らんでいました。
手がかりが弱いと迷子になる
先の Anthropic の記事は、道具の渡し方や手がかりが足りないと、エージェントが道具を使い損ねたり行き止まりを追いかけたりして、文脈を無駄にすると注意しています。
エージェントはファイル名やフォルダの並び、更新日時を手がかりに探します。
同じ test_utils.py でも、tests フォルダにあるか src/core_logic にあるかで役割が違って見える、という例も挙がっていました。
Agent SDK の記事が、フォルダとファイルの構成そのものがコンテキストエンジニアリングの一部になると書いているのも同じ話です。
埋め込み検索は「無い」と言えない
組み合わせるときに見落としやすいのが、埋め込み検索は必ず何かしらの候補を返すことです。
Zenn の計測では、答えが無い問いと言い換えの問いの正解とで類似度の数値が重なり、数値だけでは「該当なし」を判定できなかったそうです。
候補の説明を読んで「無い」と答えられたのはエージェントの側で、類似度の高さだけで答えの有無を決めない作りが要ります。
数字は自分のデータで測り直す
ここで引いた数字は、Cursor が自社の評価、Zenn が個人の 104 ノート、Anthropic の判断は主に社内の感触と、どれも条件がばらばらです。
答えの分かっている問いを 20 問ほど用意して両方を試せば、自分の手元でどちらが効くかを確かめられます。
最後に
エージェント型検索は、検索語を決め、結果を読み、足りなければ探し直すところまでをモデルに任せる方式でした。
事前に索引を作る RAG より遅くトークンも食う代わりに、索引の鮮度や置き場所に悩まずに済みます。
Claude Code は CLAUDE.md を先に読ませて残りを grep で探すハイブリッドで、Cursor は grep と意味検索を組み合わせています。
モデルの前に何を並べるかという考え方そのものは、コンテキストエンジニアリングの記事で整理しています。
二択で考えるより、まず道具で探させ、遅さや費用が気になってから索引を足すという順番で考えると、迷いにくいでしょう。
以上です。
コメントを残す