Hermes Agentのメモリシステムとは何か、そしてそれはどのように機能するのでしょうか？

Hermes Agentは、 ~/.hermes/memories/ に保存される2つのファイルによる永続メモリシステムを採用しています。これには、 MEMORY.md （最大2,200文字）と USER.md （最大1,375文字）が含まれ、各セッションの開始時にシステムプロンプト内へfrozen blockとして注入されます。エージェントは、add、replace、removeの各ツールアクションを通じてこれらのファイルを管理し、検索プロセスを介することなく、常に重要な事実を利用可能な状態に保ちます。

なぜHermes Agentは、すべてを保存するのではなく、メモリを約3,600文字に制限しているのでしょうか？

文字数制限は技術的な制約ではなく、意図的な設計上の選択です。メモリに制限を設けることで、エージェントはすべてを詰め込むのではなく、重要な情報を圧縮、統合、優先順位付けするという「精査」を余儀なくされます。小規模で精査されたメモリは、際限なく増え続けるリトリーバル・データベースと比較して、高速（LLMのprefix cachingを活用）であり、ノイズが少なく、より有用です。

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

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

Hermes Agentのcore memoryとsession searchの違いは何ですか？

Core memory（MEMORY.mdおよびUSER.md）は、システムプロンプトに常に含まれる、厳選された重要な事実の小さなセットを保持します。これにより、クエリを必要とせず、即座にアクセス可能で、トークンコストも固定されます。一方、Session searchは、エージェントがCore memoryに集約されていない過去のセッションの情報を必要とした際に、SQLiteの会話履歴全体をオンデマンドで検索します。Core memoryは常に重要となる情報の保持に、Session searchは履歴の参照に特化しています。

Memoryが有効化されている場合、Hermes Agentはどのようにrecallを実行し、各ターンをどのように保存するのでしょうか？

各モデルの返答前に、フレームワークは現在のユーザーメッセージをクエリとして使用し、設定された外部プロバイダーからコンテキストをプリフェッチします。アシスタントの返答後、同期パスによって永続的な状態が保持されます。組み込みのMEMORY.mdおよびUSER.mdは、プロバイダーと並行してロードされたままとなります。これらは「どちらか一方」ではなく、「二層構造」として機能します。

Hermes Agentの外部メモリプラグインにおいて、recall modeは何を制御するのでしょうか？

自動プリフェッチ注入のみ、プロバイダー取得ツールのみ、あるいはその両方を同時に選択できます。これにより、トークンの消費量と、モデルが検索ツールや推論ツールをどれほど明示的に呼び出す必要があるかとの間でトレードオフが可能になります。

Hermes Agentは、どの外部メモリプロバイダーをサポートしていますか？

Hermes Agentは、Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、Supermemoryの8種類の外部メモリプロバイダー・プラグインをサポートしています。外部プロバイダーは一度に1つのみ有効化でき、常にアクティブなMEMORY.mdおよびUSER.mdファイルに置き換えるのではなく、それらに情報を追加する形で機能します。各プロバイダーは hermes memory setup で設定可能であり、セルフホスト型のナレッジグラフからエンタープライズ向けのコンテキスト・フェンシングまで、幅広いユースケースをカバーしています。プロバイダーによって外部依存関係は異なり、LLM、embeddingモデル、またはPostgreSQLデータベースを必要とするものもあれば、Holographicのようにこれらを一切必要とせず、完全にローカルで動作するものもあります。有効化コマンドや依存関係の一覧を含む比較については、www.glukhov.org の「Agent memory providers compared」をご参照ください。

データをクラウドに送信することなく、完全にローカルで実行できるHermes Agentのメモリプロバイダーはどれですか？

Holographicは、LLM、embeddingモデル、データベース、ネットワークコールといった外部依存関係が一切ない唯一のプロバイダーです。より高性能なローカル環境を構築する場合、HindsightとMem0はどちらもLLMおよびembeddingの推論にOllamaをサポートしており、すべてのデータはマシン内に保持されます。ByteRoverはメモリをプレーンなMarkdownファイルとして保存し、OllamaなどのローカルLLMのみを必要とするため、embeddingモデルやデータベースは不要です。OpenVikingも、Ollamaベースのセットアップウィザードを通じて完全なローカル動作をサポートしています。一方、RetainDBとSupermemoryはクラウド専用であり、ローカルでの実行はできません。

