Rust製の長期記憶OSS「ai-memory」の仕組みと設計思想

複数のコーディングエージェント CLI を併用していると、多くの開発現場が「エージェントを切り替えるたびにコンテキストを説明し直す」という壁にぶつかります。昼は Claude Code で設計を進め、夜は OpenAI Codex で細かい修正を回す、という使い方をしていると、片方に話した「なぜこの実装を採用しなかったか」「どのアプローチで失敗したか」がもう片方には伝わりません。プロジェクトが長期化するほど、この再説明コストは無視できない大きさになっていきます。

この課題に対して、ここ 1 年ほどでオープンソースの「AI コーディングエージェント向け永続メモリ」というカテゴリが急速に整理されてきました。技術ブログでも既に、Claude Codeのセッション間記憶を自動化するclaude-memの仕組み、AIエージェントの永続メモリ基盤にagentmemoryが選ばれる理由、AIエージェントのメモリ基盤にSupermemoryが選ばれる理由｜Mem0との違い、AIエージェントの永続メモリにcogneeが選ばれる理由｜ナレッジグラフの強みの 4 本を紹介してきました。

本記事で取り上げる ai-memory（akitaonrails/ai-memory）は、このシリーズの 5 本目にあたる Rust 製の長期記憶サーバーです。README では自身を「agentmemory の Rust 後継（Rust successor）」と位置づけており、既存の 4 本とは別の軸で「Rust による単一バイナリ運用」「Claude Code や Codex を含む 14 以上のハーネスへの横断対応」「Karpathy 流の compile-not-retrieve 型メモリモデル」という差分を打ち出しています。

以下では、公式ドキュメントと README、そして作者である Fabio Akita（akitaonrails）氏のブログ記事をベースに、ai-memory の設計思想・アーキテクチャ・対応エージェント・セットアップの流れ・類似 OSS との位置づけまでを整理します。実運用に載せるかどうかを判断するための材料を、1 記事で俯瞰できる形にまとめました。

ai-memory とは — 概要と基本情報

まずは ai-memory がどのような立ち位置のプロダクトなのかを、GitHub リポジトリの記述と README から整理していきます。「初見でどこまで期待できるツールなのか」を先に固めておくと、以降の比較や導入検討で判断がぶれにくくなります。

何を解決するツールか

ai-memory は、GitHub リポジトリ（akitaonrails/ai-memory） で公開されているオープンソースのコーディングエージェント向け長期記憶サーバーです。GitHub リポジトリの説明では「Solution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors」と紹介されています（出典: akitaonrails/ai-memory）。

README 冒頭ではこの立ち位置がより具体的に説明されており、次のように書かれています。

Long-term memory for AI coding agents. Quit Claude Code mid-task, start OpenAI Codex in the same directory, continue without re-explaining the architecture, the failed approaches, or the open questions.

（出典: akitaonrails/ai-memory README）

要するに ai-memory は、複数のコーディングエージェント CLI にまたがって「セッションを跨いだ長期記憶」と「エージェント間の引き継ぎ」を提供するサーバーです。セッションが終わるたびに、生ログではなくサニタイズ済みの観測イベントから「凝集された Markdown ページ」を作り、次のエージェントには「where you left off（前回の続き）」のハンドオフとして渡します。ストレージはベクトル DB ではなく、平文 Markdown を git 管理するというユニークな設計を採用しています。

リポジトリ基本情報

判断材料として重要なのが、リポジトリの健全性と活発さです。GitHub API から取得した基本情報は以下の通りです。

スター数 4,240・フォーク数 313 と、既存の類似 OSS（cognee の 2 万超などと比べると）まだ規模は小さめですが、公開から日が浅い割にコミットが直近日付（2026-08-24）で入っており、アーカイブ状態でもフォーク版でもない本家リポジトリです。ライセンスは MIT で、商用プロダクトへの組み込みや改変配布の自由度が高い点も、意思決定上のプラス材料と言えます。

