Codexのコード検索をBM25で高速化｜探索トークンを削減する設計

コーディングエージェントの利用コストと待ち時間を押し上げる要因の一つは、Glob/Grepで候補を探し、ファイルを順に読んでいく発見の非効率です。リポジトリが大きくなるほど、無関係なファイルを開いて次の検索語を考え直し、再び読み込むという往復が頻発します。

📑目次

論文が示したこと — 規模で逆転する BM25 と File-System Agent
Codex への落とし込み — BM25 前段候補検索の二次実験
コーディングエージェント一般への拡張 — hybrid BM25 と「いつ grep のままか」
導入判断チェックリストと次アクション
よくある質問（FAQ）
まとめ

Wang らによる論文 BM25 Wins at Scale（arXiv:2607.26497）は、コーパスが拡大するにつれ File-System Agent より BM25 が accuracy-cost で優位になる交差を、制御実験で示しました。

実務上の論点

実務で主な論点になるのは、次の設計です。

候補検索を BM25 に寄せる
エージェントを後段に回す

独立した複数のソースと突き合わせて、これらを整理します。

論文が示した交差と Agent+BM25 制御の数値
Codex へ BM25 前段を置いた二次実験報告
コーディングエージェント向け hybrid / lexical の独立分析
導入判断チェックリスト

読み終えたあとに決められること

読み終えると、次に何を決めるべきかがはっきりします。

自リポジトリで BM25 前段を試す価値があるか
何を測るか
鵜呑みにしない境界

想定読者と根拠の置き方

想定している読者は次のとおりです。

Codex や Claude Code などのコーディングエージェント利用者
RAG・社内検索の設計者
SWE 基盤担当

発見元の二次報告は Zenn の Knowledgesense 記事ですが、数値の一次根拠は arXiv と複数の独立整理に置きます。

この記事で学べること（概要）

論文が示したこと — 規模で逆転する BM25 と File-System Agent

結論から述べると、コーパスが成長するほど「全体から候補を並べる」lexical検索が有利になり、生ファイルを渡り歩くエージェント探索はクエリトークンコストの点で不利になります。

実験設計

Pengyu Wang らの arXiv:2607.26497v3（2026-07-31）は、EnterpriseRAG-Bench 上で次の制御設計を使いました。

28 段の厳密入れ子コーパス（約 1,144→511,959 文書、約 450 倍）
質問・gold / adversarial bedrock・reader / judge を固定
計測指標: accuracy、構築 / query tokens、latency
比較パラダイム: lexical（BM25）、dense、graph、agentic（File-System Agent）

主結果

主な結果は、点推定と論文および独立整理で、次のとおりです。

最小共有ティアでは File-System Agent が先行しうるが、bedrock で query tokens が BM25 の約 39 倍
約 1,000 万 corpus tokens 付近で BM25 が逆転し、以降の共有ティアでリード
フルスケールでは BM25 と Agent の差が約 20 ポイントに近づく（第三者整理の例: BM25 50.5 / Agent 30.7）
oio-blog の整理では、最小規模の統合スコア例として File-System Agent 77.4 / BM25 74.7、最小規模 query tokens として BM25 5.8K vs Agent 226K が挙げられます

Agent+BM25 制御

Agent+BM25 制御（同一 150 問）では、役割分担がはっきりします。

raw-file agent: スコア 36.9 / 895K tokens/query
Agent+BM25: スコア 69.4 / 101K tokens/query、document recall 36.8→72.4
BM25 単体の整理例: 54.8 / 5.8K（oio-blog）

実務含意

論文が実務に示す含意は単純です。

lexical を scalable default とする
agentic reasoning は ranked discovery の後段に置く
失敗の主因は「統合推論そのもの」より「候補発見」側に寄りやすい

条件別の比較表

条件/指標	File-System Agent（raw）	BM25	Agent+BM25 制御
小規模での傾向	点推定が先行しうる	僅差〜後追い	—
bedrock query tokens	BM25 の約 39 倍	低コスト端（例 5.8K 系）	中間（例 101K）
~10M corpus tokens 以降	探索空間拡大で相対劣位	共有ティアをリード	—
フルスケール accuracy 差	約 20pt 劣後の整理	リード	36.9→69.4（150問制御）
制御時 tokens/query	895K	5.8K 系（単体整理）	101K

限界の読み方

限界についても、先にはっきりさせておきます。

単一ベンチ・単一 reader / judge である
hybrid BM25+rerank や agent-top-k の網羅評価は限定的
「BM25 が常に勝つ」ではなく、「候補発見を安い全体検索に寄せるとスケール耐性が出やすい」と読むのが安全

Codex への落とし込み — BM25 前段候補検索の二次実験