Hermes Agentは、何をメモリに保存するかをどのように決定しているのでしょうか？

エージェントは、優先順位に基づく決定木に従ってプロアクティブにメモリを保存します。ユーザーによる明示的な修正や指示は、即座に保存されます。推論された好みや観察されたパターンはユーザープロファイルに格納され、環境に関する事実、プロジェクトの規約、ツールの癖などはエージェントノートに格納されます。一方で、容易に再発見可能な情報やセッション固有の一時的なデータは保存対象から除外されます。メモリが満杯になった場合、エージェントは新しい情報を追加する前に、関連するエントリを統合・圧縮することでコンソリデーション（整理）を行います。

Hermes Agentのメモリは、ローカルに保存されますか、それともクラウドに保存されますか？

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

Hermes Agent Memory System：パーシステントなAIメモリの仕組み

「メモリ（記憶）の有無こそが、ツールとパートナーを分かつ境界線である。」

お分かりでしょう。AIエージェントとチャットを開始し、プロジェクトについて説明し、好みを共有し、いくつかの作業を済ませ、タブを閉じます。そして翌週に戻ってくると、まるで初対面の相手と話しているかのようです。すべてのコンテキストは失われ、すべての好みは忘れ去られ、プロジェクトを一から説明し直すことになります。

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

単発のやり取りであれば、それで問題ありません。質問をして、答えを得て、次に進むだけです。しかし、セッションをまたいで「物事を行う」こと、間違いから学び、ユーザーと共に進化することを目的とした「エージェント」にとって、ステートレスさは深刻なアーキテクチャ上の限界となります。これは、self-hosted AI systemsにおける中心的な未解決問題の一つです。

3d electro tetris as an ai agent memory system

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

これらのアプローチの多くには共通の問題があります。メモリを「後付けの要素」として扱っていることです。つまり、クエリを投げるデータベース、詰め込むだけのコンテキストウィンドウ、あるいは明快さをもたらすのではなく遅延とノイズを増大させる検索システムとして扱っているのです。

Hermes Agentは、根本的に異なるアプローチを取ります。メモリは、エージェントが必要な時に「検索するもの」ではありません。メモリとは、エージェントが常に「そうである」状態を指します。システムプロンプトに組み込まれ、精査され、境界が定められ、常にアクティブなものです。高速であるために十分に小さく、有用であるために十分に構造化されており、忘れるべきことを知るために十分に規律に基づいています。

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

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

なぜ「コンテキストを追加するだけ」ではエージェントに対してスケールしないのか

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

しばらくの間は、それでうまくいきます。128Kのコンテキストウィンドウがあれば、大量のテキストを収めることができます。

しかし、コンテキストはメモリではありません。両者の間には、現実的かつ重要な違いがあります。コンテキストとは「今見せられているものすべて」であり、メモリとは「能動的に保持し、持ち越していくもの」です。

コンテキストには精査（キュレーション）がありません。それは単なる「データの塊」です。コンテキストが大きくなるにつれ、モデルは必要な一つの事実を見つけ出すために、何千もの無関係な履歴トークンを処理しなければならなくなります。これはトークンとコストの浪費を招き、レイテンシを悪化させ、最終的には限界に達します。

メモリは精査されています。それは、経験をコンパクトで実行可能なものへと蒸留したものです。無限に成長するのではなく、統合、更新、そして忘却を行います。

人間の記憶も同じように機能します。これまでのすべての会話を覚えているわけではありません。誰と話しているのか、相手が何を重視しているのか、何に合意したのか、何を学んだのかといった、重要な部分だけを覚えています。残りの部分は忘れられるか、必要になった時に検索可能な状態になっています。

研究の現状

AIエージェントのメモリ領域は2024年以降爆発的に拡大しており、専用のベンチマークスイート、増え続ける研究文献、そして異なるアーキテクチャ的アプローチ間の測定可能なパフォーマンスの差が存在します。現在の状況は以下の通りです。

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

