mem0とは？v3の破壊的変更・旧版のSQLインジェクションとAIエージェントに記憶を持たせる実装

mem0は、LLMとの会話からファクトを抜き出して保存し、次の会話で必要な分だけ引き戻すメモリ層です。GitHubのスターは約6.8万（2026年10月時点）、ライセンスはApache-2.0、PyPI上の最新版は2.2.1（2026年9月25日リリース）。ここで注意がいるのは、日本語で読める解説記事の大半が v1.1〜v2 時代に書かれており、そのコードを2.x系にそのまま貼ると ValueError で止まる点です。もう一つ、旧版のまま動かしている環境には、2026年10月22日に公表されたDatabricksベクトルストアのSQLインジェクション（CVE-2026-115324）が関わってきます。この記事では、mem0の内部処理の流れ、2.x系で動くインストールから追加・検索までのコード、v3で削除されたグラフメモリと既定値の非互換、旧版の脆弱性の影響範囲と確認手順、OSS版とマネージド版の費用の数え方、そして受託開発で採用してよい条件と見送るべき案件の型までを扱います。数値と仕様は公式ドキュメントとPyPI、GitHubリポジトリ、GitHub Advisory Databaseにあたって確認しました。

まとめ：mem0の採用を決める前に確認する3点とv3移行の判断順序

mem0を入れるかどうかは、機能の多さではなく次の3点で決まります。第一に、対話が単発で終わらず、同じ利用者が何度も戻ってくるプロダクトなのか。第二に、記憶が外れたときに業務上どこまで許されるのか。第三に、保存した内容の保持期間と削除の責任を誰が持つのか。

三つめを詰めずに進む例が多く見られます。メモリ層は個人の嗜好や業務情報を長期に溜め込む仕組みなので、実質的には個人データを蓄積する保管庫です。どのタイミングで消えるのかを決めないまま本番に出すと、退会したはずの利用者の発言が数か月後の応答に混ざります。

移行の順序も先に示しておきます。既存コードがv2以前で動いているなら、まず search() のエンティティIDを filters 辞書へ移し、top_k と threshold と rerank を明示指定して旧挙動を復元してから、v3の新既定値へ寄せていく順番が安全です。一気に上げると、検索件数が100件から20件に減った影響と、類似度しきい値が0.1に入った影響が混ざり、どちらで結果が変わったのか切り分けられません。

グラフメモリを前提に設計していた場合は、移行そのものを止める判断もあります。v3のOSS版では graph_store 設定と enable_graph が削除され、この機能はマネージド版へ移りました。関係性の追跡が要件の中核なら、v2系に留めるか、別のメモリ基盤を評価する方が筋が通ります。

ただし「旧版に留める」判断には条件が付きます。mem0aiの0.1.117以上1.0.8未満でDatabricksベクトルストアを使っている環境は、CVE-2026-115324の影響範囲に入ります。v2系に留めるとしても、少なくとも1.0.8以上へは上げてください。Databricksを使っていない構成でも、手元の版番号を一度確かめておくと後の判断が速くなります。

mem0の仕組みと記憶の抽出から検索までの処理経路を実装目線で整理

「会話履歴を全部プロンプトへ入れる」方式との違いは、保存するものと引き戻すものを分離している点にあります。AIエージェントとは？生成AIとの違い・仕組みと業務に組み込む判断基準を解説で扱った自律的な振る舞いを長期に続けるには、履歴そのものではなく履歴から抽出した事実を持ち回る必要があります。

会話からファクトを抽出してベクトルストアへ保存する処理の流れ

add() に渡されたメッセージは、まずLLMへ送られてファクト抽出にかけられます。「昨日は疲れた」のような揮発的な発話は落ち、残るのは「PythonとAWSで開発している」のような持続する属性です。抽出された文はembeddingへ変換され、ベクトルストアへ格納されます。

