cclensの続編｜なぜCodexは同じコードを何度も読み直すのか？ BM25で解く検索非効率の正体

昨日、cclensで自分のClaude Codeを計測したら、9,097トークンの無駄が見えたという記事を書きました。セッションを1回始めるだけで、ルールファイルを読むだけの9,097トークンが消えていた——という実測の話。正直、あれを書いた時点では「無駄が見えた」で終わっていました。なぜその無駄が生まれるのか、そこまでは踏み込めていない。

で、その続きが思わぬ方向から出てきました。ナレッジセンスという会社のCTOが書いたZennの記事です。タイトルは「BM25を使用してCodexのトークンの消費を30%抑える」。読んだ瞬間、これ昨日の記事の答え合わせじゃん…と思いました。

前編がレストランのレシートを見て「材料費が思ったより高い」と気づいた話だとしたら、今日は厨房の中の動線を見る話。同じ食材を取りに、料理人が冷蔵庫と棚を何往復もしていた——そういう種類の無駄です。料理で言うと、これは致命的だよね。動きが多いほど、火は通らないまま時間だけが過ぎていく。

前編（当ブログ・自社環境の実測）

ALWAYS-ON HEAVY　claude_md/global　2865 tokens/session
ALWAYS-ON HEAVY　rule/judgment　2265 tokens/session
ALWAYS-ON HEAVY　rule/channels/ux-settings　1542 tokens/session
（合計: 9,097 tokens/session）

→ 前編を見る：cclensで自分のClaude Codeを計測したら、9,097トークンの無駄が見えた

前編で分かったのは「入口のコスト」でした。作業を始める前に、AIが自分の設定書を読むだけで消えていく分。今日の話は、そこから先——作業中にAIが「探し回る」ことで消えていく分のほうです。分けて考えると、途端に手の打ちどころが見えてきます。

元ネタは、Knowledge Sense, Inc.のCTOであるsasakuna氏が2026年8月11日にZennへ公開した記事、「BM25を使用してCodexのトークンの消費を30%抑える」です。読み始めて、いちばん最初に手が止まったのがこの一文でした。

sasakuna氏（Knowledge Sense, Inc. CTO）

「Claude CodeやCodexは、非常にシンプルなキーワード検索しか実装していません」

→ 元記事を見る（Zenn・ナレッジセンス）

え、そこ？と思った人もいるかもしれません。私も同じでした。GPT-5世代の頭脳を積んだAIが、コードを探す手段としてはGrepとGlob——つまり「この文字が入ってるファイルを出して」「この名前のファイルを出して」という、20年前からある道具しか持っていない。頭は最新、手足は骨董品。この落差が、そのまま無駄の正体でした。

厨房でたとえるなら、三つ星の腕を持つ料理人に、ラベルの貼っていない冷蔵庫を渡しているようなもの。まず扉を開ける、違う、閉める、次の棚を開ける、また違う…この往復のあいだ、腕はまったく活きていません。しかもAIの場合、開けた扉の中身を毎回「読んで」しまう。読んだ分だけトークンが減っていきます。

	従来の探し方（Grep / Glob）	BM25を前に置いた探し方
やること	検索語と対象フォルダを変えながら、複数のファイルを読んで絞り込む	関連度の高い順に、コードの断片を最初から並べて返す
返ってくるもの	一致したファイルの中身（丸ごと読むことが多い）	上位候補のパス、行範囲、短い抜粋だけ
AIの負担	関係ないファイルも読むので、推論の回数が増える	読む候補と範囲を早い段階で絞り込める
たとえると	ラベルなしの冷蔵庫を端から開ける	仕込み担当が食材を3つに絞って出しておく

BM25という名前は初めて聞く方が多いと思います。難しそうな響きだけど、中身はけっこう素朴。元記事の定義がいちばん短くて分かりやすいので、そのまま引きます。

sasakuna氏（Knowledge Sense, Inc. CTO）

