cx: AI agent に LSP を走らせずに semantic code navigation を与える

AI agent に codebase を触らせるとき、一番高くつくのは model 自体ではなく、どうやって code を探させるかであることが多いです。

多くの session で agent が最初にやるのは編集ではなく探索です。directory を見て、file 名を推測し、関数名を grep し、必要なのは 1 個の定義だけなのに file 全体を context に入れてしまう。実際に欲しいのは「この関数の定義」「この symbol の参照先」「この directory に何があるか」だけ、という場面がかなり多いです。

今日書いておきたい ind-igo/cx は、まさにその段階を狙った tool です。editor を作り直すわけでもなく、language server や IDE の前提を全部そろえさせるわけでもありません。代わりに、file overview、symbol search、definition、references を 1 つの CLI で提供して、AI agent により安い semantic navigation の層を与えます。

GitHub repository page と公開 metadata を 2026-06-21 時点で見ると、この repository は 272 stars、16 forks、主要言語は Rust。作成日は 2026-03-18、公開上の最新更新日は 2026-06-21 です。license は MIT。repository 内の Cargo.toml と CHANGELOG.md では、現在の version は 0.7.1、その日付は 2026-05-15 になっています。

Project overview

項目	内容
Repository	ind-igo/cx
位置づけ	AI agent 向けの semantic code navigation CLI
Stars	272
Forks	16
主要言語	Rust
作成日	2026-03-18
最終更新日	2026-06-21
License	MIT
Current version	0.7.1
Version date	2026-05-15

解いているのは「どう書くか」ではなく「どう読まずに済ませるか」

cx README の言い方はかなり明快です。これは AI agent 向けの semantic code navigation です。

重要なのは「検索が速い」ことより、agent が file 全文を読む前に、構造化された query を先に使えることです。README にある推奨の順序もかなりはっきりしています。

cx overview で directory や file の見取り図を見る;
cx symbols で project 全体から symbol を探す;
cx definition で定義だけを抜く;
cx references で使用箇所を確かめる。

この順番には意味があります。agent の context 浪費は、推論不足というより、探索そのものを高い方法でやっていることから起きがちだからです。

欲しい情報が「この関数はどこにあるか」「この directory には何があるか」「この型はどこで使われるか」なら、file 全体を毎回読むのはコストの高い選択です。cx はそこに対して、より安い query の階段を用意しています。

いちばん面白いのは、LSP を前提にしていないこと

定義ジャンプや参照検索をやるなら language server を使えばいいのでは、という疑問は自然です。README でもそこに正面から答えています。

cx の考え方はかなり実務寄りです。

LSP は editor と人間向けに設計されている;
常駐 process や比較的大きい resource を前提にしやすい;
言語ごとの setup も必要になる;
でも agent が必要なのは、code の構造に query する能力である。

つまり cx は、IDE backend 全体を再現したいのではなく、もっと狭くて、しかし agent には非常によく使われる層を狙っています。

編集前に、十分な判断材料だけを安く取る。

この割り切りはかなり良いです。現在の coding agent は、IDE そのものよりも、grep + cat より賢く、完全 LSP より軽い中間レイヤーを必要としている場面が多いからです。

4 つの主要 command が、agent の探り方をかなりきれいに分解している

cx を見ていて面白いのは、code 読みの前段階をいくつかの明確な action に分けていることです。

1. `overview`: まず directory と file の地図を見る

cx overview src/ は directory 直下の構造と symbol の概観を返し、cx overview src/main.rs は file 内の struct、enum、function、その range や signature を見せてくれます。

これは agent の最初の問いにかなり合っています。

ここは見るべき directory か;
この file に対象の関数はあるか;
さらに読む価値があるか。

Markdown heading も index できるので、README や設計文書まで navigation 対象になるのも実用的です。

2. `symbols`: 文字列検索ではなく構造検索にする

cx symbols --kind fn の価値は、「関数っぽい名前を grep する」のではなく、project に存在する function や type を構造化して返せることにあります。

agent が曖昧に「deploy っぽい function がどこかにあるはず」と思っているとき、本当に欲しいのは文字列一致の山ではなく、候補となる定義の一覧です。

