0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@0h-n0

Titans・Mem0・SimpleMem で理解するLLM長期記憶の3パラダイムと実装戦略

0
Last updated at Posted at 2026-04-04

Titans・Mem0・SimpleMemで理解するLLM長期記憶の3パラダイムと実装戦略

この記事でわかること

  • LLMエージェントの長期記憶が2025-2026年にどう進化したか、3つのパラダイム（フラット検索型・構造化型・ポリシー管理型）の全体像
  • Google Titans+MIRASの「驚き度メトリック」によるテスト時メモリ更新の仕組み
  • Mem0・SimpleMem・A-MEM・LangMemなど主要フレームワークの技術的差異と選定基準
  • 実際にMem0とLangMemを使ってPythonで長期記憶を組み込む実装パターン
  • KVキャッシュ圧縮（KVzip）やMemOSなど周辺技術の位置づけと使い分け

対象読者

  • 想定読者: LLMを活用したアプリケーションやエージェントを開発しているMLエンジニア
  • 必要な前提知識:
    • Transformer アーキテクチャの基本（Attention、KVキャッシュ）
    • RAG（Retrieval-Augmented Generation）の概念
    • Python での LLM API 呼び出し経験

結論・成果

LLMの長期記憶は2025-2026年に急速に成熟し、単なるRAGの延長ではなく独立した研究・実装分野として確立されました。論文のベンチマーク（LoCoMo）では、SimpleMem が推論トークンを30倍削減しながら F1 を 26.4%向上させたと報告されています。Mem0 は OpenAI Memory と比較して p95 レイテンシ 91%削減・トークンコスト 90%以上削減を達成したとされています。Google の Titans は 200万トークンを超えるコンテキストで GPT-4 を上回る BABILong ベンチマーク結果を報告しています。

一方で、これらの手法にはそれぞれ明確なトレードオフがあります。フラット検索型はマルチホップ推論に弱く、構造化型はメンテナンスコストが高く、ポリシー管理型は学習に大量のデータが必要です。本記事では、各パラダイムの特性を整理し、ユースケース別の選定指針を提示します。

LLMの長期記憶はなぜ必要か

LLM はデフォルトではステートレスです。会話が終われば前回の内容は忘れ、新しいセッションでは白紙の状態から始まります。コンテキストウィンドウが 128K〜200K トークンに拡大しても、数日にわたる対話履歴やユーザーの好みを保持するには不十分です。

ICLR 2026 では MemAgents ワークショップ が採択され、エージェントの記憶層を専門に議論する場が設けられました。論文 Memory in the Age of AI Agents では「メモリはファウンデーションモデルベースのエージェントのコア能力として台頭した」と指摘されています。長期記憶はもはやオプション機能ではなく、エージェント設計の中心的な課題です。

なぜ単純なRAGでは不十分か

RAG は「質問に関連する文書を検索してプロンプトに注入する」仕組みですが、以下の制約があります。

制約 具体例
時系列の欠落 「先週言ったこと」を正しく取得できない
関係性の喪失 エンティティ間のリンクが検索ヒューリスティクスに依存
矛盾の未解決 古い情報と新しい情報が共存し、どちらを優先すべきか不明
スケーラビリティ 会話ログが増えるほど検索精度が低下

これらの制約を克服するために、2025-2026 年にかけて多様な長期記憶アプローチが提案されました。

長期記憶の3パラダイムを整理する

論文 Choosing How to Remember: Adaptive Memory Structures for LLM Agents（2026年2月）は、LLM エージェントの長期記憶を3つのパラダイムに分類しています。

パラダイム1: フラット検索型

概要: 会話から抽出した事実・要約をベクトルストアに格納し、類似度検索で取得する最もシンプルなアプローチです。

代表的なフレームワーク: Mem0、LightMem、MemoryBank

強み:

  • 実装が容易で、既存の RAG インフラを流用可能
  • 抽出・更新が高速
  • パーソナライゼーションに適している

