AIの長期記憶をアプリで実装する：要約記憶・ベクトル記憶・構造化メモの違いを、公式資料で確かめる

3行でいうと

AIは、渡された文脈しか読まない。記憶とは「何を保存し、いつ書き、次の会話にどう戻すか」をアプリ側で決めること。
型は3つ。古い会話を要約で置き換える、1件ずつ保存して意味で探す、決まった形のメモやファイルに書く。
Anthropicの記憶ツールは、保存と実行をアプリ側が受け持つ。パスの検証、サイズ制限、古いメモの削除は実装側の責任。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書や論文を読んでまとめたものです。数字や名前は2026年10月8日に確認し、記憶ツール・コンテキスト編集・コンパクションの文書、LangChainとOpenAIの文書、Mem0の論文のページは10月22日に読み直しました（Anthropicのエンジニアリング記事とMemGPTの論文は10月8日の確認のままです）。ベータ機能の名前や条件は変わります。

先に結論

会話の途中で文脈が長くなって困る問題と、別の日の会話を覚えておく問題は、別の問題です。前者には「要約」や「古い道具の結果の削除」、後者には「保存先」が要ります。
「ユーザーの好み」のように項目が決まっているなら、1つのJSONの形（プロフィール）が扱いやすい。蓄積する事実が増え続けるなら、1件ずつ保存して検索する形が向きます。作業の進み具合を次の回に渡すなら、ファイルやメモが向きます。
どの型でも、保存の判断、更新、削除の設計が品質を左右します。保存先を足せば解決、ではありません。

前提：言葉の整理

コンテキストウィンドウは、AIが1回の呼び出しで読める文章の範囲です。ここに入らない過去は、AIには見えません。
長期記憶は、会話をまたいで残す情報です。AIが自分で覚えているわけではなく、アプリが保存して、必要なときに文脈へ戻します。
埋め込み（エンベディング）は、文章の意味を数の並びにしたものです。意味の近い文章は、数の並びも近くなるので、意味で探せます。この探し方をベクトル検索と呼びます。

学術的には、MemGPTの論文（2023年10月）が、OSのメモリ階層に着想を得た「仮想コンテキスト管理」（速い記憶と遅い記憶の間でデータを移す）を提案しています。

Anthropicのエンジニアリング記事（2025年9月29日）は、文脈を「有限の資源」と呼び、長くなるほど、中の情報を正確に思い出す力が落ちる現象（context rot）を観察していると書いています。そのため、「入れられるだけ入れる」より、「必要な情報だけを入れる」設計を勧めています。

型1：要約記憶（古い会話を、要約で置き換える）

仕組み：会話が長くなったら、古い部分を要約に置き換えます。Anthropicの文書では、この機能を「コンパクション」と呼び、サーバー側が要約を書くため、自分で要約の処理を書かなくてよいとされています。いつ要約するかは、リクエストで指示する方法と、入力のトークン数（AIが数える文字量の単位）が設定した値に達したらAPIが自動で行う方法があります。どちらもベータ版（2026年10月22日に読み直した文書でも、ベータと書かれていました）です。OpenAIのAgents SDKにも、保存した会話履歴をResponses APIで圧縮するセッション（OpenAIResponsesCompactionSession）があります。既定では1ターンごとに圧縮が必要かを確かめ、しきい値に達したときだけ圧縮する、と書かれています。

強み：実装が軽く、1回の会話の中の「流れ」を保てます。

弱み：Anthropicの記事は、強く圧縮しすぎると、あとで重要になる細かい情報が消えると警告しています。また、別の日の会話に持ち越すものではなく、1つの会話の延命です。

関連して、古い道具の実行結果だけを、ルールで消す機能（context editing）もあります。Anthropicの記事は、道具の結果の削除を、最も安全で軽い圧縮の1つとしています。

型2：ベクトル記憶（1件ずつ保存して、意味で探す）

仕組み：「ユーザーは短く直接的な言い方を好む」のような記憶を、1件ずつ保存し、埋め込みを付けて、次の会話で意味の近いものを検索して文脈に入れます。LangChain（LangGraph）の文書では、これを「コレクション」と呼び、記憶を「名前空間（フォルダのようなもの）」と「キー（ファイル名のようなもの）」の下にJSONで保存し、意味による検索と内容による絞り込みの両方ができると説明しています。

強み：同文書は、1件ずつの記憶のほうが、新しい情報を足しやすく、情報を失いにくいため、あとから探したときの網羅性（再現率）が高くなりやすいとしています。

弱み：同文書が挙げる難点は次のとおりです。

既存の記憶を削除したり更新したりする判断が難しい。モデルによって、足しすぎる傾向と、上書きしすぎる傾向がある。
検索の設計が必要になる。
個々の記憶がばらばらで、全体の関係が文脈に入りにくい。

論文では、Mem0（記憶の抽出・整理・検索の仕組み）の論文（2025年4月）が、LOCOMOという会話記憶のテストで、OpenAIの記憶に比べて、LLMによる採点で26%の相対的な改善、全履歴を渡す方式に比べて、遅延（p95）が91%低く、トークン費用が90%以上少ないと報告しています。ただし、これは提案した側の論文の自己評価です。

型3：構造化メモ（決まった形のプロフィールやファイル）

仕組みは2つあります。

