Recall: Claude Code 用ローカルプロジェクトメモリ

Recall は Claude Code に耐久性のあるオフラインメモリを提供します

Recall は、Claude Code セッションにおける「コールドスタート」問題を解決するために設計されたローカルファーストプラグインです。セッションの活動を自動的に取得し、ユーザーのマシン上に完全に保存されたコンパクトで再開可能な要約に凝縮します。LLM の代わりに従来の Python 要約器を使用することで、Recall は開発者が追加のモデルトークンを消費したり、機密性の高いセッション文字起こしを外部 API に送信したりすることなく、プロジェクトコンテキストを保持したまま作業を再開できます。

コア機能とメモリアーキテクチャ

Recall は、プロジェクトルート内の .recall/ ディレクトリに保存される 2 つの主要ファイルでプロジェクトメモリを管理します：

history.md: すべてのセッションを記録する追記専用ログで、プロンプト、Claude の応答、触れたファイル、実行したコマンドを含みます。
context.md: プロジェクトの現在の状態を凝縮した要約で、目標、進捗の概要、次のステップ、未解決のスレッド、触れたファイルのリストを含みます。

ローカル要約プロセス

多くのメモリツールが LLM 呼び出しに依存するのとは異なり、Recall は決定論的なローカルアルゴリズムを使用して context.md を生成します。要約器（scripts/summarizer.py）は TF-IDF（Term Frequency-Inverse Document Frequency）と TextRank（文ベクトルの余弦類似度グラフ上で PageRank に基づくパワーイテレーション）を利用しています。

この抽出的要約アプローチは次を保証します：

トークンコストゼロ: メモリの更新は既存の Claude Code サブスクリプション以外に費用がかかりません。
プライバシー: 文字起こしや機密情報はローカルマシンから外部に出ません。
依存関係なし: 実装は純粋な Python でベンダリングされており、numpy は大規模セッション向けのオプションアクセラレータとして使用されますが、ツールの動作に必須ではありません。

Claude Code との統合

Recall は既存の Claude Code のメモリ機能を置き換えるのではなく補完します。手動指示と完全な文字起こし再生の間の特定のギャップを埋めます：

機能	`CLAUDE.md` / `#`	`--continue` / `--resume`	Recall
性質	手書きのルール/メモ	会話全体の再生	自動取得ログ + ローカル要約
保守	手動	なし	自動
内容	従うべき指示	過去の全文文字起こし	目標、ファイル、コマンド、次のステップ
再開コスト	小	大（トークン多）	~1–2K トークン（コンパクトな要約）
形式	編集可能な Markdown	ローカルセッション状態	`.recall/` 内のプレーンテキスト

ワークフローとコマンド

Session Start: SessionStart フックが context.md を提示し、保存されたコンテキストから再開しセッションのログを継続するかユーザーに尋ねます。
During Session: Stop と SessionEnd フックが history.md に活動を段階的に追記します。
Saving Context: ユーザーは /recall:save を実行してローカル要約器を起動するか、recall.config.json の auto_save_context: "on_end" を有効にしてプロセスを自動化できます。
Utility Commands: /recall:show は現在のコンテキストを表示し、/recall:log は履歴ログをリアルタイムで表示します。

プライバシー、セキュリティ、設定

Recall はデータ漏洩とコード実行を防止するために厳格な信頼境界を設計しています：

ネットワーク分離: プラグインはネットワーク呼び出しを行わず、API キーも不要です。
シークレット除去: ベストエフォートで一般的なシークレット形式（API キー、PEM キー、.env の代入）をディスクに書き込む前に除去します。
強化された Git 統合: コンテキスト要約のために git diff や log を取得する際、Recall は core.fsmonitor、diff.external、フックを無効化し、信頼できないリポジトリからのコード実行を防ぎます。
パス制限: output_dir はプロジェクトディレクトリ内に留まるよう強制され、ディレクトリトラバーサル攻撃を防止します。

コミュニティの視点と代替案

開発者間の議論は、エージェントメモリ管理に対するさまざまなアプローチを示しています。Recall の自動化が監査や「横断的コンテキスト」の取得に有用と考える人もいれば、手動の代替手段に頼る人もいます：

手動ステータスドキュメント: 一部のユーザーは日付付き Markdown ファイルを含む status_docs/ フォルダを維持し、人間と LLM の両方のプロジェクト日誌として機能させています。
手動状態管理: 他のユーザーは state.md ファイルを使用し、マイルストーンで更新し、手動で「行き止まり」やデバッグ失敗の試みを除去します。
自動化への懐疑: 一部の開発者は、エージェントが古い計画や失敗した推測で「中毒」されるのを防ぐために、最初から新しいセッションを開始する方が好ましいと主張します。

"プロジェクトメモリで難しいのは、より多く保存することではなく、後で何を信頼しないかを決めることです。古い計画やデバッグ失敗の推測は、エージェントを静かに、しかし速やかに中毒させる可能性があります。"