Mnemo ローカル記憶レイヤー：Ollama と自作 LLM に引き継げる記憶を残す

Mnemo を検索する人の悩みは、もう 1 つローカル LLM ツールを知りたい、という話だけではないはずです。Ollama はすでに動いている。OpenAI-compatible API 経由でローカルモデルも呼べている。そこで困るのが次の段階です。セッションが終わると、モデルはプロジェクトの決定、ユーザーの好み、API 制約、昨日のデバッグメモを忘れます。毎回 prompt に貼り直すことはできますが、prompt は長くなり、古い情報と新しい情報が衝突し始めます。

Mnemo はその隙間に置く道具です。長期記憶を自分のマシンに置き、SQLite とグラフ関係でエンティティやテキストチャンク、検索結果を保存します。そのうえで、取り出したコンテキストを Ollama、OpenAI、Anthropic、または互換バックエンドへ渡します。モデルそのものに記憶を与えるわけではなく、万能の知識ベースでもありません。交換でき、バックアップでき、人間が確認できるローカル記憶サービスとして見るほうが扱いやすいです。

Mnemo が担当する記憶レイヤー

ローカル LLM ワークフローはだいたい 3 層に分けられます。モデルは生成を担当し、アプリケーションは処理の流れを担当し、記憶レイヤーはセッションをまたいだ情報を戻します。Ollama は第 1 層で、モデルをローカルで動かす部分を受け持ちます。RAG は主に「この質問に似た文書チャンクはどれか」を解きます。Mnemo は、さらに小さい会話横断メモリを狙っています。

分かりやすい例はローカルのコーディングアシスタントです。今日、「このプロジェクトでは当面 LangChain を使わず、API 層は FastAPI + SQLite のままにする」と伝えます。明日、新しいセッションで「検索機能をどう足すか」と聞いたとき、その決定を思い出してほしい。毎回、別の技術スタックを提案されると困ります。

そのため、Mnemo は Ollama API 呼び出し の後に置くと考えやすいです。まずモデルが安定して答える状態を作り、その後で、どの情報を記憶として残すか決める。順番が逆だと、まだ不安定な demo が状態管理の難しい仕組みに変わります。

構成を見る：Rust API、SQLite、グラフ探索

Mnemo README では、リポジトリが 4 つの Rust crate に分かれています。mnemo-core はエンティティ抽出、グラフ操作、検索エンジン、DB 層を担当します。mnemo-api は Axum REST API、mnemo-cli は CLI、mnemo-bench は benchmark 群です。ローカルツールとしては、この分割が大事です。過去会話を prompt で要約するだけの仕組みではない、と分かるからです。

SQLite は状態を持ち、グラフ関係は手がかりを増やす

よくある記憶システムは、会話をチャンクに分け、embedding を作り、類似度で検索します。それでも使えますが、すぐに 2 つの問題に当たります。同じ人、プロジェクト、決定が別セッションで何度も出てくること。もう 1 つは、2 つの事実が矛盾したとき、ベクトル類似度だけではどちらを信じるべきか決められないことです。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

Mnemo の公開説明では、entity deduplication と graph-first retrieval が強調されています。文章からエンティティを抽出し、既存のエンティティと統合し、関係エッジを検索時に使う、という考え方です。たとえば「API gateway」「auth middleware」「FastAPI service」が別々の会話に出てきても、あとでシステムについて聞いたときにグラフでつながります。

ただし、グラフ拡張は広げすぎないほうがいい。README では、グラフで広げた結果は低めのスコアで扱い、直接一致した内容が上に来ると説明されています。これは現実的な取捨です。グラフ関係は手がかりを増やす役割で、直接ヒットした証拠を押しのけるものではありません。

benchmark 数字はプロジェクト測定として見る

README の benchmark 表は具体的です。Apple M2、SQLite WAL、インメモリ petgraph、debug build で完全な検索パイプラインがおよそ 4.2 ms。release build ではさらに速い、と書かれています。これはローカル経路が測られていることを示しますが、あなたの環境で同じになる保証ではありません。データ量、抽出処理、ディスク、モデルバックエンド、検索方針で結果は変わります。

私はレイテンシより先に 3 つを見ます。書き込んだ記憶を再現できるか。検索結果が出典を説明できるか。誤った記憶を削除または修正できるか。遅さは後から直せることがあります。出典のない誤記憶は、後続の Agent を信じづらくします。

Docker + Ollama で最小経路を動かす

初日に Mnemo を主プロジェクトへつなぐ必要はありません。一時ディレクトリで upstream README の Docker + Ollama ルートを動かし、アプリ統合に進むか後で判断します。

git clone https://github.com/zaydmulani09/mnemo
cd mnemo
docker compose up -d

# README の例にあるモデルを初回 pull
docker exec mnemo-ollama ollama pull llama3

# API サービスを確認
curl http://localhost:8080/health

Ollama 入門をすでに試した人なら、この流れは見慣れているはずです。違いは、Mnemo が Ollama コンテナの横に記憶 API を立てること。あとでアプリは、過去の決定をすべてモデルコンテキストに詰め込む代わりに、この記憶サービスへ問い合わせます。

Python SDK で煙検査をする

README には Python SDK の最小例もあります。確認するのは 1 つだけ。記憶を書き込み、自然文の質問で戻ってくるか。

from mnemo import MnemoClient

client = MnemoClient()

client.ingest("Rust のベクトルデータベース vecdb を作っています")
print(client.get_context("いま取り組んでいるデータベースプロジェクトは何ですか？"))

