codesearch: AI agent 向けの offline multi-repo code search MCP
AI agent に code を書かせるとき、token をいちばん無駄にしやすい場所の 1 つは、生成そのものではなく context 探しです。
小さな project なら grep で足ります。ただ、workspace に複数 repo、古い実装、cross-language な境界があると、agent はすぐに「関係ありそうな file を全部読む」方向に寄ります。その結果、context window は探索で埋まり、本当に考えるべき部分が狭くなります。
今日メモしておきたい flupkede/codesearch は、このかなり具体的な問題を扱う project です。AI agent に local / offline / MCP-native な code search layer を渡し、まず index に聞かせ、必要になった code だけを読ませます。
GitHub repository page、README、tags / release page、default branch の commit history を 2026-07-04 時点で確認すると、この project は 50 stars、10 forks。repository の primary language は Rust、license は Apache-2.0 です。repository 作成日は 2026-02-06。GitHub が記録している直近の repository push は 2026-07-01 で、default branch master の最新公開 commit は 2026-06-21、commit は 4542950 です。最新 release / tag は v1.0.213、公開日は 2026-06-21 です。
Project overview
| 項目 | 内容 |
|---|---|
| Repository | flupkede/codesearch |
| 位置づけ | local-first multi-repo semantic code search MCP server |
| Stars | 50 |
| Forks | 10 |
| Primary language | Rust |
| License | Apache-2.0 |
| Repository 作成日 | 2026-02-06 |
| 直近の repository push | 2026-07-01 |
| Default branch 最新 commit | 2026-06-21, 4542950 |
| Latest version | v1.0.213 |
| Release date | 2026-06-21 |
| 中心の考え方 | 複数 repo を local index し、semantic search、literal search、symbol navigation、code chunk retrieval を MCP 経由で agent に渡す |
解いているのは、agent が「読みすぎる」問題です
今の AI coding workflow では、agent が直接 file を読み、grep を走らせ、候補 path を開き、大量の code を context に入れる、という流れがよくあります。
小さな repository ならそれでも大きな問題にはなりません。ただ、実際の project では必要な情報がいくつもの層に散っています。
- 現在の app repo;
- shared package;
- schema / proto / generated client;
- infra repo;
- 古い実装や migration script;
- docs と ADR。
人間の engineer は、まず大まかな地図を作ります。この関数はどこにあるか、誰が呼んでいるか、似た実装はどの repo にあるか、docs ではどんな制約になっているか。agent が file reading だけに頼ると、この「道を探す」部分が主な cost になります。
codesearch は、この探索を index capability として前に出します。README では、vector embedding、BM25 full-text search、Reciprocal Rank Fusion、tree-sitter AST chunking、symbol index を組み合わせると説明されています。agent は最初から full file を読む必要がなく、compact な hit を受け取り、必要なときだけ get_chunk で code を展開できます。
小さな違いに見えますが、agent workflow では重要です。search result は default で compact、code は必要な chunk だけ読む。context 探しで token を使い切らないための設計です。
Multi-repo がいちばん見るべき部分です
code search MCP の多くは、single repository では動きます。codesearch で面白いのは、multi-repo serve mode を中心に置いている点です。
README の serve mode は、登録済み repositories を管理し、project や group で query を route し、cross-repo RRF ranking で複数 repo の結果をまとめられます。monorepo ではない team にとって、この点は「semantic search」そのものより実用的です。
code の問題は、自然に single repo を越えるからです。
たとえば agent に API handler を直してもらうとき、frontend caller、backend handler、shared types、database migration、SDK package、deployment config を同時に見る必要があるかもしれません。single repo index では context の一部しか見えません。multi-repo index は、engineer の頭の中にある実際の project boundary に近いです。
だから codesearch は、長く使う workstation 側の tool として相性が良いです。ある directory を一回 agent に渡すのではなく、local code map を維持し、複数の MCP client から使えるようにします。
Local、offline、CPU-only という割り切りは実務的です
codesearch は自分を重い knowledge graph platform として見せていません。README では、fully local、fully offline、no GPU、no Docker、static binary、runtime model downloads なし、という境界が何度も出てきます。
この割り切りは地味ですが、enterprise network や個人の offline environment では大事です。
code indexer が起動時に model を download し、Docker を立て、外部 service に繋ぐ前提だと、permissions、proxy、compliance、machine resource のどこかで詰まります。codesearch の狙いはもっと狭いです。prebuilt binary は Windows、Linux、macOS ARM64 向けに用意され、source からなら cargo build --release で build できます。README の目安では、初回 indexing は 2-5 分、その後の incremental indexing は 10-30 秒 です。
これは cloud solution より常に強い、という話ではありません。deployment friction が小さいという話です。project ごとに新しい search service を作るのではなく、workstation の基礎設備として置けます。
MCP tool の分け方が、実際の code reading に近いです
個人的に良いと思うのは、巨大な “search everything” tool だけを出していないことです。
README にある MCP capability には、次のものがあります。
search: semantic search、または literal / regex / phrase search;find: definition、usages、imports、dependents;explore: file outline、または similar chunk;get_chunk: chunk id から full code を読む;find_impact: C# 寄りの impact helper;status: index と service state の確認。
この分け方は agent に向いています。少し成熟した agent なら、いつでも「全文検索して全部読む」べきではありません。概念的に近い実装を探しているのか、symbol definition を見たいのか、誰が依存しているかを確認したいのか、特定 chunk だけを開けばいいのかを分けるべきです。
codesearch の Agent Guidance も実用的です。README では AGENTS.md や .cursorrules に、いつ codesearch を使い、いつ grep/glob に戻るかを書くことを勧めています。remote serve の場合は、返ってくる path が server filesystem の path なので local file として開かず、get_chunk で内容を取るべきだとも説明しています。
これは、MCP tool の難しさを作者が分かっているということです。server を登録するだけでは足りません。agent が正しいタイミングで、正しい tool を選ぶ必要があります。
v1.0.213 は serve mode の細部を固めているように見えます
最新 release / tag の v1.0.213 は、派手な機能追加というより、serve mode を実用に近づける release に見えます。
release notes では、running codesearch serve に CLI delegation するとき CODESEARCH_SERVE_API_KEY を送る修正、すべての registered repo を動的に指す reserved virtual all group、MCP initialize instructions の「いつ codesearch を使うか」説明強化が挙げられています。
こういう変更はかなり工程感があります。
demo なら、もっと機能名を積みがちです。日常使用に寄せると、API key、network binding、scope_required、server-side path、agent instructions、自己参照的な test といった細かい問題に当たります。codesearch は小さい project ですが、直している問題は実用 path 上のものです。
向いている人、向いていない人
codesearch は、次のような人には試す価値があります。
- 複数 repo をまたいで作業することが多い developer;
- Claude Code、Cursor、OpenCode など MCP client をすでに使っている人;
- agent に full file を読ませすぎず、index を先に使わせたい人;
- offline、local、enterprise proxy environment を重視する人;
- team workstation や個人開発機に軽量な code map を置きたい人。
一方で、次の用途には過剰かもしれません。
- とても小さな repo だけを扱っていて、
ripgrepで十分な場合; - 完全な code graph、call graph analysis、IDE-level refactor が必要な場合;
- local index を一切維持したくない場合;
- MCP/CLI infrastructure ではなく、完成度の高い UI product が欲しい場合。
また、project はまだ若いです。stars / forks は少なく、ecosystem feedback も限られています。release speed が速いぶん、interface や config はまだ動く可能性があります。main workflow に入れる前に、まず重要度の低い repo で index size、query quality、agent の tool usage を確認したほうがいいです。
まとめ
flupkede/codesearch の価値は、「もう 1 つの semantic code search」ではありません。もっと具体的に、AI coding agent 向けの local / multi-repo / MCP-native な search and navigation layer です。
この方向が面白いのは、agent の上限が context 取得の方法で決まることが多いからです。書けないのではなく、最初に読むものを間違える、読みすぎる、散らばって読む。
codesearch は、この流れを少し制御しやすくします。先に index、先に compact search、必要になったら get_chunk、複数 repo では project / group で scope を明示する。
日常の開発が single repo、single language、single agent window ではなくなっているなら、この種の tool は plugin というより、だんだん基礎設備に近づいていくと思います。