deja-vu：agent の会話ログを検索できるローカル記憶層にする
AI coding agent で無駄になりやすいのは、最初に問題を解く時間だけではない。同じ問題を二度目にまた最初から調べ直す時間も大きい。先週直した database connection pool、昨日確認した deploy script の境界、長い会話の中で決めた design trade-off は、多くの場合ローカルの session logs に残っている。人間は「前にやった気がする」と覚えているが、agent は新しい問題として検索と推論をやり直しがちだ。
今日紹介する vshulcz/deja-vu は、その隙間を狙った tool だ。project code の RAG でも hosted knowledge base でもなく、Claude Code、Codex、opencode、aider、Gemini CLI、Cursor、Antigravity、Grok Build、Qwen Code がすでに local に書いている conversation records を index し、local-first な agent memory layer にする。deja "jwt refresh token" で過去を検索でき、deja mcp を agent に接続すれば、再デバッグの前に recall tool で過去の session を確認できる。
2026-07-19 時点で GitHub repository API、README、release page、latest commit API、LICENSE、go.mod から確認できる公開情報では、vshulcz/deja-vu は 367 stars、17 forks。GitHub の primary language は Go、license は MIT。repository creation time は 2026-07-14 07:45:44 UTC、default branch main の latest push は 2026-07-19 09:48:55 UTC。最新の main commit は 9505393 で、message は fix(install): spawn the MCP server through cmd on windows (#170)。最新 GitHub release は v0.13.0、published time は 2026-07-18 21:47:21 UTC。go.mod は現在 Go 1.25 を宣言している。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | vshulcz/deja-vu |
| 位置づけ | local agent session search、MCP recall、自動 context memory layer |
| Stars | 367 |
| Forks | 17 |
| 主言語 | Go |
| ライセンス | MIT |
| GitHub 作成時刻 | 2026-07-14 07:45:44 UTC |
| 最新 push | 2026-07-19 09:48:55 UTC |
| 最新 main commit | 9505393、fix(install): spawn the MCP server through cmd on windows (#170) |
| 最新 release | v0.13.0、2026-07-18 21:47:21 UTC |
| キーワード | agent memory、MCP、CLI、local-first、redaction、session search |
すでに存在する記録を使う
deja-vu の面白いところは、新しい knowledge management workflow を先に要求しない点だ。多くの agent tool はもともと local machine に session logs を残している。Claude Code の JSONL、Codex の sessions と history、opencode の SQLite database、aider の chat history、Cursor の agent transcripts などだ。deja-vu はそれらの store を発見し、message を parse し、redaction し、index を作り、必要なときに取り出せるようにする。
この角度はかなり実用的だ。team knowledge base が失敗しやすいのは、書き込みコストが高いからだ。一方で agent session records はすでに書かれている。ただ検索できず、引用しにくく、machine 間で扱いにくい。deja-vu は「前に agent とどう解いたか」を記憶の断片から、CLI と MCP で呼べる local database に変える。
README の使い方も直接的だ。install 後に deja install --all を実行すると、対応する harness に MCP recall をつなぐ。deja install --auto を使うと、hook を持つ tool では session start 時に関連する history を context に注入できる。Codex、Claude Code、opencode、Cursor のような tool に対して、「まず過去を調べる」習慣を追加する形だ。
MCP recall が検索以上に効く
もちろん command-line search も便利だ。terminal で error message、file path、design keyword を探し、その結果を prompt に戻せる。ただ deja-vu が agent workflow に向いている理由は、その操作を MCP server にしているところにある。
README に並ぶ MCP tools は recall、recall_context、blame、remember だ。recall は compact snippets を返し、agent が「この問題を見たことがあるか」を素早く判断するのに向く。recall_context は best match を markdown digest にする。blame は file path から、その file を議論した sessions を探す。remember は明確な conclusion を durable notes として保存する。つまり単なる “chat log search” ではなく、過去の会話を agent が能動的に呼べる tool にしようとしている。
長期 project ではこれが効く。多くの bug fix は純粋な code fact ではなく、文脈付きの decision だ。なぜある library を upgrade しなかったのか、なぜ compatibility path を残したのか、なぜある CI failure を external issue と判断したのか。README に書くほどではないが、session memory には残しておきたい情報が多い。
privacy と redaction は避けられない境界
agent session を index するなら、現実的な問題がある。session には secrets、internal URL、customer data、failure logs、temporary tokens が混ざる可能性がある。deja-vu はこの点を避けていない。README では、index 時に AWS keys、api_key= / token= 形式、bearer tokens、JWT、PEM private key、よくある provider tokens、credential 付き URL を redaction すると説明している。deja share と deja sync export でも export 時に再度 redaction する。
さらに deja forget は tombstones を使い、後続の re-index で削除済み session が戻らないようにする。deja stats --redaction は harness と rule ごとの redaction facts を表示できる。DEJA_NO_REDACT=1 は明示的に unsafe な opt-out として扱われている。
この設計により、「すべての chat logs を全文検索に入れる」だけの tool より信頼しやすい。ただし caveat もはっきりしている。redaction rule は formal security proof ではない。sensitive repository、customer environment、compliance-heavy な setting では、どの harness を読むのか、index がどこに置かれるのか、sync/share を使うのか、その data flow を team が受け入れられるのかを先に確認する必要がある。
local-first だが依存がゼロとは言わない
deja-vu の README は “one binary、no models、no services、nothing leaves your machine unless sync/share” という位置づけを前面に出している。これは個人の development machine には向いている。vector database も cloud service も不要で、毎回 query のために model を呼ぶ必要もない。
同時に、すべてが完全に dependency-free だとは書いていない。README では opencode と Cursor IDE の indexing が sqlite3 CLI に shell out すると説明している。semantic recall は optional layer で、local Ollama、LM Studio、または OpenAI-compatible embedding endpoint を使い、deja embed が vector sidecar を書く。embedding endpoint がない場合でも、ordinary lexical search と MCP recall は動き続ける。
この整理はむしろ良い。agent memory の default path は stable、explainable、offline であるべきだ。semantic layer は enhancement として足せばよい。最近の “AI memory” project は早く black-box embedding store に寄りがちだが、deja-vu の default は日常の developer が維持しやすい形に近い。
誰に向いているか
同じ codebase で毎日 agent を使う人には、deja-vu は試す価値がある。特に「難しい問題ではないが、context がいつも失われる」workflow に向く。CI flakes を前回どう扱ったか、ある module をなぜ直接消せないのか、production incident の調査経路、migration script が前回どこで詰まったか、といった情報だ。
複数の agent tools を切り替える人にも向いている。README に並ぶ supported harnesses は広い。Claude Code、Codex CLI、opencode、aider、Gemini CLI、Cursor、Antigravity、Grok Build、Qwen Code。各 tool の history は本来それぞれの directory に閉じているが、deja-vu は少なくとも一つの search entry point を与える。
一方で、一回限りの project が多く、各 project で agent を数回しか使わないなら価値は弱くなる。memory layer は history が蓄積して初めて効く。十分な過去 session がなければ、これはよくできた local log searcher に近い。
注意したいところ
第一に、project は非常に若い。repository は 2026-07-14 作成で、今日時点でまだ数日しか経っていない。release は v0.13.0 まで進み、latest commit も 2026-07-19 だが、API、index format、install behavior はこれから変わる可能性が高い。
第二に、自動 context injection は慎重に扱いたい。deja install --auto の体験は良さそうだが、自動注入は agent の初期判断に影響する。README では default の DEJA_RECALL=safe が current project に制限し、weak results を filter し、injection size を絞ると説明している。それでも初回導入では、まず manual recall や CLI search で hit quality を観察する方がよい。
第三に、share と sync は data boundary だ。redaction があっても、deja share と deja sync export/import は session digest や records を別の場所へ移す。個人の machines 間では便利だが、company environment では policy の確認が必要になる。
第四に、Windows support はまだ素早く修正されている途中だ。今日の latest commit 自体が、Windows stdio MCP client を cmd /c 経由で起動する修正だった。maintainer の反応が速いとも言えるし、cross-platform agent config がまだ動き続けている領域だとも言える。
まとめ
deja-vu の価値は、複雑な新しい memory architecture を発明したことではない。あなたの agent history はすでに local にあるが、うまく index されず、呼び出されていない、という事実を拾ったことだ。これを CLI、MCP recall、自動 context、redacted sharing、sync として使えるようにしている。小さく、実際の development workflow に近い。
「これは前に agent と話したはず」と感じることが多いなら、vshulcz/deja-vu を non-critical project で数日試す価値がある。agent experience の改善は、常により賢い model から来るとは限らない。すでに行った作業を、検索でき、引用でき、再利用できる形に戻すだけでも効くことがある。