論文の交差検証は、企業文書RAGを制御する研究です。これをコーディングエージェントにそのまま当てはめられるかどうかは、実装側の二次証拠が必要です。

二次実験の位置づけ

発見元の Zenn 記事（Knowledgesense / 須藤英寿、2026-08-11 前後）は、論文アイデアを自社コードベースで Codex 比較した 二次実験報告です。論文の再現そのものではありません。

比較条件

比較条件の報告値は次のとおりです。

通常探索: Glob / Grep / ファイル読み取り
BM25 探索: ローカル BM25（MCP）+ 該当範囲の追加読み取り
リポジトリ: 約 7,536 ファイル / 68.8MB、断片約 15,000、SQLite インデックス 164MB・構築約 27 秒
Codex CLI 0.146.0-alpha.3.1、モデル gpt-5.6-sol high
低 / 中 / 高難度各 4 問・各条件 1 回・新セッション

主結果

主結果は、Zenn 自社計測で全問正解のうえで、次です。

セッション全体トークン: 1,812,066 → 1,283,250（29.2% 削減）
質問ごとの削減率中央値 28.5%（12 問中 10 問で削減）
動作時間中央値 50.8s → 30.0s（参考、中央値短縮率 34.2%）
難度別トークン削減率中央値: 低 39.8% / 中 31.9% / 高 28.5%（中・高で 1 問ずつ BM25 が悪化した例あり）

仕組みの要点

仕組みの要点は、報告では次のとおりです。

識別子の camel / snake 分割
日本語 bigram
パス語のブースト
返すのは上位パス・行範囲・短い抜粋
深い調査は通常の Codex 読み取りへ渡す

トークンが減る理由として推測されるのは、次の往復が減ることです。

無関係ファイルの読み取り
「次の検索語を考える」ループ

二次結果のスナップショット

指標	通常探索	BM25探索	差分
セッショントークン合計	1,812,066	1,283,250	−29.2%
質問ごと削減率中央値	—	28.5%	10/12 問で削減
動作時間中央値（参考）	50.8s	30.0s	−20.8s
インデックス構築	—	約 27s / 164MB SQLite	導入固定費

出典: Zenn / Knowledgesense「BM25を使用してCodexのトークンの消費を30%抑える」（二次実験報告）。論文一次は arXiv:2607.26497

約 30% の読み方

読者にとって特に重要なのは、次の扱い方です。

約 30% は当該リポ・質問セット・1-run の二次結果である
論文の 895K→101K 制御とは尺度が違う
自環境の保証値として転記しない
「BM25 前段が効きうる仮説」として固定質問で再測定する材料にする

Codex 周辺の効率・ハーネス議論は、別稿の GPT-5.6 × Codex serving / harness 整理や Codex CLI 更新メモとあわせて読むと、探索以外のコスト層も切り分けやすくなります。

コーディングエージェント一般への拡張 — hybrid BM25 と「いつ grep のままか」

論文の「候補発見をlexicalに寄せ、agentを後段に置く」方針と、実装側の「grep-then-readをやめる」判断は、同じ役割分担です。

monorepo での問題

Particula Tech（Sebastian Mondragon、2026-07-05）の独立分析は、次の問題を整理しています。

monorepo で grep → 全ファイル read が context / token を食い潰す
hybrid（AST chunk + dense + BM25）や MCP 経由の関連関数返却が、vendor self-eval で同等 retrieval quality 時にトークン約 40% 削減と報告
第三者ベンチではない点は明記が必要

実務上の役割分担

実務での役割分担は、次のように整理できます。

BM25: 識別子・稀少トークン・パス語に強い
dense: 「どこで認証している？」のような意味クエリを補う
agent: 候補後の横断調査・統合・編集判断
インデックス運用: Merkle-tree 差分などで変更ファイルのみ再埋め込みし、churn 比例に維持する

いつ grep のままか

Codex CLIを含む複数のMCPクライアント設定が列挙される一方で、限界条件も独立して整理されています。

小リポ・完全一致・一回限りは grep が正しい
流行の hybrid を常設するより、「候補発見コストが支配的かどうか」で切り替える方が再現しやすい

状況別ガイド

状況	向きやすい手段	理由 / 注意
中〜大規模 monorepo・繰り返し探索	BM25 前段 or hybrid	候補発見コストが支配的
一意な識別子の一発特定	grep / 厳密一致	インデックス固定費が無駄になりやすい
意味的な「どこで認証してる？」系	hybrid（BM25+dense）	lexical 単独の語彙ギャップを dense が補う
変更が激しい monorepo	差分再インデックス	フル rebuild 前提だと運用が折れる
セキュリティ境界	ローカル index / MCP 権限	リポジトリ全文を外部へ送る設計は別リスク