「検索語が文書中に現れる頻度と、その語の珍しさを使って、関連性の高い文書を順位付けする検索手法」

→ 元記事を見る（Zenn・ナレッジセンス）

ポイントは「珍しさ」のところ。レシピ検索で考えると腑に落ちます。「塩」で検索しても、ほぼ全部のレシピが引っかかるので役に立たない。でも「ブールマニエ」で検索したら、該当するレシピは一気に数枚まで絞られます。ありふれた言葉は軽く、珍しい言葉は重く数える——それだけのルールで、検索の精度は跳ね上がる。

sasakuna氏はこれをMCPという仕組みでCodexに繋ぎ、Codexが使える検索方法のひとつとして足しました。コードベースを一定の行数で分割しておいて、質問に関連度が高い断片を返す。返すのは上位候補のパス・行範囲・短い抜粋だけで、もっと詳しく見たければCodexが自分で読みに行く。この「渡しすぎない」設計がきれいなんですよね。

sasakuna氏（Knowledge Sense, Inc. CTO）

「検索手段をBM25に寄せることで、効率的に必要な情報を集められるようになっています」

→ 元記事を見る（Zenn・ナレッジセンス）

ちなみに元記事は、参考論文としてWangらの「BM25 Wins at Scale」（arXiv:2607.26497v3・2026年7月）を挙げています。今どきAI検索といえばベクトル検索（意味の近さで探すやり方）が主流かと思いきや、規模が大きくなるとBM25のような古典的な手法が強い、という話。古い道具が新しい現場で復活するのは、けっこう気持ちいい。

で、実際どのくらい効いたのか。ここがこの記事のいちばんおいしいところです。検証の条件がきちんと書いてあるので、まず並べておきます。

検証条件	数値
リポジトリ規模	7,536ファイル / 68.8MB
分割したコード断片	15,000個
テスト問題	12問（低難度4問・中難度4問・高難度4問）
使用したCodex CLI	0.146.0-alpha.3.1
モデル	gpt-5.6-sol high
実行方式	各質問・各条件を1回ずつ、新規セッションで実行

そして結果がこれ。

sasakuna氏（Knowledge Sense, Inc. CTO）

「BM25を候補検索としてCodexの前段に置くことで、回答品質を維持しながら、検索から回答までに使うトークンを約3割減らせました」

→ 元記事を見る（Zenn・ナレッジセンス）

実測値（元記事より）

セッション全体のトークン合計: 1,812,066 → 1,283,250（29.2%削減）
質問ごとの削減率の中央値: 28.5%
1回あたりの動作時間の短縮率の中央値: 34.2%
インデックスのSQLiteファイル: 164MB / 構築時間27秒

→ 元記事を見る（Zenn・ナレッジセンス）

181万トークンが128万トークンになった。しかも回答の品質は落としていない。ここで私がいちばん唸ったのは、削減率が難易度によって違うという部分でした。

質問の難度	トークン削減率（中央値）	時間短縮率（中央値）
低難度	39.8%削減	35.7%短縮
中難度	31.9%削減	40.6%短縮
高難度	28.5%削減	28.4%短縮

簡単な質問ほど、よく効く。逆に言えば、難しい質問はもともと「探す」より「考える」の割合が大きいので、探し方を直しても伸びしろは小さいということです。当たり前と言えば当たり前。でもこれ、人に仕事を任せる時の設計そのままだと思いませんか。定型作業ほど段取りで効く、判断が要る仕事は段取りだけでは速くならない。

ついでに気持ちよかったのが、インデックスの構築が27秒で終わっているところ。仕込みに1時間かかるなら誰もやらないけど、27秒なら「とりあえずやっとくか」になります。導入のハードルは、効果の大きさより面倒くささで決まるんですよね。

BM25をそのまま持ってきただけでは、コード検索ではうまく効きません。元記事で紹介されていた工夫は3つ。ここが実務家っぽくて、私はいちばん好きな部分です。

