AIエージェントのメモリ基盤にSupermemoryが選ばれる理由｜Mem0との違い

AI エージェントや LLM アプリを開発していると、必ず突き当たるのが「会話をまたぐと AI がすべてを忘れる」という壁です。前回のやり取りも、ユーザーの好みも、プロジェクトの文脈も、新しいセッションでは白紙に戻ってしまいます。

この課題を解決する手段として「メモリ層」を専用基盤に任せる選択肢が注目されており、Mem0・Zep・Letta といった OSS が次々と登場しています。複数の候補が並ぶと、初めてメモリ基盤を選定するエンジニアにとっては「どれを選べばいいのか」「自社の要件に合うのはどれか」という判断が一気に難しくなります。

本記事では、AI 向けメモリエンジン／メモリ API として高い注目を集める Supermemory（リポジトリ: supermemoryai/supermemory）を、採用判断の観点から深掘りします。何ができる OSS なのか、Mem0 や Zep とどう違うのか、セルフホストは可能か、メンテナンス状況は健全か——こうした「採用候補に残すか外すか」を判断するための材料を整理します。

なお本記事は、公式リポジトリ・公式ドキュメント・サードパーティの比較記事をもとにしたドキュメントベースの紹介です。実際の動作検証は行っていないため、最終的な採用判断は必ず公式ドキュメントと自社環境での検証を併用してください。

Supermemoryとは｜AIに長期記憶を与えるメモリエンジン

Supermemory は、AI が会話のたびに文脈を失う問題を解決する、AI 向けのメモリ／コンテキストエンジンです。公式リポジトリの説明では「Memory engine and app that is extremely fast, scalable. The Memory API for the AI era.（AI 時代のためのメモリ API）」と位置づけられています（出典: supermemoryai/supermemory README）。

会話から事実を自動的に抽出してユーザープロファイルを構築し、時系列での知識の変化や矛盾を扱い、必要なコンテキストだけを LLM に渡す——この一連の処理を担うのが Supermemory の役割です。

Supermemoryが解決する課題

LLM はコンテキストウィンドウの範囲しか「覚えて」いません。長い会話履歴をすべて毎回プロンプトに詰め込めばトークンコストが膨らみ、応答も遅くなります。かといって履歴を切り捨てれば、AI はユーザーの好みや過去の決定を忘れてしまいます。

Supermemory はこの間を埋めるレイヤーです。公式ドキュメントによれば、Supermemory は会話からメモリを自動抽出し、静的な事実（安定した属性）と動的なコンテキスト（直近の活動）を組み合わせたユーザープロファイルを維持し、パーソナライズされた応答に必要なコンテキストを返します（出典: Supermemory Quickstart）。アプリ側は「全履歴を管理する」のではなく「必要な記憶を呼び出す」設計に切り替えられます。

公式リポジトリでは、AI メモリ系の主要 3 ベンチマーク（LongMemEval / LoCoMo / ConvoMem）で 1 位であると主張されており、LongMemEval のスコアは 81.6% とされています（出典: supermemoryai/supermemory README）。これらの数値はプロジェクト側の主張であり、ベンチマークの条件は各社で異なるため、採用判断では数値そのものより「どの軸で強みを主張しているか」を読み取る材料として捉えるのが現実的です。

リポジトリ基本情報とメンテナンス健全性

採用判断で見落とせないのが「このプロジェクトは継続的にメンテナンスされているか」という点です。OSS は活発に保守されていなければ、依存先としてのリスクが高くなります。

（出典: supermemoryai/supermemory、リポジトリメタデータ 2026年6月5日時点）

スター 2.5 万・フォーク 2.2 千という規模に加え、最終更新は当日（記事執筆時点）で、アクティブに開発・保守されている状態です。ライセンスは MIT で、商用利用を含めて比較的自由度の高い条件です。指名検索で記事や解説が一定数ヒットする規模でもあり、「採用候補として情報が集めやすい」点は初見エンジニアにとって安心材料になります。

ただし、後述するようにライセンスが MIT であることと「すべての機能を自前でセルフホストできる」ことは別問題です。この区別が採用判断の核心になるため、のちほど詳しく整理します。

Supermemoryの主要機能とアーキテクチャ

Supermemory は単なる「会話メモリの保存庫」ではなく、メモリ抽出・検索・外部データ連携・マルチモーダル取り込みまでをカバーする広い機能セットを持ちます。自社要件と照らし合わせる際のチェックポイントとして、主要機能を整理します。

メモリの仕組み（抽出・User Profiles・Hybrid Search）

