Mem0とは？料金と使い方、OSSの違いを解説

2026年9月21日

公開日: 2026年9月21日

公式ドキュメント・公式発表などの一次情報を確認したうえで、株式会社Nexaが執筆・更新しています。AIツールの仕様や料金は変わることがあるため、導入判断の前に各公式サイトの最新情報もご確認ください。運営会社について

Mem0はAIアプリに長期記憶を加える仕組みであり、企業導入では費用、保存データ、利用者分離、削除制御の4項目から運用方法を選びます。

提供形態：自社で運用するOSSと、提供元が基盤を管理するPlatformがあります。
料金：Platformには無料枠があり、追加と検索の月間リクエスト上限は別々です。
安全管理：利用者ごとに検索範囲を限定し、誤った記憶の訂正と削除確認も設計します。

対象読者：AIアプリ導入を検討するDX推進担当者と開発責任者

今日やること：試す業務を1つ選び、保存する情報と削除条件を書き出す。

この記事の著者

株式会社Nexa 代表取締役川島陸

一橋大学経済学部卒業後、フォーティエンスコンサルティング株式会社（旧株式会社クニエ）にて法人向けAI導入支援等を経験。独立後、AI系メディア運営やDify/n8nの導入支援を経て、株式会社Nexaを創業。法人向けAI研修・AI導入支援・AI関連メディア運営を手掛ける。

詳しく見る AI顧問の無料相談

Mem0は、AIアプリが次の会話でも使う情報を保存し、必要なときに取り出すための仕組みです。毎回すべての会話を送り直す代わりに、利用者の好みや継続中の作業に関する情報を回答へ反映できます。

ただし、覚えられる情報が増えるほど、誰に見せていつ消すかも決める必要があります。公式情報を基に、料金、使い方、OSSとPlatformの違いから、保存と削除の設計まで整理します。仕様と料金の確認日は2026年9月21日です。

Mem0とはAIアプリに長期記憶を加える仕組み

Mem0は会話から再利用する情報を保存する部品であり、回答を生成するAIモデルそのものとは異なります。

AIアプリで過去のやり取りを次回にも生かすには、その情報を保管する場所と、必要な部分を取り出す処理が必要です。Mem0はこの役割を担うメモリ層です。ここでのメモリはパソコンの作業用メモリではなく、会話をまたいで参照する記録を意味します。

たとえば「報告は箇条書きがよい」という好みを保存すれば、後日の報告作成にも参照できます。これは仕組みを説明するための想定例であり、特定企業の導入実績ではありません。

Mem0の公式GitHubではソースコードが公開されています。一般利用者向けの完成したチャット画面と考えるより、自社アプリに組み込む機能として検討すると役割を理解しやすくなります。

Mem0は追加と検索をどう組み合わせるか

Mem0では追加時に記憶を整理し、回答前に関連情報を検索します。検索結果を回答へ渡すのはアプリ側です。

Mem0で会話から記憶を保存し、関連情報を検索して回答に使う処理の流れ 図1: 保存と検索を分け、回答に使う記憶をアプリ側で選びます。

公式の処理フローは、記憶の書き込みと読み出しに分かれます。addは情報の追加、searchは関連する記憶の検索を行う操作です。基本の流れは次のとおりです。

保存する価値がある会話をaddへ渡します。
再利用できる事実を抽出し、重複を整理して保存します。
新しい質問に対してsearchで関連する記憶を探します。
アプリが必要な記憶を選び、回答を作るモデルへ渡します。

抽出には大規模言語モデル（LLM）を使います。文章を読み、好みや決定事項などを取り出すモデルです。検索では、文章の特徴を数値の並びに変える埋め込みなどを利用します。言葉が完全一致しなくても、意味が近い記憶を探すための表現です。

まず「どの会話を追加し、どの質問で検索するか」を図にすると、組み込む場所を決められます。

＼ AI導入の進め方を一緒に整理しませんか／

AI顧問の無料相談はこちら

RAGや会話履歴とは何が違うか