作者は Fabio Akita（akitaonrails）氏で、Rust と Ruby を中心とした OSS コミュニティで長く活動しているブラジル在住の開発者です。README の「Acknowledgements」では、このコードベース自体が Claude Code（Anthropic Claude Opus 4.7）と協働して構築されている旨も明記されています（出典: akitaonrails/ai-memory README）。AI 支援開発と Rust による実装、というメタな観点でも興味を惹くリポジトリです。

なぜRustで作り直したのか — 設計思想の背景

ai-memory を検討するときにまず理解しておきたいのが、「なぜ Rust で書かれたのか」「なぜ既存の類似 OSS がある中で新たに作られたのか」という設計思想の背景です。作者本人がこの点をブログでも README でも明示的に説明しているため、判断材料としてそのまま利用できます。

「retrieve」ではなく「compile」する

ai-memory の中心的な設計判断のひとつが、Andrej Karpathy 氏が提唱した「LLM Wiki」の考え方を採用している点です。README にはこの方針が Key features のひとつとして次のように整理されています。

Karpathy-style LLM wiki. Pages are compiled from observations at session-end (or PreCompact; clients without a true session-end event can use ai-memory finalize-session --agent <agent> for a manual final close), not retrieved over raw logs.

（出典: akitaonrails/ai-memory README）

セッション終了時（あるいは PreCompact イベント）に、それまでの観測を凝集した Markdown ページへコンパイルし、以降はそのページを引く、という発想です。生ログを都度検索するアプローチと比べると、検索時のコストが小さく、内容が「読める Markdown」として残る点が特徴です。作者は自身のブログ記事「I Built a Memory System for Coding Agents: ai-memory」で、この設計判断に至った経緯を詳しく説明しています。

なお、Karpathy 氏の「LLM Wiki」の原文は karpathy/442a6bf555914893e9891c11519de94f の Gist で公開されており、README 末尾の「Influences and prior art」からも参照されています。

平文Markdown + Git を真実の源にする

もうひとつの設計上の特徴が、ストレージに専用のバイナリ形式ではなく、平文 Markdown ファイルと git を採用している点です。README では次のように説明されています。

The wiki is plain markdown in a git repo - grep-able, openable in Obsidian, backed up with rsync. No vector database to babysit, no write_note ceremony, no manual context-loading.

（出典: akitaonrails/ai-memory README）

つまり、記憶ページは Obsidian で開ける、grep で検索できる、rsync でバックアップできる、という運用上の利便性が得られます。ベクトル DB のセットアップやモデル管理を必須にしない方針で、必要になったときにオプションとして追加する形になっています。この「Markdown を真実の源とする（markdown-on-disk source-of-truth）」思想は、README の「Influences」に記載されている basicmachines-co/basic-memory からの影響を受けたものです。

agentmemory から受け継いだこと、書き直したこと

ai-memory がユニークなのは、既存の類似プロジェクトである rohitg00/agentmemory との関係を README で明示している点です。「Influences and prior art」セクションには次のように書かれています。

agentmemory - most of the right ideas; this project is the Rust successor.

（出典: akitaonrails/ai-memory README）

「ほとんど正しい発想を持っていた、本プロジェクトはその Rust 後継である」という位置づけで、agentmemory（TypeScript 実装）の思想を継承しつつ、実装言語とアーキテクチャを見直したものが ai-memory ということになります。作者は前掲のブログ記事のほか、AI Agent Memory: Karpathy LLM Wiki and agentmemory in Pract… でも agentmemory を運用する中で見えた課題と、Rust で書き直したい理由を整理しています。

agentmemory 側の設計や採用のポイントについては AIエージェントの永続メモリ基盤にagentmemoryが選ばれる理由 にまとめています。ai-memory を検討する際は、この後継関係を理解した上で読み比べると位置づけがはっきりします。

アーキテクチャの全体像と主要コンポーネント