なぜこのアプローチを選ぶか:

  • プロダクション環境で即座に導入したい場合に適しています。Mem0 は SOC 2 / HIPAA 準拠で、AWS 上での運用実績もあります。
  • 単純な事実の記憶（ユーザーの好み、過去の設定）で十分なケースに向いています。

制約条件:

フラット検索型は「マルチホップ推論」や「クロスコンテキスト統合」が必要なタスクではパフォーマンスが低下すると報告されています（Choosing How to Remember）。例えば「先月の会議でAさんが提案した内容と、今週Bさんが報告した結果の関連性」のようなクエリには不向きです。

パラダイム2: 構造化型

概要: メモリをノートやグラフとして構造化し、エンティティ間の関係を明示的に管理します。

代表的なフレームワーク: A-MEM（NeurIPS 2025）、Zep、MemGAS

強み:

  • 関係性の推論が可能（マルチホップクエリ）
  • 時間的な知識の更新が容易
  • エンティティの矛盾検出が組み込まれている

A-MEM の特徴: Zettelkasten（ツェッテルカステン）メソッドに着想を得た自己組織化メモリです。新しいメモリが追加されると、既存メモリのコンテキスト表現やタグが自動的に更新され、知識ネットワークが継続的に洗練されていきます。

制約条件:

構造化型は「固定されたメモリ構造やルーティング戦略に依存するため、会話パターンや推論要求の変化に対する適応性が制限される」と指摘されています。グラフの肥大化によるメンテナンスコストも課題です。

パラダイム3: ポリシー管理型

概要: 強化学習や OS 的な階層管理メカニズムにより、「何を・いつ・どう記憶するか」を学習によって最適化します。

代表的なフレームワーク: Memory-R1、MIRA、MemoryOS（EMNLP 2025 Oral）、Mnemosyne

強み:

  • タスクに応じた適応的なメモリ管理
  • 不要なメモリの自動削除（forgetting）
  • 理論的にはもっとも柔軟

制約条件:

現時点では「ほとんどのアプローチが依然として固定された構造的バイアスや手作りの組織化ルールを前提としている」ため、真の適応性には到達していません。学習に必要なデータ量も大きく、コールドスタート問題があります。

3パラダイムの比較

観点 フラット検索型 構造化型 ポリシー管理型
実装難易度 低 中〜高 高
マルチホップ推論 弱い 強い タスク依存
メンテナンスコスト 低 高 中
適応性 低 中 高（理論上）
プロダクション実績 多い（Mem0等） 増加中 研究段階が多い
代表的ベンチマーク F1 Mem0: 34.20 FluxMem: 51.16 未統一

主要フレームワークの技術詳細と実装を理解する

Google Titans + MIRAS: ニューラル長期記憶

Titans は Google が発表した、RNN 的な効率性と Transformer 的な精度を統合するアーキテクチャです。MIRAS はその理論的基盤となるフレームワークです。

驚き度（Surprise Metric）メカニズム:

Titans の核心は「驚き度」による記憶の選択的保存です。これは、モデルの現在のメモリ状態と入力の乖離を検出する内部エラー信号です。

テスト時メモリ更新: 従来のモデルはオフライン再学習でしか知識を更新できませんでしたが、Titans はデータ処理中にリアルタイムでメモリを更新します。2つの補助メカニズムを備えています。

  1. モメンタム: 直前のコンテキストの流れを考慮し、個別には驚きが低い情報でも文脈的に重要なら記憶する
  2. 忘却（weight decay）: 極めて長いシーケンスに対してメモリ容量を適応的に管理する選択的忘却ゲート

ベンチマーク結果（論文報告値）:

  • BABILong ベンチマーク: パラメータ数が大幅に少ないにもかかわらず GPT-4 を上回る精度
  • 200万トークンを超えるコンテキストウィンドウにスケール可能
  • Mamba-2、Gated DeltaNet、Transformer++ を言語モデリング・常識推論で上回る

注意点:

Titans はモデルアーキテクチャレベルの変更であり、既存の Transformer ベース LLM（GPT-4o、Claude 等）にそのまま適用することはできません。現時点では研究段階のアーキテクチャであり、プロダクション利用は今後の展開次第です。

