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

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

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

文字数の制限は技術的な制約ではなく、意図的な設計上の選択です。有限のメモリは、エージェントに情報のキュレーション（圧縮、統合、重要度の優先順位付け）を強要し、すべての情報を無差別に格納するのを防ぎます。膨大な検索データベースよりも、小さくキュレーションされたメモリは、LLMのプレフィックスキャッシングを利用することで高速であり、ノイズが少なく、より実用的です。

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

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

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

コアメモリ（MEMORY.mdおよびUSER.md）には、システムプロンプトに常時組み込まれる少量の厳選された重要事実が保持されており、クエリ不要で即座にアクセス可能かつトークンコストは固定です。セッション検索は、エージェントがコアメモリに凝縮されていない過去のセッション情報が必要になった場合に、SQLiteの会話履歴全体をオンデマンドで照会します。コアメモリは常に重要な情報用であり、セッション検索は履歴の検索用です。

Hermes Agentは、メモリ機能が有効になっている場合、各ターンでどのように検索（recall）を実行し、情報を保存しているのでしょうか？

各モデルのレスポンス前に、フレームワークは現在メッセージをクエリとして用いて、設定済みの外部プロバイダからコンテキストをプリフェッチします。アシスタントのレスポンス後、同期パスは永続的な状態を保持します。組み込みの MEMORY.md と USER.md はプロバイダと並行して読み込まれたまま残り、二者択一ではなく二層構造となります。

Hermes Agentのエクステルナルメモリプラグインにおけるリコールモードは何を制御しますか？

自動プリフェッチの注入のみ、プロバイダー検索ツールのみ、あるいは両方を併用するかを選択します。これにより、トークン使用量とモデルが検索や推論ツールを明示的に呼び出す度合いの間でトレードオフが生じます。

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

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 Agentのメモリプロバイダーは？

Holographicは外部依存がゼロの唯一のプロバイダーです。LLM、埋め込みモデル、データベース、ネットワーク呼び出しは一切不要です。より高機能なローカルセットアップについては、HindsightとMem0はどちらもOllamaによるLLMおよび埋め込み推論をサポートしており、すべてのデータがローカルマシン内に保持されます。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は根本的に異なるアプローチを取ります。メモリは、必要に応じてエージェントが「検索」するものではありません。エージェントが常に「持つ」ものです——システムプロンプトに組み込まれ、整理され、制限され、常にアクティブです。それは高速であるために小さく、有用であるために構造化され、何を忘れるべきかを知るために規律があります。

この記事では、その仕組みを詳しく説明します。AIアシスタントのメモリシステムにおけるクロスフレームワークモデル内部のHermes固有のレイヤー、およびAIアシスタントアーキテクチャにおけるより広範なスタックについてです。アクティブ化と検査コマンド（hermes memory、hermes dump、ログのテール表示）については、Hermes Agent CLIチートシートと併せてご参照ください。Hermesの「長期知識」の補完的な側面——整理されたメモリファイルではなくSKILL.md内の再利用可能な手順——については、Hermes Agentスキル作成 — SKILL.mdの構造とベストプラクティスをご覧ください。

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

なぜエージェントには「文脈を追加するだけ」ではスケールしないのか

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

ある程度の間、それは機能します。128Kのコンテキストウィンドウを持っています。そこに多くのテキストを収めることができます。

しかし、文脈はメモリではありません——それらには現実的で重要な違いがあります。文脈は現在あなたに提示されているすべての情報です。メモリはあなたが能動的に保持し、持ち運ぶものです。

文脈にはキュレーション（整理）がありません。それはダンプです：成長するにつれて、モデルは必要とする1つの事実を見つけるために、無関係な履歴の数千トークンを処理しなければなりません。それはトークンとコストがかかります、レイテンシを増幅し、最終的には上限に到達します。

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

人間のメモリも同じように機能します。あなたはかつて行ったすべての会話を記憶していません。あなたが記憶するのは、重要な部分だけです：誰と話をしているか、何が気にされているか、何で合意したか、何を学んだか。残りは忘れ去られ、必要に応じて検索可能になります。

研究の現状

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

Letta（旧MemGPT）は、永続メモリを第一級の関心事として扱う最も初期のフレームワークの一つであり、GitHubスター数は21,700に達しています。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は約48,000のGitHubスターに成長し、21のフレームワーク統合をサポートしています。トレードオフはクラウド依存とコストです。

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

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

パート2：アーキテクチャ

この部分は上から下へ読んでください——まずレイヤーとターンごとのリコール/ストア、次にMEMORY.mdとUSER.mdに何が含まれるか、最後に外部プロバイダーを接続する方法です。

2つのレイヤー

Hermesはメモリを2つのレイヤーにスタックします：

ビルトイン —— MEMORY.mdとUSER.md、ファイルベースで常にアクティブ。エージェントメモには2,200文字、ユーザープロファイルには1,375文字という硬性上限があります。
1つの外部プロバイダー（オプション） —— Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、Supermemory、および設定で有効化する同等のもの。一度に1つだけの外部バックエンドが実行されます。それはファイルの横に検索と保持を追加しますが、それらを置き換えるものではありません。

メンタルモデルは累積的です——フリーズされたコアファイルと最大1つのプラグイン。プリフェッチと同期フックは外部レイヤーをオーケストレートします。2つのファイルはフリーズされたシステムプロンプトの一部として別々に注入され続けます。

ランタイムフロー（プリフェッチと同期）