続いて、ai-memory がどのようなコンポーネントで構成されているかを整理します。運用上のイメージを掴む上で最も重要なのは、「1 個の Rust バイナリ + 1 個のデータディレクトリ」というシンプルな構成に集約されている点です。詳細は公式の docs/ARCHITECTURE.md にまとまっています。

データディレクトリの構造

サーバーが所有するデータディレクトリは、次のような役割ごとのサブディレクトリで構成されています（README の記述に基づく構成）。

• wiki/ — Markdown で書かれた「真実の源」。git でバージョン管理される
• raw/ — Managed workstreams モードで取得された、サニタイズ済み・不変（immutable）のトランスクリプト
• db/ — SQLite のインデックス（FTS5 全文検索・エンティティ・埋め込み）
• models/ — ローカル埋め込みモデル用（予約領域）
• logs/ — ローリングトレース出力

書き込みは 1 個の SQLite ライターを通じて直列化され、各エージェントのライフサイクルフックが送ってきた観測イベントを、セッション終了時に Markdown ページへコンパイルする流れになっています。

ハイブリッド検索（FTS5 + エンティティ + グラフ + 埋め込み）

検索は、複数のシグナルを Reciprocal Rank Fusion（RRF）で束ねるハイブリッド構成になっています。README では次のように説明されています。

Authority-aware recall. FTS5, entity-match RRF, graph-neighbor RRF, and optional vector RRF generate candidates by relevance.

（出典: akitaonrails/ai-memory README）

つまり、SQLite の FTS5 による全文検索、エンティティ一致による検索、グラフ隣接ノードによる検索、そしてオプションのベクトル検索の 4 系統を組み合わせています。埋め込みプロバイダを設定しない「Zero-LLM モード」でも、FTS5・エンティティ・グラフ隣接・ルールベース要約だけで動作するようになっており、README ではこの点が「LLM is opt-in」として明確に位置づけられています。

検索の重み付けやハンドオフの生成ロジックの詳細は、docs/ARCHITECTURE.md と設計判断の背景をまとめた docs/design-decisions.md に整理されています。

プロジェクト分離とマルチワークスペース

もうひとつ、実運用で重要になるのがプロジェクトごとの分離設計です。README では次のように、物理的な階層でプロジェクトを分離する方針が明記されています。

Per-project isolation by construction. Each project lives at <wiki_root>/<workspace_id>/<project_id>/… keyed by stable UUIDs.

（出典: akitaonrails/ai-memory README）

同じページパスが 2 つの異なるプロジェクトで衝突することなく共存でき、プロジェクトの削除は rm -rf 一発で完了する、というシンプルな運用が可能になっています。加えて、任意のディレクトリに .ai-memory.toml というマーカーファイルを置けば、workspace / project の割り当てを明示的に指定できます。モノレポや git worktree、あるいは仕事用と個人用の分離を「うっかり混ざる」ことなく管理したいケースで有用です。

対応エージェント（Support Matrix の要点）

ai-memory の大きな売りのひとつが、対応するコーディングエージェントの幅広さです。単一のエージェント専用ではなく、Claude Code・Codex・Cursor をはじめとする 14 以上のハーネスに対応しており、README では「Support Matrix」として一覧化されています。詳細は README のほか、docs/mcp-install.md に MCP 設定のリファレンスがまとまっています。

主要ハーネスの対応状況

README の Support Matrix から、主要ハーネスの対応度と特徴を抜粋すると次のようになります（出典: akitaonrails/ai-memory README）。

プラットフォームは Linux が主要ターゲットで、macOS（Apple Silicon ネイティブバイナリあり）、Windows（WSL2 推奨、ネイティブは Experimental）にも対応しています。Arch Linux 向けには AUR パッケージも用意されています。

MCPのみ対応と lifecycle hooks 対応の違い

対応度の「Supported」と「MCP-only」は、実運用時に重要な差になります。Supported なエージェントでは、セッション終了イベントや SessionStart などのライフサイクルフックを利用して、観測の自動キャプチャとハンドオフの自動注入が行われます。一方 MCP-only のエージェント（Claude Desktop・Zed・VS Code Copilot など）ではフックが使えないため、ハンドオフの受け取りは MCP ツールを能動的に呼び出す（例: memory_handoff_accept）形になります。

