mimirs：AI coding agent に検索できる project memory を渡す
AI coding agent が context を浪費しやすいのは、実際に patch を書く数行ではなく、毎回 project を理解し直す部分だ。File がどこにあるか、この概念は何という名前か、test entry はどこか、前回なぜその道を避けたのか。人間の developer はこうした project memory を頭の中に残しているが、agent は新しい session でまた grep し、README を読み、directory structure を推測しがちだ。
この問題は、必ずしもより大きい context window だけで解く必要はない。もっと実務的な方法は、project ごとに local で更新でき、検索できる memory layer を置くことだ。Code chunk、symbol relation、wiki、conversation history、manual annotation を repository の近くに置き、agent が必要なときだけ取り出せるようにする。
今日見るのは TheWinci/mimirs。AI coding agents 向けの local MCP server / CLI で、Bun、SQLite、sqlite-vec、semantic search、AST-aware chunking、dependency graph、conversation history を使って project context を保存する。README の位置づけはかなり直接的で、persistent project memory for AI coding agents、一つの command で setup し、その後はできるだけ手間をかけない、というものだ。Claude Code、Cursor、Windsurf、JetBrains Junie、GitHub Copilot、そして stdio MCP server を扱える任意の client に対応する。Codex も ~/.codex/config.toml から手動で接続できる。
GitHub repository API、README、LICENSE、Releases page、Tags page、package.json、recent commit を 2026-08-16 時点で確認すると、TheWinci/mimirs は 29 stars、2 forks。主要言語は TypeScript。GitHub repository API と package.json は license を Apache-2.0 と報告しており、LICENSE file も Apache License 2.0 text だ。Repository created time は 2026-03-16 22:51:00 UTC、latest public push は 2026-08-15 09:23:55 UTC、default branch は main。GitHub Releases page には現在 正式な Release はない。Tags page の最新 tag は v1.7.1、日付は 2026-06-22。main branch の現在の package.json version は 1.8.0、recent commit は 8c11a54、message は 1.8.0、commit time は 2026-08-15 11:21:41 +02:00。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | TheWinci/mimirs |
| 位置づけ | AI coding agent 向けの local project memory / code retrieval MCP server |
| Stars | 29 |
| Forks | 2 |
| 主要言語 | TypeScript |
| ライセンス | Apache-2.0 |
| 作成日時 | 2026-03-16 22:51:00 UTC |
| Latest push | 2026-08-15 09:23:55 UTC |
| Default branch | main |
| GitHub Releases | 正式 Release なし |
| 最新 tag | v1.7.1、2026-06-22 |
| 現在の package version | 1.8.0 |
| Recent commit | 8c11a54、1.8.0 |
| キーワード | MCP、semantic search、SQLite、local-first、agent memory、code graph |
解いているのは「毎 session のゼロスタート」
mimirs の目的は IDE を置き換えることでも、汎用 vector database を作ることでもない。むしろ、agent が繰り返し行う repository exploration を沈殿させる tool に近い。Project を index し、search、read、project map、dependency graph、annotation、conversation search といった tools を提供することで、agent が code を書く前に relevant files と過去 context を素早く取り出せるようにする。
README には分かりやすい問題設定がある。Agent は session 開始時、file name を推測し、keyword で検索し、context を燃やし、昨日話したことを忘れる。mimirs の答えは、それらを local SQLite に残し、MCP 経由で agent に渡すことだ。Model に repository 全体を一度に飲み込ませるのではなく、model が小さな質問を投げ、index からより relevant な断片を返す。
これは中規模以上の codebase で特に効く。多くの修正は難しい patch そのものより、「本当に変更すべき場所」を見つけるまでが長い。Agent が毎回 ls、find、grep auth から始めるなら、会話の最初の数往復は探索に消えてしまう。mimirs はその探索を project-level cache にする。Files、chunks、symbols、call relation、conversation history が少しずつ積み上がる。
Local-first なので codebase に向いている
この project の大事な取捨選択は local-first であることだ。README は API key、cloud service、Docker が不要で、core dependency は Bun と SQLite だと説明している。Index は default で project の .mimirs/ directory に置かれる。Repository が read-only mount にある場合は、RAG_DB_DIR で writable location に index を逃がせる。
Codebase context ではこの設計が重要になる。Team は public issue を model に渡すことには抵抗がなくても、private repository 全体、過去の議論、一時 annotation を外部 memory service に預けたいとは限らない。mimirs が model call まわりの data boundary をすべて解決するわけではないが、少なくとも project memory layer は手元に残せる。「agent に project を覚えさせるために cloud knowledge base を入れる」圧力を下げられる。
Editor ecosystem への接続も現実的だ。README には Claude Code、Cursor、Windsurf、JetBrains Junie、GitHub Copilot の MCP config snippet があり、Codex 向けの TOML 例もある。最短経路は次のような形だ。
bunx mimirs init --ide claude
bunx mimirs index
bunx mimirs status自動初期化を使わない場合でも、stdio MCP server として bunx mimirs@^1 serve を client に登録し、RAG_PROJECT_DIR で project root を指せばよい。この形なら、まず重要度の低い repository で試しやすい。Server-side architecture を変える必要はない。
Search だけでなく、wiki、graph、会話記憶もある
mimirs で一番分かりやすい機能は semantic search だが、file に embedding を貼るだけではない。package.json と README から見える範囲でも、AST-aware chunking、dependency graphs、conversation history、project wiki、annotation、affected tests、symbol usage などを扱う。つまり「agent が project について知るべきこと」をいくつかの tool に分解している。
これは大事だ。Code search は常に「似ている text を探す」ではない。ある時は function の caller を知りたい。ある時は module change がどの tests に効くかを知りたい。ある時は前 session の結論を取り出したい。ある時は project structure の summary が欲しい。mimirs は MCP tools として入口を分けるので、agent はすべてを普通の grep query に翻訳しなくて済む。
README には Django、Kubernetes、Excalidraw、mimirs 自身で測った Recall@10 や MRR などの benchmark も載っている。この blog ではそれを第三者検証済みの数字として扱う必要はないが、作者が retrieval quality を見ていることは分かる。単なる「code を vector database に入れました」demo ではなさそうだ。
Caveats
第一に、mimirs はまだ小さい project だ。29 stars、2 forks で、GitHub Releases page に正式 release もない。package.json は 1.8.0 まで進んでいるが、Tags page の最新 tag は v1.7.1 に留まっている。Production team が日常 agent workflow に入れるなら、version cadence が速く、interface がまだ動く可能性を受け入れる必要がある。
第二に、Bun と SQLite extension に依存する。個人の development machine では難しくないが、controlled enterprise environment、remote dev container、Windows/macOS mixed team では、Bun path、SQLite version、GUI 起動の editor から PATH が見えない問題が現実になる。README が bunx を GUI editor から見つけられない case をわざわざ説明しているのは、この点が机上の問題ではないからだ。
第三に、memory system は maintenance cost も生む。古い annotation、過去 conversation、誤った index、削除済み file への relation が残れば、agent を誤誘導するかもしれない。mimirs には index や wiki update の path があるが、team 側でも何を長期保存し、何を branch や task 終了時に消すかを決める必要がある。
まとめ
TheWinci/mimirs が面白いのは、agent memory を抽象的な slogan にせず、local project workflow に落としているところだ。Bun で起動し、SQLite に保存し、MCP で tools を公開し、editor から直接使う。Agent に必要なのは無限の context ではなく、繰り返し問い合わせられ、少しずつ育つ project clues だという前提に立っている。
Claude Code、Cursor、Windsurf、Codex、あるいは自作 MCP client で、同じ codebase を agent に何度も触らせているなら、mimirs は中規模 repository で試す価値がある。最適な用途は「model にすべてを覚えさせる」ことではない。各 session の cold start を減らし、file を探す時間と document の読み直しを削り、本当に変更すべき code に注意を向けることだ。