Sahil Senら5名の研究チームが2026年5月に公開したarXiv論文が、Claude Code・OpenAI Codex CLI・Google Gemini CLIという3つのAIエージェントハーネスを使った実証実験で「古典的なgrep（パターンマッチング）がベクトル検索を多くの場面で上回る」ことを示し、RAG設計の常識に一石を投じている。

RAGの「常識」に疑問を投げかけた研究

近年のLLMエージェント開発において、検索拡張生成（RAG: Retrieval-Augmented Generation）はほぼ標準アーキテクチャとなっており、「精度の高い検索にはベクトルデータベース（セマンティック検索）が必要」というのが暗黙の常識になっていた。

しかしこの論文は、「実際のエージェントループの中でどちらが機能するか」という実務的な問いに正面から取り組み、その前提を揺さぶる結果を示している。

実験の設計：2段階で公平に比較する

研究では2段階の実験が行われた。

実験1：LongMemEvalでの直接比較

長期対話履歴の記憶能力を評価するベンチマーク「LongMemEval」から116問をサンプリング。独自ハーネス「Chronos」を加えた4環境で、grepとベクトル検索の正答率を比較した。注目すべきは、ツール呼び出し結果の「提示方法」も変数に組み込んだ点だ。LLMがツール結果をプロンプトに直接受け取るインライン方式と、ファイルとして書き出してLLMが別途読み込むファイルベース方式の両方をテストしている。

実験2：ノイズ耐性のテスト

実際のユースケースでは、関連情報が大量の無関係なコンテキストに埋もれることが多い。実験2では無関係な会話履歴を段階的に増やし、両手法のノイズ耐性を定量的に比較した。

主要な発見：ハーネスが検索アルゴリズムを超える

発見1：grepの優位性

4ハーネスを通じて、grepはベクトル検索より高い精度を示した。LLMが出力したクエリに対して、ベクトル空間での近似マッチングよりも文字列の確実な一致・部分一致の方が信頼性が高かったのだ。

発見2：ハーネス設計が精度を決定する

より重要な発見は「同じ会話データ・同じ検索アルゴリズムを使っても、どのハーネスを使うかで精度が大きく変わる」という事実だ。Claude Code、Codex CLI、Gemini CLI、Chronos、それぞれで同じデータに対して異なるスコアが出た。ツール結果の提示方法（インライン vs ファイルベース）もスコアを動かす変数となった。

日本のIT現場への影響

RAGパイプラインのコスト再考：ベクトルデータベースの導入・運用には相当なコストと複雑性が伴う。コードベース、ドキュメント、ログのような構造化コーパスを扱うシステムでは、grepを基盤にしたシンプルな設計も十分に選択肢に入る。

「どう検索するか」より「どうループを回すか」：検索アルゴリズムの最適化より先に、エージェントアーキテクチャ全体の設計に注力すべきだという優先順位の転換を、この研究は示唆している。

ツール結果の渡し方が性能を変える：インライン vs ファイルベースという設計判断が精度に影響するという発見は、エージェント開発における「プロンプトの渡し方」の重要性を改めて浮き彫りにする。

筆者の見解

この論文の結論は、実務で感じてきた直感とよく一致している。AIエージェントシステムの設計において「何を使って検索するか」よりも「ハーネスをどう設計し、どうループを回すか」が最終性能を左右するという認識だ。

grepの優位性については「精巧さより確実性」という観点から腑に落ちる。ベクトル検索は「意味的に近いものを見つける」のが得意だが、「確実に存在する文字列を取得する」用途ではgrepの方が信頼性が高い。LLMが生成するクエリの特性を考えると、完全一致・部分一致が有効に機能する場面は想像以上に多い。

より示唆深いのは「ハーネスが精度を決める」という発見だ。「どのLLMが優れているか」を比べる議論から、「ハーネスを含めたシステム全体をどう設計するか」を問う時代への移行を、この研究は実証的に示している。エージェント開発者にとって、ハーネスの選定と設計は今後ますます重要な技術領域になっていく。

出典: この記事は Is Grep All You Need? How Agent Harnesses Reshape Agentic Search の内容をもとに、筆者の見解を加えて独自に執筆したものです。