Hermesエージェントのメモリシステムとは何か、そしてそれはどのように機能するのか？

Hermes Agentは2ファイル構成の永続メモリシステム（MEMORY.mdは最大2,200文字、USER.mdは最大1,375文字）を採用しており、これらは~/.hermes/memories/に保存され、各セッション開始時にシステムプロンプトに凍結ブロックとして注入されます。エージェントはこれらのファイルを追加・置換・削除ツールアクションで管理し、取得ステップ不要で重要事実を常に利用可能に保っています。

「なぜHermesエージェントは情報をすべて保存するのではなく、メモリを約3,600文字に制限するのですか？」

文字数制限は技術的な制約ではなく、意図的な設計上の選択です。メモリに上限があることで、エージェントは不要な情報を一切取り込むのではなく、本質的に重要な情報のみを抽出・統合・優先順位付けして整理することを強いられます。膨大に成長し続ける検索データベースよりも、こうした厳選された小さなメモリの方が高速（LLMのプレフィックスキャッシングを活用するため）で、ノイズが少なく、実用的です。

Hermes Agentは、コンテキストを失うことなくセッション間で情報をどのように記憶しているのでしょうか？

各セッション開始時、MEMORY.mdとUSER.mdはシステムプロンプトへの凍結スナップショットとして注入され、エージェントは最初のトークンから完全なコンテキストを保持します。すべての会話履歴はFTS5による全文検索機能を備えたSQLiteデータベース（~/.hermes/state.db）に保存されます。過去のコンテキストが必要な場合、エージェントはこのデータベースをクエリし、高速なLLM呼び出しで関連する過去のセッションを要約してから、現在の会話に注入します。

Hermes Agentのコアメモリとセッション検索の違いは何ですか？

コアメモリ（MEMORY.mdとUSER.md）には、システムプロンプトに常時組み込まれる少量の重要な事実がキュレーションされています。これにより、クエリ不要で即時アクセスが可能であり、トークンコストは固定です。セッション検索は、エージェントがコアメモリに蒸留されていない過去のセッションの情報が必要になった場合に、SQLiteの会話履歴全体をオンデマンドで照会します。コアメモリは「常に重要な事項」を、セッション検索は「履歴の参照」を担います。

Hermes エージェントはどのような外部メモリプロバイダをサポートしていますか？

Hermes Agentは8つの外部メモリプロバイダプラグイン——Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、Supermemory——をサポートしています。外部プロバイダは同時に1つのみ有効にできますが、これは常時有効なMEMORY.mdおよびUSER.mdファイルを置き換えるものではなく、追加されます。プロバイダは hermes memory setup コマンドで設定され、セルフホスティング型ナレッジグラフからエンタープライズレベルのコンテキストフェンシングまで、多様なユースケースに対応します。各プロバイダには異なる外部依存要件があり、一部にはLLM、埋め込みモデル、またはPostgreSQLデータベースが必要ですが、Holographicはこれら一切を必要とせず、完全にローカルで動作します。起動コマンドと依存関係の表を含むスタンドアロン比較については、www.glukhov.orgの「Agent memory providers compared」を参照してください。

クラウドにデータを送信せずに完全ローカルで実行可能なHermesエージェントのメモリプロバイダはどれですか？

Holographicは外部依存ゼロの唯一のプロバイダーであり、LLM、埋め込みモデル、データベース、ネットワーク呼び出しを必要としません。より強力なローカルセットアップには、HindsightとMem0がどちらもLLMおよび埋め込み推論にOllamaをサポートしており、すべてのデータがローカルマシン内に保持されます。ByteRoverはメモリをプレーンなMarkdownファイルとして保存し、OllamaなどのローカルLLMのみを必要とするため、埋め込みモデルやデータベースは不要です。OpenVikingもOllamaベースのセットアップウィザードを通じて完全なローカル動作をサポートしています。RetainDBとSupermemoryはクラウドのみ対応であり、ローカルでの実行はできません。

