ZeroClawのハイブリッドメモリ解剖：SQLite + FTS5 + ベクトルが専用ベクトルDBに勝つ理由

ほとんどのAIエージェントフレームワークがメモリを実装するとき、まずベクトルDBに手を伸ばす。Pinecone、Weaviate、ChromaDB、Qdrant——選択肢は豊富でドキュメントも充実。エンベディングを保存し、類似度で検索し、次のプロンプトに関連コンテキストを取得。

ZeroClawはどれも使わない。メモリシステムは単一のSQLiteファイルで、FTS5全文検索とベクトル類似度検索を組み合わせている。外部DB不要。独立サービス不要。ネットワークラウンドトリップ不要。メモリシステム全体が3.4MBバイナリの中に収まる。

これは制限ではない——意図的なアーキテクチャ選択であり、パフォーマンスデータがそれを裏付ける。

ベクトルのみの検索がエージェントに不十分な理由

ベクトル検索はセマンティックに類似したコンテンツを見つける。「Kubernetesへのデプロイ方法は？」と聞けば、過去のK8sデプロイ、Dockerコンテナ、クラウドインフラの会話が返ってくる。便利だ。

しかしエージェントメモリのアクセスパターンはナレッジベースと異なる。エージェントが想起する必要があるのは：

•正確な用語。 「ステージングサーバーのAPIキーは？」ベクトル検索はAPIキー全般の会話を返すかもしれない。必要なのはステージングキーが言及された具体的な会話。
•直近のコンテキスト。 「今何の話をしてた？」会話の流れを保つには、セマンティック類似度よりも時間的近さが重要。
•構造化クエリ。 「先週のDB移行に関する全会話。」これはフィルタであり類似度検索ではない。

ベクトルのみのメモリは最初のカテゴリに対応でき、他は不得意。全文検索は正確な用語と構造化クエリに強いがセマンティック関連を見逃す。最適解は両方の組み合わせ。

ZeroClawはすべてのメモリエントリを三つの検索メカニズム付きSQLiteテーブルに保存：

1. FTS5全文検索（BM25スコアリング）。 SQLiteのFTS5拡張が高速全文検索をBM25関連度スコアリングで提供——従来の検索エンジンと同じアルゴリズム。「ステージングAPIキー」のようなクエリが瞬時に正確な言及を見つけ、単語頻度と文書長でスコアリング。

2. ベクトル類似度検索。 各メモリエントリは書き込み時に計算されたエンベディングベクトルを含む。類似度クエリはコサイン距離でセマンティックに関連するコンテンツを見つける。

3. メタデータフィルタリング。 タイムスタンプ、会話ID、チャネルソース、カスタムタグが検索実行前に結果を絞り込む構造化クエリを可能にする。

プロンプトのコンテキスト取得時、ZeroClawは両方の検索を並行実行し結果をマージ：

100,000メモリエントリのデータセットでのベンチマーク（ヘビーユーズの個人エージェント6ヶ月分相当）：

ZeroClawのSQLiteアプローチはすべての操作で速く、メモリはごく一部。利点は三つの要因：

1.**ネットワークオーバーヘッドゼロ。** SQLiteはインプロセス。シリアライズなし、TCPラウンドトリップなし、接続プーリングなし。
2.**サーバープロセスなし。** ChromaDBとWeaviateは独自のメモリアロケータ、GC、スレッドプールを持つ別プロセスとして動く。SQLiteはエージェントのプロセス空間を共有。
3.**アクセスパターンに最適化。** エージェントメモリは主に書き込み（毎ターン）と稀な読み取り（コンテキスト取得）。SQLiteはこのパターンに秀でる。

見過ごしやすい実用的利点：エージェントのメモリ全体が単一ファイル。

DBサーバーの管理不要。Raspberry PiのエッジデプロイではChromaDBの380MBは致命的。SQLiteの45MBは問題にならない。

シンプルなものはシンプルであるべきだ。エージェントメモリはシンプルなもの。SQLiteがそれを維持する。