ヘルメスエージェントメモリシステム：永続的なAIメモリが実際にどのように機能するか

ご存知の通り、AIエージェントとのチャットを開き、プロジェクトを説明して、自分の好みや設定を共有し、作業を進めて、タブを閉じる。翌週に戻ってみると、まるで最初のお約束のように、文脈は消え、すべての好みが忘れられ、プロジェクトの説明を最初からやり直す羽目になる。

これはバグではありません。大規模言語モデル（LLM）の設計思想そのものです。それらはステートレス（状態保持しない）です。各リクエストは独立しており、各レスポンスは現在送信されたプロンプトに基づいて生成されます。現在のコンテキストウィンドウ内のトークン以外には、記憶も履歴も継続性もありません。

単発のやり取りであれば、これで十分です。質問して、答えを得て、次の話題へ移る。しかし、エージェント——複数のセッションにわたって「行動」し、ミスから学び、あなたと共に進化すべきシステム——にとって、ステートレス性は厳格なアーキテクチャ上の制限です。これはセルフホスト型AIシステムにおける中心的な未解決問題の一つです。

業界はこの問題の解決に挑んできました。LangChainはメモリモジュールを追加し、OpenAIはスレッド機能付きアシスタントを導入しました。Letta、Zep、Cogneeといったフレームワークは、永続的なメモリを中心に据えたアーキテクチャを構築しました。Databricksは「メモリスケーリング」について発表し、蓄積された経験によってエージェントのパフォーマンスが向上するという考えを示しました。2024年以降、専用のベンチマーク論文、エピソード記憶の調査、そして急速に成長するツールのエコシステムが台頭し、エージェント型AIにおける中心的な未解決問題の一つとして認識されるようになっています。

これらのアプローチの多くに共通する問題があります。それらはメモリを「後付け」のものとして扱っています。クエリを実行するデータベース、コンテキストウィンドウに詰め込むデータ、明瞭さよりもレイテンシやノイズを追加する検索システムとして。

Hermes Agentは根本的に異なるアプローチを取ります。メモリは、必要な時にエージェントが「取得」するものではありません。それは常にエージェントの「一部」です——システムプロンプトに組み込まれ、キュレーションされ、範囲が限定され、常にアクティブです。それは高速であるために十分に小さく、有用であるために十分に構造化され、何を忘れるべきかを知るために十分に規律正しいものです。

この記事では、その仕組みを詳しく説明します。

第1部：AIエージェントのメモリ問題

エージェントにとって「コンテキストを追加するだけ」が拡張性を持たない理由

ステートレスなAIに対する明らかな解決策は、コンテキストを追加することです。以前の会話を添付し、プロジェクトのドキュメントを含め、履歴のすべてを送信します。

一時的にはそれが機能します。128Kのコンテキストウィンドウがあり、そこには多くのテキストを収めることができます。

しかし、コンテキストはメモリではありません——それらには実質的で重要な違いがあります。コンテキストは、今まさに目にしているすべてです。一方、メモリは、能動的に保持し、先へ運ぶものです。

コンテキストにはキュレーションがありません。それは単なるダンプです。成長するにつれて、モデルは必要な一つの事実を見つけるために、関連性の低い履歴の数千トークンを処理しなければなりません。それはトークンとコストがかかります、レイテンシを増幅し、最終的には天井に突き当たります。

メモリはキュレーションされたものです。それは経験の濃縮であり、コンパクトで実行可能なものです。それは無限に成長するのではなく、統合され、更新され、忘却されます。

人間のメモリも同じように機能します。過去に交わしたすべての会話を覚えているわけではありません。重要だった部分——誰と話をしているか、彼らが何に関心を持っているか、何に合意したか、何を学んだか——だけを覚えています。残りは、必要に応じて検索するか、忘れ去られます。

研究の現状

2024年以降、AIエージェントのメモリ分野は爆発的に拡大し、専用のベンチマークスイート、増加する研究文献、および異なるアーキテクチャアプローチ間の測定可能なパフォーマンスギャップが生じました。現在の状況は以下の通りです。

