Recall：散らばった AI coding session をローカル索引にする
AI coding ツールを複数使い始めると、文脈は消えるというより、いろいろな場所に散らばる。
今日は Codex でテストを直し、明日は Claude Code でデプロイスクリプトを追い、週末には Cursor や OpenCode で別の方針を試す。各ツールにはそれぞれ会話ファイル、履歴形式、復帰方法がある。あとから「前回なぜこのモジュールを触らなかったのか」や「あの失敗したコマンドはどの session だったか」を探そうとすると、検索対象は互いにつながっていないローカルディレクトリの山になる。
今日メモしておきたい samzong/Recall は、この AI coding session の断片化を扱う小さなツールだ。チャットボットでもクラウド記憶サービスでもなく、Rust で書かれた local-first search across AI coding sessions である。Claude Code、Codex、OpenCode、Cursor、Gemini、Cline、Kiro、Copilot CLI、Antigravity などのローカル履歴をひとつの索引に同期し、TUI、セマンティック検索、使用量統計、JSONL エクスポート、resume の入口を提供する。
2026-07-08 時点で GitHub repository API、repository page、README、release page、commits page、LICENSE、Cargo.toml、Git history から確認できる公開情報では、samzong/Recall は 50 stars、9 forks。主言語は Rust で、GitHub の言語統計では Rust が約 97.4%。ライセンスは MIT。リポジトリ作成日は 2026-04-09 09:43:56 UTC、最新 push は 2026-07-07 15:59:32 UTC。デフォルトブランチは main。最新 release は v0.2.10 で、公開時刻は 2026-07-06 19:41:56 UTC。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | samzong/Recall |
| 位置づけ | ローカル AI coding session の検索、使用量統計、エクスポート、復帰入口 |
| Stars | 50 |
| Forks | 9 |
| 主言語 | Rust |
| ライセンス | MIT |
| リポジトリ作成日 | 2026-04-09 09:43:56 UTC |
| 最新 push | 2026-07-07 15:59:32 UTC |
| 最新バージョン | v0.2.10 |
| リリース公開時刻 | 2026-07-06 19:41:56 UTC |
| 主な入口 | recall sync、TUI、semantic search、usage dashboard、JSONL import/export、session resume |
まず「session がどこにあるか」を解く
多くの agent memory ツールは、会話から知識を抽出することに注目する。Recall はもう少し下の層にいる。まず、自分のマシン上で実際に発生した AI coding session を取り戻せるようにする。
README の使い方は素直だ。recall sync は増分同期、recall は TUI の起動、recall usage は使用量ダッシュボード、recall export と recall import --dry-run は JSONL の移行、recall session list はスクリプト向けの session 一覧、recall session share は選んだ session の共有に使う。さらに recall skill install で agent を自動検出し、対応する skill を入れる導線もある。
この方向性は「もうひとつノートアプリを作る」より日常の開発に近い。何を長期知識として残すかを先に決めるのではなく、まずローカルにどんな session があり、どの agent に属し、全文検索やセマンティック検索ができ、元の CLI に戻れるかを見えるようにする。
複数の履歴ディレクトリより、ひとつの索引がよい
AI coding の履歴には面倒な点が二つある。
ひとつは形式がそろわないこと。Claude Code、Codex、OpenCode、Cursor、Cline、Gemini などは、session の保存場所も構造も違う。もちろん grep は使えるが、JSONL、Markdown、データベース、独自ディレクトリが混ざると、横断検索はすぐに面倒になる。
もうひとつは、探したいものが必ずしもキーワードではないことだ。「あの migration を避けると決めた session があった」は覚えていても、当時の単語が migration だったのか schema だったのか rollout だったのかは忘れる。Recall の README が semantic search、full-index、incremental sync を同じ表に置いているのは、この種の手がかりを探しやすくするためだ。
local-first という設計も分かりやすい。README の謝辞には SQLite FTS5、sqlite-vec、Candle、Hugging Face、intfloat/multilingual-e5-small が出てくる。テキスト検索とベクトル検索を、できるだけローカルに閉じて扱う方向だ。
Codex をよく使う人に効くところ
Recall の面白い点は、「続きを見る」ことを検索結果の一部として扱っているところだと思う。
普通のログ検索は「その文章がどこにあるか」までは答えてくれる。coding agent の履歴では、もう一歩進んで、その session がどのツールのものか、元の文脈に戻れるか、別の流れにエクスポートできるか、token や使用量を見られるかが重要になる。README の対応表では、Codex、Claude Code、OpenCode、Pi、Gemini などが discovery、full-index、incremental-sync、semantic-search、export、resume、usage の多くをカバーしている。
その意味で Recall は、ローカルの agent history console に近い。結論の真偽を判断してくれるわけではないし、古い文脈を勝手に次の prompt へ注入するわけでもない。ただ、agent の操作を追跡したい、別ツールへ引き継ぎたい、特定プロジェクトの過去 session を見返したい、という場面で入口を集約してくれる。
注意したいところ
第一に、プロジェクトはまだ新しい。リポジトリ作成日は 2026-04-09、最新 release は 2026-07-06 の v0.2.10 で、README も約 65 行だ。個人の作業フローで試すにはよいが、検証なしにチームの監査基盤として扱う段階ではない。
第二に、これはローカル session の索引であって、長期知識ベースそのものではない。検索結果には、失敗した試行、古い仮説、agent の途中推論も混ざり得る。プロジェクトルール、デプロイ文書、セキュリティ方針に反映する内容は、人間が確認する必要がある。
第三に、複数 agent の対応には適配コストがある。README の表でも、resume や usage などの対応状況はツールごとに完全には一致しない。導入するなら、まず普段使っている一つか二つの agent で sync、検索、復帰の流れを確認したほうがいい。
第四に、ローカル索引にもプライバシー境界は必要だ。Recall の価値は履歴を手元に置くことだが、session には鍵の断片、顧客情報、内部パスが含まれることがある。export や share はログと同じ慎重さで扱うべきだ。
まとめ
Recall が見ているのは「agent に永遠の記憶を持たせる」ことではない。もっと素朴に、自分のマシンにはすでに多くの AI coding 履歴があるのに、なぜこんなに探しにくいのか、という問題だ。
その履歴をローカルのひとつの索引にまとめ、TUI、セマンティック検索、使用量統計、エクスポート、復帰入口を足す。毎日複数の coding agent を行き来している人には、かなり具体的な価値がある。ディレクトリを掘る時間を減らし、曖昧なキーワードを推測する回数を減らし、前回の作業で本当に何が起きたかを早く取り戻せる。