8月10日、Hexmosが「Your AI Assistant Forgets Everything. Memory Layers Fix That」と題した記事を公開した。この記事では、AIエージェントがセッションをまたいで知識を保持できない問題を「メモリ層」で解決する実装方法について詳しく紹介されている。以下に、その内容を紹介する。

AIエージェントの「健忘症」問題

CLAUDE.md や AGENTS.md のような設定ファイルは、エージェントに事前知識を与える定番の手段だ。しかし、プロダクトのアーキテクチャ、技術選定の経緯、3週間前のミーティングで出た制約条件——そういったものを全部詰め込むのは現実的ではない。仮に詰め込んだとしても、エージェントは毎回全内容を読み込むことになり、現在のタスクに無関係な情報まで常にコンテキストを圧迫する。

モデル自体は呼び出しをまたいで何も保持しない。つまり、解決策はモデルに何を送るかを制御するレイヤーに実装するしかない。

メモリ層の仕組み

メモリ層はエージェントとモデルの間に挟まるミドルウェアで、すべてのメッセージを2回通過する。

入力時：ユーザーの質問をもとにストレージを検索し、関連性の高い知識だけをプロンプトに追加してモデルへ渡す。

出力時：やり取りの内容を読み取り、保存する価値がある情報を選別してストレージに書き込む。

設定ファイルとの本質的な違いは選択だ。設定ファイルは毎回すべてを送る。メモリ層ははるかに多くを保持しつつ、現在のリクエストに必要なものだけを送る。

保存と検索の内部動作

保存時、メモリ層はLLMを使ってチャットのトランスクリプトをそのまま保存するのではなく、独立したファクトとして書き直す。「そういえば先四半期にMongoから移行したんだよね、Postgresで問題ない」という発言は、project uses Postgres, migrated from MongoDB という短い事実として格納される。

検索はキーワードマッチではなく埋め込み（embeddings）を使う。「どのデータベースを使うべきか？」と聞いても、「database」という単語がファクトに含まれていなくても、意味的な近さでPostgresに関する記録が引き出される。ただし埋め込みはエラーコードやパッケージ名といった固有の文字列には弱いため、多くのツールがキーワード検索と組み合わせて使っている。

mem0をClaude Codeで動かす

記事で紹介しているのはmem0だ。Claude Code、Codex、Cursorなど、skillsスタンダードをサポートするエージェントで動作する。

最速のセットアップはCLIを使う方法だ：

npm install -g @mem0/cli      # または: pip install mem0-cli
mem0 init --agent --agent-caller claude-code

特筆すべきは、--agentフラグを使うとメールアドレス不要・ダッシュボード不要で即座にAPIキーが発行される点だ。後から mem0 init --email <your-email> でアカウントに紐付けでき、それまでに蓄積した記憶はそのまま引き継がれる。この方法ではmem0側がLLMの呼び出しと埋め込み処理を担うため、OpenAIのキーも不要だ。

Claude Codeに統合する場合はプラグインを追加する：

/plugin marketplace add mem0ai/mem0
/plugin install mem0@mem0-plugins

これでMCPサーバー、SDKスキル、ライフサイクルフックが一括インストールされる。フックの動作は以下の通りだ：

• セッション開始時：既存のメモリを読み込む
• プロンプト送信前：関連するメモリをインジェクト（タイムアウト8秒）
• ファイル読み込み時：そのファイルに関連する記憶を追加
• セッション終了時：今回のセッションから保存すべき情報を抽出（タイムアウト30秒）

実際に動かした結果

記事ではFlaskアプリの開発中に以下の2点をエージェントに伝えた：

we use uv for everything in this project, not pip or venv directly. also keep routes in app.py, don't split into blueprints, it's a small app

CLIで確認すると、両方の情報がしっかり保存されていた。

そしてチャットをクリアした新しいセッションで、上記の設定については一切触れずに次のように指示した：

add a delete endpoint and a test for it

結果、エージェントはBlueprint構造への分割もせず、確認の質問もせず、直接app.pyを編集した。前のセッションで記録された設定が、それを知らない新しいセッションの行動を正しく制御した。

コストとトレードオフ

記事では導入前に把握すべきデメリットも率直に挙げている。

レイテンシ：プロンプト送信前の検索と、セッション終了後の抽出でレイテンシが加算される。記憶が6件だけの状態でも検索に約2秒かかった。

ストレージの肥大化：自動的なプルーニング（削除）機能はない。3週間前に撤回したアーキテクチャ上の決定が、現在の設定と同じ確度でデータベースに残り続ける。

誤った記憶の蓄積：抽出ステップが会話を誤解釈すると、その誤読が永続的な背景情報になる。記憶が間違っていてもアラートは来ない。エージェントのアドバイスが徐々にずれてきて初めて気づく、というケースが起きうる。

セットアップ自体は1時間以内で完了した（APIキーの扱いがREADMEに明示されていない点でやや手間取ったとのことだが）。記事の結論は「エージェントのコンテキスト問題はモデルの問題ではなく、ストレージと検索の問題だ」というものだ。そしてストレージの問題には、エンジニアリング的に筋の通った解決策がある。

詳細はYour AI Assistant Forgets Everything. Memory Layers Fix Thatを参照していただきたい。