リコールはモデルが応答する前に発生し、永続化はアシスタントメッセージの後に発生します。Hermes Agentのメモリマネージャーでは、これは入力側でのプリフェッチと出力側での同期に対応します。以下の名称は実装のサーフェス（MemoryManager、各プロバイダーのprefetch / sync_turn / queue_prefetch）と一致します。

User message
    |
    v
MemoryManager.prefetch_all(query)        <-- リコールフェーズ
    |
    +-- provider.prefetch(query)        <-- 各外部プロバイダーがそのストアを検索
    |
    v
Context injected into LLM turn
    |
    v
LLM responds (assistant message)
    |
    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ツール。 モデルは、何かが永続されるべきという指示がある場合、add、replace、またはremoveでmemoryを呼び出します——耐久性のある事実、好み、修正、環境メモ。target='user'はUSER.mdを維持し、target='memory'はMEMORY.mdを維持します。例の形状：memory(action='add', target='user', content='…')。
外部プロバイダーでの受動的保持。 フレームワークは各ターンでプロバイダーの同期パスを呼び出し、モデルが各事実を名指ししなくても、会話チャンク、要約、または抽出が行われるようにします。振る舞いはバックエンドによって異なります——例えばHindsightはターンをバッチ処理し、エンティティと関係による構造化保持を実行します；Honchoはダイアレクトパイプラインを通じて対話を送信します；Mem0およびSupermemoryスタイルのスタックはターンから事実を受動的に抽出します。
プロバイダー固有のツール。 プラグインがそれらを公開する場合、honcho_conclude、hindsight_retain、またはhoncho_profileなどの明示的な書き込みは、オンデマンドで耐久性のあるスライスを保存します。

自動リコール対プロバイダーツール

コアメモリは読み取りツールを必要としません——それはすでにプロンプト内にあるからです。外部バックエンドは、プリフェッチからの自動注入（そのコンテキストスライスには別個のリコールツール呼び出しなし）または、モデルがプリフェッチだけでは不十分な sharper クエリを必要とする場合の明示的な検索ツール（honcho_search、honcho_reasoning、honcho_context、hindsight_recall、hindsight_reflect、および同等のもの）を追加します。

リコールモード（外部プロバイダー）

プラグインは、トークンを制御とトレードオフする構成可能なリコールモード（通常は設定内のmemory.providerの横にあるrecall_mode）をサポートします。

モード	プリフェッチからの自動注入	プロバイダーツール利用可能	典型的な用途
context	はい	いいえ	ハンズオフ、予測可能なコンテキスト
tools	いいえ	はい	モデルが検索するタイミングを選択
hybrid	はい	はい	最も豊富なコンテキスト；トークン使用量が多い

外部プロバイダーが設定されていない場合（memory.providerが空または未設定）、ビルトインファイルとセッション検索のみが適用されます——プラグインからのプリフェッチ/同期はありません。

ディスク上のパスと予算

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.
§

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

なぜフリーズされるのか？プレフィックスキャッシング。システムプロンプトはセッション内のすべてのターンで同じです。セッション開始後にメモリを静的に保つことで、モデルはプレフィックス計算をキャッシュし、可変部分——会話——のみを処理できます。これは重要なパフォーマンス最適化です。あなたは各ターンで同じメモリトークン上の注意を再計算していません。

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

文字制限としての機能

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

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

メモリが満杯になると、エージェントは沈黙して失敗しません。現在のエントリと使用率を持つエラーを受け取り、次にワークフローに従います：

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

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

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

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

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

外部メモリプロバイダー（アクティブ化とリンク）

ビルトインのMEMORY.mdとUSER.mdを超えて、Hermes AgentはHoncho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、またはSupermemoryの1つの外部メモリプラグインを一度に接続できます——永続的、セッション横断的な知識のために。一度に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および他のスタックとどのように関係するかについては、**エージェントメモリプロバイダー比較**をご覧ください。

プロファイル固有の配線および本番ワークフローについては、Hermes Agent本番セットアップをご覧ください。**AIシステムメモリハブ**はこのガイドおよび関連する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ネットワークについて話した？」と尋ねます。エージェントはセッション履歴を検索し、関連会話の要約を返します。

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

決定ツリー

これがエージェントが「これは覚える価値があるか？」を重んじる方法です：

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

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

パート4：内部メモリ対外部ナレッジベース

ここで混乱がよく発生します。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は何だ？」
「コード構造はどうなっているか？」

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

パート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 via 短く一意なサブストリングを使用します。完全なエントリテキストは必要ありません。これは正確なコンテンツを知らずに外科的な編集を可能にします。

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

ターゲットストア：`memory`対`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.

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

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

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

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

経験則：常にコンテキストにあるべき重要な事実にはメモリを使用します。歴史的検索にはセッション検索を使用します。

パート6：哲学

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

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

制限されたメモリの方が良く機能します。その理由は以下の通りです。

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

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

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

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

「忘却」の問題

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

Hermes Agentがそれを処理する方法は以下の通りです：

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

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

メモリスケーリング

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

彼らの研究はイエスと示唆しますが、条件付きで。メモリスケーリングには以下が必要です：

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

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

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

メモリはエージェント型AIにおける競争の堀になりつつあります——モデル自体ではなく、モデルがセッション間で運ぶものです。同じ基礎モデルを持つ2つのエージェントは非常に異なるパフォーマンスを示す可能性があります：1つはあなたの好み、環境、過去のミスを記憶し；もう1つは毎回冷ややかにはじまります。

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

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概要をご覧ください。