ハクソク

世界を動かす技術を、日本語で。

Show HN: Semble – grepより98%少ないトークンを使用するエージェント向けコード検索

8日前原文(github.com)

概要

Semble はエージェント向けの超高速・高精度なコード検索ライブラリ。 grep+read より約98%トークン効率が良く、全工程がCPUのみで完結。 Claude Code, Cursor, Codex, OpenCode 等のMCP対応エージェントで即利用可能。 インデックス作成・検索ともに極めて高速（大規模リポジトリでも秒単位）。 APIキー・GPU・外部サービス不要のゼロセットアップ。

Semble：エージェントのための超高速コード検索

  • Semble は、エージェントが必要とするコードスニペットを即座に返すコード検索ライブラリ
  • grep+read 方式と比べ、約98%少ないトークン消費で必要な文脈のみ返却
  • インデックス作成 ・ 検索 ：平均250ms/1.5ms（全てCPU上で動作）
  • MCPサーバー または Bashツール として利用可能
  • APIキー不要、 GPU不要、 外部サービス不要 のシンプル構成

主な特徴

  • インデックス作成速度：平均リポジトリで約250ms
  • 検索応答速度：1.5ms（CPUのみ）
  • トークン効率： grep+read 比で約98%削減
  • 精度：NDCG@10 = 0.854（コード特化型トランスフォーマーモデルの99%相当）
  • MCPサーバーとしてClaude Code, Cursor, Codex, OpenCode等に即時連携
  • ローカル/リモート（git URL）両対応、変更検知時は自動再インデックス

セットアップと利用方法

  • MCPサーバーとして利用
    • uv パッケージが必要
    • Claude Code: claude mcp add semble -s user -- uvx --from "semble[mcp]" semble
    • Codex, OpenCode, Cursor: 各設定ファイルにコマンド・パラメータを追加
  • Bash統合
    • pip install semble または uv tool install sembleでインストール
    • AGENTS.mdやCLAUDE.mdにコード検索スニペットを追記
    • 例：
      • semble search "authentication flow" ./my-project
      • semble find-related src/auth.py 42 ./my-project
  • CLIとしても単独利用可能（MCP不要）

ワークフロー例

  • semble searchで関連コードチャンクを高速抽出
  • 返却されたチャンクで文脈不足の場合のみファイル全体確認
  • 必要に応じてsemble find-relatedで関連実装を探索
  • 完全一致や文字列確認のみgrep併用

機能詳細

  • search ：自然言語またはコードクエリでコードベース検索
  • find_related ：指定ファイル・行番号に類似するコードチャンク抽出
  • savings ：トークン節約量を可視化（期間別・コール種別で集計）
  • 更新 ：pip install --upgrade sembleやuv tool upgrade sembleで簡単アップデート
  • Python API ：
    • SembleIndex.from_path("./my-project")でローカルディレクトリをインデックス化
    • SembleIndex.from_git("https://github.com/MinishLab/model2vec")でリモートリポジトリも対応
    • index.search("save model to disk", top_k=3)で自然言語検索
    • index.find_related(results[0], top_k=3)で類似コード抽出

仕組み・アルゴリズム

  • Chonkie でファイルをコード認識型チャンクに分割
  • Model2Vec（potion-code-16M） による静的埋め込み＋ BM25 による識別子・API名のレキシカルマッチ
  • RRF（Reciprocal Rank Fusion） で融合し、コード特有のシグナルで再ランク
    • シンボル定義の優先表示
    • 識別子ステムによる追加重み付け
    • 複数チャンク一致時のファイル単位ブースト
    • テスト・レガシー・ダミーコードのノイズ低減
  • 全処理がCPUで完結、ミリ秒単位のレスポンス

ベンチマーク・トークン効率

  • 63リポジトリ・19言語・約1250クエリで評価
    • Semble：NDCG@10=0.854、インデックス263ms、クエリ1.5ms
    • CodeRankEmbed Hybrid（137Mパラメータ）と比較し99%の精度・218倍の速度
  • トークン削減例：
    • grep+read：100kトークン必要→Sembleは2kトークンで94%リコール達成
    • 実際の節約量はsavingsコマンドで確認可能

