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

Mnemosyne は Hermes Agent 向けのローカルファーストなメモリプロバイダーです。ワーキングメモリ、構造化ファクト、時間的データ、エピソード履歴をローカルの SQLite に保存します。ホスト型サービスは不要で、必須のネットワーク呼び出しもなく、異例のほど粒度の細かい書き込み制御を提供します。

Mnemosyne の最も有用な性質は、生データの想起品質そのものではありません。書き込みパスに対して公開する制御量です。会話の自動保存はロール（役割）によって制限することも完全に無効化することもでき、ツール結果のログ記録はデフォルトでオフです。明示的な remember（記憶）と forget（忘却）操作は常に利用可能であり、新しめのリリースではコンテキスト圧縮境界周りの自己エコー抑制がオプトイン方式で追加されました。この組み合わせにより、永続的なメモリは欲しいが、すべての会話を自動的に永続的知识にすることを避けたい場合の合理的な選択肢となります。

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

Mnemosyne を1分で理解する

一般的なメモリプロバイダーは、キャプチャ、抽出、保存、検索、そして将来のプロンプトへの注入という基本的なループの何らかのバージョンを行います。Mnemosyne は、その基本的なループの周りに複数の異なるレイヤーを追加します：ワーキングメモリ、意味論的および辞書的な想起、構造化ファクト、時間的情報、エンティティリンク、エピソードメモリ、統合（consolidation）、正規化ファクト、そしてメモリ検証。ストレージは FTS5 と任意のベクトル検索を備えたローカル SQLite であり、クラウド専用のメモリ製品よりもはるかに検査しやすく、単純な MEMORY.md ファイルよりも能力が高くなります。

ごく簡潔に言えば、Hermes プロバイダーエコシステム全体との比較では：Holographic はシンプルで、意図的にファクトストア指向です。Hindsight はハイブリッド検索、ナレッジグラフ、そして反省（reflection）を重視します。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

ローカル埋め込み（エMBEDDING）のサポートには、embeddings extra を付与したコアパッケージと 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

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

Hermes のメモリツールセット全体を無効にしないこと

2つの概念を区別してください：Hermes 自身の組み込みメモリ（MEMORY.md / USER.md。Hermes エージェントメモリシステム で完全に取り扱われています）と、外部プロバイダー（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 エージェント CLI チートシート のほうがより迅速な参考になります。

デフォルトの保持ポリシーに注意する

最初に理解すべき制御は sync_roles です。現在の Mnemosyne のデフォルトは、初期リリースよりも既に保守的です — 自動 Hermes 同期は、ユーザーとアシスタントの両方のターンではなく、ユーザーのターンにデフォルトで設定されています。しかし、厳密な明示的のみ保持（explicit-only retention）の場合、ターン自動保存を完全に無効にするために追加の手順を取る価値があります。~/.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 に明示的なポリシーを追加します：

## Long-term memory policy

Mnemosyne is the long-term memory provider.

Do not write anything to Mnemosyne unless the user explicitly asks you to
remember, save, retain, or store that information.

If information appears useful for future sessions but the user did not
explicitly request that it be remembered, ask for permission before calling
mnemosyne_remember or another Mnemosyne write tool.

Do not create durable memories from your own reasoning, assumptions,
summaries, interpretations, conclusions, or inferred preferences.

Do not create durable memories from tool output unless the user explicitly
asks for that result to be remembered.

When storing an approved memory, preserve what the user actually stated.
Do not embellish it with inferred context or conclusions.

Reading and recalling Mnemosyne memories is allowed without asking for
permission.

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

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

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

保守的な Mnemosyne 設定

これらの要素を組み合わせると、セルフホスティングされたパーソナルエンジニアリングエージェント向けの初期設定は以下のようになります。~/.hermes/config.yaml に：

memory:
  provider: mnemosyne

  mnemosyne:
    sync_roles: []

~/.hermes/.env に：

MNEMOSYNE_LOG_TOOLS=0
MNEMOSYNE_SELF_ECHO_ENABLED=1

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

Only store long-term memory when the user explicitly requests it.
Do not promote model-generated conclusions or tool output into durable memory
without explicit permission.

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

まずベースラインのカウントを確認します：

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 エディットよりもサポートされた管理ツールを優先するもう一つの理由です。

統合（consolidation）：sleep() に急がないこと

Mnemosyne は、ワーキングメモリをより長く残る表現に統合できますが、これは変更を伴う操作です。積極的な自動統合を有効にする前に、実際に何かがキャプチャされているかを検査し、通常のターンが意図せずメモリに入ってはいないことを確認し、削除が端到端（end to end）で動作することを確認し、データベースをバックアップしてください。その後、次のコマンドで実験します：

hermes mnemosyne sleep

最近の Mnemosyne の変更により、コンフリクト処理がより保守的になりました — 意味論的類似性だけでは、もう一つのメモリを無効化すべきという証拠にはなりません。これは、永続的なエージェントメモリシステムが進むべき正しい方向であり、AI エージェントにおける自己強化的なメモリループ で扱われています。

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

重要な変更を行う前に、ポータブルなエクスポートを作成します：

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

重要なインストールでは、メジャーアップグレード前にローカルデータベースやデータディレクトリのコピーも行ってください。Mnemosyne 4.x は現在プレリリースラインであるため、メジャーバージョンアップグレードは、ルーティンなパッチ更新よりも慎重に対応すべきです。

最終推奨セットアップ

すべてのことを記憶することよりも、メモリの正確性がより重要な長期間実行される Hermes インストールの場合、永続的な設定は以下のようになります：Mnemosyne ローカルストレージオン、自動想起オン、会話自動保存オフ、アシスタントメッセージ自動保存オフ、ツール結果ログオフ、明示的な remember と forget オン、自己エコー抑制オン、セッション検索オン、承認パスがテストされたら機密データの書き込みに対する人間のレビューが望ましい。これにより、Mnemosyne は主にキュレーションされた長期メモリストアとして機能し、トランスクリプトアーカイブとはなりません — 目標は、Hermes がかつて言ったことをすべて記憶させることではなく、次のセッションが始まったときに依然として真であるものを記憶させることです。異なるプロバイダーや保持ポリシーを持つ複数のプロファイルを管理する場合、Hermes エージェント本番環境セットアップ が、それらを整合的に保つためのプロファイルレベルの配線について扱っています。