Grepだけで十分？AIエージェントの検索体験を激変させる「Agent Harnesses」の正体

エンジニアの皆さんは日々の開発で「Grep」を使い倒していると思いますが、果たしてそれだけで十分でしょうか？現在、AIエージェントによる検索技術の進化が目覚ましく、中でも注目されているのが「Agent Harnesses」です。この記事では、従来のテキスト検索の限界をどう打破し、どのようにしてエージェントがよりインテリジェントに情報を探し出せるようになるのか、その仕組みを深掘りします。

話はそれるけど、grepをrgに書き換えるフックを入れてるんだよね。でも最近、モデルがgrepに強くバイアスかかってるせいで、これって結局無駄なんじゃないかと思えてきた。shimやaliasを作るような上手い方法ってあるかな？

これは意外な結果だね。ソースコードみたいに構造化された入力なら、セマンティックサーチよりgrepの方が優秀だろうと思ってた。でも、自然言語のエラーや不整合のせいで、情報がこぼれ落ちる隙間がかなりできちゃうみたいだね。

もし「苦い教訓（bitter lesson）」を心底信じてるなら、エージェントにすべてのツールを与えて、どれを使うか判断させればいい。

• 正規表現 (grep)
• ハイブリッド検索 (bm25 + vector)

どっちかじゃなきゃいけないなんてことはないんだから、この「X対Y」の議論はあまり面白くないよね。

正規表現フィルタリングと、マルチベクトル埋め込みを使ったセマンティックランキングを組み合わせたら、良い結果が出てるよ。自分は日常的にLightOnチームのColGREPを使ってる。 https://github.com/lightonai/next-plaid/blob/main/colgrep/README.md

コードベースの検索にはずっと伝統的なgrepを使ってる。検索頻度が高くて対象が散らばってるときは、IDEよりずっと役立つんだよね。

grepの設計は驚くほど優れてて、今でも予想を上回る活躍を見せてるよ。

この調査がプログラミングに関するものだと早合点しちゃだめだよ。彼らが測定したのはコードじゃなくて、長い会話を検索するエージェントの能力だからね。

我々はLongMemEvalベンチマーク（Wu et al., 2025）の116問の代表的なサブセットで評価を行っており、これは複数セッションにわたる長い会話全体から質問に回答するエージェントの能力をテストするものだ。

自分の調査だと、トークンを気にしなくてファイル数が10万未満ならgrepで十分かな。ダイレクトコーパスインタラクションの論文[1]を読むと、それ以上の規模での分析結果が載ってる。個人的な経験から言うと、grepとエージェントを組み合わせると、BM25検索エンジンより少しだけ関連性の高い結果が得られる。ただし、トークンを消費する覚悟が必要だけどね。

grepが最高だと思ってるなら、それは君が「コンテンツを検索しやすく整理する」ように社会工学的に仕向けられてきたからだよ。何がエージェントにとって有用かをドキュメント化し、論理的な場所に置く。結局、検索の半分以上はコンテンツの整理で決まるんだ。エージェントを使うかどうかにかかわらずね。Googleが成功した理由の一つもそこで、みんなが検索エンジンに引っかかるようにコンテンツを工夫してる。技術だけがすべてじゃないんだよ :)

1- https://arxiv.org/abs/2605.05242

例えばVisual StudioでC#のコードベースをいじってるとき、CopilotがRoslyn駆動のシンボルデータベースやセマンティック検索を使わずに、grepで周辺を検索してくるのは正直ありえないわ。たぶん、AI関連の開発を担当してるのがPythonしか書かないような「AI特化型の人たち」だからじゃないかな。

表2と3を見れば、知るべきことはだいたいわかるはず。プログラミング向けに調整されたハーネス（CodexやClaude Code）を使うときはgrepが勝つ。ニュートラルなハーネスを使うときはベクトル検索が勝つんだ。

これまでのGrep対RAGの議論は、どれも要因がごちゃ混ぜになってる。一番多いのは、会社がパイプラインをゼロから作り直して問題を解決しただけのケース。最悪なのは、ワンショットRAGからマルチステップGrepに移行して、「マルチステップRAGでも同じ結果が出たはず」という事実に完全に気づいていないケースだね。

結局のところ一番大事なのは、ユーザーが気にかけている「製品の機能」を理解して、それをパイプラインにどう反映させるかだよ。

記事によるとさ：

LongMemEvalは、トークン化しても安定して残りやすい正確な日付、件数、好み、範囲といった字面通りの証拠を復元することを評価する。

これって、字面通りの文字列一致に有利で、grepと相性が良いベンチマークを選んでおいて、それで「ほらgrepが勝った、grepさえあればいいんだ」って結論づけてるだけじゃないの？

ベンチマークのデモ画像(1)の例も、どれもgrepが得意そうなものばかり。自転車についての会話のあと、自転車（複数形も含む）について検索するとか。埋め込みベースのアプローチが輝くような、例えば「ベートーヴェンのソナタの会話のあとにクラシック音楽について質問する」みたいな例じゃないんだよね。

(1) https://github.com/xiaowu0162/LongMemEval/blob/main/assets/longmemeval_examples.png