sqlite-graph-memory

sqlite-graph-memory：Claude Code、Cursor、Codex 向けの、手持ちの Markdown ノートを使った永続メモリ

普段から保存しているノートに蓄積される、コーディングエージェント向けの長期メモリです。Obsidian の保管庫を含む、あらゆる Markdown フォルダーで使える MCP サーバーと CLI を提供します。pip install でインストールしてフォルダーを指定すれば、Claude Code、Cursor、Codex など、あらゆる MCP クライアントから情報を呼び出せます。

エージェントはセッションごとにすべてを忘れ、単純なベクトル検索では、関連のない断片が平坦に返されます。このツールを使えば、手持ちの Markdown ノートを対象に連想検索できます。ベクトル検索でエントリーポイントを見つけ、すでに書いた [[wikilinks]] がグラフになります。SQLite ファイルは 1 つだけで、グラフデータベースも ETL 処理もサーバーも不要です。

3 つのコマンド

pip install 'sqlite-graph-memory[embeddings]'
sgm-index ./notes
sgm-ask --ab "In which programming language is the tool behind Project Ouzel written?"

./notes は、Markdown ノートが入った任意のフォルダーです。以下とまったく同じ出力を得るには、このリポジトリにある 202 ノートの合成保管庫を使ってください（pip パッケージには含まれていません）。

git clone --depth 1 https://github.com/tonydzi/sqlite-graph-memory && cp -R sqlite-graph-memory/bench/vault ./notes

実際の出力、上位 5 件（全 12 件）：

--- DIRECT memory (vector) ---
 1. [  1.66] project-ouzel
 2. [ -1.33] project-avocet
 3. [ -1.79] tool-cobbleset
 4. [ -2.44] meeting-2025-10-21-lighthouse-sync
 5. [ -2.70] person-severin-ibarrondo

--- ASSOCIATIVE memory (vector+graph) ---
 1. [  1.66] project-ouzel
 2. [  1.14] tool-lanternfish  <== +graph
 3. [ -1.33] project-avocet
 4. [ -1.79] tool-cobbleset
 5. [ -2.44] meeting-2025-10-21-lighthouse-sync

答えは tool-lanternfish にあります（「Lanternfish は Elixir で書かれています」）。質問では Lanternfish の名前が出ていないため、ベクトル検索では上位 12 件にまったく表示されません。project-ouzel からリンクされているため、グラフを 1 ホップたどると 2 位に表示されます。

このホップによってベクトル検索では見つからなかったものが見つかった場合は、スターを付けることで、ノートフォルダーを持つ他の人がこのリポジトリを見つけやすくなります。sgm-ask --ab は、マシンごとに一度だけ、ターミナル内で同じ質問をします。SGM_NO_STAR_PROMPT=1 で無効にできます。

これが 1 回のクエリで実現することですが、常に効果があるわけではありません。この同じ保管庫では、全体としてベクトルのみの検索のほうがグラフモードより上位にランク付けされます。数値は bench/ にあります。--ab を使えば、手持ちのノートでどちらが優れているかを測定できます。

あらゆる MCP クライアントから利用できます（Claude Desktop、Cursor、Zed、Windsurf）：上記のインストール後に sgm-mcp を実行するか、uvx --with 'sqlite-graph-memory[embeddings]' sqlite-graph-memory を使ってください。BRAIN_INDEX_DIR に、sgm-index が作成した index フォルダーを設定します。設定例： examples/mcp-config.json。Claude Code： claude mcp add sqlite-graph-memory -e BRAIN_INDEX_DIR=/path/to/index -- sgm-mcp。 Codex：~/.codex/config.toml に [mcp_servers.sqlite-graph-memory] テーブルを作成し、command = "sgm-mcp" を設定します。最初にファイルを読むエージェント向けの情報： llms.txt。

これは何か

AI エージェント向けの SQLite ベースの Graph RAG です。フレームワークではなく、実用段階のパイロットです。個人用の「セカンドブレイン」エージェント環境から切り出したメモリレイヤーです。ベクトル検索でエントリーポイントを見つけ、手作業で書いた [[wikilinks]] をグラフとして使い、クロスエンコーダーでホップによって取り込まれた項目を再ランク付けします。 データベースは SQLite のみです（schema.sql）。

