Srclight：coding agent にローカルなコード索引を渡す

Coding agent を知らない repository に入れると、多くの token は「道案内」に消える。まず何度か grep し、いくつか file を読み、誰が誰を呼んでいるかを推測する。問題が module をまたぐと、tool calls はすぐに方向の定まらない探索になる。小さな repository なら耐えられるが、monorepo や multi-repo workspace では、この orientation cost が bug fix や design change を遅くする。

今日見るのは srclight/srclight。Deep code indexing for AI agents を掲げる local MCP server / CLI だ。SQLite FTS5、tree-sitter、embeddings、call graph、Git blame / hotspots、build system analysis、multi-repo workspace を使い、codebase を agent が問い合わせられる structured index にする。Remote code-understanding SaaS ではなく、README は fully local、single SQLite file per repo、no Docker / Redis / vector DB という方向を強調している。

GitHub repository API、README、LICENSE、Releases page を 2026-08-11 時点で確認すると、srclight/srclight は 53 stars、10 forks。主要言語は Python、license は MIT。Repository created time は 2026-02-23 20:00:08 UTC、latest public push は 2026-08-11 00:57:21 UTC。Default branch は develop。最新 GitHub Release は v0.20.1、published time は 2026-08-11 00:57:50 UTC。Release note では、v0.15.1 以来の PyPI / MCP registry release であること、現時点で 42 MCP tools と 189 passing tests があることが書かれている。

プロジェクト概要

項目	内容
リポジトリ	srclight/srclight
位置づけ	Local code-indexing MCP server / CLI
Stars	53
Forks	10
主要言語	Python
ライセンス	MIT
作成日時	2026-02-23 20:00:08 UTC
Latest push	2026-08-11 00:57:21 UTC
Default branch	develop
最新 GitHub Release	v0.20.1、2026-08-11 00:57:50 UTC
キーワード	MCP、code indexing、code search、SQLite FTS5、tree-sitter、embeddings、local-first

解いているのは agent の「repository を読むコスト」

Srclight の README は、AI coding agents がかなりの context と tool calls を orientation に使っている、という見方から始まる。代替案は、code を先に index し、agent には MCP tools 経由で structured questions を聞かせることだ。Caller を探すために agent 自身が何度も grep する必要はない。Module を理解するために最初から大量の file を読む必要もない。「authentication を扱う code はどこか」を semantic search で探すことも、関数を変える前に impact / blast radius を見ることもできる。

この種の tool の価値は、agent が file を一つ二つ読む手間を省くことだけではない。「codebase map」を毎回の探索ではなく、再利用できる asset にすることだ。一度 index ができれば、次の session からは symbols、call relationships、documents、Git changes、semantic search から入れる。同じ repository で Codex、Claude Code、Cursor を毎日使う人にとって、同じ directory structure を prompt に戻し続けるより、engineering infrastructure に近い。

設計は local-first で素朴

Srclight の実装方針はかなり現実的だ。Repository ごとに .srclight/index.db を持ち、中心にあるのは SQLite、FTS5、tree-sitter、optional embeddings。README は Docker、Redis、外部 vector database が不要だと書いている。Indexing は incremental で、content hash により changed files だけを処理する。Semantic search を使う場合、embedding vectors は SQLite と .npy sidecar files に保存される。

ここで local-first は重要だ。Code index は internal API、未公開の logic、test data、config path、comment に残った古い事情まで拾う可能性がある。それを local MCP server として動かし、default では code を cloud に送らない形にしているので、個人や小さな team でも security boundary を説明しやすい。より強い semantic search が必要なら Ollama の local embedding model を使えるし、外部 API を許容するなら Voyage や OpenAI-compatible providers も選べる。

Install path も直接的だ。

pip install srclight
cd /path/to/your/project
srclight index
srclight search "lookup"
srclight serve

MCP client から使う場合は srclight serve を起動する。README には Claude Code の stdio / SSE configuration があり、Cursor も SSE / streamable HTTP で接続できると説明されている。Multi-repo workspace では srclight workspace init、workspace add、workspace index、workspace search で複数 repo を同じ query surface に載せられる。

面白いのは「検索」だけではないところ

Symbol search だけの tool は珍しくない。Srclight が面白いのは、agent が実際に必要としそうな context をまとめている点だ。Source full-text search、symbol index、call relationships、document extraction、Git blame、hotspots、build system analysis、community / impact analysis、cross-session learnings。Release note でも、v0.20.1 までに get_communities、get_execution_flows、get_impact、detect_changes などの tools が入ったと説明している。

これは「速い grep」だけを目指していないということだ。実際の use case は、変更前にその関数の callers を確認する、module の frequent-change points を見る、execution flow tracing で影響範囲を判断する、multi-repo workspace で同じ concept を探す、debug 中に README、CSV、PDF、DOCX のような documents も検索対象にする、というものになりそうだ。

全ての project がこれを必要とするわけではない。ただ、方向は一貫している。Agent に必要なのは file content だけではなく、queryable relationships と history だ。Tool の返す結果が安定していれば、agent は repository の中で迷うより、判断と変更に token を使える。

誰が試すとよさそうか

Srclight は、agent が repository で「探すのに時間を使いすぎる」と感じている人に向いている。Python / TypeScript / Go / Java が混ざる project を保守していて、call chain を追わせる、module をまたぐ変更をさせる、history を見ながら bug を直す、複数 repo の間で同じ concept を探す、といった作業が多い場合だ。先に local index を作り、MCP tools を agent に接続すると、毎 session を grep から始めるよりすっきりする。

Code privacy を気にしつつ semantic search を使いたい人にも合う。最も保守的な path は local index と FTS5 だけを使うことだ。Natural language search が必要になってから Ollama の local embedding model を足せばよい。そうすれば「AI code understanding」が、source upload 前提の service にならない。

向かない場面もある。Repository が小さく、agent に毎回独立した file edit だけを頼むなら、普通の grep と file read で十分だ。Srclight の価値は reusable index と structured queries から出る。長期利用や複雑な関係がないなら、単に toolchain が一つ増える。

注意したい境界

第一に、project は若い。Created time は 2026-02-23 で、stars と forks もまだ少ない。Latest push と release は活発だが、community validation は限られている。まず personal project や low-risk internal repository で試し、最初から唯一の code-understanding layer として扱わないほうがよい。

第二に、semantic search の cost はゼロではない。README は local embeddings に Ollama を挙げており、大きな model は VRAM を使う。Vector sidecar も disk と memory を消費する。多くの repository では、FTS5、symbol search、callers / callees だけで十分なこともある。最初から全 option を有効にする必要はない。

第三に、index files の扱いが必要だ。.srclight/ は自動的に .gitignore に入ると README にあるが、backup、CI cache、local sync folder、team machine の permission は別問題だ。Code index database は source repository そのものではないが、十分な構造と断片を含む。無害な temporary file として扱うべきではない。

まとめ

srclight/srclight が面白いのは、agent の codebase orientation を local で reusable かつ queryable な layer にしているところだ。各 session に token を使わせて道探しをさせるのではなく、SQLite FTS5 と tree-sitter で素朴な index を作り、MCP server で existing agent workflow に渡す。Embeddings、Git information、impact analysis は、その上に深い code understanding を足す余地になっている。

まだ小さい project だからこそ、Gumi の観察対象としてちょうどよい。大企業 platform でも汎用 AI wrapper でもなく、daily coding-agent workflow の実際の摩擦を薄くしようとしている tool だ。同じ repository 群で何度も agent を動かす programmer なら、Srclight は試用 list に入れる価値がある。

リポジトリ：https://github.com/srclight/srclight