AIエージェントに記憶を持たせる企業が知っておきたいOSS「Mem0」の使いどころ

「AIのチャットボットに、利用者ごとの好みを毎回教え直すのが手間だ」「サポートの履歴をAIに覚えさせたいが、どこまで残してよいか決められない」——AIを使った顧客対応や社内アシスタントの検討に入った、情報システムや企画の担当者から出てくる声です。こうした悩みは、会話を長くすれば解決するように見えます。しかし本当の論点は、会話の長さではありません。AIに何を覚えさせ、何を覚えさせないかを、企業が決めているかどうかが分かれ目です。この記事では、AIエージェントに長期記憶を持たせるOSS「Mem0」を取り上げ、仕組みと使いどころ、そして記憶を持たせる前に決めておきたい情報の範囲・保存期間・削除への備えを、一次情報に基づいて整理します。導入や設定の手順は扱いません。

Mem0とは何か。2026年10月時点で確かめられる事実

Mem0は、GitHubで公開されているOSSです。リポジトリの説明ではAIエージェントのための記憶の層とされ、READMEでは「メムゼロ」と読み、AIアシスタントやエージェントに記憶の層を足して、利用者ごとの好みを覚え、対話を続けるとされています。種類としては、AIエージェントに長く使える記憶を持たせるための基盤です。

配布の形を確かめておきます。リポジトリは組織のアカウントで2023年6月20日に作られ、ライセンスはApache-2.0です。2026年10月16日時点でスターは6万7,259、フォークは7,921、最後の更新は同じ日でした。スターの伸びは1日あたり55件ほどで、作成から3年以上がたっています。作者のアカウントは2023年6月19日の作成で、公開リポジトリは12件、フォロワーは1,226人です。個人の試作ではなく、組織として続けられている点が分かります。

提供の形は3つあるとREADMEは説明します。自分のプログラムに組み込むライブラリ、自前のサーバーで動かす形、提供元が運用するマネージドの形です。OSSとして公開されているのは前の2つで、マネージドは別のサービスです。この記事では、公開されている情報から確かめられる範囲を扱います。

なぜ今、AIエージェントの記憶が注目されるのか

論文は問題意識をはっきり書いています。大規模な言語モデルは、文脈として一度に扱える長さに限りがあり、長い対話や複数回にわたるやり取りを通して一貫性を保つのが難しいとされます。毎回それまでの会話を全部読み込ませれば、費用と待ち時間が膨らみます。

そこで、会話から後で使えそうな情報だけを取り出して保存し、必要なときに必要な分だけ引き出す考え方が注目されています。READMEは、利用者の好みや過去のやり取りを覚えておくことで、同じことを何度も尋ねさせないと説明しています。記憶は、AIを賢くするというより、同じ前提を何度も言わせないための道具です利用者にとっては待たされないこと、企業にとっては費用を抑えることが狙いです。

利用者が特定できる情報を記憶に残す場合は、利用目的を示し、同意を得る流れも検討が要ります。記憶は、利用者が忘れてほしいと思ったときに消せる状態であることが望ましく、その手段をあらかじめ用意しておくことが、長く使われるサービスの前提になります。

企業にとっての関心は、利便性と統制の両立にあります。記憶が増えれば対応は滑らかになりますが、残る情報が増えるほど、個人情報や機密の扱い、古い誤情報が混ざる危険も増えます。何を覚えさせ、いつ消すかを先に決めておくことが、導入の前提になります。

記憶をためて引き出す仕組みの考え方

公式ドキュメントによると、Mem0はアプリとモデルの間に立ちます。アプリが会話のやり取りを渡すと、Mem0はそこから後で使えそうな事実を取り出して保存し、次のモデル呼び出しの前に問い合わせて、関係する記憶を返します。どの記憶をAIへの指示に混ぜるかは、アプリ側が決めます。

保存の流れは4段とされます。まず関連する既存の記憶を確認し、次に言語モデルが好みや決定、予定などを事実として取り出し、重複を除いて意味を数値化し、最後に登場する人物や組織、概念を取り出します。会話そのものではなく、取り出した事実を保存するのが既定です。

