Hermesエージェント向けMnemosyne：ローカルメモリクイックスタート

書き込みを制御されたローカル Hermes メモリ。

目次

Mnemosyne は Hermes Agent 向けのローカルファーストなメモリプロバイダーであり、ワーキングメモリ、構造化された事実、時間的データ、エピソード記憶をローカルの SQLite に保存します。ホスティングサービスは不要で、ネットワーク呼び出しも必須ではなく、非常に細粒度な書き込み制御が特徴です。

その最も有用な性質は、生の検索品質ではありません。書き込み経路に対して公開している制御量です。会話の自動保存はロールで制限できるか完全に無効化でき、ツール結果のログ記録は既定でオフになり、明示的な remember と forget 操作は常に利用可能になります。また、新しいリリースでは、コンテキスト圧縮境界付近での自己エコー抑制がオプトイン方式で追加されました。この組み合わせにより、全会話を自動的に恒久的な知識に変換せずに永続メモリを持ちたい場合の合理的な選択肢となります。

この書き込み経路の規律が重要である理由は、エージェントメモリには文書化された既知の失敗モードが存在するためです。モデル自身の推論が取得され、観察として後で取得され、そのさらに強力なバージョンを正当化するために使用されることがあります。AIエージェントにおける自己強化型メモリループ は、この失敗モードを詳しく扱っています。このガイドでは、実際にそれを制限する具体的な Mnemosyne の設定に焦点を当てます。Mnemosyne が他の Hermes メモリバックエンドに対してどのように位置づけられるかについては、エージェントメモリプロバイダー比較 を参照してください。

光るロックとフィルターを介して小さな友好的なエージェントモジュールに接続された半透明なローカルデータベースのボルト

1分でわかる Mnemosyne

典型的なメモリプロバイダーは、キャプチャ、抽出、保存、検索、そして将来のプロンプトへの注入のいずれかのバージョンを行います。Mnemosyne は、この基本的なループの周りに複数の明確なレイヤーを追加します：ワーキングメモリ、セマンティックおよびレキシカルな想起、構造化された事実、時間的情報、エンティティリンク、エピソード記憶、統合（コンソリデーション）、正規化された事実、そしてメモリ検証。保存は FTS5 と任意のベクトル検索を備えたローカル SQLite であり、クラウド専用のメモリ製品よりはるかに検査しやすく、単純な MEMORY.md ファイルよりも強力です。

簡潔に言うと、Hermes プロバイダーエコシステムの他のものと比較すると：Holographic はよりシンプルで、意図的に事実ストア志向です。Hindsight はハイブリッド検索、ナレッジグラフ、内省を重視します。Honcho は弁証法的推論を用いたピアおよびユーザーモデリングを重視します。Mem0 は LLM による自動事実抽出を重視します。一方、Mnemosyne はローカル SQLite 保存、ハイブリッド想起、統合、構造化された事実、および非常に細粒度な保持制御を組み合わせます。すべてのプロバイダーの詳細な分解、インフラ要件、セルフホスティングのメモについては、エージェントメモリプロバイダー比較 に記載されています。

現在のバージョン

2026年9月現在、PyPI 上の安定リリース版は mnemosyne-memory 3.15.1 です。4.0 ブランチはプレリリース版として利用可能です。本番環境の Hermes インストールの場合は、特定の 4.0 の修正や機能が必要で、データベース移行と動作変更のテストに備えている場合を除き、安定版から始めることをお勧めします。インストールされているバージョンは以下で確認できます：

hermes mnemosyne version

Hermes への Mnemosyne インストール

標準的なローカルインストールを使用した場合、まず Hermes 自身の仮想環境を有効にします：

source ~/.hermes/hermes-agent/venv/bin/activate

ローカル埋め込みサポートのために、コアパッケージの embeddings エクストラと Hermes プラグインラッパーをインストールします：

python -m pip install \
  "mnemosyne-memory[embeddings]" \
  mnemosyne-hermes

次にプラグインを登録します：

mnemosyne-hermes install

既存のプラグイン登録を置き換える場合は：

mnemosyne-hermes install --force

プロバイダーを有効にし、ゲートウェイを再起動します：

hermes config set memory.provider mnemosyne
hermes gateway restart

以下で確認します：

hermes memory status

予想される出力は以下のようになります：

Provider: mnemosyne

Plugin: installed
Status: available

Docker と永続サーバーでのインストール

