論文解説: MemGPT — 仮想メモリ管理に着想を得たLLMエージェントの無制限セッション維持

論文概要（Abstract）

本記事は MemGPT: Towards LLMs as Operating Systems（Packer et al., 2023）の解説記事です。MemGPTは、オペレーティングシステムの仮想メモリ管理から着想を得て、LLMの固定長コンテキストウィンドウを超える長期ステートフルセッションを実現するシステムである。著者らは、LLMエージェントが自身のコンテキスト（「メインメモリ」）と外部ストレージ（「ディスク」）間でデータを明示的にページング管理する仕組みを提案し、複数セッションにまたがる対話の一貫性維持と長文ドキュメント分析において、従来のコンテキスト切り詰め手法を上回る性能を報告している。

この記事は Zenn記事: Bedrock AgentCore Runtimeで8時間連続セッションと状態永続化を実装するの深掘りです。

情報源

arXiv ID: 2310.08560
URL: https://arxiv.org/abs/2310.08560
著者: Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, Joseph E. Gonzalez
発表年: 2023年（初版）、2024年更新
分野: cs.AI, cs.CL, cs.LG

背景と動機（Background & Motivation）

LLMの固定長コンテキストウィンドウは、長時間の対話セッションや大規模ドキュメント分析において根本的な制約となる。GPT-4の8K/32Kトークン、Claude 3の200Kトークンのように、近年コンテキスト長は拡大傾向にあるが、長いコンテキストはレイテンシとコストの増大を伴う。

従来のアプローチには以下の問題があった:

コンテキスト切り詰め: 古い会話ターンを単純に削除するため、重要な文脈が失われる
要約ベース: 要約時に情報が不可逆的に圧縮され、詳細な事実の再現が困難
RAG（Retrieval-Augmented Generation）: 検索精度に依存し、関連情報の想起が不完全な場合がある

著者らは、この問題がOSにおける物理メモリの制約と本質的に同一であると指摘し、仮想メモリのページング機構をLLMのコンテキスト管理に応用するアプローチを提案した。

主要な貢献（Key Contributions）

貢献1: OSの仮想メモリ階層をLLMコンテキスト管理にマッピングする設計パラダイムの提案
貢献2: LLM自身がメモリ管理命令（APPEND, RETRIEVE, EVICT）を発行する自律的なページング機構の実装
貢献3: 複数セッションにまたがる長期対話と大規模ドキュメントQAにおける従来手法の性能上回りの実証

技術的詳細（Technical Details）

アーキテクチャ: メモリ階層

MemGPTのコアアイデアは、LLMのコンテキストウィンドウを「メインメモリ」、外部ストレージを「ディスク」とみなす2層メモリ階層である。

graph TB
    subgraph メインメモリ（コンテキストウィンドウ内）
        A[System Prompt<br/>固定]
        B[Working Context<br/>可変・ページング対象]
        C[FIFO Queue<br/>最近の会話ターン]
    end
    subgraph 外部ストレージ（ディスク相当）
        D[Recall Storage<br/>全会話履歴]
        E[Archival Storage<br/>長期記憶・ドキュメント]
    end
    B <-->|RETRIEVE / EVICT| D
    B <-->|RETRIEVE / EVICT| E
    C -->|溢れ| D

メインメモリの構成:

コンポーネント	役割	容量
System Prompt	タスク定義、ペルソナ設定	固定（変更不可）
Working Context	現在のタスクに必要な情報	可変（ページング対象）
FIFO Queue	最近の会話ターン	固定幅（溢れ分はRecall Storageに退避）

外部ストレージの構成:

ストレージ	役割	実装
Recall Storage	全会話履歴の保存	ベクトルDB（デフォルト: LanceDB）
Archival Storage	長期記憶、ドキュメントチャンク	ベクトルDB + テキストストア

メモリ管理命令

著者らは、LLMがFunction Calling機構を通じて以下のメモリ管理命令を発行すると報告している。

\[\text{action}_t = f_{\text{LLM}}(\text{context}_t, \text{tools})\]

ここで、

$\text{action}_t$: 時刻$t$におけるLLMの行動（メモリ操作またはユーザー応答）
$\text{context}_t$: 時刻$t$のメインメモリ内容
$\text{tools}$: 利用可能なメモリ管理ツール群