引き出しのときは、意味の近さ、語句の一致、実体の重なり、時間の手掛かりを組み合わせて順位づけするとされます。何を覚え、どう引くかの設計が、そのまま結果の質を決めますなお、OSS版はマネージド版にある関係をたどる記憶の仕組みを持たないと明記されています。自前で動かす場合は、その分を別の工夫で補う必要があります。

記憶は、用途に合わせて複数の置き場に分けて保存されるとされます。事実と付随する情報は、後から取り出して直せる形で残り、意味を数値化したものは近さの計算のために別に持ち、登場する人物や組織の情報は、問い合わせの精度を上げるために使われます。自前で動かす場合は、これらの置き場を自分で選び、運用することになります。

主な機能1：記憶の追加と、古い情報の扱い

公式ドキュメントは、自動の取り込みは追加型だと説明します。利用者が引っ越したと話しても、古い事実を黙って書き換えず、新しい事実を足す形になります。訂正や削除は、明示的な操作で行うとされています。

READMEは2026年4月の新しい記憶の仕組みとして、1回の呼び出しで追加だけを行う方式を挙げ、記憶が積み上がる一方で上書きされないと説明しています。古い情報が残ることを前提に、運用を組む必要があります。「覚えている」と「正しい」は別です古い記憶は、訂正されるまで繰り返し読み出されます。

追加型であることは、かえって扱いやすい面もあります。過去の事実を消さずに残すため、判断の履歴をたどりやすく、あとから人が確認して訂正する運用とも相性がよいとされます。一方で、訂正の工程を省くと、誤りがそのまま残り続けます。

また、会話をそのまま残したい場合は、事実への取り出しを止めて元の内容を保存する指定があるとされます。用途によっては、要約するより原文を残したいこともあります。どちらの方式を選ぶかも、残す情報の範囲を左右する判断です。

主な機能2：利用者ごと・場面ごとに記憶を分ける

ドキュメントは、記憶を利用者、場面、エージェントなどの単位で分けられると説明します。検索のときに必ずこれらの条件で絞るよう、注意を促しています。これを怠ると、別の利用者の記憶が混ざる恐れがあります。

記憶の分離は、企業にとって最も重要な統制点です。顧客対応の場面で、ある利用者の情報が別の利用者への回答に混ざれば、それ自体が事故になります。ドキュメントも、利用者や場面の識別子で必ず絞るよう繰り返し書いています。

メタデータには、部署や用途、データの出どころといった区分を持たせられるとされます。あとから「この記憶はどの区分のものか」をたどれるようにしておくことが、削除や点検の前提になります。記憶を分ける設計が、そのまま説明責任を支えます分離の単位は、導入の最初に決めておきたい設計の一つです。

記憶の分離は、検索の条件だけでなく、保管の単位でも考えます。ある用途の記憶を別の用途から見せないようにするには、保管そのものを分ける設計が有効とされます。分離の粒度を細かくしすぎると運用が重くなるため、事故が起きたときの影響の大きさを基準に決めます。

想定される使い方と使う場面

READMEが挙げる用途は、AIアシスタントの一貫した対話、顧客対応での過去のやり取りの参照、医療での利用者ごとの履歴、仕事の効率化やゲームでの適応的な動きです。いずれも、利用者と長く付き合う場面です。一度きりの問い合わせより、続く関係のなかで効果を発揮します。

使い方の型は2つと説明されています。役に立ったやり取りの後に記憶を追加し、モデルに尋ねる前に記憶を引き出して指示に混ぜる、という流れです。この2か所をアプリのどこに置くかを決めることが、設計の中心になります。

導入の形は、試作ならライブラリ、チームで自前の設備に置くなら自前サーバー、運用を任せるならマネージドと整理されています。自前で持つか、任せるかで、守りの責任の置き場所が変わりますこの選択は技術の好みではなく、どの情報を誰の管理下に置くかの判断です。

