Context Mem

---

問題

今日の AI ツールには、単一のパッケージで同時に解決されていない問題が 2 つあります。

AI が忘れてしまいます。 新しいセッションは毎回ゼロから始まります。先週の木曜日に決めたアーキテクチャ上の決定事項、設定ミスのある環境変数が原因だと突き止めるのに 4 時間かかったバグ、3 回伝えた好みなどは、どれも引き継がれません。すでに共有されているコンテキストを説明し直すため、毎回のセッションで最初の 10 分を費やします。これが、チームの開発者一人ひとり、すべてのプロジェクト、毎日続くことを想像してください。

コンテキストが膨れ上がります。 長時間のコーディングセッションでは、コンテキストウィンドウの上限を超えてしまいます。ツール出力が 50 件ある一般的なセッションでは、スタックトレース、テスト出力、ファイルの読み取り結果、シェルコマンドなど、未加工のテキストが 365 KB 蓄積されます。トークンごとに費用がかかるか、モデルの処理が遅くなります。単純な切り詰めでは、モデルに必要な証拠そのものが失われます。すべてを保持すると、応答が遅くなり、推論コストが急増します。

この 2 つの問題は互いに悪影響を及ぼします。忘却への解決策（すべて保持する）は、コンテキストの膨張への解決策（すべて破棄する）とは正反対です。その結果、多くのツールが強いる誤った二者択一が生まれます。AI がすべてを忘れるか、コストが膨らむかのどちらかです。context-mem は、未加工の履歴をコンテキストウィンドウに詰め込むのではなく、インデックス化、圧縮、検索が可能なメモリストアを構築することで、この両方を同時に解決します。

---

解決策 — 1 つのツール、2 つの柱

柱 1：メモリ（LLM Wiki）

すべてのツール呼び出しは自動的に取り込まれ、要約され、閲覧可能な Markdown ボルトに書き込まれます。これは、AI がプロジェクトについて管理する、生きた Wiki です。エンティティごとにバックリンク付きのページが作成されます。トピックごとに統合ページが作成されます。セッションは閲覧可能なソース文書になります。決定事項は、再構成可能な記録として蓄積されます。

ボルトは .context-mem/vault/ に保存され、基盤となる SQLite ストアから継続的に同期されます。Obsidian で読んだり、ターミナルから grep で検索したり、ハイブリッド BM25＋ベクトル検索＋任意の LLM 判定機能を使って 45 以上の MCP ツールから問い合わせたりできます。未加工の SQLite ストアが正式な記録であり、Markdown ボルトはそこから派生した、人が読みやすいレイヤーです。

これは Andrej Karpathy の LLM Wiki パターン のリファレンス実装です。3 つのレイヤー（未加工のソース／Wiki／スキーマ）で構成され、他のシステムにはない、ツール呼び出しからの自動取り込み機能を備えています。

柱 2：圧縮（14 種類の要約器）

すべての観測内容は、保存前にコンテンツを考慮した要約器を通過します。スタックトレースと JSON 設定ファイルを同じようには扱いません。ビルド時のシェル出力は、TypeScript コンパイラーのエラーとは異なる方法で圧縮されます。システムはコンテンツの種類に応じた適切な圧縮を適用します。

その結果、ツール出力が 50 件あるコーディングセッションのサイズは、365 KB から 3.2 KB になります。トークンを 99.1％削減できることを検証済みです。圧縮は適応的です。重要度が高く新しい観測内容はそのまま保持され、重要度が低く古いものは段階的に圧縮されます。ピン留めされた項目は、古さにかかわらず圧縮されません。

---

ワンコマンド

npm i context-mem && npx context-mem init

init はエディターを自動検出し、適切な設定ファイルを書き込みます。

エディター	書き込まれる設定
Claude Code	.mcp.json + 8 hooks + CLAUDE.md
Cursor	.cursor/mcp.json + .cursor/rules/context-mem.mdc
Windsurf	.windsurf/mcp.json + .windsurf/rules/context-mem.md
VS Code / Copilot	.vscode/mcp.json + .github/copilot-instructions.md
Cline	.cline/mcp_settings.json + .clinerules/context-mem.md
Roo Code	.roo-code/mcp_settings.json + .roo/rules/context-mem.md
Aider	.aider.conf.yml（MCP ブロック）
Continue	.continue/config.json（MCP ブロック）
JetBrains AI	.idea/mcp.json

