ホームHermesとは記憶スキルマルチプラットフォーム自動化コマンド一覧ブログDelegationMCP人格設定導入と移行活用シナリオ
記憶するAI — Memory・Session Search・外部メモリの全体像 のイメージ
PERSISTENT MEMORY

記憶するAI — Memory・Session Search・外部メモリの全体像

MEMORY.md、USER.md、session_search、ByteRover などの外部メモリ連携を通じて、Hermes Agent が継続性を持つ仕組みを解説します。

[PR] 人気おすすめビジネス書特集

なぜAIに記憶が必要なのか

AIを実務に組み込むときの大きな障害は、前回の文脈が消えることです。プロジェクト構成、ユーザーの好み、運用ルール、以前の結論を毎回説明するのは現実的ではありません。

Hermes Agent はこの問題に対して、必要な情報だけを厳選して持つ「境界のある永続メモリ」というアプローチを取っています。

MEMORY.md と USER.md の二層構造

Hermes Agent の標準メモリは MEMORY.md と USER.md に分かれています。前者は環境や運用ルールなどエージェント側の実務メモ、後者はユーザーの嗜好や話し方などのプロフィールです。

この分離により、何を覚えているのかが読みやすく、更新もしやすくなります。しかも文字数制限があるため、要点だけが残りやすい設計です。

session_search が会話履歴を補う

固定メモリだけですべての過去を持つのは難しいため、Hermes Agent は session_search によって過去会話を検索できます。

固定メモリが常備知識だとすれば、session_search は必要時に取りに行く長期履歴です。この二段構えで継続性を支えています。

外部メモリプロバイダでさらに深い継続性へ

Hermes Agent は ByteRover、Honcho、Mem0 などの外部メモリプロバイダにも対応しています。知識グラフや意味検索、ユーザーモデリングまで含めて拡張できるため、プロジェクト横断の知見管理にも向きます。

軽量メモから本格的な記憶基盤まで段階的に育てられるのが Hermes の強みです。

メモリ方式の比較: 固定メモリ・session_search・外部メモリ

Hermes Agent の記憶機構は一枚岩ではなく、性質の異なる複数のメモリが連携する多層構造です。それぞれに得意・不得意があるため、特徴を整理しておくと設計判断がしやすくなります。

三種類のメモリの特徴比較

  • 固定メモリ（MEMORY.md / USER.md）: 毎回のプロンプトに必ず乗る常備知識。容量は小さいが即応性が高い。「運用ルール」「固有名詞」「意思決定結果」を置くのに向く。
  • session_search: 過去会話ログを検索して必要なときだけ引き出す履歴参照。容量は大きいが検索コストが発生する。「以前に話した内容を改めて参照したい」時に強い。
  • 外部メモリプロバイダ（ByteRover / Honcho / Mem0）: 意味検索・知識グラフ・ユーザモデリングなど高度な記憶機構。容量制限が緩く、プロジェクト横断の知見蓄積に向くが、設計と運用の手間が増える。

実務では、まず MEMORY.md と USER.md だけで運用を立ち上げ、会話量が増えてきたら session_search を活用、知識量がさらに増えたら外部メモリを導入する、という段階的な拡張が扱いやすいです。

MEMORY.md の書き方の実例

MEMORY.md は「Hermes が常に参照する事実集」なので、情報の粒度と鮮度管理が重要です。書式に厳密なルールはありませんが、実運用で扱いやすい構成を例示します。

# MEMORY.md の例
## プロジェクト基礎情報
- サービス名: BusinessHub
- デプロイ: AWS CloudFront + S3
- 本番ドメイン: *.businesshub.trueone.co.jp
- デフォルトブランチ: main

## 運用ルール
- ブログ記事は必ず新規ブランチで作成しPRを出す
- 機密情報はこのファイルに書かない
- 画像生成は Fireworks API を使用

## 繰り返し頻出する固有情報
- 顧客A社の問い合わせ窓口: support@example.com
- 週次報告の提出先: #ops-weekly (毎週金曜17時)

## 意思決定のメモ
- 2026/03: フロントフレームワークは導入しない方針
- 2026/04: OGP画像は1200×630で統一する

箇条書きで要点を並べる形式が Hermes との相性がよく、読み込ませたときの応答精度も安定しやすいです。逆に、長文のナラティブを延々と書くと情報が埋もれ、不要な行動を取らせる原因になります。

USER.md の書き方の実例

USER.md はユーザー自身のプロフィールや話し方の好みを置く場所です。ここが整っていると、Hermes の返答スタイルが一気に自然になります。

# USER.md の例
## 基本情報
- 氏名: 野口 慎一
- 所属: 株式会社TrueOne
- 役割: SEOサイトの企画・運用

## 返答スタイルの好み
- 結論を先に、背景を後に
- 専門用語は許容するが、略語は初出で展開する
- 箇条書きを多用してよい

## 作業環境
- エディタ: Claude Code（CLI 中心）
- OS: Linux (WSL2)
- 言語: 日本語優先、英語の技術情報は原典を併記

この USER.md は「Hermes が毎回読む自己紹介カード」のようなものだと考えると扱いやすいです。逆にユーザー個別の機微情報（パスワードや秘密鍵など）は絶対に書かないのが鉄則です。

session_search の活用コマンド例

