2026年版 AI Agent Memory プラットフォーム徹底比較：エンタープライズ導入チェックリスト

要点

• agent memory を単一機能として評価してはいけない。ストレージと検索、ガバナンス、分配を別レイヤーとして評価する。
• ベクター専用メモリはリコールには有用だが、スコープ付き書き込み、レビュー、監査ログ、ロールバックを提供しない。
• マネージド memory サービスや SDK は導入を加速するが、エンタープライズ側には「agent が何を保存・変更・忘却してよいか」のポリシーが依然として必要。
• グラフメモリはユーザー事実と関係に強く、ファイル形式のメモリは agent が共有成果物を生み出すケースで強い。
• Agents Filesystem は、複数 agent が永続ファイル、パス単位の権限、バージョン履歴、レビュー可能な変更を必要とするときに不可欠となる。

なぜ agent memory がインフラ上の意思決定になったか

チームが「agent memory が必要」と言うとき、実際には少なくとも3つの異なる課題を同時に指している。

1. agent にはセッションをまたいで覚えていてほしい：設定、決定、未完了タスク、以前のコンテキスト。
2. agent には必要な根拠を必要なときだけ取り出してほしい。会話全文をプロンプトに詰め込むのではなく。
3. agent が共有コンテキストを変えられるなら、memory 書き込みを統制できる必要がある。

最初の2つはいまや当たり前の要件だ。3つ目こそが本番システムで最も居心地悪くなる部分になる。

コンテキストウィンドウがいくら大きくなっても、それはワーキングセットに過ぎない。ポリシーエンジンでも、永続ストアでも、レビューワークフローでも、ロールバック機構でもない。agent が質問に答えるだけなら検索で十分かもしれない。しかし agent がオンボーディング資料、インシデント runbook、アカウントプラン、ポリシー要約、生成レポートを更新するようになった瞬間、メモリは運用状態（operational state）になる。

Cloudflare の現行 Agents ドキュメントは、永続的な会話ストレージ、context block、圧縮、検索、AI が制御できる memory ツールを Session API として整理している（Cloudflare Agents memory ドキュメント、Session API リファレンス）。Redis も別の視点から同じ転換を示している：agent memory は、ステートレスなモデル呼び出しをステートフルなシステムに変えるためのインフラである、と（Redis agent memory 概要）。

これらは有用なシグナルだ。しかし購買側の問いはもっと狭い：実際に制御したい失敗モードに、どのタイプの memory プラットフォームが適合するか？

memory プラットフォームを評価する3層モデル

ほとんどの比較は何もかもを「long-term memory」に押し込める。結果として、チームは良い retriever を買った後、依然として安全にリリースできない現実に気づく。

代わりに3層モデルを使う。

レイヤー	何に答えるか	欠けたときの典型的な失敗
Memory レイヤー	どう保存、ランク付け、検索、要約、期限切れを行うか	無関係なリコール、古い事実、重複メモリ、高いトークンコスト
ガバナンスレイヤー	誰が読み、書き、承認、削除、監査、ロールバックできるか	サイレントドリフト、危険なパーソナライズ、コンプライアンスギャップ、復旧経路の不在
分配レイヤー	複数の agent、ツール、ランタイム、人間が同じコンテキストをどう消費するか	フレームワークロックイン、コピーされたコンテキスト、一元的な真実の崩壊

多くのプラットフォームがまず宣伝するのは memory レイヤーだ。しかし、マルチエージェントと実在の企業データに晒されたときにシステムが生き残るかを決めるのは、ガバナンスレイヤーと分配レイヤーである。

コンテキストをインフラとして考え始めているチームは、ファイルワークスペースの観点を掘り下げた puppyone の記事 AI agent infrastructure and versioned filesystems も併せて読むと良い。

memory、ファイル、ロールバックが必要な agent のために、ガバナンス済みコンテキスト層を構築Get started→

agent memory アプローチの実務比較

有用な比較は「どのツールが最高か」ではない。「このワークフローにどのアーキテクチャが合うか」だ。

