codebase が大きくなると、AI agent が token を浪費しやすい場所は、コードを書く部分ではなく context を探す部分になりがちだ。

人間なら file name、IDE index、記憶を頼りに「authentication middleware はこのあたり」と当たりをつけられる。agent はまず grep し、可能性のある file を大量に開き、関係の薄い実装まで context に入れてしまう。概念と code 上の命名がずれていたり、同じ流れが複数 service に分散していたりすると、traditional grep と fuzzy search は問題をまた model に戻してしまう。agent にとって良い入口は、自然言語で探したい logic を説明し、path、line number、ranking 付きの code snippet を返す tool だ。

今日メモしておきたい dvcdsys/code-index は、project name を Code IndeX、CLI を cix と呼ぶ self-hosted semantic code search system だ。Go server、cix CLI、Web dashboard、workspace、multi-repo search、tree-sitter chunking、SQLite FTS5、chromem-go vector store、local llama.cpp embedding sidecar、そして optional な Voyage AI / OpenAI-compatible embedding provider を持つ。IDE replacement ではなく、terminal と AI agent に「semantic に code を探す」ための安定した tool を渡す位置づけだ。

2026-07-12 時点で GitHub repository API、README、release API、tags API、languages API、commits API から確認できる公開情報では、dvcdsys/code-index は 24 stars2 forks。主言語は Go、license は MIT。リポジトリ作成日は 2026-03-17 10:38:44 UTC、最近 push は 2026-07-10 15:36:38 UTC。default branch main の現在の最新 commit は bc4c9c2c、commit time は 2026-07-02 16:25:05 UTC。最新 GitHub release は server/v0.12.1 で、公開時刻は 2026-07-02 16:38:58 UTC。tags API では CLI 側の v0.3.0 なども確認できる。

プロジェクト概要

項目内容
リポジトリdvcdsys/code-index
位置づけself-hosted semantic code search、CLI、dashboard、agent tool layer
Stars24
Forks2
主言語Go
ライセンスMIT
リポジトリ作成日2026-03-17 10:38:44 UTC
最近 push2026-07-10 15:36:38 UTC
最新 main commitbc4c9c2c、2026-07-02 16:25:05 UTC
最新 releaseserver/v0.12.1
release 公開時刻2026-07-02 16:38:58 UTC
主な機能cix CLI、Web dashboard、workspace、hybrid search、local embeddings、Claude Code plugin、MCP server

agent にまず検索させ、それから file を読ませる

Code IndeX の基本的な使い方は分かりやすい。cix-server を起動し、API key と bootstrap admin を設定し、cix init で current project を登録して index する。その後 terminal で cix search "authentication middleware" を実行できるし、symbol、file、workspace も検索できる。http://localhost:21847/dashboard を開けば Web UI からも探せる。

AI coding workflow にとっての価値は、「context を探す」作業を model のその場の推測ではなく、再利用できる外部 tool にすることだ。README は cix を agent が呼べる shell command として設計している。agent が関連実装を探すとき、まず cix search を実行し、ranking 済み snippet、path、line number を受け取り、そこから読む file を決める。agent に広範囲の grep をさせるより context を節約しやすく、audit もしやすい。

project には Claude Code plugin もある。install すると、cix を agent の default code search reflex として使える。multi-repo work には cix-workspace がある。Claude Desktop や Cowork のように Claude Code plugin を読めない環境向けには、Code IndeX が built-in stdio MCP server を提供し、同じ search capability を cix_* tool として公開する。search service は一つだけ deploy し、client は CLI、plugin、MCP のどれかで使う。この形は実用的だ。

単なる vector store demo ではない

「code に semantic search をつける」小さな project の多くは、最後には embedding demo になりがちだ。file を chunk し、vector store に入れ、cosine similarity で返す。Code IndeX の README を見る限り、もう少し工程寄りに作ろうとしている。

server は Go HTTP API で、dashboard は server binary に embed される。indexing pipeline は tree-sitter / WASM で AST chunking し、30 以上の language を扱う。metadata と symbol は SQLite、FTS5 は BM25 mirror、vector side は chromem-go。default embedding は local llama.cpp sidecar で、CodeRankEmbed の GGUF quantized model を使う。つまり dense search、BM25、symbol metadata、dashboard を同じ service にまとめている。

workspace も注目したい点だ。Code IndeX は複数 repo を named corpus として grouped でき、server side で clone、index し、その集合に対して hybrid search をかけられる。monorepo ではない team には役立つ。現実の system は API、frontend、infra、SDK、docs が複数 repository に散っていることが多い。single-repo search では「この request ID は gateway から worker までどう渡るのか」に答えにくい。workspace は少なくとも agent に cross-repo search の入口を渡す。