ステータス：パイロットです。この言葉は重要です。実際の環境（Claude Code で運用する約 10 万件のノートを含む Obsidian 保管庫）で毎日動作していますが、意図的に最小限の構成にしており、汎用化は目指していません。テストカバレッジにばらつきがある点については、意図的に不足させている機能を参照してください。 エージェント向けの軽量 Graph RAG に関する近日公開予定の記事に付随するコードとして公開しています。すでに書かれている設計ノートは docs/bitemporal.md です。

理由

ほとんどの Graph RAG スタックでは、グラフデータベース、ETL パイプライン、エンティティ抽出パスが必要です。 HippoRAG（arXiv:2405.14831）はこの方法で KG を導出し、 Graphiti/Zep は時間軸を持つグラフを維持します。 Markdown ナレッジベースを使う単一ユーザー向けエージェントには、これら3つすべてが過剰です。

• グラフはすでに存在します — Obsidian/Logseq/plain-markdown のユーザーは、[[wikilinks]] としてエッジを手作業でキュレーションしており、brain_ask.py はそれを解析するだけです。 抽出パスは不要で、エッジの品質はモデルが抽出するものより優れています。
• SQLite で十分です — 永続化する価値があるのは、派生状態（ターンごとの台帳）とテレメトリーだけで、どちらも schema.sql で定義されています。 ファイルは1つで、ドライバーは標準ライブラリのものを使い、運用作業はゼロです。
• RAG の品質を高めるうえでコストがかかるのは、グラフインフラではなくリランカーです — brain_ask.py のリランク処理を参照してください。

そのため、このパイロットが賭けるのは、エントリーポイントにはベクトル検索、関連付けには手作業でキュレーションした wikilinks、意外な発見の確かさを保つにはクロスエンコーダー、永続化が必要なものにはすべて SQLite を使うことです。 4つのステップはすべて、brain_ask.py という1つのファイルにこの順で収められています。

アーキテクチャ

3つのレイヤーと、障害を相互に分離した3つのコンポーネントです。

markdown notes (with [[wikilinks]])
        │
        ├── index_notes.py      chunk + embed (e5-base) → .npy/.pkl index
        │
        ├── brain_ask.py        recall pipeline:
        │       1. dense retrieve  top-60 chunks, dedup by file
        │       2. --graph         +1-hop wikilink neighbours of top-15 hits (max 40)
        │       3. rerank          cross-encoder → top-12
        │       4. --ab            run vector-only AND vector+graph, diff,
        │                          log the delta to SQLite (ab_recall)
        │
        └── turnstate_hook.py   agent Stop-hook: after every assistant turn,
                                parse the transcript tail and append one row
                                (ask, summary, files, tools, commands, decisions)
                                to SQLite (turns). 0 LLM tokens, pure stdlib.
                                turnstate_show.py = read-only viewer.

schema.sql では両方のテーブルを説明しています。グラフは SQL には実体化されません。 brain_ask.py はクエリ時にノートからエッジを解析し、1ホップ／隣接ノード40件に制限します。 そのため、保守コストゼロでグラフをノートと常に同期できます。ホップ数やコーパスの規模が必要とする場合にのみ、エッジテーブルを実体化してください。

実際の運用を経て残った設計上の選択

• グラフ展開は候補生成であり、ランキングではありません（brain_ask.py）。隣接ノードはベクトル検索のヒットと同じリランカープールに入るため、関連性の低いリンク先ノートは下位に沈みます。 これにより、1ホップ展開を安全に有効なままにできます。
• エンティティゲート（brain_ask.py の looks_like_entity）。A/B テレメトリーでは、グラフ展開は「エージェントメモリの手法」のようなテーマに関するクエリには有効ですが、「NotebookLM」のような名前／ツールの検索には逆効果だと示されました。名前のカードはあらゆるものにリンクしているため、ホップによってノイズが取り込まれます。 brain_ask.py のヒューリスティックは意図的に保守的で、名前のようなクエリに限ってグラフを無効にします。
• ポリシーとしてのクラッシュセーフティ。 グラフのホップ（brain_ask.py）と Stop フック（turnstate_hook.py）はどちらもラップされているため、何らかの障害が発生しても以前の動作にフォールバックします。つまり、ベクトルのみで想起し、台帳の行は追加しません。 メモリレイヤーによって、メモリレイヤーがない場合よりエージェントの性能が低下してはなりません。
• 思い込みではなく、測定する。 --ab は実際の各クエリで両方のパイプラインを実行し、グラフがトップ N に昇格させたノートの数を schema.sql の ab_recall に記録します。 「連想メモリ」に価値があるかどうかは、印象ではなく週次の SQL クエリで判断します。