READMEは、外部の対話サービスに記憶を持ち込む例や、複数の開発部品と組み合わせる例も挙げています。利用者が普段使う道具に記憶を足せる一方で、記憶の渡し先が増えることを意味します。どの道具に記憶を渡すかを決めることも、導入時の判断になります。

似た手段と比べた違い

記憶を持たせる方法は、Mem0だけではありません。ここでは、公式ドキュメントと論文で示された違いを整理します。比べる相手は、毎回それまでの会話を全部読み込ませる方式です。

観点	会話を全部読ませる方式	記憶の層を使う方式
扱う情報	会話の全文	取り出した事実と付随する情報
費用と待ち時間	会話が長いほど増える	必要な分だけ引くため抑えやすい
続けたときの一貫性	文脈の長さに左右される	記憶として持ち越せる
個人情報の扱い	全文に含まれやすい	何を残すか選べる分、決めることも増える
導入の主な手間	比較的小さい	記憶の設計と点検が必要

論文は、全会話を読ませる方式に比べて待ち時間と費用を大きく抑えたと報告しています。ただし、公表の数値は提供元またはその協力者が測ったものです。READMEは、数値がマネージド版の最適化を含み、OSS版では同じ数値にはならないと明記しています。

比較の数値だけで導入を決めず、自社のデータで確かめます表は方向づけのための整理であり、成績の保証ではありません。自社の業務でどの種類の記憶が必要かを、検証用のデータで見てから判断します。

公開された評価の数字をどう読むか

READMEは2026年4月の新しい記憶の仕組みについて、公開の評価での改善を数値で示しています。対話の長期記憶を測る公開の評価で、以前の方式から大きく伸びたとされ、複数の評価で高い値を挙げています。

ただし、この数値の読み方には注意が要ります。README自身が、評価は提供元のマネージド版で測ったもので、OSSには無い最適化を含むと明記し、OSS版では同じ方向の改善は見込めるが同じ数値にはならないとしています。つまり、公開のスコアは、自前で動かす構成の成績をそのまま保証するものではありません。

論文はまた、全会話を読ませる方式に比べて、費用と待ち時間の両方を抑えたと報告しています。会話が長くなるほど、この差は大きくなるとされます。ただし、これも提供元の測定条件での結果です。自社の対話の長さや言語で同じ傾向になるかを、確かめる必要があります。

また、評価を確かめる枠組み自体は公開されているとされますが、測った主体は提供元側です。提供元の数値は出発点として見て、自社のデータで確かめますテスト用の質問と自社の業務では、必要になる記憶の種類も違います。

安全性の評価：紹介可とした根拠

このラインでは、紹介するOSSを、公開されている事実だけをもとに精査しています。OSSをダウンロードしたり動かしたりはしていません。Mem0の判定は「紹介可」です。

根拠にした事実は次のとおりです。組織のアカウントで2023年6月に作られ、公開リポジトリを12件持ち、作ったばかりの使い捨てのアカウントではありません。スターの伸びは1日あたり55件ほどで、不自然な水増しの兆候は見られませんでした。GitHub上にこのリポジトリのセキュリティ勧告は登録されておらず、ライセンスはApache-2.0です。リポジトリの直下には、取り込み時に自動で動く処理を含むファイルは見当たりませんでした。

なお、ここで問題が見つからなかったことは、安全の保証ではありません。この精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。導入するかどうかは、自社の確認の手順に沿って判断してください。

導入前に知っておきたい注意点

紹介可とはいえ、一次情報を読むと気になる点もあります。一つ目は、既定の構成が外部のAIサービスに依存することです。OSS版の既定では、事実の取り出しにも、意味の数値化にも、外部のモデルを使い、そのための鍵を設定する必要があるとドキュメントは説明しています。記憶の中身が、事実の取り出しのために外部へ送られる経路があります

