これは何の論文か
この論文の中心問いは、エージェントが大きな資料群を検索するとき、検索手法だけを比べてよいのか、ということ。普通の検索評価では、grepや BM25 のような文字列検索と、埋め込みを使うベクトル検索を別々に比べがちである。しかし実際のエージェントは、検索結果を受け取り、読み、次の検索語を考え、止めるか続けるかを判断する。その全体は、検索器単体ではなくハーネス込みで動いている。
著者らは、LongMemEval から116問を取り出し、長い会話履歴に対する質問応答で実験している。比較するのは、文字列で狙う grepと、意味の近さで広く拾うベクトル検索。さらに、独自ハーネスの Chronosと、Claude Code、Codex、Gemini CLI のようなプロバイダー製 CLI ハーネスを比べる。
もう一つ重要なのが、検索結果の渡し方である。検索結果をそのまま会話文脈へ入れる直接挿入方式と、結果をファイルに書き出してエージェントに読ませるファイル経由方式を比べている。前者はすぐ読めるが文脈を圧迫する。後者は大きな結果を保持できるが、エージェントがファイルを開いて統合する追加作業を正しくこなす必要がある。
結果は、単純な「grep が勝つ」ではない。Experiment 1の直接挿入条件では、すべてのハーネス・モデルの組み合わせで grep がベクトル検索を上回る。一方で、ファイル経由方式にすると順位が入れ替わる場合があり、Codexと GPT-5.4 の組み合わせではプログラム経由 grep が大きく落ちる。つまり、検索結果の渡し方そのものが別のツール利用課題になる。
読後に残るポイントは、エージェント検索を検索器単体で評価してはいけない、ということ。grepは、会話履歴の中にそのまま残っている日付、好み、発言、数値を拾うには強い。しかし証拠が言い換えられている資料、コード意味理解、視覚資料、科学論文の統合では違う結果になりうる。検索手法、ハーネス、結果の渡し方を一体で見る必要がある。
Is Grep All You Need? は、エージェント検索における grep とベクトル検索を、ハーネスや結果の渡し方込みで比べる実験論文である。
対象は、長い会話履歴から必要な証拠を見つけて質問に答える LongMemEval の一部である。エージェントは、会話履歴や時系列イベントを検索し、証拠を読み、最終回答を作る。
論文の狙いは、検索器単体のランキング性能ではなく、エージェントが検索結果をどう受け取り、どう読み、いつ止めるかまで含めた実行性能を見ることにある。
何が問題だったのか
検索器だけを単体で比べても、エージェント検索の実力は分かりにくい。grep が強いのか、ベクトル検索が強いのかは、結果をどのようにエージェントへ渡し、どのハーネスで読み、どの文脈制約の中で使うかに依存する。
問題は、検索性能が検索器の性質だけで決まらないことだ。inline で結果を渡すのか、ファイルに保存して読むのか、ノイズが増えた時にどのように再検索するのか、ハーネスごとの違いが結果を大きく変える。
この論文が扱う問題は、agentic search を検索アルゴリズム単体ではなく、ツール呼び出し、文脈構成、読み取りループを含むハーネス問題として評価することである。
検索の議論では、grep、BM25、埋め込み検索、意味的検索のどれが強いかが単体で比較されがちである。しかしエージェントがリポジトリや大量文書を読む時、検索器だけで性能が決まるわけではない。検索結果をどう表示するか、どれだけ文脈を圧迫するか、ファイルを開けるか、何度探索できるかが結果を大きく変える。
既存の比較で足りなかったのは、検索器をエージェントハーネスの一部として見る視点である。grep が弱いのか、grep の結果を直接挿入で渡した時に強いのか、ファイル経由にした時に別の検索器が有利になるのかは、ハーネスなしには判断できない。
この論文は、検索手法そのものではなく、検索手法とエージェントハーネスの組み合わせを評価する。つまり「grep で十分か」ではなく、「どのハーネスなら grep が十分になり、どのハーネスでは足りないのか」を問う。
提案手法の中身
実験には、LongMemEval の116問サンプルを使う。質問は、知識更新、複数セッションの統合、ユーザーの好み、ユーザー発言、時間推論などのカテゴリにまたがる。
検索対象は、会話の発話と、Chronos が抽出した時系列イベントである。これに対して、grep は正規表現や文字列一致で検索し、ベクトル検索は埋め込みインデックスを使って意味的に近い記録を返す。
ハーネスは、独自実装の Chronosと、Claude Code、Codex、Gemini CLI を比べる。CLI ハーネスでは、エージェントが grep や検索スクリプトをシェル経由で呼べる。
検索結果の渡し方は二種類ある。直接挿入方式では検索結果がそのまま会話文脈へ入る。ファイル経由方式では検索結果がファイルに書かれ、エージェントはそのファイルを読むか、さらに grep して中身を探す。
評価は、エージェントの最終回答を GPT-4o の採点器で判定する。Experiment 1 は検索手法、ハーネス、結果の渡し方を比較し、Experiment 2 は不要な会話セッションを増やしたときの変化を見る。
どうやって確かめたのか
評価では LongMemEval 116問を使い、Chronos、Claude Code、Codex、Gemini CLI などのエージェントハーネスを比較する。検索方法だけでなく、結果を直接挿入で渡すか、ファイルとして渡すか、エージェントが追加でファイルを開く/読み取るできるかといった条件も見る。
重要なのは、同じ検索器でもハーネスが変わると順位が変わる点である。直接挿入で結果を短く渡すなら grep が強く見える場合がある。一方、ファイル経由方式では、検索結果の保持や再参照のしやすさが変わり、別の設計が有利になる。
この評価により、検索器の単体スコアではなく、エージェントが検索結果をどう使えるかまで含めて比較する必要があることが分かる。
結果はどうだったのか
Experiment 1 では、直接挿入方式に限ると、すべてのハーネス・モデルの組み合わせで grep がベクトル検索を上回った。特に、LongMemEval のように日付、好み、発言、数値などの文字列証拠を拾う課題では、文字列検索が強い。
ただし、同じモデルでもハーネスを変えると結果は大きく変わる
たとえば Claude Opus 4.6は、Chronosの直接挿入 grepで 93.1% だが、Claude Codeの直接挿入 grep では 76.7% になる。これは、検索器だけでなく、プロンプト、ツール説明、出力整形、停止判断が効いていることを示している。
ファイル経由方式にすると、grep とベクトル検索の順位は一部で入れ替わる
特に Codexと GPT-5.4 の組み合わせでは、直接挿入 grepが 93.1% なのに、プログラム経由 grepは 55.2% まで落ちる。検索が安くても、結果ファイルを開いて統合するループが不安定だと性能は崩れる。
Experiment 2 では、関係ない会話セッションを増やしても性能は単純に右肩下がりにはならない。ある設定ではベクトル検索が強く、別の設定では grep が追いつく。ノイズ量だけでなく、どのハーネスで、どのモデルが、どんな検索語を作るかが効いている。
論文の結論は、grep が常にベクトル検索に勝つという主張ではない
むしろ、文字列証拠が残る会話履歴では grep が強い一方、エージェント検索の性能は検索手法、ハーネス、結果の渡し方の三つで決まる、という主張である。
限界・注意点
- この結果は、長い会話履歴に対する質問応答に強く結びついている。答えの根拠がそのままの文字列として残っている課題では grep が有利になりやすい。
- 科学論文の統合、コードの意味理解、画像や表を含む資料、言い換えが多い文書では、ベクトル検索やハイブリッド検索の見え方は変わる可能性がある。
- 実験は特定のモデル、特定の CLI ハーネス、特定の実装で行われている。プロバイダー側のハーネスは内部実装が完全には見えないため、差の原因をすべて分解できるわけではない。
- Codex の一部のスケーリング行は未完であり、すべてのベンダーについて完全に対称な比較ができているわけではない。
おい丸のようなエージェントにどう使えるか
おい丸のような作業支援エージェントでは、wiki、ブログ、コード、ログを頻繁に探す。ここで大事なのは、高級な検索器を入れることだけではない。検索結果をどの粒度で見せるか、必要なら元ファイルへ戻れるか、検索ログを残すか、文脈を圧迫しないかが使い勝手を決める。
たとえば、短い確認なら grep 的な文字列検索で十分なことが多い。一方、長い調査や複数資料の統合では、検索結果をファイル化し、参照IDを保ち、後から open できるハーネスが効く。
この論文は、検索改善を「ベクトルDBを足す」だけで考えないための警告になる。エージェント型検索の性能は、検索器、ツール出力、ファイルアクセス、文脈予算、停止判断をまとめた設計で決まる。
Q&A
この論文の中心問いは？
エージェント検索の性能は、grep かベクトル検索かだけで決まるのか。それとも、ハーネスや検索結果の渡し方まで含めて決まるのか。
なぜ grep が注目されているの？
CLI エージェントでは grepやシェルが自然に使え、日付や発言のような文字列証拠を直接探す課題では非常に強いから。
ベクトル検索は弱いという結論？
そうではない。会話履歴のように文字列証拠が残る課題では grep が強く出たが、言い換えや意味理解が重要な領域では結果が変わりうる。
grep はキーワード検索と何が違う？
grep は広い意味ではキーワード検索側だが、BM25 のように文書頻度や長さでランキングする検索エンジン型ではない。この論文の主比較は grep とベクトル検索であり、BM25やハイブリッド検索まで含めた結論ではない。
grep とベクトル検索は一発検索として比べているの？
一発検索のランキング比較ではない。エージェントが検索語を作り、ツールを呼び、結果を読み、必要なら追加検索して最終回答する実行ループ込みで比べている。
grep はファイル名だけを探している？
本文の説明では違う。grep ツールは質問ごとのファイルから会話ターンと Chronos が抽出した時系列イベントを読み込み、生テキスト欄に対して正規表現・文字列一致を行う。
ベクトル検索はファイル名もベクトル化している？
論文本文で明示されているのは、各会話ターンと時系列イベントを埋め込みして質問ごとのインデックスに保存すること。ファイル名や session 名を埋め込み text に混ぜたかは、本文だけでは十分に分からない。
ファイル名やメタデータの作り方で結果は変わりそう？
かなり変わりうる。ファイル名、セッションID、タイムスタンプ、正解/ノイズが推測できる情報、チャンクスキーマ、メタデータの露出範囲は、grep とベクトル検索の両方に影響する。論文はこの点を十分に分解評価しているわけではない。
ハーネスとは何？
エージェントを動かす実行環境のこと。プロンプト、ツール呼び出し、文脈構成、検索結果の整形、停止判断などを管理する。
直接挿入方式とは？
検索結果をそのまま会話文脈へ入れる方式。すぐ読めるが、結果が大きいと文脈を圧迫する。
ファイル経由方式とは？
検索結果をファイルに保存し、エージェントが必要に応じてファイルを読む方式。文脈圧迫は避けられるが、読み取りと統合の追加作業が発生する。
一番重要な結果は？
直接挿入条件では grep がすべての組み合わせでベクトル検索を上回った一方、ファイル経由条件では順位が入れ替わることがあり、ハーネス差も大きかったこと。
Codex の結果で面白い点は？
GPT-5.4と Codex CLI では、直接挿入 grepが 93.1% と強い一方、プログラム経由 grepは 55.2% まで落ちた。検索自体より、結果ファイルを扱うループが効いている可能性がある。
この論文を実務に使うなら？
検索器だけを差し替えるのではなく、検索結果の表示、ファイル化、ツール説明、grep / 読み取り / シェルの使わせ方をまとめて設計・評価する。
一言でいうと？
エージェント検索は、検索器単体の勝負ではない。検索手法、ハーネス、結果の渡し方が一緒に性能を作る。
関連する記事
- この論文は、コーパスを直接歩く検索エージェント の次に読むとよい。資料庫を直接歩くという発想に、ハーネスと結果の渡し方という実装面の条件を足してくれる。
- エージェントの行動ログをどう読むか と並べると、検索結果だけでなく、エージェントがどう検索し、どう読んで、どこで止めたかを行動として観察する必要が見えてくる。
- 実務に引くなら、wikiや repo の探索で、検索器を変える前に、検索結果を文脈へ入れるのか、ファイルとして読ませるのか、grep / file 読み取り / シェルをどう許すのかを点検するとよい。