Hermes が永続的な Docker またはイメージベースのデプロイ内で実行されている場合、コンテナの再構築可能な Python 環境ではなく、マウントされた Hermes ホーム内のサイドバーチャル環境にインストールし、プラグインがイメージ再構築後も残るようにします：

export HERMES_HOME=/opt/data
VENV="$HERMES_HOME/.mnemosyne/venv"
python3 -m venv "$VENV"
"$VENV/bin/python" -m pip install --upgrade "mnemosyne-memory[embeddings]" mnemosyne-hermes
"$VENV/bin/mnemosyne-hermes" install --mode wrapper --python "$VENV/bin/python"
hermes config set memory.provider mnemosyne

サイドバーチャル環境は、実行中の Hermes ゲートウェイと同じ Python メジャー/マイナーバージョンを使用する必要があります。PATH 内の無関係な python3 を指さないでください。その後、実際のコンテナまたはサービスを再起動し、hermes memory status と並行して "$VENV/bin/mnemosyne-hermes" status で検証します。

Hermes のメモリツールセット全体を無効にしないでください

2つの概念を区別してください：Hermes 自体の組み込みメモリ（MEMORY.md / USER.md、詳しくは Hermes Agent メモリスステム を参照）と、外部プロバイダー（Mnemosyne）。外部プロバイダーを設定する際に安易に hermes tools disable memory を実行しないでください。Hermes のバージョンによっては、そのコマンドが外部メモリプロバイダーのツールも隠す可能性があります。代わりに、以下に示すようにプロバイダー設定を使用してください。

基本的なステータスと検査

hermes memory status
hermes mnemosyne stats
hermes mnemosyne stats --global
hermes mnemosyne inspect "query"

可搬性のバックアップをエクスポートします：

hermes mnemosyne export \
  --output ~/mnemosyne-backup.json

バックエンドデータベースは通常、~/.hermes/mnemosyne/data/mnemosyne.db にあります。SQLite であるため、標準的なツールによる検査とバックアップは簡単です。このガイド全体で言及されているゲートウェイ、セッション、診断コマンドの残りの部分については、--help の出力を掘り下げるよりも、Hermes Agent CLI チートシート の方が速いリファレンスになります。

既定の保持ポリシーには注意が必要です

理解すべき最初の制御は sync_roles です。現在の Mnemosyne の既定値は、初期リリースよりも既に保守的になっています — Hermes の自動同期は、ユーザーターンとアシスタントターン両方ではなく、ユーザーターンにのみ既定で設定されています — しかし、厳格な明示的なみ保持の場合には、ターン自動保存を完全に無効にするための余分なステップは価値があります。~/.hermes/config.yaml を編集します：

memory:
  provider: mnemosyne

  mnemosyne:
    sync_roles: []

空のリストは、通常の会話ターンが sync_turn() によって自動的に保存されないことを意味します。明示的な mnemosyne_remember 操作は依然として機能します — 通常の会話が自動的にメモリに流入することを止め、明示的な「覚えておくこと」だけが Mnemosyne に到達します。

自動ツール結果ログを無効にする

Mnemosyne はツール実行をメモリとして記録することもできます。保守的な設定の場合、~/.hermes/.env でそれを無効にしておきます：

MNEMOSYNE_LOG_TOOLS=0

これは既に既定値ですが、明示的に設定することで、既定値に関する前提に頼るのではなく、ポリシーを文書化できます。その後、Hermes を再起動します：

hermes gateway restart

sync_roles: [] と MNEMOSYNE_LOG_TOOLS=0 を組み合わせることで、両方の主要な自動書き込み経路 — 会話の自動保存とツール結果の自動保存 — がオフになります。

自動想起を有効に保つ

自動書き込みを無効にするには、想起を無効にする必要はありません。有用なポリシーは、自動保持をオフにしつつ、自動想起、明示的な remember、明示的な forget をすべてオンにしておくことです。メモリは読みやすく、書きにくくあるべきで、これは「すべてキャプチャして後で整理する」ような既定値のほぼ逆です。

永続的なエージェント指示を追加する

プロバイダー設定はプロバイダーレベルの自動キャプチャをブロックしますが、モデル自身が明示的な書き込みツールを呼び出すことを決定する可能性があります。SOUL.md に明示的なポリシーを追加します：

## 長期メモリポリシー

Mnemosyne は長期メモリプロバイダーです。

ユーザーが明示的に情報を覚えておく、保存する、保持する、または保存することを求めない限り、Mnemosyne に何も書き込まないでください。

