Rust製でLLMwiki対応！AIコーディングエージェントに「記憶」を授ける：ai-memoryをお試ししたいのです

Rust製でLLMwiki対応。わたしも同じ設計思想でRAGを作ってましたが、良い参考になりました。

人生でここまで「お試ししなくても性能がなんとなく理解るリポジトリ」に出会うこともない。
なんせ、工程が殆ど同じものを同時期に作ってる。

こうなれば、わたしはもっと魔改造して差別化を図るしか無いですね。
うーん、歩みの遅さと世界の早さを知る、いい機会。

RAG。いいRAGを探しているんです。

RAGがないと狙った性能を作成ツールになかなか持たせられないのは、わたしが下手だからでしょうか？

セッションが切れるたびにエージェントがすべてを忘れてしまうという、AIの記憶喪失問題。博士の愛した数式を思い出します。

この「再説明の苦痛」を過去のものにしてくれるかもなツールがRust製の長期記憶RAG「ai-memory」。

1. 概要：ai-memoryとは何か？

ai-memoryはCLIベースのAIエージェントに対し、ツールやセッションを跨いだ「持続的な記憶」を提供するソリューション。まぁ簡単に言ってRAGですね。

最大の魅力はエージェントの開始・終了をトリガーに自動で情報を収集する「Fire-and-forget（放りっぱなし）」なライフサイクルキャプチャにあります。

例えば、Claude Codeを中断し、数時間後に同じディレクトリでOpenAI Codexを起動したとしましょう。

通常、後者のエージェントはこれまでの設計判断や失敗したアプローチを一切知りません。はじめまして、こんばんわです

ai-memoryを導入すれば、エージェントは過去の「Source of Truth（信頼できる情報源）」を参照し、前回のコンテキストを維持したまま作業を再開できます。これは単なるログの保存ではなく、「管理されたワークストリーム」という開発体験。

一応、Obsidianとか使ってる人なら「毎回開発ログを残して」でローカルLLMとかをサブAgentにして残させても同じことは出来る。

わたしはそのひと手間も嫌で、自作ツールで自動的にしてもらってます。
Token消費も軽いんだろうなっていう所感です

2. このツールが向く人・向かない人

ツール疲れを感じている現代の開発者にとって、ai-memoryは戦略的なバックストップらしいです。バックストップ（Backstop）とは、射撃場や狩猟において、発射した弾丸が外れたり標的を貫通したりした際に、安全に受け止めて止めるための土手や壁（安土）のこと。うーん、異文化。

向いている人

• マルチエージェントを使い分けるプロ： Claude Code, Cursor, Devin, Command Codeなど、用途に応じてエージェントを切り替える必要がある人。お金持ちですね

• 長期プロジェクトの「文脈」を重視する人： 数週間前の意思決定の背景をAIに即座に思い出させたい人。

• 「外部脳」を自分の管理下に置きたい人： 記憶をGitで管理し、Obsidianで閲覧したり、rsyncでバックアップしたりと、情報のポータビリティを重視する人。わたしはコレですね。

向かない人

• 使い捨てのコードしか書かない人： 継続的なコンテキストが必要ない、単発のタスクが中心の人。

• 環境構築を極端に嫌う人： DockerやCLIツール（ラッパーのセットアップ等）へのアレルギーがある人。

3. 性能：Rustによる高速性とライフサイクルキャプチャ

技術的な堅牢性は、このツールの大きな強み。

• Rust製の高パフォーマンス基盤： システム全体がRustで記述されており、SQLiteをインデックスとして活用。高速かつメモリ安全な動作を保証します。

• 極めて精密なデータ保持：

  • 16 KiBのDurable Backstop： すべての観察ボディに対し、16 KiBの耐久性のあるバックストップを維持します。

  • サニタイズされた保持能力： ユーザープロンプトや要約には最大16 KiB、ツール出力の通知には2 KiBの枠を確保し、ノイズを排した効率的な記憶を実現します。

