grepはLSPに勝るのか？コーディングエージェントがより高度なツールを無視する理由

grepはLSPに勝るのか？コーディングエージェントがより高度なツールを無視する理由 コード検索と編集タスクにおいて、grepとLSPベースのセマンティックナビゲーションを比較しました。その結果は、ツールのLLMフレンドリーさが、その背後にある機能と同等に重要である理由を示しています。 PXPengcheng Xu エンジニアリング · 2026-08-12 リンクをコピー なぜコーディングエージェントは、より正確な結果を返す検索インターフェースを無視するのでしょうか？私は、grepによるレキシカル検索と、LSPベースのセマンティックナビゲーションを比較する小規模な研究でこの疑問を探求しました。セマンティックナビゲーションはノイズを減らし、トークンを節約すると予想していました。しかし、エージェントはgrepを使い続けることが多かったのです。セマンティックパスを強制的に先に使わせると、タスクの成功率が低下することもありました。これはLLMフレンドリーさの問題です。ツールがモデルにとってフレンドリーである理由は、単に結果が正確であるだけではありません。次のステップに必要な十分なコンテキストを返し、そのコンテキストをモデルが直接使用できるインターフェースと出力形式で提示する必要があります。学習データとの親和性も重要かもしれません。モデルはトレーニング中に類似したアクションパスを学習した可能性があります。インターフェースの特性は直接評価できます。トレーニングサポートは、これらの結果と一致する仮説であり、この研究で証明されたものではありません。この結果は、LSPに対する一般的な反論ではありません。このプロトコルには、コードナビゲーションをはるかに超える機能が含まれており、この研究ではその一部しかテストしていません。むしろ、この結果はより広範なエンジニアリングの問題を指摘しています。モデルはツールを単独で使用するわけではありません。それは、利用可能なアクション、その名前、入力、およびモデルに返されるコンテキストを定義するハーネスを通じてそれらを使用します。この記事では、コード検索がコード検索と編集タスクの両方にどのように影響したか、なぜgrepが一部の条件で有利だったのか、そしてそれがエージェントプラットフォームにとって何を意味するのかを説明します。モデルとその使い慣れたツールループは、一つの能力表面として機能します。 2つのコード検索インターフェースの比較 エージェントがコードコンテキストを取得するための2つの方法を比較しました。grepはレキシカル検索を実行します。つまり、一致するテキストを見つけます。テストされたLSPベースのツールは、参照、定義、ドキュメントシンボルを通じてセマンティックナビゲーションを実行し、コメント内の同じ単語と実際の関数呼び出しを区別できます。このパイロット研究では、3つのClaudeモデル、複数のPythonおよびTypeScriptリポジトリ、および複数のタスクタイプを対象としました。両方の方法がタスクを正常に完了した場合にのみトークン使用量を測定しました。これは一般的な評価エラーを制御するためです。失敗した実行は、早期に停止しただけで効率的に見えることがあります。単純なコード位置特定タスクでは、3つのモデルすべてが、両方のツールが利用可能な場合、セマンティックツールを選択したのは0％から6％でした。セマンティックファーストパスを強制すると、そのアームでの成功率は100％から89％に低下しました。参照補完タスクでは異なる結果が得られました。すべての呼び出し元を見つけるように求められた場合、モデルは45％から57％の時間でセマンティックナビゲーションを選択しました。LSPベースのパスは、grepの0.76と比較して、偽の一致を削除することで1.00の精度に達しました。しかし、再現率は両方のアームで約0.66にとどまりました。セマンティックナビゲーションは、より多くの真の呼び出しを見つけませんでした。残りの制限は、検索の精度ではなく、エージェントがどれだけ徹底的に作業したかに起因しました。より強力なモデルでは、精度の向上は節約ではなく、トークン使用量の増加を伴いました。 モデルはgrepを盲目的に好むわけではありません — タスクによってルーティングします grepとLSPの両方が利用可能で、エージェントが自由に選択した場合のセマンティック（LSP）ツールの呼び出しシェア。凡例：Opus 4.8（青）、Sonnet 4.6（マゼンタ）、Haiku 4.5（緑）。同じモデル、同じ自由選択 — タスクによってルーティングが反転します。ローカライゼーションとリネームでは、エージェントはほぼ常にgrepに頼ります。参照形状の作業では、約半分の時間、プロンプトなしでLSPに頼ります。アクションの分布はタスク形状であり、盲目的な習慣ではありません。 | タスク | Opus 4.8 | Sonnet 4.6 | Haiku 4.5 | | ------------------ | -------- | ---------- | --------- | | Localization | 0% | 4% | 6% | | Reference-completeness | 45% | 50% | 57% | | Multi-file rename | 3% | — | — | コードベースも重要でした。クリーンなTypeScriptリポジトリでは、LSPベースのナビゲーションはF1ゲインを生み出さず、トークンを16％多く使用しました。ノイズの多いTypeScriptリポジトリでは、F1を0.246改善し、トークンを12％少なく使用しました。有用な予測因子はレキシカルノイズであり、言語が強力な静的型付けを持っていたかどうかではありません。 コードベースのノイズがセマンティックナビゲーションの価値を決定します 参照補完におけるセマンティック検索からの精度向上（ΔF1 = LSP − grep）。バーの色は、そのリポジトリでgrepがどれだけノイズが多いかを示します。prec = そこでのgrepの精度。凡例：青はここではgrepがクリーンであることを意味します。マゼンタはここではgrepがノイズが多いことを意味します。同じ言語の2つのリポジトリで、反対の評価。クリーンなremedaでは、LSPは何も追加しません — grepはすでにすべての参照を正しく解決しているため、セマンティック検索は純粋なオーバーヘッドです。ノイズの多いhonoでは、+0.246 F1を追加します。予測因子は、そのコードベースでgrepの精度がどれだけ低下するかであり、言語が静的に型付けされているかどうかではありません。 | Repo | Language | grep precision | ΔF1 (LSP − grep) | Token cost | | -------- | ---------- | -------------- | ---------------- | ---------- | | remeda | TypeScript | 1.00 | +0.000 | +16% | | hono | TypeScript | 0.51 | +0.246 | −12% | | requests | Python | 0.76 | +0.072 | +19% | これらの結果は、カテゴリー別ではなく条件付きです。エージェントは単に「常にgrepを使用する」わけではありませんでした。タスクによってルーティングが変更され、LSPベースのナビゲーションの価値はリポジトリによって変化しました。 ツールのインターフェースがエージェントの動作を変える テストされたLSPベースのツールは、当初は場所（ファイルパス、行、列）のみを返しました。その後、エージェントはコードを検査するためにファイルを開く必要がありました。対照的に、grepは通常、一致する行をすぐに返しました。例: src/auth.ts:42: return validateToken(token)。セマンティックナビゲーションの応答に、同様の形状でソーステキストを含めるように変更しました。セマンティックバックエンドと参照のセットは同じままでした。モデルに返される情報だけが変わりました。リネームタスクでのPass@1は0.67から0.83に上昇し、フォローアップのファイル読み込みはエピソードあたり15.2から3.2に減少しました。ソースコンテキストを返すことで、セマンティックナビゲーションが改善されます。 マルチファイルリネーム、Opus 4.8、pyright（事前ウォームアップされたインデックス付き）。両方のLSPアームで同じセマンティックバックエンド — 出力形状のみが異なります。凡例：grep（青）、LSP — 場所のみ（マゼンタ）、LSP + インラインコンテキスト（緑）。場所を返すことは、エージェントに各サイトを読みに行かせることを強制します。インラインでラインを返すことはそうしません。ソースの±2行を参照ごとに添付すると、フォローアップのファイル読み込みが15.2 → 3.2に削減され、grep自身の4.3を下回り、pass@1は0.67から0.83に引き上げられました。検索バックエンドは変更されませんでした。返されたものの形状だけが変わりました。 | Arm | pass@1 | Site recall | Tokens | Follow-up reads | | ------------------------ | ------ | ----------- | ------ | --------------- | | grep | 1.00 | 1.000 | 2,451 | 4.3 | | LSP — locations only | 0.67 | 0.930 | 4,131 | 15.2 | | LSP + inline context | 0.83 | 0.958 | 3,336 | 3.2 | この結果は、Anthropicが「Writing effective tools for agents」で強調している原則を示しています。ツールは非決定的なエージェントのためのインターフェースであるため、それらが返すコンテキストは設計の一部です。セマンティックに正しいツールでも、各結果の解釈にいくつかの追加アクションが必要な場合、エージェントのワークフローが悪くなる可能性があります。出力の変更は、ポストトレーニングデータが改善を引き起こしたことを証明するものではありません。各応答により有用な情報が含まれていたため、単純に役立った可能性もあります。しかし、この結果は、モデルは抽象的な「ツールの使用」ではなく、具体的なアクションパターンを学習するという、より広範な仮説と一致しています。使い慣れたループ — プロンプト、ツール呼び出し、読みやすい結果、次のアクション — は、実際に見られる能力の一部となり得ます。 なぜレキシカル検索が有利だったのか インターフェースの親和性は説明の一部にすぎません。レキシカル検索は、一部のタスクにとって実際の構造的な利点もありました。セマンティック参照は、テキストの一致の一種にすぎません。リネームでは、コメント、ドキュメンテーション、設定、または文字列を更新する必要がある場合もあります。find_referencesは設計上それらを返しませんが、grepはできます。セマンティック参照 ⊂ テキスト上の出現 テキスト全体にわたる編集の場合、grepは、LSPベースのナビゲーションで完璧にトレーニングされたモデルであっても、より優れた検索ツールになる可能性があります。これにより、観察された動作の2つの説明が得られます。 構造：一部のタスクはテキストの完全性を必要としますが、テストされたセマンティックナビゲーションメソッドはそれを提供しません。 分布：