Hermes Agentは、メモリに保存するデータをどのように決定しますか？

エージェントは優先度決定木に基づいてメモリを能動的に保存します。ユーザーからの明示的な修正と指示は即時に保存されます。推測された好みや観察されたパターンはユーザープロファイルに記録され、環境の事実、プロジェクトの慣習、およびツール特有の特性はエージェントノートに格納されます。容易に再発見できる情報やセッション固有の一時情報は保存対象から除外されます。メモリが満杯になった場合、エージェントは新しいエントリを追加する前に、関連するエントリを統合・圧縮してメモリを整理します。

Hermesエージェントのメモリはローカルに保存されているか、クラウドに保存されているか

デフォルトでは、すべてのメモリはローカルマシンまたはVPSに完全に保存され、外部サーバーとの同期は一切行われません。MEMORY.mdとUSER.mdは ~/.hermes/memories/ 内のプレーンテキストファイルであり、会話履歴は ~/.hermes/state.db に保存されます。Mem0、Honcho、またはRetainDBといったクラウドベースの外部プロバイダーを設定した場合、データはそれらのサードパーティサービスに送信されますが、コアメモリファイルは常にローカルに保持されます。

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

メモリは、ツールとパートナーの違いを決定づける。

ご存知の通り、AIエージェントとのチャットを開き、プロジェクトの説明、好みなどを伝え、作業を進めて、タブを閉じます。翌週に戻ってみると、まるで初めて話す陌生人のよう——すべての文脈が消え、あらゆる好みが忘れ去られ、プロジェクトの説明を最初からやり直すことになります。

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

単発のやり取りであれば、これで十分です。質問して、答えを得て、次に進みます。しかし、エージェント——セッションを超えて「作業」を行い、間違いから学び、共に進化すべきシステム——にとっては、ステートレス性は大きなアーキテクチャ上の制限となります。これは自己ホスト型AIシステムにおける中心的な未解決問題の一つです。

3d electro tetris as an ai agent memory system

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

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