二つ目は、マネージド版とOSS版で機能に差があることです。関係をたどる記憶の仕組みはマネージド版にあり、OSS版には無いとドキュメントは明記しています。READMEの評価の数値もマネージド版のものです。「OSSだから自前で完結する」と単純には言えず、どの処理をどこで動かすかを構成で決める必要があります。

三つ目は、記憶の保管先を自分で選ぶ必要があることです。試作では手元のファイルに保存する構成が既定とされますが、本番では自前のデータベースに置く構成も選べます。保管先が増えるほど、暗号化や権限、保存期間の管理の対象も増えます。

悪用されうるリスク

Mem0は守りのための道具ではありませんが、使い方しだいで生まれうる危険があります。最も大きいのは、覚えさせた情報が、そのまま漏えいの対象になることです。記憶には利用者の好みや、場合によっては取引先や契約の話が入りえます。保管先が破られれば、会話を全部残す場合と同様に、あるいはそれ以上に整理された形で情報が持ち出されます。

次に、推測であることを断ったうえで挙げます。外部から届いた文章に紛れ込んだ命令でAIを操る攻撃では、記憶への書き込みを狙う経路が考えられます。ドキュメント自身が、秘密の値や認証情報、伏せていない機微な情報を記憶させないよう注意を促しています。記憶は後で引き出すための情報であるため、書き込まれた誤りや悪意ある内容が、その後も繰り返し読み出されうる点が、通常の入力より厄介です。

また、別の利用者の記憶が混ざる設定の誤りは、情報の取り違えとして現れます。ドキュメントが検索の条件づけを繰り返し求めているのは、この事故が起きやすいことの裏返しと考えられます。なお、本記事の執筆時点で、Mem0の悪用事例は一次情報からは確認できませんでした。

記憶に残す情報の範囲をどう決めるか

ここからは、企業の守りに関わる論点です。AIに記憶を持たせるとき、最も基本的な決め事は、何を残してよいかの線引きです。ドキュメントは、好みや決定、予定、目標など、後で使い回せる情報を記憶の対象とし、秘密の値や認証情報、伏せていない機微な情報は避けるよう勧めています。

大切なのは、この線引きを道具に任せず、用途ごとに人が決めることです。顧客対応、社内の問い合わせ対応、開発の補助では、扱う情報の種類が違います。用途ごとに、残してよい情報、残す前に伏せ字にする情報、そもそも記憶させない情報の三段階に分けると、運用しやすくなります。

個人情報や機密は、記憶に入れる前の段階で減らします取り込む前に余計な情報を落とせば、あとから消す手間も、漏えいしたときの影響も小さくなります。AIに事実を取り出させるときも、その結果をそのまま保存せず、決めた区分に当てはまるかを点検する工程を挟むことが有効です。

記憶として要約せず、元の文章のまま残す指定も選べます。原文を残せば、あいまいな表現もそのまま保てますが、その分だけ個人情報や機密がそのまま入りやすくなります。要約するか原文のままかは、用途ごとに、残す情報の範囲とあわせて決めます。

保存期間と削除の要求への対応

次に決めるのは、いつまで残すかです。記憶は追加型で積み上がるため、放っておくと古い情報が残り続けます。古い誤情報は、訂正されないまま繰り返し読み出されると、判断を誤らせます。残す期間と、見直す時期を先に決めます種類ごとに期間を変えるのも有効です。

削除については、ドキュメントが明示的な削除の操作を用意していると説明しています。ただし、記憶は事実として要約されているため、利用者本人が「これを消してほしい」と頼んだときに、どの記憶がそれに当たるかを人が確かめられるようにしておく必要があります。削除は道具の操作だけで完結せず、対象の特定と確認の手順が要ります。

開示や訂正の求めに応える前提として、どんな情報が記憶に入っているかを一覧できる状態にしておくことが役立ちます。ドキュメントは、記憶を利用者や用途ごとの区分で絞り込む考え方を示しています。区分を丁寧に付けておけば、ある利用者やある案件の記憶をまとめて取り出すことがしやすくなります。

導入を検討するときに確かめること

