Semble - grepよりトークンを98%少なく使うエージェント向けコード検索

 (github.com/MinishLab)
17 ポイント 投稿者 GN⁺ 2026-05-18 | 2件のコメント | WhatsAppで共有
  • エージェントが自然言語・コードクエリで必要なコード断片だけを即座に見つけられるようにしたコード検索ライブラリ
  • grep+read と比べて 約98%少ないトークンを使用し、ファイル全体を読む代わりに関連チャンクだけを返す
  • 平均してリポジトリを約250msでインデックス化し、クエリには約1.5msで応答、CPU上で API キー・GPU・外部サービスなしに動作
  • ベンチマーク結果では 137M パラメータの CodeRankEmbed Hybrid と比べてインデックス化は218倍高速で、検索品質は99%を維持
  • MCP サーバーとして Claude Code、Cursor、Codex、OpenCode および MCP 対応エージェントで利用でき、リポジトリは必要に応じてクローン・インデックス化され、セッション中はインデックスがキャッシュされる
  • Bash ベースの利用にも対応: AGENTS.md や CLAUDE.md に semble search と semble find-related のワークフローを入れられ、Claude Code と Codex CLI のサブエージェントではこの方式を使う
  • CLI はローカルパスと https:// Git URL の両方を受け取れ、path を省略すると現在のディレクトリをデフォルトとして使う
  • Python ライブラリとしても使え、SembleIndex.from_path、SembleIndex.from_git、search、find_related でカスタムツールに検索を統合可能
  • 動作原理:
    tree-sitter によるコード認識チャンク化 +
    Model2Vec(potion-code-16M) の意味埋め込み +
    BM25 の lexical マッチングを RRF(Reciprocal Rank Fusion) で結合
  • 静的埋め込みモデルを使うため、クエリ時にトランスフォーマーの forward pass が不要で、CPU上でミリ秒単位で実行
  • MIT ライセンス

関連記事

