AI coding agent が context を探すとき、よく無駄になるのは「検索できない」ことではない。毎回 code structure を推測し直すことだ。function name を grep し、いくつか file を開き、import、caller、test、隣の module を追う。この流れは動くが、mechanical な探索に token を使いすぎる。さらに agent が見ているのは text fragments であって、誰が誰を呼ぶのか、変更がどこへ波及するのか、この project ではどう書くのが自然かを必ず理解しているわけではない。

今日メモしておきたい luuuc/sense は、その隙間を狙った local tool だ。editor でも新しい agent runtime でもなく、AI coding agent が使うための MCP server / CLI である。Sense は local で codebase を index し、tree-sitter で symbol、call、import、inheritance などの関係を抽出する。そして Claude Code、Cursor、Codex CLI、OpenCode、または他の MCP client に、sense_graph、sense_search、sense_blast、sense_conventions という四つの tools として渡す。

2026-07-14 時点で GitHub repository API、README、Releases page、Tags page、commit history、languages API、LICENSE から確認できる公開情報では、luuuc/sense は 21 stars、1 fork。主言語は Go、license は MIT。repository 作成日は 2026-04-17 18:19:50 UTC、最近 push は 2026-07-14 09:15:21 UTC。default branch main の現在の最新 commit は ae5976b、commit time は 2026-07-14 09:15:19 UTC。GitHub Releases page と Tags page の最新 version はどちらも v1.11.25 で、release published time は 2026-07-14 09:23:38 UTC だ。

プロジェクト概要

項目内容
リポジトリluuuc/sense
位置づけAI coding agent 向けの local code structure index、MCP server、CLI
Stars21
Forks1
主言語Go
ライセンスMIT
リポジトリ作成日2026-04-17 18:19:50 UTC
最近 push2026-07-14 09:15:21 UTC
最新 main commitae5976b、2026-07-14 09:15:19 UTC
Latest GitHub releasev1.11.25、2026-07-14 09:23:38 UTC
最新 tagv1.11.25
主な入口curl -fsSL https://luuuc.github.io/sense/install.sh | sh、sense scan、sense setup
キーワードMCP、tree-sitter、symbol graph、semantic search、blast radius、conventions、local-first

structure の問題は structure tool に任せたい

Sense の README は、agent は code text を持っているが map を持っていない、という問題設定をしている。人間の engineer が「この function は誰に呼ばれるのか」と考えるとき、頭の中では structure view に切り替える。だが agent が grep と file read しか持っていない場合、structure question を大量の text search に分解してしまう。Sense はこの structure layer を先に計算しておく。

外に出す tools はかなり絞られている。sense_graph は symbol relationship、caller、callee、inheritance、tests、dead code を扱う。sense_search は hybrid semantic code search で、keyword / text fallback も持つ。sense_blast は blast radius、affected code、affected tests、risk score を見る。sense_conventions は source から project conventions を検出する。coding agent にとっては、巨大な grep output を渡されるより扱いやすい。問題の種類ごとに入口が分かれているからだ。

特に気になるのは sense_blast と sense_conventions だ。前者は「ここを変えるとどこに触るか」を答え、後者は「この project では普通どう書くか」を答える。AI が出す code の問題は、syntax error だけではない。命名、layer、framework idiom、test placement が微妙に project からずれることが多い。Sense が convention detection を一級機能として扱っている点は、単なる search tool より面白い。

local index で、repository を外部 service に渡さない

install path は素直だ。

curl -fsSL https://luuuc.github.io/sense/install.sh | sh
cd /path/to/project && sense scan
cd /path/to/project && sense setup

README によれば、Sense は local で code を parse し、bundled ONNX model で embedding を作り、index を .sense/ に保存する。SaaS account、API key、cloud dependency は不要だ。company codebase では、この点は大きい。local agent には repository を読ませたいが、codebase 全体を外部の code search service に送るのは避けたい、という team は多い。

