Uteke: AI agent に local-only semantic memory を足す
AI agent を実プロジェクトで使うと、失われやすいのは 1 回の回答ではなく、session をまたぐ小さな事実だ。
たとえば staging 環境の deployment 手順、incident review で決めたこと、ある project で「この API はもう使わない」と判断した理由、前回 agent が調査途中で見つけた手がかり。こうした情報は chat history、issue、notes、shell history に散らばる。次に agent を開くと、また質問し、また読み、また推測するところから始まりがちだ。
今日メモしておきたい codecoradev/uteke は、AI agent のための local memory tool だ。完全な agent platform でも cloud RAG service でもない。Rust 製の offline-first semantic memory engine として、SQLite/FTS5 に text と metadata を保存し、local ONNX embedding で semantic recall を行い、CLI、HTTP server、Docker、MCP server から使えるようにする。
GitHub repository API、README、release page、license file、docs/mcp.md、docs/docker.md から 2026-07-07 に確認できる公開情報では、Uteke は現在 33 stars、6 forks。repository の主言語は Rust、license は Apache-2.0、作成日は 2026-05-29。直近 push は 2026-07-06 15:25 UTC。default branch は develop。最新 release は v0.6.7 で、GitHub release page 上の公開時刻は 2026-07-06 05:12 UTC。
Project Overview
| 属性 | 内容 |
|---|---|
| Repository | codecoradev/uteke |
| 位置づけ | local-first AI agent memory engine / CLI / MCP server |
| Stars | 33 |
| Forks | 6 |
| 主言語 | Rust |
| License | Apache-2.0 |
| Repository 作成日 | 2026-05-29 |
| Latest push | 2026-07-06 15:25 UTC |
| Latest version | v0.6.7 |
| Release time | 2026-07-06 05:12 UTC |
| 核心アイデア | agent memory を local に検索可能、tag 付け可能、MCP から呼び出し可能な軽量 storage layer にする |
扱っているのは agent の「覚えていない」問題
最近の AI coding workflow では、model が足りないというより、continuity が足りないことが多い。
Model は repository を読み、test を走らせ、patch を書ける。ただ、前回なぜある file を避けたのか、ある environment variable がどの service に対応するのか、team がすでにどの migration path を捨てたのかは知らない。人間の developer はこうした情報を頭、notes、review に残す。Agent に外部 memory がなければ、毎回 current prompt と filesystem からやり直すしかない。
Uteke の切り口は小さい。Agent が明示的に remember と recall を使えるようにする。README の quick example では、deployment memory を tags、entity、category 付きで保存し、natural language query で呼び出す。Room、author、memory type、metadata、relationship graph、pin/unpin など、整理のための要素も用意されている。
これは「chat log 全体を context に戻す」こととは違う。再利用できる事実を小さな record として保存し、tags、room、semantic retrieval で関連部分だけを取り出し、agent が採用するか判断するほうが扱いやすい。
Local-first が一番はっきりした取捨選択
Uteke の README は offline-first と single binary を強く押し出している。Default path では OpenAI key、Qdrant、Postgres、Neo4j、別 Python service は不要だ。初回実行時に約 188MB の embedding model を download し、その後の data は local machine に残る。
この選択は、次のような context に向いている。
- project 内部の decision、deployment step、customer environment の手がかりを cloud memory provider に送るのは避けたい;
- Codex、Claude Code、Cursor などの agent に memory layer を足したいが、vector database を運用したくない;
- offline、intranet、sensitive code environment で agent が検索できる memory を持ちたい;
- 完全な platform 導入ではなく、まず command-line tool から試したい。
設計も素直だ。SQLite storage、FTS5 full-text search、local embedding、HNSW vector index。Semantic retrieval と keyword retrieval を合わせて使うのは、この種の短い事実には現実的だ。Deployment step、function name、environment name、tag、version number は、意味だけでなく exact match も重要になる。
MCP 接続なので孤立した note tool になりにくい
Uteke が agent workflow で意味を持つのは、MCP server を提供しているからだ。
docs/mcp.md では 2 つの接続方式が説明されている。Local agent には stdio transport が推奨され、uteke-mcp を直接動かす。HTTP が必要な場合は uteke-serve を起動し、http://127.0.0.1:8767/mcp で接続する。文書は境界も明確にしている。MCP は tool-based integration であり、memory が毎 turn 自動注入されるわけではない。Agent が uteke_recall、uteke_remember などをいつ呼ぶか決める。
この制約はむしろよい。Memory system が毎回古い情報を自動注入すると、無関係な過去の事実が入り込み、現在の task を汚すことがある。Tool-based call なら、開発上の明示的な操作に近い。Code を直す前に project background を recall する。調査が終わったら conclusion を保存する。Environment issue に当たったら tag で history を探す。
Coding agent にとって、これは「別の notes app を開く」より自然だ。Memory は repository や user machine の近くに置ける。Agent は必要な時に呼び、developer は CLI や HTTP API で中身を確認、import、export できる。
Interface は小さいわりに揃っている
Uteke は小さな project だが、入口は少なくない。
CLI では uteke remember で memory を保存し、uteke recall で hybrid retrieval を行い、uteke stats で状態を見る。Docker docs では local HTTP server として 127.0.0.1:8767 に立てられることが示されている。Default は localhost のみで、外に出す場合は UTEKE_AUTH_TOKEN を設定する。
MCP docs にある tools は、storage、semantic recall、text search、document、room、graph、pin/unpin などを含む。直近 push の commit message も MCP 向け pin/unpin tools の追加で、project が agent usage を中心に速く機能を足していることが分かる。
もう 1 つ良い点は、memory を単なる text chunk としてだけ扱わないことだ。Type、room、author、tags を持つ record として扱う。長く使う project や multi-agent workflow ではこれが効いてくる。たとえば repository ごとに feature room を作って design decision を保存し、人間と agent の書き込みを author で区別できる。
どんな場面に合うか
Uteke は、まず個人の agent workspace や小さな team の共有環境で試すのがよさそうだ。
Codex、Claude Code、その他の MCP client で毎日 project を直しているなら、繰り返し出てくる facts を保存できる。Test command の罠、deployment environment の違い、module に関する過去の decision、前回調査で残った direction。次回 agent が始める前に project や tag で recall するほうが、巨大な prompt に追記し続けるより保守しやすい。
軽量な agent runbook としても使える。よくある障害、service name、調査順、禁止操作を searchable memory として置く。Agent がすべてを自動で守るわけではないが、task 開始時に local project に近い context を取り出せる。
より正式な team knowledge base としては、Uteke はまだ最終形ではないかもしれない。ただ、local agent memory として見るなら、deployment cost と privacy boundary はかなり扱いやすい。
注意点
第一に、project はかなり新しい。Repository 作成日は 2026-05-29、現時点の stars は 33、latest release は v0.6.7。試用や小さな workflow には向くが、評価なしに team の critical infrastructure にする段階ではない。
第二に、初回利用時に embedding model を download する。README と Docker docs では約 188MB と説明されている。Pure text notes より重いが、外部 vector database を運用するよりは軽い。
第三に、memory は事実そのものではない。Agent が保存した内容は古い、間違っている、context が足りない可能性がある。Code change、deployment、security operation に使うなら、repository、logs、config、tests で確認する必要がある。
第四に、MCP は明示的な tool であって魔法の memory ではない。文書も auto recall や auto extract ではないと説明している。有効に使うには、「重要な conclusion を保存する」「大きな task の前に recall する」という workflow の癖が必要になる。
まとめ
Uteke が気になるのは、agent memory を十分小さく作っているからだ。Local binary、SQLite-backed store、CLI/HTTP/MCP interfaces。
この種の tool は、agent に突然長期人格を与えるものではないし、project documentation を置き換えるものでもない。ただ、毎回説明し直しているが cloud memory service には預けたくない小さな engineering facts を、local に残して tool call で取り出せるようにする。
すでに実 project で MCP-compatible coding agent を使っているなら、Uteke は低リスクに試せる。Deployment step、module convention、debugging conclusion、project caveat を保存し、agent が同じ質問や同じ遠回りを減らせるか観察する。価値は「すべてを覚える」ことではなく、再利用できる engineering context を queryable local asset にすることにある。