AIエージェントの永続メモリとは？Claude Code時代に必要になった理由
persistent memory、long-term memory、MCP memory serverなどの言葉がなぜ注目されているのかを、Claude CodeやCodexの作業文脈から整理します。
永続メモリという言葉が出てきた背景
AIエージェントは、1つのチャットの中では非常に強力です。しかし、セッションが変わった瞬間に、前回どのファイルを読んだか、どのエラーを見たか、どの方針を捨てたかを失いやすいという問題があります。
Claude Code、Codex、CursorのようなAIコーディングエージェントを毎日使うほど、この問題は目立ちます。毎回プロジェクト構成を説明し直し、昨日読んだIssueを貼り直し、なぜその実装方針にしたかをもう一度説明することになります。
persistent memoryが解く問題
persistent memoryは、AIエージェントがセッションをまたいで参照できる記憶のことです。単にチャットログを保存するだけではなく、次の推論に必要な情報を取り出しやすい形にしておくことが重要です。
たとえば、ユーザーの好み、プロジェクトの設計方針、よく使うコマンド、以前に失敗した実装、調査済みのGitHub Issueなどがメモリ候補になります。これらがあると、エージェントは毎回ゼロから始めずに済みます。
何を記憶すべきで、何を記憶すべきではないか
永続メモリで難しいのは、たくさん保存することではありません。次の推論で役に立つ形に削ることです。すべてのチャットログ、すべての画面、すべてのブラウザ履歴をそのまま突っ込むと、ノイズが増え、トークンも増え、古い情報が新しい判断を邪魔します。
残すべきものは、再利用される可能性が高い情報です。プロジェクト固有のルール、採用した設計方針、捨てた選択肢と理由、よく使うコマンド、失敗した調査、ユーザーの好み、進行中のタスクなどです。
逆に、その場限りのログ、秘密情報、古い一時的な仮説、誤った推測、個人情報は慎重に扱う必要があります。AI memoryは便利ですが、間違った情報を長く覚えるほど、後の回答が静かに悪くなります。
memoryの実装パターン
実装パターンは大きく4つあります。1つ目は、会話履歴をそのまま検索する方法です。実装は簡単ですが、会話の外で起きた調査や判断を拾えません。
2つ目は、ユーザーやプロジェクトに関する事実を抽出して保存する方法です。Mem0や多くのmemory APIはこの方向に近く、アプリに組み込みやすい一方で、作業画面やブラウザ履歴のような周辺文脈は別途集める必要があります。
3つ目は、エージェントランタイム側でmemoryを持つ方法です。Lettaのようにstateful agentを作る場合に向いています。エージェントそのものを設計するなら強力ですが、既にClaude CodeやCodexやCursorを使っている人の作業環境を横断するには別の接続面が必要です。
4つ目は、MCP memory serverとして外部から文脈を渡す方法です。既存のエージェントを変えずに、必要なときだけ作業メモリを読ませられるため、複数ツールをまたぐ開発者と相性が良いです。
実装方式を比較する
現在のAI memoryは、同じmemoryという言葉を使っていても実装の層が違います。SEO上もここを分けて説明しないと、Mem0、Letta、agentmemory、Recall系のどれとも同じに見えてしまいます。
| 方式 | 主な利用者 | 記憶する対象 | 強い場面 | 注意点 |
|---|---|---|---|---|
| Memory API / SDK | AIアプリ開発者 | ユーザー事実、会話、好み、アプリ内イベント | 自社プロダクトに長期記憶を組み込む | 既存のClaude CodeやCodexの外側で起きたPC作業は別途集める必要がある |
| Agent runtime memory | stateful agentを作る開発者 | agent state、memory blocks、tool call、会話 | 記憶を持つagentそのものを設計する | 既に使っている複数ツールを横断する用途とは層が違う |
| MCP memory server | 既存AIクライアント利用者 | 外部データ、作業ログ、LTM、日次レポート | Claude Desktop、Cursor、Codexなどへ後付けで文脈を渡す | 返す粒度と安全設計を誤ると、生ログの投げ込みになる |
| Local work memory | 複数AIエージェントを使う作業者 | 画面、ブラウザ、アプリ利用、キーボード入力、agent会話 | 会話の前後にあった作業文脈まで復元する | 記録範囲が広いので除外設定とローカル前提の設計が必須 |
Contextbergは4つ目に寄せています。エージェントの中にmemoryを作るというより、ユーザーのPC作業環境側にmemoryを置き、必要なときだけMCPで読ませる設計です。
memory API型とMCP memory server型
現在のAI memoryには大きく2つの方向があります。1つは、Mem0やLettaのように、アプリやエージェントランタイムへmemoryを組み込むAPI/SDK型です。これはAIアプリを作る開発者に向いています。
もう1つは、MCP memory serverのように、既存のClaude Desktop、Claude Code、Cursorなどへ外部メモリを接続する型です。こちらは、すでに複数のAIツールを使っている開発者が、自分の作業文脈を渡すために使います。
会話履歴だけでは足りない理由
AIエージェントの会話履歴は重要ですが、開発の判断は会話の前にかなり進んでいます。Stack Overflowを読む、GitHub Issueを追う、ログを見る、VS Codeで試して消す、ドキュメントを比較する。こうした前段はチャット履歴には残りません。
つまり、本当に必要なのはagent chat historyだけではなく、work contextです。どの画面を見て、どのページを読み、どのアプリで何をしていたかまで含めて初めて、次のエージェントが判断の背景を追えます。
これから伸びる検索語
今後は、AI agent memory、persistent memory、Claude Code memory、MCP memory server、local-first memory、cross-agent memoryのような語が増えていくはずです。
これらは単なる流行語ではなく、AIコーディングエージェントが実務に入り込むほど自然に出てくる課題を表しています。エージェントがコードを書く能力だけでなく、作業の続きを覚える能力が問われ始めています。
よいAI memoryを見分ける観点
よいAI memoryは、保存量ではなく再利用のしやすさで評価します。必要な場面で必要な粒度の情報が返るか、古くなった情報を消せるか、ユーザーが中身を確認できるか、秘密情報を除外できるかが重要です。
また、どのエージェントからでも使えるかも大きな差になります。Claude Codeだけに閉じたmemoryはClaude Codeでは便利ですが、CodexやCursorへ移った瞬間にまた説明し直しになります。複数エージェント時代には、memoryをエージェント側ではなくユーザーの作業環境側に置く発想が必要になります。
最後に、クラウド前提かローカルでも動くかです。memoryは通常のプロンプトよりも個人情報や業務情報を含みやすいので、local-first、OpenAI互換エンドポイント、OpenRouter、自前APIキー、ローカルLLMなどの選択肢があるかは導入判断に直結します。
導入前に見るべきチェックリスト
AI memoryは一度入れると、日々の作業判断に影響します。だから、単に保存できるかではなく、どの粒度で、どの出口から、どれだけ安全に取り出せるかを見るべきです。
| 観点 | 見ること | 弱い実装で起きること |
|---|---|---|
| 粒度 | 生ログではなく、Activity / Hourly / LTMのように用途別に分かれているか | 全部を詰め込み、長くて読めないcontextになる |
| 出口 | Claude Code、Codex、Cursor、Claude Desktopなど複数の接続先から読めるか | 1つのagentを離れるとまた説明し直しになる |
| 鮮度 | 直近の作業と長期記憶を分けて扱えるか | 古い判断が新しい実装を邪魔する |
| 可視性 | ユーザーが記録・要約・LTMを確認、編集、削除できるか | AIが誤って覚えた内容を直せない |
| 安全性 | ローカル保存、除外設定、localhost制限、トークン認証があるか | 便利だが導入前の不安が消えない |
Contextbergはどの位置にいるか
Contextbergは、memory APIやagent runtimeを作るものではありません。Claude Code、Codex、Cursorのような既存エージェントへ、PC上の作業文脈をMCP経由で渡すローカル作業メモリです。
会話履歴だけでなく、画面、ブラウザ履歴、アプリ利用、キーボード入力、エージェント会話履歴をまとめて、ユーザー側の作業環境にメモリを置く。この立ち位置が、SDK型のmemory基盤との違いです。