エージェント検索は実行環境の問題です

2026年5月14日のarXiv論文では、116件のLongMemEval質問を使い、Chronos、Claude Code、Codex、Gemini CLIにおけるgrepとベクトル検索が検証されました。論文の最初の実験では、すべての実行基盤とモデルの組み合わせで、インラインgrepがインラインベクトル検索を上回りました。ただし、より大きな発見は別にあります。結果は検索手法だけでなく、実行環境によってもほぼ同じくらい変わっていたのです。¹

エージェント検索の品質は、「grepかベクトルか」だけでは決まりません。プロンプト、ツールの提供形態、シェルの使いやすさ、結果の整形、コンテキスト圧、受け渡し経路、再試行の挙動、そしてモデルがツール利用のループを閉じられるかまで含めた、実行環境全体にあります。

要約

Sen、Kasturi、Lumer、Gulati、Subbiahは、Chronosというカスタム実行基盤と、3つのプロバイダー提供CLI実行基盤であるClaude Code、Codex、Gemini CLIを対象に、語彙検索とベクトル検索を比較しました。¹ 研究では116問のLongMemEval-Sサブセットを使い、ツール結果をインラインで渡す場合と、ファイル経由で渡す場合の両方を検証しています。¹ 実験1では、すべての実行基盤とモデルの組み合わせでインラインgrepがインラインベクトル検索を上回りました。Codex CLIとGPT-5.4の組み合わせでは、インラインgrepが93.1%、インラインベクトル検索が75.9%でした。¹ ただし、この論文はgrepが一般にベクトル検索より優れていると証明したものではありません。著者らは、結論が長期記憶を扱う会話QAという設定に限られることを明示しています。この設定では、答えが文字どおりの記述に依存することが多いためです。¹ エージェントを作る側にとって重要なのは、もっと鋭い示唆です。検索手法、エージェントの実行環境、結果の受け渡しは1つのシステムとして評価すべきです。

重要なポイント

• エージェントを作る人へ: grepを真剣なベースラインとして残してください。長いチャット履歴に対するQAでは、特に名前、日付、ユーザーに関する事実が重要な場合、「とりあえずベクトル検索」は雑に見えます。¹
• CodexとClaude Codeのユーザーへ: プロバイダーのCLIを、検索プリミティブを包む中立的なラッパーだと考えないでください。同じ会話データでも、実行基盤の違いで大きな変化が出たと論文は報告しています。¹
• RAGチームへ: 検索器だけでなく、結果の受け渡し経路も報告してください。インライン結果とファイル経由の結果では挙動が変わりました。ファイル経由では、もう1つツール利用の作業が増えるためです。¹
• 移行作業へ: 検索を信頼できるものにしている実行環境の挙動を守ってください。Claude CodeからCodexへの移行では、同等性を宣言する前に、検索、会話記録の形、検証ループをテストすべきです。
• 引用の多いシステムへ: 最終的な引用だけが証拠のすべてではありません。別のAgentic GraphRAG論文は、出典の信頼性が、引用されたノードだけでなく、訪問されたものの引用されていないグラフ文脈にも依存し得ると論じています。⁴

grep論文は実際に何を検証したのか

この論文が問うているのは実践的な問題です。LLMエージェントが長い会話履歴に基づいて質問に答えるとき、検索結果は検索手法にどれだけ左右され、周囲のエージェントシステムにどれだけ左右されるのでしょうか。¹

著者らは、2種類の検索ファミリーを比較しました。

これらの検索器を、2種類の実行環境で試しています。

結果がモデルに届く方法も変えています。インライン受け渡しでは、検索ヒットが会話に直接挿入されます。プログラムによる受け渡しでは、結果がファイルに書き出され、モデルがそれを見つけ、開き、統合する必要があります。¹ 実装の細部に聞こえるかもしれません。しかしデータは、それ自体がタスクの一部だと示しています。

なぜここではgrepが勝ったのか

測定されたタスクは、文字どおりの情報回収に向いています。LongMemEvalは、複数セッションにまたがる長い会話について質問します。多くの答えは、名前、時刻表現、個人的な事実、過去の正確な発言に依存します。このような設定では、特徴的な文字列の背後に答えがあることが多いため、高精度の語彙検索ツールが意味検索器を上回ることがあります。¹

論文のTable 1は、その傾向をはっきり示しています。

この表は、「ベクトルデータベースを消せ」と言っているわけではありません。論文自身も、その読み方に注意を促しています。著者らは、結論が長期記憶の会話QAに結びついたものであり、科学的な統合、視覚資料、コード意味論では、密ベクトル検索やハイブリッド検索が異なる挙動を示す可能性があると述べています。¹

よりよい読み方はこうです。正確検索は、本格的なエージェント実行環境の中で一級の席を持つべきです。エージェントがファイルシステムを検索し、ログを読み、過去の会話記録を調べ、ユーザーの文字どおりの事実を回収できるなら、語彙検索は最も安価で信号の強いツールになり得ます。