公式リポジトリで挙げられている中核機能は次のとおりです（出典: supermemoryai/supermemory README）。

• Memory Engine: 会話からの事実抽出、時系列の変化や矛盾の解決、期限切れ情報の自動忘却を扱います。
• User Profiles: 安定した事実（静的）と直近の活動（動的）を組み合わせて自動的に維持されるプロファイル。1 回の API 呼び出しで約 50ms で取得できると主張されています。
• Hybrid Search: RAG（ドキュメント検索）とパーソナライズドメモリを統合したクエリ。記憶とドキュメントを同じコンテキストプールで扱える点が特徴です。

RAG だけを使っている開発者にとっては、「ドキュメント検索」と「ユーザー固有の記憶」を別々に管理せず統合的に扱える点が、Supermemory を検討する一つの動機になります。

コネクタとマルチモーダル取り込み

Supermemory は外部データソースとの連携機能を内蔵している点が、他のメモリ OSS との大きな差別化要素です（出典: supermemoryai/supermemory README）。

• Connectors: Google Drive / Gmail / Notion / OneDrive / GitHub を、リアルタイムの webhook で同期します。
• File Processing: PDF・画像（OCR）・動画（文字起こし）・コード（AST 対応のチャンキング）といったマルチモーダルな取り込みに対応します。

「社内ドキュメントやメール、Notion の情報をまとめて AI の記憶に取り込みたい」というユースケースを内蔵機能でまかなえるかどうかは、自作の取り込みパイプラインを組む工数を大きく左右します。ここは類似 OSS との比較で重要な論点になります。

MCP・フレームワーク連携と技術スタック

開発ツールやエージェントフレームワークへの組み込みやすさも、Supermemory の特徴です。

• MCP server: Model Context Protocol に対応し、Claude / Cursor / Windsurf / VS Code などの IDE・クライアントと連携できます（出典: supermemoryai/supermemory README）。
• フレームワーク連携: Vercel AI SDK / LangChain / LangGraph / OpenAI Agents SDK などのエージェント開発フレームワークとの統合が用意されています。

技術スタックとしては、GitHub のトピックに postgres・drizzle-orm・cloudflare-workers・cloudflare-kv・cloudflare-pages などが挙げられています。PostgreSQL をデータストアに、Cloudflare のエッジプラットフォーム上で動くアーキテクチャであることが読み取れます。この「Cloudflare Workers 前提」という点は、セルフホストを検討する際の制約に直結するため、採用判断では特に注意が必要です。

SupermemoryのAPI／SDKの使い方イメージ

実際にコードに組み込むとどのような手触りになるのか、公式の例から見ていきます。Supermemory はクラウドのマネージド API を前提とした設計で、API キーを用意すれば SDK 経由で記憶の追加・取得が行えます。

containerTag を軸にした add / profile の流れ

Supermemory の中核となる概念が containerTag です。これはユーザーやドキュメント、プロジェクトといったエンティティを束ねる識別子で、同じタグでメモリを追加・検索することでコンテキストを統合できます。

公式リポジトリの TypeScript の例は次のとおりです（出典: supermemoryai/supermemory README）。

import Supermemory from "supermemory";
const client = new Supermemory();
await client.add({
  content: "User loves TypeScript and prefers functional patterns",
  containerTag: "user_123",
});
const { profile, searchResults } = await client.profile({
  containerTag: "user_123",
  q: "What programming style does the user prefer?",
});

add でユーザーに関する事実を記録し、profile で「このユーザーの好みは？」といった問い合わせを投げると、プロファイルと検索結果が返ります。アプリ側は「履歴をすべて管理する」のではなく、「タグ単位で記憶を追加し、必要なときに問い合わせる」という流れになります。

Python でも同等の API が提供されています（出典: supermemoryai/supermemory README）。

from supermemory import Supermemory
client = Supermemory()
client.add(
    content="User loves TypeScript and prefers functional patterns",
    container_tag="user_123"
)
result = client.profile(container_tag="user_123", q="programming style")

SDK のインストールと API キーの設定手順は公式の Supermemory Quickstart にまとまっています。TypeScript（npm install supermemory）と Python（pip install supermemory）の両方に SDK が用意されており、SUPERMEMORY_API_KEY を環境変数に設定して使う構成です。LLM の推論や埋め込み生成はサーバー側で処理されるため、利用者は API キーのみで始められる点が、学習コストの低さにつながっています。

MCP / フレームワーク経由の組み込み