意図的に含めていないもの

• エンティティ用の検索レーンはありません。本番環境のセットアップには、人やプロジェクトのカードを対象とする追加の検索レーンがありますが、個人データとの結び付きが強すぎるため公開できません。
• 増分インデックス作成はありません（課題で追跡中）。パッケージ化は v0.3.0 から利用できます（pip install sqlite-graph-memory）。現在は評価スイートもあります — 置き換える前に測定するを参照してください — ただし、wikilink から導出した正解データに基づいて検索を評価するものであり、弱い教師信号であることは明記されています。テストのカバレッジにはばらつきがあります。 index_notes.py、brain_ask.py、mcp_server.py にはユニットテストがありますが、turnstate_hook.py にはありません。ここに文章で書かれた数字を鵜呑みにせず、現在のテスト数は pytest -q を実行して確認してください。以前、このファイルには「テストなし」と書かれていたのに、7件が成功していたのはそのためです。 上記のステータス行でパイロットとしているのは意図的です。

クイックスタート

# Indexing and reranking need the embedding stack; the base install leaves it out
# so that `pip install sqlite-graph-memory` stays small instead of pulling ~2 GB
# of torch. Ask for it explicitly:
pip install 'sqlite-graph-memory[embeddings]'

# 1. index a folder of markdown notes
sgm-index /path/to/notes

# 2. ask, three ways
sgm-ask "how do I think about agent memory"
sgm-ask --graph "how do I think about agent memory"
sgm-ask --ab    "how do I think about agent memory"   # logs the diff to SQLite

# 3. inspect the A/B telemetry
sqlite3 turnstate.db "select ts, query, new_in_top, promoted_via_graph from ab_recall order by id desc limit 10"

どのコマンドも基本インストール環境で実行すると、ModuleNotFoundError を発生させるのではなく、不足している追加パッケージを通知します。この動作は tests/test_optional_extra.py でテストされています。

Claude Code でターンごとの台帳を有効にするには、Stop フックを登録します（正確な設定ブロックは examples/claude-code-stop-hook.json で、sgm-turnstate-hook を呼び出します）。その後、次を実行します。

sgm-turnstate-show --stats

インストールではなく、クローンから作業していますか？ pip install -e '.[embeddings]' を実行すると、同じ4つのコマンドが使えるようになり、モジュールも from sqlite_graph_memory import brain_ask としてインポートできます。

設定は環境変数のみで行い、すべての変数は .env.example に記載されています。初期設定ではすべてカレントディレクトリを使用します。CUDA 対応の torch ビルドがあれば GPU が自動的に使われ、小規模なコーパスなら CPU でも問題なく動作します。

--ab の出力例

おもちゃの4ノートコーパスで --ab を指定した場合の brain_ask.py の出力です（実際の実行では約10万ノートのボルトを使用します）。

A/B RECALL: how should agent memory work
(Direct=4 vector / Associative=+0 graph; Associative promoted 0 new notes into top-12, 0 of them via graph)

--- DIRECT memory (vector) ---
 1. [  4.11] agent-memory
 2. [ -6.50] graph-rag
 3. [ -8.66] sqlite-ledger
 4. [ -9.73] cooking

--- ASSOCIATIVE memory (vector+graph) ---
 1. [  4.11] agent-memory
 2. [ -6.50] graph-rag
 3. [ -8.66] sqlite-ledger
 4. [ -9.73] cooking

これほど小さなコーパスでは、候補プールにすでにすべてのノートが含まれているため、グラフによる追加効果はありません。規模が大きくなると興味深い差が現れます。まさにその証拠を schema.sql の ab_recall テーブルに蓄積しています。

公開ベンチマーク — bench/

次のセクションにある数値はすべて非公開ボルトから得たものなので、研究室の外部にいる人は検証できません。bench/ は再現可能な評価用の環境です。架空の研究室を題材にした自動生成の202ノートのボルト、7クラス91問（答えがボルトに含まれない問題を22問含む）、そしてエージェントのメモリに重要な3つの指標、つまり根拠ノートの recall@k、逐語的な引用、事実が見つからないときの回答保留を用意しています。

python bench/run.py --system bm25          # one command, stdlib only
python bench/validate.py                   # what CI runs on every result file