導入の検討では、機能の多さより先に確かめたい点があります。下の手順は、OSSを動かす前の段階で、資料と社内の取り決めによって確かめられることに絞っています。

この手順の要は、道具を入れる前に、何を覚えさせないかを決めておくことです。記憶は入れた瞬間から増え始めます。残さない基準を先に決めておかないと、あとから減らす作業のほうが重くなります。

企業が取るべき対策

五つの対策を挙げます。一つ目は、AIに記憶を持たせる用途を、既存の情報管理の対象として明示することです。記憶は新しい種類のデータ置き場であり、資産の一覧に載っていなければ漏れます。記憶の保管先を、情報資産の台帳に加えます。

二つ目は、記憶を分離する設計の徹底です。利用者や場面ごとに記憶を分け、検索の条件づけを運用で守ります。三つ目は、監査の記録です。ドキュメントは、自前サーバーで動かす形に、利用者ごとの鍵と要求の監査ログが含まれると説明しています。誰がどの記憶を読み書きしたかを、後からたどれるようにしますマネージド版も監査ログと権限の統制を備えるとされます。

四つ目は、外部への送信の把握です。記憶の作成や検索には、外部のモデルを使う構成があります。どの用途で何が外に出るかを一覧にします。五つ目は、調達と保守の確認です。配布元、ライセンス、更新の状況、脆弱性の報告の窓口を、導入前に文書で確かめます。

加えて、記憶を扱える人を絞ることも欠かせません。記憶の閲覧や削除ができる権限は、業務上必要な人に限ります。運用の担当者が替わるときに、記憶の扱いの決まりを引き継ぐ手順も用意しておくと、属人化を避けられます。

AIに任せる範囲と、人が決める範囲

Mem0は、会話から事実を取り出す処理をAIに任せます。取り出しの判断がなぜそうなったかは、人には見えにくくなります。何を記憶させないか、いつ消すか、誰の記憶かを分ける基準は、AIに決めさせず人が先に決めます。

やってはいけない向き合い方を挙げます。

• 機密や個人情報を、そのまま記憶させてよい情報として扱う
• 記憶を利用者や場面で分ける条件を決めないまま使い始める
• 古い記憶を訂正せず、そのまま残し続ける
• 削除を求められたときに、どの記憶かを人が確かめずに操作するだけにする
• 公開の評価の数値を、自社での確認を省いて導入の根拠にする
• 記憶の保管先を、情報資産の一覧に入れないままにする

裏を返せば、人が決める範囲ははっきりしています。何を覚えさせないか、いつ消すか、誰のものかを分ける基準、という三つですAIに任せてよいのは、人が決めた範囲の中で、会話から候補を取り出す部分です。取り出した結果が基準に合うかを確かめる工程も、人が用意します。

• Mem0の機能・構成・評価の数値は、GitHubのリポジトリとREADME、公式ドキュメント、論文を2026年10月16日に確かめた範囲に基づきます。内容は変わる可能性があります
• 公開の評価の数値は、提供元が測ったものです。README自身が、マネージド版の最適化を含むため、OSS版では同じ数値にはならないとしています
• この記事は防御と評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Mem0は、AIエージェントやアプリに長期記憶を持たせるOSSです。会話をそのまま保存するのではなく、後で使えそうな事実を取り出して保存し、必要なときに引き出します。利用者や場面ごとに記憶を分けられ、ライブラリ、自前サーバー、マネージドの三つの形で使えます。組織として3年以上続けられ、ライセンスはApache-2.0です。

一方で、記憶を持たせるということは、残す情報を増やすということでもあります。個人情報、機密、古い誤情報が記憶に残り、それが繰り返し読み出されます。何を覚えさせないか、いつ消すか、誰の記憶かをどう分けるか、外部へ何が送られるか。これらは道具ではなく、企業が先に決めることです。

公開の評価の数値は提供元のものであることも踏まえ、自社のデータで確かめてから判断します。記憶を便利に使うほど、覚えさせない情報を決める力が問われます。それが、AIエージェントの時代に記憶と付き合う基本になります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。