semble_rs: AI agent の grep、ls、CI ノイズをまとめて薄くする

このところ AI coding agent 周辺の tool を見ていると、だんだんはっきりしてくる現実があります。

多くの token は「推論」そのものではなく、agent が environment を雑に読むことに消えている。

最初に ls -R で repository 全体を広げる。次に grep で大量の候補を拾う。さらに file 全文を cat する。最後に build や CI を回して、数 MB の log をそのまま context に入れる。

Codex、Claude Code、Cursor を本気で日常投入しているなら、これはすぐに現実的なコストになります。

今日メモしておきたい johunsang/semble_rs は、まさにこの流れに手を入れる project です。新しい chat shell を作るのでも、常駐 service を立てるのでもなく、コード検索、コードツリー要約、依存・影響分析、build/CI ログ圧縮 を 1 つのローカル Rust binary にまとめ、agent が本当に source を開く前に、もっと安い構造ビューを取れるようにします。

GitHub repository page、release page、公開 commit 履歴、README を 2026-07-01 時点で確認すると、この project は 136 stars、20 forks。主言語は Rust、license は MIT です。公開 commit 履歴の起点は 2026-05-12、直近の公開更新は 2026-06-02。最新 release は v0.9.1 で、公開日は 2026-05-15 です。

Project overview

項目	内容
Repository	johunsang/semble_rs
位置づけ	AI coding agent 向けローカル code retrieval / context compression CLI
Stars	136
Forks	20
主言語	Rust
公開 commit 起点	2026-05-12
直近の公開更新	2026-06-02
Latest version	v0.9.1
Release date	2026-05-15
Code license	MIT
中心の発想	構造検索と log 要約で、agent の全文乱読を減らす

これは「context budget」を 1 つの問題として扱っています

semble_rs でいちばん面白いのは、単に「また 1 つ code search tool が増えた」ではないところです。

この project は、もともと別々に見えがちな痛点を、同じ問題としてまとめています。

• まず repository の輪郭をどう見るか;
• コードを全文ではなく、先に意味ベースでどう絞るか;
• 編集前に依存関係と影響範囲をどう見るか;
• build や CI の log をどう薄くして読むか。

README の自己定義もかなり明快です。AI coding agent 向けの Rust tool であり、grep、cat、read、ls の一部を置き換えつつ、build と CI output を圧縮すると書いてあります。

この整理はかなり正しいと思います。

agent が高くつくのは、最後の精読だけではありません。むしろ前段の探索が荒いことの方が痛いです。

1. まず directory tree を丸ごと広げる;
2. 次に全文検索する;
3. さらに file を丸ごと開く;
4. 最後に大量の test / build / CI log を読む。

semble_rs は、この一連の行為を agent 向けに細くしようとしています。

tree、search、digest の三本柱が分かりやすいです

代表的な command は次の通りです。

semble_rs tree ./my-project --symbols
semble_rs search "how is auth handled" ./my-project --outline
cargo build 2>&1 | semble_rs digest

この 3 つは、それぞれ別の context waste に対応しています。

1. tree は「最初から repository 全体を膨らませない」

README にある通り、実際の project で ls -R をやると .git/、target/、node_modules/ まで一緒に出てきます。人間にも noisy ですが、agent にとってはもっと高いです。

semble_rs tree は gitignore-aware な index を使い、

• directory だけを見る;
• 深さを制限する;
• file ごとの top-level symbol を添える;
• 言語で絞る;

といったことができます。

README 自身の benchmark では、この repository の tree 出力は 533 B、ls -R は 398,101 B で、自報では 747× の縮小です。より大きな Python backend でも数十倍規模の差が出ています。

もちろん、これは project 側の測定なので、そのまま普遍値として受け取るべきではありません。ただ、方向性はとても妥当です。

最初に見る「地図」を薄くするだけで、agent の初手はかなり改善されます。

2. search は「全文 grep + file 丸読み」を減らす

semble_rs search は単純な keyword search だけではありません。README によると、内部では次の要素を組み合わせています。

• tree-sitter による chunking;
• BM25;
• Model2Vec の static embedding;
• RRF による融合;
• code-aware rerank。

しかも ranking signal もかなり実務的です。

• symbol らしい query は lexical 寄りにする;
• 自然言語 query はより balanced に扱う;
• 定義位置を boost する;
• identifier stem、同一 file の coherence、隣接 chunk、dependency 関係を加味する;
• test、legacy、.d.ts など noise になりやすい場所は下げる。

私が好きなのは、algorithm より出力の分け方です。semble_rs は結果を何段階かに分けています。

• --outline: まず構造だけ見る;
• --group: directory 単位でまとめる;
• --compact: 精密に絞る;
• --json --strip: 本当に必要なときだけ chunk body を取る。

これは agent にかなり向いています。

必要なのは「もっと大量の text」ではなく、

先に安い view、次に狭い展開、最後に必要部分だけ本文