実行環境が結果を変えた

この論文で最も役に立つ一文は、「grepが勝った」ではありません。実行基盤を変えると、検索器を変えたときと同程度の規模で上限が動き得る、という点です。¹

例を1つ挙げると、Claude Opus 4.6のインラインgrepは、Chronosでは93.1%に達しましたが、Claude Codeでは76.7%でした。¹ 同じモデルファミリー、同じベンチマークサブセット、しかし実行環境が違います。別の例では、Codex CLIとGPT-5.4の組み合わせで、インラインgrepは93.1%でしたが、grep結果をプログラムによるファイル受け渡しに移すと55.2%まで下がりました。プログラムによるベクトル検索は67.2%でした。¹

これは検索結果だけの問題ではありません。実行環境の結果です。

モデルは証拠を見つける以上のことをしなければなりませんでした。ツールの契約を理解し、検索語を選び、stdoutを解釈し、再試行すべきタイミングを判断し、結果がインラインでない場合はファイルを読み、証拠を答えに統合する必要がありました。これらの各段階はすべて、エージェント実行環境に属します。どこかがもろければ、強い検索器でも弱い答えになります。

ファイル経由の受け渡しはツール利用テストである

ファイル経由の受け渡しには、わかりやすい魅力があります。大きな検索結果を、モデルが読む必要を示すまで直近の会話記録の外に置けるため、コンテキスト圧を下げられます。インラインのベクトル結果がウィンドウを埋める場合には助けになるはずです。

論文は、そのトレードオフを示しています。いくつかの行では、プログラムによるベクトル検索がプログラムによるgrepを上回っており、これはコンテキスト圧の議論を支えます。¹ しかしCodex/GPT-5.4の行は、反対側も示しています。ファイル受け渡しは、安価な検索を複数段階の作業手順に変えてしまうことがあります。エージェントは成果物を見つけ、開き、有用な箇所を抜き出し、最初の読み取りでは足りなかった場合に再試行しなければなりません。¹

つまり、プログラムによる受け渡しは、コンテキスト帯域と引き換えに、ツール利用ループを回し切る能力を要求します。この交換が得になるのは、実行環境がそのループを確実に閉じられる場合だけです。

これは実務にも関わります。ローカルエージェントの検索が失敗するのは、インデックスが間違っていたからだけではありません。stdoutの分割が下手だった、結果ファイルのパスを見落としやすかった、コマンドがノイズを返しすぎた、プロンプトがタスクを悪く捉えさせていた、あるいはモデルが1回読み取っただけで止まってしまった。そうした理由でも検索は失敗します。

Codex移行にとっての意味

私自身のClaude CodeからCodexへの移行では、ファイルツリーをコピーすることではなく、運用上の契約を移すことに重点を置いてきました。この論文は、その選択を補強しています。

検索品質が実行環境に依存するなら、移行品質は「Codexに検索ツールがあるか」以上の問題になります。移行では、検索を有用にしている挙動を守らなければなりません。

• エージェントが、意味検索の前に正確検索を使うべきタイミングを知っている。
• コマンド出力が、読める程度に小さく保たれている。
• 証拠のパスが最終回答まで残る。
• ファイル経由の成果物を見つけやすく、調べやすい。
• 検索に失敗したとき、早すぎる回答ではなく、よりよいクエリにつながる。
• 公開文章では、もっともらしい検索結果ではなく、出典検証を使う。

このリストは意図的に公開可能で一般的な内容にしています。非公開のフック、非公開のプロンプト、ローカル作業手順の内部は明かしていません。要点は運用上の契約です。エージェントには、検索したことに自信ありげに見せるだけでなく、何を見つけたのかを証明させる必要があります。

この論文は、明らかな機能がすべて存在していても、移行後の体験が悪くなり得る理由も説明しています。Claude CodeとCodexはどちらもシェルツールを公開しているかもしれません。どちらもファイルを読めるかもしれません。どちらも検索できるかもしれません。しかし、会話記録の形式、ファイル結果の扱い、停止挙動、再試行パターンが違えば、同じ検索プリミティブでも違う仕事になります。

ほかの3つの手がかりも同じ方向を指している

同じ調査で見つかった2026年5月14日の別の3本の論文も、より広い同じ傾向を示しています。エージェント品質は、孤立したモデル呼び出しから、実行環境アーキテクチャへ移りつつあります。

APWAは、高度に並列なエージェント作業を分散実行の問題として扱います。著者らは作業手順を、相互通信なしで独立リソースが処理できる非干渉のサブ問題へ分解し、従来システムが失敗する大きなタスクでのスケーリングを評価しています。² これはプロンプトの小技ではなく、実行環境についての主張です。

MeMoは、記憶を独立したモデルコンポーネントとして扱います。実行役のLLMを固定し、新しい知識を専用の記憶モデルにエンコードします。そして検索ノイズへの耐性、オープンソースとクローズドソースのLLMとのプラグアンドプレイ互換性を報告しています。³ これは長いコンテキストの主張ではなく、記憶アーキテクチャの主張です。