将来のセッションに有用な情報が存在するが、ユーザーが明示的にそれを覚えるよう要求しなかった場合、mnemosyne_remember または他の Mnemosyne 書き込みツールを呼び出す前に許可を求めてください。

独自の推論、前提、要約、解釈、結論、または推測された選好から永続メモリを作成しないでください。

ユーザーが明示的にその結果を覚えるよう求めない限り、ツール出力から永続メモリを作成しないでください。

承認されたメモリを保存する際、ユーザーが実際に述べた内容を保持してください。推測されたコンテキストや結論で飾り立てないでください。

Mnemosyne メモリの読み取りと想起は、許可を求めずに許可されます。

ゲートウェイを再起動し、その後新しいセッションを開始します：

hermes gateway restart

/new

これはモデルによる強制ポリシーであり、ハードな権限境界ではありません — 上記のプロバイダーレベル設定に置き換わるものではなく、それを補完するものです。

memory.write_approval はどうですか？

Hermes は組み込みの MEMORY.md / USER.md 書き込みに対して memory.write_approval: true をサポートしており、Mnemosyne は新しいリリースで明示的な書き込みに対する独自のプロバイダー固有のステージングを実装しています。これは有望ですが、真剣に受け止めるべきアーキテクチャ上の注意事項があります：Hermes はまだ、すべての外部メモリプロバイダー間で統一されたプロバイダー非依存の承認契約を公開しておらず、Mnemosyne の pending/apply 実装は共有標準の一部ではなく、プロバイダー固有です。設定キーが存在するからといって、承認が正しく動作すると想定しないでください — 正確な Hermes と Mnemosyne のバージョンに対してテストしてください。プロバイダー非依存の承認が成熟するまで、sync_roles: []、MNEMOSYNE_LOG_TOOLS=0、および上記の明示的な書き込み SOUL.md ポリシーを組み合わせることで、信頼できるベースラインが得られ、承認経路を頼りにする場合に限り、別途テストされます。

自己エコー抑制を有効にする

現在の Mnemosyne は、任意の自己エコー抑制も提供しています：

MNEMOSYNE_SELF_ECHO_ENABLED=1

これを ~/.hermes/.env に置き、その後再起動します：

hermes gateway restart

自己エコー抑制は、特定のコンテキスト圧縮境界を対象としています — その目的は、プロバイダーがちょうど作成したメモリが独立したコンテキストであるかのようにエージェントに即座にフィードバックされるケースを減らすことです。これは意図的にベストエフォートであり、書き込みフィルタリングの代わりにはなりません：書き込み制御は疑わしいメモリが最初から入るのを止め、自己エコー制御は最近のプロバイダー出力が直ちに跳ね返ってくるのを止めます。どちらも重要であり、どちらがどちらの代わりにはなりません。

保守的な Mnemosyne 設定

要素を組み合わせると、セルフホストされた個人用エンジニアリングエージェント向けの開始設定は以下のようになります。~/.hermes/config.yaml において：

memory:
  provider: mnemosyne

  mnemosyne:
    sync_roles: []

~/.hermes/.env において：

MNEMOSYNE_LOG_TOOLS=0
MNEMOSYNE_SELF_ECHO_ENABLED=1

そして SOUL.md において、最低限：

ユーザーが明示的に要求した場合にのみ、長期メモリを保存してください。
明示的な許可なしに、モデルによって生成された結論やツール出力を永続メモリに昇格しないでください。
flowchart LR U[User conversation] -.->|blocked| M[(Mnemosyne)] T[Tool results] -.->|blocked| M R["Explicit: remember this"] -->|mnemosyne_remember| M Q[Future question] -->|recall| M

通常の会話が保持されないことをテストする

まずベースラインの计数を確認します：

hermes mnemosyne stats

新しい Hermes セッションを開始し、エージェントに覚えるよう要求せずに、単純な事実文を言います。例えば：

PurpleOtter uses port 48123.

その後、それを探します：

hermes mnemosyne inspect "PurpleOtter"

予想される結果：Results for 'PurpleOtter': 0。また、hermes mnemosyne stats を再確認します — ワーキングメモリの数は、その通常のターンによって増加していないはずです。

明示的なメモリをテストする

次に、同じ種類の文を言いますが、明示的に保持を要求します：

Remember that BlueKoala uses port 17321.

検査し、その後新しいセッションを開始してそれを求めます：

hermes mnemosyne inspect "BlueKoala"

/new

What port does BlueKoala use?

