# AIメモリ比較 2026——ChatGPTからTanka AIまで、誰の記憶を持つのか

> AIメモリとは何か。ChatGPT・Claude・GeminiからMem0・Letta・Graphiti・LangMem・EverOS、Tanka AIまでを一次資料で比較し、RAGとの違い、記憶単位、共有、可搬性、Tanka AIとEverMemOSの関係、OSSと商用製品の選び方を整理する。

- Kind: REPORT
- Published: 2026-08-23
- Canonical: https://kiokulab.com/notes/ai-memory-comparison-2026
- Publisher: Kioku Lab (https://kiokulab.com)

---

2026年、「AIメモリ（AI Memory）」はAI産業でもっとも意味の膨らんだ言葉の一つになった。

ChatGPTは「あなたを覚える」と言う。Claudeは会話を越えて仕事の文脈を引き継ぐ。AWSやGoogle CloudはAIエージェント向けのメモリを提供し、GitHubにはMem0、Letta、Graphiti、LangMem、EverOSが並ぶ。[Tanka AI](https://www.tanka.ai/)（AIネイティブな企業運営を掲げるチーム向け製品）は「チームの記憶」——組織の記憶——を掲げている。

ところが、それらは同じ問題を解いていない。

あるAIメモリは好みを一行の事実として残す。あるAIメモリはエージェント自身の状態を保つ。あるAIメモリは時間とともに変わる関係をグラフにする。そしてあるAIメモリは、担当者が替わってもチームの仕事を続けるためにある。

> **AIメモリの違いは、どれだけ覚えられるかではない。誰の記憶なのか、何を記憶の一単位として残すのか、誰が修正できるのか、そして製品の外へ持ち出せるのかである。**

本稿は、主要な個人向け製品、マネージド基盤、オープンソース実装を同じ物差しでいったん比べ、その後で「そもそも同じ競技なのか」を問い直す。

**調査範囲。** 本稿は2026年8月23日時点の公開一次資料をもとにした代表例の比較であり、網羅的な製品一覧でも、順位表でもない。機能・提供条件・ライセンスは変わり得る。各製品について「公開資料で確認できること」と「会社の公式説明」を分けて記す。

## AIメモリ比較 2026——用途別の結論

**本稿では、AIメモリ（AI Memory）を、会話やタスクの境界を越えて残り、後の推論や行動に使われる持続的な状態と定義する。** ただし、2026年時点で単一の標準方式はない。用途別の結論は次のとおりだ。

- **個人AIを継続的にパーソナライズしたい**なら、ChatGPT、Claude、Geminiでは、記憶機能が製品体験として統合されている。
- **AIエージェントに事実や経験を持たせたい**なら、Mem0、Letta、Graphiti、LangGraph Store / LangMem、EverOS、各社のマネージド型メモリが候補になる。
- **オープンソースに唯一の最適解はない。** 原子化された事実、長寿命のAIエージェント、時間グラフ、独自スキーマ、エピソード／プロファイルのどれを記憶単位にするかで選択は変わる。
- **Tanka AI、EverMemOS 1.0、現在のEverOSは同一ではない。** Tanka AIはEverMemOS 1.0を採用した商用製品で、公開アップストリームはEverOSへ発展している。両者は同じ系譜にある別のものとして読む。
- **組織の記憶は、個人向けメモリやエージェントメモリを単に共有したものではない。** 決定権限、未決事項、出典、確認、期限、引き継ぎまで扱う必要がある。

以下では、この結論に至る比較軸と根拠を示す。

## AIメモリとRAG・コンテキストウィンドウの違い

議論が混線する最大の理由は、四つの異なるものをすべて「記憶」と呼ぶことにある。

- **コンテキストウィンドウ（context window）**は、一度の推論でモデルが見られる作業台である。広い作業台は長い資料を置けるが、次の仕事まで残るとは限らない。
- **セッション／チャット履歴**は、会話の原記録である。保存されていても、重要なものが選ばれ、更新され、必要なときに使われなければログのままだ。
- **RAG**は、外部情報を検索して作業台へ運ぶ読み出し経路である。AIメモリはRAGを使えるが、RAGだけでは「何を記憶にするか」「古い事実をどう扱うか」は決まらない。
- **長期記憶（long-term memory）**は、会話やタスクの境界を越えて残り、形成・更新・忘却・想起される状態である。

流れにすると、こうなる。

> 原記録 → 記憶の形成・書き込み → 持続的な保持・更新 → 検索・文脈編成 → コンテキストウィンドウ → 推論

検索はこの鎖の後半にある。**記憶は、検索より前から始まっている。**

## 同じ言葉の中に、四つの市場がある

| 層 | 記憶の主体 | 主な記憶単位 | 解いている問い | 代表例 |
|---|---|---|---|---|
| 個人向けAI製品 | ユーザー | 好み、属性、仕事の文脈、会話の要約 | 「このAIは私を覚えているか」 | ChatGPT、Claude、Gemini |
| AIエージェント基盤／マネージド型メモリ | ユーザー、AIエージェント、セッション、チーム | 会話イベント、要約、事実、手順、ファイル | 「AIエージェントは次の実行へ何を持ち越すか」 | Claude Memory Tool、AWS AgentCore、Agent Platform Memory Bank、Microsoft Foundry |
| メモリ基盤 | アプリが定義する主体 | 原子化された事実、エピソード、プロファイル、関係、プロンプト | 「記憶をどう形成・保存・検索するか」 | Mem0、Letta、Graphiti、LangMem、EverOS |
| チーム／組織の記憶 | チーム、案件、組織 | 判断、約束、未決事項、前提、来歴 | 「何を組織の判断として引き継いでよいか」 | Tanka AI |

これら四層は技術的に重なり合う。個人向け製品の内側にもメモリ基盤はあるし、マネージド基盤の上にチーム向け製品を作ることもできる。重要なのは、**製品名ではなく、どの主体のどの問題を解いているか**で見ることだ。

## クローズド製品の強さ——記憶を製品体験にする

個人向けのクローズド製品は、保存方式の自由度よりも、記憶の形成・確認・利用を一つの体験にまとめることに強みがある。

| 製品 | 公開資料から分かる記憶像 | ユーザーの制御 | 組織記憶との境界 |
|---|---|---|---|
| [ChatGPT](https://help.openai.com/en/articles/8590148-memory-and-new-controls-for-chatgpt) | 会話、ファイル、接続アプリから得た文脈を継続的に統合し、Memory summaryとして見せる。以前のSaved Memoriesに比べ、固定項目ではなく更新される総合像に近い | Memory summaryの修正・削除、Memoryの停止、Temporary Chat、応答に使われた一部の出典確認 | 組織の正式決定を表す公開スキーマではなく、主目的は個人への適応 |
| [Claude](https://support.claude.com/en/articles/11817273-use-claude-s-chat-search-and-memory-to-build-on-previous-context) | カテゴリ別の記憶項目を会話中に読み書き・更新し、プロジェクトごとに独立した記憶空間を持つ。過去チャット検索は、記憶とは別の機能として提供される | Pause / Reset、Incognito、個別項目の管理。さらに[コピー＆ペースト型のインポート／エクスポート](https://support.claude.com/en/articles/12123587-import-and-export-your-memory-from-claude)を提供 | 新しい記憶体験はFree・Pro・Max向けに移行中で、Team・Enterpriseは当面旧体験。インポートはFree・Pro・Max・TeamのWeb / Desktopで提供される実験的機能である。組織横断の責任・権限・決定状態を表すものではない |
| [Gemini](https://support.google.com/gemini/answer/16598469) | 過去のGemini会話や接続されたGoogleアプリの情報を、個人化に利用する | Activityや会話、接続アプリをユーザーが管理。情報を記憶利用の対象から完全に除くには、元の会話と接続元の両方を扱う場合がある | 過去チャットによる個人化は18歳以上、個人Googleアカウント、Keep Activityの有効化が条件で、仕事・学校・保護者による管理対象のアカウントには非対応。GemsやLiveチャットなど一部機能でも利用できない。独立した組織記憶プロトコルではない |

この層で最も重要な問いは「私を正しく理解しているか」である。たとえば「菜食である」「簡潔な文体を好む」「このプロジェクトではRustを使う」は、AIが個人に適応するための優れた記憶になる。

しかし、「A社への提示条件は承認済みか」「誰がその約束をしたか」「異動後の担当者がそれを変更してよいか」は別の問いだ。**個人のメモリを複数人で共有しても、それだけでは組織の記憶にならない。**

## マネージド基盤——保存を任せるか、制御を手元に残すか

AIエージェントを作る側には、クラウド事業者のマネージド基盤を利用する選択肢もある。記憶の保存・抽出・運用をサービスとして引き受ける形だ。

| サービス | 設計上の特徴 | 開発者側に残る設計・制御 |
|---|---|---|
| [Claude API Memory Tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool) | Claudeがメモリディレクトリの読み取り・作成・更新を要求するが、実際の操作はアプリ側が実行する。記憶はファイルとして扱われる | 保存先と実行を自社側に置ける。クローズドモデルだが、データ面では「全部お任せ」とは逆の設計 |
| [Amazon Bedrock AgentCore Memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html) | セッション内の会話を保つ短期記憶と、会話から好み・事実・要約を抽出する長期記憶を分けたマネージドサービス | インフラ運用をAWSへ委ね、AIエージェント側はスコープと利用方法を設計する |
| [Agent Platform Memory Bank（旧Vertex AI Memory Bank）](https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/memory-bank) | 会話から記憶を生成・統合し、スコープごとに取得・更新・削除・TTL・変更履歴を管理する | Google Cloud上のAIエージェント実装とIAMに統合する |
| [Microsoft Foundry Agent Service Memory（Preview）](https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/memory-usage) | 要約、ユーザープロファイル、手続き記憶などを扱い、スコープを個人・チームその他の識別子に分けられる | Azure上での保存、スコープ、TTLとAIエージェント統合を設計する。Previewの提供条件と変更可能性を織り込む必要がある |

ここで「クローズド」は、データを必ずベンダーへ丸投げすることを意味しない。ClaudeのMemory Toolのように、モデルが操作を提案し、保存は利用者のインフラに残す方式もある。反対に、オープンソースでも、標準設定のLLMや埋め込みモデルを外部APIに頼れば、全経路が自社内に閉じるわけではない。

## オープンソースAIメモリ比較——五つの設計思想

オープンソース側の差は、検索アルゴリズム以上に、**記憶の最小単位**に表れる。

| 実装 | 記憶の最小単位 | 得意な設計 | 比較上の注意 |
|---|---|---|---|
| [Mem0](https://docs.mem0.ai/open-source/overview) | 会話から抽出した最小単位の事実 | `user` / `agent` / `run`でスコープを分け、`add`・`search`・`update`・`delete`の簡潔なAPIでアプリへ組み込みやすい。Apache-2.0でセルフホスト可能 | 現在のOSS版にGraph Memory、decay、temporal reasoning、Dreamは含まれず、[Platform固有機能](https://docs.mem0.ai/platform/platform-vs-oss)である |
| [Letta Code](https://github.com/letta-ai/letta-code) | 長寿命のAIエージェントが維持する状態、自己定義（identity）、経験、メモリブロック、参照可能な履歴 | AIエージェントそのものを持続する主体として扱い、文脈・スキル・プロンプトを自ら更新する。MemFSでは文脈をGitで追跡できる | 単独の検索部品というより、状態を保持するAIエージェント実行基盤であり、品質はAIエージェント自身の記憶管理にも依存する。旧`letta`リポジトリのV1実装は退役済み |
| [Graphiti](https://help.getzep.com/graphiti/getting-started/overview) | 時間とともに有効・無効が変わるエンティティ間の事実 | エピソードの来歴を残し、関係の変化を二つの時間軸を持つグラフ（bi-temporal graph）として保持し、意味検索・全文検索・グラフ検索・時間検索を組み合わせる。Apache-2.0でセルフホスト可能 | OSSのGraphitiと、独自エンジンで大規模運用する[Zep](https://help.getzep.com/zep-vs-graphiti)は同一製品ではない |
| [LangGraph Store / LangMem](https://docs.langchain.com/oss/python/concepts/memory) | アプリが定義するプロファイル、事実の集合、エピソード、手続き的プロンプト | 実行中の書き込みと、バックグラウンドでの振り返り（reflection）を組み合わせ、スキーマも保存先も開発者が選べる | 完成済みの記憶オントロジーではない。来歴、競合、期限、削除の意味はアプリ側が設計する |
| [EverOS](https://github.com/EverMind-AI/EverOS) | 読み書きできるMarkdownを正本とし、ユーザーのエピソード／プロファイルとAIエージェントのケース／スキルを分けて保持する | ローカルファーストのMarkdown + SQLite + LanceDB、Git管理、バックグラウンドでの振り返り（reflection）を組み合わせる。Apache-2.0でセルフホスト可能 | EverMemOSから発展した現在の公開アップストリーム。Tanka AIが採用するEverMemOS 1.0や論文時点の実装とは別版 |

一行に縮めるなら、Mem0は**事実**、Lettaは**AIエージェントが維持する自己状態**、Graphitiは**変化する関係**、LangMemは**アプリが定義する記憶型**、EverOSは**人とAIエージェントの経験を可読なファイルへ編成すること**を中心に据える。

これは優劣ではない。顧客の好みを一件ずつ取り出すなら原子化された事実は扱いやすい。価格や所属の変化を過去も含めてたどるなら時間グラフが効く。AIエージェントに自分の作業原則を育てさせるなら、編集可能な状態や手続き記憶が自然だ。**単位が違えば、適する検索方式も違う。**

## 「OSSかSaaSか」だけでは、開放性を測れない

開放性は二択ではなく、少なくとも五つに分解すべきである。

1. **コードを読んで変更できるか。**
2. **自社の環境で動かせるか。**
3. **保存先、LLM、埋め込みモデル、ベクトルストアを交換できるか。**
4. **記憶を、内容と構造の意味を保った形式でエクスポートできるか。**
5. **別の製品へ移しても、来歴・更新履歴・権限・有効期限を失わないか。**

Apache-2.0のリポジトリがあっても、四番と五番が自動的に満たされるわけではない。一方でClaudeはクローズド製品だが、個人メモリをテキストとして持ち出す経路を公開している。

本当に問うべきは、ベンダーロックインだけではない。**意味のロックイン**である。文字列をエクスポートできても、「これは誰の判断か」「まだ有効か」「誰に見せてよいか」が失われれば、記憶は移行の途中でただのメモに戻る。

## Tanka AIは、どこに置くべきか

Tanka AIを、上のOSS表の六番目に置くと理解を誤る。公開資料上、長期記憶基盤の系譜と、それを利用する商用製品を分けて見る必要がある。

第一は、オープンソースの長期記憶基盤である。2026年1月の[EverMemOS論文](https://arxiv.org/abs/2601.02163)と[旧系統の公開実装を残す第三者フォーク](https://github.com/NetMindAI-Open/EverMemOS)は、会話をMemCell、エピソード、プロファイルへ編成し、長期に検索・利用する設計を公開している。一方、現在の正規アップストリームである[EverOS](https://github.com/EverMind-AI/EverOS)は、Markdownを正本にしてSQLiteとLanceDBを同期し、ユーザーのエピソード／プロファイルとAIエージェントのケース／スキルを分けるローカルファーストの実装へ発展している。

第二は、商用のチーム向けアプリケーションである。Tanka AIの[公式技術記事](https://www.tanka.ai/zh/blogs/memory-is-not-storage-it-is-intelligent-data)は、EverMemOS 1.0をTanka AIに実装し、Tanka LinkからChat、Memo、Email、Google Docs、Notionなどを取り込むと説明する。また2025年12月までに1,000万件近くを処理したとしている。いずれもTanka AIの公式説明による。

したがって、**EverMemOS論文、旧実装のスナップショット、現在のEverOS、Tanka AIの本番実装は、関係する系譜ではあっても同一物として扱えない。** Tanka AIが採用するEverMemOS 1.0と現在のEverOSは、同じ系譜にある別の版として読む。

同じ記事は、削除、プライバシー、記憶の継承、ライフサイクル、ユーザーフィードバックによる更新を、今後の課題として挙げている。この点は重要である。長期記憶は、多く残せるだけでは完成しない。残した後の異議申立て、訂正、失効、削除まで含めて初めて運用になる。

ここで、証拠の層を明確にしておく。

| 確認できること | 根拠 |
|---|---|
| 現在のEverOSは公開コードを持ち、Markdownを正本に、SQLite / LanceDBによる検索と振り返り（reflection）を備える | 正規アップストリームの公開コードと文書で確認可能 |
| EverMemOS論文と旧系統の実装は、MemCell、エピソード、プロファイル形成と複数の検索方式を示す | 論文と旧系統の公開実装を残す第三者フォークで確認可能 |
| EverMemOS 1.0はTanka AIで利用され、複数の業務情報源を取り込んでいる | Tanka AIの公式説明 |
| `DECISION` / `COMMITMENT` / `ASSUMPTION` / `OPEN`、人による確認、`review_by`、`steward`、出典参照(`source`)を一体で扱う | [Kioku LabのMemory object v0.1](/notes/memory-object)が提案する評価軸 |

公開資料によれば、Tanka AIは、**EverMemOS 1.0の長期記憶設計を採用した、チーム／組織の記憶を対象とする商用アプリケーション**と位置づけられる。この領域で問われるのは、「AIが何を覚えるか」から一段先の問いである。

> **何が、誰の確認を経て、組織の記憶になる資格を得るのか。**

この問いに答える評価軸を、Kioku Labは[Memory object v0.1](/notes/memory-object)として提示している。

## ベンチマークが測る記憶、測らない記憶

AIメモリ製品の比較で、もっとも扱いが難しいのがスコアだ。本稿では各社が公表するスコアを横一列に並べない。

| ベンチマーク | 主に測るもの | それだけでは証明しないもの |
|---|---|---|
| [LoCoMo](https://aclanthology.org/2024.acl-long.747/) | 長い複数セッションの二者会話からのQA、時系列・複数段階の推論、イベント要約。公式QA評価は主にトークン単位F1 | 複数のリクエストをまたぐ持続的書き込み、削除、権限、正式決定、責任、引き継ぎ |
| [LongMemEval](https://arxiv.org/abs/2410.10813) | 情報抽出、複数セッション推論、知識更新、時間推論、答えがない時の棄権 | 単一利用者を越えたアクセス制御、決定／未決、出典の権威、組織の責任 |
| [LongMemEval-V2（2026 preprint / Work in Progress）](https://arxiv.org/abs/2605.12493) | 大量の過去のWebエージェントの行動履歴から、環境状態、作業手順、失敗しやすい点を取り出す能力 | 実運用中のオンライン学習、仕事全体の成否、組織内の承認と引き継ぎ |
| [GateMem（2026 preprint）](https://arxiv.org/abs/2606.18829) | 複数主体・組織場面での権限内の有用性、文脈に応じたアクセス制御、明示削除後に検索結果へ出さないこと | 決定の確定権限、未決事項、来歴と責任を保った一般的な引き継ぎ |

同じベンチマーク名の数値でも、データセットの版、対象タスク、回答モデル、上位何件を検索するか、投入トークン数、取り込み方法、採点方法が違えば、同じ能力を測っているとは限らない。LoCoMoの公式QAは主にトークン単位F1を用いる一方、LongMemEvalのend-to-end評価はLLMによる正答判定を使う。検索段階のRecall@kと最終回答の正答率も、同じ「正答率」としては比べられない。

したがって、ある製品がLoCoMoで高得点だったとしても、正確に言えるのは「その条件で、長い会話から必要な情報を取り出し利用できた」までである。**誰の権限で確定した判断か、誰に見せてよいか、何が未決か、担当交代後も出典と責任が残るかは、別の試験が要る。**

共有メモリの権限を測るGateMemなど、新しい試みは始まっている。しかし、権限・決定状態・来歴・期限・引き継ぎ・責任を一つの公開評価系で同時に扱うベンチマークは、今回確認した範囲ではまだ見当たらない。これはTanka AIだけの課題ではない。**AIメモリ産業全体に残る評価上の空白である。**

## 選ぶ前に、六つだけ問う

製品名より先に、次の六問に答えると選択肢はかなり絞れる。

1. **主体は誰か。** 一人の利用者か、一つのAIエージェントか、一つの案件か、チームか、組織か。
2. **記憶の最小単位は何か。** 好み、事実、エピソード、関係、手順、決定、約束、未決事項のどれか。
3. **書き込みを誰が確定するか。** AIが自動で残すのか、人が確認するのか、権限者の承認が要るのか。
4. **矛盾と時間をどう扱うか。** 上書きするのか、履歴を残すのか、古い事実を失効させるのか。
5. **誰に見えるか。** 検索結果から後段で除外するのか、検索対象そのものにスコープとACLを適用するのか。
6. **持ち出したときに意味が残るか。** 本文だけでなく、出典、確認者、更新履歴、権限、期限もエクスポートできるか。

そして、担当交代後も仕事を続けたい組織がTanka AIを評価するなら、「検索できたか」だけでPoCを終えてはいけない。**出典へ戻れるか、決定と未決を混同しないか、権限が変わっても漏れないか、古い判断を失効できるか、記憶を次の担当者や別のシステムへ渡せるか**を試すべきである。[実際の引き継ぎ事例](/notes/handover)を使って試験すれば、デモの検索精度と業務継続性を分けて見られる。

## AIメモリについて、よくある質問

### AIメモリとRAGの違いは何か

RAGは、外部情報を検索して現在の推論へ渡す読み出しの仕組みである。AIメモリは、それに加えて何を残すか、どう更新・失効・削除するかという書き込みとライフサイクルを持つ。**AIメモリはRAGを利用できるが、RAGはAIメモリ全体ではない。**

### ChatGPTやClaudeのメモリは、エージェントメモリと同じか

同じではない。ChatGPTやClaudeの製品機能は主にユーザーへの個人化と会話の継続を目的とする。エージェントメモリは、開発者が作るAIエージェントの状態、経験、手順を複数の実行へ持ち越すための基盤を指すことが多い。

### オープンソースで最も優れたAIメモリはどれか

一つには決められない。簡潔な事実抽出ならMem0、AIエージェント自体の持続ならLetta、時間と関係ならGraphiti、独自スキーマならLangGraph Store / LangMem、可読なファイルを正本にした人とAIエージェントの記憶ならEverOSというように、記憶単位で適性が変わる。ライセンスだけでなく、セルフホスト、外部モデル依存、エクスポート形式、更新規則も確認すべきだ。

### Tanka AIとEverMemOS / EverOSの違いは何か

EverMemOSは2026年の論文と旧実装で示された長期記憶基盤で、現在の正規アップストリームはEverOSへ発展している。Tanka AIは、EverMemOS 1.0を利用していると公式に説明する商用のチーム向けアプリケーションである。論文、旧実装、現行EverOS、Tanka AIの本番実装は同一ではなく、一つから他の機能を推定することはできない。

### AIメモリのベンチマークで一位なら、組織にも最適か

そうとは限らない。LoCoMoやLongMemEvalは、長い履歴から情報を取り出し、時間関係や更新を理解する能力を主に測る。権限、正式な決定、未決事項、出典の権威、担当交代後の責任まで同時には測っていない。

### オープンソースならプライバシーと可搬性は保証されるか

保証されない。セルフホストできても外部LLMへデータを送る設定はあり得るし、本文をエクスポートできても来歴・権限・期限が失われる場合がある。コード、導入形態、保存先、モデル依存、スキーマ、エクスポートを別々に確認する必要がある。

## 誰のための過去なのか

この市場は、確実に前へ進んでいる。個人向けメモリは「毎回説明する」負担を減らし、エージェントメモリはセッションを越えて学びを残し、オープンソースは事実・状態・時間・経験という異なる記憶単位を実装できるようにした。

だが、多くのAIメモリが最適化しているのは、まだ**AIが思い出せること**である。

[組織の記憶](/notes/organizational-memory)が問うのは、過去を思い出せるかだけではない。その過去を、いまの判断に使ってよいのか。誰が確定し、誰が異議を唱えられ、いつ見直し、次の担当者へ何を渡すのか。そして、それを次の推論で使える[文脈へ変換できるか](/notes/as-fast-as-context)。そうした条件まで満たして、初めて仕事は続く。

> **AIが過去を思い出せるだけでは、組織の記憶にはならない。誰の判断で、いまも有効なのか。誰が修正できるのか。その情報まで残って、初めて引き継げる。**

AIメモリの次の競争では、記憶容量や検索精度だけでなく、**記憶の正当性を管理し、判断に用いる能力**が問われる。

---

### 出典・調査方法

各製品について公開された公式ドキュメント、正規リポジトリ、論文を優先し、マーケティング上のベンチマーク値は共通条件を確認できない限り順位づけに用いなかった。以下はすべて2026年8月23日に最終確認した。

#### 個人向け製品

- OpenAI｜ChatGPT Memory｜現行ヘルプ｜[Memory and new controls for ChatGPT](https://help.openai.com/en/articles/8590148-memory-and-new-controls-for-chatgpt)
- Anthropic｜Claudeのチャット検索と記憶｜現行ヘルプ｜[Use Claude’s chat search and memory](https://support.claude.com/en/articles/11817273-use-claude-s-chat-search-and-memory-to-build-on-previous-context)
- Anthropic｜Claudeの記憶の移行｜実験的機能｜[Import and export your memory from Claude](https://support.claude.com/en/articles/12123587-import-and-export-your-memory-from-claude)
- Google｜Geminiの過去チャットによる個人化｜現行ヘルプ｜[Get personalization with memory of your past Gemini chats](https://support.google.com/gemini/answer/16598469)

#### AIエージェント向け基盤

- Anthropic｜Claude API Memory Tool｜現行API文書｜[Memory Tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool)
- Amazon Web Services｜Bedrock AgentCore Memory｜現行開発者ガイド｜[How AgentCore Memory works](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html)
- Google Cloud｜Agent Platform Memory Bank（旧Vertex AI Memory Bank）｜現行製品文書｜[Agent Platform Memory Bank](https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/memory-bank)
- Microsoft｜Foundry Agent Service Memory｜Preview｜[Create and use memory in Foundry Agent Service](https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/memory-usage)

#### オープンソース実装

- Mem0｜OSS版｜現行文書｜[Open Source Overview](https://docs.mem0.ai/open-source/overview)
- Mem0｜PlatformとOSSの差分｜現行文書｜[Platform vs OSS](https://docs.mem0.ai/platform/platform-vs-oss)
- Letta｜Letta Code｜現行正規リポジトリ｜[letta-ai/letta-code](https://github.com/letta-ai/letta-code)
- Graphiti / Zep｜Graphiti｜現行文書｜[Graphiti overview](https://help.getzep.com/graphiti/getting-started/overview)
- LangChain｜LangGraph Store / LangMem｜現行文書｜[Memory concepts](https://docs.langchain.com/oss/python/concepts/memory)
- EverMind｜EverOS｜現行正規アップストリーム｜[EverMind-AI/EverOS](https://github.com/EverMind-AI/EverOS)
- NetMindAI-Open｜EverMemOS｜旧系統の実装を残す非正規フォーク｜[NetMindAI-Open/EverMemOS](https://github.com/NetMindAI-Open/EverMemOS)

#### 評価研究とTanka AI

- Maharana et al.｜LoCoMo｜ACL 2024｜[Evaluating Very Long-Term Conversational Memory of LLM Agents](https://aclanthology.org/2024.acl-long.747/)
- Wu et al.｜LongMemEval｜ICLR 2025｜[Benchmarking Chat Assistants on Long-Term Interactive Memory](https://arxiv.org/abs/2410.10813)
- Wu et al.｜LongMemEval-V2｜2026 preprint / Work in Progress｜[LongMemEval-V2](https://arxiv.org/abs/2605.12493)
- GateMem preprint｜GateMem｜2026 preprint｜[GateMem](https://arxiv.org/abs/2606.18829)
- Hu et al.｜EverMemOS｜2026 preprint｜[A Self-Organizing Memory Operating System](https://arxiv.org/abs/2601.02163)
- Tanka AI｜EverMemOS 1.0の製品利用に関する公式説明｜2026年公開記事｜[記憶はストレージではなく、知性あるデータである](https://www.tanka.ai/zh/blogs/memory-is-not-storage-it-is-intelligent-data)

### 外部での言及

- Zenn「「AIメモリ」は 4 層ある——個人・エージェント・基盤・組織の記憶」(2026-09-03)— https://zenn.dev/llmjp/articles/86b7428d19027a

---

Source: https://kiokulab.com/notes/ai-memory-comparison-2026 · Contact: info@kiokulab.com