sweet-search：AI agent に local code search の足場を渡す
AI coding agent が code を探すとき、かなり素朴な loop に戻りがちだ。まず grep し、file を読み、また grep し、さらに file を読む。
この loop は動くが、安くはない。grep が返すのは string match であって、answer ではない。agent はどの file を開くべきか、どの match が noise なのか、同じ function の call chain を十分に見たのかを自分で判断しなければならない。codebase が大きくなり、命名が揺れるほど、context はすぐ埋まる。人間にとって search は定位のための動作だが、agent にとって search result の形はその後の reasoning cost に直結する。
今日メモしておきたい mrsladoje/sweet-search は、そこに向けた小さな tool だ。local code search を agent が扱いやすい六つの interface、search、grep、find、semantic、trace、read に分けて提供する。README の主張は明快で、raw grep output をそのまま agent に渡すのではなく、ranked、compressed、token-budget aware な result を渡す。optional な MCP server もあり、Claude Code、Codex、Gemini CLI、Cursor 向けの agent prompt injection も用意されている。agent が編集を始める前に、より安定した search reflex を持たせるための tool だ。
2026-07-12 時点で GitHub repository API、README、release API、tags API、commits API、languages API から確認できる公開情報では、mrsladoje/sweet-search は 21 stars、0 forks。主言語は JavaScript、license は Apache-2.0。repository 作成日は 2026-02-06 18:14:57 UTC、最近 push は 2026-07-08 22:16:31 UTC。default branch main の現在の最新 commit は 5d84770b、commit time は 2026-07-08 22:16:26 UTC。GitHub Releases page で latest release とされているのは v2.6.9 で、公開時刻は 2026-07-03 10:18:00 UTC。Tags page の最新 tag は v2.6.17、日付は 2026-07-08 だ。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | mrsladoje/sweet-search |
| 位置づけ | AI coding agent 向けの local code search / retrieval tool |
| Stars | 21 |
| Forks | 0 |
| 主言語 | JavaScript |
| ライセンス | Apache-2.0 |
| リポジトリ作成日 | 2026-02-06 18:14:57 UTC |
| 最近 push | 2026-07-08 22:16:31 UTC |
| 最新 main commit | 5d84770b、2026-07-08 22:16:26 UTC |
| Latest GitHub release | v2.6.9 |
| 最新 tag | v2.6.17 |
| 主な機能 | CLI、MCP server、hybrid retrieval、indexed grep、semantic search、trace/read tools、agent prompt injection |
agent に grep を上手くさせるのではなく、grep 回数を減らす
sweet-search の install path は普通の CLI に近い。npm install -g sweet-search で入れ、repository に移動して sweet-search init と sweet-search index を実行する。その後は “where do we validate JWT tokens?” のような natural-language query を直接投げられる。default usage では API key は不要で、README は index と model が local machine 上で動くことを強調している。
面白いのは、「また一つ code search command を作った」ことではなく、output surface を agent 向けに作り直している点だ。README では六つの tool が分かれている。search は general retrieval、grep は faster string match、find は file discovery、semantic は natural language to code、trace は call / relationship、read は controlled file reading の入口だ。agent にとっては、巨大な grep output 一つより、この方が使いやすい。段階ごとに違う tool を選べるからだ。
これは日常の pain に近い。agent が bug を直す前に必要なのは、validate を含む全行ではなく、「おそらく関係がある数個の code span と、その関連度」だ。search tool が token budget を意識して返し、keyword、semantic、structural relation を分けて扱えるなら、agent は無駄に file を読み散らかしにくくなる。
hybrid retrieval と local index が主線
sweet-search の README は hybrid retrieval を明示している。BM25F lexical、dense semantic、structural graph signal を query 時に fuse し、その後 rerank する。indexed grep も一級の機能として扱われており、embedding だけに寄せていない。code search ではこれは大事だ。semantic similarity が exact symbol match より常に信頼できるわけではない。function name、config key、error code、environment variable のようなものは、正確な match が欲しい場面が多い。
repository には JavaScript、Rust、Python、Shell、Objective-C が含まれている。GitHub languages API では主言語は JavaScript だが、crates、native、mcp、packages、core などの directory があり、単なる frontend script ではない。README では local reranking、SIMD kernel、GPU accelerated indexing、Apple Metal、CUDA、CoreML Neural Engine、CPU fallback も触れられている。これらをそのまま性能保証として受け取る必要はないが、少なくとも作者はこれを vector-store demo ではなく search engine として作ろうとしている。
incremental indexing も注目したい。README は index が working tree に追従し、uncommitted edits も扱うと説明している。agent workflow ではこれは重要だ。agent は未 commit の branch 上で複数 file を連続して変更することが多い。search が前回の full index だけを見るなら、agent は古い構造を読むかもしれない。index が現在の working tree に追従するなら、後続の search は実際の状態に近づく。
agent prompt injection は少し強いが、方向は合っている
sweet-search は command だけを渡して、あとは user が agent に使い方を教える、という形ではない。init は tool-routing prompt を CLAUDE.md、AGENTS.md、GEMINI.md、Cursor rules などに注入できる。session-start prewarm hook を登録し、Claude Code に /sweet-index skill を入れることもできる。このやり方は少し強い。project 内の agent instruction file を変更するからだ。ただ、tool の目的から見ると筋は通っている。agent に search discipline がなければ、すぐ grep と大量 read に戻ってしまう。
最近の tag message からも、作者が agent behavior をかなり調整していることが分かる。v2.6.17 は P2 fix-surface agent guide、trace correctness、C++ graph coverage が中心で、v2.6.16 は verdict-gated trust agent guide を調整している。普通の user には地味な release headline だが、AI coding workflow では意味がある。project は「agent が search result を見た後、次に何をするべきか」も product の一部として扱っている。
これは sweet-search の特徴であり、同時に caveat でもある。完全に中立な grep replacement ではなく、明確な workflow assumption を持つ tool だ。すでに自分の AGENTS.md 規約を持っている project では、まず小さな repository で試し、injection が既存 workflow と衝突しないか確認した方がいい。
MCP があるので一つの editor に閉じない
README では sweet-search が MCP server を提供でき、同時に CLI としても使えることが示されている。これは特定 editor の plugin だけを作るより扱いやすい。CLI は Codex や Claude Code のように shell を実行できる agent に向いている。MCP は search capability を structured tool として client に見せたい環境に向く。prompt injection は「いつ使うべきか」という strategy layer を担当する。
この分離は実用的だと思う。search engine、local index、agent call interface、agent behavior prompt が、それぞれ違う問題を解いている。AI coding support tool の中には最後の layer だけを作り、「まず search してください」という prompt を増やすものも多い。しかし底の tool が grep だけなら、結局 agent の負担は残る。sweet-search は少なくとも underlying retrieval も補おうとしている。
team で試す場合にも、この構造は助かる。まず CLI だけを local agent に渡す。結果がよければ、MCP server をより統一された agent environment に接続する。automatic prompt injection が気に入らなければ、manual call path だけを残すこともできる。小さな tool は、最初から全移行を要求すると試されにくい。sweet-search の入口は比較的分解しやすい。
向いている場面
第一の場面は、すでに AI coding agent を使っていて、context search のために grep/read round が多すぎると感じている場合だ。sweet-search の狙いは、その round をより structured な search result に圧縮することにある。
第二の場面は、codebase がある程度大きく、traditional grep の hit が多すぎるが、source code を external SaaS code search に渡したくない場合だ。sweet-search の default path は local index と local model なので、private repository の実験に向いている。
第三の場面は、agent に keyword、semantic、structural relation の入口を同時に渡したい場合だ。grep、semantic、trace、read が分かれているため、一つの natural-language search box だけより制御しやすい。
第四の場面は、agent prompt を調整することに抵抗がない場合だ。sweet-search の価値の一部は search discipline にある。AGENTS.md などを tool に触らせたくない場合は、init option を慎重に見た方がいい。
注意したいところ
第一に、project はとても小さい。21 stars、0 forks で、commit と tag は活発だが ecosystem feedback はまだ少ない。採用するなら version pin し、重要でない repository で比較テストするのがよい。
第二に、release state は少し分かりにくい。GitHub Releases page の latest release は v2.6.9 だが、Tags page は v2.6.17 まで進んでいる。この記事で両者を分けて書いたのは、automation、package version、GitHub release badge が別々の「latest」を見る可能性があるからだ。
第三に、local model と index は free ではない。README は CPU、GPU、CoreML path に触れ、model download と cache footprint も説明している。large repository では first indexing、incremental maintenance、disk usage を実測したい。
第四に、prompt injection は review すべきだ。agent の search strategy に影響するので、長所にもなるし、team の既存規約と衝突する可能性もある。特に厳密な AGENTS.md を持つ project では、無条件に init しない方がいい。
まとめ
sweet-search が面白いのは、「agent の grep を速くする」だけで終わらず、code search を agent loop の中でより明確で、token-efficient で、audit しやすい一連の action にしようとしている点だ。
agent が codebase の中で迷いがちなら、あるいは local semantic / code graph retrieval が無駄な file reading を減らせるか試したいなら、mrsladoje/sweet-search は実験リストに入れる価値がある。まだかなり early stage だが、問題設定は現実的だ。AI agent の coding ability は、まず読むべき code を見つけられるかどうかに制限されることが多い。