setup の動きも重要だ。Claude Code、Cursor、Codex CLI、OpenCode などを自動検出し、.mcp.json、.cursor/mcp.json、.codex/config.toml、opencode.json などの MCP config を書く。さらに CLAUDE.md、.cursorrules、AGENTS.md のような routing guidance も書ける。これは少し強い体験だ。agent instruction file に触るからである。ただ、agent がいつ structure tool を使うべきか知らなければ、すぐ grep と file read に戻ってしまうので、product の方向としては理解できる。

採用するなら、まず小さな repository で sense setup を実行し、どの file が変わるかを見たい。そのうえで、config を commit するか、個人環境だけに残すかを決める。tool 自体は local だが、workflow には明確な意見を持っている。完全に透明な grep replacement ではない。

demo ではなく、かなり engineering 寄りに見える

Sense README は二つの support tier を挙げている。core tier には Go、JavaScript、TypeScript、TSX、Ruby、Swift、Lua、Bash、Zsh などがあり、standard tier には Python、Rust、Java、Kotlin、C#、C++、C、PHP、Scala などがある。GitHub languages API では Go が最大で、Python、Shell、Dockerfile、Makefile も含まれる。21 stars の project としては、実装面は薄くない。

README には benchmark もある。複数の実 codebase で、Sense を使うと agent が読む file、tool call、token が減る、という説明だ。これらの数字を一般的な performance promise として読むつもりはない。benchmark は常に task と repository に依存する。ただ、作者がこの project を「agent が structure question に払う反復 cost を減らすもの」と定義していることはよく分かる。単なる vector search wrapper ではない。

最新 release v1.11.25 の内容も、その方向を示している。release note は、Go の大きな repository で interfaces × structs の 500K budget が implicit interface satisfaction edges を無効化していた問題を取り除いた、と説明している。これはかなり地味だが実務的な変更だ。AI という言葉を前面に出すより、code graph の正確さと coverage を直している。

向いている場面

第一の場面は、agent に cross-file change をよく任せるが、caller、callee、test、impact range を探すだけで回数を使いすぎる場合だ。Sense の symbol graph と blast radius は、まさにこの問題向けに見える。

第二の場面は、syntax より project convention が重要な場合だ。Rails association、Go interface、Django model、layered directory、naming habit などは、文章で説明するだけでは agent が忘れやすい。sense_conventions は source からその pattern を見せる。

第三の場面は、code understanding を local に留めたい場合だ。Sense は index と model を local に置くため、private repository で試しやすい。

第四の場面は、複数の agent client を使っている場合だ。Sense は特定 editor plugin だけに閉じず、MCP と CLI で capability を出す。Claude Code、Codex CLI、Cursor、OpenCode を混ぜて使う environment と相性がよい。

注意したいところ

第一に、project はまだ若い。21 stars、1 fork、repository 作成日は 2026-04-17。commit、release、tag は活発だが、外部利用例は多くない。まず non-critical repository で試し、version を pin したい。

第二に、sense setup は agent config と instruction file を書く。便利だが、team repository では先に diff を確認し、既存の AGENTS.md、CLAUDE.md、Cursor rules と衝突しないか見るべきだ。

第三に、README 自身も Sense は general search engine ではないと書いている。log message、config key、error code などの plain text lookup では grep がまだ直接的だ。Sense は all-purpose search replacement ではなく、structure problem に向いた tool と見る方がよい。

第四に、benchmark numbers は参考値だ。language、repository size、agent type、task mix で結果は変わる。価値を見るなら、自分の project の典型 task で比較する必要がある。

まとめ

Sense の面白さは、AI coding の問題を単に「model をもっと強くする」話にしていないところだ。大きな codebase で agent に足りないのは、query できる local structure map である。誰が誰を呼ぶのか、どこへ影響するのか、project convention は何か、semantic search と text search のどちらを使うべきか。

Codex CLI、Claude Code、Cursor、OpenCode を使っていて、agent が code relationship を理解するために何度も grep し、file を読み、また grep しているのを見るなら、luuuc/sense は試験リストに入れる価値がある。まだ小さい project だが、方向は明確だ。codebase understanding を local に戻し、agent の blind reading cost を減らす tool である。