#32 AIに「grep」を使わせたら検索が変わった

賢いAIエージェントには、従来の「検索エンジン経由」ではなく、grep や bash といった昔ながらのコマンドラインツールで生のドキュメントを直接探らせた方が、安く・速く・正確に答えを見つけられることを示した研究。

ChatGPTのようなAIに社内文書やWebから情報を探させる時、現在は「ベクトル検索」という仕組みが主流です。文書を事前に数値化（埋め込み）してインデックスを作り、質問に「意味的に近い」上位数件を返す方式です。

しかし最近、エージェント型AI（自分で計画を立てて何度も検索する賢いAI）が登場し、この方式の限界が見えてきました。たとえば「特定の語句が完全一致する文書」「複数の弱い手がかりを組み合わせる」「文書の前後を細かく確認する」といった作業が、検索エンジン経由ではうまくできないのです。一度フィルターで弾かれた情報は、後からどんなに賢く推論しても取り戻せません。検索インターフェース自体がボトルネックになっていました。

著者らの提案は驚くほどシンプルです。​ベクトル検索もインデックスも一切使わず、エージェントにLinuxの黒い画面（ターミナル）を渡して、grep（文字列検索）、find（ファイル検索）、cat（中身を見る）といった昔からあるコマンドで直接コーパスを探らせる。これを「Direct Corpus Interaction（DCI、直接コーパス操作）」と呼びます。

たとえばエンジニアがコードベースから何かを探す時、IDEの検索バーよりも grep 'foo' file | grep 'bar' のようにコマンドを組み合わせた方が早い、という経験に近い発想です。AIエージェントも同じように、検索を絞り込んだり、見つけた箇所の周辺を読んだり、仮説を立てて検証したりを自由に組み合わせられます。事前のインデックス構築も不要で、ファイルが更新されても即座に対応できます。

実装は2種類：Claude Codeをベースにした高性能版（DCI-Agent-CC）と、bashとreadだけの軽量版（DCI-Agent-Lite）です。

ディープリサーチのベンチマーク「BrowseComp-Plus」で、同じClaude Sonnet 4.6を使った場合、従来のQwen3埋め込み検索を使うと正答率69.0%・コスト約1,440ドルだったのが、DCIに置き換えると 正答率80.0%（+11ポイント）、コスト1,016ドル（−29.4%）​ に。精度も上がり、コストも下がるという珍しい結果です。

マルチホップQA（複数の文書を辿って答える問題）では、DCI-Agent-CCが平均83.0%と、最強の検索エージェントベースライン（52.3%）を 30.7ポイント上回り ました。情報検索ランキングのタスクでも、最強ベースライン47.0%に対して68.5%（+21.5ポイント）を達成しています。

興味深いのは、DCIが勝つ理由が「より多くの正解文書を見つけたから」ではない点。むしろ、一度たどり着いた文書から 細かい証拠をピンポイントで抽出する能力 が大きく寄与しているそうです。

この研究は「AIに情報を探させる」アプローチに発想転換を迫ります。多くの企業がRAG（検索拡張生成）を社内導入する際、まずベクトルDBを構築するところから始めますが、それは大規模で静的なコーパスでは合理的でも、​日々更新される社内ファイルや、構造が複雑なドキュメント群 には必ずしも最適ではないかもしれません。

特に注目すべきは、ファイルが頻繁に変わる開発現場、法務文書、研究データなど、「インデックスを作り直すのが面倒」「完全一致検索が必要」「文脈を細かく追いたい」といったケース。エージェントが直接ファイルを探れる方式は、こうした現場と相性が良いはずです。

また、コストと精度の両方が改善するというのは経営的にも魅力的です。ベクトルDB構築・運用の手間が消え、汎用的なコマンドラインツールだけで済むため、インフラがシンプルになります。一方で、コーパスが大きくなると探索コストが急増する（40万文書で精度37.5%まで低下）という制約もあり、用途を選ぶ技術であることは押さえておく必要があります。