Letta（旧MemGPT）は、永続メモリを第一級の懸念事項として扱う最も初期のフレームワークの一つで、GitHubスター数は21.7Kに達しました。OSに触発された3層モデルを使用しています：コアメモリ（小さく、常にコンテキスト内）、検索メモリ（検索可能な会話履歴）、アーカイブメモリ（長期の冷保管）。「すべてのメモリが同等ではない」という洞察は正しかったです。しかし、実装において、エージェントはLettaランタイム内で完全に実行される必要があります。これを採用することは、単なるメモリレイヤーだけでなく、プラットフォーム全体を採用することを意味します。

Zep / Graphitiは、時間的エンティティ追跡による会話メモリに焦点を当てています。事実に有効性ウィンドウが付与されるため、グラフはいつそれが真であったかを知ります。関係グラフが必要なチャットボットには強みがありますが、環境事実とプロジェクトの規則を追跡する自律型エージェントには適していません。

Cogneeは、ドキュメントと構造化データからの知識抽出のために構築され、30以上のインジェストコネクタとナレッジグラフバックエンドを備えています。組織知識とRAGパイプラインに優れていますが、個人エージェントのメモリには焦点を当てていません。実用的なセットアップガイドはローカルLLMでのCogneeのセルフホスティングを参照してください。

Hindsightは、エンティティ関係と、複数のメモリを組み合わせて新しい洞察を行うユニークなreflect合成ツールによる知識グラフベースの検索を行います。エージェントメモリベンチマークでトップクラスの性能を示し、Hermes Agentのメモリプロバイダーとして利用可能です。

Mem0は、サーバー側でのLLM分析によってメモリ抽出を処理し、最小限の構成を必要とします。ECAI 2025で発表されたMem0の研究論文（arXiv:2504.19413）は、AIメモリへの10の異なるアプローチをベンチマークし、選択的抽出アプローチ——離散的な事実を保存し、重複を除去し、関連するもののみを検索する——を検証しました。Mem0は約48KのGitHubスター数を獲得し、21のフレームワーク統合をサポートしています。トレードオフはクラウド依存性とコストです。

Databricksのメモリスケーリング研究は、エージェントのパフォーマンスが蓄積された経験によって向上するという概念を導入しました。そのアーキテクチャは、システムプロンプト、エンタープライズアセット、および組織とユーザーレベルでスコープされたエピソード/セマンティックメモリを保持し、メモリ品質がモデル能力と同様に重要であることを検証しました。

ほとんどのフレームワークに共通する点は、メモリを「検索問題」として扱うことです。どこかに保存し、必要時にクエリし、コンテキストに注入します。Hermesは逆を行います——メモリはオンデマンドで取得されるのではなく、セッション開始時に注入され、常に存在します。常にアクティブ、常に利用可能、そして有用さを保つためにキュレーションされています。

第2部：アーキテクチャ——2つのファイル、1つの脳

Hermes Agentの組み込みメモリシステムは2つのファイルに存在します。

• ~/.hermes/memories/MEMORY.md — エージェントの個人的なノート（2,200文字、約800トークン）
• ~/.hermes/memories/USER.md — ユーザープロファイル（1,375文字、約500トークン）

これが永続メモリ表面のすべてです。2つのファイル、合計3,600文字未満、1,300トークン未満。意図的に小さく見えるのは、そうだからです——そしてそれがまさに設計意図です。

MEMORY.md：エージェントのノート

ここでは、エージェントは環境、プロジェクト、ツール、規則、そして教訓について学んだすべてを保存します。以下のような見た目です：

ユーザーのプロジェクトは ~/code/gateway にある Go マイクロサービスであり、gRPC + PostgreSQL を使用しています
このマシンは Ubuntu 22.04 を実行しており、Docker と kubectl がインストールされています
ユーザーは変数名に snake_case を好み、camelCase を避けます