Mem0とRAGは排他的な選択肢ではありません。元の会話、社内資料、利用者の記憶を目的に応じて使い分けます。

RAG（検索拡張生成）は、関連情報を検索し、その内容をモデルに渡して回答を作る方式です。たとえば社内規程の該当箇所を探し、根拠付きで説明させます。Mem0の記憶検索も、検索した情報を回答へ渡す設計と組み合わせられます。

対象	主な役割	想定例
元の会話履歴	発言の順序や表現を記録する	問い合わせ時の説明を確認する
文書を使うRAG	資料を検索して回答根拠にする	旅費規程の条件を調べる
Mem0の記憶	再利用する事実や好みを取り出す	出張手配時の座席の好みを参照する

規程と好みが食い違う場合、好みを理由に規程を変えることはできません。情報源ごとの役割と優先順位を決めて併用します。文書検索の詳しい設計は、RAGとは？仕組み・メリット・導入方法【2026年】でも解説しています。

AI導入に関するお困りごとは、株式会社NexaのAI顧問がサポートします。「何から始めればいいか分からない」という段階からご相談いただけます。

AI顧問の無料相談はこちら →

OSSとPlatformは運用責任で選ぶ

OSSは自社で構成と運用を管理し、Platformは提供元の基盤を利用します。費用だけでなく管理範囲が違います。

OSSは、公開されたソースコードをライセンスに従って利用できるソフトウェアです。Mem0はApache 2.0ライセンスで公開されています。Platformは、Mem0が運用するサービスを呼び出す形態です。

公式のPlatformとOSS比較を基に、導入判断で使う違いを整理します。

比較軸	OSS	Platform
動かす場所	自社が選ぶ環境	Mem0が管理する基盤
モデルや保存先	自社で選定、設定、運用	基本の記憶処理は提供元が管理
費用の考え方	モデル、保存基盤、運用工数	契約プランとアプリ側の費用
データ管理	接続先を含め自社で設計	契約条件と提供機能を確認
更新や障害対応	自社の担当範囲が広い	サービスとの責任分担を確認

OSSには、アプリ内で使うライブラリとセルフホストサーバーがあります。ライブラリはプログラムから呼ぶ部品です。サーバーは処理を受け付けるサービスとして動かします。両者の画面や認証機能を同じものとして比較しないでください。

＼業務自動化のお悩みをAI顧問に相談できます／

AI顧問の無料相談はこちら

Mem0 Platformの料金と無料枠

Platformには無料枠がありますが、追加と検索の月間上限は別です。利用人数だけでは費用を判断できません。

公式料金ページの2026年9月21日時点の表示は次のとおりです。Mem0 Platformの公開プランであり、連携サービス経由の契約条件と同一とは限りません。

プラン	月額の表示	追加リクエスト／月	検索リクエスト／月	プロジェクト数
Hobby	無料	10,000	1,000	1
Starter	19米ドル	50,000	5,000	1
Pro	249米ドル	500,000	50,000	無制限
Enterprise	個別見積もり	無制限	無制限	無制限

リクエストはサービスへの処理要求です。1回の追加で複数の記憶が抽出されることもあり、追加リクエスト数を保存できる記憶の件数と読み替えることはできません。無料枠でも検索を頻繁に行う設計なら、検索側の上限が先に判断材料になります。

料金ページにはProのGraph Memoryなども掲載されていますが、機能説明だけで全プラン利用可能とは判断しません。超過時の単価、税、保存容量など、表にない条件は契約前に確認してください。

OSSでもモデルと運用の費用はかかる

OSSのライセンス料がなくても、モデル利用、データ保存、保守には費用が生じます。月額ゼロとは限りません。

OSSの公式概要では、ライブラリの既定構成にOpenAIのモデルと埋め込みを使用すると説明されています。ローカルへインストールしても、外部モデルを呼ぶ設定なら、その利用条件と料金を別途確認する必要があります。

見積もりでは、記憶の抽出と検索にかかる費用、最終回答を生成する費用、保存基盤の費用を分けます。Platformでも、自社アプリの最終回答に使うモデルの費用まで含まれると考えない方が安全です。

