あなたが触ってきたほとんどの AI チャット UI は、本当の意味での記憶というものを持っていない。持っているのはコンテキストウィンドウであって、これはまったく別の話だ。同じ会話の中で少し前に話したことはモデルにまだ見えているが、昨日の会話で話したことはもう消えている。翌日には再びゼロから始まり、アシスタントは初対面のような顔でまた自己紹介してくる。
Hermes Agent は違う。会話コンテキストとは別の場所に、本物のメモリレイヤーを持っている。時間をかけてあなたに関することを学び、それをセッションやプラットフォームをまたいで運び、話しかけるたびに同じ人物として振る舞えるようにしてくれる。この記事では、それが実際にどう動いているのか、どの設計判断が効いているのか、そして v0.7.0 の差し替え可能なメモリインターフェースが何を変えたのかを書く。
短期記憶と長期記憶
まず肝心な区別から。
Hermes の短期記憶は、セッションのコンテキストウィンドウだ。今エージェントが握っている会話履歴の断片で、先回りの圧縮戦略と組み合わせて管理されている。コンテキストがモデルの上限に近づくと、Hermes は古いターンを構造化サマリに畳み込み、最新のやり取りは原文のまま残す要約パスを走らせる。この圧縮ロジックはリリースを重ねるごとに磨かれてきた——v0.4.0 では構造化サマリと反復更新が入り、その後もトークンバジェットによる末尾保護、差し替え可能な要約エンドポイント、フォールバックモデルのサポートが積み重なっている。長い会話でも、エージェントが重要なコンテキストを落とさずに、静かに速くて安いままでいられるのはここのおかげだ。
長期記憶の方が面白い。事実、好み、訂正、ユーザーモデルがしまわれたストアで、会話の外側に住んでいる。今日 Telegram で「私の名前は Alice だ」と伝えると、その事実は長期記憶に書き込まれる。翌日 Slack で別のことを訊ねると、その事実が引き出されて、あなたのメッセージがエージェントに届く前にコンテキストへ差し込まれる。モデルが見られるのは結局ウィンドウに収まる分だけだが、そのウィンドウは、あなたについて知っておくべきことで下地が整っている。
短期記憶はバッファだ。長期記憶は人だ。
Honcho——それは何者で、なぜ重要なのか
Hermes の既定の長期記憶プロバイダは Honcho という、AI ネイティブ記憶のために作られたライブラリだ。Honcho の仕事は、エージェントの裏で動きながら三つのことをやることにある。
- 1.観測する。 ユーザーのメッセージもエージェントの応答も、すべてイベントストリームとして Honcho に流れ込む。Honcho はそのストリームから内部のユーザーモデルを組み立てる——素の会話履歴ではなく、会話から推論した構造化された事実と好みだ。
- 2.ユーザーについて推論する。 Honcho は内部に小さな「対話（ダイアレクティック）」レイヤーを持っていて、「あなたは誰で、何を望んでいて、何を訂正したか」について一貫した像を組み立てようとする。これは単なるキーワード抽出ではない。稼働中のユーザーの心的モデルだ。
- 3.差し込む。 新しいターンごとに、Honcho はあなたについて重要だと思うことを短くまとめたコンテキストスニペットを出力する。Hermes はそれをシステムプロンプトの先頭に付けて渡す。Honcho が学ぶにつれて、このスニペットは変わっていく。
ここで見落とされがちな細かい話を二つだけ挙げておきたい。
一つ目、Honcho への書き込みは非同期だ。エージェントは記憶の書き込みでブロックされない。先に返事を返して、記憶レイヤーはそのやり取りをバックグラウンドで処理する。つまり長い会話が記憶更新のためにレイテンシ税を払うこともないし、メモリバックエンドが落ちたからといってボットが止まるわけでもない——落ちている間の更新は失うが、アシスタントはしゃべり続ける。
二つ目、Honcho のリコール結果はキャッシュされたシステムプレフィックスの外に置かれている。Anthropic のプロンプトキャッシュ機能（Claude Sonnet 4.6 のようなモデルでは重要な仕組みだ）は、システムプロンプトがターン間で安定していることでキャッシュがヒットする前提になっている。Honcho が差し込むスニペットはターンごとに変わるので、Hermes はそれをキャッシュ対象のシステム部分の後ろにわざと継ぎ足す。静的な部分には引き続きキャッシュが効き、動的な記憶レイヤーも変化する部分でちゃんと仕事をする。リリースノートに載ることはないが、月額が 50 ドルで収まるか 500 ドルに化けるかを決める種類の機械的トレードオフだ。
ゲートウェイモードでのマルチユーザー分離
Hermes のゲートウェイは既定で、複数のユーザーを同じエージェントプロセスにまとめて通す。長期記憶はユーザーごとに分離されている必要がある——でなければ Alice のアレルギー情報が Bob の料理提案に紛れ込んでくる。v0.3.0 リリースで、ゲートウェイ内の Honcho にちゃんとしたマルチユーザー分離が入った。実質的には以下のような意味だ。
- •ゲートウェイのユーザー ID はそれぞれ独立した Honcho peer に対応付けられ、記憶の書き込みは peer ごとにスコープされる。
- •グループチャットのセッションは既定でユーザーごとのセッションを継承するので、同じチャンネルを共有していても、参加者ごとに別々の記憶ストリームが書かれていく。
- •プロファイル単位のメモリ分離（v0.5.0 / v0.6.0）は、同じマシンで複数の Hermes プロファイルを動かしている場合、それぞれのプロファイルの記憶が別の宇宙になるということだ。プロファイルを切り替えても、一方の人格がもう一方へ漏れ出すことはない。
どれもユーザーの目には見えない。見えないからこそ、このボットはあなたを誰かと取り違えて覚えたりしない。
差し替え可能なメモリインターフェース（v0.7.0）
Hermes の最初の 5 リリースでは、Honcho はハードワイヤードだった。v0.7.0 で、メモリレイヤーがちゃんとしたプロバイダインターフェースにリファクタされた——任意のメモリバックエンドが実装できる、小さな Python の抽象基底クラスだ。アーキテクチャ上の変更としては地味だが、実用上のインパクトは桁違いに大きい。
このインターフェースのおかげで、Hermes のコアに手を入れずにメモリバックエンドを差し替えられるようになった。
- •Honcho はリファレンスプロバイダだ（そして今も既定のまま）。機能は一通り揃っていて、本物のユーザーモデルを走らせ、マルチユーザー分離もきちんと処理している。
- •Supermemory は v0.8.0 で第二のファーストクラスプロバイダとして追加された。マルチコンテナサポート、差し替え可能な検索モード、アイデンティティのテンプレート化を備えている。
- •mem0、OpenViking、RetainDB、Hindsight、ByteRover はすべて Hermes のプラグイン機構にコミュニティ製のメモリプラグインとして乗っている。統合の深さはさまざまだ。
- •自分で書くこともできる。抽象基底クラスは小さい——
write()、recall()、いくつかのライフサイクルフックを実装して、プラグインとして登録すればいい。
組み込みのメモリプロバイダ——他に何もセットアップしていない場合に使われる、依存ゼロの既定値——は SQLite ベースの事実ストアで、基本だけを押さえている。事実を書き、関連度でリコールし、ユーザーごとにスコープする。Honcho ほど賢くはない。ただ外部サービスを一切必要としないので、月 5 ドルの VPS で動かしている個人アシスタントには、たいていこれだけで十分だ。
これが静かに解き放ったもの
差し替え可能メモリは、リリースノートの上では「メモリをプロバイダインターフェースにリファクタしました」という、用務員仕事みたいに地味な改修に見える。見出しにはならない。でも実際にやっていることは、「AI アシスタントはあなたについて何を覚えておくべきか」という問いを、「Hermes がどう動くか」という問いから切り離すことだ。
これでもう、Honcho を自分のユースケースに合ったメモリバックエンドに置き換えられる——個人の知識ベースに対してセマンティック検索を走らせたい人にはベクトルストア、明示的なエンティティ関係が欲しい人にはグラフデータベース、記憶データが自分のマシンから一切出てほしくない人にはローカル SQLite のみの構成、チームなら社内メモリサービス、といった具合に。エージェント本体は変わらない。memory インターフェースの裏にいる何かだけが変わる。
数年先まで生き残りたいプロジェクトにとって、これは正しい抽象の高さだ。記憶というものはとても個人的で、あなたにとって正しいメモリバックエンドが、他の誰かにとっても正しいとは限らない。Hermes の仕事は、差し込まれたどんなメモリレイヤーに対してもちゃんとした同居人であること、そしてそのレイヤーの仕事の邪魔をしないことだ。