AIエージェントのメモリは、コンテキスト窓をひたすら広げれば解ける──そう思われていた。だがMem0が出してきた数字はまったく違う。フルコンテキスト方式が1回あたり26,031トークンを溶かすところを、Mem0は1,764トークンで同等の精度を出す(ECAI 2025論文 Table 2)。比較対象のZepは記憶グラフ全体で60万トークン超を必要とすると報告されており、Mem0の1会話あたりトークン量と比べるとメモリ規模で約340倍に達する(同論文§4.5)。AWSはこのMem0をエージェントSDKの公式メモリプロバイダーに選び、2026年4月の新アルゴリズムではLoCoMo 91.6点を平均約7,000トークンで叩き出した。この記事では、Mem0が解いた『AIエージェントの記憶』の中身、海外4社の使い方、そしてここから派生して作れるプロダクトを整理する。
『会話を閉じたら忘れる』を解く:AIエージェント記憶の課題
ChatGPTのチャット履歴とAIエージェントの「記憶」は、見た目が似ていても別ものだ。前者は過去のメッセージを並べて毎回コンテキスト窓に流し込んでいるだけで、ユーザーが何を好み、どのプロジェクトを進めているかをエージェントが構造化して保持しているわけではない。会話が長くなれば古いメッセージは押し出され、別セッションに切り替えれば、また一から自己紹介し直す羽目になる。
力技で解くなら「コンテキスト窓を1Mトークンまで広げて全履歴を毎回流せばいい」になる。だが、ECAI 2025の論文(Chhikara et al.)が測った数字はその限界をはっきり見せる。フルコンテキスト方式は精度こそ72.9%(LLM-as-Judge)を出すが、p95レイテンシは17.1秒、1回あたりのトークン消費は26,031トークンに達する。1Mトークン入力をClaude Sonnet 4.6で回すと1回あたり3ドル相当。1日50タスク動かすだけで150ドルが文脈オーバーヘッドに溶けるという試算もある(Hermes OSの解析)。
Mem0はLLMとアプリの間に挟まる『賢いキャッシュ』のような位置付けで、コンテキスト窓を広げる戦いを降りて、データベース的に「事実だけ」を取り出す方向に舵を切ったのがこのライブラリの設計上の選択だ。
Mem0とは何か──中核アーキテクチャ『抽出・更新・取得』の3段階
Mem0の動き方は、論文では3段階に整理されている。会話履歴をそのまま貯めるのではなく、毎回「事実」に圧縮して扱うのがポイントだ。
第1段階(抽出):新しい発話ペアが入ると、Mem0は内部の小型LLM(GPT-4o-mini相当)で「重要な事実」を切り出す。生の発話「昨日ピザを食べたらナッツの破片が混ざってて喉がイガイガしてさあ」は、「ユーザーはナッツアレルギーを持つ」という1行の事実に圧縮される。
第2段階(更新):抽出した事実を、既存の記憶ベクトルの中で意味的に近いものとつき合わせる。「追加(ADD)」「上書き(UPDATE)」「削除(DELETE)」「変更なし(NOOP)」の4択をLLMが判断する。ユーザーが後日「ナッツアレルギーは治った」と言えば、過去の事実は単に消されるのではなく『無効化』される。事実の履歴を残したまま、現在の状態だけを更新できる作りだ。
第3段階(取得):次にユーザーが何か話したとき、3つの並列パスでスコアを取る。意味の近さ(セマンティック類似度)、キーワード一致(BM25)、エンティティ一致だ。3つを統一スコアにまとめて関連度の高い記憶だけを引いてくる。2026年4月の新アルゴリズム(Single-pass Hierarchical Extraction + Multi-signal Retrieval)は、この多信号取得をもう1段強化したものだ。
派生版のMem0g(グラフ版)では、記憶をエンティティのノードとリレーションのエッジで表現し、Neo4j上に保持する。会話文の流れではなく「人物・組織・時刻」のつながりを保ちたいケースで効くが、本記事は標準版を主に扱う。
91.6点を約7,000トークンで取る、Zepの340分の1で
数字を並べる。
- ECAI 2025論文 Table 2の測定値:Mem0は1会話あたり1,764トークンで、LLM-as-Judgeスコア66.88%(±0.15)。Zepは1会話あたり3,911トークン、65.99%(±0.16)。ただしZepは記憶グラフ全体で60万トークン超を要する設計とされ(同論文§4.5)、メモリ蓄積規模ではMem0の約340倍の差になる
- フルコンテキスト方式比でp95レイテンシ91%削減、トークンコスト90%超削減。OpenAI Memory比で精度は相対26%向上(arXiv 2504.19413)
- 2026年4月の新アルゴリズムでは、LoCoMo 91.6点、LongMemEval 93.4点、BEAM 1M 64.1点を、1クエリあたり平均約6,956トークンで達成(Mem0自社測定、公式ブログ「State of AI Agent Memory 2026」掲載値)
- 時間的推論で+29.6ポイント、マルチホップ推論で+23.1ポイントの改善
数字の意味を読み解けば、Mem0は「全部を渡す代わりに、抽出した事実だけを渡す」というデータベース的な解法を、精度を落とさずに成立させたことになる。Zepのような時系列グラフ型と比べると、1会話あたりのトークン消費でも軽量で、かつメモリ全体の蓄積規模では何百倍も小さいまま、フルコンテキスト方式の精度に届いた。LLMの長期記憶を扱う上で、まず数字で比較するならMem0は現時点で最効率の部類に入る。
Python 20行で動かす:記憶の追加と検索
Mem0のOSS版はApache 2.0で、pip install mem0aiで入る(パッケージ名はmem0ではなくmem0aiなので注意)。最小の使い方はこうなる。
from mem0 import Memory
from openai import OpenAI
memory = Memory() # 内部でベクトルストアとLLMを起動
openai_client = OpenAI()
def chat(user_id: str, user_message: str) -> str:
# ① 取得:このユーザーに関連する記憶を3件だけ引く
hits = memory.search(query=user_message,
filters={"user_id": user_id},
top_k=3)
context = "\n".join(h["memory"] for h in hits["results"])
# ② 推論:全履歴ではなく「抽出された事実だけ」をLLMに渡す
messages = [
{"role": "system", "content": f"既知の事実:\n{context}"},
{"role": "user", "content": user_message},
]
res = openai_client.chat.completions.create(
model="gpt-4o-mini", messages=messages,
)
answer = res.choices[0].message.content
# ③ 抽出+保存:Mem0が今回のやりとりから事実を切り出して書き戻す
memory.add(messages + [{"role": "assistant", "content": answer}],
user_id=user_id)
return answer
user_idの代わりにagent_idやrun_idを渡せば、エージェント単位・実行単位で記憶スコープを切り分けられる(Mem0は会話・セッション・ユーザー・組織の4層メモリを持つ)。AWS Strands Agents SDKと組み合わせる場合は、Agent(tools=[mem0_memory, use_llm])の形でmem0_memoryをエージェントのツールとして直接渡せる。
AWS・TrendMicro・Groq・BrowserUse──実際に使っている企業
AWS(米国):2025年5月、AmazonはStrands Agents SDKの公式メモリプロバイダーとしてMem0と戦略的パートナーシップを結んだ(Mem0公式ブログ)。BedrockのモデルとMem0を組み合わせ、エージェントが過去対話を覚えた状態で動く構成をSDK初日からサポートする。
TrendMicro(グローバル、サイバーセキュリティ):社内向けAIチャットボット「Trend's Companion」を、Amazon Bedrock + Amazon Neptune + Mem0の構成で構築した(2026年4月22日、AWS公式ブログで詳細公開)。Neptuneが組織構造・プロセスの知識グラフを持ち、Mem0が短期(会話)と長期(永続的な業務知識)のメモリを管理する。著者はTrendMicroのシニアアーキテクトShawn TsaiとAWSのソリューションアーキテクト陣(Ray Wang、Zhihao Lin)だ。
Groq(米国、LPU推論基盤):GroqCloud上でMem0をリアルタイム動作させる事例を公式が公開している。GroqのLPUに載せ替えたことでレイテンシは約5分の1、エンドツーエンド2秒未満を達成。共同創業者でCTOのDeshraj Yadavは公式記事で「Groqの決定論的・低レイテンシな推論が、ユーザーをまたいだリアルタイム記憶の信頼できる基盤になる」とコメントしている。
BrowserUse(オープンソース、ブラウザ自動化エージェント):Webブラウザを操作するOSSエージェント。Mem0統合でタスク完了率を66%から98%まで引き上げた(+32ポイント)。同時にLLMコストが41%下がっている。エージェントが過去に同じサイトで失敗した手順を覚えていることで、無駄な試行錯誤が消えた結果だ。
なおInfoWorldの取材記事では、Netflix・Lemonade・Rocket MoneyもMem0を本番に組み込んでいると報じられている(各社個別の公式発表は本記事執筆時点で未確認で、出典はInfoWorldの記述に依る)。
Letta・Zepと何が違うのか──Agent Memory 3社の設計思想対比
Agent Memoryの分野には別の派閥がある。代表的なのはLettaとZepだ。
Letta(旧MemGPT):UCバークレー発の研究をベースに、エージェントが「自分のメモリを自分で管理する」OS的な構造を採る。コアメモリ(コンテキスト窓内)・リコールメモリ(ディスクキャッシュ相当)・アーカイバルメモリ(コールドストレージ相当)の3層を、エージェントが関数呼び出しで明示的に出し入れする。エージェントはLetta上で「走る」ものとして設計されていて、既存スタックからの移行には2〜6週間の開発工数が必要になるとTokenMixのレポートは試算している。
Zep:時間つきの知識グラフ(Temporal Knowledge Graph)が中核。「いつから・いつまでその事実が有効か」を全ファクトに記録し、時系列クエリに強い。AtlanのランキングではLongMemEval全体スコアで63.8点(Mem0旧版は49点)を出す。ただしECAI 2025論文§4.5では、Zepの記憶グラフ全体が60万トークン超を要すると報告されている。
Mem0:LLMとアプリの間に挟む「ライブラリ型」。フレームワーク非依存で、LangChain・CrewAI・AutoGen・自前のループ、どれにでも接続できる。ロックインは低く、別ライブラリへの差し替えも数日の作業で済む。
整理するとこうなる。エージェントを丸ごとLettaに乗せたい人にはLetta、時系列で事実が変わる業務(法務・医療・金融)で精密な時間追跡を最重要視するならZep、まずは既存のスタックに記憶層だけ後付けしたいならMem0が向く。
この技術で何が作れるか:3つの方向性
A. 垂直特化型──治験コーディネーター向け患者対話メモリ
ベース実例:TrendMicroが社内copilotで採るBedrock + Neptune + Mem0構成。
発展アイデア:治験(臨床試験)に参加する患者と話す医療スタッフ向けAIアシスタント。患者ごとに、副作用の訴え・服薬忘れ・気分の変化を全てMem0のuser_id単位で永続化し、Neptuneにはプロトコル(治験計画書)と禁忌薬の知識グラフを置く。次の対話時に過去30日分の状態変化が事実リストで返るので、医療スタッフが「前回からの変化」を毎回聞き直す必要が消える。Mem0のtemporal queries(+29.6ポイント改善)が効くシナリオで、「いつ症状が出始めたか」「服用と症状の前後関係」が問えるのが鍵だ。
B. 既存プロダクト置換型──サポートSaaSの『記憶層』だけ差し替える
ベース実例:BrowserUseがMem0統合でタスク完了率を66%→98%、コストを41%下げた事例。
発展アイデア:ZendeskやIntercomのようなチケット型サポートSaaSは、過去問い合わせを「全文検索」で引いてくる構造になっている。これを、顧客個人の単位で事実化(「2024年に解約を1度示唆」「契約形態はEnterprise」)したMem0レイヤーに差し替えると、AI返信ドラフトの精度が変わる。既存SaaSのうち「記憶を扱うレイヤー」だけを置換するBYOM(Bring Your Own Memory)型のミドルウェアとして売る。
C. 新カテゴリ創出型──『個人専用エージェント』を可搬にする標準メモリ
ベース実例:AWSがStrandsの公式メモリプロバイダーにMem0を採用した事実そのもの。
発展アイデア:エージェントが個別サービスに紐付いて記憶を持つ、という現状を反転させる。ユーザー側が「自分の記憶」をクラウドに持ち、好きなAIサービスに記憶ごとログインする世界を作る。OpenIDのような認証連携と組み合わせ、ChatGPTにもClaudeにもGeminiにも、自分の食事制限・好みのトーン・進行中のプロジェクトを同じuser_idで渡せるようにする。CEOが言う「すべてのアプリケーションがデータベースを必要とするように、すべてのエージェントは記憶を必要とする」を、ユーザー側に主権を渡す形で具現化する新カテゴリだ。
自社で採用するときに見るべきポイント
- 時系列推論が業務の中心(法務・医療・金融)で、事実の有効期間を厳密に追いたい場合:Zepの方が安心。Mem0は時間情報も持つが、グラフ構造の精密さでは劣る
- 既存のLangChainやCrewAI、自前のループに『あとから』記憶層を足したい場合:Mem0が最短ルート。ロックインも低い
- エージェントの実行ランタイムごと丸ごと預けたい場合:Letta
- 管理SaaSで使いたい場合:Mem0プラットフォームはSOC 2、HIPAA、BYOK、オンプレ展開に対応。グラフメモリは月額249ドルのProプランから、というのは留意点(Atlan「Best AI Agent Memory Frameworks in 2026」)
「LLM-as-Judge 91.6点」のような数字はMem0が自社のベンチマーク基盤(memory-benchmarks)上で測ったものなので、自社ワークロードでも同じ差が出るとは限らない。社内データで小さく回して、トークン量・レイテンシ・回答品質を一度測ってから本採用を決めるのが安全だ。
もっと詳しく知りたい人へ
- GitHubリポジトリ:mem0ai/mem0(56,100スター、Apache 2.0、@mem0/cli v0.2.5が2026年5月14日リリース)
- 論文(ECAI 2025):Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
- 2026年4月新アルゴリズム公式解説:State of AI Agent Memory 2026
- AWS Strands SDK統合発表:AWS and Mem0 Partner Blog
- 公式ドキュメント:docs.mem0.ai
最後に──『コンテキスト窓』の次の話
長い文脈窓を持つLLMが当たり前になっても、AIエージェントのメモリはそれだけでは解けない。むしろコンテキスト窓を広げるほど、毎回どの情報を渡すかという選別の問題が大きくなる。Mem0が示しているのは、「すべての履歴を毎回送る」のではなく、「事実だけを抽出して保管し、関連するものだけを取り出す」というデータベース的な発想だ。CEO Taranjeet Singhの言葉「すべてのアプリケーションがデータベースを必要とするように、すべてのエージェントは記憶を必要とする」(Mem0公式PR、2025年10月)は、エージェント時代のインフラの輪郭をうまく示している。
問いはここから先だ。あなたの作っているプロダクトのどこに「記憶」を載せると、ユーザー体験が一段上に上がるか。記憶層は派手な機能ではないが、これから出てくるエージェント製品の差別化を裏側で支える土台になりそうだ。