アプローチ	適する場面	得られるもの	それでも自分で解く必要があるもの
マネージド memory サービス	単一のクラウドや agent ランタイム上で構築中のチーム	永続セッション、context block、圧縮、管理されたストレージパターン	クロスプラットフォーム分配、組織横断の書き込みポリシー、より深いレビュー
Memory SDK / レイヤー	迅速にパーソナライズやスコープ付きリコールを追加したい製品チーム	memory 追加・検索・スコープ付けの API	同意、保持、シークレット、監査、ロールバック
セッション & ナレッジグラフメモリ	会話中心で、ユーザー事実と関係が価値を持つ製品	抽出された事実、ユーザーグラフ、グループグラフ、解釈可能な関係	変更承認、真実の源ガバナンス、運用成果物の扱い
ステートフル agent ランタイム	長時間実行、自分でメモリツールを扱う agent	agent レベルの memory 操作とツール駆動のリコール	チームとランタイムをまたいだ共有コンテキストのガバナンス
自前の基盤	データ、遅延、コンプライアンスに厳格な要件があるプラットフォームチーム	ストレージ、インデックス、デプロイ、可観測性への最大の制御	抽出ロジック、UX、ポリシー、評価、長期運用
Agents Filesystem	共有ファイル、成果物、ガバナンス付き書き込みを伴うマルチエージェントワークフロー	agent 可読な構造、永続ファイル、パス単位権限、バージョニング、ロールバック	memory ポリシー設計、承認ゲート、検索とオーケストレーションとの統合

この表は意図的に「唯一の勝者」を立てない。サポート chatbot、コーディング agent、財務バックオフィス agent のメモリ問題は同じではない。

マネージド memory サービス

マネージド memory サービスの魅力は、永続化、圧縮、検索をランタイムプリミティブとして束ねる点にある。Cloudflare の Agent memory モデルは、agent がツール経由で検索・読み込み・更新できるセッションストレージと context block を中心に据えている。

適する場面：

• agent がすでに当該プロバイダの agent フレームワーク内で稼働している
• 主な痛みはセッションやワークフローをまたいで有用なコンテキストを保つことである
• 圧縮・リコールのカスタムパイプラインを減らしたい
• プロバイダのデプロイおよびデータモデルを受け入れられる

注意点：

• マネージド memory プリミティブは、自動的にエンタープライズ統制モデルになるわけではない。
• 複数 agent が共有運用コンテキストに書き込むなら、レビュー、バージョニング、保持、ロールバックが別途必要。
• 複数のクライアント、IDE、ジョブランナー、サンドボックスをまたいで agent が走るなら、プロバイダ純正 memory はより大きなシステムの1つの島になるかもしれない。

マネージド memory は配管工事を減らすために使う。ポリシー層の代替とは見なさない。

Memory SDK とスコープ付き memory レイヤー

永続パーソナライズ、スコープ付きリコール、ランタイム全面採用なしの memory API が欲しい場合、多くは SDK が最速の道だ。

Mem0 はその好例で、ドキュメントが会話・セッション・ユーザー・組織メモリを区別している。また、取得可能なメモリにシークレットや未マスクの PII を置かないよう注意している（Mem0 memory types）。スコープがなければ「memory」は雑多な引き出しになる。

適する場面：

• ユーザーまたはワークスペース単位のパーソナライズが必要
• 既存アプリにメモリを追加したい
• memory 書き込み経路を自社アプリが制御している
• 同意、保持、削除ポリシーを SDK 外で強制できる

注意点：

• SDK は API を提供するだけで、完全な運用モデルではない。
• 組織メモリはユーザーメモリより遥かに危険で、1回の誤書き込みが大量のユーザーや agent に波及しうる。
• memory 抽出は無害なキャッシュ更新ではなく、書き込み操作として扱う。

実務上の起点ルール：セッションメモリからユーザー／組織メモリへ昇格するものには、必ずオーナー、TTL もしくは保持ポリシー、監査ログを付ける。

グラフメモリ

重要情報が関係性（人、アカウント、設定、エンティティ、ポリシー、依存、時系列イベント）であるとき、グラフ指向メモリが最も強い。

たとえば Zep のドキュメントは、セッション固有のチャット履歴に加え、検索可能なユーザーナレッジグラフとグループグラフを扱う（Zep quickstart、Zep group graph ガイド）。事実と関係が明示構造になるため、埋め込みだけの手法よりも解釈可能性が高い。

