Codanna: coding agent に local code structure memory を足す
coding agent に実プロジェクトを直させるとき、よく起きる摩擦がある。model は本当の意味では codebase を「見えて」いない。
grep は使える。いくつかの file は読める。LSP から少し情報を取れることもある。検索結果をつなげて、おおよその場所を推測することもできる。ただ、問題が「この関数はどこから呼ばれるのか」「認証ロジックの入口はどこか」「ここを変えるとどの implementation に影響するのか」になると、plain text search は急に重くなる。Agent は file、command output、推測の間を行き来し、context budget をコードを書く前の探索に使ってしまう。
今日メモしておきたい bartolli/codanna は、この workflow に local code intelligence index を足す project だ。CLI でもあり、MCP server でもある。Agent が symbol、call relationship、implementation location、semantic match、project document を query できるようにし、毎回 bare filesystem から探り直さなくて済むようにする。
GitHub repository API、README、release page、license file、default branch の shallow clone から 2026-07-05 に確認できる公開情報では、Codanna は現在 703 stars、63 forks。repository の主言語は Rust、license は Apache-2.0、作成日は 2025-07-24。default branch の直近 push は 2026-07-04 02:29 UTC。最新 release は v0.9.23 で、GitHub release page 上の公開時刻は 2026-07-04 02:46 UTC。
Project Overview
| 属性 | 内容 |
|---|---|
| Repository | bartolli/codanna |
| 位置づけ | local code intelligence CLI / MCP server |
| Stars | 703 |
| Forks | 63 |
| 主言語 | Rust |
| License | Apache-2.0 |
| Repository 作成日 | 2025-07-24 |
| Latest push | 2026-07-04 02:29 UTC |
| Latest version | v0.9.23 |
| Release time | 2026-07-04 02:46 UTC |
| 核心アイデア | code structure、semantic search、document retrieval を local MCP tool として agent に渡す |
もう 1 つの chat shell ではなく、agent の「コードを探す」能力を補う
Codanna の README にある入口はかなり素直だ。初期化し、source を index し、MCP 経由で semantic search や document search を呼ぶ。
この種の tool が面白いのは、agent を置き換えようとしていないところだ。完全な IDE として振る舞うわけでもない。むしろ local code intelligence layer として、codebase を事前に解析し、agent が query できる capability の集合に変える。
実際の開発では、この層が効く場面は多い。
- bug fix を頼んだ agent が、まず関数の call chain を知る必要がある;
- 初めて触る repository で、「login retry failure を処理している場所」を探したい;
- interface を変える前に、どの implementation と caller が影響を受けるか見たい;
- Markdown docs も一緒に検索し、source code だけでなく設計メモも agent に参照させたい。
毎回 agent に grep、find、sed、rg と人間の読解で地図を作らせると、コストが高い。Codanna の価値は、こうしたよくある問いをより構造化された query に寄せるところにある。
MCP なので既存の agent workflow に差し込みやすい
Codanna が MCP を support している点は、単体 CLI であることより重要だと思う。
いま多くの人には、すでに固定の coding agent がある。Claude Code、Codex、Cursor、Windsurf、あるいは他の MCP-compatible client だ。この種の user が本当に欲しいのは、新しい app を開くことではなく、既存 agent に信頼できる tool を足すことだ。
Codanna の立ち位置はかなり自然だ。
- CLI が repository と document collection の初期化、index、管理を担当する;
- MCP server が semantic search、symbol lookup、relationship tracking を agent に公開する;
- agent は task understanding、重要 file の確認、code edit、test execution を続ける。
この分担は、「project 全体を一度に context に詰め込む」より扱いやすい。context window が大きくなっても、repository 全体の長期的な構造記憶を抱える場所としては向いていない。local index なら repository の横に残り、必要な時だけ小さな結果を返せる。
見ているのは keyword だけでなく structure
README が押し出している capability は明確だ。semantic search、relationship tracking、document search、MCP integration、profile。
この中で特に実務に効くのは relationship tracking だと思う。Agent にとって、「文字列を見つける」ことは最初の一歩にすぎない。本当に知りたいのは、その symbol が何なのか、どこから呼ばれるのか、何を呼ぶのか、interface implementation や dependency がどうつながっているのかだ。
これは AI coding tool が間違えやすい場所でもある。Model は関数名を見つけると、同じ文字列を全部関連ありと見なすことがある。入口だけ直して、別 implementation を見落とすこともある。Codanna がこうした relationship を tool call として返せるなら、大きめの project で agent が迷子になる確率を下げられる。
Semantic search は別の問題を扱う。人間が task を言うとき、code 内の正確な名前を使うとは限らない。「auth token expiry を処理している場所」と言っても、実際の code では refreshSession、credentialRenewal、validateClaims のような名前かもしれない。Keyword search だけでは当たりにくい。Intent query には semantic search のほうが向いている。
まず local に置くのがよさそう
Codanna は、現時点では local development environment や team で決めた agent workspace に置くのが一番合っていると思う。
Install path は README 上ではかなり明確だ。shell installer、Homebrew、Nix、Windows PowerShell script があり、Cargo などの選択肢も案内されている。初期化後は src を index でき、project docs を collection として追加することもできる。
この性格は company-wide search platform というより、「各 repository の横に置く index service」に近い。まず複雑な repository で試し、agent が Codanna 経由で関数を探し、call を追い、document を引けるか見る。その結果、blind search や間違った edit が減るかを観察するのがよい。
導入も段階的にできる。Team workflow を大きく変える必要はないし、IDE を移行する必要もない。Agent client が MCP を話せるなら、Codanna を extra tool として接続できる。
注意点
第一に、index は無料ではない。README では初回利用時に約 150MB の embedding model を download すると説明されている。Source build では Rust 1.85+ が必要で、Linux では OpenSSL 周辺の依存も必要になる。小さな使い捨て script repository には重いかもしれない。
第二に、Windows support は experimental とされている。Cross-platform team では、まず macOS、Linux、WSL の user で試し、その後で全員に広げるか判断するほうがよさそうだ。
第三に、どんな code intelligence index にも freshness の問題がある。Agent が file を変更したあと index がいつ更新されるのか、generated code をどう扱うのか、project 内の少し珍しい language や macro system をどこまで理解するのかで、結果の質は変わる。実務では Codanna の出力を「質の高い手がかり」として扱い、絶対的な事実とは見ないほうがよい。
第四に、まだ速く変化している小さな project だ。703 stars は十分な注目を示しているが、成熟した language server や commercial code search platform と比べると、stability と ecosystem は成長途中にある。
まとめ
Codanna が気になるのは、agent coding のかなり素朴な問題を切っているからだ。Model に「続きを書く」能力がないわけではない。足りないのは、「正しい場所で書く」ための context であることが多い。
Code structure、call relationship、semantic search、document retrieval を local MCP tool にすると、agent は grep 的な推測を少し減らし、engineer が自分で調べるような context に近づける。Architecture を代わりに設計してくれるわけでも、すべての edit を正しくするわけでもない。ただ、agent を「file 探索」から少し解放してくれる。
Claude Code、Codex、その他の MCP client をすでに実 repository で使っているなら、Codanna は複雑な project で試しやすい小さな tool だ。Workflow を大きく変えず、まず local code memory を 1 層足せる。