私たち自身のベースラインはリーダーボードで公開しており、弱点も明記しています。「現在の期限はいつですか」という質問では、両方の決定を検索できています（R@5 1.00）が、6回中6回、置き換えられた決定を引用しています。このボルトでは、ベクトルのみのモードがグラフモードを上回っています（R@5 0.88 対 0.85）。ほかのメモリシステム（mem0、Letta、Khoj、標準的な RAG）も、アダプターファイル1つとプルリクエストで参加できます。bench/CONTRIBUTING.md をご覧ください。CI は提出された数値をすべて質問ごとの出力から再計算するため、手入力した数値をリーダーボードに載せることはできません。

入れ替える前に計測する — eval/

RAG パイプラインへの「明らかな」アップグレードはどれも、仮説にすぎません。新しい埋め込みモデル、より強力な再ランキングモデル、ハイブリッド BM25、別のチャンク分割方法。自分のコーパスで数値を出さずに入れ替えるのは、変更履歴の記録を伴う迷信です。eval/ は私たちが作れる最小限の誠実な評価基準で、ラベル付けの予算も LLM の呼び出しも不要です。すでに書いた Wiki リンクが関連性ラベルになります。

python eval/run_eval.py --selftest                       # metrics only: no model, no index
python eval/build_gold.py /path/to/notes --n-per-class 60   # -> eval/gold-<today>.jsonl (freeze it)
python eval/run_eval.py --gold eval/gold-<today>.jsonl --sqlite

4つの質問クラスがあり、それぞれパイプラインの異なる部分を検証します。title（ノートのタイトルでそのノート自体が見つかること）、body（最初の段落でそのノート自体が見つかること）、bridge（最初の段落から [[links]] 先のノートが見つかること。これがグラフの目的です）、temporal（古いノートのタイトルから、superseded_by: "[[newer-note]]" というフロントマターのフィールドを介して、その置き換え先が見つかること）です。すべての質問をベクトルのみとベクトル＋グラフの両方のモードで評価するため、「グラフは役に立つか？」という問いが好みの問題ではなくなります。

run_eval.py は brain_ask.py をインポートし、エージェントが呼び出すものと同じ関数、つまり load_index、retrieve_candidates、expand_1hop、rerank_candidates を呼び出すため、計測対象は実際に実行されるものです。パイプラインを再実装する評価では、再実装されたものが計測されます。--sqlite を指定すると、クラスとモードごとに1行ずつ gold_eval テーブルに追加されます。これにより、6週間後の実行結果を今日の結果と比較できます。

判明するまでにかかったコスト

ホームボルト（約24kチャンク、RU+EN、2026-09-16）の数値です。固定したゴールドセット184問（タイトル60問／本文60問／橋渡し60問／時間的質問4問）、ベクトル＋グラフモード：

タイトルと時間的質問のnDCG値は修正済みです。この修正こそ、このページで最も有益な情報です。このモジュールを検証した外部レビュー委員会は、ランキングに同じファイル名が2回出現すると、ndcg_atがゴールドノートに二重の評価を与えていることを発見しました。wikilinkはファイル名でノートを参照するため、2つのフォルダーにfoo.mdがあるとこの問題が起きます。すぐに再現できました。ndcg_at(['foo','foo'], ['foo'])は1.63を返しました。これは、この指標の最大値を超えています。184問中4問に影響し、タイトルのnDCGを0.031、時間的質問のnDCGを0.108押し上げていました。Recall@12とMRRには影響していません（前者は集合ベースで、後者は最初のヒットで停止するためです）。また、同じ4問が両方の実行結果を押し上げていたため、変更前後の差はすべて小数点以下4桁まで維持されました。タイトルの+0.0056は+0.0055になりました。したがって、以下のマージと差し戻しの判断は変わりません。しかし、報告していたはずの絶対値は誤っていました。そして、誰も厳しく検証しない評価は、いつまでもお行儀よく間違ったままです。

その判断につながった変更は2つです。重複したスナップショットのコピーをインデックスから取り除いた変更（27 095 -> 24 216チャンク）では、指標は0.0000だけ動きました。数値上の改善はありませんが、古いコピーが検索枠を占有するのを防げます。数値がゼロだったからこそ、これは正確に把握しておく価値があります。実際に数値を改善した変更では、候補集合ではなく並べ替えにグラフの票を反映しました。wikilinkグラフ上のパーソナライズドPageRankをRRFで再ランキングモデルと融合し、再ランキングモデルの上位5つの位置は保護しました。原因は推測ではなく測定によって判明しました。正解したbridgeの回答の97%は、すでに候補プールに含まれていたのに、クロスエンコーダーがそれらを落としていました。関係性がテキスト上のものではなく、構造上のものだったためです。明白な解決策に見える検索範囲の拡大では、まったく効果がなかったでしょう。