API キーは不要です。クラウドアカウントも不要です。データがマシンの外に出ることはありません。

---

60 秒でわかる二本柱

[ placeholder: GIF or video — Claude Code session with split view showing Obsidian graph updating in real time alongside the context-mem dashboard token savings chart ]

---

アーキテクチャ（Karpathy の LLM Wiki パターンのリファレンス実装）

                    ┌─────────────────────────────────────────┐
                    │            Raw Sources (immutable)       │
                    │  tool calls · observations · file reads  │
                    └──────────────────┬──────────────────────┘
                                       │
                                       ▼
                    ┌─────────────────────────────────────────┐
                    │           Observation Pipeline           │
                    │                                          │
                    │  PrivacyEngine (9 detectors)             │
                    │    → 14 content-aware summarizers        │
                    │    → entity extraction (100+ aliases)    │
                    │    → topic detection                     │
                    │    → importance scoring (0.0–1.0)        │
                    │    → adaptive compression tier           │
                    └────────────────┬────────────────────────┘
                                     │
                   ┌─────────────────┴───────────────────┐
                   │                                     │
                   ▼                                     ▼
    ┌──────────────────────────┐       ┌─────────────────────────────┐
    │    SQLite (primary)      │       │   Markdown Vault (derived)  │
    │                          │       │                             │
    │  observations            │──────▶│  .context-mem/vault/        │
    │  entities + graph        │  sync │    index.md                 │
    │  knowledge               │       │    log.md                   │
    │  events                  │       │    sources/<session>.md     │
    │  FTS5 index              │       │    entities/<name>.md       │
    │  vector embeddings       │       │    topics/<name>.md         │
    └──────────────────────────┘       │    knowledge/<id>.md        │
                   │                   └─────────────────────────────┘
                   │
                   ▼
    ┌──────────────────────────────────────────────────────────────┐
    │              Hybrid Retrieval                                │
    │                                                              │
    │  BM25 (8 strategies + synonym expansion)                     │
    │  + Vector (nomic-embed-text-v1.5, 768-dim)                   │
    │  + Trigram + Levenshtein                                     │
    │  → Fusion (intent-adaptive weights, IDF reranker)            │
    │  → Optional LLM judge (Haiku, 50/50 blend, 100% R@5)        │
    └──────────────────────────────────────────────────────────────┘

3 つのレイヤー（Karpathy による）：

• 生データソース — ツール呼び出しの出力、ファイルの読み取り結果、シェルコマンド、観察結果です。一度だけ書き込まれ、変更されることはありません。永続的な記録です。
• Wiki — LLM が管理する Markdown ボールト（.context-mem/vault/）です。SQLite から自動同期されます。人間が読みやすく、Obsidian 互換で、grep で検索できます。エンティティページ、トピックページ、セッションページ、ナレッジページ、インデックス、イベントログが含まれます。
• スキーマ — docs/llm-wiki-schema.md が、ページ構造、リンク規約、エージェントのワークフローレシピ、相互運用契約を定めています。公開仕様であり、ほかのツールも準拠した Wiki を出力できます。

多くのメモリーシステムと異なる点は、context-mem が SQLite を Markdown に置き換えるものではないことです。SQLite が信頼できる唯一の情報源です。観察結果の保存、検索、インデックス作成は SQLite で行います。ボールトはその上にある、閲覧、リンク、差分確認が可能な表示レイヤーです。人間や LLM がデータベースクライアントなしでナビゲートできるレイヤーです。ボールトのディレクトリを削除しても、重要なデータは失われません。ボールトのページを手動で編集した場合、その変更は保持され、次回の同期で上書きされません。

これは、Karpathy の 3 層モデルを、稼働中の AI 開発環境に適用したものです。不変の入力、維持される統合レイヤー、そしてその統合を規定する公開スキーマで構成されます。ボールトは MCP ツールと独立して利用できます。Markdown ファイルを集めたディレクトリにすぎません。任意のエディターで開けます。Git に入れられます。コミット間の差分を確認できます。新しい会話にページをコピー＆ペーストして、長文のコンテキストとして使うこともできます。MCP ツールは自動化された手段であり、Markdown ボールトは持ち運び可能で永続性があり、人間が読みやすい手段です。

---