これらはログではありません。事実です。密集した、宣言的な、情報に富んだものです。タイムスタンプも、余分な言葉も、「1月5日にユーザーは私に～するように頼んだ」などもありません。

USER.md：ユーザープロファイル

ここでは、エージェントはあなたについて知っているすべてを保存します。

ユーザーはフルスタック開発者であり、TypeScript、Go、Python に慣れています。
ユーザーは変数名に snake_case を好み、camelCase を避けます。
ユーザーは主に Linux Ubuntu 22.04 を使用します。
ユーザーは Terraform を使用して AWS にデプロイします。

アイデンティティ、役割、好み、技術スキル、コミュニケーションスタイル、嫌いなもの。エージェントがあなたに対して、他の誰に対しても異なるように応答させる要素です。

フロズンスナップショットパターン

セッション開始時、両方のファイルはディスクから読み込まれ、システムプロンプトに固定ブロックとして注入されます。以下のような見た目です：

══════════════════════════════════════════════
MEMORY (あなたの個人的なノート) [7% — 166/2,200 文字]

ユーザーのプロジェクトは ~/code/gateway にある Go マイクロサービスであり、gRPC + PostgreSQL を使用しています § このマシンは Ubuntu 22.04 を実行しており、Docker と kubectl がインストールされています § ユーザーは変数名に snake_case を好み、camelCase を避けます §

══════════════════════════════════════════════ USER PROFILE (ユーザーとは誰か) [8% — 110/1,375 文字] ══════════════════════════════════════════════ ユーザーはフルスタック開発者であり、TypeScript、Go、Python に慣れています。 § ユーザーは変数名に snake_case を好み、camelCase を避けます。 §

この形式は、ヘッダー、使用率、文字数、および `§`（セクション記号）区切り文字を使用します。エントリは複数行にわたる可能性があります。モデルによってパース可能でありながら、人間が読めるように設計されています。