出典とセキュリティ境界

出典（2026年7–8月時点）:

⚠️ ローカルのBM25/MCPであっても、インデックスに載せる範囲、ツール権限、外部送信の有無は組織ポリシーとは別問題です。トークン削減のために全文を外部サービスへ送信する設計は、コスト改善と引き換えに情報漏洩のリスクを広げます。

導入判断チェックリストと次アクション

論文の 39× / 20pt や二次実験の 29.2% は、条件付きの実測です。採用判断は自セッションの計測から始めます。

今すぐ（30–60分）

直近 1 週間の Codex / エージェントセッションで、「検索・読取」に使ったツール呼び出し回数と概算トークンを眺める
失敗パターンが「候補が見つからない」か「候補後の統合推論」かを切り分ける
リポジトリ規模（ファイル数・MB）と、識別子検索 vs 意味検索の比率をメモする

試すなら最小実験（半日〜1日）

固定質問セット（低 / 中 / 高）を 8–12 問用意し、通常探索 vs BM25 前段を 新セッション・同モデルで比較する
測る指標: セッショントークン合計、質問ごと中央値、正解 / 必要情報の被覆、（参考）所要時間
インデックス構築時間・容量・更新運用（フル vs 差分）を記録する

採用に進む条件（例）

トークンまたは時間が再現可能な幅で改善し、品質が落ちない（または許容範囲）
中・高難度で悪化する質問タイプが特定でき、フォールバック（grep / 手動パス指定）がある
MCP / ローカル index の権限・秘匿情報が組織ポリシーに合う

やらない／保留の条件

小規模リポで grep が既に一発で足りる
質問が毎回一回限りで index 固定費を回収できない
論文の 39× / 20pt や二次実験の 29.2% を、自環境の保証値として扱う必要がある場合

次の一手

次の一手としては、再現しやすい順序が次のとおりです。

まず計測する
固定質問で A/B する
悪化ケースのフォールバックを設計する
差分インデックス運用を決める

Codex Security CLI/SDKや、serving/harness側の議論と並行して考えると、これらを混同しにくくなります。

「探索コスト」
「実行・権限・提供コスト」

よくある質問（FAQ）

Q1. 論文の「BM25 が勝つ」はコーディングエージェントにもそのまま当てはまるか？

論文は企業文書 RAG の制御スケール研究です。コーディングへの一般化は二次実験と実装分析で補強する必要があり、無条件の勝利宣言ではありません。

Q2. 「トークン 30% 削減」は誰でも再現できる数字か？

いいえ。Knowledgesense の約 7.5k ファイル・12 問・特定 Codex / モデル条件の二次計測（全体 29.2%）です。自環境では固定質問セットでの再測定が必要です。

Q3. BM25 を入れれば Agent は不要になるのか？

論文の制御では Agent+BM25 が raw-file agent より高スコアかつ低トークンでした。候補発見を lexical に任せ、統合・横断調査は agent が担う分担が本筋です。

Q4. Dense / vector DB に置き換えるべきでは？

論文では dense は効率的でも accuracy で BM25 に劣る場面が示されます。コード識別子には BM25 が強く、意味クエリは hybrid が現実的です。Particula の整理も同様の方向です。

Q5. インデックス更新はどう運用するのか？

二次報告では約 27 秒構築のスナップショット例があります。変更が激しい場合は差分再埋め込み（Merkle 等）を検討してください。放置 index は陳腐化リスクがあります。

Q6. Claude Code など他エージェントでも同じか？

候補発見の逐次コストという原理は共通しえますが、ツール面・MCP 対応・計測は製品ごとに要確認です。本記事の Codex 数値を他製品へ直接転記しないでください。

関連記事:

まとめ

要点

Wang らは、コーパス成長下で BM25 が File-System Agent を accuracy-cost で追い抜き、agentic は ranked discovery 後段が適切と示しました（約 10M 交差、約 39× query tokens、Agent+BM25 36.9→69.4 / 895K→101K）
二次の Codex 実験は BM25 前段でセッショントークン約 29% 削減を報告しました。論文制御とは尺度が違い、条件付きの実装ヒントとして読むのが妥当です
独立分析は monorepo の grep-then-read 問題と hybrid BM25 の実務条件（小さいリポでは grep）を補強します
読者の次アクションは、自セッションを計測し、固定質問で A/B し、悪化ケースと index 運用を決めてから採用判断することです

根拠の置き方

事実根拠は arXiv と独立二次ソース、および自環境計測に置いてください。人気シグナルだけで導入を決めないことが、再現可能な判断につながります。

著者

krona23

IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。

DevGENT について →

📚 次に読む