自分の主戦場のエージェントがどちらに属するかを最初に確認しておくと、「入れたのに期待した振る舞いにならない」というつまずきを避けやすくなります。

セットアップの流れ（インストール手順の概略）

ai-memory は Rust の単一バイナリで動作するため、導入経路は比較的シンプルです。ここでは、README と docs/install.md を基に、代表的な導入経路と初期設定コマンドの役割を整理します。

なお本記事はドキュメントベースの紹介であり、実行手順の網羅的な検証を目的としたものではありません。導入を検討する際は必ず公式インストールガイドの最新版を参照してください。

Docker で立ち上げる最短経路

最初に試すのに最も手軽なのは Docker です。README の「Quick Start」セクションでは、ループバックバインドと Zero-LLM モードでの最短起動が案内されています。Docker イメージは linux/amd64 と linux/arm64 の両アーキテクチャに対応しており、Docker Desktop 越しでの Windows 実行にも対応した公式ラッパーが用意されています（出典: akitaonrails/ai-memory README）。

デフォルトでは 127.0.0.1:49374 のループバックのみにバインドされ、外部公開はされない構成になっています。ホームラボや LAN 内の複数マシンから 1 台のサーバーへアクセスしたい場合は、後述する bearer token 認証と併せて公開範囲を明示的に広げる形になります。

install-mcp と install-hooks の役割

各エージェント側の設定は、install-mcp と install-hooks の 2 つのサブコマンドに分かれています。

• install-mcp — 各エージェントの MCP 設定ファイル（例: Claude Code の .mcp.json、Cursor の設定、Kimi Code の ~/.kimi-code/mcp.json など）に、ai-memory サーバーへの接続情報を追記する
• install-hooks — 各エージェントのライフサイクルフック設定に、観測をサーバーへ POST するフックスクリプトを登録する

install-mcp だけで最低限の「ツールとしての呼び出し」は成立し、install-hooks を追加することで自動キャプチャと自動ハンドオフが有効化されます。MCP-only のエージェントでは install-mcp のみを実施し、ハンドオフの受け取りは MCP 呼び出しで対応する、という切り分けになります。詳細な引数リファレンスは docs/install.md および docs/mcp-install.md にまとまっています。

Zero-LLMモードで始める選択肢

前述の通り、ai-memory は LLM プロバイダを設定していない「Zero-LLM モード」でも運用できます。README では次のように、この位置づけが明示されています。

LLM is opt-in. Zero-LLM mode still gives you FTS5, manually declared entity, and graph-neighbor search plus rule-based summarisation. Add a provider when you want consolidated pages, lint contradictions, or staged auto-improvement proposals.

（出典: akitaonrails/ai-memory README）

LLM プロバイダは、コンソリデーション（セッション終了時のページ生成）、lint（矛盾検出）、bootstrap（既存プロジェクトからの初期ページ合成）などの場面で必要になります。まずは Zero-LLM モードで検索と手動書き込みの流れを確認し、必要になった段階で Anthropic・OpenAI・Gemini・GitHub Copilot などのプロバイダを追加する、という段階的な導入が可能です。

なお、README では anthropic-oauth プロバイダについて「Anthropic の利用規約に反する非公式手段である」旨が明示的に警告されているため、業務利用の際は選択しないほうが安全です。

Managed workstreams — 複数ハーネス横断でセッションを継続する

ai-memory の中でも既存の類似 OSS と最も差がつく機能が、Managed workstreams（マネージド・ワークストリーム）です。詳細は docs/managed-workstreams.md に整理されています。

想定ワークフロー

README の Key features では、Managed workstreams の目的が次のように説明されています。

