Agent memory providerとは何ですか？

Agent memory providerは、AIアシスタントのためにセッションをまたいで事実を保存・取得します。Agent frameworkはこれらをプラグインとして公開しており、これによりユーザーの好み、プロジェクトに関する事実、および要約された会話の洞察を、単一のチャットスレッドを超えて保持することが可能になります。

これらの8つのプロバイダーをサポートしているフレームワークには、どのようなものがありますか？

Hermes Agentは、hermes memory setupを通じてこれら8つすべてを統合します。OpenClawおよび関連するエコシステムは、HonchoやSupermemoryを含むいくつかの共通のバックエンド向けにプラグインを提供しています。その他のスタックについては、ベンダーに応じてHTTP APIまたはMCPを介して統合することが可能です。

LLMやembeddingの呼び出しを一切行わずに実行できるプロバイダーはどれでしょうか？

Holographicは、holographic reduced representation algebraのみを使用しており、LLM、embeddings、データベース、およびネットワークコールを一切使用しません。この比較における他のすべてのプロバイダーは、抽出または検索のために、少なくとも1つのLLMコールまたはリモートサービスに依存しています。

外部メモリを完全にオンプレミスで運用することは可能でしょうか？

いくつかのプロバイダーは、推論用のOllamaまたはOpenAI互換エンドポイントに加え、必要に応じてローカルのPostgreSQL、Qdrant、あるいはバンドルされたデータベースを使用することで、完全なローカルスタックをサポートしています。一方で、RetainDBおよびSupermemoryのデフォルトのクラウドサービスでは、同等の保証を備えたローカル限定のデプロイには対応していません。

Agent Memory Providersの比較 — Honcho、Mem0、Hindsight、およびその他の5社

エージェントの永続的なメモリを実現する、8種類のプラグ可能なバックエンド。

現代のアシスタントは、コンテキストウィンドウを超えて何かが保持されない限り、タブを閉じるとすべてを忘れてしまいます。**Agent memory providers（エージェントメモリプロバイダー）**は、セッションをまたいで事実や要約を保持するサービスまたはライブラリです。これらは多くの場合、フレームワークを軽量に保ちながらメモリを拡張できるように、プラグインとして組み込まれます。

このガイドでは、Hermes Agentの外部メモリプラグインとして提供されている8つのバックエンド — Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、Supermemory — を比較し、それらがより広範な AI systems スタックにどのように適合するかを説明します。これらと同じベンダーが、コミュニティまたは公式の統合を通じて、OpenClaw やその他のエージェントツールにも登場します。AI Systems Memory hub には、この記事が Cognee や関連ガイドと並んで掲載されています。

Hermes固有の境界付きコアメモリ（MEMORY.md および USER.md）、凍結動作、およびトリガーについては、Hermes Agent Memory System を参照してください。

Hermes Agentは、永続的でセッションをまたいだ知識を提供するために、8つの外部メモリプロバイダープラグインをリストしています。一度にアクティブにできる外部プロバイダーは1つだけです。組み込みの MEMORY.md と USER.md は、それらと並行してロードされたままになります。これらは置き換えではなく、追加として機能します。

外部依存関係。 Holographic をを除くすべての外部プロバイダーは、少なくとも1つの外部サービス呼び出し（メモリ抽出用のLLM、セマンティック検索用のエンベディングモデル、またはストレージ用の PostgreSQL のようなデータベース）を必要とします。これらの依存関係は、プライバシー、コスト、およびメモリスタックを完全に self-hosted して実行できるかどうかに直接影響します。Hindsight と ByteRover は依存関係を最小限に抑えるか、あるいは排除しています。一方、Honcho、Mem0、Supermemory は最も多くの構成要素を必要とします。プロバイダーが Ollama やその他の OpenAI 互換エンドポイントをサポートしている場合、LLM やエンベディングの呼び出しをローカルモデルにルーティングし、データをサードパーティのサーバーから完全に切り離すことができます。

ai agent memory system providers

Hermes Agent によるアクティベーション

hermes memory setup   # インタラクティブな選択 + 設定
hermes memory status  # アクティブなものを確認
hermes memory off     # 外部プロバイダーを無効化