ほかの7つの変更は、事前に定めた次のルールに基づき、同じ基準で却下しました。いずれかのクラスでnDCG@12が0.01を超えて悪化したら、その変更を差し戻します。

これらの判定は、モデルについての主張ではありません。このコーパスをこの基準で測った場合についての主張です。入れ替えを判断するうえで必要なのは、こうした主張だけです。そして、このモジュールをブログ記事ではなくここに掲載しているのは、皆さんのコーパスは私たちのものとは異なる結果になるからです。

この評価で分からないこと

ウィキリンクによる正解ラベルは弱い教師信号です。リンク先の隣接ノートが、必ずしも質問に答えるノートとは限りません。bridge はリンクから構築されるため、リンクをたどる手法はどれもそこで有利になります。測定しているのは「パイプラインがつながりをたどれるか」であって、「正しいつながりか」ではありません。1回の実行で採点するのは、あるインデックスのあるバージョンだけです。また、2回の実行の間に正解セットを再構築すると、2つの数値は比較できなくなります。これは評価がひそかに嘘をつき始める典型的なケースです。60問では、nDCGの±0.02の差はノイズの範囲内です。これは、同じパイプラインの2つの候補版を凍結して比較したところ、184問中33問で結果が食い違ったことから分かりました。

指標は意図的に壊すことができます。EVAL_MUTANT=1を設定すると、nDCGはすべてのケースで完璧な1.000を返すようになり、その状態でpytest tests/test_eval.pyを実行すると必ず失敗しなければなりません。指標が壊れていてもテストが成功するなら、そのテストスイートは指標をテストしていません。

ロードマップ

現在 — 最新リリース（2026-10-19時点でPyPIとMCP Registryにおけるv0.3.1）。 日々稼働しているパイロットには、検索パイプライン、ターンごとの台帳とA/Bテレメトリが含まれ、これらはすべてbrain_ask.pyとturnstate_hook.pyにあります。また、双時間設計ノートも含まれています。既知の不具合はここで脚注に記すのではなく、トラッカーで管理しています。このファイルでは意図的にイシュー番号を挙げていません。イシューはクローズされても、その周辺の説明文は気づかずに残り、そのずれこそが以前この段落に二度もあった不具合だからです。

次の予定：

• 公開ベンチマークとしてbench/（bench-v0.1）が公開されました。合成の202ノートのVault、91問、ほかのシステムも参加できるリーダーボード、そして数値を再現するCIが用意されています。まだ不足しているのは、完全なアブレーションマトリクス（ホップ数 × シード上限 × 隣接ノート上限 × 再ランキング対象プール × ゲーティングポリシー）です。bench/には最初の2つの条件、0ホップと1ホップが含まれています。重要な問いは「グラフが役に立つか」ではなく、どのクエリクラスで役に立つかでした。eval/では直感ではなく、クラスごとに答えを示します。
• 双時間エッジ — 設計ノートはdocs/bitemporal.mdです。クエリ時にグラフを解析するのではなく実体化する場合は、各エッジに有効期間（valid_from / valid_to / observed_at）を設けます。そうすれば、再構築時に古くなった事実を削除するのではなく終了させることができ、履歴を保持しながら現在の情報を優先して検索でき、as_ofクエリで過去を再構築できます。信頼度の減衰による、破壊的でない経年処理です。1日目のA/Bテスト結果（コンテキストサイズはほぼ変わらず、検索された候補は平均経過時間で約60%新しい）は、注意事項とともにdocs/bitemporal.mdにまとめています。データ量の利点は長期的に現れるため、これは1つのコーパスでの1日分の結果であり、ベンチマークではありません。
• パターンに関する解説記事（「グラフ抽出を使わないGraph RAG」）を執筆中です。

目立った変更はすべて新しいリリースとして公開されるため、「パイロット」という言葉が適切でなくなったかどうかは、コミットグラフではなくリリースフィードで確認できます。

モデル