Opt-in managed workstreams. ai-memory run claude, then ai-memory run codex --yolo, then ai-memory run command-code, transparently resumes one logical workstream with native per-harness sessions, a portable visible-event ledger, and full-ledger search.

（出典: akitaonrails/ai-memory README）

つまり ai-memory run claude で Claude Code のセッションを開始し、そのまま ai-memory run codex --yolo で Codex に切り替え、さらに ai-memory run command-code で Command Code に移る、というエージェント横断の作業をひとつの論理的な「ワークストリーム」として扱えるようにする仕組みです。各エージェントのネイティブなセッション再開機能を活用しつつ、共通のイベント台帳（portable visible-event ledger）を通じて相互に文脈を引き渡します。

想定される使い方としては、「昼間はチームで契約している Claude Code、夜間は個人利用の Codex で続きから作業する」「試験導入中の別ハーネスへ、既存の作業ログを持ったまま乗り換える」といったシナリオが典型です。

ai-memory run と ai-memory continue の違い

Managed workstreams には、明示的にハーネス名を指定する ai-memory run <harness> と、直近のセッションを自動で選択する ai-memory continue の 2 系統が用意されています。README では、ai-memory run の引数なし呼び出しについて次のように説明されています。

ai-memory run with no harness continues the newest usable Claude Code, Codex, OpenCode, Pi, Crush, Kimi Code, Command Code, or Kiro CLI v2/v3 session for this checkout.

（出典: akitaonrails/ai-memory README）

つまり、ハーネスを指定しない場合は「このチェックアウトで最も新しく使えるセッション」を自動選択します。ハンドオフのパケットには origin-marking（発生元マーキング）が付き、Claude が自分自身で書いて読み戻したパケットはそのまま破棄される、といったループ防止の仕組みも組み込まれています。

類似OSSとの位置づけ（内部リンクハブ）

ここまで見てきた通り、ai-memory は既存の類似 OSS と重なる領域を持ちながら、Rust による単一バイナリ運用と複数ハーネス横断という差別化ポイントを持ちます。既に技術ブログで紹介してきた 4 つの類似 OSS それぞれとの位置関係を整理しておきます。

claude-mem との違い

thedotmack/claude-mem は、Claude Code へセッション間の記憶を追加することに特化した TypeScript 実装のプラグインです。SQLite と Chroma を組み合わせたハイブリッド構成で、対象は Claude Code に絞られています。ai-memory は Rust の単一バイナリで動作し、Claude Code に加えて 14 以上のハーネスに対応する点、そして Managed workstreams で複数ハーネス横断のセッション継続を提供する点で立ち位置が異なります。claude-mem の設計と採用ポイントは Claude Codeのセッション間記憶を自動化するclaude-memの仕組み にまとめています。

agentmemory との関係（Rust successor）

前述の通り、ai-memory は README の「Influences and prior art」で自身を rohitg00/agentmemory の Rust 後継（Rust successor）と明言しています。agentmemory は TypeScript 実装で、コーディングエージェント専用の永続メモリ基盤という設計思想を先行して提示していました。ai-memory はその発想を継承しつつ、実装言語を Rust に変え、compile-not-retrieve 型のメモリモデルへと整理し直し、Managed workstreams を新設した、という関係になります。agentmemory の詳細は AIエージェントの永続メモリ基盤にagentmemoryが選ばれる理由 を参照してください。

Supermemory との違い

supermemoryai/supermemory は、SaaS を主軸としつつセルフホストも可能な、より汎用的な AI エージェントメモリ基盤です。マルチモーダルなデータ取り込みや Web SDK・コネクタが充実しており、コーディングエージェント以外の用途にも広く適用できます。ai-memory は local-first（ローカル優先）でセルフホスト前提、かつコーディングエージェント特化という点で棲み分けが明確です。Supermemory 側の詳細は AIエージェントのメモリ基盤にSupermemoryが選ばれる理由｜Mem0との違い にまとめています。

cognee との違い

