Zikkaron について
Zikkaron は Claude Code 向けの永続メモリエンジンで、計算神経科学のアルゴリズムに基づき、決定事項やデバッグの経緯、プロジェクトの文脈をセッションをまたいで保持します。すべてローカルマシンで動作し、データは単一の SQLite ファイルに保存されます。長期間にわたるプロジェクトを継続する開発者に向いています。
主な機能
- 01自動統合による永続メモリ
- 02コンパクション前後のチェックポイントと復元
- 03決定事項の自動保護と事実のアンカー設定
- 04基礎メモリを生成するプロジェクトシード機能
- 05クエリ時に LLM を使わないローカル SQLite ストレージ
活用シーン
- 01Claude Code のセッションをまたぐアーキテクチャ決定の引き継ぎ
- 02長いセッションのコンパクション後も重要な文脈を保持
- 03既存のコードベースでプロジェクトメモリを素早く構築
MCP 対応
Zikkaron は MCP サーバーとして、recall、remember、get_project_context、anchor などの MCP ツール 24 種を Claude Code に公開し、メモリの保存と取得を行います。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。
詳細
Zikkaron
Zikkaron(זיכרון)はヘブライ語で「記憶」を意味します。
AI はタブを閉じるたびにあなたのことを忘れてしまいます。説明したアーキテクチャ上の決定も、一緒に深掘りしたデバッグの迷路も、「SQLite ではなく Postgres を使っていることを忘れないで」という訂正も、すべて消えてしまいます。次のセッションでは、自分のツールにとってあなたは見知らぬ人です。
Zikkaron は、計算論的神経科学に基づく Claude Code 用の永続メモリエンジンです。取り組んだこと、考え方、決めたこと、そしてその理由を記憶します。コンテキストに押し込むだけの単純なテキストダンプではなく、記憶を統合し、適切に忘れ、適切なタイミングで適切なコンテキストを再構築する、生きた記憶システムです。
26 個のサブシステム。24 個の MCP ツール。すべてローカルマシン上で動作します。SQLite ファイルは 1 つです。
もう同じことを繰り返さなくてよくなるまで、たった 2 分
pip install zikkaron
Claude Code の設定に追加します。
{
"mcpServers": {
"zikkaron": {
"command": "zikkaron"
}
}
}
使い方を Claude に伝えます。グローバルな ~/.claude/CLAUDE.md(プロジェクトごとの設定ではなく、ホームディレクトリにあるもの)に、次の内容を追加します。
## Memory
- On every new session, call `recall` with the current project name
- Before starting any task, call `get_project_context` for the current directory
- After completing significant work, call `remember` to store decisions and outcomes
または、Zikkaron に任せることもできます。起動するたびに、sync_instructions を通じて最新の手順を ~/.claude/CLAUDE.md に自動で同期します。一度設定すれば、あとは気にする必要はありません。
実際に使うと、こんな感覚です
月曜日。 厄介な認証トークンの競合状態のデバッグに 1 時間かけます。Claude は、Redis と JWT の設定との間にある TTL の不一致まで原因を追跡するのを手伝います。問題を修正すると、Claude はその記憶を保存します。
木曜日。 ユーザーから、時々ログアウトされるという報告があります。同じプロジェクトで Claude Code を開きます。バグについて説明する前に、Claude は月曜日に行った Redis の TTL 修正を思い出し、関連があるかを確認して、追加したミドルウェアがセッション中に Redis が再起動した場合のエッジケースに対応できているかを尋ねます。
それが違いです。「会話履歴はこちらです」というものではありません。本当の想起です。前回入力した言葉だけではなく、構築してきたものの全体像をツールが理解している、ということです。
本当に機能する検索
Zikkaron を、長い会話の記憶に関する標準ベンチマークである LoCoMo(Maharana ほか、ACL 2024)でテストしました。会話 10 件、質問 1,986 件。単純な事実検索から、複数の段階をたどる推論、さらには回答を誤らせるように設計された敵対的なひっかけ問題までを網羅しています。
| Zikkaron | 意味 | |
|---|---|---|
| Recall@10 | 86.8% | 正しい記憶が、10 回中ほぼ 9 回、上位 10 件に表示されます |
| MRR | 0.708 | 正解は通常、1 番目か 2 番目の結果です |
| Single-hop MRR | 0.757 | 事実に関する質問では、ほぼ毎回一度で正解します |
| Temporal MRR | 0.712 | 「X はいつ起きましたか?」という質問に対して、時間をしっかり把握します |
重要なのは、検索時に LLM が動作していないことです。API 呼び出しもありません。数十億のパラメーターを持つモデルもありません。22MB の埋め込みモデル、SQLite ファイル、そして処理を担う一連の神経科学アルゴリズムだけです。このような数値を達成するシステムの多くは、処理に GPT-4 を必要とします。Zikkaron は、ホップフィールドエネルギースコアリング、拡散活性化、クロスエンコーダーによる再ランキングによって、同等の結果を実現します。
BEAM:1,000 万トークンの会話を扱う、単一のメモリシステム
BEAM(Tavakoli et al., ICLR 2026)は、現存する最も難易度の高い長期記憶ベンチマークです。各会話が1,000万トークンに及ぶ10件の会話を対象とし、10種類の記憶能力を測る200問の質問で構成されています。そのうち、矛盾の解決、イベントの順序付け、指示への従順性という3つの能力は、これまでのベンチマークではテストされていません。
論文で評価されたすべてのシステムが、この規模では性能を大きく落とします。報告された最高スコア(Llama-4-Maverickで動作するLIGHTフレームワーク)でも0.266です。1,000万トークンでは、ほとんどの能力がほぼゼロにまで低下します。コンテキストウィンドウを使う手法では収まりきらず、RAGの手法ではノイズに埋もれてしまいます。
Zikkaronは総合スコア0.404を達成し、ICLR 2026の論文で報告された最高スコアを52%上回ります。
| 能力 | Zikkaron | LIGHT(最高) | 結果 |
|---|---|---|---|
| 指示への従順性 | 0.750 | 0.500 | +50%。検索が不完全でもClaude Opusは適切に読み取ります |
| 情報抽出 | 0.650 | 0.375 | +73%。1万件の記憶から具体的な事実を検索します |
| 知識の更新 | 0.650 | 0.375 | +73%。熱減衰によって、事実の最新バージョンが浮かび上がります |
| 好みへの対応 | 0.642 | 0.483 | +33%。セッションをまたいでユーザーの好みを追跡します |
| 棄権 | 0.450 | 0.750 | スクラッチパッドなしで、自分が知らないことを把握するのは困難です |
| 要約 | 0.216 | 0.277 | 要約には、多数のソースパッセージを一度に扱う必要があります |
| 複数セッションの推論 | 0.195 | 0.135 | +44%。離れたターン間の証拠を結び付けます |
| 時間的推論 | 0.175 | 0.075 | +133%。Yに対してXはいつ起きたのか? |
| 矛盾の解決 | 0.163 | 0.050 | +226%。数千ターン離れた発言の矛盾を検出します |
| イベントの順序付け | 0.150 | 0.266 | 検索でイベントは見つかりますが、時系列に並べるのは困難です |
| 総合 | 0.404 | 0.266 | +52% |
10種類の能力のうち7種類で、公開済みの最高性能を上回りました。特に大きく向上したのは、構造化メモリが最も効果を発揮するはずの能力です。矛盾の解決(+226%)、時間的推論(+133%)、知識の更新(+73%)です。論文中のすべてのシステムがこれらの能力でほぼゼロのスコアとなるのは、コンテキストウィンドウを使う手法には、事実の変化やイベントの発生時期を追跡する仕組みがないためです。Zikkaronでは、熱力学的減衰、再固定化、時間メタデータによって、これらを標準で扱えます。
LIGHTが上回る3つの能力(棄権、イベントの順序付け、要約)は、実際の限界を示しています。棄権には情報が存在しないと認識する必要があり、話し合った内容を明示的に記録するLIGHTのスクラッチパッドが役立ちます。イベントの順序付けには、適切なイベントを検索するだけでなく、完璧な時系列で並べる必要があります。要約には多数のソースパッセージを同時に検索する必要がありますが、私たちの検索予算では、関連コンテンツの一部しかカバーできません。
重要な留意点として、BEAM論文のベースラインでは、読み取りモデルにGPT-4.1-nanoを使用しています。私たちは、これより大幅に高性能なClaude Opus 4.6を使用しています。検索MRRがわずか0.086であるにもかかわらず、指示への従順性で0.750を達成した結果は、検索品質とは別に読み取りモデルの品質もQAスコアに寄与することを示しています。私たちの検索指標(MRR 0.422、Recall@10 0.353)はモデルに依存せず、論文のベースラインと直接比較できます。
ベンチマークの設定:BEAM-10Mスプリット、会話10件、質問200問、論文のRAGモードに合わせたペアチャンクの取り込み、論文の評価コードに合わせたint()キャストによるルーブリックごとの二値ナゲットスコアリング、イベント順序付けにはscipyによるKendall tau-b、会話ごとに新規データベースを使用。
海馬リプレイ:圧縮後も残るコンテキスト
あまり語られない問題があります。Claude Code のコンテキストウィンドウは 200k/1M トークンです。長時間のセッションでウィンドウがいっぱいになると、コンテキストは 圧縮 されます。古いメッセージが要約され、ツールの出力が削除され、指示が言い換えられます。重要なニュアンスが失われ、会話の早い段階で定めた決定が曖昧な要約へと溶け込んでしまいます。
Hippocampal Replay はこの問題を解決します。睡眠中に重要な経験を脳が再生し、長期記憶として定着させる神経科学の現象にちなんで名付けられたこの機能では、コンテキストの圧縮を「睡眠」と捉え、Claude が「目覚めた」ときに重要な情報を再生します。
仕組み:
圧縮が始まる前に、フックが実行されます。Zikkaron は作業中の内容、開いていたファイル、決定した内容、未解決のエラーなど、アクティブなコンテキストをすべて取り込みます。これらはすべてチェックポイントとして保存されます。
圧縮後には、2 つ目のフックが実行されます。Zikkaron はコンテキストをインテリジェントに再構築します。すべてをそのまま戻すのではなく、最新のチェックポイント、重要として固定した事実、関連性の高いプロジェクトの記憶、使用パターンに基づく次に必要になりそうな情報など、適切な要素を組み合わせます。
重要な情報を明示的に指定することもできます。
Tool: anchor
content: "We're using the event-sourcing pattern. All state changes go through the event bus."
reason: "Architecture constraint"
固定した記憶は最大限に保護されます。どのような場合でも、圧縮後に必ず残ります。
プロジェクトごとの初回セットアップ:
Tool: install_hooks
project_directory: "/path/to/your/project"
その後はすべて自動で行われます。意識する必要も、手動で呼び出す必要もありません。フックが実行され、コンテキストが取り込まれ、復元されます。長時間のセッションも、ただ……問題なく続けられます。
ゼロギャップメモリ(v1.3.0)
以前のバージョンには、まだギャップがありました。1 時間かけて少しずつ作業を進めても、小さな進捗は直前の内容と比べて「意外性がない」と判断され、Zikkaron の書き込みゲートによって半分がブロックされていました。重要なアーキテクチャ上の決定をしても、徐々に要点だけの概要へと薄れていきました。新しいセッションに戻っても、Claude は直前に何をしていたのかまったくわかりませんでした。
v1.3.0 では、これらすべてが解決されています。
適応型書き込みゲート。 システムは保存した直近 10 件の記憶を追跡するようになりました。同じディレクトリ、同じ時間帯、類似した内容などから同じタスクに取り組んでいることが明らかな場合は、意外性のしきい値を下げ、小さな進捗も記録されるようにします。ゲートは引き続きノイズをブロックします。ただし、作業内容までブロックすることはなくなります。
決定事項の自動保護。 「Memcached ではなく Redis を使うことにした」や「CRUD ではなくイベントソーシングパターンを選んだ」といった発言をすると、Zikkaron は決定パターンを検出し、自動的に保護対象としてマークします。保護された記憶は圧縮されず、急速に劣化することもありません。決定事項はセッションを越えて残ります。
アクションの自動記録。 Claude がツールを呼び出すたびに、PostToolUse フックが実行されます。ファイルの編集、bash コマンド、検索など、すべてが軽量なアクションログに記録されます。統合デーモンがこれらを定期的に処理し、実際の記憶に変換します。日常的な作業で remember を呼び出す必要はありません。システムが自動で把握します。
セッションコンテキストの注入。 新しいセッションが始まるたびに SessionStart フックが実行され、ホットメモリ、固定した事実、最近のアクション、最後のチェックポイントなど、プロジェクトのコンテキストを Claude のコンテキストウィンドウに直接注入します。Claude は、何をしていたかを把握した状態で毎回のセッションを開始します。
マイクロチェックポイント。 これまではツールを 50 回呼び出すごとにチェックポイントを作成していましたが、現在はエラーの発生、決定事項、高い意外性を持つ情報など、重要なイベントが起きた際に自動でチェックポイントを作成します。重要な状態の変化を、発生した瞬間に記録します。
セッションの一貫性。 過去 4 時間以内に作成された記憶には、時間とともに直線的に減少するヒートボーナスが付きます。「10 分前に伝えたばかりなのに」という問題は、もう起きません。
すべてのフックは stdio と HTTP の両方のトランスポートモードで動作します。SQLite データベースに直接アクセスするため、サーバーとの通信は不要です。
プロジェクトのシード:コールドスタートを解決
Zikkaron は、セッションを重ねながら自然に記憶を構築します。継続的な作業には最適ですが、1年間取り組んできたコードベースにインストールする場合はどうでしょうか。Claude がプロジェクトを十分に把握するまで、何十回もセッションを重ねることになります。そのころには、すでに同じことを50回も繰り返し説明しているでしょう。
seed_project がこれを解決します。1回呼び出すだけで、Zikkaron がプロジェクト全体をスキャンし、構成、設定ファイル、ドキュメント、CI/CD、エントリーポイント、コンポーネントごとの概要から、基盤となる記憶を作成します。次のセッションでは、Claude はプロジェクトの内容、使用技術、構成をすでに把握した状態で開始できます。
# CLI
zikkaron seed /path/to/your/project
# Preview without storing
zikkaron seed /path/to/your/project --dry-run
または、Claude Code 内から MCP ツールとして呼び出すこともできます。
Tool: seed_project
directory: "/path/to/your/project"
抽出される情報:
- プロジェクト概要 — 名前、技術スタック、ファイル数、ディレクトリツリー
- 設定ファイル —
package.json、pyproject.toml、Cargo.toml、go.modなど、15種類以上。正しく解析されます(TOML はtomllib、JSON はjsonを使用)。正規表現でのスクレイピングは行いません。依存関係、スクリプト、ワークスペース、ビルドバックエンドなどをすべて抽出します。 - ドキュメント — README、ARCHITECTURE、CONTRIBUTING、CLAUDE.md、CHANGELOG
- CI/CD — GitHub Actions、GitLab CI、Jenkins、Travis、Azure Pipelines
- エントリーポイント —
main.*、index.*、app.*、server.*、__main__.py - コンポーネントごとの概要 — モノレポに対応しています。トップレベルのディレクトリだけでなく、ネストされた設定ファイル(
packages/web/package.json、services/api/Cargo.tomlなど)を探して、サブプロジェクトの境界を検出します。
再実行を想定した設計です。 シードを再実行すると、以前のシード記憶に追記するのではなく、きれいに置き換えます。プロジェクトが進化したらシードをやり直すことで、記憶に現在の状態が反映されます。すべてのシード記憶には、識別用の _seed タグが付けられます。
重要度の差別化。 シードされた記憶はすべて同じではありません。プロジェクト概要やドキュメントは、コンポーネントのファイル一覧(0.5)より高い値(0.85~0.9)で開始します。Claude は重要な情報を優先して提示します。
LongMemEval
チャットアシスタントの長期的な対話メモリを評価する現在の標準ベンチマークであるLongMemEval(Wu et al., ICLR 2025)を全件実施しました。6つのカテゴリにわたる、人手で作成された500件の質問を、それぞれ約40セッション分の会話履歴(約115kトークン)に埋め込んでいます。このベンチマークでは、LoCoMoでは評価されない能力、つまりアシスタントが何を言ったか(ユーザーの発言だけでなく)を思い出せるか、情報が時間とともに変化したときに追跡できるか、何がわからないかを把握できるか、数週間離れたセッション間で推論できるかをテストします。
| Zikkaron | 意味 | |
|---|---|---|
| Recall@10 | 96.7% | ほぼすべての質問で、適切なメモリが上位10件の結果に表示されます |
| MRR | 0.945 | 正解がほぼ常に返される最初の結果になります |
| 知識更新 MRR | 1.000 | ユーザー情報が変わると、Zikkaron は常に最新バージョンを最初に表示します |
論文で報告された最高の検索性能は、このデータセットで Recall@10 が78.4%でした。Zikkaron は、検索ループにLLMを一切使用せずに96.7%を達成しています。
カテゴリ別の検索性能:
| カテゴリ | MRR | Recall@10 |
|---|---|---|
| 単一セッション(ユーザー) | 0.973 | 1.000 |
| 単一セッション(アシスタント) | 0.964 | 0.964 |
| 単一セッション(好み) | 0.810 | 0.967 |
| 複数セッションの推論 | 0.966 | 0.958 |
| 時間的推論 | 0.902 | 0.955 |
| 知識の更新 | 1.000 | 0.979 |
知識の更新でMRRが満点だったのは、熱に基づく減衰によって、同じ事実の古いバージョンよりも新しい情報が自然に上位に表示されるためです。これはベンチマーク向けに設計したものではありません。熱力学モデルがそのように機能するだけです。
時間的推論は最も難しいカテゴリであり、MRRは最も低い0.902でした。それでも、適切なメモリは通常、上位2件の結果に含まれます。「Xに参加したのは何週間前か」のような質問では、セッションのタイムスタンプとの照合が必要です。埋め込みベースの検索では、メモリの内容に時間メタデータを直接埋め込むことで対応しています。
Claudeを読み手と判定者の両方に用いたQA評価全体では、総合正解率は75.6%でした。特に知識の更新(85.9%)とアシスタントの発言の想起(94.6%)で高い性能を示しました。複数セッションの推論(54.9%)が主な課題ですが、これは検索ではなく、読み手による情報の統合に関する問題です。複数セッションに関する質問では、95.8%の割合で適切なセッションを検索できています。読み手は、それらをまたいで情報を結び付けるために、さらに作業を行う必要があります。
ベンチマークの設定:LongMemEval_S バリアント、ラウンド単位のメモリ分解、質問ごとに新しいデータベースを使用し、500件の質問をエンドツーエンドで評価。
内部の仕組みを支える科学
Zikkaron は、データベースが行を保存するように記憶を保存するわけではありません。脳が経験を扱うのに近い方法で記憶を扱います。
記憶には温度があります。 すべての記憶は最初は熱い状態です。アクセスし続ければ、熱いまま保たれます。アクセスしなければ、冷えていきます。しきい値を下回ると、圧縮されます。まず要旨になり、次にタグになり、やがて完全に薄れていきます。これはバグではありません。脳が何を残す価値があるか判断するときに使うのと同じ数学的枠組みに基づく、レート歪み最適な忘却です。重要な記憶は圧縮されにくく、意外性のある記憶は温度が上がります。退屈で重複した記憶は、静かに消えていきます。
保存にはゲートキーパーがいます。 すべての情報に記憶される価値があるわけではありません。Zikkaron は、すでに知っている内容を予測するモデルを維持し、その予測に反する情報だけを保存します。同じことを2回伝えても、書き込みゲートが2回目の試みをブロックします。これは予測符号化です。大脳新皮質が感覚入力をフィルタリングするのと同じ仕組みです。予測誤差だけが通過します。
想起によって記憶は変化します。 新しいコンテキストで記憶を想起すると、ただ受動的に返すだけではありません。想起時のコンテキストを保存時のコンテキストと比較し、十分な不一致があれば、記憶を再固定化して、現在の事実を反映するように更新します。不一致が深刻な場合は、古いバージョンをアーカイブし、新しいバージョンを作成します。これは実際の神経科学に基づいています。Nader らは2000年に、想起された記憶は不安定化し、書き換えられる可能性があることを示しました。コードベースが進化するように、Zikkaron のコードベースに関する記憶も進化します。
記憶は限られた領域を奪い合います。 エングラムスロットのプールがあり、各スロットには興奮性スコアがあります。このスコアは使用時に急上昇し、時間とともに低下します。新しい記憶が到着すると、最も興奮性の高いスロットに割り当てられます。同じスロットにある記憶は時間的に結び付けられ、内容に共通点がなくても、関連する経験の連鎖を作り出します。これは、CREB 依存性の興奮性を通じて実際のニューロンがエングラムを割り当てる仕組みをモデル化したものです。
バックグラウンドでの固定化は睡眠のように行われます。 アイドル状態になると、アストロサイトのデーモンが起動し、最近の経験を処理します。エンティティと関係を抽出し、ナレッジグラフを構築し、類似した重複を統合し、因果関係の連鎖を発見し、ランダムな記憶のペアを比較して新たなつながりを見つける「夢のリプレイ」を実行します。4つのドメイン特化プロセスが、コード構造、アーキテクチャ上の決定、エラーパターン、依存関係という異なる種類の知識を、それぞれ異なる速度で処理します。
認知マップがすべてを整理します。 後続表現によって概念空間の2Dマップが構築されます。このマップでは、内容がまったく異なっていても、似たコンテキストでアクセスされる記憶が集まります。デバッグの記憶はほかのデバッグの記憶の近くに集まり、アーキテクチャ上の決定も互いに集まります。このマップをたどれば、キーワード検索では決して見つからない関連知識を発見できます。
24 個すべてのツール
| ツール | 目的 |
|---|---|
remember | 予測符号化の書き込みゲートを通じてメモリを保存する |
recall | 熱度を重み付けしたランキングによる複数シグナル検索 |
forget | メモリを削除する |
validate_memory | 現在のファイル状態と照合して古さを確認する |
get_project_context | ディレクトリのホットメモリを取得する |
consolidate_now | 統合サイクルを強制的に実行する |
memory_stats | すべてのサブシステムにわたるシステム統計 |
rate_memory | メタメモリ追跡のための有用性フィードバック |
recall_hierarchical | 指定した抽象化レベルでフラクタル階層にクエリする |
drill_down | メモリクラスターを詳しく調べる |
create_trigger | 一致するコンテキストで発動する未来志向のトリガーを設定する |
get_project_story | プロジェクトの自伝的な物語 |
add_rule | フィルタリングと再ランキングのための神経記号的制約 |
get_rules | 有効なルールの一覧を取得する |
navigate_memory | 後続表現を介して概念空間をたどる |
get_causal_chain | エンティティの因果的な祖先と子孫 |
assess_coverage | ギャップを特定しながらナレッジの網羅性を評価する |
detect_gaps | 孤立したエンティティ、古くなった領域、欠落したつながりを見つける |
checkpoint | コンパクションからの復旧に備えて作業状態のスナップショットを作成する |
restore | 海馬リプレイを介してコンパクション後のコンテキストを再構築する |
anchor | 重要な事実をコンパクションの影響を受けないようにマークする |
install_hooks | 自動キャプチャ、コンテキスト注入、コンパクション復旧フックを有効にする |
sync_instructions | 最新のZikkaronの機能でCLAUDE.mdを更新する |
seed_project | 1回のスキャンで既存プロジェクトのメモリを初期設定する |
アーキテクチャ
すべてローカルで動作します。WAL モード、FTS5 全文検索、近似最近傍ベクトル検索用の sqlite-vec を備えた単一の SQLite データベースを使用します。
5 つのレイヤーに整理された 26 個のサブシステム:
コアストレージと検索
| モジュール | 役割 |
|---|---|
storage.py | SQLite WAL エンジン、16 個のテーブル、FTS5 インデックス、sqlite-vec ANN 検索 |
embeddings.py | Sentence-transformer によるエンコード(all-MiniLM-L6-v2)、バッチ処理 |
retrieval.py | 4 つのシグナルの融合:ベクトル類似度、FTS5 BM25、ナレッジグラフ PPR、拡散活性化 |
models.py | 型階層全体を表す Pydantic データモデル |
config.py | ZIKKARON_ プレフィックスを使用した環境変数ベースの設定 |
記憶の動態
| モジュール | 役割 |
|---|---|
thermodynamics.py | 熱、驚き、重要度、感情価、時間経過による減衰 |
reconsolidation.py | Nader et al.(2000)に基づく 3 つの結果を伴う不安定化した検索 |
predictive_coding.py | 予測誤差を通じて冗長性を除外する書き込みゲート |
engram.py | CREB に似た興奮性による競合的なスロット割り当て |
compression.py | 3 つの圧縮レベルによる、レート・歪み最適化に基づく忘却 |
staleness.py | SHA-256 ハッシュ比較によるファイル変更監視 |
統合と整理
| モジュール | 役割 |
|---|---|
consolidation.py | 定期的な統合を行うバックグラウンドのアストロサイトデーモン |
astrocyte_pool.py | コード、意思決定、エラー、依存関係に特化したワーカープロセス |
sleep_compute.py | 夢の再生、Louvain コミュニティ検出、時間的圧縮 |
fractal.py | ドリルダウン式のナビゲーションを備えたマルチスケールの記憶ツリー |
cls_store.py | 相補学習システム:高速なエピソード記憶ストアと低速な意味記憶ストア |
知識構造
| モジュール | 役割 |
|---|---|
knowledge_graph.py | Personalized PageRank を備えた型付きのエンティティ・関係グラフ |
causal_discovery.py | コーディングセッションデータから因果 DAG を構築する PC アルゴリズム |
cognitive_map.py | ナビゲーションベースの検索に用いる Successor Representation |
narrative.py | プロジェクトの自伝的ストーリーの合成 |
curation.py | 重複の統合、矛盾の検出、相互参照のリンク |
先端機能
| モジュール | 役割 |
|---|---|
hopfield.py | 最新の連続値 Hopfield ネットワーク(Ramsauer et al., 2021) |
hdc_encoder.py | 10,000 次元の双極空間における超次元コンピューティング |
metacognition.py | 知識の網羅状況の自己評価と不足箇所の検出 |
rules_engine.py | ハードおよびソフトなニューロシンボリック制約 |
crdt_sync.py | CRDT による複数エージェント間の記憶共有 |
prospective.py | ディレクトリ、キーワード、エンティティ、時間を対象とした将来指向のトリガー |
sensory_buffer.py | セッションの生コンテンツを取得するエピソード記憶バッファー |
restoration.py | コンテキスト圧縮への耐性を高める海馬再生エンジン |
seed.py | プロジェクトのスキャンと基盤となる記憶の初期化 |
高度なセットアップ
ソースから
git clone https://github.com/amanhij/Zikkaron.git
cd Zikkaron
pip install -e .
SSE トランスポート
stdio の代わりに、常駐バックグラウンドサーバーとして実行します:
zikkaron --transport sse
次に、Claude Code に URL を指定します:
{
"mcpServers": {
"zikkaron": {
"type": "sse",
"url": "http://127.0.0.1:8742/sse"
}
}
}
デフォルトのポートは 8742 です。--port で変更できます。データベースのデフォルトの保存先は ~/.zikkaron/memory.db です。--db-path で変更できます。
Configuration
すべての設定では、環境変数のプレフィックスとして ZIKKARON_ を使用します。
| Variable | Default | What it controls |
|---|---|---|
ZIKKARON_PORT | 8742 | サーバーのポート |
ZIKKARON_DB_PATH | ~/.zikkaron/memory.db | データベースの場所 |
ZIKKARON_EMBEDDING_MODEL | all-MiniLM-L6-v2 | Sentence-transformer モデル |
ZIKKARON_DECAY_FACTOR | 0.95 | 統合サイクルごとのヒート減衰 |
ZIKKARON_COLD_THRESHOLD | 0.05 | 記憶がアーカイブ候補となるヒートのしきい値 |
ZIKKARON_WRITE_GATE_THRESHOLD | 0.4 | 書き込みゲートを通過するための最小サプライザル |
ZIKKARON_HOPFIELD_BETA | 8.0 | Hopfield ネットワークの鋭さ |
ZIKKARON_SR_DISCOUNT | 0.9 | 後続表現の割引率 |
ZIKKARON_COGNITIVE_LOAD_LIMIT | 4 | アクティブなコンテキストチャンクの上限(Cowan の 4 +/- 1) |
全項目の一覧は zikkaron/config.py にあります。
Testing
python -m pytest zikkaron/tests/ -x -q
34 個のテストファイルにわたる 998 個のテストで、すべてのサブシステムを網羅しています。
References
実装の基盤となった論文と書籍
Ramsauer et al. 「Hopfield Networks is All You Need」(ICLR 2021、arXiv:2008.02217)
Nader, Schafe, LeDoux. 「Fear memories require protein synthesis in the amygdala for reconsolidation after retrieval」(Nature 406、2000)
Osan, Tort, Bhatt, Amaral. 「Three outcomes of reconsolidation」(PLoS ONE、2011)
McClelland, McNaughton, O'Reilly. 「Why there are complementary learning systems in the hippocampus and neocortex」(Psychological Review 102、1995)
Sun et al. 「Organizing memories for generalization in complementary learning systems」(Nature Neuroscience 26、2023)
Stachenfeld, Botvinick, Gershman. 「The hippocampus as a predictive map」(Nature Neuroscience 20、2017)
Whittington et al. 「The Tolman-Eichenbaum Machine」(Cell 183、2020)
Spirtes, Glymour, Scheines. Causation, Prediction, and Search(MIT Press、2000)
Kanerva. Sparse Distributed Memory(MIT Press、1988)
Frady, Kleyko, Sommer. 「Variable Binding for Sparse Distributed Representations」(IEEE TNNLS、2022)
Toth et al. 「Optimal forgetting via rate-distortion theory」(PLoS Computational Biology、2020)
Josselyn, Frankland. 「Memory allocation: mechanisms and function」(Annual Review Neuroscience 41、2018)
Rashid et al. 「Competition between engrams influences fear memory formation and recall」(Science 353、2016)
Zhou et al. 「MetaRAG: Metacognitive Retrieval-Augmented Generation」(ACM Web、2024)
License
MIT
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。