主要な命令:

命令	動作	OS仮想メモリの対応
`core_memory_append`	Working Contextに情報を追加	メモリ書き込み
`core_memory_replace`	Working Context内の情報を更新	メモリ書き換え
`conversation_search`	Recall Storageから会話履歴を検索	ページフォルト → ディスクI/O
`archival_memory_search`	Archival Storageから長期記憶を検索	ページフォルト → ディスクI/O
`archival_memory_insert`	Archival Storageに情報を保存	ディスクへのページアウト

ページフォルトの類推

OSの仮想メモリでは、必要なデータがメインメモリになければページフォルトが発生し、ディスクからロードされる。MemGPTでは、LLMが「必要な情報がWorking Contextにない」と判断した場合に、自律的にconversation_searchやarchival_memory_searchを呼び出す。

\[\text{ページフォルト率} = \frac{\text{検索命令の発行回数}}{\text{全命令の発行回数}}\]

著者らの実験では、ページフォルト率が高すぎるとターンあたりのレイテンシが増加し、低すぎると情報の想起漏れが発生するトレードオフが存在すると報告されている。

FIFO Queueのエビクション

メインメモリのFIFO Queueが容量上限に達すると、最も古い会話ターンが自動的にRecall Storageに退避される。この動作はOSにおけるFIFO/LRUページ置換アルゴリズムに対応する。

\[\text{FIFO Queue}: q = [m_{t-k}, m_{t-k+1}, \ldots, m_t]\]

新しいメッセージ$m_{t+1}$が到着し$

> k$となった場合:

\[q' = [m_{t-k+1}, \ldots, m_t, m_{t+1}], \quad m_{t-k} \rightarrow \text{Recall Storage}\]

実装のポイント（Implementation）

Function Calling対応LLMの要件

MemGPTはFunction Calling（Tool Use）対応のLLMを前提としている。著者らはGPT-4での実装を基本としているが、Function Callingをサポートする任意のLLMで動作すると述べている。

  
from letta import create_client

client = create_client()

agent = client.create_agent(
    name="long-session-agent",
    memory=ChatMemory(
        human="ユーザーの情報をここに記録",
        persona="アシスタントの性格定義"
    ),
    llm_config=LLMConfig(
        model="gpt-4",
        model_endpoint_type="openai"
    ),
    embedding_config=EmbeddingConfig(
        embedding_endpoint_type="openai",
        embedding_model="text-embedding-3-small"
    )
)

response = agent.send_message("前回の会議で決まった内容を教えて")

状態の永続化

著者らの報告によると、MemGPTのエージェント状態はJSON形式でディスクに永続化される。プロセス再起動後もREST API経由でセッションを再開でき、Working Context、Recall Storage、Archival Storageの全状態が復元される。

検索品質の依存性

Recall StorageとArchival Storageの検索にはベクトル類似度検索が使用される。著者らは、検索品質がEmbeddingモデルの選択に強く依存すると指摘している。不適切なEmbeddingモデルを使用すると、関連情報のページインが失敗し、LLMが不正確な応答を生成するリスクがある。

実験結果（Results）

マルチセッション対話の一貫性

著者らは、10ターン以上の長期対話タスクにおいて、以下のベースラインとの比較実験を報告している。

手法	対話一貫性スコア	情報想起率
固定長切り詰め	低い	早期ターンの情報をほぼ喪失
要約ベース	中程度	要約時に詳細が不可逆的に消失
RAGベース	中〜高	検索精度に依存
MemGPT	高い	明示的なページング管理で改善

著者らは、特に「以前の会話で言及された具体的な事実の再現」においてMemGPTが優位であったと報告している（論文Section 5.1）。ただし、定量的なスコアは評価タスクとLLMモデルに依存するため、汎化性には注意が必要である。

ドキュメントQA

著者らは、コンテキストウィンドウを超える長文ドキュメントに対するQAタスクでも評価を行い、MemGPTのArchival Storageによるチャンク検索が、単純なチャンク分割＋RAGよりも正確な回答を生成する傾向を報告している。

実運用への応用（Practical Applications）

AgentCore Runtimeとの関連

MemGPTのメモリ管理モデルとAgentCore RuntimeのSession Storageは、異なるレベルで同様の課題を解決している。

側面	MemGPT	AgentCore Session Storage
永続化対象	LLMコンテキスト（テキスト）	ファイルシステム状態
粒度	トークンレベル	ファイルレベル
管理主体	LLM自身（自律的ページング）	インフラ（マネージドサービス）
容量制限	ベクトルDBの容量	1GB / セッション
保持期間	無制限（ストレージ依存）	14日間

実務では、両者を組み合わせることでより堅牢なステートフルエージェントを構築できる。AgentCore RuntimeのSession Storageでファイルシステム状態（コード、依存パッケージ、設定ファイル）を永続化し、MemGPT的なメモリ管理で会話コンテキストの長期維持を行う構成である。

スケーリングの考慮事項

MemGPTのページング操作はLLM推論を伴うため、以下のスケーリング特性がある:

レイテンシ: ページフォルト1回あたり1回のLLM推論 + ベクトル検索のレイテンシが加算される
コスト: ページフォルト頻度に比例してLLM推論コストが増加する
同時セッション: 各エージェントが独立したメモリ階層を持つため、メモリ使用量はセッション数に比例する

まとめと今後の展望

MemGPTは、OSの仮想メモリモデルをLLMのコンテキスト管理に応用することで、固定長コンテキストウィンドウの制約を超えた長期ステートフルセッションを実現するシステムである。著者らは、複数セッションにまたがる対話一貫性と長文ドキュメントQAにおいて、従来の切り詰め・要約ベースの手法を上回る性能を報告している。

現在のMemGPTはLetta Frameworkとして活発に開発が継続されており（GitHub: cpacker/MemGPT、MITライセンス）、AgentCore Runtimeのような商用エージェント実行基盤と組み合わせた運用も検討に値する。ただし、メモリ管理の品質がLLMの推論精度とEmbeddingモデルの検索品質に依存する点は、本番環境導入時の重要な評価ポイントである。

参考文献

arXiv: https://arxiv.org/abs/2310.08560
Code: https://github.com/cpacker/MemGPT（MITライセンス）
Letta Framework: https://www.letta.com/
Related Papers: AIOS (arXiv:2401.16158), Infini-attention (arXiv:2404.07143), StreamingLLM (arXiv:2309.17453)
Related Zenn article: Bedrock AgentCore Runtimeで8時間連続セッションと状態永続化を実装する

📄 論文解説: MemGPT — 仮想メモリ管理に着想を得たLLMエージェントの無制限セッション維持

論文概要（Abstract）

情報源

背景と動機（Background & Motivation）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

アーキテクチャ: メモリ階層

メモリ管理命令

ページフォルトの類推

FIFO Queueのエビクション

実装のポイント（Implementation）

Function Calling対応LLMの要件

状態の永続化

検索品質の依存性

実験結果（Results）

マルチセッション対話の一貫性

ドキュメントQA

実運用への応用（Practical Applications）

AgentCore Runtimeとの関連

スケーリングの考慮事項

関連研究（Related Work）

まとめと今後の展望

参考文献

📄 論文解説: MemGPT — 仮想メモリ管理に着想を得たLLMエージェントの無制限セッション維持

論文概要（Abstract）

情報源

背景と動機（Background & Motivation）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

アーキテクチャ: メモリ階層

メモリ管理命令

ページフォルトの類推

FIFO Queueのエビクション

実装のポイント（Implementation）

Function Calling対応LLMの要件

状態の永続化

検索品質の依存性

実験結果（Results）

マルチセッション対話の一貫性

ドキュメントQA

実運用への応用（Practical Applications）

AgentCore Runtimeとの関連

スケーリングの考慮事項

関連研究（Related Work）

まとめと今後の展望

参考文献

関連記事

📄 論文解説: A Survey of AI Agent Protocols — MCP・A2Aを含むエージェントプロトコルの体系的分類

📄 論文解説: AgentBench - LLMエージェント評価の決定版ベンチマーク

✍️ RAG完全サーベイ: 基礎から最先端まで進化の全体像