Zep / Graphiti は、時間的なエンティティ追跡を備えた会話メモリに焦点を当てています。事実に有効期限を持たせることで、グラフが「いつ何が真実であったか」を把握できるようにしています。リレーションシップグラフを必要とするチャットボットには強力ですが、環境の事実やプロジェクトの慣習を追跡する自律型エージェントにはあまり適していません。

Cognee は、ドキュメントや構造化データからの知識抽出のために構築されており、30以上のインジェクションコネクタとナレッジグラフ・バックエンドを備えています。組織的な知識やRAGパイプラインに優れていますが、個人のエージェントメモリにはあまり重点を置いていません。実践的なセットアップガイドについては、self-hosting Cognee with local LLMsを参照してください。

Hindsight は、エンティティの関係性を伴うナレッジグラフベースの想起を行い、複数のメモリを組み合わせて新しい洞察を生み出す独自の「reflect（内省）」合成ツールを備えています。エージェントメモリのベンチマークにおいてトップクラスのパフォーマンスを示しており、Hermes Agentのメモリプロバイダーとしても利用可能です。

Mem0 は、LLMによる分析を通じてサーバーサイドでメモリの抽出を行い、最小限の設定で動作します。ECAI 2025で発表されたMem0の研究論文（arXiv:2504.19413）では、AIメモリに対する10の異なるアプローチをベンチマークし、離散的な事実を保存し、重複を排除し、関連するものだけを想起するという「選択的抽出」アプローチの有効性を検証しました。Mem0はGitHubスター数約48Kに成長し、21のフレームワーク統合をサポートしています。トレードオフは、クラウドへの依存度とコストです。

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

ほとんどのフレームワークに共通する問題は、メモリを「検索問題」として扱っていることです。つまり、どこかに保存し、必要に応じてクエリを投げ、コンテキストに注入するという考え方です。Hermesはそれとは逆のアプローチを取ります。メモリはオンデマンドで検索されるのではなく、セッション開始時に注入され、常に存在します。常にアクティブで、常に利用可能であり、有用性を保つために十分に精査されています。

第2部：アーキテクチャ

このセクションは、上から順に読んでください。まずレイヤーとターンごとの想起/保存について、次にMEMORY.mdとUSER.mdに何が格納されるか、最後に外部プロバイダーをどのように接続するかについて説明します。

2つのレイヤー

Hermesはメモリを2つのレイヤーでスタックしています。

組み込み (Built-in) — MEMORY.md と USER.md。ファイルにバックアップされ、常にアクティブです。上限は、エージェントのメモとして2,200文字、ユーザープロファイルとして1,375文字です。
外部プロバイダー（オプション） — Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、Supermemory、および設定で有効にした同等のプロバイダー。一度に実行できるのは1つだけです。これはファイルに加えて検索と保持機能を追加するものであり、ファイルを置き換えるものではありません。

メンタルモデルは「加法的」です。固定されたコアファイルに、最大1つのプラグインが加わります。Prefetch（事前取得）とsync（同期）のフックが外部レイヤーをオーケストレーションし、2つのファイルは固定システムプロンプトの一部として個別に注入されたままとなります。

ランタイムフロー（prefetch と sync）

想起（Recall）はモデルが回答する前に行われ、永続化（Persistence）はアシスタントのメッセージの後に行われます。Hermes Agentのメモリマネージャーでは、これは入力時のprefetchと出力時のsyncに対応します。以下の名称は実装上のインターフェース（MemoryManager、プロバイダーごとの prefetch / sync_turn / queue_prefetch）と一致しています。

ユーザーメッセージ
    |
    v
MemoryManager.prefetch_all(query)        <-- 想起フェーズ
    |
    +-- provider.prefetch(query)        <-- 各外部プロバイダーが自身のストアを検索
    |
    v
LLMのターンにコンテキストを注入
    |
    v
LLMが回答（アシスタントメッセージ）
    |
    v
MemoryManager.sync_all(user, assistant)  <-- 保存フェーズ
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- 次のターンに向けたバックグラウンド検索

組み込みの MEMORY.md と USER.md は prefetch_all を通じて取得されることはありません。これらはすでに固定システムプロンプトの一部となっているからです。外部バックエンドは prefetch_all / sync_all にプラグインされます。queue_prefetch を使用すると、現在の回答をブロックすることなく、プロバイダーが次のターンのための検索を準備（ウォームアップ）できます。