• シームレスな自動化： ライフサイクルフックを利用するため、開発者はコマンドを打つたびに「記憶して」と意識する必要がありません。

4. 他ツールとの性能比：従来のRAGとの決定的な違い

一般的なRAG（検索拡張生成）が「生のログを検索する」のに対し、ai-memoryは「Wikiを編纂する」というアプローチ。

• 「Compile vs. Retrieve」： アンドレイ・カルパシー氏が提唱する「LLM Wiki」の概念を実装。膨大な生のチャットログ（アクション可能な信号が埋もれたノイズ）をそのままにせず、セッション終了時に整理統合してWiki化します。

• 歴史的背景と信頼性： ai-memoryは、Pythonベースのagentmemoryにおける知見を継承し、Rustで書き直された正統な後継ツール。cogneeなどの先行事例を研究し、開発現場での実用性を極限まで高めています。

という訳で、Obsidianと自作ツールのPierrotKnowledge、ai-memoryの3つで比較してみよう。

自作ツールはLLMwiki+OKFに準拠した形でTypeScriptとRustの2パターンで作ってて、今回はRustでつくったPierrotKnowledgeをお試しです。使用するPCはミニPCのA6。知ってる人は前回の記事で同じ検証しているのを知ってるかもです。以下は前回記事。

で、前回記事と同じタイミングでやったので同じ失敗なんですが。
実際に動画撮って計測したんですが、1日経って確認したら、普通に個人情報入っていたんで消しました。
いっかい録画する前に確認する癖をつけないと駄目ですね。

渡したのは、1000件のnote調査結果のマークダウン。
使うのはOpencode無料枠のHy3。作るのはnote攻略HTMLツール
余計なSkillやプラグインは抜いてます。設計のみFableで作ったSkillで補助しています。
UI用Skillくらい入れても良かったなぁと後になって後悔しています。

素の状態：メモリ消費560MB、速度15分、Token消費は約64000（Routerでの計測）UIがしょぼめの全体的に70％の出来（GrokでHTMLを読み込ませての診断）。ハルシネーションが結構有りました。

次に、各RAGをやってみる。メモリ消費とかは素の状態に足し算した結果

Obsidian：平均メモリ消費2.3GB、速度22分、Token消費は約23000、意外と減らないな。UIはそんなに変わらないけど、機能性は22％くらい上昇らしい。やっぱり中国産LLMはRAGで品質が簡単に上がるなぁ。ハルシネーションはかなり減って見当たらないです。速度が増えてしまった。多分検索に時間使った感じですね。

ai-memory：平均メモリ消費1.1GB、速度7分、Token消費は約18000。UIはシンプルになり、ツール内検索などのUX・機能性も素と比べて27％くらい上昇らしい。資料のもろパクリが増えて、速度がむっちゃ早くなった印象。こちらもハルシネーションはなし

PierrotKnowledge：平均メモリ消費1.1MB、速度7分、Token消費は約18000、うーん。設計思想同じなんだから変わるわけがなかった。UIはこっちもシンプルになって、機能性は27％くらい上昇。こちらも資料のもろパクリが増えた印象。こちらもハルシネーションはなし。OKFの分だけ初回は不利かなーと思ったけど、あんまり大差ない。有利もない。残念。多分何度もやりとりしたり、RAGが膨らまないと効果ないかも。ヘッドレスモードならもう少しメモリは抑えられたかも。見たかっただけかもですね。

前回記事でTypeScriptの時に消費メモリ900MBくらいに抑えられたけど、あれは機能を結構犠牲にしていたからなぁ。

早さと省エネはやっぱりRustが俄然有利だったりする。
エコシステムとかコンパイラが難ですけども。

お試しした結果：Rustはやっぱり早くて軽い。
取り敢えず入れて使ってお試しし続けますーっ

5. メリットとデメリットの徹底比較

メリット

• ベンダーロックインの完全解消： 記憶の実体はGit管理下のMarkdownファイル。エージェント間での引き継ぎが驚くほどスムーズに。