topoteretes/cognee は Python 実装で、ナレッジグラフと GraphRAG を主眼に置いた AI エージェント向けメモリ基盤です。ドメイン非依存の汎用ナレッジベースとしても使える設計になっています。ai-memory は Markdown wiki + FTS5 + エンティティ / グラフ隣接 + オプションのベクトルによる RRF ハイブリッドという別系統のアプローチをとり、コーディングセッションの記憶に特化した設計を選んでいます。cognee の設計思想は AIエージェントの永続メモリにcogneeが選ばれる理由｜ナレッジグラフの強み に整理しています。

ライセンスと採用時の注意点

最後に、業務プロダクトでの採用を検討する際に押さえておきたいライセンスと運用上の注意点を整理します。

ライセンス

ai-memory のライセンスは MIT で、商用プロダクトへの組み込み・改変・再配布の自由度が高い、扱いやすいライセンスです。ライセンス本文は LICENSE を参照してください。

セキュリティ既定と非ループバック運用時の注意

前述の通り、既定では 127.0.0.1:49374 のループバックのみにバインドされる安全な構成になっています。ホームラボや LAN・VPN 越しに複数マシンから 1 台のサーバーへアクセスしたい場合は、bearer token 認証を有効にした上で公開範囲を広げる必要があります。README では、この点について次のようにトレードオフが明示されています。

Server runs local (loopback) OR on a homelab box (LAN/VPN/cloud) with bearer-token auth.

（出典: akitaonrails/ai-memory README）

DNS リバインディング対策や TLS リバースプロキシの設置は、公開範囲を広げる際に別途検討することになります。個人開発と業務利用ではリスクの捉え方が変わるため、共有サーバー化する場合は README のセキュリティ関連セクション（docs/users.md などを含む）に一度目を通しておくのが安全です。

まだ発展中である点

ai-memory はスター数 4,240・直近プッシュ 2026-08-24 とアクティブに開発が続いている一方で、リリースはまだ 0.x 系のバージョンです。Managed workstreams も opt-in と位置づけられており、機能が今後も追加・整理される可能性があります。業務プロダクトで採用する場合は、参照するバージョンを明示的に固定し、CHANGELOG を追いながら更新するといった運用が現実的です。

まとめ — ai-memoryを検討するときの判断軸

ここまでの内容を踏まえると、ai-memory は次のような要件を持つチーム・個人に特に相性が良いと言えます。

• 複数のコーディングエージェント CLI を横断して使う — Claude Code・Codex・Cursor などを日常的に使い分けているケースで、Managed workstreams による横断的なセッション継続が最も効いてくる
• local-first / セルフホスト前提で運用したい — Docker 単体、あるいは Rust ネイティブバイナリで運用できるため、SaaS 依存を避けたいプロジェクトに向く
• 記憶ページを Markdown として持ち回りたい — 平文 Markdown + git 管理のため、Obsidian で開いたり rsync でバックアップしたりといった従来の運用ツールと組み合わせやすい
• 段階的に LLM プロバイダを組み込みたい — まずは Zero-LLM モードで FTS5 + エンティティ + グラフ隣接の検索だけで運用し、必要に応じて Anthropic や OpenAI 等を追加できる

一方で、Claude Code しか使わないケースでは claude-mem のほうがシンプルに導入でき、ナレッジグラフを中心に据えたいなら cognee、SaaS ベースでのマネージド運用と汎用性を優先するなら Supermemory のほうが合っていることもあります。「AI エージェント向け永続メモリ基盤」というカテゴリ全体を俯瞰したい方は、シリーズの先行記事もあわせて確認してください。

なお本記事は、README・公式ドキュメント（ARCHITECTURE / managed-workstreams / install 等）・作者ブログをベースにドキュメントの読み解きとしてまとめたものです。実際の導入判断にあたっては、公式ドキュメントの最新版と、対象とする自プロジェクトのライフサイクル要件を必ず突き合わせてください。

関連情報

外部の開発チームによる AI エージェント開発の相談や、コーディングエージェント基盤の設計・構築を検討している方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。