長期メモリへの3つのパス

組み込みの memory ツール。 指示の中で「永続させるべきこと」（永続的な事実、好み、修正、環境に関するメモなど）が示された場合、モデルは memory を add、replace、または remove で呼び出します。target='user' は USER.md を維持し、target='memory' は MEMORY.md を維持します。例：memory(action='add', target='user', content='…')。
外部プロバイダーによる受動的な保持。 フレームワークは各ターンでプロバイダーの同期パスを呼び出すため、モデルがすべての事実を明示的に命名することなく、会話をチャンク化、要約、または抽出できます。動作はバックエンドによって異なります。例えば、Hindsightはターンをバッチ処理してエンティティと関係性を用いた構造化された保持を実行します。Honchoは対話パイプラインを通じてダイアログを送信します。Mem0やSupermemoryスタイルのスタックは、ターンから受動的に事実を抽出します。
プロバイダー固有のツール。 プラグインが公開している場合、honcho_conclude、hindsight_retain、または honcho_profile のような明示的な書き込みによって、オンデマンドで永続的なスライスを保存できます。

自動想起 vs プロバイダーツール

コアメモリには読み取り（read）ツールは必要ありません。すでにプロンプト内に含まれているからです。外部バックエンドは、prefetchによる自動注入（そのコンテキストのスライスに対して個別の想起ツール呼び出しは不要）、または、prefetchだけでは不十分な鋭いクエリが必要な場合に、モデルが明示的な取得を選択できるツール（honcho_search、honcho_reasoning、honcho_context、hindsight_recall、hindsight_reflect など）のいずれかを提供します。

想起モード（外部プロバイダー）

プラグインは、トークンと制御のトレードオフを行う設定可能な想起モード（通常、設定内の memory.provider の隣にある recall_mode）をサポートしています。

モード	prefetchからの自動注入	プロバイダーツール利用可	適した用途
context	はい	いいえ	自動化、予測可能なコンテキスト
tools	いいえ	はい	モデルが取得タイミングを選択
hybrid	はい	はい	最も豊かなコンテキスト、トークン使用量増

外部プロバイダーが設定されていない場合（memory.provider が空または未設定の場合）、組み込みのファイルとセッション検索のみが適用され、プラグインによる prefetch/sync は行われません。

ディスク上のパスと予算

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

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

これが永続メモリの全容です。合計で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.
§

このフォーマットは、ヘッダー、使用率、文字数、および § (セクション記号) の区切り文字を使用しています。エントリは複数行にわたることができます。これは、人間にとって読みやすい状態を保ちつつ、モデルが解析しやすいように設計されています。

なぜ「フローズン（固定）」なのか？それは Prefix caching のためです。システムプロンプトは、セッション内のすべてのターンで同じです。セッション開始後にメモリを静的な状態に保つことで、モデルはプレフィックスの計算をキャッシュし、変数部分（会話内容）のみを処理できます。これは大幅なパフォーマンスの最適化になります。毎ターン、同じメモリトークンに対してアテンションを再計算する必要はありません。

セッション中に加えられた変更は即座にディスクに保存されますが、システムプロンプトに反映されるのは次のセッション開始時のみです。ツールのレスポンスには常に最新の状態が表示されますが、モデルの「思考」はセッションの途中で変わることはありません。これにより、モデルがメモリを更新した直後に、同じ会話の中でその更新に反応してしまうという「自分の尻尾を追いかける」ような事態を防ぎます。

機能としての文字数制限

2,200文字。1,375文字。これらは恣意的な制限ではありません。精査を強制するための設計上の制約です。

無制限のメモリは負債となります。何でも放り込み、決して統合せず、最終的にはノイズになってしまいます。境界のあるメモリは、エージェントに選択を強います。「本当に重要なことは何か？」「次に必要になるものは何か？」「意味を失わずに圧縮できるものは何か？」

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

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

これが、メモリの有用性を維持する方法です。メモリはデータベースではありません。重要な事実の精査されたコレクションなのです。

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

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

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

外部メモリプロバイダー（有効化とリンク）