local-first だが embedding provider は切り替えられる

default mode では、Code IndeX は local llama.cpp sidecar で embedding を実行し、README は code が machine から出ないことを強調している。private repository、offline environment、あるいは個人 machine で semantic code search を試したい場合に向いている。Docker CPU image、CUDA image、macOS native Metal path も document に用意されている。

同時に、local model だけに閉じているわけではない。embedding provider は dashboard で Voyage AI または OpenAI-compatible endpoint に切り替えられる。README は provider や model dimension を変えると full reindex が必要だとも説明している。embedding space が違えば vector は比較できないので、この明示は大事だ。「model を変えても cost はない」と見せるのではなく、reindex を system behavior として扱っている。

team で評価するなら、この構造は現実的だ。まず default local model で一、二個の repo を index し、result quality、resource usage、index time を見る。検索品質が足りなければ code retrieval に強い external embedding provider に切り替える。compliance requirement が強ければ provider を local または internal endpoint に固定する。呼び出し側は cix と HTTP API のままなので、provider を変えるたびに agent integration を書き直す必要はない。

dashboard と運用境界も補われている

Code IndeX の dashboard は単なる one-page demo ではない。README では projects、search、users/API keys、runtime sidecar control、drift indicator などが挙げられている。server には Swagger UI と OpenAPI spec もあり、REST surface は auth、users、projects、indexing、search、workspaces、webhooks などを含む。

こうした細部は、semantic indexing tool を実際に使うときに効いてくる。誰がどの project を見られるのか。API key をどう発行するのか。index は stale か。model sidecar は動いているか。workspace clone はどこにあるのか。webhook push 後に auto-reindex されるのか。これらを user 側で全部補う必要があると、tool は personal script から team service に進みにくい。Code IndeX は少なくとも、それらを product surface として扱っている。

Docker deployment もはっきりしている。CPU multi-arch image、CUDA 12.8 image、version-pinned tag、team deployment、CUDA、security hardening、backup、update channel の document がある。24 stars の小さな project として見ると、この document density はむしろ注目点だ。

向いている場面

第一の場面は、AI coding agent の pre-search だ。agent が code を変更する前に専用 tool で関連実装を探し、grep、glob、大量 file reading を model に丸投げしないようにしたい場合に向く。cix search は path、line number、snippet を返すので、agent loop に入れやすい。

第二の場面は、multi-repo system understanding だ。workspace search は関連 repo を一つの検索文脈にまとめられる。backend、frontend、SDK、infra が分かれている team では、「この概念はどの repo にあるのか」を探す cost を下げられる。完全な knowledge graph ではないが、入口としては十分意味がある。

第三の場面は、local または intranet の code retrieval だ。default local embedding、SQLite/chromem-go、self-hosted server、Docker deployment があるため、pure SaaS code search より restricted environment に入れて試しやすい。

第四の場面は、複数 agent に統一された code search entrypoint を渡したい場合だ。CLI、Claude Code plugin、MCP server、HTTP API が同時にあるので、特定の editor や chat window に縛られない。

注意したいところ

第一に、project はかなり新しく小さい。リポジトリ作成日は 2026-03-17、現在は 24 stars と 2 forks しかない。documentation と release flow はすでに多いが、採用時は early-stage tool と見て、version pin と rollback plan を用意したい。

第二に、semantic search は magic ではない。embedding model、chunking、language support、repository structure、query phrasing はすべて結果に影響する。README は server upgrade 後の reindex を促しており、parsing と embedding pipeline はまだ安定化の途中だと分かる。agent に接続する前に、自分の project の real task で比較した方がいい。

第三に、local embedding には resource cost がある。CPU、CUDA、Metal の path はあるが、index speed、memory、disk、model download は machine によって大きく変わる。large monorepo や multi-repo workspace では、index と rebuild の cost を先に見積もりたい。

第四に、permission sandbox ではない。Code IndeX は誰が project を見られるか、誰が API key を持つかを扱えるが、agent が cix の結果をどう使うかは agent の permission と実行環境に依存する。「検索が local に残る」ことを、完全な security boundary と誤解しない方がいい。

まとめ

dvcdsys/code-index が面白いのは、semantic code search を agent が実際に再利用できる local service としてまとめている点だ。CLI、dashboard、workspace、hybrid ranking、local embeddings、MCP、Claude Code plugin が、同じ問題に向けて作られている。

AI coding workflow が「context を探す」作業で遅くなっているなら、または複数 agent に統一された code retrieval entrypoint を渡したいなら、Code IndeX は小さく試す価値がある。まだ若いが、問題設定は正確だ。agent がコードを書く前に、まず読むべきコードを reliable に見つけられる必要がある。