IDE やエージェントに直接メモリ機能を組み込みたい場合は、MCP 経由での導入も用意されています。公式リポジトリでは次のクイックインストールコマンドが示されています（出典: supermemoryai/supermemory README）。

npx -y install-mcp@latest https://mcp.supermemory.ai/mcp --client claude --oauth=yes

このコマンドは MCP クライアント（この例では Claude）に Supermemory の MCP サーバーを登録するものです。SDK でアプリに組み込む方法と、MCP でエディタ／エージェントに後付けする方法の両方があるため、自分のユースケースに近い入り口を選べます。

セルフホスト可否とデプロイモデル｜採用前に確認すべき制約

ここが、初見のエンジニアが最も見落としやすく、かつ採用可否を左右する論点です。「MIT ライセンスの OSS だから自由にセルフホストできるはず」という前提で進めると、後から要件と合わないことに気づく可能性があります。

クラウド前提の利用モデル

Supermemory の主たるデプロイ先は、クラウドのマネージド API です。LLM 推論や埋め込み生成はサーバー側で処理され、利用者は API キーを用意するだけで使い始められます。料金面では、個人や小規模な用途であれば無料枠で十分という日本語解説記事の言及もあります（出典: Supermemory API 解説（apidog, 2026年））。素早く立ち上げたいケースでは、この「API キーだけで始められる」手軽さが大きな利点になります。

セルフホストの条件と制約（オンプレ完全運用は不可）

一方で、自社インフラ内で完結させたい場合は、いくつかの制約を理解しておく必要があります。公式ドキュメントやサードパーティの比較記事によれば、セルフホストはエンタープライズプランのアドオンとして提供され、Cloudflare Workers へのデプロイを前提とし、PostgreSQL（pgvector）と OpenAI の API キー（必須。Anthropic / Gemini は任意）が必要とされています（出典: Supermemory Docs、Mem0 vs Supermemory 比較（mem0 公式））。

つまり、Docker ベースで自社サーバーに丸ごと載せるような「完全オンプレ」の運用パスは用意されておらず、Cloudflare のエッジプラットフォームに密結合した形になります。また、エンタープライズ／セルフホストの価格は公開されていません。

ここで重要なのは、リポジトリが MIT ライセンスで公開されている範囲と、マネージドサービス／エンタープライズとして提供される範囲は別物だという点です。OSS として誰でも参照・利用できる部分と、クラウドやエンタープライズプランでのみ提供される機能・運用形態は区別して考える必要があります。「完全オンプレ必須」「インフラを自社で完全管理したい」という要件がある場合は、ここが採用の分かれ目になります。

Mem0・Zepなど類似OSSとの違い

「どれを選ぶか」の核心が、類似 OSS との比較です。ここでは代表的な Mem0・Zep と、補足として Letta を取り上げ、Supermemory との違いを整理します。

Supermemory と Mem0 の違い

Mem0（mem0ai/mem0） は、会話メモリを中心としたメモリ層 OSS です。LLM ベースの事実抽出にベクトル埋め込みとナレッジグラフを組み合わせる構成で、ライセンスは Apache 2.0、完全なセルフホストが可能とされています。

両者の主な違いは次のとおりです。

• 機能範囲: Supermemory は Gmail / Notion / GitHub などのコネクタやマルチモーダル取り込みを内蔵し、カバー範囲が広い一方、クラウド主体でフルセルフホストはできません。Mem0 は取り込みパイプラインを自作する必要がある場面が多いものの、オンプレ運用がしやすい構成です。
• デプロイ: Mem0 は完全セルフホスト可。Supermemory はクラウドが主体で、セルフホストはエンタープライズアドオン・Cloudflare Workers 前提。
• ベンチマーク主張: LongMemEval では Supermemory が Mem0 を大きく上回ると主張されていますが、これは各社の測定条件に依存します（出典: Mem0 vs Supermemory（mem0 公式比較）、Building AI apps with Mem0 and Supermemory（LogRocket））。

ごく単純化すると、「内蔵機能の広さとマネージドの手軽さ」を取るなら Supermemory、「ライセンスの自由度とフルセルフホスト」を取るなら Mem0、という対比になります。

Zep・Letta との位置づけの違い

Zep（getzep/zep） は、LLM アプリ向けの専用メモリ DB で、会話要約・エンティティ抽出・ファクト管理をリアルタイムに処理します。temporal knowledge graph（時間軸を持つナレッジグラフ）による時間推論や関係性の追跡に強みがある点が特徴です。「いつ・誰が・何を」という時系列の関係性を厳密に追いたいユースケースでは、Zep が候補に挙がります。日本語の比較記事では、LongMemEval で Zep が 63.8%、Mem0 が 49.0% といった報告もあります（出典: AIエージェントメモリ比較 2026年版（renue））。

