メモリアーキテクチャ：3層ハイブリッドシステム
ベクトル検索だけでは不十分な理由と、SQLite+FTS5、LanceDB、memory.mdの組み合わせが本当に記憶するアシスタントを作る方法。
SQLite+FTS5
80% of lookups
LanceDB
Semantic recall
memory.md
Always in context
メモリの問題
多くのOpenClawユーザーは単一のメモリアプローチから始めます。ベクトルデータベースかフラットなmemory.mdファイルです。両方とも機能します — 機能しなくなるまでは。ベクトル検索はファジーなセマンティック想起に優れていますが、事実の検索には高価で不正確です。プレーンテキストファイルは常にコンテキスト内にありますが、スケールしません。解決策は？完全なスペクトルをカバーする3層ハイブリッドアーキテクチャです。
3層アーキテクチャ
外部依存なしの正確なファクト検索。個人アシスタントの実際のニーズの80%をカバー — 日付、名前、好み、決定。FTS5全文検索で高速かつ柔軟。
コンテキスト関連のファジーセマンティック想起。「先週のレストランの会話は何だった？」正確な言葉を覚えていなくても、ベクトル検索が見つけます。
LLMのコンテキストウィンドウに常に存在すべき重要な情報。名前、好み、重要な関係、アクティブなプロジェクト。小さく、厳選され、常に存在。
なぜベクトル検索だけではダメなのか？
ベクトル検索が「AIネイティブ」アプローチに感じたので直接LanceDBを選びました。しかし個人アシスタントにとって、ほとんどのメモリクエリは構造化検索です。SQLite+FTS5なら初日から外部依存ゼロでニーズの80%をカバーできたはずです。
ベクトル検索はファジーセマンティック想起に優れています。しかし「パートナーの誕生日は？」や「ハートビートにどのモデルを使う？」には過剰です。これらはシンプルなデータベースがより速く、安く処理できる構造化ファクトです。
ハイブリッドアプローチ — 正確なファクトの構造化ストレージ、コンテキスト想起のベクトル検索、重要情報の常時ロードコンテキスト、鮮度管理の時間認識減衰 — が完全なスペクトルをカバーします。
メモリアプローチ比較
| アプローチ | 強み | 弱み | 最適 |
|---|---|---|---|
| memory.mdのみ | 常にコンテキスト内、シンプル | スケールしない | < 50の重要ファクト |
| ベクトルDBのみ | セマンティック検索、スケール可能 | 高価、ファクト検索に不正確 | 大規模非構造化メモリ |
| SQLite+FTS5のみ | 高速、正確、ゼロ依存 | セマンティック理解なし | 構造化ファクト検索 |
| 3層ハイブリッド ✅ | 完全カバー | セットアップが複雑 | 本番個人アシスタント |
依存関係とセットアップ
better-sqlite3@11.0.0SQLiteドライバ + FTS5全文検索@lancedb/lancedb@0.23.0組み込みベクトルDB（セマンティック検索）openai@6.16.0埋め込み生成（text-embedding-3-small）@sinclair/typebox@0.34.47ランタイム型検証（プラグイン設定）ビルド要件
APIキー
OPENAI_API_KEYRequired埋め込み生成に必須（text-embedding-3-small）SUPERMEMORY_API_KEYOptionalオプション — 第2層クラウドアーカイブバックアップ日次ファクト抽出
システムには会話ログをスキャンし、構造化ファクトを抽出してSQLiteデータベースにバックフィルするCLIコマンドが含まれます。セーフティネットとして — リアルタイムキャプチャで漏れた会話が日次スイープでキャッチされます。
設計原則
最初から減衰を設計
早期にTTL分類を追加。なければ、古いファクトが蓄積し検索結果が乱雑になります。
決定を明示的に抽出
生の会話ログはノイズです。根拠付きの凝縮された決定を保存。500トークンの議論より有用です。
ハイブリッドが純粋に勝る
単一のメモリシステムですべてのクエリパターンはカバーできません。各レイヤーに明確な役割を。
ゼロ依存優先
SQLite+FTS5から始めましょう — 外部サービスなしでニーズの80%をカバー。