ローカルモデルでも計算資源と保守の負担は残ります。価格比較にはバックアップ、更新、障害対応の運用工数も加えましょう。

＼ AI活用の「次の一手」を一緒に考えませんか／

AI顧問の無料相談はこちら

保存される記憶と元の会話を区別する

Mem0の既定動作で保存する記憶は、会話から抽出した事実です。元の会話や周辺ログの保存とは分けて確認します。

公式説明では、通常の記憶は逐語録ではありません。たとえば「報告は短い箇条書きでお願いします」という入力から、報告形式の好みを取り出します。一方、infer=Falseという指定では、渡した内容をそのまま保存する使い方もあります。

記憶には本文のほか、利用者IDや作成時刻などのメタデータが関わります。メタデータは記録に付ける補助情報で、検索範囲や整理に使います。意味検索用の埋め込みや、変更履歴も管理対象です。

さらに、元の会話がアプリのログや監視サービスに残るかは別問題です。OSSでも、保存先だけでなくモデルへ送る経路を含めて確認してください。「自社サーバーに置いたから外部送信はない」とは限りません。保存場所と送信先を別の欄にして整理すると見落としを減らせます。

保存してよい情報を先に決める

記憶する情報は再利用する目的に必要な範囲へ絞ります。秘密情報を除き、期限がある情報は削除条件も決めます。

公式の処理フローでも、秘密情報や認証情報を保存しないよう案内されています。以下は企業向けの設計例です。製品が自動でこの分類を実施するという仕様ではありません。

分類	想定する情報	運用の例
継続して使う	回答の長さや形式の好み	本人が確認、訂正できるようにする
期限を設ける	一時的な作業の希望条件	作業終了時の削除担当を決める
原則として保存しない	パスワード、秘密鍵、不要な個人情報	Mem0へ送る前に除外する

一度だけの旅行先を居住地として保存すると、提案がずれます。実データを使う前に、架空の好みや作業条件で分類を試してください。

user_idで利用者を分けても認可は必要

利用者ごとの検索条件とアプリの権限確認は別の役割です。user_idだけで安全な分離が完成するわけではありません。

Platformの識別子の公式説明では、user_idは利用者、agent_idはエージェント、run_idは一連の処理を区別します。Platformにはアプリや提供先を分けるapp_idもあります。OSSに同じ識別子がすべてあるとは限りません。

認可は、本人がアクセスできる情報や操作を確認する処理です。ログインした本人を確かめる認証とも区別します。利用者が送ったIDをそのまま信頼すると、他人のIDへ差し替えられる設計になりかねません。

アプリのサーバー側でログイン情報から検索範囲を決め、保存、検索、一覧、削除のすべてで同じ規則を適用します。会社別に提供するなら会社の境界も必要です。検証では利用者Aの記憶が利用者Bの検索結果に含まれないことを、回答生成より前の段階で確認します。

古い記憶は明示的に更新する

新しい会話を追加しても古い記憶が必ず訂正されるとは限りません。業務上の変更は更新や削除を明示して扱います。

現行の公式説明では、自動抽出の基本経路は追加型です。転居の発言から新しい住所に関する事実を保存しても、以前の情報を黙って書き換えるとは限りません。修正が必要な場面ではupdateやdeleteを使うよう案内されています。

業務で「担当部署が変わった」という情報を扱う場合、古い部署を履歴として残すのか、現在の所属だけ参照させるのかを先に決めます。新旧両方を検索結果に渡せば、モデルが古い方を使う可能性があります。

保存した記憶に出典と確認時点を結び付け、訂正後に同じ質問を再度試してください。Platformの追加機能による整理と、基本の追加操作を混同せず、自社が使う経路で期待する変更を確かめます。

削除は対象の指定と完了確認まで行う

削除は対象を限定して実行し、処理後に対象記憶が残っていないかを確認します。ログやバックアップも別に管理します。

Mem0の記憶を対象範囲を限定して削除し、一覧や記憶IDで完了を確認する手順 図2: 権限と対象範囲を確かめ、削除の完了まで確認します。