検索ベンチマーク（誠実な測定方法）

すべてのスコアはセッション単位の検索再現率です。正しい証拠を含むセッションが、上位 k 件の結果に 1 つでも含まれていたかを測定します。これは、検索と生成、判定を組み合わせたエンドツーエンドの QA 精度とは異なります。エンドツーエンドの QA 精度は測定がより困難で、すべてのシステムでスコアが低くなります。ここでは両方の測定値を公開しています。

完全ローカル（API 呼び出しゼロ、完全無料）

ベンチマーク	検索再現率	E2E QA 精度	質問数	セッション数
LongMemEval	97.8% R@5	v3.4 後に公開	500	約 53/会話
LoCoMo	98.1% R@10	v3.4 後に公開	1,977	19～35/会話
MemBench	98.0% R@5	—	500	—
ConvoMem	97.7% R@10	—	250	—

オプションの LLM 再ランキングあり（クエリ 500 件あたり約 $1）

ベンチマーク	検索再現率
LongMemEval	100.0% R@5（500/500）

LLM ジャッジ（Claude Haiku）が BM25 とベクトル検索による上位 N 件の候補を 0～10 点で評価し、検索スコアと 50/50 で組み合わせます。ai_curation.enabled = true の場合に有効になります。Haiku の料金では、クエリあたり約 $0.002 が追加されます。

方法論に関する注記：

• 正しい証拠セッションが top-k に 1 件でも含まれていれば、「ヒット」としてスコアが付与されます。エンドツーエンドの QA ではありません。
• LoCoMo ベンチマークでは、データセットが提供するメタデータ（session_summary、observation、event_summary）をセッションドキュメントに追加します。本番システムでは、要約器とエンティティ抽出によって同等の情報強化を行います。
• 同義語の拡張：コアクエリビルダーには、一般語彙の同義語が含まれます（movie → film、sibling → brother）。同義語をまったく拡張しない場合、結果は約 1～2% 低くなります。
• ベンチマークコードはすべてオープンで実行可能です：npm run bench。詳細は benchmarks/ を参照してください。

方法論の全文：docs/benchmarks/methodology.md（v3.4 とともに公開）。

---

圧縮ベンチマーク（検証済み）

シナリオ	圧縮前	圧縮後	削減率
一般的なコーディングセッション（ツール出力 50 件）	365 KB	3.2 KB	99.1%

要約器ごとの内訳：

要約器	圧縮率
ログ出力	97%
エラー	95%
シェル／CLI	約95%
コード	92%
JSON	89%
TS コンパイラーのエラー	約88%
テスト	約85%
ビルド出力	約94%
Git ログ	約90%
HTML	約92%
Markdown	約75%
CSV	約80%
ネットワーク応答	約88%
バイナリ（16 進ダンプ）	約98%

重要度の高い観測（DECISION、MILESTONE、PROBLEM フラグ）は、意味レベルで損失なく圧縮され、経過時間にかかわらずそのまま保持されます。圧縮の対象は、定型的なツール出力です。

---

主な機能

メモリ

• LLM Wiki の基盤 — .context-mem/vault/ にある Markdown ボルトで、SQLite から自動同期されます。エンティティページ、トピックページ、セッションソースページ、ナレッジページ、index.md、log.md が含まれます。Obsidian と互換性があり、grep にも適しています。
• コンテンツを認識する 14 種類の要約器 — JSON、シェル、コード、ログ、エラー、TS エラー、テスト、ビルド、Git ログ、HTML、Markdown、CSV、バイナリ、ネットワーク。それぞれのコンテンツタイプに合わせて調整されています。
• 適応型の 4 段階圧縮 — 逐語的（0～7 日）→ 軽度（7～30 日）→ 中程度（30～90 日）→ 要約（90 日以上）。ピン留めされたエントリは、常に逐語的な状態で保持されます。
• ナレッジグラフ — 型付きのエンティティ・関係モデル：ファイル、モジュール、パターン、決定、バグ、人、ライブラリ、サービス、API、設定。graph_query、graph_neighbors、add_relationship でたどることができます。
• 時間的事実 — すべてのナレッジエントリに valid_from／valid_to を設定します。後継関係をたどるチェーンもあります。temporal_query は「時刻 T において X について何が真だったか？」に回答します。
• 決定の経緯の再構成 — explain_decision は、ファイルの読み取り → エラー → 検索 → 決定へと、証拠の連鎖をさかのぼります。完全な来歴情報を提供します。
• エンティティインテリジェンス — テクノロジー、人、ファイルパス、CamelCase 識別子、ALL_CAPS 定数を自動検出します。100 以上の標準エイリアス（React.js → React、Node → Node.js など）を備えています。
• セッションナラティブ — すぐに使える 4 種類のテンプレート：PR の説明、スタンドアップの更新、ADR、オンボーディングガイド。context-mem story --format pr。
• 起動時プライマー — セッション開始時に、トークン予算に応じてコンテキストを注入します。4 層構成：プロジェクトプロフィール（15%）、重要なナレッジ（40%）、最近の決定（30%）、上位エンティティ（15%）。
• プロンプトごとの注入 — UserPromptSubmit フックが、各メッセージに関連するメモリを自動注入します。レート制限とトピックの重複排除機能を備え、手動コマンドは不要です。