または、~/.hermes/config.yaml で手動で行うこともできます：

memory:
  provider: openviking  # または honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

プロバイダー比較

プロバイダー	ストレージ	コスト	外部依存関係	セルフホスト可否	特徴的な機能
Honcho	クラウド/セルフホスト	有料/無料	LLM + Embedding model + PostgreSQL/pgvector + Redis	はい — Docker / K3s / Fly.io	対話的なユーザーモデリング + セッション範囲のコンテキスト
OpenViking	セルフホスト	無料	LLM (VLM) + Embedding model	はい — ローカルサーバー; Ollamaネイティブな初期設定ウィザード	ファイルシステム階層 + 階層型ロード
Mem0	クラウド/セルフホスト	有料/無料 OSS	LLM + Embedding model + Vector store (Qdrant or pgvector)	はい — Docker Compose OSS; 完全ローカルも可能	サーバーサイドでのLLM抽出
Hindsight	クラウド/ローカル	無料/有料	LLM + 同梱のPostgreSQL + 内蔵エンベッダー + 内蔵リランカー	はい — Docker または内蔵Python; Ollamaで完全ローカル化可能	ナレッジグラフ + `reflect` による合成
Holographic	ローカル	無料	なし	ネイティブ — インフラ不要	HRR代数 + 信頼スコアリング
RetainDB	クラウド	$20/月	クラウド管理 (RetainDBサーバー上でLLM + 検索を実行)	いいえ	デルタ圧縮
ByteRover	ローカル/クラウド	無料/有料	LLMのみ — エンベディングモデルなし、DBなし	はい — デフォルトでローカルファースト; Ollamaをサポート	ファイルベースのコンテキストツリー; エンベディングパイプラインなし
Supermemory	クラウド	有料	LLM + PostgreSQL/pgvector (エンタープライズ向けCloudflareデプロイ)	エンタープライズプランのみ	コンテキストフェンシング + セッショングラフ取り込み

詳細な内訳

Honcho

最適：マルチエージェントシステム、セッションをまたいだコンテキスト、ユーザーとエージェントのアライメント。

Honchoは既存のメモリと並行して動作します。USER.md はそのまま維持され、Honchoは追加のコンテキストレイヤーを追加します。会話を、メッセージを交換するピア（対等な存在）としてモデリングします。各Hermesプロファイルにつき、1人のユーザーピアと1人のAIピアが存在し、すべてがワークスペースを共有します。

外部依存関係： Honchoには、セッションの要約、ユーザー表現の導出、および対話的推論のためのLLM、観察内容全体のセマンティック検索のためのエンベディングモデル、ベクトルストレージ用のpgvector拡張機能付きPostgreSQL、およびキャッシュ用のRedisが必要です。api.honcho.dev のマネージドクラウドがこれらすべてを処理します。セルフホスト展開（Docker、K3s、またはFly.io）の場合、独自の認証情報を提供する必要があります。LLMスロットはOllamaやvLLMを含むあらゆるOpenAI互換エンドポイントを受け付けるため、推論をオンプレミスに留めることができます。エンベディングスロットはデフォルトで openai/text-embedding-3-small ですが、LLM_EMBEDDING_API_KEY と LLM_EMBEDDING_BASE_URL を介して設定可能なプロバイダーをサポートしています。vLLMとBGEモデルのようなローカルオプションを含む、あらゆるOpenAI互換エンベディングサーバーが使用可能です。

ツール： honcho_profile (ピアカードの読み取り/更新)、honcho_search (セマンティック検索)、honcho_context (セッションコンテキスト — 要約、表現、カード、メッセージ)、honcho_reasoning (LLM合成)、honcho_conclude (結論の作成/削除)。

主要な設定パラメータ：

contextCadence (デフォルト 1): ベースレイヤーの更新間隔（最小ターン数）
dialecticCadence (デフォルト 2): peer.chat() LLM呼び出しの間隔（推奨 1-5）
dialecticDepth (デフォルト 1): 1回の呼び出しあたりの.chat()パス数 (1-3に制限)
recallMode (デフォルト ‘hybrid’): hybrid (自動+ツール), context (注入のみ), tools (ツールのみ)
writeFrequency (デフォルト ‘async’): フラッシュのタイミング: async, turn, session, または整数 N
observationMode (デフォルト ‘directional’): directional (すべてオン) または unified (共有プール)