v3ではこの抽出が単一パスの ADD-only へ変わりました。v2までは候補抽出のあとに ADD / UPDATE / DELETE を判定する二段構えで、LLM呼び出しが複数回走っていました。公式の移行ガイドは、これを1回のLLM呼び出しへ束ねた結果、抽出レイテンシがおよそ50%減り、LoCoMoのスコアが20ポイント上がったと記載しています。

設計への影響は小さくありません。add() の戻り値にUPDATEとDELETEが返らなくなったため、イベント種別で分岐していた既存コードは分岐そのものを外すことになります。記憶の更新は「古い記憶を書き換える」のではなく「新しい記憶を足して、検索側で新しい方を優先させる」形に変わったと理解してください。コンテキストの組み立て全体をどう設計するかはコンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いと4つの実装手法で整理しています。

ここで押さえておきたいのは、保存される文の出どころです。ベクトルストアに入るのはLLMが会話から書き起こした文であり、その会話は利用者が自由に入力したものです。つまりメモリの本文・メタデータ・発話者名は、すべて外部入力として扱う必要があります。後述するDatabricks連携の脆弱性は、まさにこの前提が実装側で崩れていた例です。

セマンティック・BM25・エンティティ一致を束ねるv3の検索方式

取り出し側は3つのシグナルを融合するハイブリッド検索になりました。意味の近さを見るセマンティック検索、語の一致を見るBM25、固有名詞の一致を見るエンティティマッチングの3つです。人名や製品名のような固有表現は、ベクトルの近さだけでは拾い漏れます。「山田さん」と「田中さん」はベクトル空間では近い位置に来てしまうためです。

この3つ目のシグナルには spaCy が要ります。導入していない環境ではエンティティマッチングが無効化され、セマンティック検索だけで動きます。Qdrantを使う場合の fastembed も同様で、入れなければBM25側が効きません。動くには動くが、公称の検索精度は出ない状態になります。

依存を落としたまま「精度が出ない」と評価してしまう事故は、この構造を知らないと起こります。ベクトル検索とキーワード検索の役割分担そのものはベクトル検索とセマンティック検索の違いで扱った通りで、mem0はその両方を内側に抱え込んだ実装だと捉えると位置づけが掴めます。

LoCoMo 92.5・p50 0.88秒という公称値の読み方と前提条件

公式リポジトリが掲げるベンチマークは3種類です。mem0ai/mem0のREADMEには、LoCoMoで精度92.5・p50レイテンシ0.88秒・トークン7.0K、LongMemEvalで精度94.4・p50 1.09秒・トークン6.8K、BEAM（1M）で精度64.1・p50 1.00秒・トークン6.7Kと記載されています。

公称値を読む際には、測定条件への注意が必要です。LoCoMoとLongMemEvalは英語の長期対話データセットで、日本語の業務会話とは分布が違います。BEAMの64.1という数字は、長さ1Mトークン規模の文脈では3分の1以上を取りこぼすという意味でもあります。記憶が外れても業務が止まらない設計にしておく前提は、この段階で置いておいてください。

トークン数の6.7K〜7.0Kは、全履歴を投げる方式との比較で効いてきます。10万トークンの履歴を毎回投げる構成と比べれば、1回の呼び出しあたりの入力量は桁で変わります。この入力量に関わる費用の内訳は、後半の章で扱う内容です。

mem0ai 2.x系のインストールから最初のメモリ追加と検索までの手順

ここからは手を動かします。2026年10月時点の2.x系で動く形だけを書きます。

mem0aiのインストールとAPIキー設定を含む前提環境の準備

PyPIのmem0aiページによると、最新版は2.2.1（2026年9月25日）、対応PythonはPython 3.10以上4.0未満、ライセンスはApache-2.0です。9月には2.0.20（9月2日）のあと2.1.0（9月18日）、2.2.0（9月23日）と続けて出ており、更新の間隔が短いパッケージだと見ておくと運用計画を立てやすくなります。エンティティマッチングまで効かせるなら、公式ドキュメントが推奨する nlp エクストラと spaCy の英語モデルを入れます。

pip install "mem0ai[nlp]>=2.2.1"
python -m spacy download en_core_web_sm
export OPENAI_API_KEY="sk-xxxxxxxx"

