永続コンテキストストア（エイゾクコンテキストストア）
LLMエージェントがセッション間で状態・嗜好・学習結果を永続的に保存し、次回の対話やタスクで自動的に復元する仕組み。MemGPT/Letta、Claude Projects、ChatGPT Memory等で実装され、パーソナライゼーションと継続的学習を実現する。
永続コンテキストストアとは
永続コンテキストストア（Persistent Context Store）は、LLMエージェントのセッション間で会話状態・ユーザー嗜好・タスク進捗・学習済み知識を永続的に保存し、新しいセッション開始時に自動的に復元するシステムである。従来のLLMは各セッションが完全に独立しており、「先週話した内容」を覚えていないという根本的な制約があった。
2024年にOpenAIがChatGPT Memoryを、AnthropicがClaude ProjectsのMemory機能を導入し、商用LLMでの永続コンテキストが一般化した。オープンソースではMemGPT（現Letta）が先駆的な実装を提供し、2026年現在ではLetta v0.6がPostgreSQLベースの永続化を標準装備している。
永続化の対象データ
| データ種別 | 説明 | 保存形式 | 更新頻度 | 例 |
|---|---|---|---|---|
| ユーザープロファイル | 名前・職業・専門分野・嗜好 | JSON/YAML | セッション毎 | 「データサイエンティスト、Python主力」 |
| 対話サマリー | 過去セッションの要約 | テキスト | セッション終了時 | 「DBマイグレーションについて相談」 |
| タスク状態 | 進行中タスクの進捗 | 構造化JSON | リアルタイム | 「Step 3/7完了、残り4ステップ」 |
| 学習済みパターン | エージェントが学んだルール | key-value | 明示的teach時 | 「このプロジェクトではBunを使用」 |
| フィードバック履歴 | ユーザーからの修正指示 | テキスト+タグ | 修正発生時 | 「コミットメッセージは日本語で」 |
| ツール設定 | 使用するAPIキー・エンドポイント | 暗号化JSON | 初回設定時 | 「Meilisearch: localhost:7700」 |
主要実装の比較
商用サービス
| サービス | 永続化方式 | 容量制限 | 自動/手動 | ユーザー制御 |
|---|---|---|---|---|
| ChatGPT Memory | サーバーサイドKV | 制限なし（実質数百件） | 自動+手動 | 記憶の閲覧・削除可 |
| Claude Projects | プロジェクト単位ファイル | 200Kトークン/プロジェクト | 手動（Knowledge） | ファイル管理可 |
| Claude Code Memory | ローカルファイル | 無制限 | 自動+手動 | MEMORY.md管理 |
| Gemini Memory | Googleアカウント連携 | 非公開 | 自動 | 設定で無効化可 |
| GitHub Copilot | .github/copilot-instructions.md | リポジトリ単位 | 手動 | ファイル編集可 |
オープンソース
| フレームワーク | 永続化バックエンド | 記憶管理 | セッション復元 | 成熟度 |
|---|---|---|---|---|
| Letta v0.6 | PostgreSQL | 自動ページング | 自動 | 本番利用可 |
| LangChain v0.3 | Redis/SQL/ファイル | 手動設定 | 手動実装 | 安定 |
| AutoGen v0.4 | SQLite | TeachableAgent | 手動ロード | 実験的 |
| CrewAI v0.80 | ファイル/DB | タスク間共有 | 自動 | 安定 |
| Haystack v2.8 | DocumentStore | パイプライン組込 | 手動 | 安定 |
Letta（旧MemGPT）の永続化アーキテクチャ
Lettaは最も成熟した永続コンテキストストア実装である。
コア概念
- Agent State: エージェントの全状態をPostgreSQLに永続化（人格設定、記憶、ツール設定）
- Core Memory: 常にコンテキストに含まれる重要情報（ユーザープロファイル、エージェント人格）
- Archival Memory: ベクトル検索可能な大容量記憶ストア（過去の全対話・学習結果）
- Recall Memory: 直近の対話履歴（FIFOバッファ、設定可能なウィンドウサイズ）
データフロー
セッション開始
→ PostgreSQLからAgent State復元
→ Core Memoryをコンテキストにロード
→ Recall Memoryから直近対話をロード
→ タスク実行中にArchival Memoryを検索
→ セッション終了時にAgent Stateを保存
APIエンドポイント例
POST /v1/agents # エージェント作成
GET /v1/agents/{id}/memory # 記憶の取得
POST /v1/agents/{id}/memory # 記憶の更新
POST /v1/agents/{id}/archival # アーカイブ記憶の追加
GET /v1/agents/{id}/archival # アーカイブ記憶の検索
Claude Code Memoryの実装パターン
Claude Codeは .claude/projects/<dir>/memory/ にMarkdownファイルとして記憶を永続化する独自の設計を採用している。
| 記憶タイプ | ファイル名規約 | 用途 |
|---|---|---|
| user | user_*.md | ユーザーの役割・専門性・嗜好 |
| feedback | feedback_*.md | 行動修正指示・確認済みアプローチ |
| project | project_*.md | プロジェクト固有の状態・進捗 |
| reference | reference_*.md | 外部リソースへのポインタ |
この設計の特徴:
- ファイルベース: DB不要、gitで履歴管理可能
- MEMORY.md索引: 全記憶ファイルへのポインタを1ファイルに集約
- 自然言語記述: 構造化データではなくMarkdownテキストで記述
- セッション横断: 新セッション開始時にMEMORY.mdを自動読み込み
永続コンテキストの設計パターン
1. Append-Only Log + Compaction
全イベントを追記し、定期的にLLMで要約・圧縮。
- 利点: データ損失リスクが低い、監査証跡として機能
- コスト: ストレージ線形増加、圧縮処理のLLMコスト
- 適用: コンプライアンス要件のある業務システム
2. Key-Value Store with TTL
記憶をkey-valueペアで管理し、TTL（有効期限）で自動削除。
- 利点: シンプル、ストレージ制御が容易
- コスト: 重要な記憶も期限切れで消失するリスク
- 適用: チャットボットのセッション管理
3. Semantic Memory Graph
記憶をノード、記憶間の関係をエッジとしてグラフ構造で管理。
- 利点: 関連記憶の連鎖的発見、推論パスの可視化
- コスト: グラフDBの運用コスト、スキーマ設計の複雑さ
- 適用: 知識管理、研究支援エージェント
4. Tiered Storage（階層ストレージ）
アクセス頻度に応じてHot/Warm/Coldの3層に分離。
- Hot: Redis/インメモリ（直近7日・高頻度アクセス）
- Warm: PostgreSQL/SSD（30日以内・中頻度）
- Cold: S3/GCS（30日超・低頻度・圧縮保存）
プライバシーとセキュリティ
永続コンテキストには個人情報や機密データが含まれるため、以下の対策が必須。
| リスク | 対策 | 実装例 |
|---|---|---|
| PII漏洩 | 書き込み時にPII検出・マスキング | Presidio / spaCy NER |
| 不正アクセス | 暗号化 at rest + in transit | AES-256-GCM / TLS 1.3 |
| データ保持超過 | GDPR/CCPA準拠の保持期限設定 | TTL + 定期パージジョブ |
| 記憶の改ざん | 書き込み監査ログ | PostgreSQL WAL / 変更履歴テーブル |
| クロスユーザー汚染 | テナント分離 | Row-Level Security / 別DB |
よくある質問（FAQ）
Q1: 永続コンテキストとファインチューニングの違いは何ですか？ A: ファインチューニングはモデルの重みを更新して知識を内蔵させるのに対し、永続コンテキストはモデルの重みは変えず、外部ストアに情報を保存してプロンプト経由で注入する。永続コンテキストは即座に更新・削除が可能だが、ファインチューニングは再学習が必要。コスト面では永続コンテキストが圧倒的に安価（ストレージ費用のみ vs 学習コスト$100〜$10,000）。
Q2: どのくらいの記憶を保持すべきですか？ A: 用途による。パーソナルアシスタントでは100〜500件の記憶で十分な個人化が可能。業務エージェントではタスクログとして10,000件以上を保持するケースもある。重要なのは「全部保存」ではなく「重要な記憶を選択的に保持」する設計。Lettaのarchival memoryは100万件以上を処理可能。
Q3: ChatGPT MemoryとClaude Code Memoryの設計思想の違いは？ A: ChatGPT Memoryはサーバーサイドで自動的に記憶を抽出・保存する「暗黙的記憶」アプローチ。一方、Claude Code Memoryはユーザーとエージェントが協調してMarkdownファイルに記録する「明示的記憶」アプローチ。後者はgitで管理可能で透明性が高いが、記憶の品質はエージェントの判断精度に依存する。
まとめ
- 永続コンテキストストアはセッション間で状態を保存し、パーソナライゼーションを実現
- Lettaが最も成熟した実装、Claude Code Memoryはファイルベースの独自設計
- Append-Only Log、Key-Value、Semantic Graph、Tiered Storageの4パターン
- プライバシー対策（PII検出、暗号化、保持期限）は必須要件
- ファインチューニングよりも低コスト・即時更新が可能な知識管理手法