ken：agent 向けコード検索を Go の静的バイナリにする
AI coding agent は、かなり素朴なところで詰まりがちだ。何を直すべきかは分かっているのに、どの code を先に読むべきかが分からない。結果として workflow は grep、glob、Read、また grep になり、context window がすぐ埋まっていく。ripgrep が悪いわけではない。問題は、agent が聞きたい問いの多くが「この文字列はどこにあるか」ではなく、「この質問に答える可能性が高い code はどこか」だからだ。
今日紹介する townsendmerino/ken は、かなり狭い問題を扱っている。agent に local、CPU-only、reproducible な hybrid code search layer を渡すことだ。これは MinishLab/semble の retrieval algorithm を Go に移植した project で、BM25、Model2Vec semantic embeddings、RRF fusion、code-aware reranker を pure Go binary にまとめ、CLI と MCP server の両方を提供する。
2026-07-19 時点で GitHub repository page、README、release/tag page、公開 git history、LICENSE、go.mod、local git clone から確認できる公開情報では、townsendmerino/ken は 25 stars、1 fork。GitHub の primary language は Go、license は MIT。GitHub embedded data の repository creation time は 2026-05-19 23:11:42 UTC。公開 git history の initial commit は 1969268、commit time は 2026-05-20 10:10:56 -07:00、message は Initial commit: ken v0 — pure-Go port of semble。default branch main の最新 commit は cc1dfa1、commit time は 2026-07-16 08:07:28 -07:00、message は chore: go fix ./... — Go 1.26 modernizers。最新のアクセス可能な GitHub release は v1.1.1 で、GitHub release page では github-actions により 2026-07-16 14:57 UTC に published。local tag 情報では v1.1.1 の tag time は 2026-07-16 07:53:54 -07:00。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | townsendmerino/ken |
| 位置づけ | AI coding agent 向けの local hybrid code search と MCP server |
| Stars | 25 |
| Forks | 1 |
| 主言語 | Go |
| ライセンス | MIT |
| GitHub 作成時刻 | 2026-05-19 23:11:42 UTC |
| 公開 Git history 起点 | 2026-05-20 10:10:56 -07:00、initial commit 1969268 |
| 最新 main commit | cc1dfa1、2026-07-16 08:07:28 -07:00 |
| 最新のアクセス可能な release/tag | v1.1.1、release page 2026-07-16 14:57 UTC、tag time 2026-07-16 07:53:54 -07:00 |
| キーワード | code search、MCP、Go、static binary、BM25、Model2Vec、local-first |
grep を置き換えるものではない
ken の README は境界をかなり明確にしている。exhaustive audit、rename 前の全列挙、正確な文字列検索は、今でも grep の仕事だ。ken が扱うのは別の種類の query、たとえば「authentication failure の retry logic はどこか」「model を disk に保存する path はどの module でつながっているか」「agent はまずどの chunk を読むべきか」といったものだ。
この種の問いは、一つの regex では解きにくい。agent は普通、いくつか keyword を探し、結果を読んで、別の keyword でまた探す。この方法でも進められるが、token と round-trip のコストが高く、命名がずれている実装を見落としやすい。
ken は repository を code-oriented chunks に分け、BM25 と semantic vector の両方で recall し、最後に RRF と reranker で並べる。agent にとって欲しい結果は「すべての matching lines」ではなく、「次に読む価値が高い数個の code fragments」だ。
単一 Go binary という形が重要
多くの code search / RAG tool の難しさは algorithm ではなく deployment にある。Python runtime、vector database、embedding service、background daemon、model download script、たくさんの environment variables が必要になることも多い。個人の実験ならよいが、ある agent workflow に一時的に入れて試すには重い。
ken の面白いところは、配布の形をかなり硬くしていることだ。README では pure Go、no cgo、CPU-only と説明され、macOS、Linux、Windows の prebuilt binaries、Homebrew、Scoop、go install が用意されている。default Model2Vec model は約 60 MB で、ken-mcp は初回実行時に自動 fetch できる。model がない場合は、まず BM25-only path を提供する。
これは複雑さがないという意味ではない。むしろ複雑さを binary と reproducible benchmark の側に寄せ、user に小さな retrieval platform を組ませない設計だ。agent tool としては、この trade-off は実用的だ。「binary を入れて、MCP server を一つ設定する」に近いほど、実際の workflow で試されやすい。
CLI より MCP 接続が効く
ken は CLI としても使えるが、観察したいのは ken-mcp の方だ。README によれば、stdio JSON-RPC の MCP server として動き、semble と同じ search / find_related tool schema と markdown output format を保つ。つまり MCP を受けられる agent client なら、ken を接続し、温まった local index を検索に使える。
これは Claude Code、Codex CLI、Cursor、opencode のような tool に向いている。agent は毎回 grep command を組み立てる必要がなく、repository 全体を context に詰め込む必要もない。まず ken に問い、ranked fragments をもとに次の read や edit を決められる。
README には definition、references、callers、outline、symbols、recently_changed、status といった structured tools や、database schema indexing も出てくる。単なる “semantic grep” ではなく、agent が呼び出せる code map に広げようとしているのが分かる。
reproducible numbers が信用点になる
ken の README は performance numbers をかなり具体的に書いているが、同時に reproduction path も示している。semble の 1,251-query benchmark で、default hybrid mode の recall@10 は 0.967 NL / 0.995 symbol、NDCG@10 は 0.842。grep + Read と比べると、natural language queries の median token cost は 189,773 から 4,120 に下がり、約 46 倍の差があるとしている。再現手順は docs/BENCH.md に置かれている。
これらの数字を「すべての repository で必ずこうなる」と読むべきではない。benchmark には corpus、query、chunker、model、evaluation metric の制約がある。それでも、小さな project が retrieval quality、token cost、reproduction commands を明示しているのは、「smart code search」とだけ言うよりずっと信頼しやすい。
さらに、ken は algorithm を semble の Python implementation から constants と pipeline order ごと移植したと説明している。model に雰囲気で retrieval pipeline を再発明させたわけではない。README の “How this was built” でも、Claude が書いた Go code より original source を優先する制約に触れている。この開発姿勢自体が AI tooling らしい。model に code を書かせるが、検証可能な制約を先に置く。
Gumi で見る理由
Gumi では最近 code search や agent context の project を何度か扱っている。だから ken は「code search」という大きな方向が新しいから選ぶわけではない。見る価値があるのは、scope をかなり具体化しているからだ。Go static binary、MCP-compatible、drop-in for semble、local CPU-only、benchmark-first。
こういう project はすぐ大きな star を集めるとは限らないが、developer toolbox には入りやすい。team はまず一つの agent に接続し、実際の repository で数日試し、grep/read loop が減るかを見られる。効果が薄ければ外すコストも低い。効果があれば、小さく安定した context entry point になる。
SDK author にとっても面白い方向がある。README では mcp.Run library により、documentation corpus と Model2Vec model を単一 MCP server binary に焼き込めると説明している。internal platform、framework docs、private SDK なら、search service を deploy するより軽い。indexing capability を持つ binary を配り、agent が local で質問できるようにするだけでよい。
注意したいところ
第一に、ken はまだ若い。GitHub repository は 2026-05-19 作成で、stars は 25。release cadence は活発で v1.1.1 まで出ているが、critical production workflow に入れる前に、read-only index と non-critical repository で試すべきだ。
第二に、正確検索の代替ではない。README も、exhaustive enumeration や refactor audit は grep の領域だと明記している。ken は「最も関連しそうな fragments を探す」ための tool であって、「ある文字列が完全に存在しないことを証明する」tool ではない。
第三に、default hybrid path は Model2Vec model に依存する。ken-mcp は自動 download できるが、offline environment、company network、strict supply-chain setting では、model source、cache path、version pinning、license chain を別途確認する必要がある。project の NOTICE と THIRD_PARTY_LICENSES.md は手がかりになるが、利用者側の compliance check は残る。
第四に、Go 1.26.5 要件は新しい。go.mod では Go 1.26.5 を使っている。release binary ではなく source build を選ぶ場合、この toolchain requirement が一部の environment では障壁になる。
まとめ
ken の価値は、まったく新しい search concept を発明したことではない。agent code search を試しやすい形に押し込んだことだ。Go binary、MCP server、reproducible retrieval numbers、そして「grep は置き換えない」という明確な境界。
AI coding agent が大きな repository で何度も grep し、違う file を読み、入口を探すだけで context を使い切るなら、townsendmerino/ken は試す価値がある。agent toolchain の改善は、常に大きな model から来るわけではない。十分に小さく、十分に local で、十分に検証可能な retrieval layer から来ることもある。