SimpleMem: 意味的ロスレス圧縮

SimpleMem（2026年1月）は、会話履歴を意味的にロスレス圧縮してトークン使用量を大幅に削減するフレームワークです。

3段階パイプライン:

  1. Semantic Structured Compression（意味構造化圧縮）: 生の対話をコンパクトなメモリユニットに変換します。代名詞の解決、時間参照の正規化、低情報コンテンツの除去をエントロピーベースのフィルタリングで実行します。

  2. Recursive Memory Consolidation（再帰的メモリ統合）: バックグラウンドで非同期実行される処理で、意味的類似度と時間的近接性に基づいて関連メモリユニットをグルーピングし、より高レベルの抽象表現に統合します。

  3. Adaptive Query-Aware Retrieval（適応的クエリ対応検索）: 密な意味埋め込み、疎な字句特徴、シンボリックメタデータを組み合わせたハイブリッドスコアリングで検索します。単純なクエリは k_min=3、複雑な推論は k_max=20 と動的に検索深度を調整します。

# SimpleMem の概念的な処理フロー（簡略化した疑似コード）
# 実際の実装は https://github.com/aiming-lab/SimpleMem を参照

class SimpleMemPipeline:
    def compress(self, dialogue: list[dict]) -> list[MemoryUnit]:
        """Stage 1: 意味構造化圧縮"""
        # エントロピーベースのフィルタリングで低情報発話を除去
        filtered = self.entropy_filter(dialogue)
        # 代名詞解決・時間参照正規化
        resolved = self.resolve_references(filtered)
        # コンパクトなメモリユニットに変換
        return self.to_memory_units(resolved)

    def consolidate(self, units: list[MemoryUnit]) -> list[MemoryUnit]:
        """Stage 2: 再帰的メモリ統合"""
        # 意味的類似度でクラスタリング
        clusters = self.semantic_cluster(units)
        # 各クラスタを高レベル抽象に統合
        return [self.merge_cluster(c) for c in clusters]

    def retrieve(self, query: str, units: list[MemoryUnit]) -> list[MemoryUnit]:
        """Stage 3: 適応的クエリ対応検索"""
        # クエリの複雑度に応じて検索深度を動的調整
        k = self.estimate_depth(query)  # 3〜20
        # ハイブリッドスコアリング（dense + sparse + metadata）
        return self.hybrid_search(query, units, top_k=k)

LoCoMo ベンチマーク結果（GPT-4.1-mini での論文報告値）:

フレームワーク 平均 F1 クエリあたりトークン 構築時間/サンプル
Full Context 18.70 16,910 -
Mem0 34.20 973 約1,300秒
SimpleMem 43.24 531 92.6秒

SimpleMem はフルコンテキスト方式と比較して約30倍のトークン削減を達成しつつ、F1 を大幅に向上させたと報告されています。

注意点:

SimpleMem は圧縮率が高い分、元の会話のニュアンスや文脈が一部失われる可能性があります。感情分析や細かいトーンの把握が必要なユースケースでは、圧縮率を下げる調整が必要かもしれません。

Mem0: プロダクション対応の記憶レイヤー

Mem0 はプロダクション環境向けの長期記憶アーキテクチャです。動的に会話から重要情報を抽出・統合・検索します。

アーキテクチャ:

Mem0g（グラフ拡張版）: 基本のフラットなベクトルストアに加え、グラフベースの記憶表現で複雑な関係性を捕捉します。エンティティをノード、関係をラベル付きエッジとして構造化します。

ベンチマーク結果（論文報告値）:

  • LLM-as-a-Judge メトリック: OpenAI Memory比で 26%相対改善
  • p95 レイテンシ: フルコンテキスト方式比で 91%削減
  • トークンコスト: 会話履歴全体処理比で 90%以上削減
  • LoCoMo の 4 カテゴリ（単一ホップ、時間、マルチホップ、オープンドメイン）すべてで既存手法を上回る