[Hermes Agent](https://www.glukhov.org/ja/ai-systems/hermes/）は根本的に異なるアプローチを取ります。メモリはエージェントが必要に応じて「取得」するものではありません。それはシステムプロンプトに組み込まれ、キュレーションされ、制限され、常にアクティブな、エージェントが「常に持っている」ものです。それは速いために小さく、有用であるために構造化され、何を忘れるべきかを知るために規律のあるものです。

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

Part 1: AIエージェントのメモリ問題

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

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

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

しかし、コンテキストはメモリではありません。それらには実質的で重要な違いがあります。コンテキストは現在表示されているすべての情報であり、メモリは能動的に保持し、持ち運ぶものです。

コンテキストにはキュレーションがありません。それはダンプです：成長につれて、モデルは必要な1つの事実を見つけるために、関連性の低い歴史の何千ものトークンを処理しなければなりません。これによりトークンとコストがかかります、レイテンシーが増加し、最終的に天井に達します。

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

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

研究の現状

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

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

Zep / Graphiti は、時系列エンティティ追跡による会話メモリに焦点を当てています。事実は有効性ウィンドウを持ち、グラフはいつ情報が真であったかを知ります。関係グラフが必要なチャットボットには強力で、自律エージェントが環境事実やプロジェクトの慣習を追跡するのには適していません。

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

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

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

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

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

Part 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: エージェントのメモ

ここは、エージェントが環境、プロジェクト、ツール、慣習、教訓について学んだすべてを保存する場所です。以下のような外観になります：

User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL
This machine runs Ubuntu 22.04, has Docker and kubectl installed
User prefers snake_case for variable names and avoids camelCase

これらはログではありません。事実です。濃密で宣言的、情報満載。タイムスタンプはなく、飾りもなく、「1月5日にユーザーは私に〜と尋ねた」などという記述もありません。

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

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

User is a full-stack developer comfortable with TypeScript, Go, and Python.
User prefers snake_case for variable names and avoids camelCase.
User primarily uses Linux Ubuntu 22.04.
User deploys to AWS using Terraform.

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

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

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

══════════════════════════════════════════════
MEMORY (your personal notes) [7% — 166/2,200 chars]
══════════════════════════════════════════════
User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL
§
This machine runs Ubuntu 22.04, has Docker and kubectl installed
§
User prefers snake_case for variable names and avoids camelCase
§

══════════════════════════════════════════════
USER PROFILE (who the user is) [8% — 110/1,375 chars]
══════════════════════════════════════════════
User is a full-stack developer comfortable with TypeScript, Go, and Python.
§
User prefers snake_case for variable names and avoids camelCase.
§

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

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

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

キャラクター制限としての機能

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

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

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

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

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

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

すべてのメモリエントリは受け入れ前にスキャンされます。システムはプロンプトインジェクションの試み、認証情報の流出、SSHバックドア、および目に見えないUnicode文字をブロックします。

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

Part 3: メモリが発火するとき —— トリガーと意思決定

Hermes Agentのメモリについて最もよく聞かれる質問は、実際に何を保存するかです。

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

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

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

ユーザーの修正。 エージェントを修正するときは、記憶するシグナルです。「また那样的なことをしないでください」「これを使用してください」「これを覚えておいてください」。これらはメモリを更新するための明示的な指示です。

例：エージェントにPython環境の設定を依頼します。エージェントはpipを提案します。あなたは「私はすべてpoetryを使います」と言います。エージェントは保存します：User prefers using the 'poetry' package manager for all Python projects.

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

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

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

例：エージェントは何がインストールされているかを確認し、保存します：This machine runs Ubuntu 22.04, has Docker and kubectl installed.

プロジェクトの慣習。 プロジェクトがどのように構成され、どのツールを使用し、どのパターンに従うか。これらはコード検査を通じて発見され、保存されます。

例：User's project is a Go microservice at ~/code/gateway using 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など。これらは外部コンテキストが必要と判断されたときに使用されます。

意思決定ツリー

以下は、エージェントが「これは記憶する価値があるか？」を重んじる方法です：

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

エージェントはこれについて過剰に考えません。能動的に保存し、満杯時に統合し、キャラクター制限がものを引き締めることを信頼します。

Part 4: 内部メモリ vs 外部ナレッジベース

ここで混乱が生じやすいです。Hermes Agentには内部メモリ（MEMORY.md、USER.md、外部プロバイダー）と外部ナレッジベース（LLM Wiki、Obsidian、Notion、ArXiv、ファイルシステム）があり、それらは完全に異なる役割を果たします。これは取得拡張生成パイプラインとエージェントのワーキングメモリの区別に似ています——外部取得は深い知識のルックアップには適していますが、アイデンティティや好みを運ぶのには適していません。内部メモリはエージェントの脳です——常にアクティブ、キュレーションされ、すべてのセッションに持ち込まれます。外部ナレッジベースはそのライブラリです——オンデマンドで参照される広大なリファレンスリソース。

区別

内部メモリ（脳）：

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

外部ナレッジベース（ライブラリ）：

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

それらがどのように関連するか

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

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

Obsidian: 双方向リンクを持つ個人ノートバウツ。エージェントはobsidianスキルを使用して読み取り、検索、ノートを生成します。ObsidianはHermesがライブラリリソースとして活用できるより広範な個人知識管理エコシステムの一部です。

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

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

ファイルシステム: プロジェクトコード、ドキュメント、設定。エージェントはプロジェクト作業中にファイルを読み取ります。

蒸留パターン

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

例：エージェントはArXivからAIエージェントのメモリスケーリングに関する論文を読み込みます。それはメモリに論文全体を保存しません。それはキーメッセージを保存します：Memory scaling: agent performance improves with accumulated experience through user interaction and business context stored in memory.

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

どちらを使用するか

内部メモリ：

「誰を支援しているか？」
「何が好みか？」
「何を学んだか？」
「プロジェクト設定は？」
「利用可能なツールは？」

外部ナレッジベース：

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

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

Part 5: 実際の仕組み

メカニクスを見てみましょう。

`memory`ツール

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

readアクションはありません——メモリコンテンツはシステムプロンプトに自動注入されます。エージェントは常にそこに存在するため、読み取る必要はありません。

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

memory(action="add", target="memory",
       content="User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed.")

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

memory(action="replace", target="memory",
       old_text="dark mode",
       content="User prefers light mode in VS Code, dark mode in terminal")

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

memory(action="remove", target="memory",
       old_text="temporary project fact")

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

replaceとremoveはold_text経由で短いユニークなサブストリングを使用します。完全なエントリテキストは必要ありません。これにより、正確なコンテンツを知らずに外科的な編集が可能になります。

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

ターゲットストア: `memory` vs `user`

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

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

キャパシティ管理

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

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

User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed. Shell: zsh with oh-my-zsh. Editor: Neovim with Telescope plugin.

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

User has a project.
On January 5th, 2026, the user asked me to look at their project which is located at ~/code/gateway and it uses Go with gRPC and PostgreSQL for the database layer.

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

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

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

機能	永続メモリ	セッション検索
容量	合計約1,300トークン	無制限（すべてのセッション）
速度	即座（システムプロンプト内）	検索＋LLM要約が必要
使用ケース	常に利用可能なキーファクト	特定の過去の会話の発見
管理	エージェントによる手動キュレーション	自動——すべてのセッションが保存
トークンコスト	セッションごとに固定（約1,300トークン）	オンデマンド（必要に応じて検索）

一般的な規則：コンテキストに常に存在すべき重要な事実にはメモリを使用し、履歴ルックアップにはセッション検索を使用します。

Part 6: 外部メモリプロバイダー

組み込みのMEMORY.mdとUSER.mdを超えて、Hermes Agentは1つの外部メモリプラグイン——Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、またはSupermemory——を一度にアタッチでき、永続的かつセッション横断的な知識を提供します。一度にアクティブな外部プロバイダーは1つだけです。2つのコアファイルはそれと併せて読み込まれます（追加的であり、置換ではありません）。

hermes memory setup、hermes memory status、およびhermes memory offでプロバイダーを有効化・検査するか、~/.hermes/config.yamlでmemory.providerを設定します。

完全な比較表、LLMおよび埋め込み依存性の注記、プロバイダー別の詳細、およびこれらのバックエンドがOpenClawや他のスタックとどのように関連するかについては、**エージェントメモリプロバイダーの比較**を参照してください。

プロファイル固有の配線および本番ワークフローについては、Hermes Agent本番セットアップを参照してください。**AIシステムメモリハブ**には、このガイドと関連するCogneeおよび知識レイヤーの記事がリストされています。

Part 7: 哲学

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

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

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

キュレーションが品質を強制する。 限られたスペースがある場合、重要なもののみを保存します。圧縮、統合、優先順位付けを行います。無制限のメモリはすべてをダンプし、決して片付けないことを促します。

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

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

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

「忘却」の問題

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

Hermes Agentはそれを以下のように処理します：

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

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

メモリスケーリング

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

その研究はそう示唆していますが、留保付きです。メモリスケーリングには以下が必要です：

品質抽出: すべての相互作用が記憶されるべきではありません。エージェントはログではなく、洞察を抽出しなければなりません。
効果的な取得: 取得されたメモリは関連性がなければなりません。ノイズはパフォーマンスを低下させます。
一般化: メモリは特定のものではなく、パターンであるべきです。「ユーザーは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月には64,000以上のGitHubスター（v0.9.0）に達し、242人以上の貢献者を持ちます。それはオープンソースであり、github.com/NousResearch/hermes-agentで利用可能です。インストール、設定、ワークフローガイドについては、Hermes Agent概要を参照してください。