supermemory入門｜AI時代のMemory APIをmem0・cognee・Lettaと比較で読み解く

この記事ではAIメモリ／RAG領域に絞って解説します。RAG全般の仕組み・主要OSS比較は RAGとは？仕組み・主要手法・ベクトル検索・ナレッジグラフを実装目線でまとめる2026年版 をご覧ください。

30秒で理解するsupermemory

supermemoryは、アプリケーションに「AIの記憶層」を組み込むためのMemory APIだ。要点だけ先に押さえる。

・supermemoryはアプリにAI記憶を組み込むためのAPI。GitHubで約25,140★、ライセンスはMIT、実装はTypeScript
・公式は「state-of-the-artなメモリ＆コンテキストエンジン」を掲げ、LongMemEval・LoCoMo・ConvoMemといった記憶系ベンチで上位を主張
・mem0 / cognee / Letta(MemGPT) と並ぶAIメモリ大型OSSの一角で、コーディングエージェント連携に強みを置く
・SaaSとセルフホストの両方をサポートし、SDKはJavaScript/TypeScriptとPythonを提供
・Google Drive・Gmail・Notion・GitHubなどのコネクタで外部データを同期し、PDF・画像・動画・コードもマルチモーダルに取り込む

LLMのコンテキスト長が伸びても「アプリがユーザーを覚えている」状態は別途設計が要る。supermemoryはその記憶層を外出しするための選択肢の一つだ。本記事は競合と並べて、どこを担当する道具なのかを切り分ける。

なぜ「AIメモリ」が新カテゴリなのか

ここ1〜2年で「AIメモリ（AI memory／agent memory）」が独立したカテゴリとして立ち上がってきた。背景には、LLM単体では解けない3つの限界がある。

第一に、コンテキストウィンドウの限界だ。1Mトークン級の長文脈モデルが増えても、毎回すべての履歴を詰め込むのは非効率でコストもレイテンシも跳ね上がる。長く動くエージェントほど、必要な事実だけを選んで渡す「記憶の出し入れ」が要る。長文脈アーキの最前線は MiniMax M3｜SWE-Bench Pro 59.0%のオープンウェイトモデル でも触れたが、文脈が伸びても記憶問題が消えるわけではない。

第二に、ステートフルなエージェントへの流れだ。1回の質疑応答で終わるチャットボットと違い、何日も走り続けるエージェントは「自分が何を知っていて、ユーザーが何を好むか」を跨セッションで保持しないと、一貫性が崩れる。エージェント設計全体の見取り図は AIエージェントフレームワーク比較2026 にまとめている。

第三に、RAGとの役割分担だ。RAGは「ドキュメントを検索して文脈に足す」仕組みで、静的な知識ベースの参照に向く。一方でメモリ層は「ユーザーや会話について、矛盾や更新を扱いながら事実を育てる」点が本質的に違う。企業が記憶・文脈をどう層構造で扱うかは Microsoft IQの4層を読み解く の整理とも響き合う。

この3つの限界が重なった結果、「LLMの外側に、ユーザーや組織についての事実を時間軸で持つ層」を独立した製品として切り出す動きが加速した。2024年から2026年にかけて、mem0・Letta・cognee・Zep(Graphiti)・Memori、そしてsupermemoryといったプロダクトが相次いで登場し、「AIメモリ」という言葉が共通語になった。各社の力点は微妙に違うが、共通するのは「コンテキストウィンドウに毎回全部を詰める運用は破綻する」という前提認識だ。記憶を外出しして必要な分だけ渡す、という発想がカテゴリの土台にある。

supermemoryの中身

supermemoryは大きく5層で構成される。データを取り込み、事実を抽出して保存し、低レイテンシで検索し、LLMのコンテキストに差し込む、という流れだ。

公式の説明を機能ごとに整理すると、次のようになる。

・自動事実抽出：会話やドキュメントから事実を切り出し、矛盾の解消や古い情報の自動失効（expiration）を扱う
・ユーザープロファイル：安定した事実（static）と直近の活動（episodic）を自動でまとめ、約50msで返すと主張
・ハイブリッド検索：RAGとメモリを1クエリに統合し、ナレッジベース文書とパーソナルな文脈を同時に引く
・コネクタ：Google Drive・Gmail・Notion・OneDrive・GitHubをWebhookでリアルタイム同期
・マルチモーダル処理：PDF、画像（OCR）、動画（文字起こし）、コード（AST対応のチャンク分割）を取り込む

検索の高速性とコネクタの厚さが、supermemoryの実用上の差別化ポイントだ。とくにコード向けのAST対応チャンク分割は、コーディングエージェントの過去文脈を扱う用途を意識した設計と言える。

