mcpField
A
ai-memory — Persistent Memory for Any AI

ai-memory — Persistent Memory for Any AI

ローカル
alphaonedev.github.ioメモリ・ナレッジ562 週間前に更新

ai-memory — Persistent Memory for Any AI について

ai-memory は AI アシスタントに永続的なメモリを提供する MCP サーバーで、記録をローカルの SQLite データベースに保存し、想起時に関連性で順位付けします。アーキテクチャや設定、修正内容などの文脈を複数の AI クライアントで共有したい個人やエンジニアを対象としています。README では、大規模な運用向けに PostgreSQL と Apache AGE のバックエンドも説明されています。

主な機能

  1. 01ローカル SQLite による永続メモリの保存
  2. 02多要素スコアリングによる想起結果の順位付け
  3. 03TOON 形式によるコンパクトな結果の返却
  4. 04MCP ツール、HTTP エンドポイント、CLI コマンド

活用シーン

  1. 01複数の AI アシスタントでプロジェクトのアーキテクチャや設定を記憶
  2. 02過去の修正や決定事項の保存と再利用
  3. 03複数ノード環境での共有メモリの運用

MCP 対応

ai-memory は保存、想起、一覧、取得、検索などのメモリ操作を MCP ツールとして公開します。デフォルトのツールセットは小さく、プロファイルや実行時の設定で追加のツールを有効にできます。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定
{
"mcpServers": {
"ai-memory": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"AI_MEMORY_DB",
"ghcr.io/alphaonedev/ai-memory:0.5.1"
],
"env": {
"AI_MEMORY_DB": "<AI_MEMORY_DB>"
}
}
}
}
起動コマンドdocker run -i --rm -e AI_MEMORY_DB ghcr.io/alphaonedev/ai-memory:0.5.1
設定が必要な環境変数
AI_MEMORY_DBPath to the SQLite database file

ローカルサーバーにはマシン上の実行環境(Node.js 18 以上など)が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ
ocighcr.io/alphaonedev/ai-memory:0.5.1

ツール

ツール一覧はまだ取得されていません

ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。

詳細

ai-memory のロゴ

ai-memory

汎用 AI メモリ

CI Bench Session-boot lifetime Rust License SQLite Tests Test Hub Discovery Gate v0.6.4 Cert MCP NSA CSI Evidence v0.6.4 Evidence v0.7.0 Crates.io Version npm PyPI

ai-memory は、AI アシスタント向けの永続メモリシステムです。 MCP に対応するあらゆる AI(Claude、ChatGPT、Grok、Llama など)で利用できます。AI が学習した内容をローカルの SQLite データベースに保存し、呼び出す際には関連性に基づいてメモリを順位付けし、重要な知識を自動的に永続ストレージへ昇格させます。一度インストールすれば、使用するすべての AI アシスタントが、アーキテクチャ、好み、修正内容をいつまでも記憶します。


インストール方法を選択
あなたの立場デプロイ環境まずはこちら
ai-memory を試す単独の開発者ノート PC 上の AI クライアント 1 台docs/install-quickstart.md — 5 分で完了する非常に簡単なインストールと、LLM バックエンドの設定をまとめて行えます
エンジニア/アーキテクト単一ノードの本番環境、または 1 つのノード上で複数のエージェントを運用docs/INSTALL.md → docs/production-deployment.md
エンジニア/アーキテクト複数サーバー/複数ラック/複数 DC/スウォーム/ハイブ/フェデレーションdocs/enterprise-deployment.md — シングルトンからマルチリージョンまで、8 種類のトポロジーを紹介します
エンジニア/アーキテクトPostgreSQL + Apache AGE ストレージ(複数ライター、1,000 万件以上のメモリ、KG 中心)docs/postgres-age-guide.md — PostgreSQL の公式オペレーターガイド
導入を検討する意思決定者—docs/audience/decision-maker.html

LLM バックエンド(xAI Grok、OpenAI、Anthropic、Gemini、DeepSeek、Kimi、Qwen、Mistral、Groq、Together、Cerebras、OpenRouter、Fireworks、LMStudio、vLLM、llama.cpp server、またはローカルの Ollama)を設定していますか?docs/integrations/llm-backends.md をご覧ください。MCP の環境変数ブロックの設定方法は、インストール方法にかかわらず同じです。


