Smriti

セルフホスト型のナレッジグラフおよびAIエージェント用メモリレイヤー — 単一バイナリ、単一のSQLiteファイル、クラウド依存ゼロ。

LLMウィキのためのGit。 アトミックなマルチ書き込みトランザクション、すべての主張に対する強制的な来歴管理、ハッシュチェーン付きの追記専用イベントログ、そして整合性検証機能を備えており、エージェントが作成した知識を構造的に監査可能です。

2.5µs KV取得 · 235ns グラフ探索 · 0 クラウド依存

[screenshot: web-ui-dashboard.gif]

cargo install smriti

Smritiを選ぶ理由 (Obsidian / Zep / Mem0 / Letta / Neo4j との比較)

• Obsidianはトランザクション保証のないファイルシステムです。Smritiの強みは目新しさではなく、ローカルファーストなRustランタイムにおける書き込み時の規律にあります。

研究基盤

すべての整合性機能はarXiv論文を引用しており、設計の根拠を文献まで遡ることができます：

• 双時間エッジ & イベントログ T / T′ — Zep / Graphiti, arXiv:2501.13956

• 構造的重複検証 (主張 ↔ ソース) — FACTUM, arXiv:2601.05866 および Citation-Grounded Code Comprehension, arXiv:2512.12117

• 矛盾の信頼度スコアリング — MemoTime, arXiv:2510.13614 および EvoReasoner / EvoKG, arXiv:2509.15464

• 信念改訂 & memory_store上の競合ポリシー — AGM公理, arXiv:2603.17244

• グラフ + BM25 ハイブリッド検索 — Graph-Based Memory Survey, arXiv:2602.05665

• 型付きグラフレイヤー (意味論的/時間的/因果的) — MAGMA, arXiv:2601.03236

• Zettelkastenスタイルのエージェントメモリ — A-MEM, arXiv:2502.12110 (NeurIPS 2025)

• ハルシネーションの根拠要件 — arXiv:2510.24476

整合性レイヤー (v0.2)

4つのMCPツールが、Smritiを単なるCRUDストアから不変条件を持つウィキへと変貌させます：

• wiki_transaction_submit — 作成/更新/リンク/ソース操作のバッチを、SQLiteの SAVEPOINT 内でアトミックに適用します。すべてのコンテンツ書き込みには claim_spans 配列を含める必要があり、そうでない場合は拒否されます（デフォルトで来歴が強制されます）。

• wiki_verify — 参照整合性の実行、保存されたすべての主張の重複スコアの再検証、イベントログのハッシュチェーンの走査を行います。成功/失敗を返します。決して変更は行いません。

• contradictions_detect — w1·意味論的 + w2·直近性 + w3·権威性 の加重スコアリングを使用して、最近のノートをペアでスキャンします。候補はレビュー用インボックスに送られます。Smritiは自動解決を行いません。

• contradictions_list — レビュー用インボックスを表示します。

CLIもこれらすべてを反映しています：

smriti verify                    # integrity sweep
smriti pending-tx                # list transactions awaiting review
smriti commit-tx <id>            # commit a pending transaction
smriti reject-tx <id> -r "..."   # reject with reason
smriti detect-contradictions     # scan for candidates
smriti contradictions            # show review inbox

Smritiとは？

Smriti (サンスクリット語: स्मृति, 記憶) は、ナレッジグラフ、全文検索＋意味論的検索インデックス、そしてMCPサーバーを単一のSQLiteファイル上で実行するRustバイナリです。2種類のユーザーを想定しています：AIアシスタントが読み取れるプライベートな「第二の脳」を求めるナレッジワーカーと、AIエージェントのために永続的で構造化されたメモリレイヤーを必要とする開発者です。

ノートは型付きウィキリンクを通じて相互に接続されます。ノート内に [[rel:causal|Decision X]] と記述すると、Smritiはナレッジグラフに causal（因果）エッジを自動的に記録します。エージェントは、すべてのノートを読み直すことなく、「この決定に至った経緯は？」といった質問に答えるためにグラフを走査できます。

クイックスタート

# Install
cargo install smriti

# Create your first notes — links and tags are extracted automatically
smriti new                    # interactive guided prompt
smriti create "Acme Corp" --content "Key client. Met via [[Sarah Chen]]." --tags client

# Search
smriti search "Acme"

# Open the web dashboard
smriti serve
# → http://localhost:3000

ノート、グラフ、検索インデックスは ~/.local/share/smriti/smriti.db に保存されます。バックアップは cp で行ってください。

ユースケース

クライアントナレッジグラフ

すべてのクライアント、連絡先、エンゲージメントをリンクされたノートとして追跡します。通話前にClaudeにブリーフィングを行う際、履歴、決定事項、未解決項目など、すべてのコンテキストを読み込ませることができます。