3. `definition`: file 全体ではなく定義だけを読む

cx definition --name resolve_root は、この tool の価値を最も直接的に示しています。

言い換えると、

main.rs を読みたいのではなく、この定義だけを見たい。

という要求に、そのまま応えているわけです。大きい repository では、これだけで context の使い方がかなり変わります。

4. `references`: まず impact を見てから手を入れる

変更作業で本当に難しいのは、書くことよりどこまで波及するか分からないことだったりします。

cx references --name Symbol が default で file 単位に group して結果を返すのは、とても agent 向きです。最初に必要なのは、どの file が影響を受けそうか、何箇所くらいあるか、どこから呼ばれているかという change-planning 情報だからです。

もっと細かい source line が必要になったときだけ --context を付ければよい。default を粗めにしているのは筋が良いです。

実体は Rust 製の multi-language indexer で、tree-sitter をうまく使っている

cx は 1 言語専用の tool ではありません。README と changelog を見ると、tree-sitter で semantic index を作り、tree-sitter-language-pack を通して language grammar を動的に取得する設計になっています。

これには実用上の利点があります。

build 時に大量の grammar を静的リンクしなくてよい;
cx lang add rust typescript python のように必要な言語だけ入れられる。

changelog から分かる最近の進み方もかなり良いです。

0.7.1 では Objective-C support を追加;
0.7.0 では Markdown heading navigation、Windows ARM64 release support、directory path filter、query coverage 拡張を追加;
0.6.x では pagination、CX_CACHE_DIR、sandbox 向け cache 制御を追加。

つまり、単に idea が面白いだけでなく、実際の agent workflow に沿って磨かれている project です。

接続コストが低いのも強い

個人的にかなり良いと思ったのは、cx skill で agent 向け prompt を直接出せることです。Codex、Claude Code、Copilot、Zed のような AGENTS.md 系の tool に、そのまま足せます。

これは小さく見えて大事です。

多くの developer tool は機能自体は悪くないのに、agent が使える形にするまでが重いです。MCP schema を書いたり、skill を別管理したり、毎回会話で使い方を説明したりする必要があります。

cx はそこをかなり軽くしています。

普通の CLI として入れられる;
自分の使い方を skill に投影できる;
構造 query と raw file read の間に段階を作れる。

だからこれは単なる terminal utility ではなく、agent-friendly な基礎部品として設計されているように見えます。

README の節約数字は面白いが、第三者ベンチではない

README では、作者が 105 回の Claude Code session を分析し、次のような数字を示しています。

read 操作の 66% は chain read;
37% は re-read;
cx を有効にすると Read call が 58% 減少;
code navigation に使う token は 40% から 55% 減少。

この種の数字は参考にはなりますが、受け取り方としては project 自身の観測値 として見るのが適切です。独立 benchmark とまでは言えません。

それでも、示している問題意識はかなり本質的です。agent workflow では code navigation そのものが大きなコスト源であり、そこを構造化して token を減らせるなら、session 全体の安定性にも効いてきます。

なぜ今この project を追う価値があるのか

cx が面白いのは、派手な自動化よりも、今の agent が本当に詰まりやすい層を狙っているからです。

agent は「書ける model」よりも前に、「安く理解できる navigation」を必要としている。

cx の方向はかなり明快です。

完全な LSP を強制しない;
すべてを grep + cat に戻さない;
tree-sitter ベースの安い structure query を先に使う;
その query を CLI と skill にして agent が覚えやすくする。

こういう tool は派手さでは目立ちにくいですが、長く workflow に残るのはむしろこちらかもしれません。

まとめ

ind-igo/cx の価値は、AI agent がいちばん無駄に token を使いがちな「探り読み」を、低コストな semantic query に置き換えようとしていることです。

完全な LSP は走らせず、巨大 file もむやみに読ませない。まず overview、symbols、definition、references で探索範囲を絞り、それでも必要なときだけ source を読む。この段階設計は地味ですが、今の agent coding workflow にはかなり効く考え方だと思います。