下限の版を明示しておくのは、後で触れる旧版の脆弱性を誤って引き戻さないためです。requirements.txt やロックファイルで版を固定している案件では、固定値そのものが1.0.8未満になっていないかも同時に見てください。

既定のLLMは 公式のPython Quickstartにある通り OpenAI の gpt-5-mini、埋め込みは text-embedding-3-small（1536次元）です。ベクトルストアはQdrantがローカルの一時領域に、履歴DBはSQLiteがホームディレクトリ配下に作られます。つまり何も設定しなければ、外部サービスはOpenAIだけ、保存先はローカルという構成で起動します。

Memory.add と search を使った最小構成の動作コードと戻り値

次のコードが2.x系で動く最小構成です。v2までの記事と見比べると、search() の書き方が変わっているのが分かります。

from mem0 import Memory

m = Memory()

messages = [
    {"role": "user", "content": "PythonとAWSで社内システムを作っています"},
    {"role": "assistant", "content": "承知しました"},
]
m.add(messages, user_id="tenant-a-user-001")

results = m.search(
    "この利用者の開発環境は何か",
    filters={"user_id": "tenant-a-user-001"},
    top_k=20,
    threshold=0.1,
)
print(results)

戻り値には ADD イベントだけが入ります。v2までのように UPDATE や DELETE を待ち受ける分岐を書いても到達しません。user_id を search() の第2引数以降にキーワード引数として渡すと例外になるため、filters 辞書へ入れる形が必須です。

2.2.1では add() の失敗時の振る舞いも変わりました。v2.2.1のリリースノートによると、ベクトルストアが挿入を拒否したレコードを成功した ADD として返すことはなくなり、抽出した記憶が1件も挿入できなかった場合は VectorStoreError が送出されます。2.2.0以前で「戻り値にADDがあれば保存できた」と判定していたコードは、例外処理を足しておかないと、これまで黙って失われていた保存失敗がそのままアプリ全体のエラーとして表に出ます。

既定のQdrant・SQLite保存先とベクトルストアを差し替える設定

本番での運用では、保存先の明示が必要です。Memory.from_config() に辞書を渡す形で、ベクトルストア・LLM・埋め込みモデルをそれぞれ差し替えられます。mem0は20種類を超えるベクトルストアに対応しており、Qdrant・Chroma・Milvus・pgvector・Pinecone・Databricksなどが選べます。

config = {
    "vector_store": {
        "provider": "qdrant",
        "config": {
            "collection_name": "mem0_tenant_a",
            "host": "qdrant.internal",
            "port": 6333,
        },
    },
    "llm": {"provider": "openai", "config": {"model": "gpt-5-mini"}},
}

m = Memory.from_config(config)

v3では {collection_name}_entities という別コレクションが自動で作られます。権限を絞ったマネージドDBでは作成に失敗するため、同じ埋め込み次元であらかじめ手動で作成しておくことが必要です。検索基盤をRAGと共用する場合の組み立てはLangChainでRAGを構築する手順と併せて設計すると、コレクション名とスキーマの衝突を避けられます。

v3で消えたグラフメモリとfilters必須化を含む非互換変更の一覧

この章が、既存記事を読んで手が止まった人向けの本題です。

graph_store削除とrelationsフィールド消失が及ぼす設計への影響

v2まで、OSS版は Neo4j などの外部グラフDBを接続してエンティティ間の関係を保持できました。公式の移行ガイドによれば、v3では enable_graph、graph_store 設定、外部グラフDB統合がまとめて削除され、グラフメモリはマネージド版の組み込み機能として再実装されています。検索結果の relations フィールドも返りません。

# v2までは動いた設定（v3では graph_store が解釈されない）
config = {
    "graph_store": {
        "provider": "neo4j",
        "config": {"url": "bolt://neo4j.internal:7687", "username": "neo4j", "password": "xxx"},
    },
    "version": "v1.1",
}