圧縮

• 14 種類のコンテンツに応じた要約機能 — どの内容にも同じ処理を適用するわけではありません。スタックトレースと JSON レスポンスには、それぞれ異なる処理を適用します。
• 固定した内容をそのまま保持 — 意思決定、マイルストーン、手動で固定した観察内容は、圧縮されません。
• 優先度に応じた段階的な切り詰め — コンテキストの予算を超過した場合、重要度の低い項目から圧縮します。重要度の高い項目は保持されます。
• 設定可能なトークン予算 — 3 つの超過時の処理方法を選べます。古い項目から圧縮、重要度の低い項目から圧縮、または強制的に切り詰めます。
• 365 KB → 3.2 KB — 一般的な 50 ツール出力のコーディングセッションで検証済みです。

両方

• ハイブリッド検索 — BM25（8 種類の戦略＋同義語の拡張）＋ベクトル（nomic-embed-text-v1.5、768 次元）＋トライグラム＋レーベンシュタイン距離を並列実行し、意図に応じて重みを調整して統合したうえで、IDF 重み付きコンテンツ再ランキングを行います。LLM による判定を用いた再ランキングも任意で利用できます。
• 時間解決機能 — 相対日付クエリ（「3 日前」「先週の土曜日」「先週」など）を決定論的に解析します。LLM のコストはゼロです。信頼度とともに絶対日付の範囲を返します。
• 45 以上の MCP ツール — 観察、検索、想起、質問、タイムライン、ナレッジグラフ、エンティティ検出、時間クエリ、セッションの引き継ぎ、マルチエージェント連携、トークン予算、ダッシュボード、診断などを利用できます。
• 完全ローカルで、クラウド不要 — SQLite がマシン上で動作します。テレメトリはありません。コア機能に API キーは必要ありません。
• 9 種類の検出器を備えたプライバシーエンジン — <private> タグを削除し、カスタム正規表現による秘匿化を適用して、API キー、トークン、パスワード、個人情報のパターンを検出します。機密情報がマシンの外部に出ることはありません。
• サブミリ秒の処理 — 重要度の分類は毎秒 556K 回、エンティティの抽出は毎秒 179K 回、BM25 検索は毎秒 3.3K 回実行でき、すべてローカルで動作します。

---

比較

メモリ分野には既存のツールが複数あります。コンテキスト圧縮分野には、さらにいくつかあります。この 2 つの側面を同時に扱うツールは、ほかにありません。

	context-mem v4	Mem0	Graphiti	Zep	Letta
LLM Wiki／Markdown ボルト	✅	❌	❌	❌	❌
ツール呼び出しからの自動取り込み	✅	❌	❌	❌	❌
検索再現率（ローカル）	97.8–98.1% R@k	未公開	未公開	未公開	未公開
トークン圧縮	99.1%	❌	❌	❌	一部対応
型付きナレッジグラフ	✅	✅	✅	一部対応	一部対応
時間グラフクエリ	✅	✅	✅	❌	❌
ハイブリッド BM25＋ベクトル＋LLM 再ランキング	✅	一部対応	❌	一部対応	❌
完全ローカル（クラウド不要）	✅	❌	❌	❌	❌
意思決定の経緯の再構築	✅	❌	❌	❌	❌
Obsidian 互換の出力	✅	❌	❌	❌	❌
MCP ツール	45 以上	一部	一部	一部	一部
ライセンス	MIT	Apache／クラウド	Apache	Apache	Apache