Agentic GraphRAGの出典来歴に関する論文は、最終的な引用が必要であっても十分ではない場合があると論じています。正確な答えは、引用されていない探索文脈、グラフ構造、訪問されたものの引用されていないエンティティに依存し得ます。⁴ これは引用形式ではなく、来歴についての主張です。

grep論文と並べると、形が見えてきます。

共通するテーマはこうです。モデルを包む実行層こそがプロダクトです。モデルの能力が有用な仕事になるかどうかは、実行環境が決めます。

エージェントスタックで変えるなら

まずは退屈なベースラインから始めます。重要なファイル、ログ、会話記録、メモに対して、エージェントに正確検索を与えます。意味検索を追加する前に、それを測定してください。

次に、2通りではなく4通りをテストします。

各実行でツールの会話記録を保存します。最終回答だけでは足りません。エージェントが正しい語を検索したか、正しいファイルを開いたか、正しい箇所に気づいたか、ミスの後に再試行したか、実際に答えを支えている証拠を引用したかを知る必要があります。

ドメインに言い換えの回収、概念的な統合、文字どおりではない証拠が必要なら、ベクトル検索を追加します。名前、ID、ファイル名、日付、ログ行、コマンド出力、ユーザー設定、過去の指示が含まれるドメインでは、正確検索を残します。両方が混ざるタスクでは、ハイブリッドな振り分けを使います。

公開文章では、検索経路をより厳しくします。引用付きの記事には、出典URL、主張と出典の対応、未検証として残るものの記録が必要です。システムがグラフ、記憶層、中間の検索経路を使ったなら、最終引用だけを唯一の痕跡にすべきではありません。来歴論文はAgentic GraphRAGについてこの点を述べていますが、プロダクト上の教訓はより広く当てはまります。証拠は目的地だけでなく、そこに至る道筋も説明すべきです。⁴

よりよいベンチマークの問い

弱いベンチマークの問いはこうです。

どの検索器が優れているのか。

より強い問いはこうです。

この実行環境、このモデル、このコーパス、この受け渡し経路、この再試行方針のもとで、どの検索挙動が検証済みの答えを生むのか。

この問いに答えるには時間がかかります。しかし、使える知見が得られます。

エージェント開発では、ついコンポーネント単位の主張に流れがちです。よりよいモデル、よりよい検索器、よりよいプロンプト、よりよい記憶、よりよい並列化。しかし運用の現実は、逆方向へ押し戻します。コンポーネントが意味を持つのは、実行環境がそれを、タスクから証拠、そして行動へ至る信頼できる経路に変えた後です。

移行する価値があるのは、その部分です。

FAQ

この論文は、grepがベクトル検索に勝つと証明していますか。

いいえ。著者らは、この結果が研究対象の長期記憶の会話QA設定に限られることを明示しています。証拠が文字どおりであることが少ない領域、たとえば科学的な統合、視覚情報の多い文書、コード意味論では、密ベクトル検索やハイブリッドな振り分けが異なる挙動を示す可能性があると述べています。¹

なぜ実験ではgrepの性能が高かったのですか。

LongMemEvalの質問は、過去の会話にある文字どおりの記述に依存することがよくあります。名前、日付、個人的な事実、正確な発言です。エージェントが特徴的な語を推測できる場合、grepの高精度なパターン検索が効きます。¹

なぜ実行基盤が重要だったのですか。

実行環境は、プロンプトの形、ツール説明、会話記録の形式、シェル挙動、コンテキスト構成、結果の受け渡し、停止条件を制御します。論文では、基礎となる会話データが同じでも、Chronos、Claude Code、Codex CLI、Gemini CLIの間で大きな精度差が報告されています。¹

Codexユーザーはこれをどう受け止めるべきですか。

正確検索をベースラインとして残し、ツールの会話記録を確認し、ある検索手法が優れていると仮定する前に、インライン受け渡しとファイル経由の受け渡しをテストしてください。論文のCodex行は有用ですが、それでも1つのベンチマーク設定、1種類のコーパスでの結果であり、スケーリング行についてはベンダー全体へ一般化するには不完全な材料です。¹

これはRAGの引用とどう関係しますか。

Agentic GraphRAGの来歴論文は、最終引用が答えを支えていても、その答えに影響した検索文脈を省いてしまうことがあると論じています。エージェントシステムでは、引用品質に、最終的に引用された出典リストだけでなく、そこに至る道筋の来歴も含めるべきです。⁴

Claude CodeからCodexへの移行では何を守るべきですか。

運用上の挙動を守ってください。エージェントがいつ検索するか、出力をどう制限するか、証拠をどう開くか、どう再試行するか、出典パスをどう記録するか、裏づけのない主張をどう拒否するかです。両方の環境がシェルと検索コマンドを公開しているからといって、同等だと仮定してはいけません。

参考文献