ここでもう一段、抽出パイプラインが実際に何をしているかを補足しておく。会話やドキュメントをそのまま全文保存するのではなく、LLMで「後から参照する価値のある事実」を切り出して構造化する。たとえば「先週はReactで実装したけど、今回はSvelteに切り替えたい」という発話からは、「現在の選好＝Svelte」「過去の選好＝React（失効）」といった形で、時間軸を持った複数の事実が抽出される。この「全文ではなく事実を蓄える」点が、単純に履歴をベクトル化するだけのアプローチとの本質的な違いだ。蓄積される単位が小さくなることで、検索時に余計な文脈を引かずに済み、約50msという低レイテンシも成立しやすくなる。

公式は記憶系ベンチマークのLongMemEval・LoCoMo・ConvoMemで上位を主張している。これらは「長い会話の途中で過去の事実を正しく思い出せるか」「複数セッションをまたいで一貫性を保てるか」を測るもので、まさにメモリ層の核心を突くテストだ。ただし、新興プロダクトのベンチ値はベンダー自身の実測であることが多く、評価条件（埋め込みモデル・チャンクサイズ・検索Top-k）で結果が動く。順位そのものを鵜呑みにせず、自社の代表ワークロードで再現率を測るのが安全だ。

競合との比較表

AIメモリ系OSSは「どこを担当する道具か」が製品ごとに大きく違う。代表的な5つを並べて、アーキ・保存方式・ライセンス・ホスティングの軸で整理する。

ざっくり性格を言い切ると、こうなる。mem0は「フレームワークに後付けする標準的なメモリ層」、Lettaは「エージェント自身が記憶を自己編集するOS的ランタイム」、cogneeは「グラフ推論とローカル実行に強い基盤」、Graphitiは「時系列の関係を追う知識グラフ」、そしてsupermemoryは「低レイテンシのマネージドAPI＋コネクタで、コーディングエージェントやアプリ統合に寄せた道具」だ。

記憶の「更新主体」の違いは、見落とされがちだが設計思想を分ける重要な軸だ。supermemoryやmem0は抽出パイプラインが裏で自動的に事実を切り出して保存する「受動型」で、開発者は何を入力するかを制御するが、分解と保存はシステム任せになる。対してLettaはエージェント自身が推論ループの中でメモリ関数を呼び、「これは覚えておく価値がある」と判断して自己編集する「能動型」だ。受動型は実装が軽く外付けしやすいが、何が記憶されるかの可観測性は下がる。能動型は長期の自律エージェントで一貫性を保ちやすいが、エージェント設計そのものに踏み込む必要がある。どちらが優れているという話ではなく、作るものがアプリか自律エージェントかで適合が変わる。

ユースケース別の選び方

チャットアプリの会話履歴記憶

ユーザーの好み・過去の発言・進行中の話題を覚えさせたいケースだ。supermemoryやmem0のように「会話を渡すと事実を自動抽出してくれる」マネージド型が相性が良い。低レイテンシで直近プロファイルを返せるsupermemoryは、応答速度が体験を左右するチャットUIに向く。

コーディングエージェントの過去文脈

過去の修正方針・コードベースの構造・チームの規約を覚えさせる用途だ。supermemoryはコードのAST対応チャンク分割やGitHubコネクタを持ち、この領域を明示的に意識している。エージェントが自分で記憶を編集する設計を重視するならLettaも候補になる。

CSボットの顧客対応履歴

顧客ごとの問い合わせ履歴・契約状態・過去の解決策を保持するケースだ。顧客単位でスコープを切る必要があるため、後述のcontainerTagでユーザー/組織を分離できる設計が効く。矛盾の解消（古い住所→新しい住所）を自動で扱える点も実務で効く。

ナレッジワーカーの個人サマリ

個人の文書・メモ・Webクリップを横断して「自分専用の要約」を作る用途だ。コネクタでDrive/Notionを同期し、マルチモーダル取り込みでPDFや動画も束ねられるsupermemoryのアプリ的な使い方がはまる。散在する情報を一箇所に集約し、過去の自分の判断や調べ物を呼び出せる「セカンドブレイン」的な体験を、APIとして自社プロダクトに組み込めるのが強みだ。データ主権を重視するならフルローカル運用ができるcogneeも比較対象になる。

ローカル実行手順

SaaSを使えばDBは不要だが、まずSDKでAPIを叩く最小構成から始めるのが分かりやすい。NPMとPythonの両方が用意されている。

# JavaScript / TypeScript
npm install supermemory

# Python
pip install supermemory

最小構成は「記憶を追加する（add）」と「検索する（search）」の2操作だ。会話ループにこの2つを挟むだけで、アプリに記憶層が乗る。以下はTypeScriptでの最小例だ（APIは公式SDKの想定。実際のメソッド名・引数は最新ドキュメントで確認のこと）。

import { Supermemory } from "supermemory";