補足として、Letta（letta-ai/letta、旧 MemGPT） は設計思想が大きく異なります。Letta は「エージェント自身がメモリを管理する」アプローチで、OS のように Core / Archival / Recall の階層でメモリを操作します。長時間にわたって自律的に動くエージェント向けの考え方です。これに対し Supermemory は「API / SDK でアプリにメモリ層を後付けする」設計で、用途の出発点が異なります。

比較表（範囲／ライセンス／デプロイ／強み）

（出典: 各リポジトリおよび renue 比較記事。ライセンス・デプロイ可否は各プロジェクトのリポジトリ・ドキュメントで最新情報を確認してください）

ベンチマーク数値はいずれも各プロジェクトの主張・測定条件に依存するため、横並びの優劣を断定する材料ではなく「どの軸を強みとして設計しているか」を読み取る材料として扱うのが安全です。

Supermemoryが向くケース・向かないケース

ここまでの内容を、採用判断の結論に落とし込みます。Supermemory が向くケースと、慎重に検討すべきケースを整理します。

向いているプロジェクト

次のような要件を持つプロジェクトでは、Supermemory が有力な候補になります。

• 複数のデータソースを横断したメモリが欲しい: Gmail・Notion・GitHub などのコネクタを内蔵で使いたい場合、取り込みパイプラインの自作工数を抑えられます。
• マルチモーダルな取り込みが必要: PDF・画像・動画・コードを含む情報を記憶として扱いたい場合に適します。
• クラウドのマネージドで素早く始めたい: インフラ構築に時間をかけず、API キーだけでメモリ層を立ち上げたいケース。
• RAG とメモリを統合的に扱いたい: ドキュメント検索とユーザー固有の記憶を別々に管理したくない場合。

慎重に検討すべきプロジェクト

一方で、次のような要件がある場合は、採用前にデプロイモデルとコスト構造を十分に確認する必要があります。

• 完全オンプレ運用が必須: 自社インフラ内ですべてを完結させたい場合、Cloudflare Workers 前提のデプロイモデルは制約になります。この要件では Mem0 など完全セルフホスト可能な選択肢の方が合致しやすいです。
• 標準的なインフラで自前運用したい: Docker ベースで自社の標準スタックに載せたい場合、現状のデプロイ前提と合わない可能性があります。
• コスト構造を完全に自社管理したい: マネージド／エンタープライズの価格が非公開のため、コストの予見性を重視する場合は事前の見積もり確認が欠かせません。

採用判断のチェックリストとしては、「コネクタ・マルチモーダルを内蔵で使いたいか」「クラウドマネージドで問題ないか」「オンプレ要件はないか」「コストの予見性をどこまで求めるか」の 4 点を自社要件と突き合わせると、候補に残すか外すかの判断がつきやすくなります。

まとめ｜Supermemoryを採用判断する次のステップ

Supermemory は、AI に会話をまたぐ長期記憶を与えるメモリエンジン／メモリ API です。本記事のポイントを振り返ります。

• 強み: 会話からの事実抽出・User Profiles・Hybrid Search に加え、Gmail / Notion / GitHub などのコネクタとマルチモーダル取り込みを内蔵し、カバー範囲が広い。API キーだけで始められる手軽さも魅力。MIT ライセンスで、スター 2.5 万・当日更新とメンテナンスも活発。
• 最大の確認ポイント: デプロイモデルがクラウド主体で、セルフホストはエンタープライズアドオン・Cloudflare Workers 前提。完全オンプレ運用は想定されていない。MIT 公開部分とマネージド／エンタープライズ提供範囲は区別が必要。
• 類似 OSS との違い: 「内蔵機能の広さ＋マネージドの手軽さ」なら Supermemory、「ライセンスの自由度＋フルセルフホスト」なら Mem0、「時系列推論・関係性追跡」なら Zep、「エージェント主体のメモリ管理」なら Letta、と設計思想で棲み分けられる。

採用候補に残すと判断した場合の次のステップとして、公式サイト supermemory.ai と公式ドキュメントで、最新の料金・セルフホスト条件・SDK の対応状況を確認したうえで、自社のユースケースに近い小さな検証から始めることをおすすめします。本記事はドキュメントベースの紹介であり、実運用での挙動・性能・コストは自社環境での検証によって確かめてください。