という順番だからです。

find-related、plan、find-pattern があるのも面白いです。特に plan は、agent がどこから触ればいいか分からないときに、軽い search の上で次に使う command を提案します。oracle ではありませんが、探索順そのものを支援対象にしているのは良い設計です。

build / CI log を一等市民として扱っているのが珍しいです

code search tool は多いですが、semble_rs で特に見分けやすいのは digest です。

gh run view <id> --log-failed | semble_rs digest
pnpm install 2>&1 | semble_rs digest
pytest 2>&1 | semble_rs digest

README の方針は明快です。

• error、file:line:col、traceback、panic stack、failed step body は残す;
• progress line や反復ノイズは折りたたむ。

対応 format も広く、cargo、pnpm/npm/yarn/bun、tsc、pytest、go test、gradle、ruff、mypy、clang/gcc/cmake/make/swiftc、GitHub Actions などが挙がっています。

agent に debug を任せることが増えているなら、これはかなり効きます。

問題は agent が log を読めないことではなく、

• log が長すぎる;
• failure signal の密度が低い;
• 進捗ノイズが context を埋める;

ことが多いからです。

README の benchmark では、実際の GitHub Actions failed log を 3.3 MB から 35 KB へ圧縮し、自報では -98.9% としています。この数値も project 自身の測定として読むべきですが、少なくとも作者が CI output compression を agent workflow の本筋 と見ているのははっきりしています。

deps と impact は編集前の確認に向いています

semble_rs は「コードを探す」だけで止まりません。

semble_rs deps src/auth.rs ./my-project --tree
semble_rs impact src/auth.rs ./my-project --tree

この 2 つはそれぞれ、

• その file が何を import / define しているか;
• その file を触ると何に波及するか;

を見る command です。

v0.9.1 では deps/impact --tree が ASCII dependency tree を出せるようになっていて、terminal 上でそのまま読めます。

これは agent にとってかなり重要です。

本当に知りたいのは「目標 file はどこか」だけではなく、

• 共有 module なのか;
• どの call-chain にぶら下がっているのか;
• 触る前に影響範囲をどこまで見ておくべきか;

だからです。

この段階を毎回 grep、IDE の参照検索、断片的な shell command で済ませると、agent は変更途中でようやく広い影響に気づく、ということが起きがちです。

「single binary / no daemon / no API key」は重要な性格です

README は何度も次を強調しています。

• single binary;
• no daemon;
• no API keys;
• no GPU;
• default embedder は minishlab/potion-code-16M で、初回実行時に HuggingFace から約 60 MB を取得。

これは地味ですが、とても重要です。

agent 向け retrieval tool は、すぐに重い方向へ伸びがちです。

• 常駐 process;
• 別 index service;
• remote API;
• 追加の infra と permission 管理。

semble_rs はそこへ行かず、

ローカル shell の一回性と composability を保ったまま、context を前処理する層

に留まろうとしています。

個人開発者や小さな team には、この形の方が実際には導入しやすいはずです。

境界もかなり正直です

この project が信用しやすいのは、限界を隠していないことです。

まず benchmark。100-query benchmark では project 自報で、

• Recall@1 は 70%;
• Recall@5 は 90%;
• Korean query の R@1 は 10%。

つまり「どんな query でも一発で当たる万能 search」とは言っていません。

次に plan。README では guardrail であって oracle ではないと明記されています。

さらに find-pattern には ast-grep が必要です。つまり何でも内製黒箱に押し込まず、合うところは外部 tool に寄せています。

AI agent tool で本当に危ないのは、能力が少ないことより、不確実さを確実さのように見せることです。その点で semble_rs は比較的節度があります。

どんな人に向くか

特に相性が良さそうなのは次のような人です。

• Codex、Claude Code、Cursor をすでに高頻度で使っている;
• grep + cat + ls -R + 長大 log の context waste を減らしたい;
• service 化された retrieval system ではなく、ローカル CLI を好む;
• 編集前に dependency と impact を見たい;
• build、test、CI output を agent に読ませる機会が多い。

逆に、たまに symbol 名を手で探すだけなら IDE で十分なこともあります。

でも、agent workflow を本格的に回し始めると、こうした context を先に整える tool の価値はかなり上がります。

まとめ

johunsang/semble_rs の面白さは、Rust 製 semantic code search を作ったことだけではありません。

この project が本当に扱っているのは、もっと日常的な問題です。

• agent にもっと賢い model を足す前に;
• まず agent に渡す入力を、もっと安く、もっと薄く、もっと段階的にできないか。

tree は repository map を薄くし、search は全文乱読を減らし、deps と impact は編集前の関係を見せ、digest は最も膨らみやすい build / CI output を圧縮します。

実プロジェクトで coding agent と長く付き合う段階に入っているなら、semble_rs が触っているのは周辺機能ではありません。

agent に何を読ませるかを先に整えること自体が、もう重要な engineering です。