mnemos: AIコーディングエージェント向け永続メモリ層（Go、MCPネイティブ、Python不要）

mnemosは、AIコーディングエージェントのための永続メモリレイヤーで、単一の静的Goバイナリ（約15MB）として構築されており、Python、Docker、CGOは不要です。純粋なGo SQLiteをmodernc.org/sqlite経由で使用し、ハイブリッド検索（BM25 + RRFによるベクトル）を提供し、必要に応じてOllamaで埋め込みを生成します。MCPネイティブで、Claude Code、Cursor、Windsurf、Codex CLIに対応しています。

ベリファイアとベンチマーク

著者は、同じエージェントをmnemosありとなしで同じプロンプトとモデルの下で2回実行し、具体的な効果を測定するベリファイアを構築しました。バイナリには3つの検証モードが含まれています：

• mnemos verify retrieval – 適切なメモリがトリガークエリに対して表面化するかをチェック
• mnemos verify behavior – Claudeをmnemosオン・オフで実行し、トランスクリプトがアサーションと一致する頻度をカウント
• mnemos verify capture – エージェントがタスク中に与えられた修正を記録するかをチェック

読み取り側の結果（Claude Codeでのn=5ペア実行）：

• session_start_on_edit: あり5/5、なし0/5（+100%）
• oss_first_for_protocol: あり5/5、なし0/5（+100%）
• no_ai_attribution_in_commit: 5/5 vs 5/5（効果なし）
• no_cgo_proposal: 5/5 vs 5/5（効果なし）
• migration_locked_refused: 5/5 vs 5/5（効果なし）

全体で+40%。モデルの事前知識が誤っているか存在しない場合（異例の慣習、再帰的なツールメモリなど）にメモリが効果を発揮します。広く知られたベストプラクティスでは効果はありませんが、劣化も見られません。

書き込み側のキャプチャ

初期ベースラインでは、エージェントはタスク中に与えられた修正のわずか7%しか記録しませんでした。「今後のセッションのために保存」は3回中3回スキップされました。2回の修正ラウンドの後、キャプチャ率は53%に達しました。

• ラウンド1（ツール記述の微調整）: 「Xを試した」「今後はYを使用」などのトリガーフレーズ例を追加。7%から13%に向上（ノイズレベル）。
• ラウンド2（構造的修正）: UserPromptSubmitフックを追加し、修正を示すフレーズをパターンマッチングし、プロンプトコンテキストにディレクティブブロックを挿入。エージェントが構造化ツールコールを実行するのは変わらないが、トリガーはスキップ不可に。13%から53%に向上。

残る失敗パターン：大規模なタスクプロンプトに埋もれたアーキテクチャ上の決定は、ディレクティブがあっても3回中0回。より強いタスクフレーミングがそれを上書きしているようです。

技術スペック

• 単一の静的Goバイナリ、約15MB
• 純粋なGo SQLite via modernc.org/sqlite
• ハイブリッド検索：BM25 + RRFによるベクトル、Ollamaを自動検出、なくても正常動作
• MCPネイティブ：Claude Code、Cursor、Windsurf、Codex CLIで動作
• バイテンポラルストア、書き込み境界でのプロンプトインジェクションスキャナー、決定的な修正からスキルへの昇格（統合ループにLLM不使用）
• ローカルファースト：明示的にOpenAIを埋め込みに指定しない限り、データはマシン外に出ません

ベリファイアハーネス

ベリファイアはリポジトリのverify/にあります。フィクスチャはYAMLで、シナリオの追加は簡単です。著者はn=5は少ないと述べており、次にtau-bench pass@kベンチマークに取り組んでいます。

リポジトリ：https://github.com/polyxmedia/mnemos