組み込みの 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 と recall_mode を設定してください。資格情報のパターンは異なります（例：HINDSIGHT_API_KEY、または $HERMES_HOME/honcho.json にあるHonchoのキー）。対話的な設定には hermes memory setup を使用してください。

最小限の組み込みのみのYAML構成：

memory:
  provider: ""
  memory_enabled: true
  user_profile_enabled: true

1つのバックエンドを有効にする例（hindsight を、インストールされている honcho、mem0、supermemory などに置き換えてください）：

memory:
  provider: "hindsight"

完全な比較表、LLMおよび埋め込みへの依存に関する注意点、プロバイダーごとの詳細、およびこれらのバックエンドがOpenClawや他のスタックとどのように関連するかについては、Agent memory providers compared を参照してください。

プロファイル固有の構成および本番環境のワークフローについては、Hermes Agent production setup を参照してください。AI Systems Memory hub には、このガイドのほか、関連するCogneeおよび知識レイヤーに関する記事がリストされています。

第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 ツールを使用します。これは、FTS5全文検索とGemini Flashの要約を用いてSQLite (~/.hermes/state.db) にクエリを投げます。「この事実を永遠に覚えておいて」というよりは、「以前これについて話しましたよね？」といったニュアンスの質問の際に使用してください。

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

外部プロバイダーツール（設定されている場合）。 外部メモリプロバイダーがアクティブな場合、フレームワークは各回答の前に自動的なprefetchステップも実行します（第2部参照）。追加のツール（honcho_search、hindsight_recall、mem0_search など）は、エージェントが明示的な取得を選択した際のターゲット検索用です。recall_mode に応じて、自動注入、ツール、またはその両方がアクティブになります。

決定ツリー

エージェントは以下のように「これは覚える価値があるか？」を判断します。

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

エージェントはこれを深く考えすぎません。能動的に保存し、満杯になったら統合し、文字数制限によって内容をタイトに保つことを信頼しています。

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

ここで混乱が生じることがよくあります。Hermes Agentには「内部メモリ」（MEMORY.md、USER.md、外部プロバイダー）と「外部知識ベース」（LLM Wiki、Obsidian、Notion、ArXiv、ファイルシステム）があり、それらは全く異なる役割を果たします。これは、retrieval-augmented generation パイプラインとエージェントのワーキングメモリの区別と似ています。外部検索は深い知識の検索には適していますが、アイデンティティや好みを保持するためには適していません。内部メモリはエージェントの「脳」であり、常にアクティブで、精査され、すべてのセッションに持ち越されます。外部知識ベースはエージェントの「図書館」であり、必要に応じて参照される膨大なリファレンスリソースです。

その違い

内部メモリ（脳）：

小規模、永続的、システムプロンプトに注入される
内容：ユーザーの好み、エージェントの慣習、直近の教訓
会話中は常に「念頭にある」
精査され、境界が定められ、能動的に管理される
例：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が図書館リソースとして利用できる広範な personal knowledge management エコシステムの一部です。

Notion/Airtable: APIを介してアクセスされる構造化データベースおよびWiki。エージェントは必要に応じてこれらにクエリを投げます。

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

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

蒸留パターン

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

例：エージェントが、AIエージェントのメモリ・スケーリングに関するArXivの論文を読みました。論文全体をメモリに保存することはありません。重要な要点だけを保存します：Memory scaling: agent performance improves with accumulated experience through user interaction and business context stored in memory.（メモリ・スケーリング：エージェントのパフォーマンスは、メモリに保存されたユーザーとの対話やビジネスコンテキストを通じた蓄積された経験によって向上する。）

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

使い分け

内部メモリを使用する場合：

「私は誰を助けているのか？」
「その人は何を好むのか？」
「私たちはたった今何を学んだのか？」
「プロジェクトのセットアップはどうなっているか？」
「どのようなツールが利用可能か？」

外部知識ベースを使用する場合：

「Xに関する最新の研究は何か？」
「プロジェクトのドキュメントには何が書かれているか？」
「先月、私たちは何について話し合ったか？」
「このサービスのAPIはどのようなものか？」
「コードの構造はどうなっているか？」

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

第5部：実際の仕組み

そのメカニズムを見てみましょう。

`memory` ツール

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

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")

部分一致 (Substring Matching)

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トークン)	オンデマンド (必要時に検索)