この表についての注記： Mem0、Graphiti、Zep、Letta の検索再現率は、当プロジェクトと比較可能な手法を用いたセッション単位の検索再現率として、同じベンチマーク（LongMemEval、LoCoMo、MemBench、ConvoMem）で公開されていません。各プロジェクトのドキュメントに公開数値がある場合でも、データセットや粒度（チャンク単位とセッション単位）が異なるか、インフラの詳細が公開されていません。直接比較しないでください。context-mem の E2E QA 数値は v3.4 とともに公開予定です。それ以外の比較はすべて、2026 年 4 月時点の公開ドキュメントに基づいています。

「トークン圧縮」の行には補足が必要です。Mem0、Graphiti、Zep は主に検索システムであり、コンテキストウィンドウのコスト問題を解決するとは主張していません。Letta は要約による部分的な圧縮に対応しています。context-mem の 99.1% という数値は、実際のコーディングセッション（50 ツール出力、365 KB → 3.2 KB）で測定されています。この測定は再現可能です。独自のプロジェクトで context-mem stats --raw と context-mem stats --compressed を比較して実行できます。

---

実際の使用例

You: "Why did we choose Postgres over MySQL?"
→ recall returns the exact verbatim quote from March 15 (importance 0.95)
  with the full evidence chain: error → file_read → search → decision

You: "What did Sarah work on last sprint?"
→ browse by person shows 14 observations mentioning Sarah,
  grouped by topic (auth, database, deployment)

You: "What are we about to forget?"
→ predict_loss shows 8 entries at risk: low importance, 45+ days old,
  never accessed. Pin the critical ones before they decay.

You: "Generate a PR description for this branch"
→ context-mem story --format pr assembles changes, decisions,
  resolved issues, and test plan from the current session

You: "What was our database schema in January?"
→ temporal_query returns what was true about the schema at that point
  in time, including since-superseded knowledge

---

はじめに

1. インストール

npm i context-mem && npx context-mem init

init はエディターに適した MCP 設定を作成します。Claude Code では IDE を再起動する必要はありません。Cursor、Windsurf、VS Code では、init の実行後に IDE を再起動してください。

2. MCP を設定する（手動の場合）

手動で設定する場合は、MCP 設定に以下を追加します。

{
  "mcpServers": {
    "context-mem": {
      "command": "npx",
      "args": ["context-mem", "serve"],
      "env": {}
    }
  }
}

Claude Code の場合、init は .claude/settings.json に8つのフックも書き込み、プロンプトを送信するたびに関連するメモリーを自動で挿入します。通常の開発中に observe を手動で呼び出す必要はありません。

3. LLM Wiki ボルトを有効にする（v3.4 以降、オプトイン）

context-mem の設定（.context-mem/config.json）に以下を追加します。

{
  "vault": {
    "enabled": true,
    "vaultDir": ".context-mem/vault"
  }
}

次回の観察データ取り込み時に、ボルトのディレクトリが自動的に生成されます。Obsidian で .context-mem/vault/ を開くと、プロジェクトのナレッジのグラフビューを閲覧できます。

v3.4 ではボルトはオプトインで、v4.0 ではデフォルトで有効になります。

4. ダッシュボード

context-mem dashboard

http://localhost:3141 でローカル Web UI を開きます。ページは6つあり、インテリジェンス概要、ナレッジグラフ、トピック、タイムライン、エンティティ、診断を表示します。

5. ベンチマーク（ご自身で実行してください）

npm run bench          # quick mode (all 4 benchmarks, sample sizes)
npm run bench:full     # full benchmarks
npm run bench:e2e-qa   # E2E QA: retrieve → Haiku answer → Haiku judge

ベンチマークのコードはすべてオープンです。数値を水増しする隠れたアダプターはありません。benchmarks/ と docs/benchmarks/methodology.md を参照してください。

---

MCP ツールリファレンス（45 個以上）

context-mem は、独自の SDK やラッパーライブラリ、ロックインを伴わず、すべての機能を MCP ツールとして公開します。MCP に対応したホスト（Claude Code、Cursor、Windsurf、VS Code、Cline、Roo Code、Aider、Continue、JetBrains AI、CrewAI、LangChain、AutoGen）なら、これらのツールを直接利用できます。有料プラン限定のツールや、クラウドサブスクリプションが必要な機能はありません。この README に記載されているすべての機能は、オープンな MCP インターフェースから利用できます。