2件のコメント

 
GN⁺ 2026-05-18
Hacker Newsのコメント

  • こういうツールを使ってみると、コーダーがAIツールに過度に依存すると馬鹿になるのと同じように、AI自体も馬鹿になる様子が見える
    エージェント型AIは、すでにコード探索や検索でかなり最適化された経路を見つけられる程度には賢いのに、こうしたツールを付けると、検索結果がほぼ常に全体の詳細ではなくポインタだけを返すので、動きが過度にアグレッシブになる傾向がある
    簡単にPiで、ある程度複雑なプロジェクトに対して全体の収集・検索経路を追跡させてみたところ、codebase-memory-mcpは入力・出力トークンが85k/4.4k、普段の設定では67k/3.2k、ツールなしでは80k/3.2kだった
    結果の品質と情報量は同じで、このツールは大差ないどころかむしろ悪化していた
    自分の普段の設定は、AGENTS.mdとCLAUDE.mdに「PROJECT.mdから読め」と1行だけ入れること
    PROJECT.mdには、プロジェクトの2〜3行の説明、関連ファイルと1行説明、注意点、そして「変更する価値があるならこのファイルを更新せよ。このファイルの目的はプロジェクトの大まかな感触を与え、必要ならそこからさらに探索させることだ」というLLM向けの文言だけを置いている

    • 「エージェント型AIはすでにコード探索や検索で高度に最適化された経路を見つけられるほど賢い」という話は、自分の経験とは違う
      職場では以前 Augment Code を使っていて、そこには事前にインデックス化されたコードに対して自然言語クエリへ答える、MCPに近い Context Engine があった
      その後Claude Codeに移ったが、不思議なことに、範囲読み取りツールがあるのに、自分の記憶にある行範囲をもとに sed でファイルを読もうとする
      それが本当に高度に最適化された経路と言えるのかはわからない
    • codebase-memory-mcp と semble はまったく同じものではないが、興味深い比較なので、確認するタスクリストに入れて、できればベンチマークにも追加してみたい
      同じ比較を semble で試す機会があれば、本当に有用なフィードバックになると思う。こういう「実際の」シナリオはベンチマークや再現が難しいので

  • 面白い。自分もこの分野で取り組んでいるが、アプローチは違った
    インデックスを作る代わりに、コードベースと一般テキスト全体に対してランキングとコード構造認識を加えた より賢い grep を作っていて、時間の大半は性能問題への対処に使ったので、非常に高速に動く
    https://github.com/boyter/cs と比較対象として追加して、自分が投げる種類の質問でLLMが何を好むのか見てみたい
    これもMCPを提供するが、検索用インデックスは作らない。デフォルトのBM25ではなくコード意味論的な変種を使っているので、ランキングがどう出るか気になる
    このツールは「認証はどう動くのか」のようなクエリにより向いていそうで、cs は authenticate --only-declarations を行った後、ファイル内容、つまり一致箇所がコードなのかコメントなのか、そしてファイル全体の複雑さに応じて結果へ重み付けをする
    スターは付けたので追っていくつもり

  • このツールがAI向けなのはわかるが、新しいコードベースや自分のコードベースを探索するときに、自分で使ってみることのほうに興味がある
    何かをリファクタリングするために、どこを変えるべきか 全体の輪郭 を見たいときに便利そうだ
    LSPもそういうことはしてくれるが、このツールはもう一段先へ行けそう

  • PiとGPT 5.5でいくつか評価してみた
    RTKオン / headroomオン / 両方オン / 両方オフを試し、すべて標準のPiシステム指示文を使い、AGENTS.md はなかった
    正確にどんなテストだったかは忘れたが、人が使う標準的なエージェント評価をいくつかで、自分が使う言語であるPythonを1つとTypeScriptを1つだった
    徹底したテストだったとか、良いテストだったとは主張しない。1日ほど AGENTS.md とPiのシステムプロンプト・ツール指示を調整していたら、もっと良い結果が出たかもしれない。評価を回しながら学んだことの1つは、そういう微妙な差が結果を大きく変えうるという点だ
    ただし 両方オフ の場合が明確に良く、3ラウンド後にすぐテストを止めるには十分だった
    問題は、コンテキスト使用量は減ることもあったが、完了までのターン数が増えて、会話全体のコストはむしろ高くなったことだ
    こういうツールを共有する人は非常に多いが、評価がまったくないか、再現が怪しいほど難しいか、あるいはこのツールのように多くのベンチマークを行いながら 間違ったものを測っている ケースが多い、という意識を強く持つようになった
    このツールが grep よりトークンを少なく使うのは確かで、ベンチマークもそれを示しているが、重要なのはそこではない。重要なのは、エージェントがこのツールを使って、同じ品質の仕事をより速くより低コストでやり切れるかどうかだ

    • 今のAI業界全体で テスト不足 がある
      このツール固有の問題ではなく、コードベースや開発フローにAIを組み込むあらゆるものの問題だ
      AI以前から「これはどれだけ速く、どれだけうまく開発されたか」を測るテストがなく、今も追加されていない
    • AIでは「できたからやった、やるべきかは考えなかった」が非常に頻繁に起きそうだ

  • 実際の エージェントベンチマーク を見たい。たとえばClaude CodeやCopilot CLIで grep を外してこのツールに置き換えるようなものだ
    RTKと複数のLSP実装を見てきたが、モデルが grep に強く強化学習されすぎていて、別形式の結果を信頼せず、再試行や再読込を繰り返す
    そのせいで、モデルが他のツール結果を信じないため、節約したトークンが全部消えてしまう

    • グローバル CLAUDE.md（~/.Claude 配下）に grep の代わりにLSPを使えと書いておいたら、その後はこの問題はなくなった
    • Codex CLIはRTKをかなりうまく回す。少なくともGPT 5.5 xhighではそうだった
      ただ、find の特定CLIフラグのようなものをサポートしていないとき、コマンドの全出力を送る代わりにエラーメッセージを出すのが気になる
      するとエージェントがトークンを無駄にしながら再試行したり、もっと悪い場合は、プロンプトのせいでRTKなしではコマンドを実行してはいけないと思い込み、試しすらしなくなる
    • こちらもそうしたベンチマークには関心があり、モデルがより使いやすくなるよう プロンプトと説明の最適化 とあわせてロードマップに入っている
      逸話レベルではあるが、こちらも当然このツールを自分たちで使っており、今のところかなりうまく動いている
      Anthropicのモデルは、このツールを呼び出して結果を信頼しているように見える
    • トークン節約はますます重要になっているが、エージェントが結果を信頼して検索を止められるかも重要だ
      検索出力だけを見るのではなく、エージェントの全体ループ を測る必要がある
    • 少なくともCodexは、grep はしばしば遅すぎるので rg を使えと言えば従うが、RTKを追加するとRTK経由で grep を使うので少し苛立つ

  • アイデアが良さそうだったので少し触ってみた
    テストは browsercode（https://github.com/browser-use/browsercode）リポジトリで行い、プロンプトは「semble CLIだけを使って、BrowsercodeがデフォルトのOpenCodeツール以外にエージェントへ提供するツールは何か答えよ。ツール入出力の正確なスキーマと、それが何をしてどう動くかを簡潔に要約せよ」だった
    ここに https://github.com/MinishLab/semble#bash-integration の AGENTS.md 断片を貼り付けた
    Sembleを使わないテストでは、同じ質問を rg と fd CLIだけを使うように変えた
    どちらの場合もPiとgpt-5.4 mediumを使い、他の設定はかなり最小限にした。実際に片方は rg と fd だけ、もう片方は semble だけを使っていたことも確認した
    Sembleなしではモデルコンテキストの10.9%とAPIクレジット$0.144を使い、Semble使用時は9.8%と$0.172を使った
    結果の回答もほぼ同じで、かなり近かった
    OpenCodeリポジトリでももう一度テストし、質問は「OPENCODE_EXPERIMENTAL_EXA 環境変数が1に設定される地点から、OpenCodeエージェントに提供されるシステムプロンプトやツールに現れる結果までの経路を追跡せよ」だった
    上と同じ指示文と文書を含めた
    Sembleでない版のほうが少し詳しく、Web検索プロバイダとしてExaまたはParallelが有効かどうかに応じて、ツール呼び出し経路がExaを呼ぶかも扱っていたが、実際の質問への答えはどちらの版も正確だった
    Semble版はコンテキスト14.7% / APIコスト$0.282、非Semble版は19.0% / $0.352を使った
    コンテキスト効率の面では明らかにSembleの勝ちだったが、非Semble版のほうがだいたい2倍速く終わった点は注目に値する
    もちろん、ただ少し触った程度なので、結果は変わるかもしれない

  • 「grep より トークンを98%少なく使う」というのは、grep がそこまで無駄が多くて、モデルが毎回98%の役に立たないゴミを読んでいると信じろということなのか？
    この主張は代表性がないか、モデルへ渡すコンテキストの大半を捨てることで何か別のものを見落としている気がする

    • 98%は grep 出力だけでなく、grep+readループ との比較だ
      エージェントが見慣れないコードベースに出会うと、普通はまず cat file をしたり、ファイル全体を読む。少なくとも自分の経験ではそうだった
      エージェントに安定して grep -C N だけをやらせて、そこで止まるようにできているなら、その設定は本当に気になる。自分には、その結果品質は有用なコンテキストとして使うには低すぎると思えるからだ
    • Claudeが node_modules に引っかかった項目のせいで数百キロバイトの出力を読む問題があった
      ripgrep が役に立つので、どこかのメモリファイルにそれを使えと1行追加するのは理にかなっている
    • grep は一致したすべての行を出力する
      LLMが検索するとノイズが多くなることがあり、具体的に探せないためにそうした検索をせざるを得ない場合もある
      目標指向の検索 はトークン数を減らせる
      ただ、この比較は必要な部分だけを受け取ることと、コードベース全体を読むことを比べているように見える

  • フィードバックを言うと、codex-cli がMCP経由でこれを呼ぶと止まる
    semble プロセスもゾンビのように残って永遠に止まったままだ。理由はわからず、ログにも何も出ない
    スキル経由でCLI呼び出し方式にすると、GPT 5.5が ripgrep に慣れているように、検索語をものすごく大量に投げようとする
    これがどれだけ効果的かはわからず、GitHub上の短い文書とエージェント指示文だけでは何が最適か明確ではない
    最後に、bash用にインストールするときGitHub外部接続関連のエラーも何度か出た。停止と関係があるかはわからない
    さらに、自分のエージェントは続けて ripgrep も使おうとするので重複しているように見える。信頼の問題があるかのように振る舞っている
    もっと詳しい エージェントスキルの説明 があれば、エージェントを正しい使い方へ誘導できそうだ

    • 詳しいフィードバックありがとう
      バグについては、設定の詳細つきでIssueを立ててもらえると助かる。これは確実に調査して修正したい部分だ
      複数クエリを投げる問題も本当に良いフィードバックで、こうしたことが起きないようプロンプトと指示文を更新し、関連テストも追加してみる
      インストール中の外部接続エラーは、uv がPyPIから依存関係を取得するときのものだと思われ、停止の原因ではないはずだ

  • 良さそうなアイデアだ
    関連する問題を1つ挙げると、小さなコードベースではClaudeがコードベース全体を一度にコンテキストへ入れて、ごく少ないトークンで処理できるのに、何かを探すために多くの時間を使ってしまうことがある
    妥当な回避策は、開始フックでディレクトリ全体をコンテキストに入れてしまうことだ
    そうするとClaudeは各タスクで「暗闇を手探りする」区間を飛ばせる
    もっと大きいリポジトリ向けに、モデルへスタブ付きの概要を与える素晴らしいプロジェクトも見たことがあるが、名前は忘れた

    • aiderかも？ https://aider.chat/2023/10/22/repomap.html
    • その通りだ。エージェントは、自分が見ているもの、たとえばファイル数やファイルサイズのような情報をあまり把握していない
      ただ、小さなコードベースなら探したいものも見つけやすいので、検索はそれでもコスト削減に役立つ可能性がある

  • こうした解決策のより大きな問題は、たいていのAIが学習のおかげで、すでに grep や検索を非常にうまく使えることだ
    AIに新しいツールを渡すと、そうしたツールはAIの 認知能力 を一部奪ってしまう
    人間なら普通はそういうツールの使い方を「学習」するが、LLMの学習は固定されており、すでに grep のような既存ツールに非常に深い熟練を持っている
    たとえばAIは、tree のようなLinuxコマンドでコードベースを探索する方法もすでに知っていて、これも十分に学習済みだ
    もう1つの問題は、こうしたツールの有用性を示す例を作るのは簡単だが、そのツールが引き起こす認知的欠損を長期実行での有用性が相殺することを、実際に証明するのは難しいということだ
    自分の第一印象では、長期実行では デプロイ可能な知能 が純減となり、エージェントは既存ツールを使う場合より悪化する気がする
    その逆を証明するのは些細な問題ではないが、もしかすると挑戦する価値のある課題かもしれない
 
roxie 2026-05-25

本文と直接関係のあるコメントではありませんが、

AIでは「できたからといって、やるべきかどうかは考えなかった」ということが、非常によく起こりそう

この一文は、あとあとまで考えさせられそうです