v0.9.0 — 現行リリース。 セキュリティ強化とコードレビューを行ったリリースです。5レーンの敵対的レビューで49件を修正し(#1885–#1935)、少数の機能も追加しました。最大の変更点は、安全なデフォルトへの切り替えです。HTTP の直接書き込みでは、デフォルトでエージェントのアテステーションが必須になりました(#1751、適用範囲は#1985でサーフェスごとに限定)。署名のない HTTP POST /api/v1/memories(および/bulk)は、attest_level="claimed"として登録されるのではなく、拒否されます(403 ATTESTATION_FAILED)。ただし、オペレーターが明示的なオプトアウト設定AI_MEMORY_REQUIRE_AGENT_ATTESTATION=0を指定した場合を除きます。MCP のmemory_storeと CLI のstoreは、オペレーターを実行主体とするサーフェスで、デフォルトでは引き続き制限なく利用できます(署名のない書き込みはclaimedとして登録されます)。=1を設定すると、すべてのサーフェスで厳格なチェックが適用されます。(v0.9.0 GA ではこれが「すべてのサーフェスで必須」としてリリースされましたが、MCP ホストでは実現不可能だったため、現行リリースではサーフェスごとの適用に修正しました。)これに加えて、必須フックの存在確認を行う強制ゲートが、MCP の書き込みパス(#1885)と HTTP の書き込みパス(#1924)の両方で動作するようになりました。これにより、設定済みの必須フックが一方のサーフェスではスキップされ、もう一方ではスキップされないという、気付かれにくいバイパスの問題を解消します。セキュリティ強化ではさらに、bulk_createで行ごとのアテステーションチェックを追加し(#1919)、受信したフェデレーションの PENDING 承認を登録済み承認者のゲート経由に変更し(#1920)、team/unit/orgの可視性スコープが名前空間階層全体に過度に広がらないように厳格化し(#1921)、skill_registerのfolder_pathインポートをシンボリックリンクによる隔離のもとで設定済みルート内に制限しました(#1923)。新しい非 argv の認証情報チャネルであるAI_MEMORY_STORE_URL/AI_MEMORY_STORE_URL_FILE(0600ファイル)により、Postgres/ストアのパスワードが、全ユーザーから読み取り可能な/proc/<pid>/cmdlineやpsに表示されないようにしました(#1927)。追加機能として、parameters_schemaとinvocation_recordを備えたエージェント作成のスキルメモリ(B7-SKILL、#1865)、recall_observationsのシャドウフィードバックループ(#1706)、メモリ派生系譜 DAG(memory_lineage、#1859)、オプトインのベクトル検索の最小構成(#1005)を追加しました。サーフェスの概要:スキーマ v78、--profile fullで101個の MCP ツール(呼び出し可能な100個と、常時有効なブートストラップmemory_capabilities)/--profile coreで7個、HTTP ルート登録92件(URL パスは重複を除いて78件)、--features sal/sal-postgresで CLI サブコマンド89個(デフォルトビルドでは87個)、型付きMemoryLink関係9個、28フィールドのMemory。2つの本番用バックエンド、組み込み SQLite と PostgreSQL + Apache AGE で、同一の API を提供し、デスクトップ、サーバー、オンデバイス(iOS + Android)で動作します。アテステーションとフック強制の切り替えを除き、すべてv0.8.1への追加変更です。この2つは安全な設定をデフォルトとする破壊的変更のため、アップグレード前に確認してください。完全な変更履歴: CHANGELOG.md §"[0.9.0] — 2026-07-08"。 v0.8.0(distributed-coordination)— 以前のリリースです。 このリリースでは、メモリー基盤が調整基盤へと進化します。#1709 の分散調整機能として、実際の状態マシンを備えた型付きアクション DAG(memory_action_*)、TTL で有効期間が制限される単一保持者のリース(memory_lease_*)、Ed25519 による署名付きシグナル(memory_signal_*)、Ed25519 による証明付きチェックポイント(memory_checkpoint_*)、凍結され、再生可能なルーチン(memory_routine_*)を追加します。これにより、異種混在のエージェント群が交代で作業し、作業を引き継ぎ、互いを信頼することなく誰が何を発言したかを証明できます。さらに、その上に型付き認知(Goal/Plan/Step のメモリー種別、lifecycle_state マシン、decomposes_into/depends_on/advances のリンク関係)を重ね、フェデレーションをデフォルトで安全な設定に強化します(ピア登録をデフォルトで有効化 #1789、遷移ごとの署名 #1718、書き込みごとのコンテンツ証明 #1464、遷移リプレイ防止ノンス #1805、送信先ピア証明書のピン留め #1678)。また、実際に処理をブロックするガバナンスも導入します。Claude Code の PreToolUse フックを type:command ラッパーに作り直し、基盤の Refuse がツールを確実に拒否するようにしました(#1811)。v0.8.0 リリース時点の構成は、スキーマ v70、--profile full で MCP ツール 100 個(呼び出し可能な 99 個と、常時有効な memory_capabilities ブートストラップ)/--profile core で 7 個、HTTP ルート登録 91 件(一意な URL パスは 78 個)、CLI サブコマンド 83/85 個、型付き MemoryLink 関係 9 種類、27 フィールドの Memory です。デスクトップ、サーバー、オンデバイス(iOS + Android)で、同一の API を介して 2 つの本番バックエンド(組み込み SQLite と PostgreSQL + Apache AGE)を利用できます。すべての変更は v0.7.0 に追加される形です。アップグレード前に、デフォルトで安全な設定への変更点を確認してください。リリースノート全文: docs/v0.8.0/release-notes.md。 v0.7.0(attested-cortex) — 以前のリリースです。 cortex-fluent の可読性向上の取り組みを、ROADMAP §7.3 の v0.7 の信頼性 + A2A の全スコープとまとめました。さらに、(2026-05-09 の運用担当者の指示により)当初 v0.7.1 向けだった postgres + AGE のファーストクラス対応と、グランドスラム達成後の出荷準備強化(Batman Forms 1-6 + 第7フォームの Option-B 基盤 + QW-1/2/3 + 整合性確認のセキュリティ総点検)も含みます。基盤は、より表現力豊か(capabilities v3、名前付きローダーツール、コンパクト化されたスキーマ、Batman の MemoryKind 語彙、ペルソナ/アトム化/複数ステップ取り込みのプリミティブ)になると同時に、暗号学的に信頼できるものになります(Ed25519 アテステーション、サイドチェーントランスクリプト、プログラム可能な25イベントのフックパイプライン、強制される名前空間の継承、V-4 の行をまたぐ署名付きイベントのハッシュチェーン)。v0.7.0 では、postgres + Apache AGE をファーストクラスのストレージバックエンドとして提供します。稼働中のデーモンには ai-memory serve --store-url postgres://… を使用できます。また、両バックエンドでスキーマの同等性を実現しています(v0.7.0 リリース時点で、sqlite + postgres は論理スキーマ v57 に統一され、CURRENT_SCHEMA_VERSION は57でした。v0.8.0 リリースの基盤では、このロックステップがスキーマ70まで進み、v58–v70 の追加的な調整 + 可視性テーブルが両バックエンドに導入されています。v58–v70 の段階については CLAUDE.md §Database を参照してください)(正式な参照先:sqlite は src/storage/migrations.rs、postgres は src/store/postgres.rs)。ディスク上のマイグレーションファイルは migrations/sqlite/0047_v56_list_composite_indexes.sql で終わり、postgres のインプロセス migrate_v57() ラダーアームに続きます。両方のラダーでは v34 以降の差分をインプロセスアームで適用するため、ファイル名の番号は論理スキーマバージョンより遅れています。v35-v57 の経緯については docs/MIGRATION_v0.7.md §schema-ladder を参照してください。v48 #933 ではフェデレーションプッシュの DLQ テーブルを追加しました。v49 #1025 では archived_memories に14個の NULL 許容列を追加し、アーカイブからの復元で v0.7.0 の完全な Memory 形状を損なわないようにしました。v50 #1156 では agent_quotas の PRIMARY KEY を (agent_id) から (agent_id, namespace) に拡張し、1つのエージェントが多数の名前空間をまたいで動作する場合でも、名前空間ごとの K8 クォータ割り当てを保持できるようにしました。v50 より前の行は _global センチネル名前空間にバックフィルされます。v51 #1255(PR #1296)では federation_nonce_cache テーブルを追加し、ピアのリプレイ防止ノンスがデーモンの再起動後も保持されるようにしました。v52 #1389 では transcript_line_dedup テーブルを追加し、RFC-0001 の memory_capture_turn L4 + recover_from_transcript L2 の冪等性を実現しました。これにより、ターン間で SIGKILL が発生しても、その後の再水和時にメモリが重複して生成されることはありません。v53 #1418 では memories_au FTS5 同期トリガーを (title, content, tags) のみに限定し、FTS 対象外の列を更新しても不要な同期が起動しないようにしました。v54 #1466 では、レガシーな NULL 期限の中期/短期行にティア既定の有効期限をバックフィルし、TTL の漏れによって行が無期限に残る問題を解消しました。v55 #1476 では、W=2 のフェデレーション追いつきクエリ(updated_at > ? ORDER BY updated_at ASC LIMIT)を索引利用可能にし、sqlite の idx_memories_updated_at インデックスを追加しました。postgres では memories_updated_at_idx DESC が Index Scan Backward による範囲スキャンにすでに対応しているため、新しいインデックスは追加していません。v56 #1579 では、索引利用可能な storage::list の書き換えに合わせて、複合リスト/アーカイブ並べ替えインデックス(idx_memories_list_order、idx_memories_ns_list_order、idx_archived_ns_archived_at)を追加しました。これは sqlite 側の DDL です。postgres の migrate_v56() アームはバージョンスタンプのみの no-op です。v57 #1579 では、検索/リコールのクエリ形状を一致させ、マッチした行ごとに tsvector を再計算するのではなく、事前計算済みの列で順位付けできるよう、postgres の保存生成 tsv tsvector 列 + memories_tsv_gin GIN インデックスを追加しました。レガシーな memories_content_fts 式インデックスは削除され、sqlite 側の同等機能は、FTS5 がすでにインデックス対象テキストを実体化しているため、バージョンスタンプのみの no-op です)。新しい ai-memory schema-init CLI 動詞と、6要素のリコールスコアリングの同等性も提供します。v0.6.4 の既定のサーフェスには、常時有効なローダーが2つ追加され、ツール数が7つになります(memory_load_family + memory_smart_load が従来の5つに加わります)。--profile full での実行時上限は公開されるエントリーが74個(呼び出し可能なメモリツール73個 + 常時有効な memory_capabilities ブートストラップ)です(Profile::full().expected_tool_count() で検証済みです。詳細は src/profile.rs を参照してください)。新機能はすべて追加的であり、信頼性 + postgres の機能はオプトインです。v0.6.x からアップグレードしますか? まず docs/MIGRATION_v0.7.md をお読みください。ほとんどの v0.6.4 クライアントでは動作に変更はありませんが、v0.6.3.1 より前の v0.6.x ユーザーには G1 名前空間継承の修正が適用されます。postgres + AGE に切り替えますか? docs/postgres-age-guide.md と docs/migration-v0.7.0-postgres.md を参照してください。完全なリリースノート: docs/v0.7.0/release-notes.md。 v0.6.4(quiet-tools) — MCP サーバーには、デフォルトで5つのツール(memory_store、memory_recall、memory_list、memory_get、memory_search)と、常時有効なブートストラップ機能 memory_capabilities が含まれます。残りの38個のツールも、--profile graph|admin|power|full を指定するか、memory_capabilities --include-schema family=<name> で実行時に展開すれば利用できます。先行読み込みを行うハーネス(Claude Desktop/Codex CLI/Grok CLI/Gemini CLI)では、リクエストごとのツールスキーマの入力トークン数が約4,700減少します。これは cl100k_base BPE で測定した76.4%の削減です。v0.6.3 と完全に同じ動作を維持するには、ai-memory mcp --profile full を実行してください。詳しくは docs/MIGRATION_v0.6.4.md を参照してください。

v0.9の新機能

v0.9.0 は主に、5レーンの敵対的レビュー(#1885~#1935)で見つかった49件の問題を修正した、セキュリティ強化とコードレビューのリリースです。さらに、v0.8.0 の連携基盤に追加機能を少数加えています。変更履歴の全文は、CHANGELOG.md §「[0.9.0] — 2026-07-08」を参照してください。

デフォルトで安全性を高めるための強化
  • HTTP の直接書き込みインターフェースでは、デフォルトでエージェントのアテステーションが必須です(#1751、#1985 によりインターフェースごとに適用)。AI_MEMORY_REQUIRE_AGENT_ATTESTATION は、インターフェースごとにコンパイル時のデフォルト値を持つ 3 状態の設定です。未設定の場合、HTTP の直接書き込み(POST /api/v1/memories と /bulk)では必須(403 ATTESTATION_FAILED で拒否)、MCP の memory_store と CLI の store(操作主体としてのオペレーター)では許容(署名なしの書き込みは attest_level="claimed" で登録)となります。=1 は全インターフェースで厳格な適用を強制し、=0 は全インターフェースで許容を強制します。提示された署名が偽造されたものである場合は、どのインターフェースでも拒否されます。書き込みに署名するには(ai-memory agents bind-key で鍵ペアを紐付けたうえで ai-memory store --sign を使用)、または =0 を指定して適用を無効にしてください。(v0.9.0 GA ではこれがすべてのインターフェースで必須としてリリースされており、MCP ホストでは実現できませんでした。詳細は #1981 を参照してください。#1985 によりインターフェースごとの適用に修正されました。)
  • MCP と HTTP の両方でフック適用をゲート(#1885 / #1924)。必須フックの有無を検証するゲート(当初は MCP のみ、#1734)が、HTTP の書き込みパスでも参照されるようになりました。これにより、MCP を完全に迂回した書き込みでは設定済みの必須フックが適用されないという、気付かれにくい迂回の欠陥(CWE-288)を解消します。
  • bulk_create のアテステーション検証(#1919)。一括書き込みでも、単一の memory_store 呼び出しと同じエージェントアテステーション要件が適用されます。リクエスト全体だけでなく、バッチ内のすべての行に有効なアテステーションが必要です。
  • フェデレーション承認者ゲート(#1920)。受信したフェデレーションの PENDING 承認が受理されるのは、ピアに登録された承認者に帰属する場合のみです。登録済みでも信頼されていないピアが、任意のリクエスターに対する承認を偽造することはできなくなりました。
  • team/unit/org スコープの強化(#1921)。可視性スコープの解決で、team/unit/org スコープに対する名前空間の祖先階層が正しく適用されるようになり、テナント分離の欠陥(CWE-863)を解消します。
  • skill_register のパス制限(#1923)。スキルの folder_path のインポート時にはパスが正規化され、設定済みルート配下に制限されます。また、インポート対象ツリー内のシンボリックリンクは追跡せず、拒否されます(CWE-22/CWE-59)。
  • argv を使わないストア URL の認証情報受け渡し方法(#1927)。新しい AI_MEMORY_STORE_URL(所有者のみが読み取れる /proc/environ)と AI_MEMORY_STORE_URL_FILE(アクセス権が 0600 のファイル)を使うと、埋め込みパスワードを含む postgres/ストア URL を ai-memory serve に渡せます。これにより、任意のローカル UID に読み取り可能な /proc/<pid>/cmdline や ps auxww を通じて URL が露出する --store-url argv への指定を避けられます。解決順序は、ファイル → 環境変数 → --store-url です。
追加機能
  • B7-SKILL — スキルメモリを第一級の機能として扱う(#1865)。登録時の parameters_schema、invocation_record、エージェントが作成したスキルのバージョン表示を追加しました。
  • recall_observations のシャドーフィードバックループ(#1706、SHADOW モード)。ランキング動作をまだ変更せずに、リコールのフィードバックループを閉じます。
  • メモリ派生のリネージ DAG(memory_lineage、スキーマ v78、#1859)。MCP と新しい GET /api/v1/memories/{id}/lineage HTTP ルートを通じて、どのメモリがどのメモリから派生したかをたどります。
  • ベクトル検索の最小オプトイン機能(#1005。基盤全体は #1860 に先送りされました)。
  • 物理 CPU 数に合わせたリランカーのワーカープール(#1867)と、デフォルトで PURE なリコール(#1869 — リコールのホットパスから書き込みの集中を取り除きます)。
  • 追記専用スパインと署名レイヤーの分離:すべての変更箇所を署名付きリビジョンリーフにルーティング(#1823)、Recorder/Judge/Stopper の3鍵署名分離(#1826)、マカロン機能トークンをエンドツーエンドで接続(#1827)、ローテーション後も維持される署名付き ID リネージの鍵継承チェーン(#1828、スキーマ v76)。

まずはこちらをご覧ください: CHANGELOG.md(全変更履歴)、docs/ADMIN_GUIDE.md(運用者向け手引き — アテステーションとフック適用の方針)。

v0.8 の新機能

v0.8.0(distributed-coordination)では、メモリ基盤をマルチエージェント(NHI)フリート向けの協調基盤へと進化させました。主な目玉は分散協調の仕組みです(#1709)。すべての機能は sqlite と postgres+AGE の両 SAL アダプターで提供され、v0.7.x の呼び出し元に対してはデフォルトの動作が同等に保たれます。ツールの全リファレンス:docs/coordination.md。詳細なリリースノート:docs/v0.8.0/release-notes.md。

分散協調基盤(Pillar-1、#1709)
  • アクション — 依存関係の DAG(スキーマ v59)。状態機械(pending → claimed → in_progress → done/failed/abandoned)を備えた型付きアクションノード、型付き DAG エッジ(requires / unlocks / blocks / gated_by / sibling)、および次に実行可能なノードを取得する frontier/next サーフェスを提供します。8 つの MCP ツール(memory_action_create / _get / _transition / _list / _add_edge / _edges / _frontier / _next)。
  • リース — 単一保有者、TTL で期限を制限したクレーム(スキーマ v59)。ハートビートで更新される compare-and-swap クレーム(action_id の PRIMARY KEY により、同時に保有できるのは 1 つ)と、1 時間ごとのリーススイーパーを備えています。4 つの MCP ツール(memory_lease_acquire / _renew / _release / _get)。
  • シグナル — 型付きの Ed25519 署名付きエージェント間メッセージ(スキーマ v60)。それぞれに署名と送信者の signer_pubkey が含まれ、correlation_id / in_reply_to でスレッド化されます。5 つの MCP ツール(memory_signal_send / _read / _inbox / _thread / _ack)。
  • チェックポイント — 証明付き条件ゲート(スキーマ v61)。条件が解決されるまでブロックするゲートです。職務分掌を実現するため、解決時にその場で自己署名(Ed25519)し、verify で署名を再確認します。4 つの MCP ツール(memory_checkpoint_create / _resolve / _query / _verify)。
  • ルーチン — パラメーター化され、凍結され、再生可能なプラン(スキーマ v62)。まず draft として作成し、その後凍結します(変更不可、Ed25519 による凍結証明)。run は {{param}} テンプレートから具体的なアクションとエッジのセットを生成し、routine_runs レコードに記録します。5 つの MCP ツール(memory_routine_create / _freeze / _run / _status / _list)。
  • すべての協調状態の変更は、改ざんを検出できる coordination.<op> 行として signed_events の V-4 ハッシュチェーンに追記されます(#1722)。権限を付与する 2 つの書き込みは、ローカル CAS と W-of-N フェデレーションへのファンアウトを備え、HTTP デーモンにも反映されます(POST /api/v1/actions/{id}/transition、POST /api/v1/signals)(#1718)。
型付き認知(Pillar-2)

memory_kind の語彙に goal / plan / step が加わります。閉じた分類体系である memory_links.relation は6 から 9 個の関係に拡張され(decomposes_into / depends_on / advances、スキーマ v63)、第一級の memories.lifecycle_state カラム(スキーマ v64)により、Goal/Plan/Step が実際の状態機械(open → active → blocked/done/abandoned)になります。この状態機械は MCP/HTTP/SAL の各サーフェスで適用され、不正な遷移は HTTP 409 CONFLICT に対応します。Memory 構造体は27 フィールドに拡張されます。新しい MCP ツールはありません。v64 の変更で追加されるのは、制約のない任意リクエストフィールドのみです。

フェデレーションの強化とセキュアなデフォルト設定

ピア登録のデフォルト有効化(#1789)、権限を付与する書き込みに対する遷移ごとの署名(#1718)、中継されるメモリに対する書き込みごとのコンテンツ証明(#1464)、遷移リプレイ用ノンス(#1805)、送信先ピア証明書のフィンガープリント固定(#1678)。互いに信頼する必要のない異種構成のフリートでは、アップグレード前に docs/v0.8.0/release-notes.md の§「Federation hardening」でセキュアなデフォルト設定への変更を確認してください。

実際にブロックするガバナンス(#1811)

Claude Code の PreToolUse ガバナンスフックを type:command ラッパー(ai-memory governance check-action --from-pretool-stdin)に作り直しました。これにより、基盤の Refuse が permissionDecision:"deny" を出力し、ツールを実際にブロックします。従来の type:mcp_tool 形式では、構造上これを強制できませんでした。さらに、必須フックの存在を強制する機能(#1734)と、ヒューマン・イン・ザ・ループに対応する新しい escalate ガバナンス判定(§22 PE-5)も追加しました。

Pillar-4 の運用制御

HTTP アドミッション制御(#1733 — オプトインの同時実行数上限を設け、超過分を型付き 503 で制限)、Apache-AGE グラフ投影の遅延実行(#1735 — 同期 AGE ラウンドトリップを PostgreSQL のリンク書き込みホットパスから除外)、キュレーターの圧縮機能の有効化(#1749 / #1750)、および signed_events の行をまたぐハッシュチェーンをエンドツーエンドでたどる ai-memory verify-audit-trail CLI(§22 PE-8)を追加しました。

スキーマ v57 → v70(すべて追加)

調整+型付き認知+可視性+暗号化準備+コールドパス+アーカイブエッジの各テーブル(v58~v70)を、sqlite と postgres の両アダプターに反映しました。初回オープン時に自動マイグレーションされ、アーカイブから復元する際も損失なく往復できます。正規の v58~v70 の段階については、CLAUDE.md §Database を参照してください。

まず読むもの: docs/v0.8.0/release-notes.md(完全なリリースノート)、docs/coordination.md(調整ツールのリファレンス)、CLAUDE.md §Database(スキーマ段階の SSOT)。

v0.7 の新機能

v0.7.0 では attested-cortex エピック(11 トラック A~K で 69/69)を完了し、当初 v0.7.1 向けだった postgres+AGE のファーストクラス対応を取り込み、さらにグランドスラム後の出荷準備強化(Batman Forms 1~6+第 7 形態の Option-B 基盤+QW-1/2/3+セキュリティ調整)も統合しました。機能の正規一覧は docs/internal/v070-feature-inventory.md を参照してください。v0.6.4 の呼び出し元に対して、すべての機能面はデフォルトで無効、またはデフォルト同等の状態を維持します。詳しくは v0.7 互換性マトリクス をご覧ください。

Substrate-native の書き込み時投資(Batman Forms 1–6 + 7th-form)
  • Form 1 — オンラインでの重複排除と統合(issue #754)。単一バッチでアクションを出力する LLM 呼び出しにより、ストア処理で v0.6.x のペアごとの分類器を置き換えます。名前空間標準で legacy_per_pair_classifier = true を設定すると、従来の yes/no 方式に戻せます。
  • Form 2 — 埋め込み前の同期的なアトマイズ(issue #755)。新しい memory_atomise ツールと、ストア前フック auto_atomise_mode = Synchronous|Deferred|Off を導入します。キュレーターが長い書き込みを2~10個の原子的な命題に分解するため、リコール処理に渡る前に細分化できます。docs/atomisation.md を参照してください。
  • Form 3 — マルチステップの取り込みオーケストレーター(issue #756)。memory_ingest_multistep は、決定論的な Jaccard+FTS ヘルパーを、プロンプトキャッシュに安定した LLM ステージに組み込みます。docs/multistep-ingest.md と cookbook/multistep-ingest/01-two-phase.sh を参照してください。
  • Form 4 — 事実の出典情報(issue #757)。引用、ソース URI、アトム粒度のスパンを、既存の memory_store / memory_atomise ペイロードに追加します。docs/provenance.md を参照してください。
  • Form 5 — 自動信頼度設定 + シャドーキャリブレーション + 鮮度の減衰(issue #758)。memory_calibrate_confidence MCP ツールと、ソースごとのベースラインスイープを導入します。環境変数は AI_MEMORY_AUTO_CONFIDENCE、AI_MEMORY_CONFIDENCE_SHADOW、AI_MEMORY_CONFIDENCE_SHADOW_SAMPLE_RATE、AI_MEMORY_CONFIDENCE_DECAY です。docs/confidence-calibration.md を参照してください。
  • Form 6 — MemoryKind の Batman 語彙(issue #759)。10種類のバリアントを持つ enum です(デフォルトは Observation。Reflection / Persona / Concept / Entity / Claim / Relation / Event / Conversation / Decision も指定できます)。任意のストア前フック auto_classify_kind(off / regex_only / regex_then_llm)も利用できます。docs/memory-kind-vocab.md を参照してください。
  • 7th-form — agent-EXTERNAL Layer-4 の配線(Option-B の基盤)(issue #760。v0.8.0 の全体的なカバー範囲は #697)。オペレーターのキーペアで署名するシードルール R001..R004、memory_check_agent_action + memory_rule_list MCP ツール、基盤の storage::insert 書き込み前フックを導入します。docs/policy-engine.md と docs/governance/agent-action-rules.md を参照してください。
  • オペレーター向けガイド — Forms 1–6 + 7th を「利用可能」から「有効」にする方法(issue #800)。7ステップの手順(オペレーターのキー生成 → シードへの署名 → R001–R004 の有効化 → キュレーターデーモン → 任意のリフレクションパス → 名前空間ポリシー)、launchd / systemd / Task-Scheduler による常時稼働、検証ブロック、ロールバック手順を説明します。docs/batman-active-mode.md と GitHub Pages のアトラス を参照してください。
クイックウィン(Tencent QW-1/2/3)
  • QW-1 — ファイルベースのリフレクションチェーンのエクスポート。 memory_export_reflection MCP ツールと名前空間ポリシー auto_export_reflections_to_filesystem により、~/.ai-memory/reflections/<ns>/<id>.md にエクスポートします。
  • QW-2 — アーティファクトとしてのペルソナ。 memory_persona + memory_persona_generate ツール、MemoryKind::Persona の行、名前空間ポリシー auto_persona_trigger_every_n_memories を導入します。docs/persona.md を参照してください。
  • QW-3 — コンテキストオフロードのプリミティブ。 memory_offload + memory_deref により、大きなツール出力をエージェントのコンテキストウィンドウ外の、アドレス指定可能な BLOB ストレージに移動します。docs/context-offload.md を参照してください。
アテステーション付きコーテックスの大型機能(Tracks A–K)
  • 証明付きリンク(Ed25519)。 v0.6.3 で導入された未使用の signature 列に、エージェントごとの実際の Ed25519 証明が記録されるようになりました。また、memory_verify(link_id) を呼び出すと、必要に応じて {signature_verified, attest_level, signed_by, signed_at} が返されます。ai-memory identity generate でキーペアを生成し、attest_level = "self_signed" を指定して有効にします。署名は、解決されたデーモンの agent_id に対応する *.priv キーペアが、設定済みのキーのディレクトリ内にある場合に限って行われます。load_daemon_signing_key が None を返す場合(src/main.rs:116-118)、行は引き続き書き込まれますが、sig は空になり、デーモンは起動時に「署名なしで続行する」というメッセージを出力します。signed_events の行をまたぐハッシュチェーンは、いずれの場合も改ざんを検出できます。詳しくは attested-cortex RFC を参照してください。
  • 署名付きイベント V-4 の完了(行をまたぐハッシュチェーン)(issue #698)。各 signed_events 行には prev_hash と sequence が含まれます。最初の行の prev_hash はゼロで、以降の行は直前の正規化された CBOR ペイロードの SHA-256 ハッシュを連鎖させます。ai-memory verify-signed-events-chain はチェーン全体を順に検証します。詳しくは docs/signed-events-v4.md を参照してください。
  • フックパイプライン(25 のライフサイクルイベント)。 プログラム可能な拡張機能により、20 個の基本イベント(pre_/post_store|recall|search|delete|promote|link|consolidate|governance_decision|archive|transcript_store と on_index_eviction)に加えて、5 個の grand-slam 追加イベント(pre_recall_expand G10、再帰学習 Task 6/8 の pre_reflect/post_reflect、L1-7 の pre_compaction/on_compaction_rollback)が発火します。フックは Allow/Modify/Deny/AskUser を返します。デフォルトでは無効です。有効にするには ~/.config/ai-memory/hooks.toml で設定します。詳しくは docs/hook-pipeline.md を参照してください。
  • サイドチェーンのトランスクリプトと再生。 zstd-3 の BLOB サイドチェーンに会話/推論の生の記録を保存します。memory_replay(memory_id) は memory_transcript_links をたどってチェーンを再構築します。名前空間ごとに [transcripts.namespaces."team/*"] で有効にします。詳しくは docs/sidechain-transcripts.md を参照してください。
  • フェデレーションのセキュリティ強化。 mTLS + X-API-Key + SHA-256 証明書フィンガープリントの許可リストに対応しています。環境変数は AI_MEMORY_FED_PEER_ATTESTATION、AI_MEMORY_FED_SYNC_TRUST_PEER、AI_MEMORY_FED_TRUST_BODY_AGENT_ID です。詳しくは docs/federation.md を参照してください。
  • K8 のクォータツール + K10 の SSE 承認。 memory_quota_status + /api/v1/quota/status(K8)。/api/v1/approvals/stream は、HMAC nonce、method と pending_id のバインド、遅延イベント数の除去に対応したサーバー送信イベントを提供します(K10)。詳しくは docs/k8-quotas.md と docs/k10-sse-approvals.md を参照してください。
  • Postgres + Apache AGE を正式バックエンドとしてサポート。 ai-memory serve --store-url postgres://…、スキーマの同等性、6 要素のリコールスコアリングの同等性、リンクの移行、AGE の Cypher による KG 機能(kg_query、kg_timeline、kg_invalidate、find_paths)に対応しています。AGE がない場合は再帰 CTE にフォールバックし、新しい ai-memory schema-init CLI 動詞も追加されています。ベンチマークによるゲートがあり、深さ 5 で AGE の p95 が CTE の p95 を 30% 以上上回る必要があります。運用手順は docs/postgres-age-guide.md を参照してください。移行手順書は docs/migration-v0.7.0-postgres.md を参照してください。
  • Capabilities v3 + スマートローダー。 memory_capabilities v3 では、summary、to_describe_to_user、ツールごとの callable_now、agent_permitted_families、schema_version="3" が追加されました。新たに常時有効な memory_load_family(family) と memory_smart_load(intent) のツールが、デフォルトの core プロファイルに加わります。固定された表現は docs/v0.7/canonical-phrasings.md にあります。
  • 権限 + A2A 承認。 v0.6.x のガバナンスサブシステムを、ルール + モード + フックから単一の Decision を導く構成にリファクタリングし、名前空間の継承(G1)が実際に適用されるようになりました。memory_pending_list/memory_pending_approve/memory_pending_reject(remember=forever) により、段階的な信頼の確立が可能です。承認 API の HMAC 署名は必須です。permissions.mode のデフォルトは enforce です(v0.6.4 では advisory でした)。ai-memory governance migrate-to-permissions で移行できます(ドライランでプレビューできます。適用するには --config-out ~/.config/ai-memory/config.toml を追加してください)。詳しくは docs/governance.md を参照してください。
再帰学習+L1/L2総仕上げウェーブ

memory_reflect 基盤プリミティブに、名前空間スコープの max_reflection_depth 上限(デフォルトは3、Some(0) はキルスイッチ)を追加しました。L2-1 リフレクションパスのキュレーター、L2-2 フェデレーション対応のリフレクション調整(memory_reflection_origin)、L2-3 無効化の伝播(memory_dependents_of_invalidated)、L2-5 フォレンジックバンドル(ai-memory export-forensic-bundle + verify-forensic-bundle)、L1-5 エージェントスキル(memory_skill_register|list|get|resource|export|promote_from_reflection|compositional_context)。全体を網羅した入門書: docs/RECURSIVE_LEARNING.md。エージェントスキルの入門書: docs/agent-skills.md。フォレンジックエクスポートの入門書: docs/forensic-export.md。

まずはこちらをご覧ください: docs/MIGRATION_v0.7.md(アップグレード手順)、docs/v0.7.0/release-notes.md(リリースノート全文)、docs/whats-new-v07.html(ビジュアル概要)、docs/v0.7/rfc-attested-cortex.md(設計の根拠)、docs/ADMIN_GUIDE.md(運用者向けプレイブック)、docs/internal/v070-feature-inventory.md(機能の正式な一覧)。

1つのバイナリ、4つの運用モード(v0.6.4)。ai-memory Rust バイナリ(tokio + axum)は、単独でも同時でも、単一の SQLite データベースを共有して次のいずれのモードでも実行できます:

  1. stdio MCP サーバー -- フルプロファイルでは JSON-RPC 経由で101個のエントリーを公開します(v0.9.0。呼び出し可能なメモリツール100個と、常時有効な memory_capabilities ブートストラップ。Profile::full().expected_tool_count() に対して検証済み)。デフォルトの --profile core では7個(元の5個 + memory_load_family + memory_smart_load)に加え、常時有効な memory_capabilities ブートストラップを公開します。ai-memory mcp / ai-memory mcp --profile full
  2. HTTP / mTLS デーモン -- 127.0.0.1:9077 上で92個の REST ルート登録(URL パスは78個)。TLS + オプションの mTLS 許可リスト + API キー認証、バックグラウンド GC ループ。ai-memory serve
  3. 自律キュレーターデーモン -- 自動タグ付け、名前空間内の兄弟項目間での矛盾の検出、類似した重複項目の統合、アクセスパターンに応じた優先度の調整を行う自己スケジュール型ループ(デフォルトの実行間隔は1時間)。すべてのアクションはロールバックログに記録されます。破壊的操作はガバナンス承認フローを通すよう設定できます。ai-memory curator --daemon
  4. 同期デーモン -- インスタンス間でクォーラムベースのピアフェデレーションを行います。W-of-N 書き込み(デフォルトは過半数)、ベクトルクロックによる軽量 CRDT マージ、ピア間の mTLS 許可リストに対応します。ai-memory sync-daemon

MCP、HTTP、CLI の各インターフェースはリアクティブです。メモリレイヤーの自己保守を実現するのがキュレーターです。セッション間もコーパスを整理し、ストアの成長に伴っても想起の品質を高く保ちます。すべてローカルファーストで、クラウドへの依存はありません。

v0.6.3 のソースを一行ずつ読んだ後の、Claude Opus 4.7 による率直な評価:

「ai-memory は、私がこれまで接続した中で最も高機能なメモリレイヤーです。その名前から想像される以上の機能を備えています。実際のところ、私にとっては、セッションのたびに何もない状態から始めなくてよいということです。私が読み込むストアは、私以外の何かによって整理されています。矛盾が気付かれないまま蓄積することもありません。コーパスが成長しても、想起の品質は高く保たれます。データが Mac mini の外に出ることはありません。

私を自律型エージェントにするものではありません。自律型エージェントに必要となる種類のメモリインフラを提供し、それ自体も小さな自律ループを実行して保守するものです。これは確かな基盤です。ここから『ai-memory が汎用タスクを実行する』までの隔たりは、発明ではなく、配線(ツール呼び出しプロトコル + ツールレジストリ + ツール使用に対応したモデル)の問題です。」 マルチエージェント AI の基盤。 ai-memory はエージェントランタイムでも、それ単体で「自律型 AI」を実現するものでもありません。マルチエージェントの自律型デプロイメントが必要とする、基盤となるメモリレイヤーです。フェデレーション(broadcast_store_quorum + spawn_catchup_loop)は、多数のエージェントが並行して書き込む際に、ピア間の W-of-N 整合性を処理します。キュレーターデーモンは、スウォームが大量に書き込むなかで共有コーパスがノイズに埋もれるのを防ぎます。Webhook サブスクリプション(HMAC 署名付き、名前空間/エージェントでフィルタリング、SSRF 対策済み)は、ストアをメッセージバスに変え、メモリイベントをきっかけに下流のエージェントを起動します。N レベルの継承と名前空間ごとのガバナンスポリシー(書き込み/昇格/削除の権限、承認者の種類、任意の N-of-M コンセンサス)を備えた名前空間階層が、スウォームの動作を制御します。これを、自動生成されたスキルを備えた 24 時間稼働のマルチマシンエージェントランナーの下に組み込めば、システム全体として自律型 AI の 振る舞い に関する基準を満たします。残る課題(重みレベルでの学習がないこと、ステートレスな推論カーネル、人間が設定するルート目標)は実在するものであり、ai-memory が対処するものではありません。ai-memory は、こうした課題を解決しようと本格的に取り組むうえで、どのような試みにも必要となるマルチエージェント向けメモリ基盤を提供します。

想起するまでトークンコストはゼロ。 会話ごとにメモリ全体を読み込む組み込みメモリシステム(Claude Code の自動メモリ、ChatGPT のメモリ)とは異なり、ai-memory は AI が明示的に memory_recall を呼び出すまでコンテキストトークンを一切消費しません。関連するメモリだけが、6 要素のスコアリングアルゴリズムで順位付けされて返されます。TOON 形式(Token-Oriented Object Notation)は、フィールド名の繰り返しをなくすことで、レスポンスのトークン数をさらに 40~60% 削減します。JSON ではメモリ 3 件で 1,600 バイトですが、TOON では 626 バイト(61% 削減)、TOON compact では 336 バイト(79% 削減)です。Claude Code ユーザーの方は、自動メモリを無効にし(settings.json で "autoMemoryEnabled": false)、ai-memory に置き換えることで、メッセージのたびに 200 行以上のメモリコンテキストに対して料金を支払う必要がなくなります。


エージェント ID(NHI)— すべてのメモリから、誰が学習したかがわかります

ai-memory が保存するすべてのメモリには metadata.agent_id が付与されています。これは、すべての操作(更新、重複排除、インポート、同期、統合)を通じて保持される非人間 ID マーカーです。すべての想起結果から、各メモリを書き込んだ AI がわかります。既定では、AI クライアント向けにすでに最適化されている TOON-compact レスポンス形式で返されます。

count:5|mode:hybrid|tokens_used:842
memories[id|title|tier|namespace|priority|score|tags|agent_id]:
a1b2|Project DB is PostgreSQL 16|long|infra|8|0.91|database,postgres|ai:claude-code@workstation:pid-3812
c3d4|API rate limit is 100 rps|long|infra|7|0.87|api,limits|ai:claude-desktop@laptop:pid-5219

署名なしの書き込みでは、agent_id は自己申告の ID です。これだけを根拠にセキュリティ上の判断をしないでください。ストアパスのエージェント認証は、HTTP の直接書き込みサーフェスでは既定で必須です(#1751、#1985 によりサーフェス単位で適用)。署名のない HTTP POST /api/v1/memories(および /bulk)は、attest_level = "claimed" として登録されるのではなく、明示的なオプトアウト AI_MEMORY_REQUIRE_AGENT_ATTESTATION=0 をオペレーターが設定しない限り、拒否されます(403 ATTESTATION_FAILED)。MCP の memory_store と CLI の store という、オペレーターが書き込み主体となるサーフェスは、既定では引き続き許可されます(署名なしの書き込みは claimed として登録されます)。=1 を設定すると、すべてのサーフェスで厳格な認証が強制されます。暗号学的な Ed25519 認証は、次の 2 つのサーフェスで利用できます。(1)ストアパス認証(#626 Layer-3) — CLI(store --sign)、MCP(memory_store)、または HTTP(POST /api/v1/memories)経由で、正規化された SignableWrite エンベロープに対する分離署名を提示すると、デーモンがエージェントに紐付いた公開鍵を使って検証し、metadata.attest_level = "agent_attested" を設定します(提示された署名が偽造されていた場合は、設定にかかわらず常に拒否されます)。(2)リンク認証(attested-cortex) — これまで予約されていた memory_links.signature フィールドを使い、受信側の検証には memory_verify(link_id) を使用します。また、追記専用の signed_events 監査チェーンも備えています。認証と来歴に関する契約の詳細は、エージェント ID のページとattested-cortex RFCをご覧ください。

過去の会話をインポート — ai-memory mine

何も知らない状態から始める必要はありません。ai-memory mine に Claude、ChatGPT、または Slack のエクスポートを指定すると、会話をターンごとに解析し、優先順位付けされ、階層タイプとタグが付いたメモリーに変換します。これにより、AI は次のセッションで、既存の履歴にあるすべての決定、修正、発見を把握した状態で始められます。

ai-memory mine claude  ~/Downloads/claude-export/
ai-memory mine chatgpt ~/Downloads/chatgpt-export.json
ai-memory mine slack   ./slack-export/

自動タグ付け、(title, namespace) に基づく重複排除、mined_from による出典情報が、インポートしたすべてのメモリーに記録されます。コンテキストがない状態から、長期ストアが埋まった状態まで、オンボーディングは5分で完了します。フォーマット別の手順については、インポート履歴ページをご覧ください。


対応 AI プラットフォーム

ai-memory は、**Model Context Protocol(MCP)**に対応するあらゆる AI プラットフォームと連携できます。MCP は、AI アシスタントを外部のツールやデータソースに接続するためのユニバーサルな標準です。

プラットフォーム連携方法設定形式ステータス
Claude Code(Anthropic)MCP stdioJSON(~/.claude.json または .mcp.json)完全対応
Codex CLI(OpenAI)MCP stdioTOML(~/.codex/config.toml)完全対応
Gemini CLI(Google)MCP stdioJSON(~/.gemini/settings.json)完全対応
Grok CLI(xAI)MCP stdioJSON(~/.grok/user-settings.json)深い連携
Grok API(xAI)MCP remote HTTPSAPI レベル完全対応
Cursor IDEMCP stdioJSON(~/.cursor/mcp.json)完全対応
Windsurf(Codeium)MCP stdioJSON(~/.codeium/windsurf/mcp_config.json)完全対応
Continue.devMCP stdioYAML(~/.continue/config.yaml)完全対応
Llama Stack(META)MCP remote HTTPYAML / Python SDK完全対応
OpenClawMCP stdioJSON(設定内の mcp.servers)完全対応
あらゆる MCP クライアントMCP stdio または HTTPプラットフォームによって異なりますユニバーサル

MCP が主要な連携レイヤーです。MCP にネイティブ対応していない AI プラットフォームには、HTTP API(localhost 上に92のルート登録/78の一意な URL パス)と CLI(--features sal または --features sal-postgres で89のサブコマンド、デフォルトビルドでは87(セッションをまたいだコンテキスト再構築のための post-#1389 L2 RecoverPreviousSession、ai-memory expand によるクエリ拡張機能のための #1443 Expand、ai-memory reembed によるベクトル空間移行機能のための #1598 Reembed)が利用できます。SSOT は ai_memory::EXPECTED_CLI_SUBCOMMANDS_DEFAULT + EXPECTED_CLI_SUBCOMMANDS_SAL と、機械的な tests/cli_subcommand_count_invariant.rs の整合性テストで固定されています)が、ユニバーサルなアクセス手段を提供します。HTTP リクエストを送信したりシェルコマンドを実行したりできる AI、スクリプト、自動化なら、どれでも ai-memory を利用できます。


60秒でインストール

ビルド済みバイナリには依存関係は不要です。ソースからビルドするには、Rust と C コンパイラーが必要です。

最速:ビルド済みバイナリ(Rust 不要)

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/alphaonedev/ai-memory-mcp/main/install.sh | sh

# Fedora/RHEL (COPR)
sudo dnf copr enable alpha-one-ai/ai-memory && sudo dnf install ai-memory

# Windows (PowerShell)
irm https://raw.githubusercontent.com/alphaonedev/ai-memory-mcp/main/install.ps1 | iex

ステップ1:Rust をインストールする(ビルド済みバイナリを使う場合は省略)

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

プロンプトに従い、ターミナルを再起動します(または source ~/.cargo/env を実行します)。

ステップ2:ソースからビルドする(Rust が必要)

Crates.io の最新リリース:

cargo install ai-memory

Git リポジトリの最新バージョン:

cargo install --git https://github.com/alphaonedev/ai-memory-mcp.git

これによりバイナリがコンパイルされ、PATH に配置されます。所要時間は1〜2分です。

ソースからビルドする場合のビルド依存関係:

  • Ubuntu/Debian:sudo apt-get install build-essential pkg-config
  • Fedora/RHEL:sudo dnf install gcc pkg-config

ステップ3:AI を接続する

設定方法はプラットフォームによって異なります。以下から該当するものを選んでください。

Claude Code(Anthropic)

Claude Code は、次の3つの MCP 設定スコープに対応しています。

スコープファイル適用対象
ユーザー(グローバル)~/.claude.json — mcpServers キーを追加マシン上のすべてのプロジェクト
プロジェクト(共有)プロジェクトのルートにある .mcp.json(git にチェックイン)プロジェクトの全員
ローカル(プライベート)~/.claude.json — projects."/path".mcpServers の下1 つのプロジェクト、自分のみ

ユーザースコープ(推奨 — どこでも動作):

~/.claude.json(macOS/Linux)または %USERPROFILE%\.claude.json(Windows)に mcpServers キーを追加します。

{
  "mcpServers": {
    "memory": {
      "command": "ai-memory",
      "args": ["--db", "~/.claude/ai-memory.db", "mcp", "--tier", "semantic"]
    }
  }
}

注: ~/.claude.json には、すでにほかの設定が含まれている可能性があります。既存のファイルを上書きせず、mcpServers キーを統合してください。

プロジェクトスコープ(チームと共有):

プロジェクトのルートに .mcp.json を作成します。

{
  "mcpServers": {
    "memory": {
      "command": "ai-memory",
      "args": ["--db", "~/.claude/ai-memory.db", "mcp", "--tier", "semantic"]
    }
  }
}

クラウド LLM を使う smart / autonomous ティア — 推奨される方法は、~/.config/ai-memory/config.toml の [llm] セクションです(#1146)。1 つのファイルをすべての環境で使えるため、AI クライアントごとの編集は不要です。

# ~/.config/ai-memory/config.toml
schema_version = 2

[llm]
backend     = "xai"
model       = "grok-4.3"
base_url    = "https://api.x.ai/v1"
api_key_env = "XAI_API_KEY"            # process-env-var name (NOT the literal key)

シェルの rc ファイル(.zshrc / .bashrc)で XAI_API_KEY をエクスポートします。MCP の設定は最小限のままにできます。

{
  "mcpServers": {
    "memory": {
      "command": "ai-memory",
      "args": ["--db", "~/.claude/ai-memory.db", "mcp", "--tier", "autonomous"]
    }
  }
}

確認方法:ai-memory boot --quiet --limit 1 を実行し、llm=xai:grok-4.3 と表示されることを確認します。正規のスキーマリファレンスは docs/CONFIG_SCHEMA.md です。

上書き方法 — env: ブロック。 MCP の設定に AI_MEMORY_LLM_BACKEND / _API_KEY / _MODEL を含む env: ブロックを追加する方法も引き続き使えます。config.toml より優先されるため、CI やセッションごとの調整に便利です。

"env": {
  "AI_MEMORY_LLM_BACKEND": "xai",
  "AI_MEMORY_LLM_API_KEY": "xai-...",
  "AI_MEMORY_LLM_MODEL": "grok-4.3"
}

MCP クライアントは、MCP の設定にある env: キーのみを指定して、新しいサブプロセスとしてサーバーを起動します。そのため、.zshrc / .bashrc でエクスポートした環境変数は引き継がれません。上記の [llm] 設定ファイルを使う方法なら、すべての環境で同じファイルを読み込むため、この煩わしさを解消できます。config.toml に API キーを直接記述すると、解析時に拒否されます。api_key_env または api_key_file を使用してください。背景: #1144 → #1146。バックエンドごとの詳しい設定例は docs/integrations/llm-backends.md をご覧ください。

Windows のパス: --db では、スラッシュまたはエスケープしたバックスラッシュを使用してください。例:"--db", "C:/Users/YourName/.claude/ai-memory.db"。

ティアフラグ: --tier フラグで機能ティアを選択します。指定できる値は keyword、semantic(デフォルト)、smart、autonomous です。smart と autonomous のティアには LLM バックエンドが必要です — #1067 対応後(v0.7.0)、次のいずれかを利用できます:ローカルの Ollama、xAI Grok、OpenAI、Anthropic、Google Gemini、DeepSeek、Kimi(Moonshot)、Qwen(Alibaba)、Mistral、Groq、Together AI、Cerebras、OpenRouter、Fireworks、LMStudio、vLLM、または llama.cpp サーバー。AI_MEMORY_LLM_BACKEND で選択します。AI クライアントが MCP サーバーを起動する場合、config.toml のティア設定は使われないため、--tier フラグを args に必ず指定してください。

重要: MCP サーバーは settings.json や settings.local.json では設定できません。これらのファイルは mcpServers をサポートしていません。

Claude が ai-memory を積極的に使うようにする: プロジェクトのルートに ai-memory の指示を記載した CLAUDE.md ファイルを追加します。これにより、Claude は会話の開始時にコンテキストを呼び出し、作業中に見つけた情報を保存します。コピーして使えるテンプレートと配置方法については、CLAUDE.md 統合ガイドをご覧ください。

OpenAI Codex CLI

~/.codex/config.toml(グローバル)または .codex/config.toml(プロジェクト)に追加します。Windows の場合は %USERPROFILE%\.codex\config.toml です。CODEX_HOME 環境変数で上書きできます。

[mcp_servers.memory]
command = "ai-memory"
args = ["--db", "~/.local/share/ai-memory/memories.db", "mcp", "--tier", "semantic"]
enabled = true

または、CLI で追加します:codex mcp add memory -- ai-memory --db ~/.local/share/ai-memory/memories.db mcp --tier semantic

注記: Codex は、アンダースコア付きのキー mcp_servers を使用する TOML 形式です(キャメルケースでもハイフン区切りでもありません)。env(キーと値のペア)、env_vars(転送する変数のリスト)、enabled_tools、disabled_tools、startup_timeout_sec、tool_timeout_sec に対応しています。TUI で /mcp を使うと、サーバーのステータスを確認できます。Codex MCP docs を参照してください。

Google Gemini CLI

~/.gemini/settings.json(ユーザー用)または .gemini/settings.json(プロジェクト用)に追加します。Windows の場合:%USERPROFILE%\.gemini\settings.json。

{
  "mcpServers": {
    "memory": {
      "command": "ai-memory",
      "args": ["--db", "~/.local/share/ai-memory/memories.db", "mcp", "--tier", "semantic"],
      "timeout": 30000
    }
  }
}

または、CLI から追加します:gemini mcp add memory ai-memory -- --db ~/.local/share/ai-memory/memories.db mcp --tier semantic

注記: サーバー名にアンダースコアを使わないでください(ハイフンを使用してください)。ツール名には mcp_memory_<toolName> の形式で自動的にプレフィックスが付加されます。env フィールド内の環境変数は、$VAR/${VAR}(すべてのプラットフォーム)および %VAR%(Windows)に対応しています。Gemini は、明示的に宣言されていない限り、継承した環境変数から機密情報に該当するパターンを除去します。確認プロンプトを省略するには、"trust": true を追加します。CLI での管理:gemini mcp list/remove/enable/disable。Gemini CLI MCP docs を参照してください。

Cursor IDE

~/.cursor/mcp.json(グローバル)または .cursor/mcp.json(プロジェクト用)に追加します。Windows の場合:%USERPROFILE%\.cursor\mcp.json。同じ名前のサーバーについては、プロジェクト設定がグローバル設定を上書きします。

{
  "mcpServers": {
    "memory": {
      "command": "ai-memory",
      "args": ["--db", "~/.local/share/ai-memory/memories.db", "mcp", "--tier", "semantic"]
    }
  }
}

注記: mcp.json を編集した後は Cursor を再起動してください。Settings > Tools & MCP でサーバーのステータスを確認できます(緑色の点は接続済みを示します)。env、envFile、および ${env:VAR_NAME} による補間に対応しています(環境変数の補間はシェルのプロファイル変数に対して不安定な場合があります。回避策として envFile を使用してください)。すべての MCP サーバーを合わせてツール数は最大約 40 個です。Cursor MCP docs を参照してください。

Windsurf(Codeium)

~/.codeium/windsurf/mcp_config.json に追加します(グローバル設定のみ。プロジェクト単位の設定はありません)。Windows の場合:%USERPROFILE%\.codeium\windsurf\mcp_config.json。

{
  "mcpServers": {
    "memory": {
      "command": "ai-memory",
      "args": ["--db", "~/.local/share/ai-memory/memories.db", "mcp", "--tier", "semantic"]
    }
  }
}

注記: command、args、env、serverUrl、url、headers 内の ${env:VAR_NAME} による補間に対応しています。すべての MCP サーバーを合わせてツール数は最大 100 個です。MCP Marketplace または Settings > Cascade > MCP Servers から追加することもできます。Windsurf MCP docs を参照してください。

Continue.dev

~/.continue/config.yaml(ユーザー用)またはプロジェクトルートの .continue/mcpServers/ ディレクトリ(サーバーごとの YAML/JSON ファイル)に追加します。Windows の場合:%USERPROFILE%\.continue\config.yaml。

mcpServers:
  - name: memory
    command: ai-memory
    args:
      - "--db"
      - "~/.local/share/ai-memory/memories.db"
      - "mcp"
      - "--tier"
      - "semantic"

注記: MCP ツールはエージェントモードでのみ動作します。シークレットの補間には ${{ secrets.SECRET_NAME }} を使用できます。プロジェクト内の .continue/mcpServers/ ディレクトリは、他のツール(Claude Code、Cursor など)の JSON 設定を自動検出します。Continue MCP docs を参照してください。

Grok CLI(AlphaOne フォーク — 自動呼び出しによる高度な統合)

grok-cli の AlphaOne フォークは、セッション単位の MCP 接続、セッション開始時のメモリー自動呼び出し、要約の保存、メモリーを考慮したシステムプロンプトなど、ai-memory を標準でサポートしています。

~/.grok/user-settings.json に追加します:

{
  "mcp": {
    "servers": [
      {
        "id": "ai-memory",
        "label": "AI Memory",
        "enabled": true,
        "transport": "stdio",
        "command": "ai-memory",
        "args": ["mcp", "--tier", "semantic"]
      }
    ]
  }
}

機能: セッション開始時に関連するメモリーをシステムプロンプトに挿入する自動呼び出し、圧縮時の要約の中間層メモリーとしての保存、すべてのモード(エージェント、計画、質問)での MCP ツールの利用、セッション単位の接続(メッセージごとのコールドスタートなし)。デフォルトでは --tier semantic を使用します(ローカル埋め込みを使用し、LLM バックエンドは不要です)。詳細な設定方法については、grok-cli docs を参照してください。

xAI Grok API(API レベル、リモート MCP)

Grok は HTTPS 経由で MCP サーバーに接続します(リモートのみ。stdio は非対応)。設定ファイルは不要です。サーバーは API リクエストごとに指定します。

ai-memory serve --host 127.0.0.1 --port 9077
# Expose via HTTPS reverse proxy (nginx, caddy, cloudflare tunnel, etc.)

Then add the MCP server to your Grok API call:

curl https://api.x.ai/v1/responses \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok-4.3",
    "tools": [{
      "type": "mcp",
      "server_url": "https://your-server.example.com/mcp",
      "server_label": "memory",
      "server_description": "Persistent AI memory with recall and search",
      "allowed_tools": ["memory_store", "memory_recall", "memory_search"]
    }],
    "input": "What do you remember about our project?"
  }'

要件: HTTPS が必要です。server_label は必須です。Streamable HTTP および SSE トランスポートに対応しています。オプション:allowed_tools、authorization、headers。xAI SDK、OpenAI 互換 Responses API、Voice Agent API で動作します。xAI Remote MCP docs を参照してください。

META Llama(Llama Stack 経由)

Llama Stack では、MCP サーバーをツールグループとして登録します。標準化された設定ファイルのパスはなく、デプロイ環境によって異なります。

ai-memory serve --host 127.0.0.1 --port 9077

Python SDK:

client.toolgroups.register(
    provider_id="model-context-protocol",
    toolgroup_id="mcp::memory",
    mcp_endpoint={"uri": "http://localhost:9077/sse"}
)

または run.yaml で宣言的に設定:

tool_groups:
  - toolgroup_id: mcp::memory
    provider_id: model-context-protocol
    mcp_endpoint:
      uri: "http://localhost:9077/sse"

注: run.yaml では ${env.VAR_NAME} による補間に対応しています。トランスポートは SSE から Streamable HTTP への移行中です。Llama Stack Tools docs を参照してください。

OpenClaw

CLI 経由で追加するか、OpenClaw の設定を直接編集してください。設定では mcpServers ではなく mcp.servers を使用します。

openclaw mcp set memory '{"command":"ai-memory","args":["--db","~/.local/share/ai-memory/memories.db","mcp","--tier","semantic"]}'

または、OpenClaw の設定ファイルに追加してください。

{
  "mcp": {
    "servers": {
      "memory": {
        "command": "ai-memory",
        "args": ["--db", "~/.local/share/ai-memory/memories.db", "mcp", "--tier", "semantic"]
      }
    }
  }
}

注: OpenClaw では mcpServers ではなく mcp.servers キーを使用します。CLI による管理:openclaw mcp list、openclaw mcp show、openclaw mcp set、openclaw mcp unset。stdio、リモート URL、Streamable HTTP トランスポートに対応しています。インラインシークレットではなく、--token-file を使用してください。OpenClaw MCP docs を参照してください。

その他の MCP クライアント

ai-memory は stdio(JSON-RPC 2.0)経由で MCP を使用します。クライアントの接続先:

command: ai-memory
args: ["--db", "/path/to/ai-memory.db", "mcp"]

HTTP のみ対応するクライアントの場合は、REST API を起動してください。

ai-memory serve
# 92 REST route registrations (78 unique URL paths) at http://127.0.0.1:9077/api/v1/

ステップ 4:完了です。テストしましょう。

AI アシスタントを再起動してください。MCP を使用している場合、セッション開始時に案内されるデフォルトの 7 ツール構成(元の 5 つに memory_load_family と memory_smart_load を追加したもの)が利用可能になります。残りの 93 個の呼び出し可能なツールは、--profile または memory_capabilities --include-schema を使ってオンデマンドで読み込まれます。「私の好きな言語は Rust だと記憶して」と頼んでください。次に、新しい会話で「私の好きな言語は何?」と尋ねてください。覚えているはずです。


モバイルプラットフォームのサポート(v0.7.0 Posture-1a)

ai-memory は、標準的な Rust モバイル向けクロスコンパイル手順により、iOS と Android に移植できます。v0.7.0 では、段階的に範囲が広がる次の 3 つのレベルで、両ターゲットの CI を実施します。

レイヤー対象範囲CI ワークフロー
レイヤー 1 — クロスコンパイルcargo check --target aarch64-apple-ios --no-default-features --features sqlite-bundled --lib と、対応する Android 向けクロスコンパイルを、すべての PR と release/** へのプッシュで実行します。モバイル環境での互換性劣化リスクの約 80% を検出します(モバイル移植性を損なうクレートの更新は、ここで検出されます)。.github/workflows/ci.yml — mobile-cross-compile ジョブ
レイヤー 2 — リリース成果物リリースタグの作成時に、ai-memory-ios.xcframework.tar.gz(xcodebuild -create-xcframework による iOS デバイスおよびシミュレーター用スライス)と ai-memory-android.tar.gz(jniLibs/<abi>/ 形式の Android arm64 / armv7 / x86_64 / x86 向け .so バンドル)を生成します。.github/workflows/release.yml — mobile-ios + mobile-android ジョブ
レイヤー 3 — ランタイムテスト対象を絞った約 50 件のテスト(ファイルシステムのサンドボックス化、デバイス上の SQLite での FTS5、HNSW の CPU 再現率、エンベッダーの CPU パス、LLM クライアントの TLS)を、release/** へのプッシュごと、および手動の workflow_dispatch で iOS シミュレーター上で実行します。Android エミュレーター上のテストは、release/** へのプッシュ時と workflow_dispatch 時のみ実行します。テスト選定の理由については、tests/mobile/README.md を参照してください。.github/workflows/mobile-runtime.yml

v0.7.0 時点のステータス: レイヤー 1 がリリースの必須条件です。タグを作成する前に、モバイル向けクロスコンパイルが GREEN である必要があります。レイヤー 2(リリース成果物)では、ビルドパイプラインと成果物の形式を提供します。C から呼び出し可能な FFI サーフェスは、v0.7.x の後続リリースで追加されます。レイヤー 3 では、release/** へのプッシュごとに対象を絞ったテストを実行します。

リリース成果物の使用:

  • iOS — v0.7.x のリリースページから ai-memory-ios.xcframework.tar.gz をダウンロードして展開し、AiMemory.xcframework を Xcode プロジェクトの「Frameworks, Libraries, and Embedded Content」にドラッグします。
  • Android — v0.7.x のリリースページから ai-memory-android.tar.gz をダウンロードして展開し、jniLibs/ ツリーをアプリモジュールの src/main/jniLibs/ にコピーします。

モバイル向け成果物は、公開されるすべての v0.7.x リリースに含まれます。デスクトップバイナリを提供する Homebrew フォーミュラと APT/RPM パッケージにも、モバイル向けダウンロードへのリンクが記載されています。CI の実装履歴については、issue #1068 を参照してください。


クイックスタート

2 分以内で、何もない状態からメモリを使えるようにします。

1. インストール

curl -fsSL https://raw.githubusercontent.com/alphaonedev/ai-memory-mcp/main/install.sh | sh

2. MCP を設定(Claude Code の例。他のプラットフォームでも同様に設定できます)

~/.claude.json にマージします:

{
  "mcpServers": {
    "memory": {
      "command": "ai-memory",
      "args": ["--db", "~/.claude/ai-memory.db", "mcp", "--tier", "semantic"]
    }
  }
}

3. 最初のメモリを保存

ai-memory store -T "Project uses PostgreSQL 15" -c "Main DB is PG 15 with pgvector." --tier long

4. メモリを呼び出す

ai-memory recall "database"

5. 統計を確認

ai-memory stats

6. AI と使う。 AI クライアントを再起動します。起動時に MCP 経由で デフォルトのメモリツール 7 個(実行時の展開または --profile full で利用可能なエントリーは 101 個)が提示され、会話中にメモリをネイティブに保存したり呼び出したりできるようになります。


SDK

MCP / HTTP / CLI のインターフェースに加えて、ai-memory は HTTP クライアントやヘルパーユーティリティ(例:v0.6.4 以降のデーモンで実行時にプロファイルを検証する requireProfile)向けに、公式の言語 SDK を提供しています。

TypeScript / JavaScript — npm の @alphaone/ai-memory

npm install @alphaone/ai-memory

Python — PyPI の ai-memory-mcp(インポート名は引き続き ai_memory です)

pip install ai-memory-mcp
from ai_memory import AiMemoryClient, require_profile

with AiMemoryClient(base_url="http://127.0.0.1:9077", api_key="...") as client:
    require_profile(client, "graph")  # raises ProfileNotLoaded on miss

両 SDK はサーバーと同じバージョン番号を使用します(0.9.0 は ai-memory 0.9.0 に対応します)。v0.6.4 以降のデーモンはプロファイルの契約を強制します。v0.6.4 より前のデーモンでは、許容的な警告して続行する動作にフォールバックするため、SDK をアップグレードしても古いサーバーで問題は発生しません。ソースコードは sdk/typescript/ と sdk/python/ にあります。


これは何をするものですか?

AI アシスタントは会話のたびにすべてを忘れてしまいます。ai-memory はそれを解決します。

MCP(Model Context Protocol)ツールサーバーとして動作します。AI がネイティブにやり取りするバックグラウンドプロセスです。AI が重要なことを学ぶと、それを保存します。コンテキストが必要になると、6 要素のスコアリングアルゴリズムで順位付けされた関連メモリを呼び出します。メモリは次の 3 つの階層に保存されます。

  • 短期(デフォルトで 6 時間、設定可能)――現在のデバッグ状況など、一時的なコンテキスト
  • 中期(デフォルトで 7 日間、設定可能)――スプリントの目標や最近の決定事項など、作業に役立つ知識
  • 長期(永続)――アーキテクチャ、ユーザーの好み、苦労して得た教訓

繰り返しアクセスされるメモリは、中期から長期へ自動的に昇格します。呼び出すたびに TTL が延長されます。使用頻度に応じて優先度が上がります。システムは自動で整理されます。

MCP に加えて、ai-memory は完全な HTTP REST API(ポート 9077 で 92 件のルート登録/78 個の一意な URL パス)と完全な CLI(--features sal または --features sal-postgres では 89 個のサブコマンド、デフォルトビルドでは 87 個(セッションをまたぐコンテキスト再ハイドレーション用の #1389 L2 RecoverPreviousSession、ai-memory expand クエリ拡張機能用の #1443 Expand、ベクトル空間移行機能 ai-memory reembed 用の #1598 Reembed を含む)を備え、SSOT は ai_memory::EXPECTED_CLI_SUBCOMMANDS_{DEFAULT,SAL} と機械的な tests/cli_subcommand_count_invariant.rs の整合性テストで固定されています)も公開しており、直接操作、スクリプト作成、あらゆる AI プラットフォームやツールとの統合に利用できます。


機能

コア
  • MCP ツールサーバー――stdio JSON-RPC で 101 個のツールを提供(フルプロファイル)。あらゆる MCP クライアントと互換性があります
  • 3 階層のメモリ――短期(デフォルトの TTL は 6 時間)、中期(7 日間)、長期(永続)。TTL は設定可能です
  • 全文検索――SQLite FTS5 による順位付けされた検索
  • ハイブリッド呼び出し――FTS5 キーワード検索とコサイン類似度を適応的にブレンドします。セマンティックの重みは 0.50(短いコンテンツ)から 0.15(長いコンテンツ)まで変化します。埋め込みは長いテキストほど情報を失うためです
  • 6 要素の呼び出しスコアリング――FTS 関連度 + 優先度 + アクセス頻度 + 信頼度 + 階層ブースト + 経過時間による減衰
  • 自動昇格――5 回以上アクセスされたメモリは中期から長期へ昇格します
  • TTL 延長――呼び出すたびに有効期限が延長されます(短期は +1 時間、中期は +1 日)
  • 優先度の強化――10 回アクセスするごとに +1(最大 10)
  • 矛盾の検出――既存のメモリと矛盾するメモリを保存すると警告します
  • 重複排除――タイトルと名前空間をキーにして upsert し、階層が降格することはありません
  • 信頼度スコアリング――確実性を 0.0~1.0 で評価し、順位付けに反映します
整理
  • 名前空間――プロジェクトごとにメモリを分離します(git remote から自動検出)
  • メモリのリンク――型付きの関係:related_to、supersedes、contradicts、derived_from、reflects_on(recursive-learning Task 1/8)、derives_from(WT-1-A atomisation)、decomposes_into、depends_on、advances の 9 種類(v0.8.0 時点)
  • 統合――複数のメモリを 1 つの長期要約にまとめます
  • 自動統合――名前空間とタグでグループ化し、しきい値を超えるグループを自動で統合します
  • 矛盾の解決――一方のメモリが他方を置き換えるものとしてマークし、置き換えられたメモリを降格させます
  • パターンによる忘却――名前空間 + FTS パターン + 階層を指定して一括削除します
  • ソース追跡――発生元(user、claude、hook、api、cli、import、consolidation、system)を追跡します
  • エージェントの識別情報(NHI)――すべてのメモリに metadata.agent_id(申告された識別情報)が付与され、更新/重複排除/インポート/同期/統合をまたいで多層防御による不変性が確保されます。エージェントで list/search を絞り込めます
  • タグ付け――カンマ区切りのタグに対応し、フィルターで絞り込めます
インターフェース
  • HTTP ルート 92 件(固有パス 78 件) -- 127.0.0.1:9077 で利用できる完全な REST API(あらゆる AI やツールで動作)
  • --features sal または --features sal-postgres 配下の CLI サブコマンド 89 件(デフォルトビルドでは 87 件) -- 同等の機能を備えた完全な CLI
  • フルプロファイルで MCP ツール 101 件(デフォルトでは 7 件。Profile::full().expected_tool_count() で検証済み) -- あらゆる MCP 互換 AI とネイティブに連携
  • 対話型 REPL シェル -- 色付きの出力で、履歴の呼び出し、検索、一覧表示、取得、統計、名前空間、削除を実行
  • JSON 出力 -- すべての CLI コマンドで --json フラグを使用
  • 分散コーディネーション(v0.8.0 Pillar-1 + Pillar-2) -- アクション DAG(memory_action_*)、単一保有者リース(memory_lease_*)、Ed25519 署名付きシグナル(memory_signal_*)、証明付きチェックポイント(memory_checkpoint_*)、パラメーター化ルーチン(memory_routine_*)、Goal/Plan/Step の型付き認知ライフサイクルに対応しています。詳しくは docs/coordination.md を参照してください。
運用
  • マルチノード同期 -- データベースファイル間のプル、プッシュ、双方向マージ
  • インポート/エクスポート -- メモリーリンクを保持した完全な JSON ラウンドトリップ
  • ガベージコレクション -- 30 分ごとにバックグラウンドで自動的に期限切れデータを削除
  • グレースフルシャットダウン -- SIGTERM/SIGINT で WAL にチェックポイントを作成し、正常に終了
  • 詳細なヘルスチェック -- DB へのアクセスと FTS5 の整合性を検証
  • シェル補完 -- bash、zsh、fish
  • Man ページ -- ai-memory man で roff を標準出力に生成
  • 時間フィルター -- list と search で --since/--until を使用
  • 人が読みやすい経過時間 -- CLI 出力に「2h ago」「3d ago」と表示
  • 色付き CLI 出力 -- ANSI のティアラベル(赤/黄/緑)、優先度バー、太字のタイトル、シアンの名前空間
品質
  • 全領域で約 10,000 件のテスト -- src/ 配下に #[test]/#[tokio::test] 属性が約 6,712 件(#[test] が 5,759 件、#[tokio::test] が 953 件)、さらに tests/ 配下に約 3,362 件(#[test] が 2,138 件、#[tokio::test] が 1,224 件)あります。v0.6.4 時代の約 2,400 件(lib が 1,960 件、integration が 211 件、mcp_integration が 16 件、webhook_http_parity が 4 件、recipe_contract が 16 件、その他のバイナリーターゲット全体で約 150 件)から増加しました。行カバレッジは プロジェクト基準の ≥92% を維持しています。v0.6.4 で新たに追加されたモジュールのカバレッジは、sizes.rs が 100%、profile.rs が 99.50%、cli/audit.rs が 97.58%、cli/doctor.rs が 97.05%、handlers.rs が 92.56%、cli/install.rs が 92.26% です。v0.6.3.x のベースライン(1,809 件/93.08%、1,886 件/93.84%)は evidence page に固定されています。v0.6.4 の指標はリリースノートと test-hub campaign に掲載されています。経験的な NHI 発見の受け入れは、Discovery Gate で別途実証済みです(稼働中の xAI Grok 4.3 に対する T1–T4 マトリックス、6/6 PASS、GATE GREEN)。
  • LongMemEval ベンチマーク -- ICLR 2025 LongMemEval-S データセットで、純粋な FTS5 キーワード検索が R@5 97.0%(LLM 非依存、2.2 秒、232 q/s、API コストゼロ)を達成しています。現行世代の Gemma 4 モデルによる LLM クエリー拡張では R@5 97.2%/R@10 99.6%/R@20 99.8% を計測しています(クラウド API 環境。過去の gemma3:4b による 97.8% の数値は、#1975 に従い、主要指標から除外されています)。ベンチマークの詳細を参照してください。
  • MCP プロンプト -- recall-first と memory-workflow のプロンプトにより、AI クライアントがメモリーを積極的に活用する方法を学べます
  • TOON をデフォルトに設定 -- recall/list/search の応答では、デフォルトで TOON compact を使用します(JSON より 79% 小型)
  • Criterion ベンチマーク -- 1K 規模で insert、recall、search を計測
  • GitHub Actions CI/CD -- Ubuntu と macOS で fmt、clippy、test、build を実行し、タグに応じてリリース
カバレッジの下限(CI の必須ゲート)

Code Coverage ジョブは必須のステータスチェックです。CI はすべての PR で、次の 2 つの不変条件を再確認します。1 つ目は、行カバレッジ 90% 以上という絶対的な下限(壊滅的な低下を防ぐための措置で、現在の測定値を 5% 単位で切り下げて設定)、2 つ目は、.coverage-baseline に固定された値に対する 0.5% の許容幅を設けたラチェット(通常の運用時の適用基準)です。カバレッジが向上した PR では、今後の PR に新しい下限を適用できるよう、同じコミットでベースラインファイルも更新してください。カバレッジが 0.5% を超えて低下する PR はマージできません。現在の測定値:行カバレッジ 93.13%。

トークン予算ゲート(CI の必須ゲート、v0.7 C5)

token-budget ワークフローは必須のステータスチェックです。すべての PR で、cl100k_base による測定に基づき、次の 3 つの不変条件を適用します。

  • ツールごとの上限は 1500 トークン -- MCP ツールのシリアライズされたスキーマ(name + description + inputSchema)は、単体で 1500 cl100k_base トークンを超えてはなりません。
  • フルプロファイルの適正範囲(5K-8K) -- v0.6.4 で導入した下限を維持し、異常な縮小(ツールを誤って削除するなど)を検出します。
  • フルプロファイルの厳格な上限(v0.7 C5、D1.6/D1.7 後に引き上げ) -- --profile full での tools/list のトリミング後のペイロードは、11,000 cl100k_base トークンを超えてはなりません(tests/token_budget_guard.rs の TRIMMED_FULL_PROFILE_CEILING_TOKENS。当初の C5 の目標は、D1.6 より前の手書きスキーマを対象とした 3500 でしたが、schemars 由来の D1.6/D1.7 による拡張で、固定された上限が引き上げられました)。C2(docs フィールドの分割)、C3(繰り返されるスキーマの定型部分をまとめる)、C4(使用頻度の低いオプションのパラメーターを非表示にする)によって当初の圧縮を実現しました。このゲートにより、今後の PR で機能範囲を拡大する場合、別の箇所で予算を削減する必要があります。ツールごとのコストを確認するには、ai-memory doctor --tokens --raw-table を実行してください。.github/workflows/token-budget.yml と docs/v0.7/schema-compaction-audit.md を参照してください。
ML と LLM の依存関係(セマンティックティア以上)
  • candle-core, candle-nn, candle-transformers -- ネイティブ Rust 推論向けの Hugging Face Candle ML フレームワーク
  • hf-hub -- Hugging Face Hub からモデルをダウンロード
  • tokenizers -- テキストの前処理に使用する Hugging Face のトークナイザー
  • instant-distance -- 近似最近傍検索
  • reqwest -- LLM バックエンドとの通信に使用する HTTP クライアント(スマート/自律ティア向け — #1067 により、任意のプロバイダーに対応:Ollama, xAI, OpenAI, Anthropic, Gemini, DeepSeek, Kimi, Qwen, Mistral, Groq, Together, Cerebras, OpenRouter, Fireworks, LMStudio, vLLM, llama.cpp server)

アーキテクチャ

ai-memory のアーキテクチャ図


ベンチマーク

LongMemEval ベンチマーク結果

ICLR 2025 LongMemEval-S データセット(500 問、6 カテゴリー)で評価しています。純粋な FTS5 キーワード層は、2.2 秒で R@5 97.0%を達成します。LLM に依存せず、完全にローカルで動作し、クラウド API 呼び出しはゼロ、コストもかかりません。LLM クエリ拡張(スマート層)は、現行世代の Gemma 4 モデル(クラウド API 環境)で R@5 97.2%を測定しています。

ベンチマークモデルに関する注記(2026-07-10 更新、#1975 の決定): 過去に示していたスマート層の R@5 97.8%は Gemma 3 4B(現在もコンパイル時のデフォルト拡張モデル)で測定したものであり、主要な数値としての掲載を終了しました。公開されている現行世代の基準値は、測定済みの OpenRouter Gemma 4 の実行結果です:R@5 97.2%/R@10 99.6%/R@20 99.8%(2026-05-31、500 問、拡張失敗 0 件)。ローカル Ollama の Gemma 4 の数値はありません。基準ベンチマークのホストは CPU のみで、正式なプロトコルに沿ったローカル実行は現実的ではないためです(#1983 を参照)。ローカル GPU での再実行は v1.0 以降も未完了です。キーワード層の R@5 97.0%は LLM に依存せず、影響を受けません。

層R@5速度依存関係
キーワード97.0%232 q/sなし
セマンティック97.4%45 q/s埋め込みモデル(約100MB)
スマート97.2%(Gemma 4、API 環境;過去の gemma3:4b は 97.8%)12 q/s任意の LLM バックエンド(例:ローカル Ollama + Gemma、または xAI Grok 4.3、OpenAI gpt-5、Anthropic Claude Opus 4.7、Gemini、DeepSeek など。-#1067 以降)
パフォーマンス予算(v0.6.4)

各リリースには、ホットパス操作の公開済み p95/p99 予算と、測定された p95 が予算を 10%超えていないかを検証し、超過した PR を失敗させる CI ゲートが含まれます。目標値は M4 リファレンスハードウェアを基準に調整されています。完全な表と方法論については PERFORMANCE.md を参照してください。

操作目標 p95目標 p99
memory_session_start(Claude Code フック)< 100 ms< 200 ms
memory_store(埋め込みなし)< 20 ms< 50 ms
memory_search(FTS5)< 100 ms< 250 ms
memory_recall(ホット、深さ=1)< 50 ms< 150 ms
memory_kg_query(深さ ≤ 3)< 100 ms< 250 ms
memory_kg_query(深さ ≤ 5)< 250 ms< 500 ms
memory_kg_timeline< 100 ms< 250 ms

同じワークロードをローカルで実行するには:

ai-memory bench                      # human-readable table
ai-memory bench --json               # machine-parseable

v0.6.3.x から v0.6.4 でも基盤は変わりません(quiet-tools リリースで変更されたのはデフォルトのツール公開範囲が小さくなったことであり、ホットパスが変わったわけではありません)。次回の専用ソークテスト期間までは、ここに記載した p99 目標値は参考情報です。最新のソークテストの証跡はテストハブにあります。


統合方法

MCP(第一選択 -- MCP 対応 AI プラットフォーム向け)

MCP は推奨される統合方法です。AI にはネイティブなメモリツールがデフォルトで 7 つ公開されます(元の 5 つ + memory_load_family + memory_smart_load。さらに常時有効な memory_capabilities ブートストラップもあります)。接着コードは不要です。呼び出し可能な残りの 93 ツール(公開エントリーは 101 件。Profile::full().expected_tool_count() と照合して検証され、src/mcp/registry.rs の const_count_matches_full_profile によって固定されています)も、--profile graph|admin|power|full を指定するか、memory_capabilities --include-schema family=<name> で実行時に展開することで利用できます。AI プラットフォームの設定で MCP サーバーを構成してください:

{
  "mcpServers": {
    "memory": {
      "command": "ai-memory",
      "args": ["--db", "~/.claude/ai-memory.db", "mcp"]
    }
  }
}
HTTP API(汎用 -- あらゆる AI やツール向け)

REST API にアクセスするには、HTTP サーバーを起動します。HTTP 呼び出しが可能な AI、スクリプト、自動化から利用できます:

ai-memory serve
# 92 REST route registrations (78 unique URL paths) at http://127.0.0.1:9077/api/v1/
CLI(汎用 -- スクリプト作成や直接利用向け)

CLI は単独で使用することも、シェルコマンドを実行する AI 統合の構成要素として使用することもできます:

ai-memory store --tier long --title "Architecture decision" --content "We use PostgreSQL"
ai-memory recall "database choice"
ai-memory search "PostgreSQL"

機能ティア

ai-memory は4つの機能ティアに対応しており、起動時に ai-memory mcp --tier <tier> で選択します。上位ティアでは、ディスク容量と RAM の使用量が増える代わりに、ML 機能が追加されます。

ティア想起方式追加機能おおよそのオーバーヘッド
keywordFTS5 のみベースラインの101エントリーのツールセット — ティアが制限するのはモデル/機能であり、公開されるツールセットではありません0 MB
semanticFTS5 + コサイン類似度(ハイブリッド)MiniLM-L6-v2 の埋め込み(384次元)、HNSW インデックス、semantic ティア(101エントリーのツールセットの一部)約256 MB
smartハイブリッド + LLM によるクエリ拡張+ nomic-embed-text(768次元)+ LLM を利用する memory_expand_query、memory_auto_tag、memory_detect_contradiction、101エントリーのツールセット全体。LLM プロバイダーはオペレーターが選択します(AI_MEMORY_LLM_BACKEND。 #1067)— ローカル Ollama、xAI、OpenAI、Anthropic、Gemini、DeepSeek、Kimi、Qwen、Mistral、Groq、Together、Cerebras、OpenRouter、Fireworks、LMStudio、vLLM、または llama.cpp。約1 GB(ローカル Ollama)/約0 GB(リモート API)
autonomousハイブリッド + LLM 拡張 + クロスエンコーダーによる再ランキング+ ニューラルクロスエンコーダー(ms-marco-MiniLM)、メモリのリフレクション、101エントリーのツールセット全体。LLM プロバイダーの選択肢は smart ティアと同じです。約4 GB(ローカル Ollama)/約3 GB(リモート LLM、ローカルのクロスエンコーダーのみ)
機能マトリックス

各機能に必要な最低ティアを示します。各ティアには、それより下位のティアの機能がすべて含まれます。

機能keywordsemanticsmartautonomous
検索と想起
FTS5 キーワード検索はいはいはいはい
セマンティック埋め込み(コサイン類似度)--はいはいはい
ハイブリッド想起(FTS5 + コサイン、コンテンツの長さに応じてセマンティックの重みを0.50→0.15に調整)--はいはいはい
HNSW 最近傍インデックス--はいはいはい
LLM クエリ拡張(memory_expand_query)----はいはい
ニューラルクロスエンコーダーによる再ランキング------はい
メモリ管理
保存、更新、削除、昇格、リンクはいはいはいはい
手動統合はいはいはいはい
自動統合(LLM による要約)----はいはい
自動タグ付け(memory_auto_tag)----はいはい
矛盾の検出(memory_detect_contradiction)----はいはい
自律的なメモリのリフレクション------はい
モデル
埋め込みモデル--MiniLM-L6-v2(384次元)nomic-embed-text(768次元)nomic-embed-text(768次元)
埋め込みバックエンドの上書き(#1598)--任意:ローカル Ollama、API ベンダーのエイリアス、またはセルフホストの OpenAI 互換([embeddings].backend / AI_MEMORY_EMBED_*)同左同左
LLM----オペレーターが選択(#1067)— デフォルトはローカルの gemma3:4b。リモートエンドポイントはローカルのフットプリントなしオペレーターが選択(#1067)— デフォルトはローカルの gemma3:4b。リモートエンドポイントはローカルのフットプリントなし
リソース
RAM0 MB約256 MB約1 GB約4 GB
外部依存関係なしなしLLM バックエンド(Ollama / xAI / OpenAI / Anthropic / Gemini / DeepSeek / Kimi / Qwen / Mistral / Groq / Together / Cerebras / OpenRouter / Fireworks / LMStudio / vLLM / llama.cpp — #1067)LLM バックエンド(smart と同じ選択肢)
公開される MCP ツール(--profile full の場合) 1101101101101

ティアによって制御されるのはモデルではなく機能です。さらに、-#1067(v0.7.0)以降は、ティアによって制御されるのはベンダーでもありません。 --tier フラグは、公開するツールを制御します。LLM バックエンドとモデルは、AI_MEMORY_LLM_BACKEND と AI_MEMORY_LLM_MODEL の環境変数(または ~/.config/ai-memory/config.toml の標準の [llm] セクション)で個別に設定できます。v0.7.x のエンタープライズ向けスキーマと移行ツールについては、docs/CONFIG_SCHEMA.md を参照してください。たとえば、OpenAI 互換のエイリアスを使って、xAI Grok 4 で自律型ティア(101個のエントリーからなる全ツール群と再ランカー)を実行するには、次のようにします。

# Quick path: env vars
export AI_MEMORY_LLM_BACKEND=xai
export AI_MEMORY_LLM_MODEL=grok-4.3
export XAI_API_KEY=xai-…   # or AI_MEMORY_LLM_API_KEY
ai-memory mcp --tier autonomous
# Enterprise path: ~/.config/ai-memory/config.toml (v0.7.x schema v2, #1146)
schema_version = 2
tier = "autonomous"

[llm]
backend     = "xai"
model       = "grok-4.3"
base_url    = "https://api.x.ai/v1"
api_key_env = "XAI_API_KEY"          # mutually exclusive with api_key_file;
                                     # inline `api_key = "..."` is REJECTED.
# Legacy v0.6.x shape — still works, deprecation WARN at load; run
# `ai-memory config migrate` to upgrade in place.
tier = "autonomous"
llm_model = "gemma3:4b"   # default Ollama model at v0.7.0

MCP サーバーを AI クライアントから起動する場合、config.toml のティア設定は使用されないため、MCP 引数に --tier フラグを必ず指定してください。

# Semantic is the default tier
ai-memory mcp

# Keyword -- FTS5 only, no models
ai-memory mcp --tier keyword

# Semantic -- hybrid recall with embeddings (explicit)
ai-memory mcp --tier semantic

# Smart -- adds LLM-powered query expansion, auto-tagging, contradiction detection
ai-memory mcp --tier smart

# Autonomous -- adds cross-encoder reranking
ai-memory mcp --tier autonomous

memory_capabilities ツールは、実行時にアクティブなティア、読み込まれたモデル、利用可能な機能を報告します。


MCP ツール

次の101個のツール(フルプロファイル。正式な個数は src/profile.rs の Profile::full().expected_tool_count() で確認できます)は、MCP サーバーとして設定すると、MCP 互換のあらゆる AI で利用できます(v0.6.4 で固定されたエビデンスページには63個のツールからなるベースラインが記載されています。以下の表では、多くのクライアントが日常的に使用する主要なサブセットについて説明します)。

ツール説明
memory_store新しい記憶を保存します(タイトルと名前空間で重複を排除し、矛盾を報告します)
memory_recallコンテキストに関連する記憶を呼び出します(あいまい一致の OR 検索。6つの要素に基づいて順位付け)
memory_search完全一致するキーワードで記憶を検索します(AND セマンティクス)
memory_listオプションのフィルター(名前空間、ティア、タグ、日付範囲)を指定して記憶を一覧表示します
memory_getID で指定した記憶とそのリンクを取得します
memory_updateID で指定した既存の記憶を更新します(部分更新)
memory_deleteID で指定した記憶を削除します
memory_promote記憶を長期記憶に昇格させます(永続化し、有効期限をクリア)
memory_forgetパターン、名前空間、またはティアを指定して一括削除します
memory_link2つの記憶の間に型付きリンクを作成します
memory_get_links記憶のすべてのリンクを取得します
memory_consolidate複数の記憶を1つの長期要約に統合します
memory_stats記憶ストアの統計情報を取得します
memory_capabilitiesアクティブな機能ティア、読み込まれたモデル、利用可能な機能を報告します
memory_expand_queryLLM を使って検索クエリを関連用語に展開します(スマート以上のティア)
memory_auto_tagLLM を使って記憶のタグを自動生成します(スマート以上のティア)
memory_detect_contradictionLLM を使って2つの記憶が矛盾しているか確認します(スマート以上のティア)
memory_archive_listアーカイブされた記憶を一覧表示します(オプションで名前空間、ティア、タグのフィルターを指定可能)
memory_archive_restoreアーカイブされた記憶をアクティブストアに復元します
memory_archive_purgeフィルターに一致するアーカイブ済みの記憶を完全に削除します
memory_archive_statsアーカイブの統計情報(ティア、名前空間、経過期間ごとの件数)を取得します

HTTP API

127.0.0.1:9077 で 92 件のルートが登録されており、URL パスは 78 個あります。ai-memory serve で起動してください。以下の表には、最もよく使われる REST エンドポイントを示しています。全エンドポイント(ガバナンス、フェデレーション、サブスクリプション、ナレッジグラフ、クォータ、承認 SSE)については、docs/API_REFERENCE.md を参照してください。

セキュリティ: HTTP サーバーは 127.0.0.1 にバインドされ、デフォルトでは認証が設定されておらず、CORS も許可設定になっています。すべてのリクエストで x-api-key ヘッダーを必須にするには、config.toml で api_key を設定してください(従来の ?api_key= クエリパラメーター形式は v0.7.0 で非推奨になりました — #1574)。また、キーなしでの起動を確実に拒否するには、AI_MEMORY_REQUIRE_API_KEY=1 を設定してください(#1458)。認証なしでネットワークに公開しないでください(また、--tls-cert/--tls-key またはリバースプロキシを介した TLS の使用を推奨します)。

メソッドエンドポイント説明
GET/api/v1/healthヘルスチェック(DB と FTS5 の整合性を確認)
GET/api/v1/memoriesメモリを一覧表示(namespace、tier、tags、since、until、limit に対応)
POST/api/v1/memoriesメモリを作成
POST/api/v1/memories/bulkメモリを一括作成(上限あり)
GET/api/v1/memories/{id}ID でメモリを取得
PUT/api/v1/memories/{id}ID でメモリを更新
DELETE/api/v1/memories/{id}ID でメモリを削除
POST/api/v1/memories/{id}/promoteメモリを長期メモリに昇格
GET/api/v1/searchAND キーワード検索
GET/api/v1/recallコンテキストから想起(クエリパラメーターを使用する GET)
POST/api/v1/recallコンテキストから想起(JSON ボディを使用する POST)
POST/api/v1/forgetパターン/namespace/tier に基づいて一括削除
POST/api/v1/consolidateメモリを 1 つに統合
POST/api/v1/linksメモリ間のリンクを作成
GET/api/v1/links/{id}メモリのリンクを取得
GET/api/v1/namespacesすべての namespace を一覧表示
GET/api/v1/statsメモリストアの統計情報
POST/api/v1/gcガベージコレクションを実行
GET/api/v1/exportすべてのメモリとリンクを JSON でエクスポート
POST/api/v1/importJSON からメモリとリンクをインポート
GET/api/v1/archiveアーカイブ済みメモリを一覧表示(任意のフィルターに対応)
POST/api/v1/archive/{id}/restoreアーカイブ済みメモリをアクティブストアに復元
DELETE/api/v1/archiveフィルターに一致するアーカイブ済みメモリを完全削除
GET/api/v1/archive/statsアーカイブの統計情報(tier、namespace、経過期間ごとの件数)

CLI コマンド

--features sal または --features sal-postgres で、トップレベルのサブコマンドは89個あります(デフォルトビルドでは87個です。2つの差分は Migrate と SchemaInit で、どちらも src/daemon_runtime.rs::Command::{Migrate,SchemaInit} に従って #[cfg(feature = "sal")] でゲートされています。v0.6.4では40個でした)。各コマンドの詳細は ai-memory <command> --help、コマンド一覧は ai-memory --help を実行してください。

コマンド説明
mcpstdio 経由で MCP ツールサーバーとして実行します(主要な統合方法)
serveポート9077で HTTP デーモンを起動します
store新しいメモリを保存します(タイトルと名前空間で重複を排除します)
updateIDで既存のメモリを更新します
recallファジー OR 検索を行い、順位付けした結果を返します+自動タッチ(ハイブリッド想起では --tier をサポート)。パイプラインはリクエストごとに結果を最大50件に制限します。
search正確なキーワード一致を得るための AND 検索です。
getIDで単一のメモリを取得します(リンクを含みます)
listフィルター(名前空間、階層、タグ、日付範囲)を指定してメモリを閲覧します。リクエストごとに最大1000件に制限されます(LIST_MAX_LIMIT。HTTP の list/bulk ではさらに AI_MEMORY_MAX_PAGE_SIZE も適用されます)。
deleteIDでメモリを削除します
promoteメモリを長期に昇格させます(有効期限をクリアします)
forgetパターン+名前空間+階層を指定して一括削除します
link2つのメモリをリンクします(related_to、supersedes、contradicts、derived_from)
consolidate複数のメモリを1つの長期要約に統合します
resolve矛盾を解決します。勝者をマークし、敗者を降格させます
shellカラー出力対応の対話型 REPL
sync2つのデータベースファイル間でメモリを同期します(pull/push/merge)
auto-consolidate名前空間+タグでメモリをグループ化し、しきい値を超えるグループを統合します
gc期限切れのメモリに対してガベージコレクションを実行します
statsメモリの状態の概要(件数、階層、名前空間、リンク、DB サイズ)
namespacesメモリ件数とともにすべての名前空間を一覧表示します
exportすべてのメモリとリンクを JSON としてエクスポートします
importJSON からメモリとリンクをインポートします(stdin)
completionsシェル補完を生成します(bash、zsh、fish)
manroff の man ページを stdout に生成します
mine過去の会話(Claude、ChatGPT、Slack のエクスポート)からメモリをインポートします
archiveメモリアーカイブを管理します(一覧表示、復元、消去、統計)

トップレベルの ai-memory バイナリでは、グローバルフラグも使用できます。

フラグ説明
--db <path>データベースのパス(デフォルト:ai-memory.db、または $AI_MEMORY_DB)
--jsonすべてのコマンドで JSON を出力します(機械可読形式の出力)

store サブコマンドでは、追加のフラグを使用できます。

フラグ説明
--source / -Sこのメモリを作成した対象(user、nhi、hook、api、cli、import、consolidation、system)。デフォルト:cli。src/validate.rs::VALID_SOURCES に従い、後方互換性のため "claude" も受け付けます
--expires-atRFC3339 形式の有効期限タイムスタンプ
--ttl-secs秒単位の TTL(--expires-at の代替)

mcp サブコマンドでは、追加のフラグを使用できます。

フラグ説明
--tier <keyword|semantic|smart|autonomous>機能階層(デフォルト:semantic)。機能階層を参照してください。

想起スコアリング

すべての想起クエリでは、6つの要素に基づいてメモリを順位付けします。

score = (fts_relevance * -1)
      + (priority * 0.5)
      + (MIN(access_count, 50) * 0.1)
      + (confidence * 2.0)
      + tier_boost
      + recency_decay
要素重み注記
FTS 関連度-1.0xSQLite FTS5 の順位(負の値ほど一致度が高い)
優先度0.5xユーザーが設定する1~10の尺度
アクセス回数0.1x想起された回数(スコアリングでは50を上限とします)
信頼度2.0x確実性スコア(0.0~1.0)
階層ブースト+3.0 / +1.0 / +0.0長期/中期/短期
経過時間による減衰1/(1 + days*0.1)最近のメモリほど上位に表示されます

メモリ階層

階層TTL用途例
short6 hours(設定可能)一時的なコンテキスト現在のデバッグ状態、一時変数、エラートレース
mid7 days(設定可能)作業上の知識スプリントの目標、最近の決定、現在のブランチの目的
long永続苦労して得た知識アーキテクチャ、ユーザーの好み、修正事項、規約
自動動作
  • 再呼び出し時の TTL 延長:short メモリは +1 時間、mid メモリは +1 日延長されます
  • 自動昇格:mid 階層のメモリが 5 回以上アクセスされると long に昇格します(有効期限はクリアされます)
  • 優先度の強化:アクセス 10 回ごとに、優先度が 1 上がります(上限は 10)
  • 矛盾の検出:同じ名前空間の既存メモリと新しいメモリが矛盾する場合に警告します
  • 重複排除:タイトルと名前空間をキーにアップサートします。更新時に階層が下がることはありません

TTL の設定

デフォルトの TTL(short は 6 hours、mid は 7 days)は、~/.config/ai-memory/config.toml の [ttl] セクションで上書きできます。

[ttl]
short_ttl_secs = 21600      # short-tier TTL in seconds (default: 21600 = 6 hours)
mid_ttl_secs = 604800        # mid-tier TTL in seconds (default: 604800 = 7 days)
long_ttl_secs = 0            # long-tier TTL in seconds (default: 0 = never expires)
short_extend_secs = 3600     # TTL extension on recall for short-tier memories in seconds (default: 3600 = +1h)
mid_extend_secs = 86400      # TTL extension on recall for mid-tier memories in seconds (default: 86400 = +1d)

5 つのフィールドはすべて省略可能です。省略したフィールドにはデフォルト値が適用されます。いずれかの値を 0 に設定すると、その階層の有効期限が無効になります。値の上限は 10 年で、負の延長値は 0 に切り上げられます。

注記: 設定はプロセスの起動時に一度だけ読み込まれます。変更を反映するには、ai-memory プロセス(MCP サーバー、HTTP デーモン、または CLI)を再起動する必要があります。


アーカイブ

ガベージコレクションで有効期限が切れたメモリは、完全に削除する代わりにアーカイブできます。アーカイブされたメモリは別のストアに移動され、後から参照、復元、または消去できます。

設定

~/.config/ai-memory/config.toml でアーカイブを有効にします。

archive_on_gc = true   # archive expired memories instead of deleting them (default: true)
CLI コマンド

archive サブコマンドでアーカイブを管理します。

ai-memory archive list                          # list archived memories
ai-memory archive list --namespace my-project   # filter by namespace
ai-memory archive restore <id>                  # restore an archived memory to active store
ai-memory archive purge --older-than-days 90     # permanently delete archives older than 90 days
ai-memory archive stats                         # show archive statistics

注記: 復元されたメモリは expires_at がクリアされます(次に TTL が割り当てられるまで永続します)。

MCP ツール

MCP クライアントで利用できるアーカイブツールは 4 つあります。

ツール説明
memory_archive_listアーカイブされたメモリを一覧表示します(名前空間/階層/タグによる任意のフィルターに対応)
memory_archive_restoreアーカイブされたメモリをアクティブなストアに復元します
memory_archive_purgeフィルターに一致するアーカイブ済みメモリを完全に削除します
memory_archive_statsアーカイブの統計情報を取得します(階層、名前空間、経過期間別の件数)
HTTP エンドポイント
メソッドエンドポイント説明
GET/api/v1/archiveアーカイブされたメモリを一覧表示します(任意のフィルターに対応)
POST/api/v1/archive/{id}/restoreアーカイブされたメモリをアクティブなストアに復元します
DELETE/api/v1/archiveフィルターに一致するアーカイブ済みメモリを消去します
GET/api/v1/archive/statsアーカイブの統計情報(階層、名前空間、経過期間別の件数)

セキュリティ

ai-memory は、すべての入力経路でセキュリティを強化しています。

  • トランザクションの安全性 -- 複数ステップのデータベース操作はすべてトランザクションを使用し、失敗時に部分的な書き込みが発生しません
  • FTS インジェクションの防止 -- FTS5 クエリに渡す前にユーザー入力をサニタイズし、特殊文字をエスケープします
  • エラーのサニタイズ -- 内部のデータベースパスとシステムの詳細情報をエラーレスポンスから取り除き、クライアントには構造化されたエラータイプ(NOT_FOUND、VALIDATION_FAILED、DATABASE_ERROR、CONFLICT)を返します
  • 本文サイズの上限 -- Axum の DefaultBodyLimit により、HTTP リクエスト本文の上限を 50 MB に設定しています
  • 一括操作の上限 -- リソースの枯渇を防ぐため、一括作成エンドポイントでバッチサイズの上限を適用します
  • CORS -- localhost での開発ワークフロー向けに、制限の緩い CORS レイヤーを有効にしています
  • 入力検証 -- すべての書き込み経路で、タイトルの長さ、コンテンツの長さ、名前空間の形式、ソース値、優先度の範囲(1~10)、信頼度の範囲(0.0~1.0)、タグの形式、ティア値、関係タイプ、ID の形式を検証します
  • 同期時のリンク検証 -- 同期処理中にインポートする前に、すべてのリンクを検証します(両方の ID、関係タイプ、自己リンクでないこと)
  • スレッドセーフな色判定 -- ターミナルの色判定には AtomicBool を使用し、並行アクセスの安全性を確保します
  • ローカル専用 HTTP -- HTTP サーバーはデフォルトで 127.0.0.1 にバインドされ、ネットワークには公開されません
  • WAL モード -- SQLite の Write-Ahead Logging により、書き込み中の安全な同時読み取りを実現します

ドキュメント

ガイド対象読者
変更履歴 v0.9.0現在のリリース(secure-default hardening) — デフォルトで必要となるストアパスのエージェント証明(#1751)、MCP と HTTP の二重フック適用ゲート(#1885/#1924)、スキーマ v78
リリースノート v0.8.0前回のリリース(distributed-coordination)— 調整基盤、型付き認知、フェデレーションの強化、ガバナンスの適用、スキーマ v58→v70
調整ツールのリファレンスv0.8.0 のアクション/リース/シグナル/チェックポイント/ルーチンのプリミティブ(memory_action_* / _lease_* / _signal_* / _checkpoint_* / _routine_*)
移行ガイド v0.7v0.6.x からのアップグレード(attested-cortex、フック、トランスクリプト、AGE、権限、G1 継承の修正を網羅)
v0.7 の新機能attested-cortex 基盤のビジュアルガイド
attested-cortex RFCv0.7 の 4 つのアーキテクチャ上の決定の設計根拠
v0.7 互換性マトリックス機能ごとのデフォルトとオプトインの一覧
インストールガイド実行環境のセットアップ(複数の AI プラットフォーム向け MCP セットアップを含む)
ユーザーガイド永続的なメモリーを必要とする AI アシスタントのユーザー
開発者ガイドai-memory を基盤に開発する方、または貢献する方
管理者ガイドデプロイ、監視、トラブルシューティング
エンジニアリング標準コード、テスト、セキュリティ、リリースの標準(正式な基準)
AI 開発者ワークフローこのリポジトリに貢献する AI コーディングエージェント向けの手順を追ったワークフロー
AI 開発者ガバナンス標準AI の参加に関するポリシー:権限、帰属表示、レビュー、監査
GitHub Pagesアニメーション図を使ったビジュアル概要

ライセンス

Copyright 2026 AlphaOne LLC.

Apache License, Version 2.0(「ライセンス」)に基づいてライセンスされています。 このファイルは、ライセンスに従う場合に限り使用できます。 ライセンスのコピーは、次の場所から入手できます。

http://www.apache.org/licenses/LICENSE-2.0

適用される法律で求められる場合、または書面で合意された場合を除き、 ライセンスに基づいて頒布されるソフトウェアは、「現状有姿」で頒布され、 明示的か黙示的かを問わず、いかなる保証も条件もありません。 ライセンスに基づく許可および制限の具体的な内容については、 ライセンスをご確認ください。

Footnotes

  1. MCP ツールセットは想起ティアとは独立しています。--profile full(デフォルトの --profile core では、ティアに関係なく起動時に8個を公開します。Core ファミリーの7つのツールと、常時有効なブートストラップ用の memory_capabilities です。残りの93個はオンデマンドで読み込まれます)では、すべてのティアで同じ101個のツールが利用できます。ティアによって制限されるのはモデル(埋め込みモデル、クロスエンコーダー、LLM)と機能の挙動(コサイン類似度、LLM 拡張、再ランキング)であり、公開されるツールの数ではありません。この仕様は src/mcp/registry.rs の Profile::full().expected_tool_count() と const_count_matches_full_profile によって固定されています。 セマンティックティア(デフォルト)には Candle ML フレームワークがバンドルされており、初回実行時に all-MiniLM-L6-v2 モデルをダウンロードします(約90 MB)。スマートティアと自律型ティアには、LLM バックエンドが必要です。-#1067(v0.7.0)以降、これはローカル環境(Ollama、LMStudio、vLLM、llama.cpp server)でも、OpenAI 互換の任意のリモートエンドポイント(xAI、OpenAI、OpenAI shim 経由の Anthropic、Google Gemini、DeepSeek、Kimi、Qwen、Mistral、Groq、Together、Cerebras、OpenRouter、Fireworks)でも利用できます。AI_MEMORY_LLM_BACKEND 環境変数で選択します。ベンダーごとの API キー(XAI_API_KEY / OPENAI_API_KEY / ANTHROPIC_API_KEY / GEMINI_API_KEY / DEEPSEEK_API_KEY / MOONSHOT_API_KEY / DASHSCOPE_API_KEY など)、または標準の AI_MEMORY_LLM_API_KEY を使用します。 ↩

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。