ユーザーを記憶しないAIエージェントには、根本的な限界があります。会話のたびに最初から始まり、ユーザーは自己紹介を繰り返し、好みをもう一度説明し、進行中の作業を再度明確にしなければなりません。摩擦が積み重なり、信頼が低下します。
これがメモリの問題です。コンテキストウィンドウは現在の会話を扱います。セッション、日、月をまたぐ長期メモリには、独自のアーキテクチャが必要です。そして、その構築は見た目以上に困難です。
この記事では、本番環境における実際のエージェントメモリを解説します。メモリの階層、保存方法の選択、検索パターン、そして役に立つメモリとハルシネーションを起こすメモリを分けるトレードオフを扱います。
「メモリ」とは何か
単純に考えれば、メモリとは「モデルが会話をまたいで物事を覚えていること」です。しかし、現実はもっと複雑です。認知科学では記憶の種類を区別しており、AIエージェントのメモリでも同様の区別が役立ちます。
作業記憶。 現在の会話です。コンテキストウィンドウ内に保持されます。永続化しない限り、会話が終わると失われます。
エピソード記憶。 過去の具体的な出来事です。「先週の火曜日にXについて話しました」「3か月前にYを決定しました」などです。
意味記憶。 一般的な事実です。「あなたの名前はAliceです」「簡潔な回答を好みます」「会社はTallinnにあります」などです。
手続き記憶。 物事の進め方です。「ユーザーが会議を依頼したら、このテンプレートを使います」「顧客がtier Xなら、process Yに従います」などです。
メモリの種類ごとに機能が異なります。完全なエージェントメモリシステムは、そのすべてを扱います。
メモリが実現すべきこと
アーキテクチャを検討する前に、目標を整理します。
連続性。 エージェントが前回の続きから始めます。セッションのたびに自己紹介をやり直す必要がありません。
パーソナライズ。 指示されなくても、エージェントがユーザーの好みを適用します。ユーザーの文体で書き、ユーザーのツールを使い、ユーザーのチームへ言及します。
コンテキストの保持。 過去の会話で決めたことを現在の会話に反映します。「先月Xに決めました」という内容を覚えている必要があります。
スキルの蓄積。 エージェントがユーザーのパターンを学び、適用します。Pythonでのコーディングについて10回会話した後は、デフォルトでPythonを選ぶべきです。
プライバシーと忘却。 何を記憶し、何を記憶せず、何を削除するのかを管理します。ユーザーの信頼と法令遵守の両方に関係します。
これらの目標は、ときに衝突します。連続性のためにはすべてを記憶したくなりますが、プライバシーのためには何も記憶したくありません。アーキテクチャによって、このトレードオフを調整します。
アーキテクチャ
典型的な階層型アーキテクチャは、次のとおりです。
┌─────────────────────────────────────┐
│ 作業記憶（コンテキスト内） │ 現在の会話
├─────────────────────────────────────┤
│ セッションメモリ（直近） │ 直近N件の会話
├─────────────────────────────────────┤
│ エピソード記憶（長期） │ 過去の具体的な出来事
├─────────────────────────────────────┤
│ 意味記憶（事実） │ 安定したユーザー情報
├─────────────────────────────────────┤
│ 手続き記憶（好み） │ このユーザーに対する振る舞い方
└─────────────────────────────────────┘
各階層には、それぞれの保存、検索、減衰ロジックがあります。
一つずつ見ていきましょう。
階層1：作業記憶
コンテキストエンジニアリングの記事ですでに扱った内容です。現在の会話をコンテキスト内に保持します。複数ターンの会話では、直近のターンをそのまま残し、古いターンを要約した階層型コンテキストを使います。
長期メモリへの引き継ぎは、セッションの終了時に行います。会話の重要情報を抽出して保存します。
階層2：セッションメモリ
直近のセッション、たとえば最後の10件の会話を簡潔な情報として保持し、次回のセッションでエージェントが利用できるようにします。
実装では、セッションごとの要約をタイムスタンプとトピックとともに保存します。ユーザーが戻ってきたとき、エージェントは最近の出来事をすぐに参照できます。
{
"session_id": "abc-123",
"user_id": "alice",
"started": "2026-05-14T10:30:00Z",
"ended": "2026-05-14T10:45:00Z",
"topic": "Acme Corp向け提案書の作成",
"summary": "Acme向け提案書のv1を作成しました。コスト削減の観点を冒頭に置くと決めました。Aliceが確認し、金曜日に送付します。",
"facts_learned": ["Acmeは現在の顧客", "Aliceの期限は金曜日"],
"open_items": ["Aliceが木曜日までにv1を確認する"]
}
新しいセッションでは、直近3～5件のセッション要約を自動的に読み込めます。これにより、エージェントは最近の出来事を把握できます。
これは、セッションをまたぐメモリの中で最も導入しやすい形です。実装が容易で、すぐに役立ちます。
階層3：エピソード記憶
長期的に記憶する価値がある具体的な過去の出来事です。決定、節目、重要な会話などが該当します。
注目すべき出来事があればセッションから抽出し、豊富なメタデータとともに保存します。
{
"event_id": "ev-456",
"user_id": "alice",
"date": "2026-04-22",
"type": "decision",
"description": "Aliceは、クエリ性能を理由に、分析ワークロードをPostgresからClickHouseへ移行すると決定しました。",
"context_summary": "性能テストとコスト分析を含む3週間の評価を経た決定です。",
"related_topics": ["infrastructure", "analytics", "database"],
"importance": "high"
}
検索では、現在の会話に関連する過去の出来事をエージェントが取得します。セマンティック検索（現在のクエリを埋め込み、類似する出来事を検索）、トピックの一致、または時間に関するクエリ（「先月は何がありましたか」）を利用します。
課題は、「記憶する価値のある出来事」の基準を決めることです。すべての会話が該当するわけではありません。一般的なパターンでは、セッション終了時にLLMが会話から注目すべき出来事を抽出します。決定、約束、節目は保存し、雑談は保存しません。
階層4：意味記憶
常に利用できるべき、ユーザーに関する安定した事実です。「AliceはAcmeのCEOです。簡潔なコミュニケーションを好み、Tallinnのタイムゾーンで働いています」などです。
量はエピソード記憶より少ない一方、より頻繁に検索されます。エージェントの「ユーザーモデル」を形成します。
実装には構造化したプロファイルを使います。
{
"user_id": "alice",
"profile": {
"name": "Alice Tamm",
"role": "CEO at Acme Corp",
"location": "Tallinn, Estonia",
"timezone": "Europe/Tallinn",
"preferred_language": "English",
"communication_style": "concise, direct, no preamble",
"expertise_areas": ["product strategy", "go-to-market"],
"tools_used": ["Notion", "Slack", "Linear"]
}
}
エージェントが新しい事実を知ったときに更新します。セッション後にLLMが新たな安定した事実を特定して提案し、自動的に統合するか、レビュー待ちにします。
重要なのは、意味記憶の事実には高い確度と安定性が必要だということです。一度の会話で何気なく述べた「Pythonを試すかもしれない」という発言を、「AliceはPythonを好む」という意味記憶にしてはいけません。保存の基準を高くします。
確信度に基づく方法は、次のとおりです。
- 一度聞いた：候補となる事実。まだ保存しません。
- 二度聞いた、または明示された：中程度の確信度で保存します。
- 明示的に確認された、または頻繁に言及された：高い確信度で保存します。
これにより、何気ない発言から誤った事実をエージェントが「学習」することを防ぎます。
階層5：手続き記憶
このユーザーに対して、エージェントがどのように振る舞うべきかを表します。ワークフロー、テンプレート、特定の操作に関する好みです。
例：
{
"user_id": "alice",
"procedural": {
"email_signature": "...",
"meeting_preferences": "必ず3つの時間帯を提示し、午前9時より前には予定を入れない",
"code_style": "Pythonでは型ヒントを必須とし、辞書よりdataclassを優先する",
"tone_for_clients": "温かく率直に伝え、次のステップを明示する",
"approval_process": "顧客向けの連絡はすべて送信前にAliceの確認を受ける"
}
}
関連するタスクが生じたとき、エージェントはこれらのパターンに従います。
更新は、明示的な指示（「Alice、この方法で常にXを行ってください」）またはパターン認識（同様の依頼を5回同じ方法で処理した後に、そのパターンを追加）によって行います。
保存方法の選択
メモリをどこに保存すべきでしょうか。
SQLデータベース。 信頼性が高く、クエリ可能で、十分に理解されています。メモリの種類ごとにテーブルを用意し、検索ではJOINを使います。構造化したアクセスパターンに適しています。
ベクトルデータベース。 エピソードのセマンティック検索（「このトピックに関連する記憶を探す」）に使います。エピソードを埋め込み、類似度で検索します。
組み合わせ。 多くの場合は最適です。構造化クエリにはSQL、セマンティック検索にはベクトルを使います。メモリ項目は一貫したIDを使い、両方に保存します。
メモリ専用ツール。 Mem0、Letta（旧MemGPT）、Zepなどです。エージェント専用に構築されたメモリレイヤーです。より高水準の抽象化が必要なら検討する価値があります。
ほとんどのチームでは、シンプルなSQLとベクトルの組み合わせで十分です。専用ツールは便利ですが、依存関係が増えます。
検索パターン
エージェントはどのようにメモリをコンテキストへ取り込むのでしょうか。
パターン1：セッション開始時の自動読み込み
新しいセッションを始めるとき、次の情報を自動的に取得します。
- ユーザーの意味記憶プロファイル。
- 直近N件のセッション要約。
- 未完了の約束またはフォローアップ。
これは、ユーザーが現れたときにエージェントが持つ基本コンテキストです。
パターン2：クエリ主導の検索
ユーザーのメッセージが過去のトピックを示唆する場合、関連するエピソードを検索します。
例として、ユーザーが「データベースについて話したときの結論は何でしたか」と尋ねたとします。エージェントはエピソードから「database」を検索し、関連するものを取得します。
実装では、ユーザーのメッセージを埋め込み、類似するエピソードを検索してコンテキストに含めます。
パターン3：明示的なメモリツール
エージェントに、メモリを照会するツールを用意します。
search_episodes(query)：過去の特定の出来事を検索します。get_user_profile()：意味記憶プロファイルを取得します。list_open_items()：保留中の約束を一覧表示します。
エージェントは会話に基づいて、これらをいつ呼び出すかを決めます。
パターン4：バックグラウンドでのメモリ拡充
バックグラウンドプロセスで定期的にメモリを確認し、次を行います。
- 関連するエピソードをテーマへ統合します。
- 事実の確信度を更新します。
- 長期間参照されていない古いメモリを減衰させます。
これは「メモリのメンテナンス」であり、時間が経ってもメモリストアを有用に保つ処理です。
メモリへの書き込み
いつメモリへ書き込むべきでしょうか。
セッション終了時の抽出
信頼性の高いパターンです。セッションが終了したら、次の処理を行います。
- LLMが会話を分析します。
- 次を抽出します。
- セッション要約。
- 注目すべき出来事（エピソード記憶向け）。
- 新しい事実（意味記憶向け）。
- 好みを示すシグナル（手続き記憶向け）。
- 更新して保存します。
この一括処理により、会話中にメモリを書き込まず、セッション中の体験を高速に保てます。
抽出用のプロンプトは、次のようになります。
この会話を分析し、次を含むJSONを出力してください。
1. summary：起きたことを2～3文でまとめた要約。
2. notable_events：記憶する価値がある重要な出来事（決定事項、節目、重要なコンテキスト）の配列。
3. new_facts：ユーザーについて新たに分かった安定した事実の配列（高い確信がある場合にのみ含める）。
4. preference_signals：観察された好みの配列（明示されたか、繰り返された場合にのみ含める）。
5. open_items：ユーザーが後で再確認する可能性のある未解決項目の配列。
慎重に判断してください。高い確信がある項目だけを含めてください。ハルシネーションを起こすより、何かを見落とす方が適切です。
価値の高い事実をリアルタイムで更新する
事実によっては、セッション終了まで待つべきではありません。ユーザーが「実は、私の名前はAliceではなくAlexです」と言った場合、その訂正は直ちに適用する必要があります。
エージェントに明示的な訂正や重要な新事実をリアルタイムで検出させ、メモリをその場で更新する方法があります。
これには慎重な設計が必要です。LLMが誤った事実を「学習」する可能性があるためです。リアルタイムの更新を適用する前に、ユーザーの確認を必須にするチームもあります。
ユーザーによる更新
ユーザーは、記憶すべき内容をエージェントへ明示的に伝えられます。
- 「Xを好むことを覚えておいてください」
- 「Yについて話したことを忘れてください」
- 「常にZを行ってください」
これらは第一級の機能として扱い、直ちに従ってください。最も確信度の高いシグナルです。
エージェントが提供できる具体的なツールは、次のとおりです。
remember(content: string, type: "fact" | "preference" | "procedure")
forget(content: string)
list_what_you_remember()
この制御をユーザーに与えることで、信頼が高まります。
忘却と減衰
際限なく増えるメモリは、雑音になります。減衰は不可欠です。
時間に基づく減衰
古いメモリは検索される可能性を低くします。実装方法は次のとおりです。
relevance * recency_decayで検索スコアを計算します。- 明示的に参照されない限り、古いメモリは実質的に表示されなくなります。
重要度に基づく保持
重要なエピソードは長く保持し、些細なものは早く減衰させます。
- 書き込み時にエピソードへ重要度を付けます。
- 重大な出来事：無期限に保持します。
- 日常的な出来事：数か月かけて減衰させます。
ユーザーによる忘却
ユーザーは、特定のメモリの削除を要求できます。
- 特定の事実。
- 特定の期間。
- 特定のトピック。
実装では、関連項目を削除するか、削除済みとしてマークする操作を用意します。
コンプライアンスに基づく削除
法的要件（GDPRの忘れられる権利、データ保持法）によって、削除が義務づけられる場合があります。
- ユーザーアカウントの削除 → すべてのメモリを削除。
- リクエストごとのデータ削除 → 特定のメモリを削除。
- 保持期限 → Nか月後に自動削除。
これらは最初から組み込む必要があります。後付けは困難です。
プライバシー上の考慮事項
メモリには機密性があります。エージェントはユーザーについて多くを知っています。次の点を考慮してください。
保存時の暗号化
メモリデータを暗号化します。標準的な対策です。
アクセス制御
ユーザーのメモリを閲覧できるのは誰でしょうか。本人だけか、システムだけか、特定の条件下ではサポート担当者も閲覧できるのかを明確に定義します。アクセスを監査してください。
PIIの取り扱い
個人を特定できる情報（実名、住所、財務情報）にはタグを付け、慎重に扱います。専用のアクセス制御と削除手順が必要です。
ユーザーからの可視性
エージェントが何を記憶しているかを、ユーザー自身が確認できるようにします。倫理的に正しいだけでなく、優れたUXでもあります。「メモリダッシュボード」を提供してください。
エージェントがあなたについて記憶していること：
プロファイル：
- 名前：Alice Tamm
- 役割：Acme CorpのCEO
- コミュニケーションスタイル：簡潔、率直
直近のセッション：
- 2026-05-14：Acme向け提案書を作成
- 2026-05-12：Q1の結果をレビュー
- ...
好み：
- 簡潔な回答を好む
- Notion、Slack、Linearを使用
[編集] [特定の項目を削除] [すべて削除]
この透明性が信頼を築きます。隠されたメモリは不気味に感じられます。
コンテキスト間の共有
ユーザーに複数の「モード」（仕事用エージェント、個人用エージェント）がある場合、メモリを分離したいことがあります。依頼されない限り、モード間で自動共有しないでください。
よくある失敗モード
いくつかのパターンを挙げます。
失敗1：捏造された記憶
エージェントが、起きていないことを記憶していると主張します。「先週Xに合意しました」と言いますが、Xについて話したことはありません。
原因：抽出または検索時に、LLMがもっともらしい記憶を「補完」します。
対策：メモリ操作を実際の会話データに基づかせます。LLMが抽出し、実際の文字起こしと照合します。捏造された事実にはフラグを付ける必要があります。
失敗2：誤った事実の学習
エージェントが誤った事実を自信を持って述べます。実際には仕事でPythonを使わざるを得ないと言ったのに、「Pythonを好むと言っていました」と主張します。
原因：抽出時の誤解です。
対策：確信度のしきい値を設けます。明示された、繰り返された、または確認された発言からだけ学習します。ユーザーが訂正できるようにします。
失敗3：プライバシー漏えい
あるユーザーのメモリが、別のユーザーとの会話に現れます。壊滅的な問題です。
原因：ユーザーごとにデータを分離するロジックの不具合です。
対策：保存レイヤーと検索レイヤーで、ユーザーのスコープを強制します。監査してください。フィルタリングをLLMに任せてはいけません。
失敗4：メモリの肥大化
1年後には、ユーザー1人当たりのメモリが数MBになります。検索が遅くなり、コストが増えます。
原因：減衰や刈り込みがありません。
対策：積極的に減衰させます。数か月後には大半のメモリをアクセス困難（検索優先度を低く）にします。定期的に圧縮してください。
失敗5：古くなった事実
ユーザーが6か月前に役割を変えたのに、エージェントが以前の役割へ言及し続けます。
原因：古い事実が置き換えられたときに更新されていません。
対策：矛盾を検出します。新しい事実が古い事実と矛盾する場合は、新しい事実を優先します（不確かな場合は確認します）。
失敗6：混乱を招く統合
バックグラウンドのメモリ統合で、ときどき情報が失われる形に記憶が書き換えられます。
原因：重要な事実を保持せずに、過度な要約を行っています。
対策：統合時に保持すべき事実を明示します。実際のメモリの文字起こしを使って、統合処理をテストしてください。
実例：メモリを備えたパーソナルアシスタント
実際のユースケースとして、個人ユーザー向けのパーソナルAIアシスタントを考えます。
メモリの階層：
- 作業記憶： 現在の会話。
- セッションメモリ： 直近7セッションを要約形式で保持。
- エピソード記憶： 直近100件の注目すべき出来事をセマンティック検索付きで保持。
- 意味記憶： ユーザープロファイル（名前、役割、好み、ツール）。
- 手続き記憶： ユーザーが明示的に設定したワークフロー。
保存：
- SQL（Postgres）：構造化プロファイル、セッション、エピソード、手続き。
- ベクトルDB（pgvector）：エピソードのセマンティック検索。
操作：
- セッション開始時：意味記憶プロファイル + 直近3セッション + 未完了項目を自動で読み込みます。
- セッション中：トピックとの関連性に応じて、エピソード検索を開始します。
- セッション終了時：LLMで抽出し、学習した内容をユーザーが確認できるようにします。
- バックグラウンド：毎週統合します（関連するエピソードを結合し、古いものを減衰）。
ユーザーによる制御：
- 記憶されている内容を表示するメモリダッシュボード。
- 個別項目の編集と削除。
- 「直近1時間を忘れる」ボタン。
- アカウントの完全削除（すべてを消去）。
結果：
- 連続性：エージェントがセッション間でも「持続しているように感じる」とユーザーが報告。
- パーソナライズ：再度プロンプトで指示しなくても、応答スタイルがユーザーの好みに一致。
- プライバシー：明示的な制御によってユーザーに安心感を提供。
- コスト：メモリはセッション当たりのトークン使用量の約5～15%。十分な価値があります。
対処した失敗モード：
- 抽出時の検証によって、捏造された記憶を検出。
- 確信度のしきい値によって、誤った事実を検出。
- すべての保存・検索箇所でプライバシーを強制。
- 減衰と統合によって肥大化を管理。
これは本番レベルのメモリシステムです。簡単ではありませんが、目的に集中したチームなら十分に実現できます。
専用ツール
Memory as a Serviceの選択肢について補足します。
Mem0。 オープンソースで、適切に設計されています。上記のパターンの多くを扱います。ゼロから構築したくない場合は検討する価値があります。
Letta（MemGPT）。 LLM自身がツール呼び出しを通じてメモリを管理する、異なるパラダイムです。強力ですが、より複雑です。
Zep。 ホステッド型のメモリレイヤーです。簡単に統合できます。
Cognee。 比較的新しく、知識グラフを基盤とするメモリです。
これらのツールは構築時間を短縮します。一方で依存関係が増え、カスタマイズに制約が生じます。成熟した本番システムではメモリを自社構築することが合理的な場合が多く、試作や小規模チームではツールの利用が妥当です。
まとめ
長期メモリによって、エージェントは健忘的ではなく、知的で連続した存在に感じられます。同時に、適切な実装が特に難しい領域の一つでもあります。
アーキテクチャは階層化されています。
- 作業記憶（コンテキスト内）。
- セッションメモリ（直近のセッション）。
- エピソード記憶（具体的な出来事）。
- 意味記憶（安定した事実）。
- 手続き記憶（好みとワークフロー）。
各階層には、それぞれの保存、検索、減衰ロジックがあります。すべての階層が、時間をまたいでエージェントを役立つものにします。
重要なパターンは次のとおりです。
- 保守的な抽出（事実を捏造しない）。
- 確信度に基づく学習（何気ない発言から学習しない）。
- 能動的な忘却（減衰と刈り込み）。
- ユーザーによる制御（透明性と編集機能）。
- プライバシーの強制（すべての階層で実施）。
適切に実装されたメモリは、AIを「会話のたびに出会う初対面の相手」から「連続性のある有用なパートナー」へ変えます。それが、ツールとしてのAIと同僚としてのAIの違いです。
日、週、月をまたいで共に使い続けるエージェントにとって、メモリは任意の機能ではありません。基盤となるものです。必要な階層と規律を備え、意図的に構築してください。