経験則として、常にコンテキストにあるべき重要な事実にはメモリを使用してください。履歴の検索にはセッション検索を使用してください。

第6部：哲学

なぜ境界のあるメモリが、無制限のメモリに勝るのか

本能的には、メモリを可能な限り大きくしたいと考えがちです。すべてを保存し、必要なものを検索する、という考えです。

しかし、境界のあるメモリの方がうまく機能します。その理由は以下の通りです。

精査が質を強制する。 スペースが限られているとき、重要なものだけを保存します。圧縮、統合、優先順位付けを行います。無制限のメモリは、何でも放り込んで、決して掃除をしないことを助長してしまいます。

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

ノイズはパフォーマンスを低下させる。 メモリが多いからといって、それが良いメモリであるとは限りません。むしろノイズが増えるだけです。モデルはシグナルとノイズを区別しなければならず、それにはアテンション（注意）が必要です。そのアテンションは、実際のタスクに費やされるべきものです。

忘却は機能である。 人間の記憶は忘れます。それはバグではなく、優先順位をつけるための仕組みです。エージェントも忘れるべきです。すべてが記憶に値するわけではありません。

「忘却」の問題

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

Hermes Agentは以下のように対処します。

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

忘却は失敗ではなく、メンテナンスです。学習解除できないエージェントは、最終的にシグナルと同じくらいのノイズを抱え込むことになります。

メモリ・スケーリング

Databricksは「メモリ・スケーリング」という概念を導入しました。数千人のユーザーを持つエージェントは、単一のユーザーを持つエージェントよりも高いパフォーマンスを発揮するのか？

彼らの研究は、いくつかの条件付きで「イエス」を示唆しています。メモリ・スケーリングには以下が必要です。

高品質な抽出: すべての対話が記憶に値するわけではありません。エージェントはログではなく、洞察を抽出しなければなりません。
効果的な検索: 検索されたメモリは関連性がなければなりません。ノイズはパフォーマンスを低下させます。
汎用化: メモリは具体的な事項ではなく、パターンであるべきです。「ユーザーはPythonを好む」はスケールしますが、「ユーザーは時刻YにコマンドXを実行した」はスケールしません。

Hermes Agentの境界のあるメモリは、自然にメモリ・スケーリングをサポートします。精査を強制することで、メモリが汎用可能で、コンパクトで、有用であることを保証します。

これが未来にとって何を意味するか

メモリは、エージェント型AIにおける競争優位性の源泉（モート）になりつつあります。モデルそのものではなく、モデルがセッション間で何を「持ち越すか」です。基盤となるモデルが同一であっても、2つのエージェントは全く異なるパフォーマンスを示す可能性があります。一方はあなたの好み、環境、過去のミスを覚えていますが、もう一方は毎回ゼロから始まります。

エージェントが永続的なメモリを持つべきかどうかという問いは、もはや議論の余地がありません。それは決着しています。持つべきなのです。未解決の問いは、そのメモリをいかに上手く設計するかです。何を保持し、何を破棄するか、いかに即時的なものにするか、そしていかにノイズ化を防ぐかです。

Hermes Agentの答えは、メモリを小さく、精査され、常にアクティブな状態に保つことです。それはクエリを投げるデータベースではなく、エージェントがすべての会話に持ち越す、ユーザーの「動的なモデル」なのです。

結論

Hermes Agentのメモリシステムは、意図的にシンプルです。2つのファイル、厳格な文字数制限、検索パイプラインなし、vector databaseなし、そしてクエリごとのレイテンシなし。制約のように聞こえることが、まさにその目的です。

それが機能するのは、メモリをデータベースとしてではなく、脳のように扱うからです。小さく、精査され、常にアクティブです。エージェントは必要になったときにメモリを検索するのではなく、メモリは単にそこにあり、すべてのセッションの最初のトークンからシステムプロンプトに編み込まれています。

外部メモリプロバイダーは、ナレッジグラフ、マルチエージェント・サポート、セルフホスト・ストレージ、エンタープライズ機能など、より多くの機能を必要とするユーザーのためにこのシステムを拡張します。しかし、コアは変わりません。境界があり、精査され、常に利用可能です。

そして、外部知識ベース（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 overview を参照してください。