コアメモリツール：

ツール	目的
observe	観察内容を保存します。自動要約、重要度スコアリング、エンティティ抽出、トピック検出を行います
recall	フィルター（重要度、種類、フラグ、時間）を指定して、元の内容を取得します
search	ハイブリッド検索（BM25＋ベクトル＋オプションの LLM ジャッジ）
ask	メモリストア全体を対象に、自然言語で質問に回答します
timeline	重要度バッジとフラグ付きで、観察内容を新しい順に表示します
stats	現在のセッションのトークン使用量（圧縮前と圧縮後）

ナレッジグラフツール：

ツール	目的
save_knowledge	矛盾の検出と時間的有効期間の設定を行いながら、ナレッジエントリを保存します
search_knowledge	検索します（デフォルトでは、置き換えられたエントリを除外します）
promote_knowledge	グローバルなプロジェクト横断ストアに昇格させます
global_search	すべてのプロジェクトを横断して同時に検索します
resolve_contradiction	ナレッジの矛盾を解決します（置き換え／統合／維持／アーカイブ）
merge_suggestions	プロジェクト間の重複候補を表示します
graph_query	エンティティ間の関係をたどります
add_relationship	型付きの関係でエンティティをリンクします
graph_neighbors	接続されたエンティティを検索します（深さを設定可能）

時間・インテリジェンスツール：

ツール	目的
temporal_query	特定の時点で何が真実だったかを問い合わせます
time_travel	任意の 2 つのタイムスタンプにおけるプロジェクトの状態を比較します
explain_decision	証拠の連鎖をさかのぼり、意思決定の理由を再構築します
predict_loss	圧縮や削除のリスクがある観察内容を特定します
generate_story	PR の説明、スタンドアップ報告、ADR、オンボーディングガイドを生成します
entity_detect	任意のテキストからエンティティを検出します
find_tunnels	プロジェクト間のトピックのつながりを検索します

セッション・エージェントツール：

ツール	目的
wake_up	セッション開始時に、トークン予算を考慮したコンテキストの要約を提供します
restore_session	チェックポイントからセッションを復元します
handoff_session	セッション間の継続性を保つためのパッケージを作成します
agent_register	役割と機能を指定してエージェントを登録します
agent_status	アクティブなすべてのエージェントと、エージェントが確保しているリソースを確認します
claim_files	並列エージェント間の競合を防ぐため、ファイルを確保します
agent_broadcast	プロジェクト内のすべてのエージェントに発見事項を通知します

システムツール：

ツール	目的
configure	ランタイム設定を更新します
budget_status / budget_configure	トークン予算を管理します
summarize	内容を保存せずに要約します（一回限り）
execute	コードを実行します（JS、TS、Python、Shell、Ruby、Go、Rust、PHP、Perl、R、Elixir）
index_content	コードを認識したチャンク分割でインデックスを作成します
search_content	インデックス化されたチャンクを検索します
list_people / list_topics	エンティティとトピックを一覧表示します
import_conversations	会話履歴をインポートします
browse	人物、エンティティ、またはトピック別に観察内容を取得します
diagnostics	エラーログ、パイプライン統計、ストレージの健全性を確認します

---

診断 API

システムの動作を確認する必要がある場合：

# MCP tool
mcp__context-mem__diagnostics

# HTTP (when dashboard is running)
curl http://localhost:3141/api/diagnostics

エラーログ、パイプライン統計、アクティブなセッション、ストレージの健全性、検索インデックスの状態を返します。

---

マルチエージェントのサポート

context-mem は、同じプロジェクトで並列に作業する AI エージェントを、競合なくサポートします：

// Agent A registers and claims a file
mcp__context-mem__agent_register({ agent_id: "agent-a", role: "backend" })
mcp__context-mem__claim_files({ files: ["src/api.ts"] })

// Agent B sees Agent A's claim and avoids the conflict
mcp__context-mem__agent_status({})
// → { "agent-a": { files: ["src/api.ts"], status: "active" } }

// Broadcast a finding to all agents
mcp__context-mem__agent_broadcast({ message: "auth module has a race condition on token refresh" })