• 埋め込み：intfloat/multilingual-e5-base（多言語対応。ホームコーパスはRU+ENです）
• 再ランカー：cross-encoder/mmarco-mMiniLMv2-L12-H384-v1

どちらもbrain_ask.pyの定数（E5_MODEL、RERANK_MODEL）として設定されており、ノートPCのGPUで動かせるほど軽量です。パイプラインはこれら特定のモデルに依存していないため、自由に差し替えられます。

メンテナー

• Anton Dziatkovskii（@tonydzi）：検索パイプライン、台帳、ベンチマーク、リリースを担当します。
• Vardhman Gupta（@Kaap10）：MCP サーバー（sgm-mcp、PR #8、#10、#14）とそのテストを担当します。mcp_server.pyに関するレビューはCODEOWNERSを通じて同氏に割り当てられます。

AI コントリビューター

このプロジェクトは人間とAIのチームで開発されており、そのことはgitログにも記録されています。コードの大半はClaudeが書き、CodexとGrokがレビューし、Geminiが調査結果を提供しています。 各AIの名前がコミットに記載されるのは、その出力によってコミットの内容が変わった場合に限られます。飾りのクレジットはありません。ラボ全体で適用され、すべてのリポジトリに共通するポリシーはこちらです： AI-CONTRIBUTORS.md。

この研究の引用

このシステムに関する論文（検索設計、パイロット運用のテレメトリ、クエリクラス別の層化評価プロトコル）が公開されています：DOI 10.5281/zenodo.22639718（プレプリント、CC BY 4.0）。機械可読な引用情報はこちらです：CITATION.cff（GitHubの「このリポジトリを引用」ボタン）。学術上の氏名：Anton DzyatkovskyはAnton Dziatkovskii名義で論文を発表しています（ORCID 0000-0001-7408-3054）。

ライセンス

MIT

お問い合わせ

ご質問、実体験の共有、またはご自身のマシン群での運用をご希望の場合：

• 👤 作者：Anton Dziatkovskii — Telegram @tonydzi · WhatsApp +1 341 222 9178 · X @Tony_Stef_
• 📣 チャンネル： @ClawRus（RU） · @ClawEng（EN）
• 🌐 palo-alto.ai · Palo Alto AI Research Lab
• 🧪 エンジニアの皆さん、この環境を試してみませんか？ ご連絡ください。テストして結果を報告してくださるエンジニアに、無料のスターターシードをお渡ししています。

コントリビューターを歓迎します — ただし順番待ちがあります

accepted ラベルが付いたIssueは範囲が明確で、自由に取り組めます。まだ担当者はいません。「claiming this」とコメントしてください。許可は不要です — 7日間、あなたの担当になります。初めての方は、 good first issueから始めてください。

ご自身のコードの著作権はそのまま保持できます。 CLAも権利譲渡も一切ありません。あなたのコントリビューションは、このリポジトリの既存ライセンスのもと、私たちと同じ条件で取り込まれます。すべてのIssueとPRに48時間以内に回答します。「いいえ。その理由はこちら」という回答も含みます。返事がない場合は私たちの不備ですので、スレッドに再度ご連絡ください。

詳細はこちら：CONTRIBUTING.md

🧩 稼働中のシステムを構成する一つの要素

このリポジトリは、実運用中の仕組みから切り出された一つの要素です。Claudeを実装パートナーとして構築したマシン群を一人のエンジニアが運用し、各マシンは互いに合意形成を行い、金銭や取り返しのつかない事柄があるときだけ人間を呼び起こします。デモとして書かれたものではなく、本番環境で稼働した後に切り出されました。また、単独でも動作し、ここから他の要素へ情報を送信することはありません。

システム全体の構成を見る → SYSTEM.md

メモリ層で最も近い関連プロジェクト：second-brain-starter-kit · voice2brain

AI と一緒に読む

ワンクリックでエージェントがリポジトリを読み込み、パターンを抽出して、自分の作業に応用するのを支援します。

Read this repo: https://github.com/tonydzi/sqlite-graph-memory (“sqlite-graph-memory” - Graph RAG on SQLite for AI agents: vector retrieval + hand-curated wikilink graph + cross-encoder rerank, with a zero-token per-turn memory ledger. Working pilot). Work out what problem it actually solves, pull out the reusable patterns and help me apply them to my own setup. Start by asking what I am working on.

_{— TonyDzi、Palo Alto AI Research Lab · セカンドブレイン、エージェント連携、永続メモリ：github.com/tonydzi}