実装例（Mem0 の基本的な使い方）:

# pip install mem0ai
from mem0 import Memory

# Mem0 クライアントの初期化
config = {
    "llm": {
        "provider": "openai",
        "config": {"model": "gpt-4o", "temperature": 0.1}
    },
    "embedder": {
        "provider": "openai",
        "config": {"model": "text-embedding-3-small"}
    },
    "vector_store": {
        "provider": "qdrant",
        "config": {"host": "localhost", "port": 6333}
    }
}
memory = Memory.from_config(config)

# メモリの追加（会話から自動抽出）
conversation = [
    {"role": "user", "content": "私はPythonとRustが得意です"},
    {"role": "assistant", "content": "素晴らしいですね！"},
    {"role": "user", "content": "最近はLLMの推論最適化に取り組んでいます"}
]
memory.add(messages=conversation, user_id="user_123")

# メモリの検索
results = memory.search(
    query="このユーザーの専門分野は？",
    user_id="user_123"
)
# => [{"memory": "PythonとRustが得意", ...},
#     {"memory": "LLM推論最適化に取り組んでいる", ...}]

# メモリの更新（矛盾は自動解決）
memory.add(
    messages=[{"role": "user", "content": "最近はGoも使い始めました"}],
    user_id="user_123"
)

なぜ Mem0 を選ぶか:

  • SOC 2 / HIPAA 準拠で、エンタープライズ要件を満たせる
  • AWS（ElastiCache + Neptune Analytics）での運用パターンが公式ブログで公開されている
  • セルフホスト（Kubernetes、エアギャップ環境）とクラウドの両方に対応

注意点:

Mem0 のメモリ抽出は LLM に依存するため、抽出精度は使用するモデルの品質に左右されます。また、グラフストア（Mem0g）を使う場合、グラフデータベースの運用コストが追加で発生します。

LangMem SDK: LangChain エコシステムの長期記憶

LangMem は LangChain が公式リリースした長期記憶 SDK です。LangGraph のメモリストアとネイティブに統合されますが、LangChain に依存せず単独でも使用可能です。

3種類の記憶モデル:

記憶タイプ 内容 保存形式
Semantic（意味的） ユーザーの好み・事実 構造化データ
Episodic（エピソード） 過去のやり取りの具体例 few-shot 例
Procedural（手続き的） タスク遂行のスキル・手順 プロンプト更新

実装例（LangMem の基本的な使い方）:

# pip install langmem
from langmem import Client

# LangMem クライアントの初期化
client = Client()

# 名前空間でスコープを管理
namespace = ("app", "user_123")

# メモリの保存
client.add_memories(
    messages=[
        {"role": "user", "content": "vLLMでバッチ推論を試しています"},
        {"role": "assistant", "content": "vLLMは連続バッチングが得意ですね"}
    ],
    namespace=namespace,
)

# メモリの検索
memories = client.search_memory(
    query="このユーザーが使っている推論フレームワークは？",
    namespace=namespace,
)

なぜ LangMem を選ぶか:

  • 既に LangChain / LangGraph を使っているプロジェクトでは導入コストが低い
  • Procedural Memory（手続き的記憶）により、エージェントのプロンプト自体を学習的に改善できる
  • 名前空間による柔軟なスコーピング（ユーザー単位、チーム単位、アプリ単位）

注意点:

LangMem はLangChain エコシステムに最適化されているため、独自のエージェントフレームワークとの統合にはアダプター実装が必要な場合があります。

KVzip: KVキャッシュ圧縮

KVzip はソウル大学が開発した、LLM の KV キャッシュをクエリ非依存に圧縮する技術です。

従来の KV キャッシュ圧縮はクエリに依存（現在の質問に最適化）するため、フォローアップ質問で精度が低下する問題がありました。KVzip は元のコンテキストを再構成する能力に基づいて各 KV ペアの重要度を定量化するため、異なるクエリ間でも圧縮済みキャッシュを再利用できます。