「AとBが同僚で、BとCが上司部下」といった関係の推論を要件に置いていたなら、OSS版のv3は選択肢から外れます。ここは言い切ります。セルフホストと関係推論の両立は、2026年10月時点のmem0では成立しません。どちらを捨てるかを先に決めてください。

filters必須化とtop_k・threshold既定値の変更が壊す既存コード

グラフメモリほど目立たないが実害が大きいのが既定値の変更です。移行ガイドの記載を表に起こします。

表中のファクト抽出用の旧設定キーは custom_fact_extraction_prompt です。v3では custom_instructions へ名前を変更します。

厄介なのは、top_k と threshold の変更が例外を出さずに結果だけ変える点です。取得件数が5分の1になり、類似度0.1未満が切り落とされる。移行直後に「記憶が消えた」と報告が上がる典型はこれで、実際にはデータではなく取り出し条件が変わっています。TypeScript版では limit が topK へ改名されているため、同じ罠がフロント側にもあります。

mem0ai旧版のDatabricks連携で見つかったSQLインジェクションの確認手順

v3への移行を見送って旧版で動かしている案件に向けた章です。2026年10月22日、GitHub Advisory DatabaseにGHSA-7587-9684-52r6（CVE-2026-115324）が公表されました。対象はmem0aiのDatabricksベクトルストア実装で、深刻度はCriticalです。

CVE-2026-115324の影響版と修正版・CVSS値と攻撃の成立条件

アドバイザリの記載を表にまとめます（2026年10月29日時点）。

表の該当ファイルのパスは mem0/vector_stores/databricks.py です。説明文によれば、記憶の本文・メタデータ・メッセージの発話者名に細工した文字列を入れると、それがエスケープされないまま insert() と update() の文字列補間に渡り、設定先のDatabricks SQLウェアハウスで任意のSQLが実行されます。攻撃者は管理画面に入る必要がなく、mem0へ流れ込む会話を書ける立場であれば足ります。チャット画面の利用者がそのまま攻撃者になりうるという点が、この脆弱性の怖さです。SQLインジェクションの一般的な仕組みと防ぎ方はSQLインジェクションとは？攻撃例と対策を実行結果で解説で、攻撃の土台になるDatabricks側の構成と課金はDatabricksとは？できること・DBU課金の料金と業種別の費用・導入事例で扱っています。

修正版の公開（3月）から公表（10月）まで7か月ほど空いている点にも注意がいります。3月下旬以降に一度でも1.0.8以上へ上げていれば対象外ですが、ロックファイルで1.0.7以前に固定したまま半年以上動かしている環境は、公表によって攻撃手順が広く知られた状態で残っています。現行の2.x系はアドバイザリが示す影響範囲の対象外です。

Databricksベクトルストアを使う環境で版番号と設定を確かめるコマンド

確認に必要な手順は次の2段階です。まず導入されている版番号が影響範囲に入るかを判定し、入る場合はDatabricksをベクトルストアに指定している箇所があるかを探します。次のスクリプトは、実行中の環境に入っているmem0aiの版を読んで判定します。

from importlib.metadata import version
from packaging.version import Version

v = Version(version("mem0ai"))
affected = Version("0.1.117") <= v < Version("1.0.8")
print(f"mem0ai {v}: {'影響範囲（1.0.8以上へ更新）' if affected else '影響範囲外'}")

続いて、リポジトリの中でDatabricksをprovider指定している設定を洗い出します。環境変数や外部の設定ファイルからproviderを読み込む実装もあるため、コードだけでなくデプロイ先の設定値も見てください。

pip show mem0ai | grep -i "^version"
grep -rn --include="*.py" --include="*.yaml" --include="*.json" "databricks" .
pip install --upgrade "mem0ai>=1.0.8"

最後の行は、v3への移行を当面見送る場合の最小限の更新です。1.0.8は1.x系のままなので、本記事で扱ったv3の非互換を踏まずに修正だけを取り込めます。

更新後にSQLウェアハウス側で見直す権限とメモリ内容の点検項目

