Codemem - AI coding assistant のための queryable code memory graph
AI coding assistant が時間を失いやすい場所は、必ずしも「code を書けない」部分ではありません。同じ repository を何度も探索し直す部分です。この service の entry point はどこか。この type は誰から参照されているか。前回なぜ別の実装を避けたのか。この diff は downstream call に影響するのか。人間の developer はこうした情報を頭、issue、commit、review の記憶として持っていますが、agent は次の session でまた rg と file reading から始めがちです。
今日紹介する cogniplex/codemem は、その問題に向けた local memory engine です。Rust で書かれており、AI assistant が codebase で見つけた files、symbols、edits、decisions、commit history を queryable knowledge graph として整理し、vector retrieval と MCP tools で agent に返します。GitHub page では現在およそ 14 stars、6 forks。主な言語は Rust、license は Apache-2.0。Latest release は v0.18.0 で、release date は 2026-05-20 です。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| Repository | cogniplex/codemem |
| 位置づけ | AI coding assistant の local code memory / knowledge graph engine |
| Stars | 約 14 |
| Forks | 6 |
| 主な言語 | Rust |
| License | Apache-2.0 |
| Latest version | v0.18.0 |
| Interface | CLI + MCP server |
Chat memory ではなく code memory
多くの AI memory tool は conversation summary に寄っています。User preference、前回の会話、project policy のような情報を保存する方向です。Codemem の狙いはもう少し engineering 寄りです。Agent が codebase で探索した事実を、次の code change で使える structured evidence として残すことに焦点を置いています。
README の考え方は明確です。Agent に必要なのは、長い text summary だけではなく queryable knowledge graph です。Commit は node になり、symbol は typed edge を持ち、edit と decision も trace として残る。次の session では「前回何をしたか」という summary だけでなく、「この function の upstream/downstream は誰か」「最近二週間で重要な file はどう変わったか」「この diff は high-centrality symbol に触れているか」を聞けるようになります。
ここが ordinary RAG tool との違いです。普通の RAG は code を chunk 化して semantic search することが多く、related snippet を探すには便利です。一方で call relationship、commit time、symbol impact radius までは扱いにくい。Codemem は vector search、graph traversal、BM25、time、repo/branch scope を組み合わせて、code modification に近い recall を目指しています。
Agent memory の chain を一通り作る
Codemem の入口は codemem init です。Initialize 時に local embedding model を download し、lifecycle hooks を登録し、対応する AI coding tool の MCP server 設定を行います。README では Claude Code、Cursor、Windsurf の auto detection が説明されています。
大きく見ると、chain は四層です。
- Context capture: session start、user prompt、tool use、stop、subagent、pre-compact などの hooks から、agent が読んだ file、search した symbol、行った edit を記録する。
- Structure building: tree-sitter、manifest parsing、optional SCIP indexer により、code symbol、file、commit、cross-service relation を graph にする。
- Hybrid retrieval: vector similarity、graph strength、BM25、scope、time、importance、confidence を合わせて recall score を作る。
- Back to agent: 32 個の MCP tools で memory CRUD、code search、graph traversal、temporal query、diff review、session context を提供する。
これは単に agent にもっと長い context を渡す仕組みではありません。必要なときに agent が tool を呼び、自分で過去の探索や code graph を問い合わせられる点が重要です。
32 個の MCP tools が見る問題
Codemem README では MCP tools がいくつかの category に分かれています。実際の development workflow で使いやすいのは、次の group です。
Memory tools は memory の write、recall、delete、associate、split、merge、refine を扱います。「この module がなぜこう設計されたか」「ある workaround をなぜ捨てたか」「debug session で確認済みの fact は何か」を残すのに向いています。Session end の短い summary だけでは、この粒度は失われやすいです。
Code and graph tools には search_code、get_symbol_info、get_symbol_graph、graph_traverse、find_important_nodes、find_related_groups などがあります。「file を探す」から「node、edge、related group を調べる」へ一段上げる tool 群です。大きな repository では、agent が directory tree から構造を推測し直すよりも安定します。
Temporal tools も特徴的です。what_changed、graph_at_time、find_stale_files、detect_drift、symbol_history により、agent は現在の working tree だけでなく time axis から codebase を見られます。Refactor 前に「この high-centrality file は 90 日間触られていないか」と聞けるだけでも、risk judgment は少し現実に近づきます。
Review tools では review_diff が diff を symbol と impact radius に mapping します。Test の代わりではありませんが、merge 前に「変更した symbol の direct / transitive dependents は何か」「diff に出ていないが一緒に確認すべき call site はないか」を agent に調べさせられます。
SCIP enrichment で IDE に近い graph を作る
Codemem は tree-sitter と ast-grep 系の structured analysis だけでも動きますが、README では optional な SCIP enrichment も強調されています。SCIP は Source Code Intelligence Protocol で、language indexer が生成した calls、references、imports、types などの関係を取り込めます。
現在 README に出ている indexer は Rust、TypeScript/JavaScript、Python、Go、Java/Kotlin、C#、Ruby をカバーしています。Codemem は Cargo.toml、package.json、pyproject.toml、go.mod などの manifest から言語を検出し、PATH にある対応 indexer を確認します。SCIP indexer がなくても動作しますが、その場合は edge source が ast-grep pattern に寄ります。Indexer がある場合、graph は IDE や language server が見る structure に近づきます。
これは agent にとってかなり大きい差です。AI は similar text を same semantics と見なしたり、local call を global impact と誤解したりします。SCIP があればすべて解決するわけではありませんが、reference relationship を pure guess から verifiable data に近づけられます。
Diff blast radius はすぐ試しやすい
Codemem で最初に試すなら、私は codemem review を見ます。Diff を読み、changed symbols、direct dependents、transitive dependents、risk score、potentially missing changes を出す機能です。Agent workflow の pre-commit stage に置きやすい。
たとえば agent が auth、billing、permission、schema migration のような high-impact area を変更したとします。通常の review では reviewer が手で call chain を追う必要があります。Codemem の価値は reviewer の判断を置き換えることではなく、まず impacted area を整理して、reviewer と agent の両方が確認すべき方向を見落としにくくすることです。
長い agent session の最後にも向いています。Agent は前半で多くの file を探索し、後半で二、三か所だけ変更することがあります。review_diff は final diff を code graph に戻して見直すので、「途中では知っていたのに最後に使わなかった」情報を拾いやすくします。
Local-first だが free ではない
Codemem の良いところは local-first な設計です。Single binary を目指し、SQLite、HNSW vector search、petgraph などの local component を使います。Embedding は default で Candle による local model を使え、初回におよそ 440MB の model download が必要です。README では Ollama、OpenAI-compatible API、Gemini などの embedding provider も設定可能です。
Private repository や enterprise codebase では、この方向は扱いやすいです。Code memory を必ず外部 service に送らずに済むからです。ただし、完全に cost-free ではありません。Initial indexing、embedding、SCIP enrichment、graph analysis には時間がかかります。大きな repository では cache、rebuild interval、team scope も考える必要があります。Workflow に組み込む前に、中規模 repository で recall quality と runtime cost を確認した方がよいです。
また、Codemem はまだかなり小さな project です。Stars は少なく、ecosystem maturity は一般的な IDE/LSP tool と同じではありません。Production workflow では、architecture decision や risk judgment を完全に任せるというより、assistant context の補助 layer として扱うのが現実的です。
最近の agent tooling と並べて見る
ここ数か月の AI coding tool には、だいたい三つの流れがあります。
- Agent が既存 tool をよりうまく呼ぶ方向。MCP、LSP、browser、test framework など。
- Agent が code structure をより理解する方向。Code graph、symbol search、blast radius analysis など。
- Agent が session をまたいで context を継続する方向。Memory、session summary、long-term project state など。
Codemem は二つ目と三つ目の境界にあります。新しい coding agent でも chat UI でもなく、agent の背後に置く code memory layer です。Claude Code、Cursor、Windsurf、その他 MCP client をすでに使っている team にとっては、差し込める structured tool set になります。
私が面白いと思うのは、memory を chat layer から engineering layer に戻している点です。Developer にとって有用な memory は、「user が refactor したいと言った」だけではありません。「どの symbol が変わったか」「なぜその design にしたか」「どの downstream がこの return value に依存するか」「前回の approach はなぜ失敗したか」です。Codemem がこれらを安定して保存し、次の change で agent が recall できるなら、repeat exploration をかなり減らせます。
試すのに向いている人
Codemem は次のような場面に合います。
- 同じ中大型 repository を AI agent で何度も変更しており、探索の重複が重い。
- Session summary だけでなく、local-first な MCP memory server を agent に渡したい。
- Diff impact、symbol history、architecture drift、code hotspot を見たい。
- Project language が tree-sitter または SCIP indexer で比較的よく covered されている。
- Early-stage tool の debugging cost を受け入れ、review の代替ではなく補助として使える。
小さな script や single-file project には重すぎるかもしれません。価値が出るのは、complex repository で「agent が今見たこと」と「codebase が元々持つ structure」を両方保存したい場合です。
まとめ
cogniplex/codemem は、注目する価値のある小さな Rust project です。AI coding assistant の memory を、local code graph、cross-session trace、hybrid retrieval、MCP tools、temporal query、diff risk analysis に分解しています。Agent が必ず正しい変更をする保証はありませんが、repeat exploration を減らし、structured evidence を増やせます。
今の AI programming workflow にとって、この方向は重要です。Context window が大きくなることと、codebase memory が reliable になることは同じではありません。次の一歩は、prompt にさらに text を詰め込むことではなく、project の変化に合わせて育つ code memory graph を agent が query できるようにすることかもしれません。