ChatGPTでもClaudeでも、セッションを閉じた瞬間に全部忘れる。昨日あれだけ説明したプロジェクト構成、今日また一から話す羽目になる——この「AI健忘症」に苦しんだ経験、ありませんか？
Nous Researchが開発したHermes Agentは、この問題に真正面から取り組んだオープンソースのAIエージェントフレームワークです。単に「会話を保存する」のではなく、人間の記憶に似た多層構造でセッションをまたいで学習・成長し続ける。
この記事では、Hermesの記憶システムを「なぜそう設計されたのか」という動機から解きほぐし、各レイヤーの役割と仕組みを図解します。
Hermes Agentとは：30秒で把握する基本情報
| 項目 | 内容 |
|---|---|
| 開発元 | Nous Research（オープンソースAI研究組織） |
| カテゴリ | 自律型AIエージェントフレームワーク |
| コア思想 | セッションを超えて学習し続ける「自己改善型エージェント」 |
| ライセンス | オープンソース |
| データ保存先 | すべてローカル（~/.hermes/配下） |
| 対応プラットフォーム | CLI / Telegram / Discord / Slack 等（Gateway経由で統合） |
| 競合・類似 | AutoGPT, OpenClaw, Claude Projects |
ポイントは完全ローカルであること。会話データもメモリもスキルも、すべてユーザーの手元に残ります。クラウドにデータを吸い上げられる心配がない。ここは個人的にかなり好感が持てます。
記憶システムの全体像：3層構造を理解する
Hermesの記憶は3つのレイヤーで構成されています。人間の記憶に例えるとわかりやすいので、対比で整理してみます。
| レイヤー | Hermesでの名称 | 人間の記憶に例えると | 役割 |
|---|---|---|---|
| 第1層 | Prompt Memory（ホットメモリ） | ワーキングメモリ（作業記憶） | 今まさに使う情報。毎回のセッションに注入 |
| 第2層 | Session Search（検索メモリ） | 長期記憶（エピソード記憶） | 過去の会話履歴を検索・想起する |
| 第3層 | Skills（手続き記憶） | 手続き記憶（自転車の乗り方） | 「やり方」を手順書として保存・再利用する |
なぜ3層もあるのか？理由はシンプルで、トークン制限です。
LLMのコンテキストウィンドウは有限です。過去の会話を全部プロンプトに突っ込めば当然溢れる。かといって何も覚えていないと毎回ゼロスタートで使い物にならない。だから「常時携帯する最重要メモ」「必要なときだけ引っ張り出すアーカイブ」「一度学んだ手順の自動化」を分離したわけです。
第1層：Prompt Memory——毎セッション注入される「ワーキングメモリ」
仕組み
~/.hermes/memories/ ディレクトリに、2つのMarkdownファイルが置かれています。
~/.hermes/memories/
├── MEMORY.md ← エージェント自身のメモ
└── USER.md ← ユーザーに関する情報
MEMORY.md には、エージェントが学んだ環境情報やプロジェクト固有の知識が書き込まれます。
# MEMORY.md の例
- このプロジェクトはPython 3.10 + Poetry で管理されている
- テストは pytest を使用。カバレッジ80%以上を維持すること
- デプロイ先は AWS Lambda（ap-northeast-1）
- git commit メッセージは Conventional Commits 形式
USER.md には、ユーザーの好みやコミュニケーションスタイルが記録されます。
# USER.md の例
- 名前: Taro
- 役割: バックエンドエンジニア
- 好みの言語: 日本語で応答すること
- コードの説明は簡潔に。冗長な前置きは不要
- TypeScriptよりPythonを好む
なぜMarkdownなのか？
ここが地味に賢いと思った設計です。JSONでもSQLでもなく人間が直接読み書きできるMarkdownを選んでいる。つまり：
- ユーザーが直接ファイルを開いて「これは違う」と手で修正できる
- エージェントも自然言語でそのまま読み込める（パース不要）
- バージョン管理（git）との相性が抜群
容量制限がある
ここ重要です。MEMORY.mdは約2,200文字、USER.mdは約1,375文字という上限が設けられています。
なぜ制限するのか？これらのファイルは毎回のセッション開始時にシステムプロンプトにそのまま注入されるからです。無制限に書き込めたら、プロンプトがどんどん肥大化してトークンコストが爆増し、レスポンスも遅くなる。
上限に達すると、エージェントは自分で古い情報を統合・整理して、重要度の低いエントリを削除します。人間が机の引き出しを整理するのと同じです。
memoryツール
エージェントはビルトインのmemoryツールを使って、これらのファイルを自律的に操作します。
| 操作 | 説明 |
|---|---|
add |
新しいエントリを追記する |
replace |
既存のエントリを更新する |
remove |
不要になったエントリを削除する |
ユーザーが「今後はTypeScriptメインで開発するから」と伝えれば、エージェントはUSER.mdの「TypeScriptよりPythonを好む」をreplaceする——という具合。自分でメモを取って、自分で整理する。
いつ読まれ、いつ書き込まれるのか？
ここが気になるところだと思うので、タイミングを整理します。
読み込み（参照）のタイミング：
| タイミング | 何が起きるか |
|---|---|
| セッション開始時（毎回） |
MEMORY.mdとUSER.mdの中身がシステムプロンプトに「凍結スナップショット」として丸ごと注入される。つまりエージェントは起動した瞬間から「前回までの知識」を持った状態で応答を始められる |
| プロンプト構築時 |
prompt_builder.pyがシステムプロンプトを組み立てる際に、メモリファイルの内容をキャッシュ安定領域（Anthropicのcache breakpoint）に配置する。これにより同一内容が続く限りキャッシュヒットし、トークンコストを節約できる |
書き込み（更新）のタイミング：
| タイミング | 具体例 |
|---|---|
| ユーザーが明示的に伝えたとき | 「このプロジェクトはMonorepo構成だから覚えて」→ エージェントがmemory addでMEMORY.mdに追記 |
| 定期的な振り返りプロンプト（Periodic Nudge） | 一定のやり取りが続くと、Hermesは内部的に「今の作業から永続化すべき知識はあるか？」という自己評価プロンプトを受け取る。価値があると判断すればmemory add/replaceを実行 |
| 環境の変化を検知したとき | エージェントが作業中に「あれ、前のメモと状況が違うぞ」と気づいた場合（例：Pythonのバージョンが変わっていた等）、memory replaceで古い情報を上書き |
| 容量上限に達したとき | 新しいエントリを追加する余地がなくなると、エージェントが自発的に古い・重要度の低いエントリをmemory removeで整理してスペースを空ける |
つまり、「毎セッション必ず読む」が「書き込みはイベント駆動」という設計です。読み込みは軽量（テキストファイルを読むだけ）、書き込みは慎重に（本当に価値がある情報だけ残す）。
第2層：Session Search——過去を検索する「長期記憶」
仕組み
すべての会話履歴は、ローカルのSQLiteデータベース（~/.hermes/state.db）に保存されます。
第1層が「常に持ち歩くポケットメモ」だとすれば、第2層は「本棚にしまった過去の日記帳」です。普段はプロンプトに載せないが、必要なときにピンポイントで引っ張り出せる。
検索の仕組み：FTS5 + LLM要約
ただのキーワード検索ではありません。SQLiteの全文検索エンジンFTS5を使い、さらにLLMによる要約を組み合わせています。
ユーザー：「先月のDB設計の議論、どうなったっけ？」
↓
1. FTS5で "DB設計" に関連する過去セッションを検索
2. ヒットした会話ログをLLMが要約
3. 要約結果を現在のコンテキストに注入
4. エージェントが文脈を踏まえて回答
これによって、2週間前の議論の結論を正確に思い出せる。しかもプロンプトに載せるのは要約版だけなので、トークン消費は最小限に抑えられます。
state.dbはいつ書き込まれ、いつ検索されるのか？
第1層のメモリファイルと違い、state.dbの動作タイミングは明確に分かれています。
記録（書き込み）のタイミング：
| タイミング | 記録される内容 |
|---|---|
| 各ターンの終了時（リアルタイム） | ユーザーの入力とエージェントの応答が1ターンごとにセッションログとして追記される。会話は途中で途切れても失われない |
| セッション終了時 | セッション全体のメタデータ（開始・終了時刻、使用ツール等）が記録される |
| コンテキスト圧縮時 | 会話が長くなりコンテキストが閾値を超えると、LLMが古い会話を要約する。この要約もstate.dbに保存され、次回検索時に活用される |
検索（参照）のタイミング：
| 場面 | 何が起きるか |
|---|---|
| ユーザーが過去の話題に言及したとき | 「先週のAPI設計どうなった？」「前に試したデプロイ手順を教えて」などの発話をトリガーに、エージェントがFTS5で過去セッションを検索する |
| エージェントが文脈不足を感じたとき | タスク実行中に「以前このプロジェクトで似たことをやったはず」と判断した場合、自発的に検索をかけることもある |
| 振り返りプロンプト時 | 定期的な自己評価の際に、直近のセッション履歴を参照して「スキル化すべき手順はないか」を判断する材料にする |
ポイントは、**state.dbは「常にバックグラウンドで書き込み続ける」が「検索はオンデマンド」**という点です。第1層（MEMORY.md）は毎回コンテキストに載るコストがかかるが、第2層は検索しない限りトークンを消費しない。この非対称性が、コスト効率の鍵になっています。
なぜベクトルDB（Embedding検索）ではないのか？
ここは個人的に「なるほど」と膝を打ったポイントです。RAGといえば「ChromaDB」「Pinecone」みたいなベクトルDBが定番ですが、Hermesはあえて**FTS5（全文検索）**を選んでいる。
理由はおそらく：
- 依存関係ゼロ: SQLiteは標準ライブラリ。外部サービス不要
- セットアップ不要: Embeddingモデルの管理が不要
- 十分に高速: 個人の会話ログ程度ならFTS5で十分実用的
- ローカル完結: データが一切外に出ない
「とにかくシンプルに、ローカルで完結する」というHermesの設計哲学が貫かれています。
第3層：Skills——「やり方」を覚える手続き記憶
仕組み
~/.hermes/skills/ ディレクトリに、Markdownファイルとして保存されます。
~/.hermes/skills/
├── deploy-to-aws-lambda.md
├── setup-python-project.md
└── database-migration-guide.md
第1層（MEMORY.md）が「何を知っているか」、第2層（Session Search）が「何があったか」だとすれば、第3層は**「どうやるか」**を保存する層です。
Toolsとの違い
ここが混同しやすいので整理します。
| Tools（ツール） | Skills（スキル） | |
|---|---|---|
| 正体 | Pythonの関数 | Markdownの手順書 |
| 性質 | 決定論的（同じ入力 → 同じ出力） | 手続き的（手順を踏んで実行） |
| 例 | ファイル読み書き、Web検索、API呼び出し | 「AWSにLambdaをデプロイする手順」 |
| 作成者 | 開発者が実装 | エージェントが自律的に生成 |
Toolsは「ナイフ」や「フライパン」――道具そのもの。
Skillsは「カレーのレシピ」――道具の使い方を組み合わせた手順書。
自律的なスキル生成
ここがHermesの真骨頂です。複雑なタスクを成功裏に完了したとき、エージェントは自分で振り返って「これは今後も使えるな」と判断すると、自動的にSkillファイルを生成します。
# deploy-to-aws-lambda.md（エージェントが自動生成したSkill例）
## 前提条件
- AWS CLI がインストール済み
- ~/.aws/credentials に認証情報が設定済み
- Python 3.10以上
## 手順
1. `poetry export -f requirements.txt -o requirements.txt` で依存関係をエクスポート
2. `mkdir -p package && pip install -r requirements.txt -t package/` でパッケージング
3. `cd package && zip -r ../deployment.zip .` でZIPアーカイブ作成
4. `aws lambda update-function-code --function-name my-func --zip-file fileb://deployment.zip`
## 注意事項
- Lambda のランタイムは python3.10 を指定すること
- タイムアウトはデフォルト3秒→30秒に変更が必要（前回ここでハマった）
次回同じタスクが来たとき、エージェントはこのSkillを読み込んで最初から効率的に実行できる。しかも「前回ここでハマった」のような失敗知見まで蓄積されている。
スキルは進化する
一度作ったSkillは固定ではありません。同じタスクを再実行した際に手順の改善点が見つかれば、Skillファイルを更新します。まさに自己改善ループ。
自己改善ループ：3層がどう連携するか
Hermesの記憶システムは、3つのレイヤーが独立しているのではなく、ループとして連携しています。
セッション開始
│
▼
┌─────────────────────────────┐
│ MEMORY.md + USER.md を │
│ システムプロンプトに注入 │ ← 第1層
└─────────────┬───────────────┘
│
▼
┌─────────────────────────────┐
│ ユーザーと対話・タスク実行 │
│ 必要に応じて過去セッション │ ← 第2層
│ をFTS5で検索・参照 │
└─────────────┬───────────────┘
│
▼
┌─────────────────────────────┐
│ 定期的な振り返りプロンプト │
│ 「学んだことはあるか？」 │ ← 自己評価
└─────────────┬───────────────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
MEMORY.md USER.md Skills/
を更新 を更新 を生成・更新 ← 第1層・第3層へフィードバック
この「定期的な振り返りプロンプト」が地味に重要です。Hermesは一定間隔で内部的に「さっきの作業から永続化すべき知識はあるか？」と自問し、価値ある情報をメモリやスキルに書き出します。ユーザーが明示的に「これ覚えて」と言わなくても、エージェントが自発的に学習するわけです。
外部メモリプロバイダー：さらに拡張する選択肢
ビルトインの3層で足りない場合、Hermesは外部メモリプロバイダーをプラグインとして接続できます。
| プロバイダー | 主な機能 |
|---|---|
| Mem0 | セマンティック検索、自動ユーザーモデリング |
| Hindsight | ナレッジグラフ、エンティティ解決 |
| Honcho | 複雑なユーザーモデリング |
| Supermemory | 大規模な外部知識ベース統合 |
ビルトイン層が「ノートとペン」なら、外部プロバイダーは「図書館のデータベース」。大規模な知識管理やチーム横断での知識共有が必要なときに威力を発揮します。
他のエージェントとの比較
| 特性 | Hermes Agent | ChatGPT (Memory) | Claude Projects | AutoGPT |
|---|---|---|---|---|
| 記憶の永続化 | ✅ ローカルファイル＋SQLite | ✅ クラウド保存 | △ プロジェクト単位 | ✅ ファイル保存 |
| 記憶の自律更新 | ✅ 自動で追記・整理 | ✅ 自動抽出 | ❌ 手動設定 | △ 部分的 |
| スキル学習 | ✅ 自動生成・改善 | ❌ | ❌ | △ プラグイン依存 |
| データの所在 | 完全ローカル | OpenAIクラウド | Anthropicクラウド | ローカル |
| ユーザーによる編集 | ✅ Markdown直接編集 | ❌ | △ | △ |
| 検索アーキテクチャ | FTS5（軽量） | 不明（内部実装） | なし | ベクトルDB |
Hermesの差別化ポイントは、「透明性」と「自律性」と「ローカル完結」の三拍子が揃っている点だと感じます。メモリの中身をユーザーが直接確認・修正でき、エージェントが自分で学習し、かつデータは一切外に出ない。
まとめ：「忘れないAI」の設計思想
Hermesの記憶システムは、「全部覚える」のではなく**「何を覚え、何を忘れ、何を手順化するかを自分で判断する」**ところに本質があります。
- 第1層（Prompt Memory）: 常時携帯する最重要メモ。容量制限で肥大化を防止
- 第2層（Session Search）: 過去の全会話を検索可能なアーカイブとして保持
- 第3層（Skills）: 成功した手順を抽出・再利用。失敗知見も蓄積
この3層が自己改善ループで回り続けることで、使えば使うほど賢くなるエージェントが実現される。
正直、最初にアーキテクチャ図を見たときは「またメモリ系か…」と思ったのですが、実装の詳細を追っていくと、一つひとつの設計判断がすごく堅実で合理的でした。特にベクトルDBではなくFTS5を選んだ割り切りとか、Markdownベースのメモリファイルを人間が直接編集できるようにしている透明性の設計は、他のエージェントにも取り入れてほしいと感じています。
あなたは普段、AIエージェントの「記憶」をどう管理していますか？ カスタムプロンプトに手動で情報を書き込んでいる？ それとも毎回ゼロスタート？ コメント欄で教えてください。