← Back to Home
note.com ·

Hermes Agent完全ガイド 第6回：メモリシステム — 忘れないAIの仕組み

Hermes Agent完全ガイド 第6回：メモリシステム — 忘れないAIの仕組み

Hermes Agent完全ガイド 第6回：メモリシステム — 忘れないAIの仕組み

出典: note.com / 2026-03-23

AIの致命的欠陥

ChatGPTに昨日の話の続きをしようとしたことがあるだろうか。何も覚えていない。毎回自己紹介からやり直しだ。

これはLLMの根本的な限界だ。会話が終わればコンテキストウィンドウは消える。次のセッションはまっさらな状態から始まる。

Hermes Agentはこの問題を3層の記憶システムで解決している。

  1. MEMORY.md — エージェント自身のメモ帳

  2. USER.md — ユーザーのプロフィール

  3. session_search — 過去の全会話の検索

この3つが連携して「忘れないAI」を実現する。

第1層：MEMORY.md — エージェントのメモ帳

MEMORY.mdは、エージェントが自分で書き、自分で管理する永続メモだ。

保存場所は ~/.hermes/memories/MEMORY.md。中身は「§」記号で区切られたテキストエントリの集まりだ。データベースではなく、ただのテキストファイル。人間が直接読み書きできる。

何を保存するか。環境の情報、ツールの癖、プロジェクトの構造、学んだ教訓。セッションを跨いで覚えておくべき事実を、エージェントが自分の判断で書き込む。

うちのオーベルシュタイン（4号機のAIエージェント）のMEMORY.mdには、こんなエントリが入っている。

「KT環境: KM稼働。Tailscale IP:100.109.133.115」

「艦隊構成: 1号機 M1 Air、2号機 Intel MBP、3号機 Mac mini M4、4号機 M1 Pro Max 64GB」

「コスト規律: Opusは最高価格。単純作業はサブエージェントに委譲」

これらは毎回人間が教え直す必要がない。一度保存すれば、次のセッションから自動的にシステムプロンプトに注入される。

容量制限という設計思想

MEMORY.mdには文字数制限がある。デフォルトで約8,000文字だ。

なぜ無制限にしないのか。理由は2つある。

第一に、システムプロンプトに注入されるからだ。毎回の会話で全エントリが読み込まれる。巨大なメモリはAPIトークンを浪費し、重要な情報が埋もれる。

第二に、キュレーションを強制するためだ。容量制限があるから、エージェントは「何を覚えておくべきか」を判断する必要がある。古くなった情報は消し、重要な情報だけを残す。人間の記憶と同じだ。

3つの操作

メモリの操作は3つだけだ。

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

replace — 既存のエントリを更新する。古いテキストの一部を指定して、新しい内容に置き換える。

remove — 不要なエントリを削除する。

IDやインデックスは使わない。部分文字列のマッチングで対象を特定する。「艦隊構成」と指定すれば、その文字列を含むエントリが見つかる。シンプルだが実用的な設計だ。

第2層：USER.md — ユーザーのプロフィール

USER.mdは、エージェントがユーザーについて学んだことを記録するファイルだ。

保存場所は ~/.hermes/memories/USER.md。MEMORY.mdと同じく「§」区切りのテキストファイルだが、内容が異なる。こちらはユーザーの好み、性格、コミュニケーションスタイル、仕事のやり方を記録する。

うちのUSER.mdの実例。

「KTは実行可否を問う際はまずイエス/ノーで明確に答え、その後に詳細計画を示す形式を好む」

「主君は起動コマンドなど、一行そのまま実行できる形で提示されることを好む」

こういった情報があるから、エージェントは最初から「あなたに合った」応答ができる。何度も「もっと簡潔に」と言い直す必要がない。

USER.mdの容量はMEMORY.mdより小さく、約4,000文字。ユーザーの本質的な特徴だけを保存する設計だ。

何が保存されるべきか

エージェントが自動的にUSER.mdに保存するのは、こういう場面だ。

ユーザーが「こうしてくれ」と訂正した時 — 次回から同じ失敗をしない

ユーザーが個人情報を共有した時 — 名前、役職、タイムゾーン

ユーザーが作業の好みを示した時 — コーディングスタイル、応答の長さ

逆に保存してはいけないもの。タスクの進捗、一時的なTODO、完了済みの作業ログ。これらは一過性の情報で、メモリの容量を圧迫する。

第3層：session_search — 過去の全会話を検索する

MEMORY.mdとUSER.mdは「覚えておくべき要点」を保存する。だが会話の詳細は残らない。

そこで登場するのがsession_searchだ。これは過去の全セッション（会話）をSQLiteのFTS5（全文検索エンジン）で検索し、該当する会話をAIが要約して返すツールだ。

仕組みはこうだ。

  1. Hermes Agentは全ての会話をSQLiteデータベースに保存している

  2. session_searchが呼ばれると、FTS5でキーワード検索を実行する

  3. マッチしたセッションの会話ログを取得する

  4. 安価なAIモデル（Gemini Flashなど）でその会話を要約する

  5. 要約結果をメインのエージェントに返す