const client = new Supermemory({ apiKey: process.env.SUPERMEMORY_API_KEY });

// 1. 会話から記憶を追加（containerTagでユーザーを分離）
await client.memories.add({
  content: "田中さんはPythonよりGoを好み、CI/CDはGitHub Actions派",
  containerTag: "user:tanaka",
});

// 2. 次の会話で関連する記憶を検索
const results = await client.memories.search({
  q: "田中さんの好みの言語は？",
  containerTag: "user:tanaka",
});
console.log(results); // 関連する事実が約50msで返る想定

Pythonでも同じ2操作で動く。LangChainなど既存のチェーンに差し込む場合は、検索結果をプロンプトの文脈に連結するだけでよい。

from supermemory import Supermemory

client = Supermemory(api_key=os.environ["SUPERMEMORY_API_KEY"])

# ドキュメントを丸ごと取り込み（RAG側）
client.documents.add(content=open("handbook.md").read(),
                     container_tag="org:acme")

# メモリとRAGをハイブリッドに検索
hits = client.memories.search(q="入社時のオンボーディング手順は？",
                              container_tag="org:acme")
context = "\n".join(h["content"] for h in hits)
# context を LLM プロンプトに連結して回答生成

MCP（Model Context Protocol）経由で使う場合は、Claude DesktopやCursor、Claude Codeなどのクライアントから接続できる。OSS実装をセルフホストする場合は、保存基盤の用意とコネクタ設定が追加で要る。SaaS版とセルフホストの切り替えは、APIエンドポイントとキーの差し替えが基本になる。

API設計のポイント

メモリAPIを使いこなすうえで押さえるべき設計上の論点がいくつかある。supermemoryの構造に沿って整理する。

・記憶の粒度：事実（fact）・出来事（event）・好み（preference）を区別して扱う。抽出パイプラインが会話から何を「事実」として切り出すかが検索品質を左右する
・タイムスタンプと失効：古い情報の自動失効や矛盾解消を持つ。住所変更のように「上書きすべき事実」を時間軸で扱えるかが実務の肝
・スコープ（containerTag）：ユーザー/組織/プロジェクトといったエンティティ単位で記憶を分離する。同じcontainerTagを使うとメモリとRAGが同じコンテキストプールを共有する
・更新と削除のセマンティクス：更新は新バージョンを作り、元は履歴として残る（isLatest=falseのような版管理）。削除はソフトデリートで履歴を保持する設計

このうち実装で一番効くのがcontainerTagの設計だ。顧客ごと・プロジェクトごとにタグを切ると、検索が混線せず、後からの削除（特定ユーザーの記憶だけ消す）もスコープ単位で扱える。最初のスキーマ設計でここを雑にすると、後から分離するのが難しくなる。

記憶の粒度設計も軽視できない。事実・出来事・好みをひとまとめに保存すると、検索時に「直近で変わった好み」と「動かない属性」が混ざって返り、プロンプトのノイズになる。supermemoryのようにユーザープロファイルが安定情報と直近活動を分けて維持してくれる設計は、この混線を抑えるための工夫だ。自前でメタデータを付けて区別する場合も、「これは恒久的な事実か、時限的な状態か」をタグで持たせておくと、後の失効・上書きが扱いやすくなる。

更新セマンティクスの理解も実務で効く。多くのメモリAPIは更新を「上書き」ではなく「新バージョンの追加＋旧版のフラグ降格」で扱う。これは監査やロールバックに有利だが、検索時に古い版まで引かないようフィルタを正しく指定する必要がある。削除も即時の物理削除ではなくソフトデリートが既定のことが多く、GDPRの「消去権」に応えるには、ソフトデリートと物理削除のどちらが要件を満たすかを事前に確認しておくべきだ。

既存アプリへの統合パターン

supermemoryは独立したAPIサーバとしても、既存フレームワークのメモリレイヤとしても使える。主な統合パターンは3つだ。

・LangChain / LlamaIndex のメモリレイヤとして：チェーンやエージェントの記憶を外出しし、検索結果を文脈に連結する。LangGraphやVercel AI SDK、OpenAI Agents SDKのインテグレーションも提供される
・OpenAI SDK / Anthropic SDK のミドルウェアとして：LLM呼び出しの前後にadd/searchを挟み、リクエストに関連記憶を注入する薄い層を作る
・カスタムAPIサーバの拡張として：自社バックエンドからMemory APIを直接呼び、ユーザーごとの記憶を管理する

LangChain入門やエージェント設計を先に押さえたい場合は LangChainの使い方｜日本語入門 が下地になる。グラフ構造で記憶・知識を扱う発想は LightRAG｜知識グラフ×デュアルレベル検索 とも比較すると、ベクトル一辺倒との違いが見えてくる。