公式の削除ガイドには、記憶IDを指定する削除や、利用者などで範囲を指定する削除があります。記憶IDは保存された各記録を識別する値です。1件の訂正と、退会時の全記憶削除では、必要な対象範囲が違います。

Platformの一括削除APIは、少なくとも1つのフィルターを要求します。全体を指す指定を通常処理へ混ぜず、削除対象を事前に一覧で確かめる設計にします。

本人と削除権限を確認し、対象IDを確定します。
対象を限定した削除を実行し、処理状態を確認します。
一覧や記憶IDで削除を確認し、別の利用者の記憶が残ることも確かめます。

エンティティ削除のように非同期で進む処理もあります。成功応答を受けた瞬間に完了したとは判断できません。また、意味検索で出ないだけでは削除の証明にならないため、一覧なども使います。アプリのログやバックアップの扱いは、それぞれの保存方針で確認します。

PlatformをPythonで試す最小手順

PlatformはAPIキーを用意し、追加と検索を試すところから始められます。最初は実在人物の情報を使わず検証します。

APIは、プログラムから別のサービスを呼ぶ窓口です。APIキーはその利用を認証する秘密の値で、公開コードやブラウザーへ埋め込みません。公式Quickstartでは、Python 3.10以上とMem0のアカウント、APIキーを前提にしています。

開発用のPython環境で、pip install mem0aiにより公式SDKを導入します。SDKはAPIを使いやすくするプログラム部品です。以下は公式の呼び出し方に沿った最小例であり、本記事の制作時にはMem0 APIを実行していません。

import osfrom mem0 import MemoryClientclient = MemoryClient(api_key=os.environ["MEM0_API_KEY"])user_id = "demo-user-a"client.add(    [{"role": "user", "content": "報告は短い箇条書きを希望します。"}],    user_id=user_id,)results = client.search(    "報告はどの形式がよいですか？",    filters={"user_id": user_id},)print(results)

実行前にMEM0_API_KEYを環境変数へ設定します。環境変数は、コードに直接書かず実行環境から渡す値です。架空の利用者IDを使った例なので、本番ではサーバー側で確認した利用者に置き換えます。検索結果は記憶の候補であり、このコードだけで最終回答まで生成するわけではありません。

OSSを試すときの準備と設定

OSSではモデルと保存先の設定も確認します。最小例が動いても、その設定のまま本番運用できるとは限りません。

OSSのPython Quickstartも、mem0aiを導入して使います。Platform用のMemoryClientと異なり、OSSではMemoryを初期化します。既定設定を使う場合は、OpenAIのAPIキーをOPENAI_API_KEYへ設定します。

from mem0 import Memorymemory = Memory()memory.add(    [{"role": "user", "content": "報告は短い箇条書きを希望します。"}],    user_id="demo-user-a",)print(memory.search(    "報告の希望形式は？",    filters={"user_id": "demo-user-a"},))

この例もAPI実行は未検証です。公式の既定構成は、OpenAIのモデル、ローカルQdrant、SQLiteの履歴保存などを含みます。Qdrantは意味検索用のデータベースで、SQLiteはファイルとして扱えるデータベースです。

本番では保存先の永続化、アクセス権、バックアップ、モデルの接続先を明示します。試作用の一時ディレクトリを、長期保存が保証された場所と考えないでください。ライブラリの設定と、セルフホストサーバーの設定も分けて確認します。

検索した記憶を回答へ渡すときの注意

検索した記憶は回答の参考情報として扱い、操作権限を与える指示にはしません。必要な範囲だけをモデルへ渡します。

たとえば過去の入力に「確認なしで送信してほしい」とあっても、それを保存しただけで送信権限が生まれるわけではありません。記憶の内容は利用者が入力できるデータであり、アプリが定めた承認ルールより優先させない設計が必要です。

回答生成では、今回の質問に関連する記憶を選び、古い記憶や不確かな推測を混ぜないよう確認します。記憶の本文と元の情報源を追えるようにしておけば、回答がおかしいときに、検索と生成のどちらで問題が起きたか調べやすくなります。