アーキテクチャ： 2レイヤーのコンテキスト注入 — ベースレイヤー (セッション要約 + 表現 + ピアカード) + 対話的補足 (LLM推論)。コールドスタート用とウォームプロンプトを自動的に選択します。

マルチピア・マッピング： ワークスペースはプロファイル間で共有される環境です。ユーザーピア (peerName) はグローバルな人間としてのアイデンティティです。AIピア (aiPeer) はHermesプロファイルごとに1つ存在します (hermes がデフォルト、その他は hermes.<profile>)。

セットアップ：

hermes memory setup  # "honcho" を選択
# またはレガシー方式: hermes honcho setup

設定ファイル: $HERMES_HOME/honcho.json (プロファイルローカル) または ~/.honcho/config.json (グローバル)。

プロファイル管理：

hermes profile create coder --clone  # 共有ワークスペースを持つ hermes.coder を作成
hermes honcho sync                   # 既存のプロファイルにAIピアをバックフィル

OpenViking

最適：構造化されたブラウジングを伴う、セルフホスト型の知識管理。

OpenVikingは、階層型ロードを備えたファイルシステム階層を提供します。これは無料で [self-hosted](https://www.glukhov.org/ja/llm-hosting/self-hosting/llm-selfhosting-and-ai-sovereignty/）であり、メモリストレージを完全に制御できます。

外部依存関係： OpenVikingは、セマンティック処理とメモリ抽出のためのVLM (Vision-Language Model)、およびベクトル検索のためのエンベディングモデルを必要とし、これらはどちらも必須です。サポートされているVLMプロバイダーには、OpenAI、Anthropic、DeepSeek、Gemini、Moonshot、およびvLLM (ローカル展開用) が含まれます。エンベディングについては、OpenAI、Volcengine (Doubao)、Jina、Voyage、およびOllama経由のあらゆるローカル提供エンベディングモデルがサポートされています。openviking-server init インタラクティブウィザードは、利用可能なRAMを検出して適切なOllamaモデル（例：エンベディングには Qwen3-Embedding 8B、VLMには Gemma 4 27B）を推奨し、完全なローカル、ゼロAPIキーの設定のためにすべてを自動的に構成できます。外部データベースは必要ありません。OpenVikingはメモリをファイルシステムに保存します。

ツール： viking_search, viking_read (階層型), viking_browse, viking_remember, viking_add_resource.

セットアップ：

pip install openviking
openviking-server init   # インタラクティブウィザード (ローカル設定用にOllamaモデルを推奨)
openviking-server
hermes memory setup  # "openviking" を選択
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

最適：自動抽出による、手間のかからないメモリ管理。

Mem0は、すべての add 操作時にLLM呼び出しを介してサーバーサイドでメモリ抽出を行います。会話を読み取り、個別の事実を抽出し、重複を排除して保存します。マネージドクラウドAPIがすべてのインフラを処理します。オープンソースライブラリとセルフホストサーバーを使用すれば、完全に制御することが可能です。

外部依存関係： Mem0は、メモリ抽出用のLLM (デフォルト: OpenAI gpt-4.1-nano; Ollama、vLLM、LM Studioを含む20のプロバイダーをサポート) と、検索用のエンベディングモデル (デフォルト: OpenAI text-embedding-3-small; OllamaやHuggingFaceを含む10のプロバイダーをサポート) を必要とします。ストレージは、ライブラリモードでは /tmp/qdrant のQdrantを、セルフホストサーバーモードではpgvector付きのPostgreSQLを使用します。これらは両方ともローカルで実行可能です。完全にローカルな、クラウドに依存しないMem0スタックも実現可能です（LLMにOllama、エンベディングにOllama、ローカルQdrantインスタンスを使用し、すべて Memory.from_config を介して構成）。

ツール： mem0_profile, mem0_search, mem0_conclude.

セットアップ：

pip install mem0ai
hermes memory setup  # "mem0" を選択
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env

設定ファイル: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes)。

Hindsight

最適：エンティティ間の関係性を伴う、ナレッジグラフベースのリコール。