1. 識別子を「まるごと」と「分解した語」の両方で検索できるようにした: getUserProfileやsnake_caseのような名前を、そのまま探すのと、get／user／profileに割ってから探すのと、両方できる状態にする
2. 日本語の連続した文字列を2文字ずつに分割した: 「検索精度」なら「検索」「索精」「精度」という形。単語の一部からでも候補を引っ張れるようになる
3. ファイルパスに出てくる語を、本文より強く評価した: ファイル名やディレクトリ名が一致したものを上位に持ち上げる

3つ目が個人的にいちばん腑に落ちました。私たちが自分でコードやフォルダを探す時も、まずファイル名を見るよね。中身を1行ずつ読むのは、名前で当たりをつけた後です。人間が無意識にやっている優先順位を、そのまま検索の重みに書き写した——それだけの話なんですが、こういう地味な写経がいちばん効く。

仕込みでたとえると、玉ねぎをどう切るかの話に近い。みじん切りにしておくか、くし切りにしておくかで、あとの工程の速さがまるで変わる。切り方を決めずに冷蔵庫へ放り込んでおくと、結局は毎回まな板からやり直しになります。

ここで昨日の記事と今日の記事を、一枚に並べておきます。同じ「トークンの無駄」の話に見えて、手を入れている場所が違うんです。

	cclens（前編・計測の道具）	BM25の前段化（今日・探し方の改善）
役割	どこで無駄が出ているかを見つける	見つかった無駄のうち「探す工程」を減らす
見るもの	過去のセッションログ、設定ファイルの重さ	作業中の検索の回数と、読み込んだファイルの量
効くタイミング	作業を始める前（入口のコスト）	作業の最中（探し回るコスト）
実測の効果	セッション開始時に9,097トークンの無駄を可視化	セッション全体のトークンが29.2%削減
厨房でいうと	レシートと在庫表を見る（棚卸し）	冷蔵庫にラベルを貼る（動線の改善）
経営でいうと	どの業務に時間を食われているかを測る	資料を探す時間そのものを構造で削る

片方だけじゃ足りない。計測しないと、どこを直せばいいか分からない。直し方を知らないと、計測しても数字を眺めて終わる。この2本立てで初めて回り始めます。

sasakuna氏（Knowledge Sense, Inc. CTO）

「この役割分担によって、検索効率の改善を実現できたと考えています」

→ 元記事を見る（Zenn・ナレッジセンス）

粗い候補の抽出はBM25へ、詳細な分析はCodexへ。この線引きが省コスト化の鍵だった、という結論です。ぶっちゃけ、この一文だけ持ち帰れば今日は十分だと思っています。

ここは正直に書きます。私は数字で管理するのが得意なタイプじゃない。感覚と勢いでやってきた人間です。だからこの手の記事を読むと、素直にすごいなあと思う一方で、自分の運用の粗さが見えて少し痛い。

思い当たる話があります。cc-booster Proという自分の道具立てを設計していた時、手元には186個のスキルと30個のエージェントが並んでいた。数が多すぎて、正直「どうせ半分は使ってないでしょ」と思っていたんです。整理してスッキリさせたい気持ちが先に立っていた。

ひろくん（田中啓之）

「未使用と決めつけるな」——186スキル＋30エージェントの使用頻度データを実際に集計してから、自分にそう言い聞かせました。

で、実際に使用頻度のデータを集計してみたら、思っていたのとは違う顔ぶれが出てきました。「これは使ってないだろう」と決めつけていたものが、地味に動いていたりする。感覚で削っていたら、たぶん必要なものを捨てていた。

前編でcclensを動かした時も同じでした。9,097トークンという数字は、測るまで一度も意識に上がっていない。今回のBM25の話も、Codexの検索が「Grepだけ」だと言われるまで、私は考えたこともなかったんです。自分の道具の中身を知らないまま使い続けている——これが、私のいちばん直すべきところ。