共有メモリによって、作業の重複を防ぎます。ファイルを確保することで、マージ競合を防ぎます。ブロードキャストによって、発見事項をすべてのエージェント間で共有し、同期を保ちます。

---

アーキテクチャのリファレンス：検索パイプライン

検索スタックでは、重みと適合率・再現率のトレードオフがそれぞれ異なる8種類のBM25戦略を並列で実行します。

戦略	重み	目的
ANDモード	2.0	適合率が高く、すべての用語が必須
フレーズマッチング	1.9	連続するキーワードの組み合わせ
エンティティ重視	1.8	固有名詞、日付、識別子
サニタイズ済みFTS5	1.5	デフォルトのトークン化
緩和AND	1.2	エンティティ＋上位キーワード
ORモード＋類義語	1.0	意味的な拡張による幅広い再現率
個別キーワード	0.5	ロングテールの検索を補完
個別の類義語	0.2	意味上の隔たりを橋渡し（きょうだい→兄弟）

これに加えて、時間解決（重み1.6）を行います。「先週の土曜日」のような相対日付のクエリは、検索前に決定論的に絶対日付の範囲へ解決されます。LLMのコストはゼロです。

ベクトル検索（nomic-embed-text-v1.5、768次元）はカスケードではなく、上位30件の候補に対してBM25と並列で実行されます。結果は意図に応じた重み（BM25：0.45、トライグラム：0.15、レーベンシュタイン：0.05、ベクトル：0.35）で統合し、IDFで重み付けしたコンテンツ再ランキングを行います。オプションのLLMジャッジは、最終的な上位N件について、検索スコアと50／50で統合します。

---

LLM Wikiスキーマ

ボルトはdocs/llm-wiki-schema.mdに記載されたスキーマに従います。次の項目が定義されています。

• ディレクトリ構成（sources/、entities/、topics/、knowledge/）
• ページの種類とフロントマターの規約
• リンク構文（[[entity-name]]はentities/entity-name.mdに解決されます）
• 操作：取り込み／クエリ／リント
• CLAUDE.md／AGENTS.md向けのエージェントワークフローのレシピ
• 相互運用性の契約 — 他のツールが仕様に準拠したWikiを出力し、context-memにインポートできます

これは公開仕様です。コミュニティRFCはgithub.com/JubaKitiashvili/context-mem/discussionsにあります。

---

パフォーマンス特性

すべてのコア操作は同期処理で、ミリ秒未満で完了します。デフォルトの操作にLLMは必要ありません。

操作	スループット	レイテンシ
重要度の分類	556K ops/s	0.002ms
エンティティ抽出	179K ops/s	0.006ms
トピック検出	162K ops/s	0.006ms
圧縮ティアの計算	3M ops/s	<0.001ms
逐語的FTS5検索	50K ops/s	0.020ms
BM25ハイブリッド検索	3.3K ops/s	0.3ms
ウェイクアップ用プライマーの組み立て	9K ops/s	0.111ms
ナラティブ生成	6K ops/s	0.164ms

ベクトル検索を有効にすると、ベクトル埋め込み（nomic-embed-text-v1.5）によりクエリごとに約5～15ms追加されます。それでも、どのネットワーク呼び出しよりも高速です。オプションのLLMジャッジはHaiku APIを1回呼び出し（約100ms）、ai_curation.enabled = trueの場合にのみ実行されます。

---

変更履歴の主な内容

• v4.0.0 — LLM Wikiの正式リリース。統合ページ、Obsidianプラグイン、8種類のIDE連携、Context Protocol RFC、圧縮処理の仕上げ。目標日：2026-05-22。
• v3.4.0 — LLM Wikiプレビュー。Markdownボルトレイヤー、スキーマ仕様v1、E2E QAベンチマーク、issue #6をクローズ（ベンチマーク手法の開示）。
• v3.3.0 — 基盤機能。CI、エラーログ、診断機能。サイレントパッチ。
• v3.2.0 — ハイブリッド並列検索。BM25とベクトルを並列実行し、意図に応じた統合を実施。
• v2.5.0 — ダッシュボード。リアルタイムWeb UI、ナレッジグラフの可視化。

---

ライセンス：MIT

Juba Kitiashviliが開発しました。

謝辞：LLM Wikiの枠組みを提唱したAndrej Karpathy（2026-04-04）。Memexを提唱したVannevar Bush（1945）。