Hindsightは、エンティティと関係性を抽出してメモリのナレッジグラフを構築します。独自の reflect ツールは、複数のメモリを組み合わせて新しい洞察を生み出すクロスメモリ合成を実行します。リコールは4つの検索戦略（セマンティック、キーワード/BM25、グラフ探索、時間的）を並列で実行し、その後、相互ランク融合 (reciprocal rank fusion) を使用して結果をマージおよび再順序付けします。

外部依存関係： Hindsightは、retain 呼び出し時の事実およびエンティティ抽出のため、および reflect 呼び出し時の合成のためにLLMを必要とします (デフォルト: OpenAI; サポートされているプロバイダーにはAnthropic、Gemini、Groq、Ollama、LM Studio、およびあらゆるOpenAI互換エンドポイントが含まれます)。エンベディングモデルとクロスエンコーダー・リランキングモデルはHindsight自体に同梱されています。これらは hindsight-all パッケージ内でローカルに実行され、外部APIを必要としません。PostgreSQLも、管理された pg0 データディレクトリを介して組み込みPythonインストールと一緒に同梱されています。あるいは、外部のPostgreSQLインスタンスをHindsightに向けることも可能です。完全にローカルな、クラウドに依存しないセットアップにするには、HINDSIGHT_API_LLM_PROVIDER=ollama に設定し、ローカルのOllamaモデルを指すようにします。これにより、retain と recall は完全に機能しますが、reflect にはツール呼び出しが可能なモデル (例: qwen3:8b) が必要です。

ツール： hindsight_retain, hindsight_recall, hindsight_reflect (独自のクロスメモリ合成)。

セットアップ：

hermes memory setup  # "hindsight" を選択
echo "HINDSIGHT_API_KEY=your-key" >> ~/.hermes/.env

hindsight-client (クラウド) または hindsight-all (ローカル) を自動インストールします。バージョン 0.4.22 以上が必要です。

設定： $HERMES_HOME/hindsight/config.json

mode: cloud または local
recall_budget: low / mid / high
memory_mode: hybrid / context / tools
auto_retain / auto_recall: true (デフォルト)

ローカルUI: hindsight-embed -p hermes ui start

Holographic

最適：ローカルのみのストレージによる、プライバシー重視の設定。

Holographicは、メモリの符号化にHRR (Holographic Reduced Representation) 代数を、メモリの信頼性のために信頼スコアリングを使用します。クラウドへの依存はなく、すべてが自身のハードウェア上でローカルに実行されます。

外部依存関係： なし。HolographicはLLM、エンベディングモデル、データベース、およびネットワーク接続を必要としません。メモリの符号化はすべて、プロセス内で実行されるHRR代数を通じて行われます。これは8つのプロバイダーの中でユニークな点であり、外部呼び出しをゼロで動作させる唯一のプロバイダーです。トレードオフとして、検索の品質はエンベディングベースのセマンティック検索よりも低くなり、Hindsightの reflect のようなクロスメモリ合成も存在しません。プライバシーと依存関係ゼロの運用が譲れないユーザーにとって、Holographicはそれを無条件に提供する唯一の選択肢です。

ツール： HRR代数を介したメモリ操作用の2つのツール。

セットアップ：

hermes memory setup  # "holographic" を選択

RetainDB

最適：デルタ圧縮を用いた、高頻度の更新。

RetainDBは、デルタ圧縮を使用してメモリの更新を効率的に保存し、ハイブリッド検索 (ベクトル + BM25 + リランキング) を使用して関連するコンテキストを表示します。月額20ドルのクラウドベースであり、すべてのメモリ処理はサーバーサイドで処理されます。

外部依存関係： RetainDBのLLM呼び出し、エンベディングパイプライン、およびリランキングはすべてRetainDB自身のクラウドインフラ上で実行されます。ユーザーは RETAINDB_KEY を提供するだけです。メモリ抽出にはサーバーサイドでClaude Sonnetを使用します。セルフホストのオプションやローカルモードはありません。すべての会話データは、処理と保存のためにRetainDBサーバーに送信されます。ユースケースにおいてデータの主権やオフライン動作が重要である場合、このプロバイダーは適していません。