Hermes は値を正しく取得する必要があります — このペアのテストは、書き込み経路ポリシー（要求なしでは何も入らない）を検索メカニズム（入ったものは確実に戻る）から分離します。

ツールログをテストする

MNEMOSYNE_LOG_TOOLS=0 が設定されている状態で、Hermes に個性的でユニークなコマンドの実行を求めます：

Use the terminal tool to run:
echo tool-canary-834729

その後、カナリア文字列を探します：

hermes mnemosyne inspect "tool-canary-834729"

予想される結果：0 results。これは、環境変数がどこでも尊重されると単純に信頼するよりもはるかに強力なテストです。

データベースの検査

保存が SQLite であるため、内部スキーマは直接検査可能です：

sqlite3 ~/.hermes/mnemosyne/data/mnemosyne.db '.tables'

バージョンによって、working_memory、episodic_memory、facts、consolidated_facts、gists、graph_edges、memoria_facts、memory_embeddings などのテーブルが表示される場合があります。これは削除をテストする場合に重要です — メモリスステムは、ワーキングメモリの行を正常に削除しながら、派生された事実、gist、グラフオブジェクトを残す可能性があります。Mnemosyne は、孤立した派生レコードに関わる実際のバグがあり、新しいリリースでは削除と診断の両方がそれに応じて強化されています。現在のスキーマを完全に理解していない限り、SQLite 行を手動で削除するのではなく、プロバイダーがサポートする削除および doctor/repair 経路を優先してください。

セッションスコープのワーキングメモリの削除

微妙な点の一つ：Mnemosyne のワーキングメモリはセッションスコープであることがあり、scope = session を持つ行は、default セッションで動作するスタンドアロンの削除には表示されない可能性があります。デバッグ時に、スコープを直接検査します：

SELECT id, session_id, scope, content
FROM working_memory;

プロバイダーまたは API は、セッションローカルレコードを変更するために正しいセッションスコープを必要とします — 生の SQL 編集よりもサポートされている管理ツールを優先するもう一つの理由です。

統合（コンソリデーション）：sleep() に急いで実行しないでください

Mnemosyne はワーキングメモリをより長期間の表現に統合でき、これは有用ですが、変更を伴う操作です。攻撃的な自動統合を有効にする前に、実際にキャプチャされているものを検査し、通常のターンが意図せずメモリに入っていないことを確認し、削除をエンドツーエンドで確認し、データベースをバックアップします。その後、以下で実験します：

hermes mnemosyne sleep

最近の Mnemosyne の変更により、競合処理がより保守的になりました — セマンティック類似性だけでは、1つのメモリが別のメモリを無効にすべきだとはもはや証明されず、これは永続的なエージェントメモリスステムが進むべき正確な方向です。AIエージェントにおける自己強化型メモリループ で扱われています。

アップグレード前のバックアップ

重要な変更の前に、可搬なエクスポートを作成します：

hermes mnemosyne export \
  --output ~/mnemosyne-backup.json

重要なインストールでは、メジャーアップグレードの前にローカルデータベースまたはデータディレクトリもコピーしてください。Mnemosyne 4.x は現在プレリリースラインであるため、メジャーバージョンのアップグレードは、定期的なパッチ更新よりも多くの注意を要します。

最終推奨セットアップ

すべてのことを覚えることよりもメモリ精度が重要な、長期間実行される Hermes インストールの場合、永続的な設定は以下の通りです：Mnemosyne ローカル保存オン、自動想起オン、会話自動保存オフ、アシスタントメッセージ自動保存オフ、ツール結果ログオフ、明示的な remember および forget オン、自己エコー抑制オン、セッション検索オン、承認経路がテストされた後には機密書き込みの人間によるレビューが望ましい。これにより、Mnemosyne は主に厳選された長期メモリストアとして機能し、トランスクリプトアーカイブとしては機能しません — 目標は、Hermes が過去に言ったすべてのことを覚えるようにすることではなく、次のセッションが開始した際に依然として真実であるものを覚えるようにすることです。異なるプロバイダーや保持ポリシーを持つ複数のプロファイルを実行する場合、Hermes Agent 本番セットアップ は、それらを整合的に保つためのプロファイルレベルの配線を扱っています。ナレッジグラフと reflect 操作を備えた別々の Docker サービスとしてメモリを実行したい場合、Hermes Agent 用の Hindsight が外部の Docker ベースのプロバイダーガイドです。

購読する

システム、インフラ、AIエンジニアリングの新記事をお届けします。