セッションをまたぐ永続化がないエージェントは、毎回、与えられたコンテキストから処理を始めます。永続化は同じ説明の繰り返しを減らせますが、プライバシー、正確性、分離、削除に関する義務も生じます。
これがメモリの課題です。コンテキストウィンドウが扱うのは現在の会話です。セッション、日、月をまたぐ長期記憶には、独自のアーキテクチャが必要です。しかも、見た目以上に難しくなります。
この記事は、テスト対象となる参照設計を示すものであり、認定された実装ではありません。プロダクトチームは、アクセス制御、修正、保持、削除、復旧、検索品質を、自社のスタックで検証する必要があります。
「メモリ」の意味
単純化すると、メモリとは「モデルが会話をまたいで物事を覚えていること」です。実際はもっと微妙です。認知科学は記憶の種類を区別しており、AIエージェントのメモリも同様の区別が役に立ちます。
作業記憶。 現在の会話です。コンテキストウィンドウ内に保持され、永続化しない限り会話の終了時に失われます。
エピソード記憶。 過去の具体的な出来事です。「先週の火曜日にXについて話し合った」「3か月前にYを決めた」などです。
意味記憶。 一般的な事実です。「あなたの名前はAliceです」「簡潔な回答を好みます」「会社はTallinnにあります」などです。
手続き記憶。 物事の進め方です。「ユーザーが会議を依頼したら、このテンプレートを使う」「顧客がティアXのときは、プロセスYに従う」などです。
記憶の種類によって役割は異なります。プロダクトとして正当化でき、運用できるレイヤーだけを使ってください。多く保存すれば自動的によくなるわけではありません。
メモリが果たすべきこと
アーキテクチャの前に、目標を確認します。
継続性。 エージェントは前回の続きから再開します。セッションごとに自己紹介をやり直す必要はありません。
パーソナライズ。 エージェントは求められなくても好みを適用します。あなたの文体で書き、あなたのツールを使い、あなたのチームに言及します。
コンテキストの保持。 過去の会話での決定が、現在の会話に反映されます。「先月、Xと決めた」は覚えている必要があります。
確認済みの好みの再利用。 明示された、または検証済みの好みを、有効な適用範囲内で再適用できます。繰り返されたというだけで、ツール、言語、振る舞いを既定値にしてよいことにはなりません。
プライバシーと忘却。 何を覚え、何を覚えず、何を削除するかです。ユーザーの信頼と法令遵守の両方のためです。
これらの目標は衝突し得ます。継続性は選択的な永続化で向上することがありますが、プライバシーと正確性は最小化、目的制限、修正、削除を重視します。アーキテクチャは、このトレードオフを明示しなければなりません。
アーキテクチャ
典型的な階層型アーキテクチャです。
┌─────────────────────────────────────┐
│ 作業記憶（コンテキスト内） │ 現在の会話
├─────────────────────────────────────┤
│ セッション記憶（直近） │ 直近N件の会話
├─────────────────────────────────────┤
│ エピソード記憶（長期） │ 過去の具体的な出来事
├─────────────────────────────────────┤
│ 意味記憶（事実） │ 安定したユーザーの事実
├─────────────────────────────────────┤
│ 手続き記憶（好み） │ このユーザー向けの振る舞い方
└─────────────────────────────────────┘
各レイヤーには、保存、検索、アクセス、出所、修正、保持、削除の振る舞いを明示する必要があります。複数の論理レイヤーが、同じ物理ストアを共有しても構いません。
順に見ていきます。
レイヤー1：作業記憶
すでにコンテキストエンジニアリングで扱っています。コンテキスト内の現在の会話です。複数ターンの会話では、直近のターンは原文のまま、古いターンは要約する階層型コンテキストを使います。
長期記憶への引き渡しは、明示的なチェックポイント、確実に記録されるイベント、またはセッション終了時に行う場合があります。セッションは突然終わることがあるため、承認済みの候補だけを永続化し、書き込み状態を観測できるようにしてください。セッション終了フックが必ず動くと仮定してはいけません。
レイヤー2：セッション記憶
直近セッションの要約は、プロダクトに正当な目的がある場合に、詳細を限定して保持できます。直近10件の会話などの件数は、例示的なポリシー入力であり、既定値ではありません。
実装：セッションごとに要約を作り、タイムスタンプとトピックとともに保存します。ユーザーが戻ってきたとき、エージェントは直近の動きをすぐ参照できます。
{
"session_id": "abc-123",
"user_id": "alice",
"started": "2026-05-14T10:30:00Z",
"ended": "2026-05-14T10:45:00Z",
"topic": "Drafting proposal for Acme Corp",
"summary": "Drafted v1 of the Acme proposal. Decided to lead with the cost-savings angle. Alice will review and send Friday.",
"facts_learned": ["Acme is a current customer", "Alice's deadline is Friday"],
"open_items": ["Alice to review v1 by Thursday"]
}
新しいセッションでは、検索品質、関連性、トークン予算、プライバシーのテストを経たうえで、直近要約のうち認可された部分集合を読み込んでも構いません。既定で、すべてのコンテキストに固定件数を自動読み込みしないでください。
これはセッションをまたぐメモリとしては比較的単純な形ですが、それでも分離、出所、修正、ライフサイクル、検索のテストが必要です。
レイヤー3：エピソード記憶
より長く覚えておく価値のある、過去の具体的な出来事です。決定、マイルストーン、重要な会話です。
注目に値する場合にセッションから抽出し、豊富なメタデータとともに保存します。
{
"event_id": "ev-456",
"user_id": "alice",
"date": "2026-04-22",
"type": "decision",
"description": "Alice decided to migrate from Postgres to ClickHouse for the analytics workload, citing query performance.",
"context_summary": "After 3 weeks of evaluation including performance tests and cost analysis.",
"related_topics": ["infrastructure", "analytics", "database"],
"importance": "high"
}
検索：現在の会話に関連する場合、エージェントは関連するエピソードを取得します。セマンティック検索（現在のクエリを埋め込み、一致するエピソードを探す）、トピック照合、または時間に基づくクエリ（「先月何が起きたか？」）です。
課題は、覚えておく価値のあるエピソードの基準です。候補となる一つのパターンは、承認済みチェックポイントで、モデルが決定、約束、マイルストーンを提案し、出典範囲と確認ルールを付けることです。モデルが付けた重要度ラベルは、個人データを永続化する権限にはなりません。
レイヤー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": "always offer 3 time slots, never schedule before 9am",
"code_style": "Python, type hints required, dataclasses over dicts",
"tone_for_clients": "warm, direct, with explicit next steps",
"approval_process": "all customer-facing communications need Alice's review before sending"
}
}
関連するタスクが起きたときに、エージェントが従うパターンです。
更新は、明示的な指示または繰り返しのパターンから始まることがあります。繰り返された振る舞いは確認の依頼をきっかけにできますが、黙って永続的な手続きを作るべきではありません。
ストレージの選択
メモリはどこに置くのでしょうか。
SQLデータベース。 信頼でき、クエリしやすく、よく理解されています。メモリの種類ごとにテーブルを用意し、結合で検索します。構造化されたアクセスパターンに適しています。
ベクトルデータベース。 エピソードのセマンティック検索（「このトピックに関連するメモリを探す」）向けです。エピソードを埋め込み、類似度で検索します。
併用。 構造化アクセスとセマンティックアクセスの両方が必要な場合、SQLにベクトルインデックスを加える構成は候補の一つです。表現が二重になると同期と削除の義務が増えるため、より単純なストアと比較してベンチマークしてください。
専用のメモリツール。 Mem0、Letta（旧MemGPT）、Zepです。エージェント向けに作られたメモリレイヤーです。より高い抽象度が欲しい場合は検討する価値があります。
構造化アクセス、セマンティック検索、テナント分離、出所、修正、保持、削除、バックアップ、復旧のテストを満たす、最小のストアから始めてください。SQL、ベクトルインデックス、その両方、専用レイヤーのいずれでも適合し得ます。チームの既定構成だと決めつけず、運用と移行の負担を比較してください。
検索のパターン
エージェントは、どのようにメモリをコンテキストへ入れるのでしょうか。
パターン1：セッション開始時の自動読み込み
新しいセッションが始まったとき、次を自動で取得します。
- ユーザーの意味プロファイル。
- 直近N件のセッション要約。
- 未完了の約束やフォローアップ。
これが、ユーザーが現れたときにエージェントが持つベースラインのコンテキストです。
パターン2：クエリ駆動の検索
ユーザーのメッセージが過去のトピックを示唆したら、関連するエピソードを検索します。
例：ユーザーが「データベースの議論の結論は何だったか？」と尋ねます。エージェントはエピソードを「データベース」で検索し、該当するものを取得します。
実装：ユーザーのメッセージを埋め込み、類似するエピソードを見つけ、コンテキストに含めます。
パターン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第17条は、例外付きの消去権を定めています。法務担当者は、この規定と他の適用規則を、プロダクト、管轄、データ上の役割に対応付けるべきです。
- ユーザーのアカウント削除要求 → 対象となるストア全体で、確認済みの削除/制限ワークフローを実行し、例外またはバックアップ失効を開示する。
- 要求単位のデータ削除 → 対象レコードと派生データを特定し、結果を検証する。
- 保持期限 → 承認済みのスケジュールに従い、対象レコードを自動的に失効させる。
これらは最初から組み込む必要があります。後付けは苦痛です。
プライバシーに関する考慮事項
メモリは機微です。ストアにはユーザーに関する情報が大量にあります。考慮事項は次のとおりです。
保存時の暗号化
メモリデータを暗号化します。標準的な対策です。
アクセス制御
ユーザーのメモリを見られるのは誰でしょうか。本人だけか、システムだけか、一定の条件下のサポート担当者か。明確に定め、アクセスを監査してください。
PIIの取り扱い
個人を識別できる情報（実名、住所、金融情報）にはタグを付け、慎重に扱う必要があります。特別なアクセス制御と、特別な削除手順が必要です。
ユーザーの可視性
プロダクトと適用される権利が求める場合は、ユーザーがメモリレコードを閲覧、修正、適用範囲の指定、削除できる手段を提供してください。メモリダッシュボードは実装の一つです。理解しやすさをテストし、他の機微データ画面と同様に保護してください。
エージェントがあなたについて記憶している内容：
プロフィール：
- 名前：Alice Tamm
- 役職：Acme CorpのCEO
- コミュニケーションスタイル：簡潔、直接的
最近のセッション：
- 2026-05-14: Acme向けの提案書を作成
- 2026-05-12: Q1の結果を確認
- ...
好み：
- 簡潔な回答を好む
- Notion、Slack、Linearを使用する
[Edit] [Delete specific items] [Delete all]
この透明性が信頼を築きます。ユーザーから見えない不透明なメモリは、信頼を築きません。
コンテキストをまたぐ共有
ユーザーに複数の「モード」（仕事用エージェント、個人用エージェント）がある場合、メモリを分けたいことがあります。求められない限り、モード間で自動共有しないでください。
よくある失敗モード
いくつかのパターンです。
失敗1：ハルシネーションによる記憶
エージェントが、起きていないことを覚えていると主張します。「先週、Xで合意しました」——しかしXは一度も議論されていません。
原因：抽出または検索の際に、LLMがもっともらしい記憶を「補完」してしまうことです。
対策：メモリ操作を実際の会話データに根拠付けます。LLMは抽出し、検証は実際のトランスクリプトと照合します。ハルシネーションによる事実にはフラグを付けてください。
失敗2：誤った事実の学習
エージェントが、誤った事実を自信を持って述べます。「Pythonを好むと言っていました」と述べますが、実際には職場でPythonを使わざるを得ないと話しただけです。
原因：抽出時の誤解釈です。
対策：確信度のしきい値です。明示的、反復的、または確認済みの発言だけから学習します。ユーザーが訂正できるようにします。
失敗3：プライバシー漏えい
あるユーザーのメモリが、別のユーザーの会話に現れます。壊滅的です。
原因：ユーザースコープ制御のロジックの不具合です。
対策：保存層と検索層でユーザースコープを強制します。監査します。フィルタリングをLLMに任せてはいけません。
失敗4：メモリの肥大化
一年後には、ユーザーあたりのメモリが数メガバイトになります。検索は遅くなり、コストは増えます。
原因：減衰もプルーニングもないことです。
対策：積極的な減衰です。ほとんどのメモリは、数か月後に検索優先度が下がり、実質的に取得されなくなります。定期的にコンパクションします。
失敗5：古くなった事実
ユーザーは6か月前に役職を変えました。エージェントはまだ以前の役職を参照します。
原因：上書きされたときに事実が更新されないことです。
対策：矛盾を検出し、出所と発効日を保持し、権威ある値が不明なときは確認を求めます。遅延した入力、引用、悪意ある入力に対して、「最新のものが勝つ」は安全ではありません。
失敗6：混乱を招く統合
バックグラウンドのメモリ統合は、ときどき情報を失う形でメモリを書き換えることがあります。
原因：重要な事実を残さずに積極的に要約することです。
対策：統合は事実を明示的に保持しなければなりません。実際のメモリのトランスクリプトで統合をテストしてください。
実装スケッチ：メモリ付きパーソナルアシスタント
個人ユーザー向けのパーソナルAIアシスタントという、例示の参照設計です。
メモリレイヤー：
- 作業記憶： 現在の会話。
- セッション記憶： 要約形式の直近7件のセッション。
- エピソード記憶： セマンティック検索付きの、直近100件の注目すべき出来事。
- 意味記憶： ユーザープロファイル（名前、役職、好み、ツール）。
- 手続き記憶： ユーザーが明示的に設定したワークフロー。
ストレージ：
- SQL（Postgres）：構造化プロファイル、セッション、エピソード、手続き。
- ベクトルDB（pgvector）：エピソードのセマンティック検索。
運用：
- セッション開始：意味プロファイル、直近3件のセッション、未完了項目を自動読み込みする。
- セッション中：トピックの関連性で起動するエピソード検索。
- セッション終了：LLMによる抽出。ユーザーは学習内容を確認できる。
- バックグラウンド：週次の統合（関連エピソードを結合し、古くなったものを減衰させる）。
ユーザー制御：
- 何が記憶されているかを示すメモリダッシュボード。
- 個別項目の編集/削除。
- 「直近一時間を忘れる」ボタン。
- 対象範囲を検証し、例外を文書化し、バックアップ失効の振る舞いを備えた、アカウント全体の削除ワークフロー。
成功と呼ぶ前に必要な証拠：
- 固定した評価セットで、取得したメモリがある場合とない場合のタスク完了、
- 保存した事実と取得したメモリの適合率（矛盾処理を含む）、
- テナント間およびユーザー間の分離テスト、
- レコード、埋め込み、キャッシュ、エクスポート、ジョブ、バックアップ失効までの修正と削除の反映、
- 実際のトレースに基づくトークン、ストレージ、レイテンシー、運用コスト、
- 自信があると仮定するのではなく、ユーザーの理解度と制御のテスト。
対処した失敗モード：
- ハルシネーション記憶のケースを、抽出と検索のテストに含める。
- 確信度スコアは較正する。スコアだけでは事実にはならない。
- 認可は検索の前と、提示の前に再度強制する。
- 保持と統合のジョブには、監査ログ、障害処理、削除テストがある。
これは設計チェックリストであり、本番準備の証明ではありません。本番相当とするには、実装の証拠とセキュリティ/プライバシーのレビューが必要です。
専用ツール
メモリをサービスとして使う選択肢についての補足です。
Mem0。 オープンソースのメモリレイヤーです。現在のドキュメントとコードを、自社の永続化、分離、削除の要件に照らして評価してください。
Letta（MemGPT）。 ツール指向のメモリ設計です。現在のドキュメントと運用上の境界を確認してください。
Zep。 ホスト型のメモリおよびコンテキストサービスです。現在のドキュメント、データ境界、削除契約を検証してください。
Cognee。 ナレッジグラフ指向の選択肢です。採用前に、現在のドキュメントとリポジトリから成熟度と適合性を検証してください。
これらのツールは実装作業を減らせる一方、ベンダー、セキュリティ、移行、データライフサイクルの依存を増やす可能性があります。同じ受け入れテストで、内製設計と比較してください。
正当化できる最小限のメモリを構築する
長期記憶があることで、エージェントは健忘ではなく、セッションをまたいで継続できます。正しく実現するのが難しいものの一つでもあります。
アーキテクチャは階層型です。
- 作業記憶（コンテキスト内）。
- セッション記憶（直近のセッション）。
- エピソード記憶（具体的な出来事）。
- 意味記憶（安定した事実）。
- 手続き記憶（好みとワークフロー）。
各レイヤーには固有の保存、検索、減衰のロジックがあります。それぞれが、時間をまたいでエージェントを有用にすることに寄与します。
重要なパターンです。
- 控えめな抽出（事実をハルシネーションしない）。
- 確信度に基づく学習（何気ない発言から学習しない）。
- 能動的な忘却（減衰とプルーニング）。
- ユーザー制御（透明性と編集可能性）。
- プライバシーの強制（すべてのレイヤーで）。
評価とライフサイクルのテストに合格したとき、メモリは説明の繰り返しを減らし、確認済みの好みをセッション間で使えるようにできます。
セッションをまたぐ継続性が必要なエージェントでは、永続化は明示的なプロダクト上の選択です。出所、認可、ユーザー制御、検証済みの廃棄経路を備えた、正当化できる最小限のメモリを構築してください。
