AI 2026年4月23日

AIの「健忘症」を本気で解決しようとしたら、こんな設計になった——Hermes Agentの記憶システム解剖

𝕏 シェアする

AIの「健忘症」という、みんなが我慢してきた問題

ChatGPTでもClaudeでも、セッションを閉じた瞬間にすべてが消える。昨日あれだけ丁寧に説明したプロジェクト構成を、今日また一から話す羽目になる。

この体験、一度でもAIを実務で使っていれば必ずぶつかる。そして大半の人は「まあそういうものだから」と諦めて、毎回コンテキストを手貼りする運用で乗り切っている。

Hermes Agentは、その諦めに対して真正面から答えを出そうとしたプロジェクトだ。

Hermes Agentとは何者か

Nous Researchが開発したオープンソースのAIエージェントフレームワーク。最大の特徴は「セッションを超えて学習し続ける」という設計思想だ。

重要なのは、すべてのデータが完全ローカルに保存されるという点。会話履歴もメモリも生成されたスキルも、~/.hermes/ 配下にあるユーザーの手元に残る。クラウドにデータが吸い上げられる心配がない。

CLI、Telegram、Discord、Slackなど複数のプラットフォームに対応しており、Gateway経由で統合できる。競合として名前が挙がるのはAutoGPTやClaude Projectsあたり。

3層構造を順番に読む

記憶システムは3つのレイヤーで構成されている。なぜ3層かというと、理由はシンプルでトークン制限だ。過去の会話を全部プロンプトに突っ込めばコンテキストが溢れる。何も覚えていなければ毎回ゼロスタート。その中間を取るための設計が、この3層構造になっている。

第1層：Prompt Memory——毎回注入される「ワーキングメモリ」

~/.hermes/memories/ に2つのMarkdownファイルが置かれる。

MEMORY.md：エージェントが学んだ環境情報やプロジェクト固有の知識（「このプロジェクトはPython 3.10 + Poetryで管理」「デプロイ先はAWS Lambda ap-northeast-1」など）
USER.md：ユーザーの好みやコミュニケーションスタイル（「TypeScriptよりPythonを好む」「コードの説明は簡潔に」など）

この2ファイルは、セッション開始時に毎回システムプロンプトに丸ごと注入される。つまりエージェントは起動した瞬間から「前回までの知識」を持った状態で応答を始められる。

容量に上限がある点も重要で、MEMORY.mdは約2,200文字、USER.mdは約1,375文字という制限が設けられている。なぜかというと、これらは毎セッションでプロンプトに載るからだ。無制限に書き込めばトークンコストが際限なく膨らむ。上限に達するとエージェントが自分で古いエントリを整理・削除する。机の引き出しを自分で片付けるイメージだ。

書き込みはイベント駆動で行われる。ユーザーが明示的に伝えたとき、定期的な振り返りプロンプト、環境変化の検知、容量上限への到達——このいずれかのタイミングで更新される。「毎回必ず読む・書き込みは慎重に」という非対称な設計が、コスト管理の肝になっている。

第2層：Session Search——FTS5で検索する「長期記憶」

全会話履歴はローカルのSQLiteデータベース（~/.hermes/state.db）に保存される。第1層が「常に持ち歩くポケットメモ」なら、第2層は「本棚にしまった日記帳」だ。

検索にはSQLiteのFTS5（全文検索エンジン）を使い、さらにLLMによる要約を組み合わせている。ユーザーが「先月のDB設計の議論どうなったっけ？」と聞いたとき、FTS5で関連セッションを検索→LLMが要約→現在のコンテキストに注入→エージェントが回答、という流れだ。プロンプトに載せるのは要約版だけなので、トークン消費を最小限に抑えられる。

state.dbは各ターン終了時にリアルタイムで書き込まれ、検索はオンデマンドで実行される。第1層のメモリファイルが毎回コンテキストに載るコストを負うのに対し、第2層は検索しない限りトークンを消費しない。この非対称性が全体の設計効率を支えている。

第3層：Skills——自律生成される「手続き記憶」

~/.hermes/skills/ に、Markdownファイルとして保存される。deploy-to-aws-lambda.md、setup-python-project.md のようなファイルが並ぶ。

第1層が「何を知っているか」、第2層が「何があったか」なら、第3層は「どうやるか」を保存する層だ。

面白いのは、このスキルファイルをエージェントが自律的に生成するという点。複雑なタスクを成功裏に完了したとき、エージェントは「これは今後も使えるな」と判断すると自動的にSkillファイルを作る。しかも「前回ここでハマった」という失敗知見まで含まれる。次回同じタスクが来たとき、最初から効率的に動ける。

一度作ったSkillは固定ではなく、再実行時に改善点が見つかれば更新される。自己改善ループが機能している。

「なるほど」と思った設計の判断

個人的に膝を打ったのが、ベクトルDBを使っていないという選択だ。

RAGといえばChromaDBやPineconeのようなEmbedding検索が定番だが、HermesはあえてFTS5を選んでいる。理由はおそらくシンプルで、依存関係ゼロ・セットアップ不要・個人の会話ログ程度ならFTS5で十分実用的・データが外に出ない、という点だろう。「精度を最大化する」より「確実にローカルで動く」を優先した判断だ。

Markdownを採用しているのも同じ思想が貫かれている。JSONでもSQLでもなくMarkdownを選ぶことで、ユーザーが直接ファイルを開いて手で修正できる。「AIが勝手に記憶した内容を確認・修正できない」という他サービスの不透明さとは対照的だ。Gitとの相性も良いため、メモリファイルをバージョン管理することもできる。