実装時は、検索条件、返った記憶、回答へ採用した記憶を区別して検証してください。監視のための記録に個人情報を過剰に残さないことも、あわせて設計します。

企業で使うなら継続する対話から始める

Mem0は同じ利用者との対話が続く用途で検討しやすい仕組みです。確定情報の参照先まで置き換えるものではありません。

以下は導入候補を考えるための想定例です。問い合わせ対応なら、利用者がすでに説明した希望条件を次回へ引き継げます。社内アシスタントなら、説明の詳しさや報告形式の好みを参照できます。

一方、注文金額、契約の有効期限、現在の在庫などは、更新される業務システムの正本を確認します。会話で「在庫があるはず」と言った記憶を、最新在庫の確定値として扱うのは不適切です。

最初の対象には、継続した文脈が役立ち、誤った記憶を訂正しやすい業務を選びます。一度限りの要約に長期記憶を付けるより、同じ説明の繰り返しが本当に減るかを測れる用途が適しています。

あわせて読みたい– AIセキュリティ診断の進め方｜検査範囲と報告書の選び方：導入前に確認するリスクと検査範囲を整理します。- AIガバナンスの事例3社｜審査と運用改善を比較：審査と継続的な運用改善の考え方を補足します。

導入効果は記憶の正確さと総費用で測る

効果検証では回答の便利さだけでなく、記憶の正確さ、分離、削除、待ち時間、総費用を同じ条件で比較します。

以下は評価の提案であり、実測結果ではありません。同じ質問セットを用意し、記憶なしと記憶ありで比較します。情報が変わる前後の質問も入れると、保存できたことだけで成功と判断するのを避けられます。

評価項目	確認する内容
抽出の正確さ	発言にない好みや属性を作っていないか
検索の有用性	回答に必要な記憶を取得できたか
利用者の分離	他人の記憶が検索結果に出ないか
訂正と削除	古い条件や削除対象を再利用しないか
応答時間	記憶検索を加えた待ち時間は許容範囲か
総費用	記憶処理と回答生成、運用を含めて妥当か

公式の性能紹介があっても、自社業務の削減率を保証するものではありません。まず合格条件を決め、検索に失敗した質問も記録します。正解した例だけで採用を決めないことが、運用負担の見積もりにつながります。

検索できないときの確認ポイント

記憶が見つからないときは、モデルの性能を疑う前に、保存結果と識別子、検索条件、SDKの版を確認します。

Platformでは、既定の抽出経路で利用者の発言とアシスタントの発言が別の識別子に帰属します。user_idとagent_idを両方指定して追加しても、各記録に両方が入るとは限りません。両者の一致を同時に求めるAND検索では、結果が空になる場合があります。

症状	最初に確認する点
追加後に見つからない	記憶が実際に抽出されたか、処理が完了したか
特定の利用者だけ空になる	保存時と検索時のIDに違いがないか
条件を足すと空になる	そのフィールドが記録に存在するか
古いサンプルが動かない	使用中のSDKと現行公式例の引数が一致するか

調査のために本番の利用者フィルターを外すのは避けます。隔離した検証データで条件を確かめ、意図した範囲を保ったまま修正してください。結果が空であることを、記憶が削除された証拠にも使わないよう注意します。

本番導入前に確認したいチェックリスト

本番導入は機能の動作だけで決めず、費用とデータ管理の条件をそろえます。未確認事項には担当者と期限を置きます。

Mem0を本番導入する前に確認する利用目的、費用、保存先、権限、削除の運用条件 図3: 利用目的から訂正・削除まで、運用条件をそろえて判断します。

項目	決めておくこと
利用目的	何を覚えると、どの業務が改善するか
費用	追加と検索の量、モデル料金、保守の負担者
保存と送信	元会話、記憶、ログ、バックアップの所在
契約	保存地域、再委託、学習利用、削除と保持の条件
権限	本人確認、会社別の境界、操作ごとの認可
訂正と削除	申請窓口、実行担当、完了確認の方法
障害対応	記憶検索が使えないときの動作と連絡先