統合の進め方には定石がある。いきなり全ユーザー・全機能に記憶層を入れるのではなく、限定したcontainerTagのスコープで「add（保存）→ search（検索）→ プロンプト連結」の最小ループを回し、抽出された事実と検索結果を目視で確認するところから始める。ここで「期待した事実が抽出されているか」「無関係な記憶が混ざっていないか」を見て、抽出プロンプトやスコープ設計を調整する。品質が安定したら対象を広げ、コネクタ同期やマルチモーダル取り込みといった重い機能を後から足していく。記憶層は一度本番データが溜まると設計変更のコストが跳ね上がるため、この「小さく回して見てから広げる」順序が事故を防ぐ。

コスト試算

supermemoryはSaaSの料金プランが公開されている（2026年6月時点の公式値。最新は公式ページで確認のこと）。利用量ベースの「組み込みクレジット」モデルが特徴だ。

セルフホスト運用のコストは、VPSとDB（ベクトル/グラフ基盤）の運用費が中心になる。Scaleプラン以上でセルフホストオプション、Enterpriseでエアギャップ自己ホストとSOC 2/HIPAA/GDPR対応が案内されている。規模が小さいうちはSaaSの利用量課金、データ主権やコンプライアンス要件が出てきたらセルフホスト、という移行が現実的なTCO設計だ。

規模別に大まかな目安を言えば、個人開発やプロトタイプはFree〜Proで十分まかなえることが多い。月数千〜数万リクエストの本格運用に入るとMaxやScaleが視野に入り、ここで「SaaSの月額＋超過利用料」と「セルフホスト時のVPS＋DB＋運用人件費」を天秤にかける局面が来る。セルフホストはインフラ費だけ見ると安く見えるが、ベクトル/グラフDBの運用・バックアップ・スケール対応の手間（＝エンジニアの時間）が乗る。少人数チームではSaaSのほうが総コストで有利なケースが多く、専任のインフラ体制がある、もしくはデータを外に出せない要件がある場合にセルフホストが効いてくる。「安いから自前」ではなく「要件があるから自前」で判断するのが、後悔しないTCO設計だ。

よくある落とし穴

メモリ層を導入すると、RAG単体では起きなかった種類の問題に直面する。代表的なものを挙げる。

・記憶の不整合：同じユーザーについて矛盾する事実（古い所属と新しい所属）が併存し、検索でどちらも返ってしまう。失効・矛盾解消の設定と、更新セマンティクスの理解が前提
・スケール時のクエリレイテンシ：記憶が増えるほど検索が重くなる。containerTagでスコープを切り、検索対象を絞る設計が効く
・GDPR/個人情報の削除要求：「忘れてほしい」要求にスコープ単位で応えられる設計が要る。ソフトデリートだけだと履歴が残り、完全削除の要件を満たせないことがある
・PII（個人情報）の自動マスキング：会話から事実を抽出する過程で、機微な個人情報をそのまま保存してしまうリスク。マスキングや保存対象の制御を最初に決めておく

とくに削除とPIIは後回しにしがちだが、本番でユーザーデータを扱う以上は設計初期に決めておくべき項目だ。「記憶できる」ことの裏側に「正しく忘れられる」ことの設計責任がある、という視点を持っておきたい。AIエージェントが正規の権限で記憶へアクセスする時代には、保存内容そのものが攻撃対象にもなり得る。記憶にAPIキーや内部URLが紛れ込めば、それを引き出すプロンプトインジェクションの標的になる。何を保存し、何を保存しないかの線引きは、機能要件であると同時にセキュリティ要件でもある。

まとめ：supermemoryをどう位置づけるか

supermemoryは、AIメモリという新カテゴリの中で「低レイテンシのマネージドAPI＋厚いコネクタ＋コーディング向けの取り込み」に寄せた道具だ。約25,140★・MIT・TypeScriptという素性は、アプリにサクッと記憶層を足したいTypeScript系の開発者に届きやすい。

・まず試すなら：Free枠で代表ワークロードを入れ、抽出された事実と検索の再現率を実測する
・mem0と迷うなら：TypeScript／コネクタ／コーディング連携重視ならsupermemory、Python中心の標準メモリ層ならmem0
・グラフ推論や時系列が要るなら：cogneeやGraphiti、自律エージェントの自己編集記憶ならLetta
・本番投入の前に：containerTag設計・削除セマンティクス・PIIマスキングを先に固める

「LLMが賢くなる」ことと「アプリがユーザーを覚える」ことは別の問題だ。後者を担う層として、supermemoryは比較検討に値する選択肢の一つと言える。

参照ソース

・supermemoryai/supermemory（GitHub公式リポジトリ） — README・機能一覧・SDK情報の一次ソース
・supermemory公式ドキュメント — Memory API・containerTag・ハイブリッド検索の設計