LightVelaドキュメント
概要
A Hermes Agentの性格は固定されたキャラクターのコピーではありません。それは、三つの要素が連携して働くことで現れます:SOUL.mdはそれが誰でありどのように機能するかを示します — 安定した行動ルール;USER.mdはどのように扱われたいかを記録します — 関係のデフォルト;MEMORY.mdとmemories/はすでに二人が築いたものを保持します — 共有された歴史の証拠。これらの役割を明確に保つことが、エージェントが安定しつつ個性的であることを可能にします:ペルソナだけでは誰に対しても同じになってしまい、記憶だけでは行動が予測不可能に変動します。互いに置き換えるべきではありません — ペルソナは特定の事実を保存せず、USER.mdは一度きりの情報を保存しません。気分、そしてMEMORY.mdには行動規則は含まれていません。3つともモデルを切り替えてもそのまま保持されるため、性格の安定性は特定のモデルに依存しません。
なぜ同じキャラクターが異なる人によって違う行動をするのか
両方とも「忍耐強い研究助手」としてエージェントを設定した2人のユーザーを想像してください。
1人目は結論を先に知りたいプロダクトマネージャーで、主にリリースのペースや優先順位について議論します。2人目は完全な導出を必要とする学生で、主に概念や課題について議論します。
もし両方のエージェントが全く同じことを言った場合、「忍耐強い研究助手」という概念は実際には根付かず、ラベルのままであり、一緒に働く具体的な方法にはならなかった。
逆に、パーソナライズが会話ごとに行動を自由に変動させることを意味するなら、そのエージェントは予測可能性を失うだろう:今日は厳格でも、明日はいい加減になる。頼れなくなる。
人格は同時に二つの矛盾する要件を満たす必要がある:安定していること、そして個人特有であること。 ヘルメスはこれを、二つの要件を異なる層に分け、それぞれを異なるファイルで担わせることで解決している。
1. 3つのピース、3つの責任
全体像から始めましょう。
| ピース | どこに存在するか | それが答える質問 | 変更頻度 |
|---|---|---|---|
| ペルソナ | SOUL.md | 私は誰ですか? どのような原則で働いていますか? | 非常に低い;編集は意図的な決定です |
| ユーザーの好み | USER.md | どのように扱われたいですか? | 低い;長期的な習慣に応じて調整されます |
| 長期記憶 | MEMORY.md、memories/ | すでに何を確立しましたか? | 高い;ほとんどのセッションでエントリが追加される可能性があります |
その変更頻度の違いは、それらを分けておく主要な理由の一つです。数か月間変わらないルールブックを、日々増える事実リストと同じファイルに入れると、安定している部分が変動する部分に押し流されてしまいます。これはUSER.mdとMEMORY.mdを分けておく理由と同じです — 「なぜHermes Agentはメモリを二つに分けるのか:USER.mdとMEMORY.mdの役割」を参照してください。
2. ペルソナ: 安定した行動ルール
SOUL.mdはエージェントのルールブックであり、通常以下をカバーします:
- 役割 — その役割:リサーチアシスタント、ライティングパートナー、コミュニティ業務アシスタント。
- トーンと表現 — フォーマルまたはリラックス、比喩を使うかどうか、ユーモアを歓迎するかどうか。
- 優先順位の順序 — 精度と速度が衝突した場合、または簡潔さと完全さが衝突した場合、どちらを優先するか。
- 行動の制限 — 何をしないか、何を詳しく書かないか、どの行動に事前確認が必要か。
ペルソナを作成する際の三つの実用的なポイント。
まず、事実ではなく原則を書きます。 「私はエージェントデモプロジェクトのプロダクトマネージャーのために働いています」という内容はSOUL.mdには含めません — これは事実であり、USER.mdやメモリに記録するのが適切です。ペルソナは「製品に関する質問では、理由の前に結論を述べる」といった永続的な原則を示すべきです。
次に、限界を判断可能な具体的なものにします。 「プロフェッショナルでいること」は遵守状況を評価できません。「医療、法律、投資の判断を提供せず、公開情報を提供し、専門家に相談することを推奨する」は評価可能です。抽象的なルールはモデルごとに遵守のばらつきが大きくなります。
第三に、衝突に対して優先順位を明示的に示すこと。 ルールは必然的に衝突します — 簡潔さと完全さはその一例です。明示的な順序がなければ、エージェントは毎回推測する必要があり、その行動は一貫性を欠くようになります。
3. ユーザーの好み: 関係のデフォルト
USER.md は、あなたに関する安定した情報 を含むため、エージェントは毎回再度尋ねる必要がありません。適切な例:
- 言語と表現 — どの言語を使用するか、専門用語をそのままにするか、例が役立つかどうか。
- コミュニケーションのペース — まず結論、それとも完全な推論の過程。
- 普段使うツールや環境 — 日常的に使用するスタック、プラットフォーム、作業スタイル。
- 明確に避けるべきこと — 調べられたくない方向性、使われてほしくない表現。
あるものがUSER.mdに属するかどうかの簡単なテストがあります:それは三か月後も真実であるか? 「簡潔な回答を好む」はおそらく真実なので、適しています。「今日は急いでいる」はそうではなく、一時的な文脈なので除外すべきです。
このテストは重要です。一時的な気分を USER.md に書き込むと、エージェントは一時的な状態を恒久的なものとして扱います。急いでいるときに「手短に」と言ったことが、長期的な好みに変わると、後で本当に詳細が必要なときにも詳細を控えるようになります。
4. 長期記憶: 共有された歴史の証拠
MEMORY.md と memories/ は すでに起こったことで、保持する価値のある事実 を保存します:プロジェクトの状態、下した決定、再利用可能な結論、あるパラメータがそのように設定されている理由など。
他の二つとの関係:
- ペルソナは 行動原則 を決定します。
USER.mdは デフォルトの対話スタイル を決定します。- メモリは あなたたちが共有する背景 を決定します。
リコールはオンデマンドです: Hermes はエントリに対して SQLite + FTS5 フルテキストインデックスを構築し、関連するトピックを取り上げたときに該当するものをコンテキストに取り入れます。すべての履歴を押し込むわけではありません。書き込みも無制限の追加ではなく、add / replace / remove の操作を通じて維持され、/memory pending で確認することができます。完全なキュレーションロジックについては、「Why More Memory Is Not Better: How Hermes Agent Selects, Curates, and Updates Long-Term Memory.」を参照してください。
記憶はペルソナの代わりにはなりません。 一般的な間違いとして、行動規則を記憶エントリとして書くことがあります。例えば、「覚えておく: 常に結論を先に述べる」といったものです。これは二つの問題を生みます。クエリが一致しない場合、そのエントリは呼び出されない可能性があり、後のエントリによって消されてしまうこともあります。行動規則は常に常駐する SOUL.md に属します。
5. これら三つがどのように組み合わさって一つの答えを生み出すか
レイヤーを結びつける具体的なシナリオ。
設定:
SOUL.md: 研究アシスタント; 推論の前に結論を出す; 不確実性を明確に示す; 医療や投資のアドバイスを拡張しない。USER.md: 英語を好む; 技術用語は元の形のままにする; 回答は見やすくする。MEMORY.md: 現在、agent-demoプロジェクトのグローバルサイトで作業中; 先週、ホームページをアニメーション付きグラデーションに変更することを決定; プロジェクトはNext.jsで実行されている。
あなたの質問: "現在のホームページのアプローチに対して、ビデオ背景を追加するリスクは何ですか?"
各レイヤーの貢献:
- メモリ は背景を提供します:エージェントは「ホームページ」がどのページを指しているかを知っており、それが最近アニメーション付きグラデーションに変更されたことも知っているため、ビデオ背景を真っ新な状態での決定としてではなく、その上に変化が加わったものとして扱うことができます。
- ペルソナ は構造を決定します:結論を先に(「主なリスクはファーストビューのパフォーマンスとモバイルデータ使用量です」)、その後に理由を挙げ、不確実性を明示的に示します。
USER.mdは表現を決定します:英語で回答し、LCPやautoplayなどの用語はそのままにし、長さは読みやすく保ちます。
どの層か一つを取り除くと、結果は目に見えて劣化します:メモリがなければ答えは一般的なものにとどまり、ペルソナがなければ構造は迷走し、不確実性は見逃され、好みがなければ言語や長さがあなたの読み方に合いません。
6. 一般的な症状とそれぞれが属する場所
実際には最もよくある質問は「この情報はどこに置くべきか?」です。下の表がそれに答えます。
| 症状 | より可能性の高い原因 | 変更すべきこと |
|---|---|---|
| すべてのトピックに対して同じ一般的なアプローチ | メモリにあなたの具体的な背景が欠けている | メモリエントリを追加する |
| 一貫性のない行動、厳格な時もあれば不注意な時もある | ペルソナのルールが抽象的すぎる、または優先すべき対立がない | ルールが判断可能になるようにSOUL.mdを編集する |
| 毎回好みを言い直す | 好みがUSER.mdに書き込まれたことがない | それらをUSER.mdに追加する |
| 一時的な状態を永久的なものとして扱う | 一度きりのコンテキストがUSER.mdに書き込まれた | そのエントリを削除し、会話中に代わりに述べる |
| あるルールは時々適用されるが、常にではない | ルールは記憶として保存されました | それを記憶からSOUL.mdに移動します |
| モデルを切り替えた後、トーンが目に見えて変わりました | 新しいモデルは異なる厳密さでルールを適用します | キー制約をより具体的にし、記憶はそのままにします |
最後の行は強調に値します:モデルを切り替えた後のトーンの変化は、人格の喪失ではありません。 SOUL.mdは依然として元の場所にあります;順守の仕方が変わっただけです。違いを見分ける方法については、「モデルを切り替えるとエージェントは忘れるのか? モデル、ペルソナ、記憶の分離」を参照してください。
7. LightVelaのアプローチ:人格と嗜好を管理可能な資産として
Hermesはこれらの三つの層を明確に区別していますが、それでも直接Markdownを編集する人々を対象としています。LightVelaはクラウドホスティングされたモデルを運用しており、ユーザー向けのファイルシステム操作を公開していないため、これらの層はセルフホスト型の設定とは異なる方法で維持されています:
- ペルソナはペルソナ機能を通じて設定されます — エージェントの設定ページにあるペルソナセクションでは、ランダムにペルソナを引くか、短いクイズに答えるかの2つのエントリーポイントがあります。ペルソナカードの役割、トーン、行動メモを確認した後、[ペルソナ注入]を選択して適用します。これにより、クラウドファイルシステムに触れることなくソウルを生成して注入できますが、任意のクラウドファイル用の汎用エディタではありません。
- メモリはコンソールで確認できます — メモリページでは、エージェントが保持している情報を表示し、事実と安定した好みの分割に合わせてメモリとユーザープロファイルの別々のタブがあります。
- 追加と削除は会話を通じて行われます — メモリを意図的に「埋める」必要はありません。通常の会話では、Hermesが保持する価値のある情報を判断します;何かを覚えさせたり忘れさせたい場合は、チャットでそう伝えるだけで大丈夫です。
- 容量は調整可能です — コンソールを使ってメモリ容量の上限を上げたり下げたりでき、長期的なコンテキストが無制限に増えるのを防げます。
- モデル間で安定 — モデルを切り替えても、メモリ、スキル、オートメーションは消えないため、性格の安定性は特定のモデルに依存しません。
- チャネルを超えて一貫性がある — 一人のエージェントは、接続されているすべてのチャネルで同じ記憶とパーソナを共有します。電話やチャネルを切り替えても失われず、プラットフォームごとに複製する必要はありません。
主なポイント
- パーソナリティは三つの要素から生まれます:
SOUL.md(行動規則)、USER.md(デフォルトのやり取りスタイル)、MEMORY.md/memories/(共有された背景)。 - これらを分ける主な理由は変更頻度の違いです:規則は数か月変わらず、記憶はほぼ毎日増加します。
- パーソナは事実ではなく原則を述べ、判断できる程度に限界を具体化し、矛盾する規則に対する優先順位を宣言します。
USER.mdメンバーシップのテスト: これが3か月後も本当であるか?- 行動規則をメモリとして保存しないでください。さもないと、記憶の取りこぼしや消去によって断続的に失敗することがあります。
- モデルを切り替えた後の口調の変化は、人格や記憶が失われたのではなく、順守の違いを反映しています。
最終更新日: 2026-08-28
LightVelaドキュメント
モデルを切り替えてもHermes Agentがあなたを忘れることはありません。なぜなら、モデル、ペルソナ、メモリは三つの別々に保存される層だからです:モデルは推論と生成を担当し、SOUL.mdは役割と表現の境界を定義し、USER.mdとMEMORY.md(memories/を含む)はユーザープロファイルとセッション間の事実を保持します。
LightVelaドキュメント
A Hermes Agent のファイルは、ひとつの散らかったフォルダに入っているわけではありません。これらは異なる責任を持つ三つの場所に属します。作業ディレクトリには現在のタスクの入力、出力、ツールの実行が格納されており、実際の境界があります — ツールはワークスペースを越えて任意のシステムパスに移動することはできません。