版を上げて終わりにしないでください。影響版の期間中に攻撃を受けていた場合、更新しても既に実行されたSQLは戻りません。最低限、次の3点は見ておきます。

• mem0が使う接続用の資格情報に、メモリ用テーブル以外への書き込み権限や他スキーマの読み取り権限が付いていないか
• Databricks SQLウェアハウスのクエリ履歴に、mem0の接続から発行された想定外の DROP・UPDATE・他テーブル参照が残っていないか
• メモリ用テーブルに、SQLの断片を含む不自然な本文やメタデータが入っていないか

一つめは今回の脆弱性に限らず効く対策です。メモリ層の資格情報を専用テーブルへの読み書きだけに絞っておけば、似た欠陥が別のベクトルストア実装に見つかっても被害はメモリ用テーブルの中で止まります。

OSS版とマネージド版の料金・運用負荷の違いと選び分けの判断基準

「OSSだから無料」で見積もると外します。費用は3つの場所に分かれて発生します。

Hobby無料枠1万件からProまでの料金階梯と超過時の課金の考え方

公式の料金ページに掲載されているマネージド版の区分は4つです。Hobbyが無料でメモリ追加10,000件／月・検索1,000件／月、Starterが月額19ドルで追加50,000件・検索5,000件、Proが月額249ドルで追加500,000件・検索50,000件、Enterpriseはカスタムで上限なし。固定プランに合わない利用形態向けに従量課金も用意されています。

数え方の癖に注意がいります。課金単位は「追加リクエスト」と「検索リクエスト」であって、保存されたメモリ件数ではありません。1回の会話ターンごとに add と search を1回ずつ呼ぶ設計なら、月間1万ターンでHobbyの検索枠を10倍超過します。検索枠のほうが先に尽きる構造だと理解しておくと、プラン選定を外しません。

脆弱性対応の観点では、マネージド版はベクトルストアの実装と版管理をmem0側が持つため、今回のような旧版の放置は起こりにくい構成です。その代わりに保存先のリージョンや保持の仕組みを自社で決められないので、どちらの負担を引き受けるかで選ぶことになります。

セルフホスト時に自前で抱えるベクトルDBとLLM費用の内訳と見積り方

OSS版で消えるのはmem0への支払いだけで、内訳の残り2つは残ります。ベクトルストアの実行コスト（Qdrantを載せるコンテナとストレージ）と、抽出・検索で走るLLMおよび埋め込みの従量課金です。

• ファクト抽出：add() 1回につきLLM呼び出し1回（v3でADD-onlyに一本化）
• 埋め込み：抽出されたファクト数だけ text-embedding-3-small を呼ぶ
• 検索：ハイブリッド検索のうちセマンティック側でクエリの埋め込みを1回
• インフラ：Qdrantコンテナ、履歴用SQLiteまたは外部DB、バックアップ領域
• 保守：短い間隔で出る新版とアドバイザリを追い、依存を上げて回帰を確かめる作業

実務でまず効くのは1つめです。add の呼び出し回数がそのままLLM費用になるため、全ターンで add を呼ぶ設計にするか、セッション終了時にまとめて呼ぶかで金額が変わります。まとめて呼ぶ側に倒すのが基本で、リアルタイム性が要件でない限りターンごとの抽出は過剰です。見落とされやすいのは最後の保守で、9月だけで3回の版上げがあったペースを前提にすると、依存更新を月次の定常作業として見積もりに入れておく方が実態に合います。

受託開発でmem0を採用してよい条件と見送るべきプロジェクトの型

ここは判断を書きます。ベンダーの導入事例にも個人ブログにも載らない部分です。

継続対話とユーザー個別の文脈が売上に効く案件という採用の条件

採用してよいのは、次の2つを同時に満たす案件です。同じ利用者が週に複数回戻ってくること。そして「前回の続き」を覚えていることが、利用継続や成約に直接効くこと。社内ヘルプデスク、継続支援型のカスタマーサポート、営業担当ごとの商談支援あたりが該当します。

