MnemoでOllamaに長期記憶を追加する:導入と運用設計

"2026 年 7 月 17 日に確認した Mnemo GitHub README を、プロジェクトの位置づけ、Docker + Ollama quickstart、現行 API と環境変数、Rust crate 構成、テスト数、benchmark の前提確認に使用しました。"
Ollama のモデルはもう質問に答えられる。でも、会話は毎回ゼロから始まります。昨日話したプロジェクト決定、今日設定した好み、明日も使いたい制約は忘れられます。
これがローカル LLM の記憶不足です。Ollama が提供するのは「答えられる」モデルサービスです。何を答えるか、前に伝えた制約を覚えているかは、毎回どれだけ手動で説明し直すかに依存します。
Mnemo は別の RAG を作ろうとしているわけではありません。ナレッジグラフとエンティティ抽出で長期記憶を管理し、ローカル LLM がプロジェクト決定やエンティティ関係を覚えられるようにします。毎回「この API は何のためのものですか」と聞き返されないための層です。
1. Mnemo とは何か:位置づけと主要機能
1.1 位置づけの読み解き
「local-first AI memory layer」で重要なのは 2 つです。
- local-first:データは手元に保存されます。クラウドに上げず、移行でき、特定 SaaS の存続に依存しません
- memory layer:別の RAG でも agent フレームワークでもありません。担当するのは「記憶」そのもの、つまりエンティティ抽出、グラフ構築、セマンティック検索です
たとえば「このプロジェクトの API base URL は何ですか」と聞いたとします。純粋なベクトル検索なら「API」に関連する文書断片をいくつも返しますが、どのプロジェクトを指しているかは分かりません。グラフ検索なら「プロジェクト -> API -> baseUrl」という関係を追い、以前設定した値を直接返せます。
ただし、前提はエンティティ抽出が正しいことです。LLM が「API base URL」を「API」と「base URL」という 2 つのエンティティに誤って分けると、グラフは分裂し、検索の鎖が切れます。ノイズ蓄積はここから始まります。
位置づけが分かったところで、主要機能を見ます。
1.2 主要機能マトリクス
Mnemo の README には 4 つの主要機能が並んでいます。
-
persistent knowledge graph(永続化ナレッジグラフ)
- エンティティと関係を SQLite に保存します。一時的なベクトルではありません
- グラフ構造は問い合わせ、エクスポート、移行ができます
-
entity extraction(エンティティ抽出)
- 会話から人名、プロジェクト名、API 名、決定などのエンティティを自動で識別します
- 純粋なベクトル検索ではなく、「この API の用途は何か」という問いを、問い合わせ可能なエンティティ関係構造に変えます
- エンティティ抽出の品質は LLM の理解力に依存します。llama3 などのローカル LLM は複雑な会話で誤認識することがあり、ノイズ蓄積は継続的なリスクです。README には自動クリーンアップ機構は示されていないため、定期的にグラフ品質を確認する必要があります
-
semantic retrieval(セマンティック retrieval)
- 現行パイプラインは全文チャンク検索、エンティティ名検索、グラフ展開、関係フィルター、スコア順位付けを組み合わせます
- グラフ展開した結果は重みを下げ、直接一致を推論関係より上位に置くことで、コンテキストの無制限な拡張を抑えます
-
graph-first vs pure vector search
純粋なベクトル検索は「似ているものを探す」方式です。グラフ検索は「関係を探す」方式です。前者は意味的に似ていても無関係なノイズを返すことがあります。後者はエンティティ間の関係の鎖を追えます。
比較すると分かりやすいです。
| 観点 | 純粋なベクトル検索 | Mnemo ナレッジグラフ |
|---|---|---|
| 検索ロジック | 類似度ランキング | エンティティ関係の追跡 |
| ノイズリスク | 高い。似ているが無関係な結果が混ざる | 低め。エンティティのアンカーがある |
| 説明可能性 | 低い。ベクトルはブラックボックス | 高い。グラフが見える |
| 移行性 | ベクトルはきれいに書き出しにくい | SQLite をエクスポートできる |
| 向く場面 | 文書検索 | プロジェクト記憶、エンティティ関係 |
1.3 技術スタックとライセンス
技術スタック:
- Rust。4 つの crate に分かれます。次の節で扱います
- SQLite。ローカル保存、WAL mode
- petgraph。インメモリグラフ
- OpenAI / Ollama / Anthropic API。LLM バックエンド
ライセンス:MIT License。利用、変更、再配布ができます。
リスクの注意点:
- 早期段階のプロジェクトです。2026-06-05 時点の GitHub README に基づきます
- API や構成は変わる可能性があります
- 大規模な本番検証は確認できません
- README の性能値は自己測定であり、独立した証明ではありません
2. 構成要素:4 つの Rust crate
Mnemo は Rust で書かれ、4 つの crate に分かれています。責務は明確です。
mnemo-core:中核ロジック
- エンティティ抽出、グラフ構築、検索ロジック
- 特定の LLM バックエンドには依存せず、インターフェースを定義します
mnemo-api:サーバー
- HTTP API を提供します。デフォルトポートは 8080
- 会話を受け取り、core を呼び、結果を返します
- health check:
curl http://localhost:8080/health
mnemo-cli:コマンドラインツール
- デバッグ、管理、問い合わせ
- HTTP 経由で Mnemo API を呼び、記憶の書き込み、検索、エンティティ確認、全消去を操作します
mnemo-bench:性能テスト
- README にある 122 個の Rust tests、21 個の Python tests、12 個の benchmarks はここにあります
- 自己測定値の出どころです
4 crate に分ける利点:
- core は API に依存せず単独でテストできます
- cli はサービスを起動せずにローカルデバッグできます
- bench は独立していて、本番コードに影響しません
弱いところ:
- Docker を使わない場合、完全な Rust toolchain が必要です
- crate 間の API が変わると、複数箇所を一緒に直す必要があります
3. インストールとデプロイ:3 つの経路
Mnemo には複雑度順に 3 つのデプロイ経路があります。
3.1 Docker + Ollama(最速で試す)
前提:Docker と Ollama がインストール済み。
# 1. プロジェクトを clone
git clone https://github.com/zaydmulani09/mnemo.git
cd mnemo
# 2. Docker を起動
docker compose up -d
# 3. Docker 内でモデルを pull
docker exec mnemo-ollama ollama pull llama3
# 4. health check
curl http://localhost:8080/health
注意:コマンドは変わる可能性があります。GitHub README を正としてください。
説明:Docker compose は 2 つのコンテナを起動します。mnemo-api(サーバー)と mnemo-ollama(Ollama)です。後者は任意です。ローカルですでに Ollama が動いているなら、mnemo-api コンテナだけを使い、MNEMO_LLM_BASE_URL=http://host.docker.internal:11434/v1 でローカル Ollama に接続できます。
LLM 接続の確認:health check が {"status":"ok"} を返しても、API が起動しただけで LLM 接続はまだ確認できていません。curl でテストリクエストを送ります。
curl -X POST http://localhost:8080/ingest \
-H "Content-Type: application/json" \
-d '{"content":"Project Atlas の API base URL は https://api.example.test","source":"chat","session_id":"mnemo-trial"}'
書き込みに成功したら、/retrieve で検索まで確認します。
curl -X POST http://localhost:8080/retrieve \
-H "Content-Type: application/json" \
-d '{"text":"Atlas の API base URL は何ですか","session_id":"mnemo-trial"}'
関連エンティティ、記憶チャンク、または context_prompt が返れば、抽出と検索の両方が動いています。
利点:
- Rust toolchain が不要
- Docker が依存関係を処理します
- Ollama と Mnemo が同じ compose network にいるため、ネットワーク設定が簡単です
欠点:
- Docker がリソースを使います
- SQLite を確認するにはコンテナに入る必要があり、デバッグが面倒です
- ログが 2 つのコンテナに分かれます
3.2 Binary(ローカルビルド)
前提:Rust toolchain(cargo、rustc)と Ollama がインストール済み。
# 1. プロジェクトを clone
git clone https://github.com/zaydmulani09/mnemo.git
cd mnemo
# 2. API crate をビルド
cargo install --path crates/mnemo-api
# 3. Ollama の URL を設定
export MNEMO_LLM_BASE_URL=http://localhost:11434/v1
# 4. サービスを起動
mnemo-api
注意:コマンドは変わる可能性があります。GitHub README を正としてください。この経路には Rust toolchain が必要です。
説明:ビルド時間はハードウェアと Cargo cache に依存します。ビルド後、mnemo-api はデフォルトで現在のディレクトリにある mnemo.db を使います。DB path は MNEMO_DB_PATH または TOML 設定で変更できます。
Ollama 接続の確認:起動前に Ollama が localhost:11434 で動き、モデルを ollama pull llama3 済みであることを確認します。起動後、curl でテストします。
curl -X POST http://localhost:8080/ingest \
-H "Content-Type: application/json" \
-d '{"content":"Mnemo のエンティティ抽出をテスト","source":"cli-check"}'
利点:
- Docker に依存しません
- ローカルプロセスなのでログが 1 つの端末にまとまり、デバッグしやすいです
- mnemo-cli でローカル SQLite を直接操作できます
- 環境変数でポートや DB パスを変更できます
欠点:
- 完全な Rust toolchain が必要です
- 初回ビルドに時間がかかります
cargo.lockが古いなど、依存関係で詰まることがあります
3.3 OpenAI-compatible(クラウド LLM)
前提:OpenAI / Anthropic / その他 OpenAI-compatible API の key がある。
環境変数一覧(2026-06 の GitHub README で確認):
export MNEMO_LLM_BASE_URL=https://api.openai.com/v1
export MNEMO_LLM_API_KEY=sk-...
export MNEMO_LLM_MODEL=gpt-4o-mini
export MNEMO_LLM_PROVIDER=openai
その後に起動します。
mnemo-api
注意:環境変数名は変わる可能性があります。GitHub README を正としてください。
向く場面:
- ローカル計算資源が足りず、クラウド LLM を使う
- OpenAI API の利用枠がある
- データがクラウドへ送信されることを許容できる。クラウド LLM を使う場合、会話内容はクラウド API に送られます。local-first のプライバシー利点はローカル保存にだけ効きます
3 つの経路から、自分の状況に合うものを選びます。次は性能値です。
4. 性能:README の自己測定値
Mnemo README には性能の自己測定値が載っています。以下は 2026 年 7 月 17 日に再確認した内容です。
テスト条件:
- Apple M2(debug build)
- SQLite WAL mode
- petgraph はインメモリ
性能値:
- 完全な検索パイプライン:約 4.2 ms
- Release build では 3〜5 倍速いとされています(約 0.8〜1.4 ms)
注意:README の自己測定であり、独立した証明ではありません。性能はハードウェア、データ量、LLM バックエンドで変わります。
この数字の読み方:
- 4.2 ms は「検索」時間で、LLM 推論は含みません。ボトルネックは LLM 推論です
- SQLite WAL とインメモリグラフの組み合わせなら、検索自体は速くできます
- ただし、これは検索処理だけで、「会話速度」ではありません
実際の体験は次に依存します。
- LLM 推論時間。検索よりずっと遅いです
- 会話内容の長さ。エンティティ抽出にも LLM 推論が必要です
- データ量。グラフが大きいほど検索は遅くなります
提案:対象ハードウェアで mnemo-bench を実行し、README の数字は参考値として扱います。約束値ではありません。
5. Local-first の特徴と境界
5.1 Local-first の利点
Local-first の核は、データが手元にあることです。
具体的な利点:
-
プライバシー保護
- 会話内容、エンティティ、関係はローカル SQLite に保存されます
- ローカル LLM を使う限り、第三者 SaaS へアップロードしません
-
データ制御
- SQLite ファイルはエクスポート、バックアップ、移行できます
- 特定 SaaS の存続に依存しません。サービスが止まってもデータは残ります
-
移行性
- マシンを変えるときは SQLite ファイルをコピーします
- 記憶を最初から「学習」し直す必要はありません
-
デバッグしやすさ
- SQLite は標準形式で、任意の SQLite ツールで確認できます
- グラフ構造が見えます。ブラックボックスのベクトルではありません
5.2 潜在リスクと境界
Local-first には利点がありますが、リスクもあります。
-
ノイズ蓄積
- エンティティ抽出は完全ではなく、誤認識します
- 誤認識したエンティティは後続検索に影響します
- 定期的な清掃が必要ですが、Mnemo には自動クリーンアップ機構がありません
- ノイズ蓄積は Mnemo 固有の問題ではなく、すべての自動記憶システムに共通します。違いは、Mnemo のグラフが見えることです。ノイズエンティティや誤関係を見られます。ベクトルシステムのノイズはベクトル内に隠れます。これはグラフの利点であり、同時に保守負担でもあります
-
削除と復旧の境界
- 現行 API はエンティティ単位、記憶チャンク単位の削除と、確認ヘッダー付きの全消去に対応します
- 直前の書き込みや 1 つの業務判断だけを取り消す高レベルのトランザクションはありません
- 誤った判断が複数のエンティティや関係へ広がった場合、source や session 情報で対象を特定してから削除するか、バックアップから戻す必要があります
- 重要な判断には
source、session_id、外部監査 ID を付け、本番事実を保存する前に抽出結果を確認します
-
hidden state
- グラフ構造は複雑で、気づかない関係が保存されることがあります
- なぜその結果が返ったのか分からない検索結果が出ることがあります
-
適用境界
- データ量が大きいと、SQLite + インメモリグラフに負荷がかかります
- 複数 Agent で共有する場合、Mnemo が提供しない認可、テナント分離、運用設計を補う必要があります
5.3 向く場面 vs 向かない場面の判断表
| 場面 | 適性 | 理由 |
|---|---|---|
| 個人プロジェクト、小規模チーム | 適する | データ量が小さく、プライバシー要件が高く、移行しやすい |
| 大量データ(GB 級) | 向かない | SQLite + インメモリグラフに負荷がかかり、ノイズも蓄積する |
| チーム共同作業(複数人書き込み) | 条件付き | 1 つの API サービスを共有できるが、認可、分離、並行動作の検証が必要 |
| 強いプライバシー要件 | 適する | ローカル LLM を使う限りデータはクラウドへ出ない |
| グローバル共有記憶が必要 | 向かない | local-first はローカル専有で、共有前提ではない |
| 既存の Ollama 環境がある | 適する | 直接統合でき、学習コストが低い |
| Rust toolchain がない | 条件付き | Docker 経路を使えるが、デバッグは面倒 |
判断:場面が「個人プロジェクト、プライバシー要件が高い、Ollama がある、データ量が大きくない」なら Mnemo は試せます。「大量データ、チーム共同作業、グローバル共有」が必要なら、Mnemo の成熟を待つか別案を考えます。
具体的な提案:
- まずテスト環境で Docker 経路を一度動かし、グラフ構造、エンティティ抽出品質、検索結果を確認します
- テスト会話でノイズリスクを確認します。意図的に無関係な話をして、Mnemo が誤認識するか見ます
- クリーンアップ案を用意します。SQLite ツールでグラフ構造に慣れ、誤エンティティを手動削除する方法を知っておきます
- README 更新を追います。早期プロジェクトなので API、構成、デプロイコマンドは変わる可能性があります
6. 次のステップ:シリーズ案内
Ollama ローカル LLM シリーズの前の記事をまだ読んでいないなら、順番に読むのがおすすめです。
-
Ollama 入門:ローカルで大規模言語モデルを動かす最初の一歩
- Ollama をまだ入れていないならここから始めます
-
Ollama API 呼び出し:curl から OpenAI SDK 互換インターフェースまで
- Mnemo は OpenAI-compatible API を使うため、Ollama の API インターフェースを理解しておきます
-
Ollama Embedding 実践:ローカルベクトル検索と RAG 構築
- 純粋なベクトル検索と、Mnemo の全文検索、エンティティ検索、グラフ展開を比較する材料になります
-
AI Agent 記憶管理:長期記憶とナレッジガバナンス実践
- Mnemo は記憶レイヤーの道具です。この回では Agent 記憶の管理方針を扱います
この 4 本を読んでから Mnemo を入れると理解しやすくなります。次の一歩は、ローカルで Mnemo の Docker 経路を動かし、ナレッジグラフがどんな形になるか見ることです。
Docker と Ollama で Mnemo の最小検証を動かす
主力 Agent に接続する前に、一時環境で Mnemo のサービス起動、モデル接続、記憶書き込み、検索、永続化、クリーンアップを確認します。
⏱️ 目安時間: 1-2 hours
- 1
ステップ 1: リポジトリを clone して compose を起動する
GitHub README に従って mnemo リポジトリを clone し、`docker compose up -d` を実行します。mnemo-api と mnemo-ollama コンテナが起動したことを確認します。 - 2
ステップ 2: テスト用モデルを pull する
コンテナ内で `docker exec mnemo-ollama ollama pull llama3` を実行します。または現在の README が推奨するモデルを選びます。 - 3
ステップ 3: API の health を確認する
`http://localhost:8080/health` を叩きます。LLM 接続を疑う前に、サービス自体に到達できることを確認します。 - 4
ステップ 4: テスト記憶を 1 件書き込む
README の Python SDK または API 例で、プロジェクト記憶を 1 件書き込みます。初日から実プロジェクトには接続しません。 - 5
ステップ 5: 検索と再起動後の永続化を確認する
自然文で書き込んだ記憶を問い合わせ、コンテナ再起動後にもう一度問い合わせます。SQLite データが消えていないことを確認します。 - 6
ステップ 6: 削除と期限切れを練習する
わざと誤った記憶を書き込み、削除、期限切れ、またはグラフ再構築を試します。後続回答が古い事実を使わないことを確認します。
FAQ
記憶は増え続けて、最後はノイズだらけになりませんか?
Mnemo はベクトル検索より何がよいのですか?
Mnemo が誤った記憶を保存したら戻せますか?
Mnemo はどの LLM バックエンドに対応しますか?
複数の agent で 1 つの記憶 DB を共有できますか?
Mnemo のデータ移行はどうしますか?
7分で読めます · 公開日: 2026年7月18日 · 更新日: 2026年7月19日
Ollama シリーズ: ローカル LLM の導入、設定、アプリケーション実戦
検索からこのページに来た場合は、前後の記事もあわせて読むと同じテーマの理解がかなり早く深まります。



コメント
GitHubアカウントでログインしてコメントできます