エージェント・メモリ・プロバイダー比較 — Honcho、Mem0、Hindsight、およびその他5つ

タブを閉じると、コンテキストウィンドウを超えて情報が保持されない限り、最新のAIアシスタントはすべての情報を忘れてしまいます。エージェントメモリプロバイダーは、セッション間で事実や要約を保持するサービスまたはライブラリです。これらは通常プラグインとして組み込まれ、フレームワーク自体を軽量に保ちつつ、メモリ機能を拡張することができます。

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

Hermes固有のバウンデッドコアメモリ（MEMORY.mdおよびUSER.md）、フリーズ動作、トリガーについては、**Hermes Agentメモリシステム**をご参照ください。

Hermes Agentは、永続的でセッションをまたいだ知識のために、8つの外部メモリプロバイダープラグインをリストしています。同時にアクティブになれる外部プロバイダーは1つだけです。内蔵のMEMORY.mdとUSER.mdは、これとは別に読み込まれたままとなります（置き換えではなく追加されます）。

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

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

最適用途: マルチエージェントシステム、セッションを跨ぐコンテキスト、ユーザーとエージェントの整合性。

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 経由で構成可能なプロバイダーをサポートしており、BGEモデル付きvLLMなどのローカルオプションを含む任意の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は階層型読み込みを備えたファイルシステム階層を提供します。これは無料で、セルフホスト可能であり、メモリストレージに対する完全な制御をあなたに与えます。

外部依存関係: OpenVikingは、セマンティック処理とメモリ抽出のためにVLM（ビジョン言語モデル）、およびベクター検索のために埋め込みモデルを必要とします——両方とも必須です。対応する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、グラフ探索、時間的）を並行して実行し、その後、相互ランク融合を使用して結果をマージし再配置します。

外部依存関係: Hindsightは、retain 呼び出しでの事実とエンティティの抽出、および reflect 呼び出しでのシンセシスのためにLLMを必要とします（デフォルト: OpenAI; 対応するプロバイダーにはAnthropic、Gemini、Groq、Ollama、LM Studio、および任意のOpenAI互換エンドポイントが含まれます）。埋め込みモデルとクロスエンコーダーリランキングモデルはHindsight自体にバンドルされており——これらは hindsight-all パッケージ内でローカルで実行され、外部APIは不要です。PostgreSQLも埋め込みPythonインストールに pg0 データディレクトリ経由でバンドルされています; 代替として、Hindsightを外部PostgreSQLインスタンスに接続することもできます。完全にローカルでクラウド不要のセットアップのために、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は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はメモリを構造化されたマークダウンコンテキストツリーとして保存します——ドメイン、トピック、サブトピックファイルの階層——ベクターまたはデータベースではなく。LLMはソースコンテンツを読み取り、それを推論し、抽出された知識を階層内の適切な場所に配置します。検索はMiniSearch全文検索であり、段階的なフォールバックとしてLLM駆動の検索を使用し、ベクターデータベースは不要です。

外部依存関係: ByteRoverはメモリキュレーションと検索のためにLLMを必要とします（Anthropic、OpenAI、Google、Ollama、および openai-compatible プロバイダースロット経由の任意のOpenAI互換エンドポイントを含む18のプロバイダーに対応）。埋め込みモデルやデータベースは必要ありません——コンテキストツリーはプレーンマークダウンファイルのローカルディレクトリです。クラウド同期はオプションであり、チーム協同のためだけに使用されます; すべてはデフォルトで完全にオフラインで動作します。完全に自己完結型のローカルセットアップのために、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 (依存関係なし) または Ollamaとの Hindsight/Mem0/ByteRover
• 埋め込みパイプラインなしで人間が読める監査可能なメモリが欲しいですか？ ByteRover

プロファイル別プロバイダー構成と実世界のワークフローパターンについては、Hermes Agentプロダクションセットアップをご参照ください。

関連ガイド

• AIシステムメモリハブ — このサブクラスターの範囲とCogneeガイドへのリンク
• Hermes Agentメモリシステム — プラグイン前のコア2ファイルメモリ
• Hermes Agentプロダクションセットアップ — 実践におけるプロバイダーのプロファイル配線