性能（論文報告値）:

  • KV キャッシュサイズ: 3〜4倍圧縮
  • FlashAttention デコーディングレイテンシ: 約2倍高速化
  • 170K トークンまでのコンテキストに対応
  • LLaMA 3.1、Qwen 2.5、Gemma 3 で検証済み

注意点:

KVzip は外部メモリストアではなく、モデル内部の KV キャッシュを最適化する技術です。そのため、Mem0 や LangMem のような「セッションをまたぐ記憶」ではなく、「長いコンテキストを効率的に処理する」ための手法として位置づけられます。

ユースケース別の選定指針を設計する

ここまでの技術を俯瞰し、ユースケース別にどのアプローチを選ぶべきかを整理します。

選定フローチャート

具体的な選定例

ユースケース 推奨アプローチ 理由
カスタマーサポートBot Mem0 ユーザー別の好み・履歴を安全に管理
コーディングエージェント LangMem + Procedural コード規約やプロジェクト知識を学習的に蓄積
調査・分析エージェント A-MEM / Mem0g エンティティ間の関係推論が必要
大量文書の QA KVzip + RAG コンテキスト効率を最大化
チャットBot（コスト重視） SimpleMem トークン30倍削減
研究用プロトタイプ MemOS 複数のメモリタイプを統合実験

よくある間違い: 記憶の粒度設計の失敗

長期記憶の実装で最も多い間違いは、記憶の粒度を適切に設計しないことです。

  • 粒度が粗すぎる: 会話全体を1つのメモリとして保存すると、検索精度が低下します。「先週のプロジェクトAの議論」と「今週のプロジェクトBの議論」が混在し、適切な情報を取得できません。
  • 粒度が細かすぎる: 一文ごとにメモリを生成すると、ストレージコストとメンテナンスが爆発します。A-MAC（Adaptive Memory Admission Control）の研究では、記憶の価値を「将来的有用性」「事実の確信度」「意味的新規性」「時間的新近性」「コンテンツタイプ」の5因子で評価するアプローチが提案されています。

トレードオフ: 記憶量が増えるほど潜在的な知識は豊富になりますが、検索ノイズも増加し、レイテンシとコストが上昇します。SimpleMem の再帰的統合や Mem0 の矛盾検出のような自動的なメモリ管理機構が、このトレードオフを緩和する鍵となります。

よくある問題と解決方法

問題 原因 解決方法
古い情報が優先される 時間的重み付けの欠如 Mem0 の矛盾検出 + 時間ベースの重み付けを導入
メモリ検索が遅い インデックスの肥大化 SimpleMem の圧縮パイプラインでトークン量を削減
関係性クエリに答えられない フラット検索型の限界 Mem0g のグラフストアや A-MEM の構造化メモリに移行
メモリが無限に増殖する 忘却メカニズムの欠如 A-MAC の5因子評価で重要度の低いメモリを自動削除
複数ユーザーのメモリ混在 名前空間の未設定 LangMem の namespace や Mem0 の user_id で厳密にスコーピング

まとめと次のステップ

まとめ:

  • LLM の長期記憶は 3つのパラダイム（フラット検索型・構造化型・ポリシー管理型）に分類され、それぞれ明確なトレードオフがあります
  • プロダクション利用なら Mem0 が現時点で最も成熟しており、SOC 2 / HIPAA 対応・AWS 運用パターンが整備されています
  • トークン効率を最優先するなら SimpleMem で30倍の削減が見込めますが、ニュアンスの喪失リスクがあります
  • Google Titans + MIRAS は「テスト時メモリ更新」という新しいパラダイムを開拓しましたが、現時点ではモデルアーキテクチャレベルの変更が必要です
  • ICLR 2026 での MemAgents ワークショップ採択が示すように、この分野は急速に成熟しつつあります

次にやるべきこと:

  • まずは Mem0 のクイックスタート で基本的な長期記憶を既存エージェントに統合してみましょう
  • LangChain ユーザーは LangMem SDK で Procedural Memory の効果を検証してみてください
  • トークンコストが課題なら SimpleMem の圧縮パイプラインを試してみてください

参考

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?