ライセンス・引用

  • MITライセンス
  • 論文・研究利用時の引用形式： 
    @software{minishlab2026semble,
  author = {{van Dongen}, Thomas and Stephan Tulkens},
  title = {Semble: Fast and Accurate Code Search for Agents},
  year = {2026},
  publisher = {Zenodo},
  doi = {10.5281/zenodo.19785932},
  url = {https://github.com/MinishLab/semble},
  license = {MIT}
}

参考リンク・フィードバック

  • GitHub: https://github.com/MinishLab/semble
  • ベンチマーク: https://github.com/MinishLab/semble/tree/main/benchmarks
  • モデル: https://huggingface.co/minishlab/potion-code-16M
  • フィードバック・質問：IssueまたはGitHub Discussionsで受付

Hackerたちの意見

実際のエージェントのベンチマーク（例えば、grepを外してこのツールを使ったCCやCopilot CLI）を見てみたいな。例えば、RTKやいろんなLSPの実装を試してみたけど、モデルがgrepにかなり依存してるから、他の形式の結果を信頼しないんだよね。だから、何度も再試行したり読み直したりして、他のツールの結果を信じないせいでトークンの節約が全くできない。

└

そうそう、これやるのも興味あるんだ。プロンプトや説明の最適化と一緒にロードマップに入ってるから、モデルが使いやすくなると思う。ちょっとした話だけど、もちろんこのツール自体も使ってて、今のところ結構うまくいってるよ。Anthropicのモデルもこれを呼び出して、結果を信頼してるみたい。

└

ClaudeにRTK用のグローバルメモリと自分のAIメモリシステム（GuardRails）を使わせるように強制したんだけど、両方ともちゃんと使ってくれてる。GuardRailsを全く言わないときだけ使わないけど、そうじゃなければRTKを使うし、RTKがサポートしてないツールを動かすときに壊れない限りはずっとRTKを使うよ。

└

Codex CLIはRTKを使うのがすごく好きみたい。まあ、GPT 5.5 xhighの時はね。ただ一つイライラするのは、例えばfindのCLIフラグがサポートされてないときに、エラーメッセージを出すんじゃなくて、コマンドの全出力を送らないこと。そうなるとエージェントがトークンを無駄に使って再試行したり、最悪の場合、プロンプトのせいでコマンドを実行するのを怖がって全く試さないこともある。

└

~/.Claudeの下にあるグローバルCLAUDE.mdに、grepの代わりにLSPを使うようにお願いする文を入れたら、それ以降この問題は全く起きてないよ。

明らかにgrepよりはいいけど、既存のLSPと比べてどうなの？

└

それか、ckみたいなツールもあるよ: https://beaconbay.github.io/ck/

https://maki.shのインデックス機能も好きだな。ソースコードには結構構造があって、grepやファイルを読む代わりに本物のパーサーを使うことで、トークンをかなり節約できる可能性がある。

PiとGPT 5.5でいくつか評価をやってみたよ。RTKをテストしたり、ヘッドルームをオンにしたり、両方オン、両方オフにしたり（すべて標準のPiシステムの指示で、AGENTS.mdは使わなかった）。具体的にどんなテストをしたかは忘れちゃったけど、一般的に使われるエージェントの評価をいくつかやったかな。PythonとTypeScriptのテストをしたのは、俺がそれを使ってるから。 exhaustiveなテストだったとは言わないし、良いテストとも思ってない。AGENTS.mdやPiシステムのプロンプト/ツールの指示を調整するのに1日くらいかければ、もっと良い結果が出たかもしれない。評価をやってみてわかったのは、微妙な違いが結果を大きく変えることがあるってこと。ただ、両方オフにした時の結果が明らかに良かったから、3ラウンドやった後にテストをすぐにやめることにした。問題は、コンテキストの使用は減ったけど（時々）、完了までのターン数が増えたから、会話全体のコストが高くなったこと。これで気づいたのは、たくさんの人がこういうツールを共有してるけど、評価がゼロだったり（再現が難しいものもある）、このツールの場合は間違ったことをテストしてるベンチマークが多いってこと。確かにこのツールはgrepよりもトークンを少なく使うけど、そこが重要じゃない。重要なのは、そのツールを使ったエージェントが同じ質の仕事をより早く、低コストでできるかどうかだね。

└

AIに関しては、「できるから、考えもしない」ってことがすごく頻繁に起こるだろうね。

いいね、これは素晴らしい。関連する問題を一つ挙げたいんだけど、小規模なコードベースだと、Claudeが必要なものを探すのにすごく時間がかかるんだ。全コードベースを一度にコンテキストに入れれば、トークンもほとんど使わないのにね。いい解決策を見つけたんだけど、スタートアップフックとして全ディレクトリをコンテキストに入れればいいんだ。そうすれば、Claudeは毎回「暗闇の中で手探りする」部分をスキップできるよ。（大きなリポジトリで動作する素晴らしいプロジェクトも見たけど、名前は忘れちゃった。）

└

もしかしてaiderかな？ https://aider.chat/2023/10/22/repomap.html

└

それは本当だね。エージェントは見ているものについてあまり知らないことが多い。例えば、ファイルの数やサイズとか。でも、小規模なコードベースの場合は、探したいものが簡単に見つかるから、コストに関しては検索が役立つかもしれないね。

面白いアイデアだと思ったから、ちょっと遊んでみることにした。テストしたのは、browsercodeのリポジトリ（https://github.com/browser-use/browsercode）で、以下のプロンプトを使ったよ。「この質問に答えるのは、semble CLIだけを使って：> Browsercodeがエージェントに提供するツールは、基本のOpenCodeツール以外に何がある？ ツールの入力と出力の正確なスキーマを提供し、それらが何をするのか、どう機能するのかを簡単にまとめて。」 それに対する非-Sembleのテストは、「この質問に答えるのは、rgとfd CLIだけを使って：> Browsercodeがエージェントに提供するツールは、基本のOpenCodeツール以外に何がある？ ツールの入力と出力の正確なスキーマを提供し、それらが何をするのか、どう機能するのかを簡単にまとめて。」両方のケースで、Piをgpt-5.4のミディアムで使って、他は非常に最小限の設定にしたよ。（もちろん、どちらのインスタンスもrgとfdだけを使っていることを確認した。）Sembleなしでは、モデルコンテキストの10.9%を使って、APIクレジットは$0.144だった（少なくとも、Piがそう報告したから、Codexサブを使っているから確実ではないけど）。Sembleを使った場合は、モデルコンテキストの9.8%を使って、APIクレジットは$0.172だった。結果のレスポンスもほぼ同じだった。すごく近い！もう一つ、OpenCodeリポジトリでテストを試みた。質問は、> OPENCODE_EXPERIMENTAL_EXA環境変数が1に設定されてから、OpenCodeエージェントに提供されるシステムプロンプトやツールにどんな影響があるかを追跡せよ。上記と同じ指示/ドキュメントを含めた。非-Semble版は少し詳細だったけど、ツール呼び出しパスがExaを呼び出すかどうかは、ExaまたはParallelがウェブ検索プロバイダーに対して有効かどうかに基づいていた。でも、質問に実際に答える点では、両方のバージョンが正確だった。Semble版は14.7%のコンテキストを使って$0.282のAPIコスト、一方非-Semble版は19.0%で$0.352だった。コンテキスト効率ではSembleが明らかに勝ってるけど、非-Semble版はSemble版の約2倍速で終わった。もちろん、これはただの遊びだから、結果は人それぞれだね。

└

わあ、すごい！シェアしてくれてありがとう！これは本当に役立つし、私たちが近い将来やりたい実験にすごく似てるね。

こういうセマンティック検索ツールには懐疑的だった。エージェントはすでにgrepで素晴らしい働きをしているし、問題はこれらの検索ツールが特定のコードを目的地として扱うことだと思う。でも、実際にはコードベースはグラフで、エージェントは検索用語の周りにもっとコンテキストが必要なんだ。幸いなことに、コードのグラフトラバーサルはLSPによって長い間解決されている。でも、LSPは非常にメモリ効率が悪い。そこで、cx[0]を作って、LSPの膨張を取り除いて、エージェント用の軽量ナビゲーションツールにしたんだ。HNでシェアする時間がなかったけど、そろそろ投稿する時かもしれない。[0] https://github.com/ind-igo/cx

面白いね。私もこの分野で作業してるけど、違うアプローチを取ったよ。インデックスを作るのではなく、コードベース（実際にはどんなテキストコンテンツでも）に対してランキングと構造的な認識を持った「スマートなgrep」を作ることに取り組んだ。ほとんどの時間はパフォーマンスに費やしたから、すごく速く動くよ。これをhttps://github.com/boyter/csに比較として追加しようと思ってる。私が質問するタイプの質問に対して、LLMが何を好むかを見るのが楽しみだ。これもMCPと一緒に出荷されるけど、検索用のインデックスは作らない。基本的なBM25を使わずにコードのセマンティックバリアントを使うから、どのようにランク付けされるかが非常に興味深い。これは「認証がどう機能するか」というスタイルのクエリにはうまくいくようだけど、csは「authenticate --only-declarations」を行って、ファイルの内容に基づいて結果を重み付けする。つまり、コード内の一致、コメント、ファイル全体の複雑さに基づいている。スターを付けて、これからも注目するよ。

私がこういうツールで個人的に観察したのは、AIを愚かにすることだね。AIツールに頼ることでコーダーが愚かになるのと似てる。これらのエージェントAIは、すでにコードの探索や検索のための非常に最適化されたパスを見つけるのに十分賢い。でも、これらのツールを使うと、彼らは非常に攻撃的になる。なぜなら、これらのツールからの検索結果はほぼ100%の場合、詳細を提供せず、ただのポインターだけだから。これを確認するために、小さなテストを実施した。これは決定的ではないけど、結果は私が観察してきたことと一致している。--- タスク：ある程度複雑なプロジェクトでの完全な取り込みと検索パスを追跡する。使用したのはPi。1. 「codebase-memory-mcp」を使った場合：85k/4.4k（入力/出力トークン）。2. 自分の通常の設定を使った場合：67k/3.2k。3. これらのツールなしの場合：80k/3.2k。見ての通り、こういうツールは悪化させた（大きくはないけど、やっぱり）。出力の質や情報内容は同じだった。--- さて、私の「通常の設定」とは何かというと？AGENTS.mdとCLAUDE.mdに書いた一行だけ。「最初にPROJECT.mdを読んでください。」PROJECT.mdには、プロジェクトの2-3行の説明、関連ファイルとその一行の説明、注意点が含まれていて、最後にこの行で終わる。「## LLM 変更した内容がここに更新する価値がある場合は、このファイルを更新してください。」このファイルの目的は、プロジェクトの大まかなアイデアを提供し、必要に応じてさらに探索できるようにすることだよ。