適する場面：

• 会話ファーストの製品
• 共有ファイル成果物よりもユーザー事実と関係が重要
• 「この人／アカウント／グループについて何を知っているか？」に答えたい
• 生の文書検索より説明可能性が重視される

注意点：

• 抽出されたグラフは書き込みプロセスと同等にしか信頼できない。
• プロヴェナンスがないと関係更新がサイレントにドリフトする。
• runbook、ポリシー文書、生成計画やレポートといった運用ファイルは、会話中心のグラフにきれいに収まらない。

グラフメモリはしばしば context base の補完であり、代替ではない。

ステートフル agent ランタイムとファイル形式メモリ

ステートフルランタイムは、agent にメモリ操作のためのツールを与える：読み、書き、検索、要約、再構成。Letta のメモリベンチマークは実務的な論点を浮かび上がらせた：メモリ性能はストレージバックエンドだけでなく、agent がそのメモリツールを信頼性高く使えるかにも依存する（Letta memory benchmark）。

ここでファイル形式のメモリが面白くなる。agent はファイル操作と相性が良い：一覧、読み取り、検索、編集、diff、書き込み。開発者はファイルレビューに慣れている。セキュリティチームもパス、マウント、ID、監査ログで推論するのに慣れている。

適する場面：

• agent が回答だけでなく永続成果物を生み出す
• agent がプラン、ワーキングファイル、決定、出力フォルダを必要とする
• 人間が変更差分をレビューする
• 複数 agent が共有コンテキスト上で協調する

注意点：

• ファイルは簡単だが、共有ファイルは難しい。
• ID、ACL、バージョン履歴、ロールバックのないローカルフォルダは、統制された memory プラットフォームではない。
• ファイルメモリは検索、評価、ポリシーチェックと組み合わせる必要がある。

ファイル単位のセーフティパターンは、puppyone の AI agent 向けファイルシステム設計 を参照。

自前 memory 基盤

一部のチームはスタックをもっと自前で持つべきだ。データ所在地、遅延、デプロイ構成、統合深度が本質要件なら、組み合わせ可能な基盤が正解になりうる。

Redis はよく使われる例で、低遅延ステート、キャッシュ、ベクター検索を一つのスタックに収められる。記事はエンコード、保存、検索、agent 応答への統合のパイプラインを示す。名前が付く部分はそこまでで、周辺が本当に難しい：

• ゴミを保存せずにメモリを抽出する
• 何を永続化するかを判断する
• ユーザー、セッション、組織、agent、ワークフロー単位で scope を切る
• 保持と削除を強制する
• なぜ memory が書かれた／読まれたかを記録する
• 検索品質とタスク結果を評価する

適する場面：

• プラットフォームチームが memory サービスを長期所有できる
• 厳格な制御要件がある
• カスタム評価と可観測性が必要
• どのベンダーモデルもアーキテクチャに合わない

注意点：

• ベクターストア + サマライザは製品化された memory プラットフォームではない。
• agent が書けるようになった瞬間にメンテ面積は急増する。
• 「pilot の後で統制を」は通常「書き直し」に化ける。

制御そのものが目的なら自作。プラットフォーム工学が差別化要因でないなら採用か購入。

Agents Filesystem が正しい memory 層になるとき

Agents Filesystem は単なるフォルダではない。agent のために設計された、統制されたコンテキストワークスペースだ。

次の条件で正解になる：

• agent がなじみあるファイル操作で共有の社内コンテキストを読む
• agent がプラン、要約、レポート、設定、変換済みデータを書き込む
• パス単位の読み書き権限で動く
• MCP、REST、CLI、サンドボックスマウントで公開される
• レビューとロールバックのために履歴を保持する
• 人間がチャットログではなく成果物として変更を確認する

まさにこれが puppyone が解こうとしている問題だ：社内データソースを接続し、コンテキストを Markdown や JSON のような agent 可読ファイルとして表現し、Access Point でアクセスをスコープ化し、agent ネイティブなインターフェースで公開し、バージョン履歴と監査ログを agent の作業に付ける。