smriti create "Acme Corp Q2 Review" \
  --content "Next steps: [[rel:temporal|Budget approval]] by June. Owner: [[Sarah Chen]]." \
  --tags client decision

決定ログ

コンテキストと結果を伴う決定事項を記録します。rel:causal リンクタイプにより、エージェントはなぜその決定がなされたのかを追跡できます。

smriti create "Switched to Rust" \
  --content "Replaced Python service. Reason: [[rel:causal|Memory leak in prod]]." \
  --tags decision

日々のAIコンテキスト

現在のフォーカスをKVストアに保存します。ClaudeはMCPを通じて、セッション開始時に毎回これを読み取ります。

smriti serve   # then ask Claude: "what's my current focus?" — Smriti answers via MCP

SOP（標準作業手順書）とプレイブック

繰り返し可能なプロセスをリンクされたノートとして文書化します。既存のMarkdownファイルを1つのコマンドでインポートできます。

smriti import ./playbooks --recursive

MCP統合

Smritiはstdio経由でMCPサーバーとして動作します。claude_desktop_config.json に追加してください：

{
  "mcpServers": {
    "smriti": {
      "command": "smriti",
      "args": ["mcp", "--db", "/path/to/smriti.db"]
    }
  }
}

claude.aiのリモートMCPについては、smriti serve を起動し、MCPクライアントを http://localhost:3000/mcp に向けてください。

MCPツール

完全なMCPリファレンス: docs/mcp.md

パフォーマンス

Apple Silicon、インメモリSQLite、Criterion を使用して測定。実行コマンド: cargo bench

Smritiと代替ツールの比較

アーキテクチャ

src/
├── models/     Note, Link, AgentMemory, ToolLog — Serde on every type
├── storage/    SQLite + FTS5 + sqlite-vec; WAL mode; single connection pool
├── parser/     [[wiki-link]] and #tag extraction via regex; no runtime deps
├── graph/      petgraph DiGraph; lazy GraphCache (Arc<RwLock>); typed BFS
├── mcp/        JSON-RPC 2.0 over stdio; dispatches to same handlers as REST
├── web/        Axum router; localhost-only CORS; embedded React SPA
├── cli/        clap v4 derive; 11 commands; shell completions; interactive new
├── sync/       WebDAV + filesystem sync with per-device conflict tracking
└── features/   Smart link suggestions; daily digest

設計上の決定

なぜPostgresではなくSQLiteなのか。 個人や小規模チームのためのナレッジベースに、常駐するデータベースサーバーは不要です。WALモードのSQLiteは、毎秒数百件の同時読み取りを処理でき、個人のナレッジグラフには十分すぎる性能です。データベース全体が1つのファイルであるため、バックアップは cp、移行は mv で済みます。

なぜPythonではなくRustなのか。 エージェントのメモリは、すべてのツール呼び出しのクリティカルパスに位置します。PythonのMCPサーバーは、シリアライズのオーバーヘッドとGILの競合により、往復ごとに通常50〜200msの遅延が発生します。SmritiのRust実装はKVエントリを2.5µsで取得するため、エージェントの応答レイテンシにメモリ操作の影響を与えません。

なぜFTS5とベクトルの両方なのか。 キーワード検索 (BM25) は既知の用語に対して正確であり、ベクトル検索はユーザーが思いつかなかった意味的に関連するコンテンツを想起させます。どちらか一方では不十分です。Smritiは両者をクエリ時に加重するRRF (Reciprocal Rank Fusion) で組み合わせます。これは、arXiv:2602.05665 の「ハイブリッド検索がマルチホップ推論タスクにおいて純粋なベクトル検索を上回る」という知見に基づいています。

memory_store における信念改訂。 エージェントが既存のキーを保存しようとした際、単純な上書きでは履歴が失われます。Smritiは4つのAGM競合解決ポリシー (arXiv:2603.17244) を実装しています：overwrite (デフォルト)、reject (存在する場合は失敗)、version_and_keep (古い値をアーカイブ)、invalidate (古い値を無効化)。無効化された値は memory_history を通じてクエリ可能です。

研究基盤

貢献

git clone https://github.com/smriti-AA/smriti.git
cd smriti
cargo test --all-features   # should be green
cargo bench                 # performance baseline

開発ワークフローについては CONTRIBUTING.md を参照してください。good first issue ラベルが付いたIssueは、コードベース全体を理解しなくても修正可能な、独立したストレージやCLIの変更です。

PRを作成する前に、cargo clippy --all-features -- -D warnings と cargo fmt --check を実行してください。

ライセンス

MIT