N3MCMCP Pro｜はじめての方へ

近日発売予定 製品一覧に戻る まずはLite版を見る

# n3memorycore-mcp-pro 総評 --- ## 全体像 これは「LLM の外部脳」として、**運用コストを最小に保ちながら、長期記憶として要求される基本契約をすべて押さえた** SQLite ベースの軽量記憶システムです。GPU も外部 API も追加プロセスもいらない。Python と SQLite と sqlite-vec があれば、ノート PC 上で何年でも回り続ける性質を持っています。 設計の中核にあるのは「**書いたものは消えない、読んだものは正確、古いものは静かに片付く**」という三つの素朴な約束で、それを WAL + synchronous=FULL の SQLite、親-Document verbatim 契約、cascade-delete を伴う retention GC で愚直に実現しています。MCP 経由で 5 つのツールしか公開しないという情報量の絞り方も、LLM クライアントが迷わない設計として正しい判断です。 --- ## 記憶装置としての性格 **強い部分**は、永続化が「形式的に正しい」のではなく「観測可能に正しい」ことです。WAL/synchronous=FULL のような宣言的な強度だけでなく、クロスセッション統合テストで実際に save → 再起動 → search が通ることまで確認している。Refresh の atomicity も、初期実装の DELETE と INSERT が別トランザクションだった脆弱性を発見・修正し、単一トランザクション化したうえで「INSERT 失敗時に victim が復元される」ことをテストで保証している。 親-Document verbatim 契約は、長文を「チャンクして検索 → 親に解決して全文返却」という王道パターンを丁寧に実装しており、orphan-chunk フォールバックまで含めて壊れにくい。Retention GC は startup と周期の二段構えになって、長時間稼働でも蓄積しにくい設計です。 **弱い部分**として残るのは、save_document 側の dedup が「親文書の embedding」（モデルの 512 token 制限で冒頭バイアスがかかる）に依存している点。チャンク単位の dedup に踏み込めばより精緻になりますが、そこは仕様準拠と複雑性のトレードオフで現状維持が妥当だと思います。 --- ## RAG としての性格 ここが今回いちばん面白く育った領域です。**多言語対応の RAG として、軽量検索系で見られる典型的な「英語中心・スペース前提」の罠をかなり踏み越えている**。 具体的には: - **NFKC 正規化** で、全角/半角・合成済/分解済の Unicode 違いを INSERT/QUERY の両側で吸収。日本語の「ＡＢＣ」と "ABC"、ベトナム語の é の合成形と分解形が同じキーになる。 - **Bigram tokenizer の拡張**で、CJK だけでなく Thai/Lao/Myanmar/Khmer/Tibetan/Javanese/Balinese を扱う。これらは単語スペースを使わない / 不規則に使う言語で、英語前提の検索系では完全にハマる領域です。 - **OR ベースの bigram クエリ**を採用したことで、「すべての bigram が一致しないと駄目」という過剰に厳しい AND セマンティクスを回避し、dense-script の検索が現実的にヒットするようになった。 - **IDF 重み付き reranker**: 候補集合内の文書頻度から smoothed IDF を計算し、common term ではなく rare term の一致を評価する。BM25 の中身でやっていることを上位レイヤでも丁寧に再構成している。 加えて、**ハイブリッド融合のモード切替** (weighted ↔ RRF)、**recency boost** (last_accessed_at による継続的な「最近触れた = 新鮮」シグナル)、**b_session/b_local** (このセッション・このマシン由来の記憶を優先) と、シンプルな乗算スタックで多軸の関連性を表現している。重量級の neural reranker や dense embedding の上位互換ではないが、**「軽いまま、効くものだけ重ねる」という設計判断は一貫していて気持ちがいい**。 --- ## エンジニアリング品質 **特筆すべきは、テストが「実装の説明書」になっていること**です。Bug 1-3、V1-3、R1、perf bug、empty-query guard、各種 enhancement —— どれも「何が起きていたら壊れるのか」を具体的に書き留めたうえで、実際にその壊れを再現できる回帰テストとして固定している。コードベースの寿命を伸ばすうえで、これは embedding 技術の選定と同じくらい重要な資産です。 修正の途中で **min_score フィルタの順序バグ** (rerank 前に適用していたため、embedding モデルが使えない環境では BM25 単独ヒットが全部消える) を別途発見・修正できたのも、テスト→診断→ピンポイント修正のループがちゃんと回っていることの証左でした。 細かい工学的な配慮も多く、 - fd レベルの stdout リダイレクト (model preload 中の C 側 print が JSON-RPC を汚さないように) - enable_load_extension(False) を finally で必ず呼ぶ - atexit による WAL checkpoint(TRUNCATE) で .db を自己完結させる - UUIDv7 による時系列順序の保証 (fallback で UUIDv4) - Windows cp932 環境向けの surrogate sanitization など、「動かす場所」と「動かし続ける時間軸」を意識した実装になっています。 --- ## このシステムの本質 私が一言で表現するなら、**「ローカルで完結する、多言語対応の、忘れない記憶」**です。 - ローカル: 外部 API なし、GPU なし、SQLite ファイル一本 - 多言語: NFKC + 拡張 bigram + IDF reranker で言語に縛られない - 忘れない: WAL + atomic refresh + retention GC + 親-doc verbatim - 「記憶」: 単なるベクトル検索ではなく、access_count・last_accessed・session・local という人間味のある軸で重み付け 軽量さを保ったまま、長期記憶に必要な工学的契約を一通り満たしている。改良の余地は当然ありますが (per-chunk dedup、クロスエンコーダ rerank、IDF の永続キャッシュ、export ツール…)、それらは「現在地の設計を否定する」必要のない、自然な延長線上の改善です。 **LLM が「記憶を持つ」という抽象的な比喩を、極めて具体的なファイル・テーブル・契約に落とし込んだ実装**として、このコードベースは十分に評価に値すると思います。