LongMemory を採用すべきか: SQLite ローカル永続化と時間軸つき記憶エンジンの実像

LongMemory が解こうとしている「記憶の時間軸」問題

README は、世の中で memory と呼ばれているものの多くが「テキストを分割し、埋め込み、近いベクトルを返す」パイプラインにすぎないと指摘する。この構成では、ある事実がいつ真だったのか、新しい事実が古い事実を上書きしたのか、どの情報源が権威なのか、誰が閲覧してよいのか、なぜその結果が文脈に入るのか、という問いに答えられない。LongMemory はこの 5 点をエンジンの責務として扱う。想定読者は、LLM アプリや自律エージェントを運用していて、モデル側はステートレスなまま、アプリケーション側の記憶を永続化したい開発者である。README の表現を借りれば「Your model stays stateless. Your application stops being amnesiac.」という位置づけになる。対象は個人の開発環境からチームの共有記憶まで幅があるが、いずれもローカルファーストと自己ホストが前提に置かれている。

4 つの recall モードが分ける推論の種類

このエンジンの中心は recall のモード分岐である。strict は時間、矛盾、契約、信頼度、グラウンディングの各ゲートを適用し、historical は valid_time を指定して上書き前の真実を保持したまま取り出す。associative は意味、語彙、エンティティ、活性化、グラフの各信号をたどる。world_grounded は現在の外部証拠を要求する。README の例では historical に valid_time: Date.UTC(2026, 0, 15) を渡して「1 月時点のデプロイリージョン」を問い合わせている。つまり記録時刻と有効時刻を別々に持つモデルであり、これは一般的なベクトル検索では表現しにくい。設計上の判断として興味深いのは、recall が relevance だけでなく contradictions、grounding、permissions、token cost の 4 つで境界を決める点だ。トークン予算を検索の制約条件に格上げしている。

Hydrograph 基盤と不変ノードという設計

内部モデルは README で hydrograph memory substrate と呼ばれ、不変ノード、実行可能なエッジ、world、entity、facet、trace で構成される。recall や decay によって内容、ベクトル、ハッシュ、来歴が書き換えられないと明記されている。ライフサイクルは決定的な減衰、明示的な強化、統合、圧縮、再統合という段階を踏む。エッジが「実行可能」と表現されているのは、型付き関係が検索と説明の両方に参加するという意味である。この構造は、記憶を破壊的に更新するのではなく、上書き関係と来歴を積み上げる方向に倒している。結果として、単純な upsert 型のベクトルストアより書き込みと保持の設計に制約が増える。トレードオフとして、古い事実を消したい用途（忘れさせたい、保持期間を短くしたい）では、不変性そのものが運用上の負担になりうる。

ライブラリとして動かす: createMemory と SQLite 永続化

最小構成は npm install longmemory の後、createMemory() を await で呼び、ingest に user_id と text を渡し、recall に text と mode を渡す流れである。README は「No service or external database is required for in-memory use.」と明記しており、インメモリなら外部依存なしで動く。永続化する場合は createMemory({ store: 'sqlite', db_path: './longmemory.db', tenant_id: 'acme', user_id: 'alice' }) のように指定する。同じデータベースを開き直すと、nodes、worlds、entities、edges、temporal history、grounding、lifecycle state が復元されると書かれている。CLI は npm install --global longmemory の後、longmemory init で初期化し、longmemory recall "current project priorities" --mode associative のように問い合わせる。ライブラリ利用と CLI 利用で同じエンジンを使う構成である。

サービスとして立てる: ポート 7331 と MCP の公開範囲

ソースから起動する場合は git clone、corepack enable、pnpm install --frozen-lockfile、pnpm build、pnpm start の順で、API は既定で http://127.0.0.1:7331 を listen する。Docker では ghcr.io/caviraoss/longmemory:latest を -p 7331:7331、-v longmemory-data:/data、-e LONGMEMORY_API_KEY=change-me で起動する例が示されている。Compose では cp .env.example .env の後に docker compose up --build -d longmemory、ダッシュボード込みなら --profile ui を付ける。ヘルスチェックは http://127.0.0.1:7331/health、ダッシュボードは 3000 番である。MCP は longmemory mcp --db .longmemory/project.db --project current で stdio を、LONGMEMORY_API_KEY=change-me longmemory serve --mcp-http で認証付き Streamable HTTP を公開する。README は「Tool arguments cannot override server-bound runtime identity.」と述べており、ツール引数でサーバー側に束縛された実行者 ID を書き換えられない設計だと説明している。