session_search は CLI やスキル内から呼び出すことで、過去会話からの情報復元ができます。以下は典型的な呼び出し例です。

# 過去会話から特定トピックを検索
$ hermes session_search "OGP画像の推奨サイズ"
> 2026/04/05 の会話で決定: 1200x630 を標準、1792x1024 を理想

# 特定期間のセッション要約
$ hermes session_search --from 2026-04-01 --to 2026-04-14 --summary

# スキル内からの呼び出し（疑似コード）
skill: recall-project-decisions
steps:
  - call: session_search
    query: "{{project_name}} の仕様決定"
  - summarize: "decision_list"
  - write_to_memory: true

session_search を使いこなすと、「Hermes はあの時の話も覚えている」という感覚が強まります。常備メモリに乗せるほどではないが、必要時には取り出したい知識を大量に保持できるのが強みです。

運用事例: 記憶機構が活きた現場

事例1: マネージャーが毎週の1on1で文脈を失わない

あるマネージャーは10名以上のメンバーと1on1をしており、前回の話題を覚えきれないのが悩みでした。Hermes Agent に「メンバーごとの1on1履歴ノート」を外部メモリに貯めさせ、1on1開始前に直近3回分の要点を要約して提示させる運用にしたところ、毎回の会話の質が明確に上がりました。

事例2: 開発チームが「同じ失敗」を繰り返さなくなる

開発現場では、過去にハマった問題と同じ問題を繰り返すことがしばしば起こります。Hermes Agent に「過去のトラブル対応ログ」をメモリ化させ、類似エラー発生時に即座に過去事例を提示させる運用にした結果、トラブル解決時間が体感で半分以下になりました。

事例3: 研究チームの文献メモを横断参照可能にする

研究チームでは、各メンバーが読んだ論文メモが散在しがちでした。Hermes Agent に外部メモリプロバイダを接続し、メンバー全員のメモを統合ナレッジとして検索可能にした結果、「誰かが以前読んだ論文」に短時間で到達できる環境が整いました。

僕が記憶機構で失敗したこと、学んだこと

個人的な体験として、記憶機構は「最初に設計を間違えると、あとで取り返しにくい」と痛感した部分です。最初の頃の僕は MEMORY.md を「とりあえず全部書いておけば良い」と考え、雑多な情報を詰め込んでいました。結果として Hermes の応答は、時に的外れなディテールを持ち出してきたり、優先順位を間違えたりするようになりました。

転機になったのは、MEMORY.md を一度バッサリ削って、本当に「毎回必ず読んでほしい事実」だけに絞った時でした。体感で応答の精度が明らかに上がり、Hermes が迷わずに動くようになりました。記憶は「多いほど強い」のではなく、「要点が残っているほど強い」のだと学びました。

もう一つの失敗は、USER.md に個人情報を書きすぎたことです。ログ出力時に露出する危険があるため、途中から「返答スタイル」と「基本プロフィール」だけに限定する運用に戻しました。機密度の高い情報は、外部メモリプロバイダ側で暗号化して扱うほうが安全です。

お金の作り方を学ぶオンライン講座【Finorie｜フィノリー】

FAQ: 記憶機構について

Q1. MEMORY.md はどれくらいの分量が適切ですか？

目安としては max_tokens 制限の半分以下（多くの場合2000〜3000字程度）が扱いやすいです。詰め込みすぎると逆に的外れな応答が増えるため、要点に絞る運用がおすすめです。

Q2. USER.md と MEMORY.md を1ファイルにまとめてはいけませんか？

技術的には可能ですが、分離しておくメリットが大きいです。ユーザー関連の更新と運用ルールの更新が別タイミングで発生するため、ファイルを分けておくと管理が楽になります。

Q3. session_search の検索精度が低いと感じた時はどうすれば？

多くの場合、セッション保存時のメタデータ設計が原因です。タグ付けや話題ラベルを明示的に残すスキルを作っておくと、検索品質が大きく改善します。

Q4. 外部メモリプロバイダはどれを選べば良いですか？

知識グラフ重視なら ByteRover、ユーザーモデリング重視なら Honcho、バランス型なら Mem0 という選び方が一般的です。ただし最初から決め打ちせず、MEMORY.md の運用で限界を感じてから検討するのが現実的です。

Q5. 機密情報はメモリに入れても大丈夫ですか？

原則として避けてください。MEMORY や外部メモリはログ出力やプロンプト表示で露出する可能性があるため、機密情報は Vault や Secrets Manager など別系統で扱うのが安全です。

記憶運用のベストプラクティス

  • 要点だけを残す: MEMORY.md は辞書ではなく「運用規約の抜粋」として扱う意識が大切です。
  • 更新頻度を決める: 月一度はメモリ棚卸しの日を作り、古くなった情報を削除する運用を入れておきます。
  • 機密情報を絶対に書かない: パスワード、個人情報、顧客機密はメモリ禁止、これを最初に全員で合意します。
  • セッションログにはタグを付ける: session_search の精度は入口のタグで決まります。「#decision」「#bug」などの簡単なラベル運用が効きます。
  • 段階的に拡張する: 最初は MEMORY.md だけ、次に session_search、最後に外部メモリプロバイダ、という順で広げるのが無理のない育て方です。

関連ページ