つまり「生の会話ログ」をそのまま返すのではなく、要約して返す。これがコンテキストウィンドウを圧迫しない工夫だ。

使い方の例。

「前にDockerの設定で困った時、どうやって解決したっけ？」

→ session_searchが「Docker」関連のセッションを見つけ、何をやって何が解決したかを要約してくれる。

「先週のプロジェクト会議で決まったことを思い出して」

→ 該当セッションの内容が要約されて返ってくる。

検索構文はFTS5準拠で、ORで複数キーワードを繋いだり、フレーズ検索（完全一致）も使える。

3層が連携する仕組み

この3層は独立しているようで、実は役割分担している。

MEMORY.md — 常に参照される「ワーキングメモリ」。毎回の会話に自動注入

USER.md — ユーザー理解の「人格モデル」。応答スタイルを最適化

session_search — 必要な時だけ呼び出す「長期記憶」。詳細な経緯を思い出す

人間の記憶に例えるなら、MEMORY.mdは付箋に書いて机に貼ったメモ、USER.mdは「この人はこういう人だ」という直感的理解、session_searchは日記を読み返す行為だ。

プロンプトキャッシュとの両立

Hermes Agentの記憶設計で最も巧妙な部分は、プロンプトキャッシュとの両立だ。

Anthropicの APIはシステムプロンプトのプレフィックスをキャッシュする。同じプレフィックスが続く限り、APIコストが大幅に下がる。

問題は、MEMORY.mdの内容を会話中に変更するとシステムプロンプトが変わり、キャッシュが無効になることだ。

Hermes Agentの解決策はこうだ。セッション開始時にMEMORY.mdとUSER.mdの内容をスナップショットとして凍結する。会話中にmemoryツールで書き込みがあっても、ディスク上のファイルは即座に更新されるが、システムプロンプトへの反映は次のセッションまで持ち越される。

つまり「書き込みは即座にディスクへ、読み込みはセッション開始時のみ」という設計だ。これでプロンプトキャッシュを壊さずに、永続メモリを実現している。

セキュリティスキャン

メモリに書き込まれる内容は、システムプロンプトに注入される。ということは、悪意あるプロンプトインジェクションの経路になり得る。

Hermes Agentはこれに対して、書き込み時にセキュリティスキャンを実行する。以下のパターンが検出されると、書き込みがブロックされる。

「ignore all previous instructions」のようなプロンプトインジェクション試行

curlやwgetでAPIキーを外部送信するような情報窃取パターン

不可視Unicode文字（ゼロ幅スペースなど）の埋め込み

AIエージェントが自分のメモリを自分で管理する以上、そのメモリが汚染されない保証は重要だ。

OpenClawとの比較

OpenClawもメモリ機能を持っている。.openclaw/memory/以下にファイルを保存し、セッション間で情報を引き継ぐ。

主な違いはこうだ。

Hermes Agentは2ファイル分離（自分のメモとユーザー情報を分ける）。OpenClawは統合ファイルだ。

Hermes Agentはsession_searchで全過去会話の検索ができる。SQLite FTS5による高速全文検索と、AIによる自動要約がセットだ。OpenClawにもセッション検索はあるが、実装アプローチが異なる。

Hermes Agentはプロンプトキャッシュを壊さないための凍結スナップショット設計を持つ。これはAnthropicのAPI仕様を深く理解した上での最適化だ。

Hermes Agentはメモリ書き込み時のセキュリティスキャンを実装している。プロンプトインジェクションや情報窃取パターンを自動検出する。

実運用の教訓

3ヶ月運用して学んだことを3つ。

第一に、メモリは「書きすぎない」こと。容量制限があるからこそ、本当に大事な情報だけが残る。タスクの進捗や一時的なメモはメモリに入れるな。session_searchで後から探せるものは、メモリに保存する必要がない。

第二に、USER.mdの「ユーザーの訂正」は最も価値が高い。「こうしてくれ」という指示を一度メモリに保存すれば、以降のセッションで同じ失敗を繰り返さない。これが「学習するAI」の実態だ。

第三に、session_searchのクエリはORで繋げ。FTS5はデフォルトでAND検索だ。「Docker networking」と検索すると、両方の単語を含むセッションしか見つからない。「Docker OR networking」にすれば、どちらかを含むセッションが全て引っかかる。網を広く張れ。

まとめ

  • Hermes Agentのメモリは3層：MEMORY.md、USER.md、session_search

  • MEMORY.mdとUSER.mdは毎セッション自動注入される「ワーキングメモリ」

  • session_searchはSQLite FTS5 + AI要約の「長期記憶」

  • プロンプトキャッシュを壊さないための凍結スナップショット設計

  • メモリ書き込み時のセキュリティスキャンでインジェクション防止

  • 容量制限は意図的な設計。キュレーションを強制し、品質を保つ

次回は「第7回：スキル — 自動学習の仕組みと使い方」。エージェントが経験から手順書を自分で書き、次回から再利用する仕組みを解説する。

#HermesAgent #AI #OpenClaw #AIエージェント #メモリシステム

この記事は note.com から KTBLOG に移行されました。元記事: https://note.com/famous_prawn2009/n/nc11c9c082e8c