ツール： retaindb_profile (ユーザープロファイル)、retaindb_search (セマンティック検索)、retaindb_context (タスク関連コンテキスト)、retaindb_remember (タイプ + 重要度と共に保存)、retaindb_forget (メモリの削除)。

セットアップ：

hermes memory setup  # "retaindb" を選択

ByteRover

最適：人間が読みやすく、監査可能なストレージを備えた、ローカルファーストのメモリ。

ByteRoverは、エンベディングベクトルやデータベースではなく、構造化されたMarkdownコンテキストツリー（ドメイン、トピック、サブトピックファイルの階層）としてメモリを保存します。LLMがソースコンテンツを読み取り、それについて推論し、抽出された知識を階層内の適切な場所に配置します。検索はMiniSearchによる全文検索であり、LLMによる検索への階層的なフォールバックを備えていますが、ベクトルデータベースは必要ありません。

外部依存関係： ByteRoverは、メモリのキュレーションと検索のためにLLMを必要とします (Anthropic、OpenAI、Google、Ollama、および openai-compatible プロバイダースロットを介したあらゆるOpenAI互換エンドポイントを含む18のプロバイダーをサポート)。エンベディングモデルやデータベースは必要ありません。コンテキストツリーは、プレーンなMarkdownファイルのローカルディレクトリです。クラウド同期はオプションであり、チームコラボレーションにのみ使用されます。デフォルトですべてが完全にオフラインで動作します。完全に自己完結したローカル設定にするには、プロバイダーとしてOllamaを接続し (brv providers connect openai-compatible --base-url http://localhost:11434/v1)、データがマシンから出ないようにします。

ツール： メモリ操作用の3つのツール。

セットアップ：

hermes memory setup  # "byterover" を選択

Supermemory

最適：コンテキストフェンシングとセッショングラフ取り込みを備えた、エンタープライズワークフロー。

Supermemoryは、コンテキストフェンシング (コンテキストによるメモリの隔離) とセッショングラフ取り込み (会話履歴全体のインポート) を提供します。メモリを自動的に抽出し、ユーザープロファイルを作成し、セマンティック検索とキーワード検索を組み合わせたハイブリッド検索を実行します。マネージドクラウドAPIが主要なデプロイ対象です。

外部依存関係： Supermemoryのクラウドサービスは、すべてのLLM推論とエンベディングをサーバーサイドで処理します。ユーザーはSupermemory APIキーを提供するだけです。セルフホストはエンタープライズプランのアドオンとしてのみ利用可能であり、Cloudflare Workersにデプロイされます。これには、pgvector拡張機能付きのPostgreSQL (ベクトルストレージ用) とOpenAI APIキー (必須、AnthropicとGeminiはオプション) の提供が必要です。Dockerベースやローカルでのセルフホストのパスはありません。アーキテクチャはCloudflare Workersのエッジコンピューティングと密接に結合しています。エンタープライズ契約なしに完全なデータの主権を必要とするユーザーにとって、このプロバイダーは適切な選択ではありません。

ツール： メモリ操作用の4つのツール。

セットアップ：

hermes memory setup  # "supermemory" を選択

選び方

マルチエージェントのサポートが必要ですか？ Honcho
セルフホストで無料なものがいいですか？ OpenViking または Holographic
設定不要なものがいいですか？ Mem0
ナレッジグラフが必要ですか？ Hindsight
デルタ圧縮が必要ですか？ RetainDB
帯域幅の効率を重視しますか？ ByteRover
エンタープライズ機能が必要ですか？ Supermemory
プライバシーを重視しますか (ローカルのみ)? Holographic
外部サービスを一切使わず、完全にローカルがいいですか？ Holographic (依存関係なし) または Hindsight/Mem0/ByteRover + Ollama
エンベディングパイプラインなしで、人間が読みやすく監査可能なメモリがほしいですか？ ByteRover

プロファイルごとの詳細なプロバイダー設定と実際のワークフローパターンについては、Hermes Agent production setup を参照してください。

Hermes Agent によるアクティベーション

プロバイダー比較

詳細な内訳

Honcho

OpenViking

Mem0

Hindsight

Holographic

RetainDB

ByteRover

Supermemory

選び方

関連ガイド

購読する