なぜ固定（フローズン）なのか？[プレフィックスキャッシング](https://www.glukhov.org/ja/llm-performance/)のためです。システムプロンプトは、セッション内のすべてのターンで同じです。セッション開始後にメモリを静的に保つことで、モデルはプレフィックス計算をキャッシュし、可変部分——つまり会話——のみを処理できます。これは重要なパフォーマンス最適化です。各ターンで同じメモリトークン上でアテンションを再計算する必要はありません。

セッション中にされた変更は直ちにディスクに保持されますが、次のセッション開始時にシステムプロンプトに反映されるだけです。ツールのレスポンスは常にライブの状態を示しますが、モデルの「心」はセッション中に変わりません。これにより、モデルが自身の尻尾を追うこと——メモリを更新し、同じ会話でその更新に反応すること——を防ぎます。

### 文字制限としての機能

2,200文字。1,375文字。これらは恣意的な制限ではありません。キュレーションを強制する設計制約です。

無制限のメモリは負債です。すべてをダンプし、決して統合せず、最終的にはノイズになることを助長します。制限されたメモリは、エージェントに選択的であることを強います。本当に重要なのは何か？再び必要になるのは何か？意味を失わずに圧縮できるのは何か？

メモリが満杯になったとき、エージェントは静かに失敗するわけではありません。現在のエントリと使用率を含むエラーを受け取り、以下のワークフローに従います：

1. エラーレスポンスから現在のエントリを読み取る
2. 削除可能または統合可能なエントリを特定する
3. `replace`を使用して、関連するエントリを短いバージョンにマージする
4. 新しいエントリを追加する

これがメモリが有用さを保つ方法です。それはデータベースではありません。それは重要な事実のキュレーションされたコレクションです。

### セキュリティ：プロンプトインジェクションスキャン

すべてのメモリエントリは、受け入れられる前にスキャンされます。システムはプロンプトインジェクションの試み、資格情報の流出、SSHバックドア、および不可視のUnicode文字をブロックします。

メモリは重複排除もされます。完全一致のエントリは自動的に拒否されます。これにより、攻撃者が繰り返し送信を通じて悪意のあるコンテンツを注入しようとする試みを防ぎます。

---

## 第3部：メモリが発火する時——トリガーと意思決定

Hermes Agentのメモリに関する最も一般的な質問は、実際にいつ何かを保存するかということです。

答えは：常に、しかし選択的にです。エージェントは`memory`ツールを通じて自身のメモリを管理し、保存の決定は明示的なシグナルと暗黙的なパターンの組み合わせによって駆動されます。

### 書き込みトリガー：エージェントはいつ保存すると決定するか？

エージェントは積極的にメモリを保存します。あなたに頼まれるのを待ちません。以下がトリガーとなります。

**ユーザーの修正。** エージェントを修正したとき、それは記憶するシグナルです。「もうそれをするな」「代わりにこれを使え」「これを覚えておけ」。これらはメモリを更新する明示的な指示です。

例：エージェントにPython環境を設定するように依頼します。`pip`を提案します。あなたは「私はすべてに`poetry`を使う」と言います。エージェントはこれを保存します：`ユーザーはすべてのPythonプロジェクトに 'poetry' パッケージマネージャーを使用することを好みます。`

**発見された好み。** エージェントはパターンを観察し、好みを推測します。特定のツール、フレームワーク、またはワークフローを一貫して使用する場合、それが保存されます。

例：異なるプロジェクトで`poetry`を複数回使用した後、エージェントはそれを好みとして保存します。

**環境事実。** マシン、プロジェクト、インストールされたツールに関するもの。これらは探索を通じて発見され、事実として保存されます。

例：エージェントはインストールされているものをチェックし、これを保存します：`このマシンは Ubuntu 22.04 を実行しており、Docker と kubectl がインストールされています。`

**プロジェクトの規則。** プロジェクトの構造、使用するツール、従うパターン。これらはコード検査を通じて発見され、保存されます。

例：`ユーザーのプロジェクトは ~/code/gateway にある Go マイクロサービスであり、gRPC + PostgreSQL を使用しています。`

**完了した複雑なワークフロー。** 5回以上のツール呼び出しを要したタスクを完了した後、エージェントはそのアプローチをスキルとして保存するか、少なくとも何が機能したかを記録することを検討します。

**ツールの癖と回避策。** エージェントがツール、API、またはシステムについて非自明なもの——制限、回避策、規則——を発見したとき、それを保存します。

**スキップされるもの：**

- 自明な情報
- 容易に再発見されるもの
- 生データのダンプ
- セッション固有の一時的なもの
- コンテキストファイル（SOUL.md、AGENTS.md）にすでに存在する情報

### 読み込みトリガー：エージェントはいつ想起するか？

メモリは取得されるものではなく、常にそこにあります。しかし、アクセスには異なるレベルがあります。

**セッション開始（自動的）。** MEMORY.mdとUSER.mdはシステムプロンプトに注入されます。エージェントは最初のトークンからそれらを持っています。クエリもレイテンシもツール呼び出しも不要です。これがコアメモリ——常にアクティブです。

**`session_search`（オンデマンド）。** エージェントがコアメモリにない過去の会話から何かを見つけようとするとき、`session_search`ツールを使用します。これはSQLite（`~/.hermes/state.db`）でFTS5全文検索とGemini Flash要約を実行します。

例：「先週Dockerのネットワークについて話した？」と尋ねます。エージェントはセッション履歴を検索し、関連する会話の要約を返します。

**外部プロバイダーツール（構成時）。** 外部メモリプロバイダーがアクティブの場合、エージェントは追加のツールを利用できます：`honcho_search`、`hindsight_recall`、`mem0_search`など。これらは、外部コンテキストが必要と判断されたときに使用されます。

### 意思決定ツリー

エージェントが「これは覚える価値があるか？」をどのように評価するか：

これは修正または明示的な指示か？ YES → メモリに保存 NO → これは好みまたはパターンか？ YES → ユーザープロファイルに保存 NO → これは環境事実または規則か？ YES → メモリに保存 NO → これは容易に再発見されるか？ YES → スキップ NO → これはセッション固有か？ YES → スキップ NO → メモリに保存

エージェントはこれについて過度に考えません。積極的に保存し、満杯時に統合し、文字制限がものを引き締めることを信頼します。

---

## 第4部：内部メモリ対外部知識ベース

ここで混乱がよく起こります。Hermes Agentには*内部メモリ*（MEMORY.md、USER.md、外部プロバイダー）と*外部知識ベース*（LLM Wiki、Obsidian、Notion、ArXiv、ファイルシステム）があり、それらは完全に異なる役割を果たします。これは[検索拡張生成](https://www.glukhov.org/ja/rag/)パイプラインとエージェントのワーキングメモリの区別に似ています——外部検索は深い知識のルックアップには良いですが、アイデンティティや好みを保持するには適していません。内部メモリはエージェントの脳——常にアクティブ、キュレーションされ、すべてのセッションに持ち込まれます。外部知識ベースはその図書館——必要に応じて参照される広大なリソースです。

### 区別

**内部メモリ（脳）：**

- 小さく、永続的、システムプロンプトに注入
- 含む：ユーザーの好み、エージェントの規則、即座の教訓
- 会話中常に「頭の中」にある
- キュレーションされ、制限され、能動的に管理される
- 例：MEMORY.md、USER.md、Honcho、Hindsight、Mem0

**外部知識ベース（図書館）：**

- 広大、参照専用、オンデマンドでアクセス
- 含む：ドキュメント、論文、コード、ノート、データベース
- 必要に応じてツール経由でアクセス
- 「記憶」されるのではなく、検索される
- 例：LLM Wiki、Obsidian、Notion、ArXiv、ファイルシステム、GitHub

### それらの関係

エージェントは必要に応じてツール経由で外部ベースに*アクセス*します。それらを「記憶」するのではなく、検索します。

**LLM Wiki (llm-wiki):** Karpathyのドメイン知識の構築とクエリのための相互リンクされたMarkdown知識ベース。エージェントは`llm-wiki`スキルを使用してそれを読み、検索し、クエリします。それはメモリではなく、参照リソースです。

**[Obsidian](https://www.glukhov.org/ja/knowledge-management/tools/obsidian-for-personal-knowledge-management/):** 双方向リンクを持つ個人的なノートボルト。エージェントは`obsidian`スキルを使用してノートを検索し、作成し、読みます。Obsidianは、Hermesが図書館リソースとして活用できるより広範な[パーソナル知識管理](https://www.glukhov.org/ja/knowledge-management/)エコシステムの一部です。

**Notion/Airtable:** API経由でアクセスされる構造化データベースとWiki。エージェントは必要に応じてそれらをクエリします。

**ArXiv:** 学術論文のレポジトリ。エージェントはトピックを研究する際に論文を検索し、抽出します。

**ファイルシステム:** プロジェクトコード、ドキュメント、構成。エージェントはプロジェクトで作業する際にファイルを読み込みます。

### 蒸留パターン

ここでの重要な洞察は、外部ベースからの重要な洞察は内部メモリに*蒸留*できるということです。

例：エージェントはAIエージェントのメモリスケーリングに関するArXivの論文を読みます。それはメモリに論文全体を保存しません。それは重要な結論を保存します：`メモリスケーリング：エージェントのパフォーマンスは、メモリに保存されたユーザー相互作用とビジネスコンテキストを通じた蓄積された経験によって向上します。`

外部リソースは広大です。内部メモリはその蒸留です。

### どちらを使うべきか

**内部メモリ：**

- 「誰を助けているのか？」
- 「彼らは何を好むのか？」
- 「今何を学んだのか？」
- 「プロジェクトの設定は？」
- 「利用可能なツールは？」

**外部知識ベース：**

- 「Xに関する最新の研究は？」
- 「プロジェクトのドキュメントには何があるか？」
- 「先月何について議論したか？」
- 「このサービスのAPIは？」
- 「コード構造は？」

エージェントはこの違いを理解し、適切に使用します——ドキュメントを検索することと、あなたとあなたの環境について学んだことを想起することを混同しません。

---

## 第5部：実際の仕組み

仕組みを見てみましょう。

### `memory` ツール

エージェントは3つのアクションを持つ単一のツールを通じてメモリを管理します：`add`、`replace`、`remove`。

`read`アクションはありません——メモリ内容はシステムプロンプトに自動注入されます。エージェントはそれを読む必要がないのは、常にそこにあるからです。

**`add`** — 新しいエントリを追加します。

```python
memory(action="add", target="memory",
       content="ユーザーは macOS 14 Sonoma を実行し、Homebrew を使用し、Docker Desktop がインストールされています。")

replace — サブストリングマッチングを使用して既存のエントリを置き換えます。

memory(action="replace", target="memory",
       old_text="ダークモード",
       content="ユーザーは VS Code でライトモード、ターミナルでダークモードを好みます")

remove — サブストリングマッチングを使用してエントリを削除します。

memory(action="remove", target="memory",
       old_text="一時的なプロジェクト事実")

サブストリングマッチング

replaceとremoveはold_textによる短い一意のサブストリングを使用します。完全なエントリテキストは必要ありません。これにより、正確なコンテンツを知らなくても外科的な編集が可能になります。

サブストリングが複数のエントリと一致する場合、より具体的な一致を要求するエラーが返されます。エージェントはその後、クエリを精緻化します。

ターゲットストア：memory 対 user

targetパラメータは、どのファイルが更新されるかを決定します。

• memory — エージェントの個人的なノート。環境事実、プロジェクト規則、ツールの癖、教訓。
• user — ユーザープロファイル。アイデンティティ、役割、タイムゾーン、コミュニケーションの好み、嫌いなもの、ワークフローの習慣。

キャパシティ管理

メモリが80%以上になると、エージェントは統合します。関連するエントリをマージし、古い事実を削除し、情報を圧縮します。

良いメモリエントリはコンパクトで情報密度が高いものです：

ユーザーは macOS 14 Sonoma を実行し、Homebrew を使用し、Docker Desktop がインストールされています。シェル：oh-my-zsh 付き zsh。エディタ：Telescope プラグイン付き Neovim。

悪いメモリエントリは曖昧または冗長です：

ユーザーにプロジェクトがあります。
2026年1月5日、ユーザーは ~/code/gateway にあるプロジェクトを調べてほしいと頼みました。それは Go を使用し、データベースレイヤーには gRPC と PostgreSQL を使用しています。

前者は密集して有用です。後者は曖昧すぎたり、冗長すぎたりします。

セッション検索対永続メモリ

session_searchと永続メモリは異なる目的を果たします。

経験則：常にコンテキストにあるべき重要な事実にメモリを使用し、履歴のルックアップにセッション検索を使用します。

第6部：外部メモリプロバイダー——8つのオプションの比較

組み込みのMEMORY.mdとUSER.mdに加え、Hermes Agentは永続的なクロスセッション知識のために8つの外部メモリプロバイダープラグインをサポートします。

一度に1つの外部プロバイダーのみがアクティブにできます。組み込みファイルは外部プロバイダーと共に常にアクティブです——置換ではなく、追加的です。

アクティベーション

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は追加のコンテキストレイヤーを追加します。それは会話をメッセージを交換するピアとしてモデル化します——1人のユーザーピアと1人のAIピア（Hermesプロファイルごと）、すべてがワークスペースを共有します。

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

主要な構成ノブ：

• contextCadence（デフォルト1）：ベースレイヤーリフレッシュ間の最小ターン数
• dialecticCadence（デフォルト2）：peer.chat() LLM呼び出し間の最小ターン数（1-5推奨）
• dialecticDepth（デフォルト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プロファイル（hermesデフォルト、他はhermes.<profile>）ごとに1つです。

セットアップ：

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は階層型読み込みを持つファイルシステム階層を提供します。それは無料で、セルフホストされ、メモリストレージの完全な制御を提供します。

ツール： viking_search、viking_read（階層型）、viking_browse、viking_remember、viking_add_resource。

セットアップ：

pip install openviking
openviking-server
hermes memory setup  # "openviking"を選択
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

最適：自動抽出によるハンズオフメモリ管理。

Mem0はサーバー側でメモリ抽出を処理します。何も構成する必要はありません——ただ機能します。トレードオフ：クラウド依存性とコスト。

ツール： 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ツールはクロスメモリ合成——複数のメモリを組み合わせて新しい洞察——を行います。

ツール： 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（ホログラフィック減算表現）代数を使用し、メモリ信頼性に信頼スコアリングを使用します。クラウド依存性はありません——すべてがあなたのハードウェアでローカルに実行されます。

ツール： HRR代数によるメモリ操作のための2つのツール。

セットアップ：

hermes memory setup  # "holographic"を選択

依存関係なし。すべてがローカルに実行されます。

RetainDB

最適：デルタ圧縮による高頻度更新。

RetainDBはデルタ圧縮を使用してメモリ更新を効率的に保存します。クラウドベースで$20/月のコストですが、圧縮によりデータ転送が少なく、更新が速いです。

ツール： retaindb_profile（ユーザープロファイル）、retaindb_search（セマンティック検索）、retaindb_context（タスク関連コンテキスト）、retaindb_remember（型 + 重要性付き保存）、retaindb_forget（メモリ削除）。

セットアップ：

hermes memory setup  # "retaindb"を選択

ByteRover

最適：プレ圧縮抽出による帯域幅制約環境。

ByteRoverは抽出前にメモリを圧縮し、帯域幅使用量を削減します。ローカルまたはクラウドモードで利用可能です。

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

セットアップ：

hermes memory setup  # "byterover"を選択

Supermemory

最適：コンテキストフェンシングとセッショングラフインジェストによるエンタープライズワークフロー。

Supermemoryはコンテキストフェンシング（コンテキストによってメモリを分離）とセッショングラフインジェスト（会話履歴全体をインポート）を提供します。クラウドベースで有料ですが、エンタープライズ規模のメモリ管理用に設計されています。

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

セットアップ：

hermes memory setup  # "supermemory"を選択

どのように選ぶか

• マルチエージェントサポートが必要？ Honcho
• セルフホストで無料が欲しい？ OpenViking または Holographic
• ゼロ構成が欲しい？ Mem0
• ナレッジグラフが欲しい？ Hindsight
• デルタ圧縮が欲しい？ RetainDB
• 帯域幅効率性が欲しい？ ByteRover
• エンタープライズ機能が欲しい？ Supermemory
• プライバシー（ローカルのみ）が欲しい？ Holographic

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

第7部：哲学

なぜ制限されたメモリが無制限のメモリに勝るのか

直感としては、メモリを可能な限り大きくすることです。すべてを保存し、必要なものを取得します。

制限されたメモリの方が機能します。その理由です。

キュレーションが品質を強制する。 空間が限られているとき、重要なものだけを保存します。圧縮し、統合し、優先順位をつけます。無制限のメモリはすべてをダンプし、決して片付けないことを助長します。

速度が重要である。 システムプロンプト内の1,300トークンは高速です。データベースから取得された100,000トークンは低速です。メモリは即座であるべきであり、クエリではありません。

ノイズがパフォーマンスを劣化させる。 より多くのメモリはより良いメモリではありません。ノイズの多いメモリです。モデルはノイズから信号を区別しなければならず、それは注意——実際のタスクに費やすべき注意——を要します。

忘却は機能である。 人間のメモリは忘却します。それはバグではありません——それは優先順位をつける方法です。エージェントも忘却すべきです。すべてが記憶されるべきではありません。

「忘却」の問題

エージェントは学習解除する必要があります。単に忘却するだけでなく、能動的に古い情報を削除します。

Hermes Agentはそれをどのように処理しますか？

• remove アクション： もはや関連しないエントリを削除します。
• replace アクション： 新しい情報でエントリを更新します。
• キャパシティプレッシャー： メモリが満杯になると、エージェントは統合し、古いエントリを削除します。
• セキュリティスキャン： 悪意のあるまたは破損したエントリをブロックします。

忘却は失敗ではありません——それはメンテナンスです。学習解除できないエージェントは最終的に信号と同じ量のノイズを運ぶことになります。

メモリスケーリング

Databricksは「メモリスケーリング」の概念を導入しました：数千のユーザーを持つエージェントは単一のユーザーを持つエージェントよりもパフォーマンスが向上するのか？

彼らの研究はイエスと示唆していますが、留保があります。メモリスケーリングには以下が必要です：

1. 品質抽出： すべての相互作用が記憶されるべきではありません。エージェントはログではなく洞察を抽出しなければなりません。
2. 効果的な検索： 取得されたメモリは関連しなければなりません。ノイズはパフォーマンスを劣化させます。
3. 一般化： メモリは特定のものではなく、パターンであるべきです。「ユーザーはPythonを好む」はスケーリングします。「ユーザーはタイムスタンプYでコマンドXを実行した」はスケーリングしません。

Hermes Agentの制限されたメモリは自然にメモリスケーリングをサポートします。キュレーションを強制することで、メモリは一般化可能、コンパクト、かつ有用であることを保証します。

未来への意味

メモリはエージェント型AIにおける競争の堀になっています——モデル自体ではなく、モデルがセッション間で運ぶものです。同じ基盤モデルを持つ2つのエージェントは非常に異なるパフォーマンスを示すことができます：一つはあなたの好み、環境、過去のミスを記憶し、もう一つは毎回冷たいスタートから始めます。

エージェントが永続メモリを持つべきかどうかという質問はもはやありません。それは決まりました：彼らは持つべきです。開かれている質問は、そのメモリをどのように設計するか——何を保持し、何を破棄し、どのように即座にし、どのようにノイズになるのを防ぐか——です。

Hermes Agentの答えは、メモリを小さく、キュレーションされ、常にアクティブに保つことです——クエリするデータベースではなく、エージェントが各会話に持ち込むユーザーのワーキングモデルです。

結論

Hermes Agentのメモリシステムは意図的にシンプルです：2つのファイル、厳格な文字制限、検索パイプラインなし、ベクトルデータベースなし、クエリあたりのレイテンシなし。制約のように聞こえるものが、まさにそのポイントです。

それは機能するのは、データベースの機能ではなく、脳の機能のようにメモリを扱うからです——小さく、キュレーションされ、常にアクティブ。エージェントは必要時にメモリを取得するのではなく、メモリは単に常にそこにあり、各セッションの最初のトークンからシステムプロンプトに織り込まれています。

外部メモリプロバイダーは、より多くのものを必要とするユーザーのためにこのシステムを拡張します：ナレッジグラフ、マルチエージェントサポート、セルフホストストレージ、エンタープライズ機能。しかし、コアは同じままです：制限され、キュレーションされ、常に利用可能。

そして外部知識ベース——LLM Wiki、Obsidian、Notion、ArXiv——は異なる役割を果たします。それらは図書館であり、脳ではありません。エージェントはそれらを検索し、記憶しません。重要な洞察は内部メモリに蒸留され、残りは図書館に残ります。

これがAIエージェントがあなたを覚える方法です。すべてを保存することではなく、重要なことを記憶することによって。

Hermes Agentは2026年2月にNous Researchによってリリースされ、2026年4月（v0.9.0）までに64,000以上のGitHubスター数を達成し、242以上のコントリビューターを擁しています。それはオープンソースであり、github.com/NousResearch/hermes-agentで利用可能です。インストール、構成、およびワークフローガイドについては、Hermes Agent の概要を参照してください。