プロフィール：LangChainの文書では、人や組織に関する、範囲の決まった情報を、1つのJSONとして更新し続ける方法です。更新のたびに、前のプロフィールをモデルに渡して新しい版を作らせます。ただし、プロフィールが大きくなると誤りが増えやすく、分割や厳格な出力の形式が役立つとされています。
ファイル型のメモ：Anthropicの記憶ツールです。公式文書によると、AIは/memoriesディレクトリの中のファイルを、view、create、str_replace、insert、delete、renameの6つの操作で読み書きします。ツールは「クライアント側」で動き、Claudeは操作を要求するだけで、実際の実行と保存先（ファイル、データベースなど）は自分のアプリが受け持ちます。有効にすると、作業前にAIが自分の記憶ディレクトリを確認するように、システムプロンプトに指示が自動で足されます。

Anthropicの記事は、後者を「構造化されたメモ書き（agentic memory）」と呼び、節目のある反復的な開発に向くとしています。一方、要約は、行き来の多い会話の流れを保つのに向くとしています。

記憶ツールの実装で、公式文書が求めていること

Anthropicの記憶ツールの文書（2026年10月22日確認）から、実装側の責任の部分だけをまとめます。

ツールの設定は{"type": "memory_20250818", "name": "memory"}だけで、入力の定義は不要です。Claude 4以降のモデルで使えると書かれています。
各操作のハンドラ（受け取って実行する処理）を自分で書きます。PythonとTypeScriptにはローカルのファイルを使う実装例が付属し、C#、Javaなどには土台のクラスがあります。
パスの検証：/memories/../../secrets.envのような指定で、ディレクトリの外に出られてしまうため、すべての操作で検証する必要があります。公式の対策は、/memoriesで始まるか確認する、正規の形に直して範囲内か確かめる、../や%2e%2e%2fのようなパターンを拒否する、など。
機微な情報：Claudeはたいてい書くのを断るが、確実にするなら、書き込む前に取り除く検査を足す。
サイズ：ファイルの大きさに上限を設け、viewで返す文字数も制限し、続きはview_rangeで読ませる。
期限：長く使われていないメモは、定期的に削除する。
圧縮との併用：長く動くエージェントでは、コンパクションで文脈を小さく保ち、要約で消えると困る情報は記憶に残す、という使い分けが勧められています。
作業を複数の回にまたぐ開発では、最初の回で進捗ログと機能のチェックリストを作り、各回の最初に読み、最後に更新するパターンが紹介されています。

選び方の目安

見立てです。ここまでの資料から、僕らは次のように整理しました。

やりたいこと	向く型	理由
1つの長い会話を最後まで保つ	要約記憶、古い道具の結果の削除	文脈の肥大を抑える。別の日には持ち越さない
利用者の好みや設定を覚える	プロフィール（JSON）	項目が決まっていて、人が中身を確認しやすい
利用者や案件ごとの事実が増え続ける	ベクトル記憶	件数が増えても意味で探せる。更新と削除の設計が要る
長い作業を、複数の回に分けて進める	ファイル型のメモ	進捗と判断を明示的に書き残せる

組み合わせも自然です。たとえば、会話の中は要約で保ち、会話の終わりに、残すべき事実だけを別の保存先に書く、という形です。LangChainの文書は、書き込みの時点にも2通りあるとしています。会話中に書く方法（すぐ使えるが、遅くなり、本来の仕事と注意を取り合う）と、あとで裏側で書く方法（遅くならないが、書く頻度とタイミングの設計が要る）です。

つまずきやすい点

全部覚えさせる。保存が増えるほど、検索のノイズと古い情報が増えます。何を覚えるかの基準と、消す条件を先に決めます。
記憶の更新を、モデル任せにする。LangChainの文書は、評価（テスト）で挙動を調整するよう勧めています。
記憶が正しいと決めつける。保存された記憶は、過去のモデルの判断の結果です。誤りが残ると、次の会話に持ち越されます。見立てです。利用者が中身を見て直せる画面があると、運用しやすいと考えます。
記憶に外部の文章を混ぜる。僕らの見立てです。ウェブから取った文章をそのまま記憶に書くと、指示のような文面が将来の会話に混ざる恐れがあります。この点は、読んだ文書では確認できていません。

気をつけること

この記事は、実際に使って確かめた記録ではありません。内容は公式文書と論文の記述に基づきます。
コンパクションと、context editingの一部はベータ版で、名前やパラメータ（例：compact-2026-09-04）が変わる可能性があります。
Mem0の数字は、提案した側の論文の自己評価で、独立した検証ではありません。LOCOMOという特定のテストの結果です。
3つの型の名前は、僕らが整理のために付けたものです。LangChainの文書は「プロフィール」「コレクション」、Anthropicは「コンパクション」「構造化メモ」「記憶ツール」と呼んでいます。
利用者の情報を保存する場合の、個人情報の扱いや保存期間の法的な要件は、この記事では扱っていません。個別の判断は専門家に相談してください。
ChatGPTやClaudeの、製品としての「メモリー機能」の仕様は読んでいません。この記事はアプリに自分で組み込む場合の話です。

出典

更新履歴

2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した
2026年10月22日 公式の資料を読み直して、次の点を直しました。
- 前：OpenAI Agents SDKのセッションは、1ターンごとに自動で圧縮することもできる → いま：既定では1ターンごとに圧縮が必要かを確かめ、しきい値に達したときだけ圧縮する