このテストでは、最終回答だけを見ないほうがいいです。サービスログ、DB ファイル、API レスポンス構造、再起動後も記憶が残るかを見ます。長期記憶の最低ラインは、きれいな文章ではありません。継続し、検査でき、復旧できる状態です。

既存 Ollama 環境なら binary ルートもある

マシン上で Ollama がすでに動いているなら、README には binary ルートもあります。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

cargo install --path crates/mnemo-api
export MNEMO_LLM_BASE_URL=http://localhost:11434/v1
mnemo-api

こちらは既存のローカル LLM 環境に向きます。自分のモデル、ポート、監視を保ちつつ、Mnemo を別サービスとして足せます。あとでクラウド側へ切り替えるなら、OpenAI-compatible base URL、API key、model、provider を設定します。

導入前に相性を確認する

Mnemo README には、すでにマネージド agent harness が記憶を十分に扱っているなら Mnemo は不要かもしれない、という境界が書かれています。これは大事です。記憶レイヤーが増えるほど、見えにくい状態も増えます。

ローカルファーストの価値は分かりやすいです。データは手元に残り、SQLite ファイルはバックアップしやすく、すべてのプロジェクト会話をクラウドへ渡さずに済みます。ただし、ローカルであることは自動的な安全を意味しません。DB ファイルを誰が読めるか、バックアップはどこに置くか、ログに API key が混ざらないか、誤記憶をどう掃除するかは別問題です。

記憶レイヤーに必要な 3 つのガードレール

長期記憶は、管理できる範囲で初めて役に立ちます。Mnemo を実運用の Agent につなぐ前に、私は 3 つのルールをプロジェクトに書きます。

すべての記憶に出典を持たせる

記憶は 1 行の要約だけで終わらせないほうがいいです。どの会話、どのファイル、どのタスク、どの API 結果から来たのかを残します。Agent が「このプロジェクトは FastAPI を使う」と言うなら、その主張の出典まで追えるべきです。

以前の AI Agent 記憶管理でも同じ点を扱いました。長期記憶は大きなクリップボードではありません。出典、時刻、有効性がないと、古い結論が新しい事実の顔をして出てきます。

検索結果には予算を持たせる

ローカルサービスが速くても、無制限に注入しないこと。多くのタスクでは、出典付きの高関連メモリを 5〜15 件返せば十分です。もっと必要なら再検索させます。関係がありそうなメモを数十件まとめて prompt に詰めると、すぐ読みにくくなります。

このルールはコンテキスト腐敗を減らします。Agent が失敗するとき、資料不足より、古い決定、似た断片、矛盾したメモに引っ張られることがあります。記憶レイヤーはノイズを減らしてから、少量の証拠を prompt に渡すべきです。

誤った記憶は撤回できるようにする

危険なのは、欠けた記憶より誤った記憶です。たとえば以前「本番 DB の schema は直接変更できる」と記録し、その後チームが migration review 必須に変えたとします。古い記憶が残っていると、Agent はいつか危ない提案をします。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

そのため、試験導入では撤回操作を用意します。ある記憶を削除する。期限切れにする。特定プロジェクトを再抽出する。ユーザー空間を消す。こうした動きがない長期記憶は、少しずつ負債になります。

トラブルシュートの順番

Mnemo のような道具で起きる問題は、モデルの文章力より、ローカルサービス、モデルバックエンド、記憶検索の接続部分に出がちです。次の順に見ます。

• curl http://localhost:8080/health が通らない：Docker コンテナが起動しているか、ポートが占有されていないかを確認します。
• Ollama がモデルを pull できない：コンテナ内で ollama list を実行し、モデルが存在するか確認します。ネットワークが遅いときは小さなモデルで試します。
• API 呼び出しが止まる：MNEMO_LLM_BASE_URL が OpenAI-compatible endpoint を指しているか確認します。Ollama の通常ポートは 11434 です。
• 回答に記憶が反映されない：まず ingest 成功を確認し、最終回答ではなく検索 context を見ます。
• 再起動後に記憶が消える：SQLite データパスが永続 volume に載っているか確認します。
• 結果が散らかる：検索件数を減らし、重複エンティティを整理し、古いプロジェクト決定を期限切れにします。

prompt をいきなり直すより、この順番のほうが効きます。prompt はモデルの言い方を変えられますが、起動していないサービスや消える DB パスは直せません。

次に読むものと安全な試験導入

まだローカルモデルを動かしていないなら、まず Ollama 入門から始めるのが近道です。モデル呼び出しが安定したら、Ollama API 呼び出し と Ollama Embedding 実践を見る。Mnemo はその後、Agent 記憶レイヤーとして試す位置づけです。

7 日間の小さな検証なら、こう進めます。

1. 対象は 1 プロジェクトだけ。マシン全体を接続しない。
2. 技術スタック、採用しない案、よくあるエラー、API 制約を 30〜50 件書く。
3. 同じ 10 個の質問を毎日投げ、正しい検索、漏れ、誤検索を記録する。
4. 誤った記憶を削除または期限切れにし、次の回答が変わるか見る。
5. コンテナとマシンを再起動し、記憶が残るか確認する。
6. DB バックアップ、権限、機密情報スキャンを足す。
7. その後で、主力 Agent に接続するか決める。

Mnemo の価値は、LLM にすべてを永遠に覚えさせることではありません。少量の重要なコンテキストを次のタスクへ安定して戻し、人間が必要なときに確認、編集、バックアップ、撤回できるようにすることです。そこまでできると、ローカル LLM は一度きりのチャットではなく、続けて使える道具に近づきます。