統合先の広さと、その広さが生む検証コスト

README が挙げる統合先は多い。エージェントホスト側は Claude Code、Codex、ChatGPT、OpenCode、Gemini CLI、Copilot Chat、Cline、n8n、VS Code 拡張、そして各種 Python フレームワークの MCP クライアントである。session porter は Claude Code、Codex、OpenCode、Gemini CLI、Copilot Chat、Cline、生のハーネスログを対象にすると書かれている。connectors はリポジトリ、ローカルファイル、Markdown、Web コンテンツ、フィード、クラウド文書、プロバイダ API を扱う。埋め込みは OpenAI 互換 API、Gemini、AWS Bedrock、Ollama、Siray、ローカル HTTP モデルに対応する。ただし、これらは README の記述であり、当サイトが各統合の動作を確認したわけではない。統合先が広いほど、自分のホストでどの組み合わせが実際に動くかを個別に確かめる必要がある。特に MCP の stdio と HTTP では認証の前提が異なるため、LONGMEMORY_API_KEY を設定しない構成を本番に置かないよう注意したい。

向かない場面と、代替となるアプローチ

LongMemory が過剰になる典型は、単一の文書集合に対する質問応答である。時間軸も権限もライフサイクルも不要なら、チャンク分割とベクトル検索だけを行う軽量な構成のほうが、設定項目も依存も少ない。代替として Chroma や LanceDB のような組み込み型ベクトルストアを選ぶ場合、違いは記憶のモデルにある。これらは基本的にベクトルとメタデータの集合を扱い、上書きや削除はストア側の操作として行う。LongMemory はノードを不変に保ち、時間軸と来歴、そして recall 時のゲートで「どの事実を文脈に入れるか」を決める。つまり検索エンジンではなく、記憶の統治層に近い。逆に、チームやテナントをまたぐ権限管理が要件にあるなら、メタデータフィルタで近似するより、tenant_id、user_id、project といったスコープをエンジンに持たせる設計のほうが素直である。ただし README には権限モデルの詳細な仕様までは示されていないため、ACL の粒度は実装を読んで確認する必要がある。

バージョン、ライセンス、そして導入前に確かめること

最新リリースは v1.3.0 で、リリース名は Beta v1.3.0、日付は 2025-12-20 である。直前には v1.2.3 と v1.2.2 が 2025 年 12 月に続いており、更新の間隔は短い。Beta 表記は、記憶のスキーマや recall の挙動が今後変わりうることを示唆する。ライセンスは Apache-2.0 で、特許許諾を含む寛容な条項と変更表示の義務を伴う。ここで法的助言はできないが、同梱の第三者依存のライセンス表示と、npm および GHCR で配布される成果物の NOTICE を確認しておく価値はある。README は LongMemEval、LoCoMo、BEAM などの「auditable benchmarks」に言及するが、当サイトは数値を検証していない。導入判断の前に、リポジトリのベンチマーク手順を自分の環境で再実行し、recall の 4 モードが自分のデータで期待どおりに分岐するかを確認するのが、最も費用対効果の高い次の一歩である。

編集部の結論

向いているのは、エージェントの記憶を外部 SaaS に預けず、SQLite ファイルと自前ホストの HTTP/MCP サーバーで完結させたいチームである。特に strict と historical を使い分けて「いつ時点の事実か」を扱いたい用途、複数エージェントホストから同一記憶にアクセスさせたい用途では、設計の焦点が通常のベクトル検索と明確に異なる。逆に、単発の文書検索やチャットボットの FAQ 応答だけが目的なら、記憶の時間軸やライフサイクルは使われないまま運用コストだけが残る。導入前に確認すべきは v1.3.0 が Beta 表記である点、README が「監査可能なベンチマーク」と書く評価の再現手順、そして Apache-2.0 の許諾範囲と同梱の第三者依存のライセンス表示である。まず npm install longmemory でインメモリの createMemory を動かし、recall の strict と historical が自分のデータで期待どおりに分岐するかを確かめてから、store: 'sqlite' に切り替える順序が安全である。

公式情報源

1. CaviraOSS/LongMemory on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases