AI Agent に長い仕事を任せると、意外に無駄になるのは推論そのものではなく、同じことを何度も調べ直す時間だ。この project の deploy script はどこか、どの config は触ってはいけないか、前回の incident で何を確認したか、review でどんな判断をしたか。System prompt に全部入れると重くなり、chat history に置くだけでは session が切れた瞬間に扱いにくくなる。

今日見るのは Perseus-Computing-LLC/perseus-vault。AI Agent のための persistent memory engine として作られている。Rust の単一 binary、local SQLite database、MCP stdio server という構成で、memory write、recall、context preparation、history query、decay、archive、audit、maintenance を tool として出す。新しい chat UI ではなく、Claude Code、Codex、Cursor、Zed、Windsurf などの MCP client が共有できる local memory layer だ。

GitHub repository API、repository page、README、Release page、Cargo.toml、LICENSE、default branch の Git history を 2026-08-09 時点で確認すると、Perseus-Computing-LLC/perseus-vault は 43 stars、7 forks。主要言語は Rust、license は MIT。Repository created time は 2026-06-06 21:31:46 UTC、latest public push は 2026-08-09 13:56:08 UTC。Default branch main の現在の HEAD は 8fecaec、commit time は 2026-08-09 13:56:08 UTC、message は fix: overhaul Hermes integration (#911)。最新 GitHub Release は v2.22.0、published time は 2026-07-29 13:08:01 UTC。Cargo.toml の crate version も 2.22.0 になっている。

プロジェクト概要

項目内容
リポジトリPerseus-Computing-LLC/perseus-vault
位置づけlocal-first な AI Agent persistent memory MCP server
Stars43
Forks7
主要言語Rust
ライセンスMIT
作成日時2026-06-06 21:31:46 UTC
Latest push2026-08-09 13:56:08 UTC
現在の default branch commit8fecaec、2026-08-09 13:56:08 UTC
最新 GitHub Releasev2.22.0、2026-07-29 13:08:01 UTC
キーワードMCP、agent memory、SQLite、hybrid recall、local-first、AES-256-GCM、audit

「何を覚えたか」と「いつ取り出すか」を分ける

Agent memory という言葉は混ざりやすい。現在の prompt、chat transcript、session summary、vector store の record、project rules が全部 memory と呼ばれる。Perseus Vault の README はここを比較的はっきり分けている。現在の prompt や injected context は host 側の一時的な context。明示的に書き込まれた durable memory だけが Vault の管理対象。Export された Markdown や synthesized record は projection であって、source record の代わりではない。

この区別は実用的だ。Agent がある文章を「見た」ことと、それを永続的に保存したことは違う。perseus_vault_remember、perseus_vault_capture、CLI の write path などを明示的に通ったときだけ、Vault は SQLite に entity を書き込み、history、journal、decay、archive、purge の lifecycle に乗せる。会話終了時に何でも自動要約する方式より、制御しやすく、後から検査もしやすい。

Recall も単純な top-N dump ではない。README では perseus_vault_context と perseus-vault prepare が recall-first だと説明されている。呼び出し側が現在の task を query として渡し、Vault はその task に関係する少量の memory を model budget に合わせて返す。Memory database が増えても、毎 turn の context が線形に膨らまない。この点は長期運用ではかなり重要だ。

SQLite と local-first で試しやすい

Perseus Vault の deployment model は素朴だ。単一 binary、SQLite database file、Docker も Postgres も hosted control plane も不要。README の one-line install は binary を ~/.local/bin/perseus-vault に置き、次のように起動する。

perseus-vault serve --db ~/.perseus-vault/data/perseus-vault.db

install-client --hooks --rules を使うと、Claude Code、Codex、Cursor などの client に MCP config と session lifecycle hooks を入れられる。既存 config は backup され、--dry-run で変更内容も確認できる。

Local-first も単なる雰囲気ではない。README によると、default path の初回 write で ~/.perseus-vault/secret.key が生成され、新規 database では AES-256-GCM encryption が有効になる。Semantic recall は binary に組み込まれた local embedding model を使うのが default で、OpenAI-compatible embedding endpoint は optional だ。最小構成では memory を外部 service に送らずに始められる。

ただし caveat はある。検索用の FTS5 index は plaintext のままだと README は説明している。Entity body が暗号化されても、database file、key file、backup、exported Markdown、search index をまとめて保護しないと、機密性は期待通りにならない。Sensitive な情報を入れるなら、試用段階から threat model を決めておいたほうがいい。

MCP tool surface は広いが、最初は絞りたい

README に並ぶ tool はかなり多い。remember、recall、scan、history、as_of、valid_at、bitemporal、journal、state、decay、prune、purge、redact、erase、vault export/import、health、stats、maintenance などがある。単なる note keeper ではなく、長期 knowledge store の lifecycle を一通り扱おうとしている。

特に面白いのは bi-temporal query だ。as_of は transaction-time、つまり過去のある時点で system が何を信じていたかを見る。valid_at は valid-time、つまり現実世界のある時点で何が真だったかを見る。bitemporal はその二つを組み合わせる。Project facts は変わるので、これは Agent memory と相性がよい。先週正しかった deploy rule が、今週は migration 後に古くなっているかもしれない。

一方で、tool が多いほど接続時の権限設計は重要になる。すべての client に purge、erase、cross-workspace copy を渡す必要はない。まずは remember、recall、context、health のような低リスク tool に絞り、personal project で recall quality を見る。その後で capture、journal、maintenance を段階的に開けるのが現実的だ。Memory system が Agent の判断に影響するなら、それ自体を infrastructure として扱うべきだ。

どんな人に向いているか

Perseus Vault は、すでに複数 turn の Agent workflow を日常的に使っている人に向いている。たとえば Codex で server maintenance をしていて、deploy constraints、検証済み command、触ってはいけない directory、前回の incident root cause を覚えさせたい場合。あるいは複数の MCP client を行き来していて、client ごとに別々の summary を持つのではなく、同じ local memory を共有したい場合だ。

Project experience を chat history から取り出す用途にも合う。Experience は category、key、body を持つ entity として書ける。History と source が残り、recall strategy も持てる。次の task では、Agent が task query で関連 memory だけを取り出す。古い summary を全部 prompt に貼るより、長く続けやすい。

逆に、たまに小さな file edit を Agent に頼むだけなら重い。AGENTS.md、README、普通の notes で十分なことも多い。Perseus Vault の価値は、長期蓄積、cross-session recall、auditable lifecycle が必要になったときに出てくる。

注意したい境界

第一に、project はかなり若い。43 stars、7 forks、2026 年 6 月作成、release は v2.22.0。開発は速いが、community validation はまだ少ない。最初は personal project や non-critical workflow で試し、production change の判断に直結させないほうがいい。

第二に、README の benchmark や比較表は project author の主張として読むべきだ。方向性を見る材料にはなるが、本当に効くかどうかは自分の memory write quality、recall precision、誤 recall のコスト、権限設計で決まる。

第三に、automatic capture は memory pollution を起こしやすい。間違った推測、一時的な path、古い command、使い捨ての判断まで永続化すると、次の Agent が古い noise に引っ張られる。Memory には cleaning、archive、decay、correction の運用が必要だ。

第四に、key management は重要だ。README は default secret key が recover できないと明記している。Database backup は key がなければ読めず、key が漏れれば local encryption の意味が薄れる。試用段階から backup と rotation を考えておきたい。

まとめ

Perseus-Computing-LLC/perseus-vault が面白いのは、Agent memory を自動要約テキストではなく、動かせて、検査できて、保守できる local system として扱っているところだ。SQLite、MCP、hybrid recall、bi-temporal history、encryption、lifecycle tools を一つにまとめ、明示的に書いた facts を必要なときだけ取り出す方向に寄せている。

まだ早い project だが、扱っている摩擦は本物だ。AI Agent を長く使うほど、毎回再発見すべきではない知識が増えていく。それを prompt に詰め続けるのではなく、検査できる local database にする。Perseus Vault はそのための小さくまとまった実装として、観察する価値がある。

リポジトリ：https://github.com/Perseus-Computing-LLC/perseus-vault