セッション記憶と永続記憶：アーキテクチャガイド
AIシステムを設計している場合、問題は記憶が必要かどうかではなく、どの種類の記憶が必要かです。セッション記憶と永続記憶は異なる目的を持ち、異なるレイヤーで動作し、異なるインフラストラクチャを必要とします。このページでは、両者を明確に説明します。
記憶の問題
多くのAIアプリケーションは、現在の会話のコンテキストウィンドウであるセッション記憶のみで構築されています。これは一回限りのクエリには機能しますが、ユーザーが継続性を期待して戻ってきたとき、エージェントが長いタスクを再開するとき、またはシステムが以前の実行からの教訓を適用する必要があるときには失敗します。セッション記憶が提供するものと、実際のプロダクションアプリケーションが必要とするものとのギャップが、永続記憶の存在する場所です。
MemoryLakeの異なる点
セッションを超えて無期限に存続する永続記憶
MemoryLakeは記憶をモデルの外部に保存し、必要に応じて取得します。期限はなく、コンテキストウィンドウの制限もなく、セッションが終了してもリセットされません。記憶は日々、月々、年々蓄積されます。
異なる永続性ニーズのための型付きカテゴリ
すべての永続記憶が同じではありません。MemoryLakeは、バックグラウンド（静的アイデンティティ）、ファクト（バージョン管理された主張）、イベント（タイムライン）、会話（セッション履歴）、リフレクション（行動パターン）、スキル（再利用可能なワークフロー）を区別します。各タイプには適切なストレージセマンティクスがあります。
94.03%の精度でミリ秒単位の取得
永続記憶は、適切な情報を適切なタイミングで取得する場合にのみ有用です。MemoryLakeの#1 LoCoMoベンチマーク結果は、システムが最近の記憶だけでなく、関連する記憶を確実に引き出すことを意味します。
永続無料 · クレジットカード不要
動作の仕組み
- 接続 — REST API、Python SDK、またはMCPを介してMemoryLakeをAIアプリケーションに統合します。セッション記憶は、モデルのコンテキストウィンドウ内で常に動作し続けます。
- 構造 — セッション終了時（または重要なイベントのためにセッション中）、関連情報を適切なMemoryLake記憶タイプに書き込みます。セッションは終了しますが、記憶は終了しません。
- 再利用 — 次のセッション開始時に、関連する永続記憶を取得し、選択的にコンテキストに注入します。モデルは空白の状態ではなく、蓄積された知識から始まります。
セッション記憶と永続記憶
| Characteristic | Session Memory | Persistent Memory (MemoryLake) |
|---|---|---|
| Lifespan | Ends when the session closes | Survives indefinitely across sessions |
| Storage location | Inside the model's context window | External memory layer, retrieved on demand |
| Capacity | Limited by context window token count | Scales to 1B+ complex documents in production |
| Cross-session access | Not available | Available to any authorized session or agent |
| Structure | Unstructured text in context | Six typed categories with defined semantics |
| Conflict detection | None — latest input wins | Automatic conflict detection and versioning for Facts |
| Retrieval accuracy | N/A (all context is present) | 94.03% LoCoMo benchmark accuracy |
| Cost at scale | Grows with context length per call | Retrieved selectively; context stays lean |
| Compliance and audit | None by default | Versioned, source-attributed, GDPR/SOC 2 compliant |
対象
この比較は、ユーザー向け製品、内部ツール、またはエージェントシステムのAI記憶インフラストラクチャを設計する際の開発者やアーキテクトにとって有用です。同じユーザーまたは同じエージェントが複数のセッションにわたって関与する場合、永続記憶はあなたのアーキテクチャに必要です。
このユースケースを自分のアカウントで試す
Brindlewood Payments のコーディングエージェントは、セッションの直近 6 ステップだけをプロンプトに残し、それ以外は MemoryRouter が MemoryLake から付け加えます。過去 6 回のセッションでチームの規約が決まっており、今朝、開発者は最初の 3 つのメッセージでそのうち 3 つ（データベースのポート、テストコマンド、レビュアー）を変更し、その後エージェントは 22 ステップの作業を素早く進めます。同じセッションを 3 通りで実行します：今日のセッションをセッション終了時にメモリへ書く、各ステップをその場で書く、各ステップをその場で書き MemoryLake が保持してからウィンドウの外に出す。7 回の実行で、終了時に保存する方式は、変更がウィンドウから外れた後の 28 問すべてに古い値（ポート 5433、`make test-ledger`、以前のレビュアー）で答えました。その場で書く方式は抽出がウィンドウに間に合うかどうかで 20/28 正解、メモリが保持するまでステップを残す方式は 28/28 正解で、プロンプトトークンは最大 1.75 倍でした。
見られるもの
- 3 つの方式がそれぞれ専用のプロジェクトと
boundaryを持ちます。過去 6 回のセッションを会話として登録し、各メモリの合意済みの値を最初に確認 - 各ステップはバックグラウンドで
conv msg appendにより追加され、memorylake router chat --boundaryが 8 つのチェックポイントに回答。正解 / 古い値 / 記録なし / 作り話 で採点 - チェックポイントごとに
fact list --queryでその時点の各メモリの値を表示し、各変更がいつ言われ、いつウィンドウから外れ、いつメモリに入ったかを記録 - 修正方法は、
conv cook-statusが会話の書き込み完了を報告するまでステップをプロンプトに残すこと。factsとask "<質問>"で終了後のメモリを確認でき、ローカル Web UI もあります
必要なもの: MemoryLake の API キー · memorylake CLI · Python 3.9 以上
実行する
git clone https://github.com/memorylake-ai/memorylake-usecases.git cd memorylake-usecases/session-gap-memory export MEMORYLAKE_API_KEY=sk-… python3 demo.py # or: python3 web/server.py
動作を見る · 実際の録画、未編集
関連するユースケース
よくある質問
セッション記憶は十分ですか？
セッション記憶は十分ですか？
単発のアプリケーション — 一回限りのクエリツール、ドキュメント要約ツール、コードフォーマッター — にはセッション記憶が十分です。継続性、パーソナライズ、または蓄積された知識が重要なアプリケーションでは、永続記憶が必要です。
MemoryLakeはコンテキストウィンドウを置き換えられますか？
MemoryLakeはコンテキストウィンドウを置き換えられますか？
いいえ — そして、そうすべきではありません。セッション記憶（コンテキストウィンドウ）と永続記憶は一緒に機能します。コンテキストウィンドウは即座に関連するものを保持し、MemoryLakeはすべての以前のセッションで学んだものを保持し、適切な部分を選択的に引き出します。
MemoryLakeは永続記憶から何を引き出すかをどのように決定しますか？
MemoryLakeは永続記憶から何を引き出すかをどのように決定しますか？
記憶タイプとセマンティックインテントでMemoryLakeにクエリを送ります。取得レイヤーは、現在のセッションコンテキストに対する関連性に基づいて結果をランク付けし、最も適用可能な記憶アイテムを返します — 保存されているすべてのもののダンプではありません。