2026年8月、Anthropicは Claude の記憶方式を変更した。それまで主流だった「会話終了後にモデルが全体を要約し、その要約を次回の context に差し込む」方式をやめ、対話中にトピックごとのファイルへ直接書き込むようにした。ユーザーは Memory 設定で Topics 一覧からファイルを個別に読み書き・削除でき、会社名の誤りのような事実を1ファイル訂正するだけで、以降の全会話に反映される。
この設計転換の背景には、要約ベースの記憶が抱えていた「訂正が効かない」問題がある。要約は生成のたびに作り直されるため、ユーザーが一度間違いを指摘しても次の要約で再び同じ誤りが復元されかねない。Letta が Sleep-Time Compute で採った解法は少し異なり、応答を返す主エージェントとは別に、アイドル時間帯だけ動く「Sleep-Time エージェント」が非同期に memory block を書き換える。目的は同じく編集の質を上げることだが、対話を止めずに記憶の整理コストを裏側に逃がす点に重心がある。
Cursor が2026年9月10日に公開した Projects は、記憶の対象を「個人の事実」から「プロジェクトの手順」に移した。コード自体は書かないコーディネーターエージェントが配下のサブエージェント群にタスクを振り、各エージェントが調べたコードベースの構造やテスト手順、作業の進め方の好みを共有ファイル群に書き足していく。あるエージェントがサービスのテスト方法を突き止めれば、以降に立ち上がる別のエージェントは同じ調査をやり直さずに済む。
この共有ファイルはクラウド上のマシンで永続し、ローカルの端末を閉じても止まらない。Slack やPRの監視、スケジュール実行のように、ユーザーが毎回プロンプトを打たなくても再開できる運用を前提にしているためで、Cursor は Projects を主に使うユーザーはマージするPR数が6倍になったと報告している。個人向け記憶が「誰か一人のための事実」を保持するのに対し、こちらは複数のエージェントインスタンスが横断で参照する共有ストックである点が構造的に異なる。
", "examples": [ { "product": "Cursor Projects", "approach": "コーディネーター配下のサブエージェント群が学んだコードベース知識・テスト手順・作業の好みを、クラウド上で永続する共有ファイルに蓄積する", "detail": "個人の事実ではなくプロジェクトの運用知識を記憶の対象にしている点が個人アシスタント型の記憶と異なる。Projects利用者はPRのマージ数が6倍という数字も公表されている。", "source_url": "https://cursor.com/blog/projects" } ], "takeaway": "エージェントが単発の会話ではなく継続的にコードベースやシステムを運用する用途なら、記憶すべきは「ユーザーの好み」ではなく「エージェント自身が積み上げた運用知識」であり、複数インスタンス間で共有できる構造にする必要がある。" }, { "heading": "「いつ真だったか」を残す必要があるなら、要約ではなくグラフを選ぶ", "body_html": "Zepの Graphiti エンジンは、会話ログと構造化されたビジネスデータの両方を、時間軸を持つ知識グラフとして統合する。ノードとエッジで事実を表現し、event time（その事実がいつ現実に起きたか）と ingestion time（システムがいつそれを取り込んだか）を別々に持たせることで、過去のある時点で何が正しいとされていたかまで遡って再現できる。事実は上書きされるのではなく、有効期間が終わった時点で invalid と記録されるだけで、履歴自体は消えない。
フラットな要約やトピックファイルは「今何が正しいか」には強いが、「いつからいつまで正しかったか」は原理的に表現しづらい——要約し直すたびに古い版は失われるためだ。監査や契約変更の追跡のように、過去の状態そのものが問い合わせの対象になる業務データを扱うエージェントでは、この非破壊性が要件になる。Zepはこの設計でDeep Memory Retrievalベンチマークにおいて既存手法を上回る結果を報告している。
", "examples": [ { "product": "Zep（Graphiti）", "approach": "会話データと業務データを時間軸付きの知識グラフに統合し、event time / ingestion timeの二重タイムスタンプで事実の有効期間を管理する", "detail": "事実を削除・上書きせずinvalid化するだけなので、過去のある時点で何が真だったかを後から再現できる。Deep Memory Retrievalベンチマークで既存手法を上回る結果を報告。", "source_url": "https://blog.getzep.com/zep-a-temporal-knowledge-graph-architecture-for-agent-memory/" } ], "takeaway": "「今の状態」だけでよいなら要約やトピックファイルで十分だが、監査・コンプライアンスのように過去の状態そのものが問われる用途では、非破壊で時間を刻めるグラフ構造を最初から選んでおく方が後から作り直すより安い。" } ] }, "editorial": "2026年の記憶実装が割れているのは「ベクトルDBを使うかどうか」ではなく、「いつ記憶を書き換えるか」と「壊れた記憶をどう訂正するか」だ。ライブ書き込み、非同期のバックグラウンド処理、非破壊のグラフ——どれも生の会話ログをそのまま貯めない点では一致している。次に来る論点は、この3層をまたいで記憶を移し替えるコスト——たとえば個人の記憶をプロジェクトの記憶に昇格させる境界線——になるはずだ。", "quick_picks": [ { "title": "ChatGPTの記憶システム「Dreaming」", "summary": "OpenAIが2026年6月に導入した、バックグラウンドで記憶の要約を再合成し続ける仕組み。「7月にシンガポールへ行く予定」を旅行後に自動で過去形へ書き換えるなど、Lettaの Sleep-Time Computeと同じく非同期の記憶整理という設計思想を共有する。", "url": "https://openai.com/index/chatgpt-memory-dreaming/" }, { "title": "LangGraphの長期記憶ストア", "summary": "LangChainが公式発表した、スレッドをまたいで参照できる長期記憶用のstore機能。namespace区切りのJSONドキュメントというフラットな構造を選んでおり、本文中のグラフ型（Zep）や共有ファイル型（Cursor）とは異なる第三の選択肢にあたる。", "url": "https://www.langchain.com/blog/launching-long-term-memory-support-in-langgraph" }, { "title": "LettaのMemory Blocks", "summary": "Sleep-Time Computeが書き換える対象である「メモリブロック」の設計思想を解説する記事。エージェントの記憶をコンテキストウィンドウ内に固定表示される編集可能な単位として扱う発想は、本文のClaudeのトピックファイルと近い。", "url": "https://www.letta.com/blog/memory-blocks/" } ] }