ori-memory について
Ori Mnemos は AI エージェント向けのオープンソースの永続メモリ基盤です。データは Markdown で保存し、ナレッジグラフでメモリを整理します。セッションやクライアントをまたいで記憶を保持しつつ、データを自分で管理したい開発者に向いています。
主な機能
- 01wiki-link をグラフのエッジとする Markdown ストレージ
- 02ACT-R の減衰と拡散活性化による検索
- 03CLI、MCP サーバー、ライブラリの三つの利用経路
- 04メモリファイルの Git によるバージョン管理
- 05API キーもネットワークも不要な動作
活用シーン
- 01コーディングエージェントのセッションをまたぐ決定事項の保持
- 02複数マシンにまたがる個人用ナレッジベースの検索
- 03保存済みの事実の置き換え、解放、完全削除
MCP 対応
ori serve を実行すると MCP サーバーが起動し、ori_recall などのツールを公開します。MCP クライアントからメモリを検索できます。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。
詳細
Ori Mnemos
AI エージェント向けのオープンソース永続メモリー基盤です。
Ori は、ナレッジグラフ上の数学モデルとして人間の認知を実装しています。ACT-R による活性化の減衰。ウィキリンクのエッジに沿った活性化の拡散。検索パターンに基づくヘブ則的な共起。検索自体に対する強化学習。サブクエリの分解を伴う再帰的なグラフ探索。このシステムは、何が重要かを学習し、重要でないものを忘れ、独自の検索パイプラインを最適化します。
セッション、クライアント、マシンをまたいだ永続メモリーを実現します。ベンチマークでは既存の製品と同等の性能を示し、いくつかの項目では大きく上回るインフラ不要の検索を提供し、データのすべてを自分で管理できます。ディスク上の Markdown。グラフエッジとしてのウィキリンク。バージョン管理には Git を使用します。データベースへのロックインも、クラウドへの依存も、ベンダーによる囲い込みもありません。
v0.7.0 · npm · 論文 · Apache-2.0
使用方法
Ori は、1 つのインデックスを通じて 3 つのインターフェースを提供します。正となるのは Markdown で、インデックスはそこから派生します。学習済みデータ（Q 値、LinUCB のアーム、検索履歴）は派生データではないため、削除する前にエクスポートしてください（再構築が必要な場合を参照）。
CLI
npx ori init # scaffold a vault
npx ori index build # derive the index
npx ori explore "…" # navigated retrieval
npx ori sql "…" # read-only SQL over the index
MCP サーバー — ori serve を実行し、クライアント設定に登録します。エージェントはこの方法で使用します。
ライブラリ — recall は、CLI と MCP の ori_recall ツールがどちらも経由する、同じ配線済みのエントリーポイントです。そのため、プログラムからの利用方法とエージェントからの利用方法が食い違うことはありません。
import { recall } from "ori-memory";
const res = await recall("./vault", "what did we decide about caching?", { limit: 5 });
for (const hit of res.data.results) console.log(hit.title, hit.score);
searchComposite は、ベクトル、グラフのメトリクス、設定をすでに組み立てている呼び出し元向けにもエクスポートされています。recall を使えば、その組み立てを自動で行えます。
エクスポート対象は意図的に最小限に抑えており、semver の契約になっています。src/core の残りは内部実装です。0.8.0 より前のバージョンでは main も exports も提供されていなかったため、通常のインポートはエラーになり、ライブラリとしての利用方法もありませんでした。ただし、CLI と MCP の利用方法は常に動作しており、既存ユーザーへの影響はありませんでした。
ori-memory/cli は、バイナリの場所を特定してリンクせずに起動する必要がある呼び出し元向けに、CLI エントリーポイントを解決します。想定されている用途は require.resolve です。インポートすると CLI が実行されます。
ベンチマーク
ForgetEval — 指示どおりに忘れられるか？
deeplethe/lethe、bench/forgeteval/、MIT ライセンス。API キーも、ネットワークも、LLM による評価も不要です。 スコア判定は GeneratedCase.run() にある約 20 行の決定論的な部分文字列チェックです。recall_texts(query, k=10) を呼び出して上位 10 件を結合し、must_contain / must_not_contain を確認します。生成にはテンプレートと random.Random(42) を使用します。オプションの LLM フックはデフォルトで llm=None であり、使用していません。
| ファミリー | Ori | 必要な処理 |
|---|---|---|
| supersession | 200 / 200 | 事実を置き換え、古い値が表示されないようにする |
| decay | 200 / 200 | release(query) — 必要に応じてソフト削除する |
| amnesia | 198 / 200 | ある対象を削除し、周辺の対象は残す |
| purge | 182 / 200 | 完全に削除し、機密情報の原文を確実に消去する |
| drift | 198 / 200 | 2 回連続で置き換え、最後の値だけを残す |
| 全体 | 978 / 1000 (97.8%) | シード 42 で生成した 1,000 件 |
このテストスイートに合わせて調整したものではありません。未使用のシードでも 97.2%（シード 7）および 98.0%（シード 123）を達成します。修正したのはマッチャーの構造的なバグであり、個別ケース向けのパッチではありません。
これらの数値は、ゼロではなく35％の下限を基準に評価してください。 オラクルはトップ10に対する
must_contain AND must_not_contain で、must_contain が空の場合――すべての decay ケースと、200件中150件の purge ケース、
合計1,000件中350件――何も返さないシステムでも、空虚に合格してしまいます。書き込みを受け付けても一切返さないヌルアダプターは、**350/1000 =
35％を記録し、decay ファミリー全体では100％になります。実際に差が出る650件では、Ori は628/650 = 96.6％で、purge は91％から64％**に落ちます。これが実際の弱点です。公表されている LangMem 99.5／Lethe 99.3／Mem0 88.8 は全件のスコアであり、同じ下限を含んでいます。
docs/falsification/forgeteval-validity.mdを参照してください。
| システム | template | adversarial |
|---|---|---|
| LangMem | 99.5 | — |
| Lethe v1 | 99.3 | 63.4 |
| Ori Mnemos | 97.8 | 65.7 |
| Mem0 | 88.8 | 68.3 |
| MemPalace | 0 | — |
Ori は同じ日の早い時刻、このベンチマークで0/1000を記録しました。 低スコアではなく、構造的なゼロです。ForgetEval のアダプタープロトコルには supersede、release、purge という3つの任意操作がありますが、Ori にはどれもありませんでした。src/ 内でソースヒットはゼロです。すべてのケースが N/A でした。Ori がすでに備えていた ACT-R の減衰曲線と Ebbinghaus 曲線は、ランキング時の事前確率であり、それらを測定するベンチマークはありません。ForgetEval の「decay」ファミリーは、明示的な release(query) 呼び出しを意味します。305行の src/core/forget.ts が1日でギャップ全体を埋めました。このページで最も示唆に富む数字です。
この表はランキングではなく、「3位」と読むのは適切ではありません。
ForgetEval のコードは deeplethe/lethe 内にあります。ベンチマークと最高スコアのシステムは同じ組織のもので、リポジトリのスター数は14です。template 列には4つの項目がありますが、そのうち1つ（MemPalace）は削除プリミティブをまったく公開していないため、仕様上0点です。残りのうち2つは上限に達しています。adversarial レイヤーでは、Ori は14構成中5位で、論文自体の McNemar 検定がノイズとする63～68％の範囲内です（χ²=0.125、
p=0.724）。論文の言葉を借りれば、「このベンチマークが読み取るのはトレードオフであり、勝者ではない」ということです。統計的に有意な比較は、template における Ori 対 Lethe のみです。z=2.81、p=0.005 で、Lethe が実際に上回っています。
誰が順位に入ったかより、誰が不在かのほうが重要です。 Supermemory（スター数30.6k、シード資金$2.6M）は、POST /v4/memories/forget-matching を提供しています。これは dryRun、threshold、maxForget、監査ハンドルを備えた自然言語による忘却機能に加え、バージョン管理された PATCH による置き換えも可能です。ここでスコアを測定されたどのシステムよりも仕様の明確な制御プレーンであり、アダプタープロトコルにもほぼそのまま対応します。これまでベンチマークで評価されたことはありません。Hindsight（24.0k）、Cognee（30.8k、API 非互換のため除外）、MemOS（11.5k）、Honcho（7.3k）も同様です。
したがって、正直に主張できるのは、Ori が業界より優れた忘却性能を持つということではありません。Ori は API キーなしでオフラインで忘却できること、そして業界の忘却性能がどれほどかは誰にも分からないということです。
15のエージェントメモリーシステムを調査しました。自社システムの忘却ベンチマークを公開しているものはゼロです。 そのようなベンチマークは5つ存在します。ForgetEval、 Memora/FAMA、MemoryAgentBench-SF、StateMemBench、MemLeak です。しかし、ベンダーはそのどれも引用していません。現存する忘却性能の数値は、すべて競合他社または第三者が算出したものです。
adversarial 列には、もう1つ注意点があります。 その385件のうち253件は、ベンダー自身のシステムが合格した場合にのみ採用されており、adversarial.py では「オラクル検証済み（Lethe / Lethe+LLM がケースに合格）」と注記されています。著者自身による、盲検で実施された77件の外部サブセットでは、業界全体のスコアが63～68％の範囲から28～33％に下がっており、内部テストスイートがかなり容易であることを示しています。「測定者のシステムが解ける」ことを採用基準とするベンチマークでは、測定者を順位付けできません。
再現方法：
git clone https://github.com/deeplethe/lethe && cd lethe
cp <ori>/bench/forgeteval_ori_adapter.py bench/forgeteval/ori_adapter.py
export ORI_BRIDGE=<ori>/bench/forgeteval-bridge.mjs
python -m bench.forgeteval.run --adapter ori --suite template --scale 200 --seed 42
4分、1,000件、$0.00です。ハーネスはケースごとに約10回呼び出すため、呼び出しごとに CLI サブプロセスを起動するとインタープリターの起動だけで何時間もかかります。そのため、アダプターは常駐する Node プロセスと NDJSON で通信します。
HotpotQA — マルチホップ検索
Mem0 との直接比較です。両システムは同じドキュメントをインデックス化し、同じ実行で同じ質問に回答しました。
| 指標 | Ori Mnemos | Mem0 1.0.6 | Δ |
|---|---|---|---|
| Recall@5 | 0.87 | 0.29 | 3.0× |
| MRR | 0.91 | 0.42 | 2.2× |
| 検索 F1 | 0.51 | 0.26 | 2.0× |
| 回答プロキシ | 0.73 | 0.34 | 2.1× |
| インフラストラクチャ | Markdown + SQLite | Redis + Qdrant + cloud | — |
n = 50、単一実行、シード平均なし、topK = 5。Mem0 は 1.0.6（2026 年 3 月）です。
2.x ではまだ再実行していないため、これは現時点での比較としてではなく、ある時点での比較としてお読みください。生の出力は bench/results/ にあります。再現するには
bench/hotpotqa-eval.ts と
bench/mem0-hotpotqa.py を使用してください。
これらは HotpotQA の公式指標ではなく、HotpotQA のリーダーボードとの比較には使用できません。 公式スコアラーの hotpot_evaluate_v1.py は、独自の normalize_answer による回答 EM/F1、(title, sentence_id) ペアに対する根拠文 F1、さらに結合 EM/F1 を報告します。上の表は bench/hotpotqa-eval.ts で定義されたタイトルレベルの検索指標であり、「回答プロキシ」は HotpotQA の指標ではありません。これは、取得したテキストに対する正解回答のトークン再現率です。この比較が有効なのは一方向のみです。Ori と Mem0 は同じ質問に対し、同じハーネスで評価されたため、2 つの列の比率には意味があります。絶対値は、どこにもそのまま適用できません。
n = 50 における Recall@5 の Wilson 95% 信頼区間は、Ori が [0.75, 0.94]、Mem0 が
[0.18, 0.43] です。区間は重ならないため、差は実在しますが、表の小数第 2 位までの精度には意味がありません。0.87 は「0.80 台後半」とお読みください。
ここではレイテンシを報告していません。評価ハーネスがレイテンシを記録しないため、数値を示しても実測値ではなく記憶に基づく値になってしまいます。実測されているのは、Ori が API キーもネットワークも使わず、Markdown とローカルの SQLite インデックスから回答することです。
LoCoMo — 長期会話メモリ
10 件の会話にわたる 1,536 件の質問。 検索では、BM25、埋め込み、 PageRank を組み合わせ、上位 5 件を取得します。API キーもネットワーク接続も不要です。回答列は 抽出的な代替指標であり、生成された回答ではなく、取得テキストに対する正解回答のトークン再現率です。
| カテゴリ | 再現率 | 回答 F1 | MRR | n |
|---|---|---|---|---|
| オープンドメイン | 0.943 | 0.929 | — | 841 |
| 単一ホップ | 0.863 | 0.758 | — | 321 |
| マルチホップ | 0.528 | 0.670 | — | 282 |
| 時間関連 | 0.565 | 0.478 | — | 92 |
| 全体 | 0.827 | 0.819 | 0.729 | 1,536 |
生の出力：bench/results/locomo-eval-2026-09-19T22-37-31-698Z.json。
npx tsx bench/locomo-eval.ts --json で再現できます。実行には 48 秒かかります。
マルチホップと時間関連は弱いカテゴリであり、そのように報告しています。
2026-09-19 に判明した、このファイルの以前のバージョンに対する 2 つの修正点：
- 以前は、質問数 695 件、全体の再現率 0.687 と報告していました。この部分集合では、1,536 件中 841 件を占めるオープンドメインカテゴリ（ベンチマークの半数以上）が、気付かれないまま除外されていました。カテゴリ別の数値はほぼ正しかったものの、「全体」は人為的に選んだ 3 カテゴリの平均でした。
bench/README.mdにはさらに別の数値（再現率 44.7%）が記載されていましたが、現在のハーネスでは何も再現できません。現在は、実行ファイルを添えて数値を 1 つだけ掲載しています。 - 2026-09-19 の実行結果は、2026-07-22 の実行結果を小数第 3 位まで再現しています。そのため、検索指標の修正
09ac45dとラムダ値の変更72fdd13を経ても、これらの数値は安定しています。
公開されている LoCoMo リーダーボードとの比較表は、意図的に掲載していません。 それらは LLM による判定スコアですが、上記の数値はトークン F1 です。これらは異なる指標であり、同じ列に並べると、順位を報告するのではなく捏造することになります。この README の以前のバージョンでは、まさにそれを行っていました。
LoCoMo 自体には、既知の欠陥があります。独立した監査では、質問の 6.4% で正解キーが誤っていることが判明し、理論上の上限は 93.57% です。また、標準の gpt-4o-mini 判定器は、意図的に誤った回答の 62.81% を正解として受け入れます。公開スコアの少なくとも 1 つは、数学的な上限を超えています。このベンチマークで近い結果が出ても、どちらの方向にも強い根拠にはなりません。そのため、ここでは報告していますが、冒頭には掲げていません。
LongMemEval-S — 検索、500 問
セッション単位、採点対象 470 問（公式スコアラーは棄権に関する 30 問を除外します）。API キー不要、ネットワーク不要、LLM による判定不要 — ベンチマーク独自のスコアラーがインポートするのは sys、json、numpy のみです。
| recall_any@k | recall_all@k | ndcg_any@k | |
|---|---|---|---|
| @1 | 0.866 | 0.300 | 0.866 |
| @5 | 0.966 | 0.830 | 0.884 |
| @10 | 0.981 | 0.904 | 0.898 |
recall_all@k は上位 k 件に正解のセッションがすべて含まれることを要求し、recall_any@k は 1 件含まれることを要求します。公式サマリーでは recall_all@5 と ndcg_any@5 が報告されます。
同じベンチマークで同じ埋め込みモデルを使用した公開済みの数値との比較です。いずれも API 呼び出しはゼロです。
| システム | 埋め込みモデル | R@1 | R@5 | R@10 |
|---|---|---|---|---|
| MemPalace (raw) | all-MiniLM-L6-v2 | 80.6% | 96.6% | 98.2% |
| Lethe v1 | all-MiniLM-L6-v2 | 85.4% | 97.4% | 99.0% |
| Ori Mnemos | Xenova/all-MiniLM-L6-v2 | 86.6% | 96.6% | 98.1% |
Ori は @1 でリードし、@10 では同等です。これは見た目より控えめな主張です。 MemPalace の独立した分析（arXiv:2604.21284）では、96.6% の R@5 は「ChromaDB のデフォルトの埋め込みモデル（all-MiniLM-L6-v2）を逐語的なテキストチャンクに適用した場合の性能」であり、最小限の ChromaDB セットアップで再現できると結論づけています。k=5 ではこの指標は飽和しており、主に埋め込みモデルの性能を測定します。3 つの行すべてで同じモデルが使われています。率直に言えば、Ori の検索はボトルネックではなく、この軸ではシステム間の差がつかなくなっています。
Ori の recall_any@5 は 0.9660 で、MemPalace が公開している 96.6% と有効数字 3 桁まで一致します。これは偶然の一致であり、数値をコピーしたものではありません。質問ごとの出力全体がコミットされています。
LoCoMo と一致する弱点カテゴリーは、複数セッションが 0.653、時間的推論が 0.772 の recall_all@5 で、どちらも単一セッションの 2 種類では 1.000 です。マルチホップと時間的推論は、両方のベンチマークで Ori が劣る分野です。これはノイズではなく、独立した 2 つの測定結果が一致しています。
再現方法：
npx tsx bench/longmemeval-eval.ts --data <longmemeval_s_cleaned.json>
python bench/longmemeval-score.py <rankings.json> <path/to/LongMemEval>
python <LongMemEval>/src/evaluation/print_retrieval_metrics.py <rankings.jsonl>
500 問を 11 分、$0.00 です。bench/longmemeval-score.py は recall_all@k を再実装するのではなく、ベンチマーク独自の evaluate_retrieval をインポートしているため、これらの数値は著者による指標の定義に基づいています。
クイックスタート
npm install -g ori-memory
ori init my-agent
cd my-agent
エージェントに接続します：
# Full adapters — auto-orient at session start, capture at session end
ori bridge claude-code --vault ~/brain # hooks + MCP + CLAUDE.md
ori bridge hermes --vault ~/brain # native plugin + MCP + HERMES.md
ori bridge opencode --vault ~/brain # plugin + MCP + AGENTS.md
# MCP-only adapters — tools available, no lifecycle automation
ori bridge cursor --vault ~/brain # .cursor/mcp.json
ori bridge codex --vault ~/brain # ~/.codex/config.toml
# Any MCP client
ori bridge generic --vault ~/brain # prints config for manual setup
Claude Code、Hermes Agent、OpenCode はライフサイクル全体の統合に対応しています。セッション開始時にエージェントが状況を把握し、セッション終了時にインサイトを記録し、ノートの書き込み時に内容を検証します。Cursor、Codex、その他の MCP クライアントは 16 個すべてのツールを利用できますが、セッションのライフサイクルは各自で管理します。
手動での MCP 設定（MCP を使用するあらゆるクライアントで動作します）：
{
"mcpServers": {
"ori": {
"command": "ori",
"args": ["serve", "--mcp", "--vault", "/path/to/brain"],
"env": { "ORI_VAULT": "/path/to/brain" }
}
}
}
セッションを開始します。エージェントは自動的に自身の ID を受け取り、初回実行時にオンボーディングを開始します。
最新情報
v0.6.0 — ナビゲート可能な再帰。 ori explore は、フラットな統合結果を返さなくなりました。エージェントには分解ツリーが表示され、どの分岐で結果が得られ、どの分岐で行き詰まったかを確認して、探索そのものを制御できます。新しいセッションコマンド：explore-start、explore-expand、explore-conclude。予算は上限ではなく目安です。明示的な延長機能を備えたソフトな上限を導入しました。4 つのシグナルを融合する処理の上に、クロスエンコーダーによる再ランキング段階を追加しました。RMH 制約 2 は部分的な対応から、実際に機能する対応へと進化しました。
$ ori explore-start "why did we choose SQLite over postgres"
exploration e7f2 — 3 branches
├─ [1] storage engine tradeoffs 4 notes, strong signal
├─ [2] deployment constraints 2 notes
└─ [3] prior migration decisions dead end — no notes
next: ori explore-expand e7f2 1 | ori explore-conclude e7f2 --answered
v0.5.6 — OpenCode ブリッジ。 初回実行時のオンボーディング、自動セッション記録、ノートの検証、複数 Vault のサポートを含む、ライフサイクル全体の統合です。ori bridge opencode の 1 コマンドで実行できます。
v0.5.5 — Ebbinghaus に基づく記憶の定着度。 一度だけアクセスしたノートはすぐに薄れます（半減期は約 7 日）。複数のセッションでアクセスしたノートは深く定着します（最大約 28 日）。短期記憶と長期記憶を、構造的に区別しています。
すべての履歴は CHANGELOG をご覧ください。
再帰型メモリハーネス
Ori は、AI エージェント向けの永続メモリの振る舞いに関する一連の制約である 再帰型メモリハーネス（RMH）フレームワークの最初の実装です。
中核となる洞察は、再帰型言語モデル（Zhang、Krassa、Khattab、2026）に由来します。RLM では、コンテキストをウィンドウに詰め込む入力としてではなく、探索する環境として捉えます。モデルに大きな机を与えるのではなく、足を与えて図書館の中を歩かせるのです。RMH は、同じ原則を永続メモリに適用します。
このフレームワークは、次の 3 つの制約で定義されます。
-
検索はグラフに沿って行う必要があります。 メモリはフラットなベクトルストアではありません。ノートはノード、Wiki リンクはエッジです。検索では、構造をたどります。α＝0.45 のパーソナライズド PageRank、エッジに沿った活性化の拡散、コミュニティを考慮したトラバーサルを利用します。見つかる情報は、グラフのトポロジーによって形作られます。
-
未解決のクエリには再帰的に対応する必要があります。 1 回の検索で不十分な場合、システムは質問をサブ質問に分解し、それぞれについて検索してから統合します。収束検出により、新たな検索で新しい情報が見つからなくなると再帰を停止します。これを実行するのが
ori exploreです。 -
検索のたびにグラフを再構築する必要があります。 検索は読み取り専用ではありません。ともに検索されたノート間では、共起エッジが強化されます（ヘッブ学習）。検索されたノートが実際に役立ったかどうかに基づいて、Q 値が更新されます。グラフは利用される中で学習し、クエリを実行するたびに次のクエリの精度が向上します。
多くのメモリシステムでは、検索を単なる探索として扱います。RMH では、検索をナビゲーション、再帰、学習として扱います。すべてのセッションを通じて進化するグラフ上で、それらを実現します。
論文全文はこちら：Introducing Recursive Memory Harness
概要
-
永続的なアイデンティティ。 エージェントの状態（名前、性格、目標、方法論）はプレーンな Markdown に保存され、MCP の指示を介してセッション開始時に自動で注入されます。アイデンティティは、再設定しなくてもクライアントの切り替え、マシンの移行、モデルの変更後も維持されます。
-
ナレッジグラフ。 すべての
[[wiki-link]]は有向エッジです。PageRank による重要度、Louvain 法によるコミュニティ検出、媒介中心性、ブリッジ検出、孤立リンクとリンク切れの分析に対応しています。構造は MCP ツールと CLI から照会できます。 -
3 つのメモリ領域。 アイデンティティ（
self/）の減衰率は 0.1 倍で、ほとんど薄れません。知識（notes/）の減衰率は 1.0 倍で、関連性によって維持されるか失われます。操作（ops/）の減衰率は 3.0 倍で、活発に消費されていき、自ら整理されます。この分離は見た目だけではなく、アーキテクチャ上のものです。 -
認知的忘却。 ノートの減衰には、任意の TTL ではなく ACT-R のベースレベル学習方程式を使用します。使用されたノートは維持されます。ウィキリンクのエッジに沿った活性化の拡散により、その近傍のノートも活性状態に保たれます。構造上重要なノードは Tarjan のアルゴリズムで保護されます。
ori pruneは、何かをアーカイブする前に、活性化トポロジー全体を分析します。 -
4 つのシグナルの融合。 セマンティック埋め込み、BM25 によるキーワード照合、パーソナライズされた PageRank、連想的な活性度を、スコアで重み付けした Reciprocal Rank Fusion で融合します。意図分類（エピソード、手続き、意味、決定）によってシグナルの重みが自動的に変わります。
-
減衰パイプライン。 アブレーションテストで検証された、融合後の 3 段階の処理です。重力減衰は、クエリ語との重複がゼロであるコサイン類似度の幻影を半減させます。ハブ減衰は P90 の次数ペナルティを適用し、マップノートが結果を支配しないようにします。解決度ブーストは、受動的な観察よりも実行可能な知識（決定、学び）を優先して表示します。
-
学習型検索（v0.4.0）。 3 つのインテリジェンス層により、セッションを重ねるごとに検索品質が向上します。詳細は、以下の検索インテリジェンスを参照してください。
-
取り込み・昇格パイプライン。
ori addは受信トレイに取り込みます。ori promoteは分類（アイデア、決定、学び、洞察、障害、機会）を行い、リンクを検出して領域を提案します。50 種類以上のヒューリスティックパターンを使用します。LLM による拡張は任意です。 -
クラウド依存なし。 all-MiniLM-L6-v2 をプロセス内で実行して、ローカルで埋め込みを生成します。ベクトルとインテリジェンスの状態には SQLite を使用します。すべてのデータはファイルシステム上にあります。コア機能に API キーは不要です。
検索インテリジェンス（v0.4.0）
手動で調整しなくても、時間とともに検索品質を向上させる 3 つの学習層です。強化学習、情報検索、認知科学、バンディット理論に関する 63 件の研究資料を統合しています。
レイヤー 1 — Q 値による再ランキング
ノートには、セッションの結果に基づき、指数移動平均の更新を通じて Q 値が付与されます。時間とともに、本当に役立つノートの順位が上がり、ノイズの順位は下がります。
| シグナル | 報酬 | 発生条件 |
|---|---|---|
| 前方引用 | +1.0 | 新しいコンテンツで、取得したノートへの [[link]] を作成する |
| 取得後の更新 | +0.5 | 取得したばかりのノートを編集する |
| セッション内での再取得 | +0.4 | 異なるクエリで同じノートが表示される |
RRF による融合の後、フェーズ B では類似度スコアと学習済み Q 値をラムダでブレンドし、さらに探索ボーナスを加えて候補セットを再ランキングします。これにより、取得頻度の低いノートも確実に見つかります。ノートが表示されても一度も使用されない場合、ボーナスは縮小します。一度でも評価されたノートはボーナスをすべて維持するため、使用されたノートの順位が、関連性の同じ未閲覧のノートを下回ることはありません。累積バイアスの上限（MAX=3.0、圧縮=0.3）により、スコアが際限なく上昇するのを防ぎます。
レイヤー 2 — 共起エッジ
一緒に取得されたノート同士のエッジが強化されます。これはナレッジグラフ上のヘッブ学習です。エッジの重みは、NPMI 正規化（ベースレートを超える実際の関連性）、GloVe のべき乗則による頻度スケーリング、強度の蓄積を伴うエビングハウス忘却曲線（頻繁に共に取得されるペアほど減衰が遅い）を使って計算されます。
ノードごとのターリジアノ恒常性により、ハブノートがすべてのエッジの重みを吸収するのを防ぎます。書誌結合により、クエリを実行する前に既存の Wiki リンク構造から 0 日目のエッジを作成します。
Wiki リンクと共起を組み合わせたグラフにパーソナライズド PageRank ウォーク（HippoRAG、α=0.5）を適用し、セマンティック検索だけでは決して見つからないノートを提示します。
レイヤー 3 — ステージのメタ学習
各オプションのパイプラインステージ（PageRank、ウォームス、ハブ抑制、共起 PPR）は、8 次元のクエリ特徴ベクトルを使う LinUCB コンテキスト付きバンディットでラップされています。システムは、どのステージがどのクエリタイプに役立つかを学習し、継続的に悪影響を与えるステージを自動的にスキップします。
ステージごとに 3 つの選択肢があります。実行／スキップ／棄権（パイプラインを早期終了）。コストを考慮したしきい値により、コストの高いステージほど高い基準が適用されます。必須ステージ（セマンティック検索、BM25、RRF フュージョン、Q リランキング）はスキップされません。バンディットの報酬は結果の形状と用語の再現率を測定しますが、ノートが使用されたかどうかは判断できないため、Q リランキングは必須です。ACQO の 2 段階カリキュラムでは、探索中（最初の 50 サンプル）はすべてのステージを実行し、その後に最適化を行います。
セッション学習ループ
Query → Retrieve → Use (cite, update, create) → Reward signals
↓ ↓
Co-occurrence edges grow Q-values update (session-end batch)
↓ ↓
Stage meta-learner updates Better retrieval next session
すべての更新はセッション終了時に単一の SQLite トランザクション内で、共起 → Q 値 → ステージ学習の順に行われます。
スタック
Layer 6: MCP Server 16 tools, 5 resources — any agent talks to this
Layer 5: Recursive Exploration PPR graph traversal, sub-question decomposition, convergence detection
Layer 4: Retrieval Intelligence Q-value reranking, co-occurrence learning, stage meta-optimization
Layer 3: Dampening Pipeline gravity, hub, resolution — ablation-validated
Layer 2: Four-Signal Fusion semantic + BM25 + PageRank + warmth → score-weighted RRF
Layer 1: Knowledge Graph + Vitality wiki-links, ACT-R decay, spreading activation, zone classification
Layer 0: Markdown files on disk git-friendly, human-readable, portable
MCP ツール 16 個 · リソース 5 個 · CLI コマンド 20 個 · テスト 874 件
トークンコスト
検索を行わない場合、質問のたびに Vault 全体をコンテキストに読み込む必要があります。Ori を使えば、コストは一定です。
| Vault のサイズ | Ori なし | Ori あり | 削減率 |
|---|---|---|---|
| ノート 50 件 | 10,100 トークン | 850 トークン | 91% |
| ノート 200 件 | 40,400 トークン | 850 トークン | 98% |
| ノート 1,000 件 | 202,000 トークン | 850 トークン | 99.6% |
| ノート 5,000 件 | 1,010,000 トークン | 850 トークン | 99.9% |
Ori を使う一般的なセッションのコストは 約 $0.10 です。使わない場合は 約 $6.00 以上 です。
アーキテクチャ
Any MCP Client
(Claude, Cursor, Windsurf,
Cline, Hermes, custom agents, VPS)
│
MCP Protocol
(stdio / JSON-RPC)
│
┌───────────────────┐
│ Ori MCP Server │
│ │
│ instructions │ identity auto-injected
│ resources (5) │ ori:// endpoints
│ tools (16) │ full memory operations
└─────────┬─────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
┌───────────┐ ┌───────────┐ ┌───────────┐
│ Knowledge │ │ Identity │ │Operations │
│ Graph │ │ Layer │ │ Layer │
│ │ │ │ │ │
│ notes/ │ │ self/ │ │ ops/ │
│ inbox/ │ │ identity │ │ daily │
│ templates│ │ goals │ │ reminders│
└─────┬─────┘ │ method. │ │ sessions │
│ └───────────┘ └───────────┘
┌─────┴──────┐
│ │
Wiki-link Embedding ┌──────────────────────┐
Graph Index │ Retrieval Intelligence│
(in-mem) (SQLite) │ │
│ │ │ Q-values (note_q) │
PageRank Semantic │ Co-occur (edges) │
Spreading BM25 │ Stage Q (LinUCB) │
Activation 4-Signal │ Dampening (3 stages)│
Communities Fusion │ Explore (PPR+RMH) │
└──────────────────────┘
MCP ツール
| ツール | 機能 |
|---|---|
ori_wake | セッションの起動：範囲を限定したブリーフィングと、新しいボルトの場合はオンボーディング |
ori_update | アイデンティティ、目標、方法論、日次記録、リマインダーに書き込み |
ori_update_decision | 更新通知に対するユーザーの回答を記録 |
ori_whats_new | インストール済みバージョンまたは任意のバージョンのリリースノート |
memory_sql | インデックスに対する読み取り専用 SQL。ランキングツールでは表現できないあらゆるクエリに対応 |
ori_health | 詳細な診断 |
ori_add | 受信箱に記録 |
ori_promote | 分類、リンク付け、領域の割り当てを行って昇格 |
ori_validate | スキーマの検証 |
ori_query_ranked | Q 値の再ランキング、共起 PPR、ステージメタ学習を用いた包括的な検索 |
ori_query_similar | セマンティック検索（ベクトルのみ、高速） |
ori_warmth | 関連性の温度フィールドを調査 |
ori_explore | 再帰的なグラフ探索 — PPR、サブ質問の分解、収束検出 |
ori_prune | アクティベーショントポロジーの分析とアーカイブ候補の提示 |
ori_index_build | 埋め込みインデックスの構築／更新と共起エッジのブートストラップ |
5 つのツールは memory_sql に置き換えられました。このツールは 1 つのステートメントでそれらの質問に回答し、ディスクからボルトを再走査する代わりにインデックスを読み取るため、20～46 倍高速です。
| 旧 | 新 |
|---|---|
ori_status | SELECT COUNT(*) FROM v_note |
ori_query orphans | SELECT title FROM v_note WHERE inbound = 0 |
ori_query dangling | SELECT * FROM v_dangling |
ori_query backlinks | SELECT src_title FROM v_link WHERE dst = '…' |
ori_query cross-project | SELECT n.title FROM v_note n JOIN note_project p ON p.note_id = n.id GROUP BY n.id HAVING COUNT(DISTINCT p.project) > 1 |
ori_query_important | SELECT title, pagerank FROM v_note ORDER BY pagerank DESC |
ori_query_fading | ori_prune。この機能は、説明でもすでに ori_prune に委ねられていました |
ナビゲーション付き探索ツール（explore_start / _expand /
_conclude）は、記録されたセッションが 6 か月間ゼロだったため、MCP から削除されました。これらは ori explore-start、ori explore-expand、ori explore-conclude として引き続き利用できます。
CLI
# Vault management
ori init [dir] # Scaffold a new vault
ori status # Vault overview
ori health # Full diagnostics
ori whats-new [version] # Release notes
# Note lifecycle
ori add <title> [--type <type>] # Capture to inbox
ori promote [note] [--all] # Promote to knowledge graph
ori validate <path> # Schema validation
ori archive [--dry-run] # Archive stale notes
ori prune [--apply] [--verbose] # Topology analysis + archive candidates
# Retrieval
ori explore <query> # Recursive graph traversal (RMH)
ori query ranked <query> # Full intelligent retrieval
ori query similar <query> # Semantic search
ori query important # PageRank ranking
ori query fading # Vitality detection
ori query orphans # Notes with no incoming links
ori query dangling # Broken wiki-links
ori query backlinks <note> # What links to this note
ori query cross-project # Multi-project notes
# Infrastructure
ori index build [--force] # Rebuild everything derived from the vault
ori index status # Index statistics
ori graph metrics # PageRank, centrality
ori graph communities # Louvain clustering
ori serve --mcp [--vault <path>] # Run MCP server
ori bridge claude-code [--scope <s>] [--activation <a>] [--vault <p>] # Claude Code (hooks + MCP + instructions)
ori bridge hermes [--scope <s>] [--activation <a>] [--vault <p>] # Hermes Agent (plugin + MCP + instructions)
ori bridge opencode [--scope <s>] [--activation <a>] [--vault <p>] # OpenCode (plugin + MCP + AGENTS.md)
ori bridge cursor [--scope <s>] [--vault <p>] # Cursor (MCP config)
ori bridge codex [--scope <s>] [--vault <p>] # Codex (TOML config)
ori bridge generic [--scope <s>] [--vault <p>] [--json] # Any MCP client (prints config)
ori bridge status [--json] # Inspect all bridge installs
ori bridge <target> --uninstall # Remove Ori config for a target
パスを受け取るコマンドでは、相対ファイルパスはボルトを基準に扱われます。絶対パスもこれまでどおり使用できます。
再構築するタイミング
.ori/ には異なる2種類のデータがあり、破棄できるのはそのうち一方だけです。
派生データ — 必要に応じて Markdown から再構築されます。
| ストア | 管理方法 | ori index build が必要なタイミング |
|---|---|---|
派生インデックス（note、edge、note_term、グラフ指標キャッシュ） | 各クエリで自動的に管理されます — ファイルごとに stat を実行し、変更されたファイルのみ再解析します | 編集時には不要です。クエリで「N of M notes」をカバーしているという警告が表示された場合は --force を指定します |
| 埋め込み（セマンティックベクトル） | 書き込み時に ori add が管理します。テーブルが存在しないか空の場合にのみクエリで処理します | ori add 以外の手段（エディター、同期クライアント、スクリプト）でノートを書き込んだ場合です。キーワードやリンクではすぐに検索できますが、埋め込みが作成されるまでは意味による検索はできません |
| 共起の初期構築 | ori index build のみ | リンク構造が大幅に変わり、初日のエッジに変更を反映したい場合です |
蓄積データ — ほかに保存場所はなく、再構築すると失われます。
retrieval_log、note_q、q_history、q_history_genuine、stage_q、
stage_log、boosts、note_access、memory_events、および
co_occurrence の retrieval 行です。
1,548件のノートがある保管庫で計測したところ、rm -rf .ori/ && ori index build を実行すると、これらのテーブルのうち8つが空になります。つまり、564セッションにわたる6か月分の検索履歴、1,427個の学習済みQ値、そしてどのランキングステージを実行するかを決定する8つの稼働中のLinUCBアームが失われます。そのうち q_history_genuine と memory_events は、本番コードでは一切作成されず、何を使っても再構築できません。
そのため、削除する前にエクスポートしてください。
ori index export-learned # -> ops/ori-learned.ndjson
rm -rf .ori/
ori index build
ori index import-learned
この往復処理は、実際の保管庫で bench/learned-roundtrip.mjs によって損失がないことを検証済みです。行数だけでなく、Q値そのもののダイジェストも比較します。値がずれているのに件数だけ一致しても、何の意味もない合格だからです。エクスポート形式はNDJSONで、決定的な順序に並べられています。56,850行で約23 MBと、243 MBのバイナリに比べて十分に小さく、差分も確認しやすいため、コミットできます。バイナリはそうはいきません。
実用上のルールは次のとおりです。自由に編集やクエリを行い、Ori以外からノートを一括追加した後は ori index build を実行します。クエリで保管庫全体をカバーできないという報告があった場合は ori index build --force を実行してください。 --force は蓄積データを保持したまま全体を再解析します。蓄積データが失われるのは、ファイルを削除した場合のみです。
このREADMEの以前のバージョンでは、.ori/ 以下のすべてのデータは派生データで、破棄できると説明していました。それは誤りであり、その説明に従った結果、6か月分の学習データが失われました。
保管庫の構造
vault/
├── .ori # Vault marker
├── ori.config.yaml # Configuration
├── notes/ # Knowledge graph (flat, no subfolders)
│ └── index.md # Hub entry point
├── inbox/ # Capture buffer
├── templates/ # Note and map schemas
├── self/ # Agent identity
│ ├── identity.md # Name, personality, values
│ ├── goals.md # Active threads, priorities
│ ├── methodology.md # Processing principles
│ └── memory/ # Agent's accumulated insights
└── ops/ # Operational state
├── daily.md # Today's completed and pending
├── reminders.md # Time-bound commitments
└── sessions/ # Session logs
すべてのファイルはプレーンなMarkdownです。任意のテキストエディター、Obsidian、またはファイルブラウザーで開けます。git log が監査履歴になります。
デプロイ
ローカル。 グローバルにインストールし、ori init を実行して、MCP クライアントに接続します。これで完了です。
VPS／ヘッドレス環境。 サーバーにインストールします。ori serve --mcp --vault /path/to/vault を実行します。メモリはファイルシステムに保持されます。git push でバックアップしてください。
リモートターミナル。 Hermes Agent はDocker、SSH、Modal、Daytonaのバックエンドに対応しています。エージェントがリモートターミナルで動作する場合は、その環境内に ori をインストールしてPATHに追加し、保管庫を永続ストレージ（エフェメラルではないストレージ）に置く必要があります。環境が休止状態になるModalのようなサーバーレスバックエンドでは、保管庫を永続ボリュームにマウントしてください。
複数の保管庫。 エージェントごとに別々のOriインスタンスを使用します。各保管庫は自己完結しており、固有のアイデンティティ、ナレッジグラフ、運用状態を持ちます。
スクリプトから利用可能。 CLIは構造化JSONを返します。cronジョブ、Webhookハンドラー、またはオーケストレーションループで使用できます。
モデルのインストール
Ori では、インストールに関する概念を 3 つに分けています。
scope：globalはマシン全体で 1 つの vault に従い、projectは 1 つのリポジトリ／ワークスペース内にとどまりますactivation：autoはアダプターが対応している場合、セッション開始時にori_wakeを実行します。manualではツールを利用可能な状態にしますが、自動で状況を把握することはありませんvault：明示的な--vaultが優先されます。指定がない場合、Ori はインストールスコープに基づいて解決します
優先順位のルール：
- プロジェクトへのインストールはグローバルへのインストールより優先されます
- 明示的な
--vaultは推定された vault より優先されます - プロジェクトの activation はグローバルの activation より優先されます
ブリッジのライフサイクル：
- 同じ
ori bridge ...コマンドを再実行すると、vault パスまたは activation がその場で更新されます --uninstallを使用すると、対応アダプターから Ori が所有する設定を削除できます- 汎用インストールでは、Ori がそのクライアント設定領域を所有していないため、手動でのアンインストール手順が出力されます
Claude Code、Hermes Agent、OpenCode は、ライフサイクルフックを備えた完全自動化アダプターです。Claude Code はフックスクリプトを使用します。Hermes は ~/.hermes/plugins/ori/ にインストールされるネイティブの Python プラグインを使用します。OpenCode は .opencode/plugins/lifecycle.js の JavaScript プラグインを使用します。3 つともセッション開始時に自動で状況を把握し（初回実行の検出による）、セッションがアイドル状態になったときにインサイトを記録します。Cursor と Codex は、ネイティブの MCP 設定インストールに対応しています。Codex は ~/.codex/config.toml に書き込み、単一のグローバル設定領域を使用します。ここでの「project」スコープは、プロジェクトごとの設定ファイルではなく、プロジェクトに類似した実行時の vault 検出を意味します。その他の MCP 対応クライアントでは、現在 ori bridge generic を使用し、出力された設定を各クライアントの設定領域に組み込めます。
設定
ori.config.yaml で、調整可能なすべてのパラメーターを制御できます。ori init の実行時に、適切なデフォルト値で生成されます。
| セクション | 制御内容 |
|---|---|
vitality | 減衰パラメーター、代謝率、ゾーンのしきい値、ブリッジボーナス |
activation | 拡散活性化：減衰、最大ホップ数、最小ブースト |
retrieval | シグナルの重み、探索バジェット、RRF k |
engine | 埋め込みモデル、データベースパス |
warmth | 驚きのしきい値、PPR パラメーター、グラフの重み |
promote | 自動昇格、プロジェクトのルーティング |
llm | オプション：Anthropic、OpenAI 互換モデル、またはローカルモデル |
LLM の統合は任意です。すべての操作はヒューリスティックのみを使って決定論的に動作します。LLM を設定すると、分類とリンクの提案が改善されます。
主権が重要な理由
ほとんどのメモリーシステムでは、ユーザーが管理できないインフラストラクチャにエージェントの知識が保存されます。独自仕様のデータベース、クラウドサービス、ベンダー独自のフォーマットなどです。
Ori は、ユーザーが所有するファイルとしてメモリーを保存します。vault はポータブルです。新しいマシンに移動したり、git リモートにプッシュしたり、テキストエディターで開いたりできます。設定を 1 行変更するだけで MCP クライアントを切り替えられます。メモリーは特定のプラットフォームにロックされていないため、どのプラットフォームに移行しても維持されます。
これは思想の問題ではありません。アーキテクチャの問題です。ポータブルなメモリーは、組み合わせ可能なメモリーです。
開発
git clone https://github.com/aayoawoyemi/Ori-Mnemos.git
cd Ori-Mnemos
npm install
npm run build
npm link
ori --version
npm test # 860+ tests
npm run lint # Type check
npm run dev # Watch mode
PR を作成する前に、CONTRIBUTING.md をご確認ください。
PR や追加機能を提供してくださった @maichler と Ori コミュニティの皆様に感謝します。
ライセンス
Apache-2.0
メモリーは主権です。Ori はエージェントに心を与えます。
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。