{"notes":[{"id":"retrieval-augmented-generation/is-grep-all-you-need","category":"retrieval-augmented-generation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Is Grep All You Need","subtitle":"Grepだけで十分？","author":"Z. Yuan","paperDate":"2026-05-14","publishedOn":"2026-08-29","paperTitle":"Is Grep All You Need? How Agent Harnesses Reshape Agentic Search","paperUrl":"https://arxiv.org/abs/2605.15184","bibliography":{"title":"Is Grep All You Need? How Agent Harnesses Reshape Agentic Search","authors":["Sahil Sen","Akhil Kasturi","Elias Lumer","Anmol Gulati","Vamse Kumar Subbiah"],"url":"https://arxiv.org/abs/2605.15184","pdfUrl":"https://arxiv.org/pdf/2605.15184v1","codeUrl":null,"preprint":{"id":"2605.15184","submittedOn":"2026-05-14","url":"https://arxiv.org/abs/2605.15184"},"publication":null,"citation":"@misc{retrievalaugmentedgenerationisgrepallyouneed2026,\n  title = {{Is Grep All You Need? How Agent Harnesses Reshape Agentic Search}},\n  author = {Sahil Sen and Akhil Kasturi and Elias Lumer and Anmol Gulati and Vamse Kumar Subbiah},\n  year = {2026},\n  eprint = {2605.15184},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2605.15184}\n}\n","citationPath":"/content/papers/citations/retrieval-augmented-generation/is-grep-all-you-need.4ebb3c804df8.bib"},"thumbnail":{"src":"/content/papers/assets/7388f9c6a8dfcf342dfed65f8f8c3d27d2ffbbf3d5dfb51aeb45005be29a2c00.png","width":944,"height":422},"locale":"ja","path":"/content/papers/ja/retrieval-augmented-generation/is-grep-all-you-need.91ccba709022.md","headings":[{"id":"問題の定義","text":"問題の定義","depth":2},{"id":"問題の解決","text":"問題の解決","depth":2},{"id":"タスク長い会話から記憶を取り戻す","text":"タスク：長い会話から記憶を取り戻す","depth":3},{"id":"2種類の検索ツール","text":"2種類の検索ツール","depth":3},{"id":"4種類のharness","text":"4種類のharness","depth":3},{"id":"結果を渡す2つの方法","text":"結果を渡す2つの方法","depth":3},{"id":"モデルと採点","text":"モデルと採点","depth":3},{"id":"議論","text":"議論","depth":2},{"id":"実験1grepharness結果の渡し方","text":"実験1：grep、harness、結果の渡し方","depth":3},{"id":"実験2妨害情報が増えるとどうなる","text":"実験2：妨害情報が増えるとどうなる？","depth":3},{"id":"2つの実験で数値が合わない","text":"2つの実験で数値が合わない","depth":3},{"id":"著者自身が示した適用範囲","text":"著者自身が示した適用範囲","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"ここ2年ほどでClaude Code、Codex、Gemini CLIを使った人なら、こんな場面を見たことがあるはずです。コードについて質問すると、まず`grep`をいくつも走らせ、ファイルをいくつか読んでから、答えを返してくれます。\n\nこれは、ここ数年のRAGの定石とは少し違います。当時の標準は、文書をチャンクに分け、ベクトルに変換してベクトルデータベースへ保存し、意味的な類似度で探すことでした。\n\nそこで、多くの人が考え始めました。agentが自分でgrepできるなら、ベクトル検索はまだ必要なのか？\n\n今回読むのは、米国のPwCから2026年5月にarXivへ投稿されたプレプリントです。タイトルは「grepで十分か」と問いかけています。ただ、読み進めると、著者が実際に測っているものが見えてきます。**同じ検索ツールでも、それを包むagentの仕組みが変わると、性能は大きく変わる。**\n\n\n> [!TIP]\n> \n> **Harnessとは？**\n> \n> 論文に繰り返し登場する**agent harness**は、「モデルの外側を包むプログラム」と考えるとわかりやすいでしょう。モデルにどのツールを渡すか、システムプロンプトをどう書くか、ツールの結果をどんな形式で返すか、いつ処理を止めるかを決めます。\n> \n> 同じClaude Opus 4.6でも、Claude Codeの中で動かす場合と、自分でLangChainを使って組んだagentの中で動かす場合とでは、harnessが異なります。モデルが同じでも、与えられるプロンプト、ツールの説明、結果の形式が変わります。\n\n\n## 問題の定義\n\n著者によると、従来の検索手法の比較では、固定されたパイプラインが想定されることが多くありました。検索器が文書を探し、プロンプトへつなぎ込み、モデルが答える、という流れです。\n\n一方、agentは検索結果をもう少し能動的に使います。何を検索するか、何回検索するか、結果は十分かを自分で決め、足りなければキーワードを変えて探し直します。こうした振る舞いは、すべてharnessの影響を受けます。\n\nそこで著者は、次の3つを調べます。\n\n1. **harnessが異なるとき、grepとベクトル検索のどちらが優れるのか？**\n2. **ツールの結果を会話へ直接入れる場合と、ファイルに書き出してagent自身に読ませる場合とで、結論は変わるか？**\n3. **無関係なデータが増えるにつれ、両者の性能はどう変化するか？**\n\n## 問題の解決\n\n### タスク：長い会話から記憶を取り戻す\n\n評価にはLongMemEvalの116問からなる部分集合を使います。\n\nLongMemEvalが測るのは、長期間の会話を記憶する能力です。各問題には大量の会話履歴（session）が付いており、そのうち1つ、あるいはいくつかのsessionに答えが隠れています。残りは無関係な妨害情報です。問題は6種類に分かれます。\n\n| 種類 | 測るもの |\n| --- | --- |\n| knowledge-update | 時間とともに変わる状態の追跡 |\n| multi-session | 複数の会話にまたがる情報の集約 |\n| single-session-assistant | アシスタント自身が話した内容の想起 |\n| single-session-preference | ユーザー個人の好み |\n| single-session-user | ユーザーが述べた事実 |\n| temporal-reasoning | 期間の計算、出来事の順序付け、日付の推定 |\n\nこの記事で作った例を挙げると、「前に転職したのは何か月前？」という問題です。答えは、数十件の会話履歴のどこかの一文に埋まっています。\n\n著者はさらに、以前提案したChronosの前処理を使い、会話中の日付や期間を構造化されたイベント記録に変換します。そして、元の会話と一緒に、問題ごとのファイルへ保存します。今回測りたいのは「証拠を見つけられるか」であり、断片的な会話から日付を推論する能力は切り分ける、という理由です。\n\n### 2種類の検索ツール\n\n**grep**：各問題の会話とイベント記録をメモリに読み込み、正規表現で原文を直接照合し、ヒット数で並べます。embeddingモデルも、ベクトル索引も、外部サービスも必要ありません。\n\n**ベクトル検索**：会話の各ターンと各イベントをあらかじめembeddingに変換し、問題ごとの索引に保存します。検索時には質問をベクトルに変換し、近似最近傍探索で候補を見つけ、rerankを行って上位$k$件を返します。$k$はagent自身が決めます。\n\n論文には、使用したembeddingモデルとrerankerの名前が記載されていません。\n\n### 4種類のharness\n\n- **Chronos**：著者がLangChainで作ったagentです。会話とイベントそれぞれにgrep版とベクトル版があり、計4つの検索ツールを実験設定に応じて有効・無効にします。システムプロンプトも問題の種類に応じて動的に調整され、時間推論の問題と好みの問題では異なる指示が使われます。\n- **Claude Code**、**Codex CLI**、**Gemini CLI**：各モデル提供元のコマンドラインagentです。著者は問題と動的に生成した検索方針を与え、bash経由で、ラップしたgrepまたはベクトル検索のスクリプトを呼び出させます。\n\n\n> [!NOTE]\n> \n> **設定で気になる点**\n> \n> 論文§3.3.1の説明では、Chronosは各問題の開始時に、まず「ベクトル検索の上位15件」を初期コンテキストとして入れてから、ツール呼び出しのループへ進みます。grep-only設定で、この手順も取り除いたかどうかは書かれていません。Chronosのgrepの成績は、この点も踏まえて読む必要があります。\n\n\n### 結果を渡す2つの方法\n\n- **Inline（標準）**：検索結果を標準出力へ直接出すか、ツール応答として会話へ挿入します。モデルはすぐに読めますが、結果が多いとコンテキストを圧迫します。\n- **Programmatic（ファイル方式）**：検索結果をファイルへ書き出し、モデルには場所だけを渡します。モデルは別のツール呼び出しで、そのファイルを読んだりgrepしたりする必要があります。大量の結果でコンテキストが埋まるのを防げる一方、操作が1段階増えます。\n\n### モデルと採点\n\n評価対象は、Claude Opus 4.6、Claude Haiku 4.5、GPT-5.4、Gemini 3.1 Pro、Gemini 3.1 Flash-Liteの5モデルです。\n\n採点はLongMemEvalの方式に従い、GPT-4oを判定役に使います。問題、正解、agentの回答を見せ、正しいか間違っているかを判定させます。\n\n## 議論\n\n### 実験1：grep、harness、結果の渡し方\n\n[![原論文Table 1：5モデルをChronosと各社CLIで動かし、grepとベクトル検索をinline・programmaticの2方式で比較した正答率](/content/papers/assets/7388f9c6a8dfcf342dfed65f8f8c3d27d2ffbbf3d5dfb51aeb45005be29a2c00.png)](/content/papers/assets/7388f9c6a8dfcf342dfed65f8f8c3d27d2ffbbf3d5dfb51aeb45005be29a2c00.png)\n\n*原論文Table 1。[**v1 PDFの5ページ目**](https://arxiv.org/pdf/2605.15184v1#page=5)より。CC BY 4.0。116問、妨害データは全件。最初の2列がinline、後ろの2列がprogrammaticです。*\n\n各行でモデルとharnessの組み合わせを固定し、4つの列に、検索2種類×受け渡し2種類の結果を並べています。\n\n**まず最初の2列（inline）を見ます。**10組すべてでgrepがベクトル検索を上回りました。差が最大なのはChronos＋Gemini 3.1 Flash-Liteの86.2%対62.9%。最小はClaude Code＋Claude Opus 4.6の76.7%対75.0%です。\n\n**次に、同じモデルを別のharnessで動かした結果です。**Claude Opus 4.6のinline grepは、Chronosでは93.1%、Claude Codeでは76.7%で、16.4ポイントの差があります。同じChronos内でのgrepとベクトルの差は9.5ポイントです。harnessを変えた影響は、検索手法を変える影響に並び、場合によっては上回ります。\n\n**最後に後ろの2列（programmatic）です。**ファイル方式にすると、10組のうち5組でベクトル検索がgrepを逆転しました。特に大きく変わったのがCodex CLI＋GPT-5.4です。inline grepでは最高値タイの93.1%でしたが、programmaticではgrepが55.2%に落ち、ベクトルも67.2%にとどまりました。\n\n著者は、次の2点から結果を解釈しています。\n\n1. **LongMemEvalでは字面の証拠が効く。**正確な日付、回数、好み、元の発言といった文字列は、トークン化の前後でも安定しています。grepならembeddingを経由せず、そのまま見つけられます。\n2. **ファイル方式ではタスクが難しくなる。**「ツールが返したメッセージを読む」という操作が、「ファイルを見つけ、開き、内容を統合する」へ変わります。増えた操作が不安定だと、検索品質とは別の理由で正答率が崩れることがあります。\n\n\n> [!TIP]\n> \n> **116問で、1問の差はどれくらい？**\n> \n> 1問は$1/116\\approx0.86$ポイントに相当します。\n> \n> Claude Code＋Opusの76.7%対75.0%を問題数に戻すと、89問対87問。差は2問です。論文では各設定を1回ずつ実行したように読め、ばらつきの範囲も報告されていません。数問の差に、大きな意味を持たせすぎないほうがよさそうです。\n\n\n### 実験2：妨害情報が増えるとどうなる？\n\n2つ目の実験では、各問題で読めるsession数を5、10、20、30、そして全件の39〜66に変えます。答えを含むsessionは必ず残し、残りの枠を同じ問題の妨害sessionで埋めます。\n\nよくある直感は、データが少なければgrepで足り、多くなったら意味検索が必要になる、というものです。\n\n結果は、もう少し入り組んでいました。\n\n- **曲線は単調に変化しない。**たとえばChronos＋Opusのgrepは、s20の90.5%からs30の85.3%へ下がり、全件では89.7%へ戻ります。\n- **データが少ないと、むしろベクトルが良い場合が多い。**s5でのChronosは、grepが83.2〜89.7%、ベクトルが87.9〜94.0%です。\n- **優劣はharnessによって変わる。**Claude Code＋OpusまたはHaikuでは、全設定でgrepが優位です。一方、Gemini CLI＋Gemini 3.1 Proでは全設定でベクトルが優位で、全件では89.7%対78.5%まで開きます。Chronosは設定によって勝者が入れ替わります。\n\n著者は、session数の上限を変えるたびに、妨害sessionを抽出し直している点も指摘しています。「30件のほうが20件より簡単」と見える途中の上下は、その回に引いた妨害情報がたまたま扱いやすかった可能性があります。これらの曲線を読むときは、各回のランダムサンプリングの影響も考慮する必要があります。\n\n### 2つの実験で数値が合わない\n\nこの論文を読むうえで、特に注意したい点があります。\n\n実験1と実験2の「全件」設定は、同じ116問、同じ妨害データ、同じinline方式に見えるのに、数値が大きく異なります。\n\n| モデルとharness | 検索 | 実験1（Table 1） | 実験2のfull（Table 2、3） |\n| --- | --- | ---: | ---: |\n| Opus＋Claude Code | grep | 76.7 | 94.0 |\n| Haiku＋Claude Code | grep | 55.2 | 81.9 |\n| Opus＋Chronos | ベクトル | 83.6 | 92.2 |\n| Gemini 3.1 Pro＋Gemini CLI | grep／ベクトル | 81.9／75.0 | 78.5／89.7 |\n\n最後の行では勝敗まで逆転しています。実験1ではgrepが勝ち、実験2ではベクトルが勝っています。両実験の設定がどこで異なるのか、論文には説明がありません。実験2はCodexの行も欠けており、著者自身が追記予定としています。\n\nしたがって、結論にある「grepは一貫してベクトルより正確」という記述が厳密に成り立つのは、実験1のinline設定です。\n\n### 著者自身が示した適用範囲\n\n著者は制約の節で、結果の対象を長期会話記憶の質問応答に明確に限定しています。この種の問題では、証拠が原文の一文として残っていることが多く、字面の照合に有利です。科学文献の内容を言い換えた要約、画像が多い文書、コードの意味など、証拠が同じ表現で現れにくい領域では、結果が変わる可能性があります。\n\n著者の主張は、**今回調べたタスクとコーパスでは、grepがエンドツーエンドの比較で勝てる**、という範囲にとどまります。検索全般の優劣は、この実験の対象外です。\n\n## 結論\n\nタイトルの「grepで十分か」への答えは、**このタスクと設定では、十分な場合が多い。ただし、誰がどう使うかによる**、となります。\n\n1. **Inlineでは、grepが10組すべてで勝つ。**長い会話の記憶には、そのまま検索できる文字列の証拠が多く、grepの得意分野に合っています。\n2. **Harnessの影響は検索手法と同じくらい大きい。**同じClaude Opus 4.6でも、自作harnessとClaude Codeでは16.4ポイントの差がありました。\n3. **ファイル方式にすると勝敗が入れ替わる。**Codex＋GPT-5.4のgrepは93.1%から55.2%へ落ち、10組のうち5組でベクトルが優位になりました。\n4. **妨害情報が増えたときの勝者は固定されない。**両者の優劣は、harness、モデル、サンプリングによって変わります。\n\n116問、各設定1回の実行、名前の記載がないベクトルモデルに基づく結果で、実験間で合わない数値もあります。自分で検証する価値のある方向として受け取り、確定した結論として扱うのは控えたいところです。\n\n著者は結論に、実用的な一文を残しています。検索の仕組み、harnessの制御、結果を渡す経路を、ひとつのシステムとして評価すべきだ、というものです。\n\ngrepとベクトルを比較するなら、自分のagentの中で比べるのがよさそうです。\n","imageSizes":{"/content/papers/assets/7388f9c6a8dfcf342dfed65f8f8c3d27d2ffbbf3d5dfb51aeb45005be29a2c00.png":{"width":944,"height":422}}}