• 透明性とポータビリティ： 記憶をObsidianなどの使い慣れたエディタで閲覧・編集可能。オフラインでのgrepも容易。

• 情報のサニタイズ： 機密情報を保護しつつ価値のある知見だけ抽出。

デメリット

• Windows環境の制約： ネイティブWindowsでは実験的な扱い。WindowsユーザーにはWSL2経由の利用を強く推奨。

• LLM設定の手間： 高度な整理統合機能にはLLMプロバイダー（AnthropicやOpenAI等）の設定が必要。ただし、検索だけであれば「Zero-LLMモード」でも動作します。

6. どんな悩みを解決するか？

ai-memoryは、開発者が日々感じる「説明コスト」を劇的に下げます。

• 「Managed Workstream」による継続： ai-memory runコマンドを使用することで、異なるエージェント間でも同一の論理的なワークストリームを継続できます。

• 意思決定のトレーサビリティ： 「なぜこのライブラリを選んだのか？」「あのアプローチが失敗した理由は？」といった、数週間前の自分（とAI）の思考プロセスを、Git履歴を遡るように復元できます。

7. 導入方法：3ステップでのクイックスタート

Step 1: ホスト側ラッパーのインストール

セキュリティを考慮し、チェックサム検証を含む推奨手順でインストールします。

mkdir -p ~/.local/bin
wrapper_tmp="$(mktemp -d)"
trap 'rm -rf "$wrapper_tmp"' EXIT
wrapper_base=https://github.com/akitaonrails/ai-memory/releases/latest/download/ai-memory-wrapper
curl -fsSL "$wrapper_base" -o "$wrapper_tmp/ai-memory-wrapper"
curl -fsSL "$wrapper_base.sha256" -o "$wrapper_tmp/ai-memory-wrapper.sha256"
expected="$(awk 'NR == 1 { print $1 }' "$wrapper_tmp/ai-memory-wrapper.sha256")"
actual="$(sha256sum "$wrapper_tmp/ai-memory-wrapper" | awk '{ print $1 }')"
[ "$actual" = "$expected" ] || { echo "wrapper checksum mismatch" >&2; exit 1; }
install -m 0755 "$wrapper_tmp/ai-memory-wrapper" ~/.local/bin/ai-memory

Step 2: サーバーの起動（Docker）

バックエンドサーバーをコンテナで立ち上げます。

docker run -d --name ai-memory \
    --restart unless-stopped \
    -p 127.0.0.1:49374:49374 \
    -v ai-memory-data:/data \
    -e AI_MEMORY_LLM_PROVIDER=anthropic \
    -e ANTHROPIC_API_KEY=your_key_here \
    akitaonrails/ai-memory:latest

Step 3: エージェントの紐付け

Claude Codeなどのクライアントにフックをインストールします。

ai-memory install-mcp   --client claude-code --apply
ai-memory install-hooks --agent  claude-code --apply

Claude Codeで複数のセッションを並行利用する場合、--session-awareフラグを追加してセッション間のコンテキスト汚染を防ぐ設定がおすすめ。

8. ビジネス事例：チーム開発と長期メンテナンス

ai-memoryは、エンタープライズレベルのチーム開発にも対応可能な設計になっています。

• 「引き継ぎコスト」の最小化： 担当者が変更になっても、ai-memoryが生成したWikiを読み込ませるだけで、数ヶ月分のプロジェクト文脈を新担当者のエージェントに即座に復元させることができます。

• エンタープライズ向け認証と属性管理： OIDC（OpenID Connect）やベアラートークン認証をサポート。共有サーバー上での運用において、誰がどの知見を蓄積したかというアトリビューションを明確に管理できます。

9. まとめ：AIとの共生を一段上のレベルへ

ai-memoryは、単なる便利なツールを越えた、開発者の「外部脳」として機能します。

面倒なセッションメモは金輪際とらなくていいのは助かると思うんですけども、なかなかRAGを周囲で使ってる人が居ないのも事実。

なんで使いたくないんだろう？
むっちゃ便利です。