逆に、記憶が効くかどうかを検証していない段階で基盤から入れるのは順序が違います。まずセッション内の履歴だけで動くものを作り、利用者が同じ説明を繰り返している箇所を実ログで数える。そこに具体的な件数が出てから、メモリ層を足す。この順序であれば、外した場合の損失が設計変更だけで済みます。エージェント本体の実装や既存システムとの接続、依存ライブラリの保守まで含めて相談先を探している場合は、AIエージェント開発の実績と進め方をご覧ください。

単発問い合わせや厳密な監査要件で採用を見送るべき案件の特徴と代替案

見送るべき型は明確です。1つめは、問い合わせが1回で完結し、利用者が二度と戻らないフォーム型の窓口。記憶する相手がいないため、LLM呼び出しが1回増えるだけの構成になります。

2つめは、応答の根拠を1件ずつ提示できなければならない業務です。医療・金融・法務の一部がここに当たります。mem0が返すのはLLMが会話から抽出した二次情報であり、原文の所在が保証されません。根拠提示が要件なら、原典を引くRAG側に寄せて、メモリ層は使わない判断が正解です。

3つめは、エージェント同士が記憶を共有し、階層化された記憶構造を必要とする研究寄りの構成です。この領域はMIRIXのようなマルチエージェント記憶システムが扱う範囲で、mem0の単層のメモリとは設計思想が違います。要件が「エージェント間での記憶の受け渡し」なら、mem0を無理に伸ばさず別基盤を評価してください。

4つめとして、依存ライブラリの版上げを誰も担当できない体制も見送りの側に入れておきます。納品後に保守契約がなく、ロックファイルが固定されたまま何年も動く前提の案件では、今回のCVE-2026-115324のような公表があっても誰も気づきません。メモリ層は利用者の入力を直接溜める部品なので、更新が止まったときの影響が他の依存より大きく出ます。

マルチテナント運用でのスコープ分離とメモリ汚染に備える設計指針

本番で詰まるのは、たいてい機能ではなく境界の設計です。

user_idとagent_idでメモリ空間を分ける設計と越境を防ぐ検証

mem0はメモリを user / session / agent の3階層で扱えます。危ないのは、複数テナントが同じコレクションを共有し、user_id だけで区切っている構成です。filters の指定漏れが1か所あれば、他テナントの記憶が検索に乗ります。

対策は2段構えにします。collection_name をテナント単位で分けて物理的に隔離したうえで、アプリ層では filters を組み立てる関数を1本に集約し、そこを通さない search() の直呼びを禁止する。そして結合テストで、テナントAの検索結果にテナントBの user_id が1件も混ざらないことをアサートしておきます。手で確認する運用にすると、必ずどこかで漏れます。

Databricksのようにテナント間で1つのSQLウェアハウスを共有する構成では、SQLインジェクションが起きた時点でコレクション単位の隔離は意味を失います。テナントごとにスキーマと資格情報を分けておけば、注入されたSQLが届く範囲をそのテナントの中に閉じ込められます。

取り込み経路の人手確認と保持期間を決めるライフサイクル管理の設計

メモリ層への攻撃はすでに研究として複数報告されています。共有メモリ空間へ他者の入力経由で汚染を混ぜる型、外部コンテンツの自動取り込みを通じて偽の前提を植え付ける型、埋め込み空間にバックドアを仕込む型。いずれも「保存する内容を誰も見ていない」ことが成立条件です。手口と防御策の全体像はメモリポイズニングとは？AIエージェントの記憶汚染の手口・事例と防御策に、入口となる指示の乗っ取りはプロンプトインジェクションとは？攻撃例・種類と対策をOWASP LLM01とコードで解説にまとめています。

実務での歯止めは地味な2つに落ちます。外部から取り込んだテキストを無確認で add() に流す経路を作らないこと。そして保持期間を決めて、期限が来た記憶を機械的に消すこと。退会処理で user_id 配下のメモリを削除する導線も、リリース前に必ず通しておきます。後から足そうとすると、どのコレクションに何が残っているか分からなくなります。