関連して、CC-Booster Proを声だけでセットアップした時の記録や、AGI CockpitでQoder・Cursor・ローカルQwen・Fleetを試して「どれをいつ使うか」を切り分けた記事も書いています。あの時も結局、触って動かすまで分からないことばかりでした。カタログを読んでいるだけでは、何ひとつ判断できない。

ここまでずっとエンジニアの話をしてきましたが、本質はまったく技術の話じゃないと思っています。今回の結論を一行に潰すと、こうなる。粗く探すのは安い担当に、深く考えるのは高い担当に。

会社の会議を思い出してください。1時間の会議のうち、「あの資料どこだっけ」「前回いくらで見積もったっけ」を探している時間って、どのくらいありますか。私の実感だと、決して短くない。そして探しているのは、たいてい会議でいちばん判断力のある人だったりします。三つ星の料理人が、冷蔵庫の扉を開け閉めしている状態そのもの。

私はAIに指示を出す時、3つのことを自分のルールにしています。

ひろくん（田中啓之）・AI指示設計の三原則

①AIに判断させない
②1タスク1エージェント
③外部AIでクロスチェックする

①の「判断させない」は、まさに今回のBM25と同じ考え方でした。判断が要らない工程——探す、集める、並べる——は、判断力を持たない安い仕組みに寄せる。判断が要る工程だけを、いちばん賢いところに残す。②の「1タスク1エージェント」も同じで、ひとつの相手にあれこれ持たせると、探すことと考えることが混ざって効率が落ちます。

この考え方は、以前「AIに全部やらせる前に、役割を渡そう」という記事でも書いた。あと、800年前の禅僧を引き合いに「AIに任せていい仕事と、任せたら意味がない仕事」を考えた記事もあります。結局どれも同じ話に着地するんだよね。任せ方の解像度が、そのまま成果になる。

そしてAI秘書は「つなぐ」より「任せ方」が難しいという記事で書いたとおり、道具を繋ぐところまでは誰でもいけます。難しいのはその先。何を渡して、何を渡さないか。BM25の話は、その線引きを技術側から証明してくれた事例だと受け取りました。

エンジニアでなくても、今日から手をつけられることがあります。特別な予算は要りません。

1. 「探している時間」を1週間だけ意識してみる: 会議・資料作成・見積もりのうち、探すことに使った時間をざっくりでいいのでメモする。測らないと、そこが太いことに気づけない
2. 探す仕事と、決める仕事を紙の上で分ける: ひとつの業務を「集める」「並べる」「決める」に割ってみる。前2つは仕組みや担当に渡せる部分です
3. 探す側に「ラベル」を用意する: ファイル名の付け方を揃える、よく聞かれることを1枚にまとめておく。BM25がファイルパスの語を重く見たのと、まったく同じ発想でいい

3つ目、地味だけど効きます。うちも記事の下書きファイルの名前をバラバラに付けていた時期があって、探すたびに小さな時間を落としていました。名前を揃えただけで、AIも私も迷わなくなった。仕込みの段階でラベルを貼っておくと、本番でまな板に戻らずに済む——これは厨房でも机の上でも同じです。

前編では、セッションを始めるだけで9,097トークンが消えていることを実測で確かめました。今日の記事は、その先の話。作業の最中にAIが同じコードを何度も読み直す——その探し回るコストが、思っていたより太かった。

ナレッジセンスのsasakuna氏の検証では、Codexの前段にBM25を置くだけで、セッション全体のトークンが29.2%、動作時間の中央値が34.2%改善しています。7,536ファイル・12問という、そこそこ現実的な規模での数字です。効いた理由はシンプルで、粗い候補の抽出を検索に、詳細な分析をAIに、と分けただけ。

これ、AIの話に見えて、任せ方の話なんですよね。探すことと考えることを同じ人に押し付けていないか。判断力のある人が、冷蔵庫の扉を開け閉めしていないか。今週の会議を1つだけ思い出して、そこを確かめてみてください。

測るのが前編、直すのが今日。両方そろって、やっと回り始めます。