ただし、全チームがいきなりフルスペックのファイル層から始める必要はない。chatbot に per-user 設定だけなら memory SDK で足りる。しかし agent が共有 runbook、ポリシー要約、コンテキストファイル、ワークフロー成果物を編集するなら、統制されたファイルシステムが復旧モデルを強化する。

重要な区別はシンプルだ：検索メモリは agent の記憶を助ける。統制されたファイルシステムはチームが agent の変更を信頼することを助ける。

2週間 bakeoff チェックリスト

プラットフォームを選ぶ前に、小さな bakeoff を走らせる。汎用デモではなく、代表的な2〜3個のワークフローを使う。

テスト	何を測るか	なぜ重要か
厳密リコール	ID、ポリシー名、アカウント事実、最新決定	運用上の事実には意味的類似度では不十分
鮮度処理	古い事実が抑制または期限切れ表示されるか	agent は期限切れのコンテキストを蘇らせてはならない
書き込み安全性	誰が書けるか、どこに着地するか、どうレビューするか	メモリ書き込みはミューテーションである
マルチエージェント隔離	低信頼 agent が共有コンテキストを汚染しないか	一つの悪書き込みを拡散させない
説明可能性	なぜそのメモリが検索・更新されたか	デバッグにはトレースが必要
ロールバック	直前状態にどれほど素早く戻せるか	悪メモリと悪ファイルは必ず発生する
移植性	複数ランタイムが同じコンテキストを使えるか	エンタープライズ agent が一生同じクライアントに留まることは稀

bakeoff は決定のために使う。最もきれいなデモを称賛するためではない。

意思決定ルーブリック

アーキテクチャ議論が曖昧になったときの近道。

• agent がすでに特定ランタイム上にあり、主な要件が永続セッションコンテキストなら、マネージド memory サービスを選ぶ。
• 既存アプリにスコープ付きパーソナライズを追加し、ガバナンスは自社製品内で強制できるなら、memory SDK を選ぶ。
• ユーザー、アカウント、事実、イベントの関係が中心価値なら、グラフメモリを選ぶ。
• agent 自身が memory ツールと長時間ワークフローを強く制御する必要があるなら、ステートフルランタイムを選ぶ。
• デプロイ制御が速度より重要なら、自前基盤を選ぶ。
• 複数 agent が共有成果物を書き、人間が権限・diff・監査・ロールバックを必要とするなら、Agents Filesystem を選ぶ。

より深いアーキテクチャの枠組みには、このチェックリストを Context Engineering：RAG では足りないとき と併読してほしい。分水嶺は似ている：単純なリコールは単純な検索で解けるが、本番 agent には構造化・統制・再利用可能なコンテキストが必要だ。

puppyone をあなたの agent スタックの統制された memory/ファイル層として評価するGet started→

FAQ

Q1: agent memory と RAG の違いは？

RAG は通常、関連ドキュメントを取得してプロンプトに追加する検索パターン。agent memory はもっと広い。永続設定、決定、ワークフロー状態、成果物、書き込みポリシー、保持ルール、そしてそれらを後から検索・変更する仕組みを含む。

Q2: ベクターデータベースを agent memory プラットフォームにできるか？

プラットフォームの一部にはなる。全体になることは稀。ベクター検索は意味的リコールに有効だが、エンタープライズ agent memory には確定的ルックアップ、スコープ付き権限、変更履歴、監査、保持、ロールバックも必要。

Q3: チームは何から実装すべきか？

まず scope：セッション、ユーザー、組織、agent ロール、ワークフロー。次に、保存してよいもの／絶対保存してはいけないもの、共有メモリに誰が書けるか、ロールバック方法を定義する。それが済んだ上でインデックスと検索を最適化する。

Q4: puppyone はこの意思決定のどこで適合するか？

memory がパーソナライズや検索だけではなく、共有の運用コンテキストでもある場合に puppyone は適合する。統制されたファイル、MCP 経由アクセスのコンテキスト、サンドボックスマウント、バージョン履歴、監査ログが必要なら、puppyone は既存のモデルとランタイムを囲む context base と Agents Filesystem のレイヤーになれる。