メモリポイズニングはLLMの判断を誤らせる攻撃で、CVE-2026-115324は保存処理そのものの欠陥です。層は違いますが、どちらも「記憶の中身は利用者が書ける」という一点から始まっています。保存前の確認と、保存先の権限の絞り込みを両方そろえておくと、片方が破られても被害を止められます。

よくある質問

mem0の導入検討でよく挙がる質問をまとめました。

mem0はOSS版とマネージド版のどちらから始めるべきですか？

検証段階ならOSS版で足ります。pip install "mem0ai[nlp]" だけでローカルのQdrantとSQLiteが自動で用意され、外部サービスはOpenAIだけで動きます。マネージド版を選ぶ理由になるのは、グラフメモリが要る場合と、ベクトルDBの運用や依存の版上げを持ちたくない場合です。Hobbyプランが無料で追加10,000件・検索1,000件まで使えるため、両方を並行して試して比較する進め方も取れます。

mem0とRAGは何が違うのですか？

引いてくる対象が違います。RAGは社内文書や仕様書といった既存のドキュメントを検索して根拠を提示します。mem0が引くのは、その利用者との会話から抽出された事実です。「この人はAWSを使っている」はmem0の領域、「AWSの料金体系はこうなっている」はRAGの領域になります。実務では併用が普通で、mem0で相手の前提を補い、RAGで根拠を出す形に落ち着きます。

v2で書いたコードはv3でそのまま動きますか？

動きません。m.search("query", user_id="alice") の形式は v3 で ValueError になり、filters={"user_id": "alice"} への書き換えが必須です。加えて top_k が100から20へ、threshold が未指定から0.1へ、rerank が有効から無効へ既定値が変わっています。この3つは例外を出さずに結果だけ変えるため、移行時は明示指定で旧挙動を復元してから、段階的に新既定値へ寄せる進め方を推奨します。移行を見送って旧版に留める場合も、1.0.8未満のままにはせず、CVE-2026-115324の修正が入った1.0.8以上へは上げておいてください。この脆弱性はベクトルストアにDatabricksを指定している場合に限られ、GHSAの記載では2.x系を含む1.0.8以上は影響範囲の外です。

グラフメモリはOSS版でもう使えないのですか？

v3のOSS版では使えません。enable_graph と graph_store 設定、Neo4jなど外部グラフDBとの統合は削除され、マネージド版の組み込み機能として再実装されました。検索結果の relations フィールドも返らなくなります。関係性の追跡が要件の中核にあるなら、マネージド版へ移るか、v2系に留めるか、他のメモリ基盤を評価するかの三択になります。

mem0は日本語の会話でも精度が出ますか？

公称ベンチマークのLoCoMo 92.5とLongMemEval 94.4は、いずれも英語の長期対話データセットでの測定値です。日本語での同等の公開値はありません。加えてv3のエンティティマッチングは spaCy の英語モデル（en_core_web_sm）を前提にしているため、日本語の固有名詞は一致シグナルに乗りにくくなります。日本語で使う場合は、自社のログでヒット率を実測してから本番判断にかけてください。

関連記事

• コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いと4つの実装手法：メモリ・RAGを含むコンテキスト全体の組み立て方を扱っています。
• ベクトル検索とセマンティック検索の違い：mem0が内側で使う検索方式の前提を整理しています。
• AIエージェントとは？生成AIとの違い・仕組みと業務に組み込む判断基準を解説：メモリ層を載せる対象であるエージェントの基本を扱っています。
• MIRIXとは何か：マルチエージェント記憶システムの概要：階層化された記憶構造を必要とする場合の比較対象です。
• LangChainでRAGを構築する手順：根拠提示が要件の場合に組み合わせるRAG側の実装手順です。
• メモリポイズニングとは？AIエージェントの記憶汚染の手口・事例と防御策：メモリ層への攻撃手口と防御策を扱っています。
• SQLインジェクションとは？攻撃例と対策を実行結果で解説：CVE-2026-115324の背景にある攻撃の仕組みを確認できます。