Hermes Agentの人格をSOUL.mdで整える|長く使える声の作り方

返答を短くしてほしい、曖昧な時は推測せずに伝えてほしい、反対意見も遠慮なく出してほしい。こうした希望を毎回の会話で説明すると、伝え忘れたセッションだけ別の相手に見えてきます。
Hermes Agent では、長く使う人格と話し方をSOUL.mdへ置けます。これは単なる補足メモではありません。公式ドキュメントでは、Hermes インスタンスの主な identity として、system prompt の最初の枠へ入るファイルです。
人格を安定させるには、派手なキャラクターを一度で完成させる必要はありません。短い基準を作り、会話で確かめながら直せる状態にします。
前回完了時から今回完了後まで
前回までに、一時的な話し方を基準の人格へ重ね、終われば外せる状態になりました。今回は、その基準の人格自体を長く保つための置き場所と書き方を扱います。
| 時点 | 状態 |
|---|---|
| 前回完了時 | SOUL.mdを保ったまま、/personalityで一時的な話し方を選び、noneで基準へ戻せます |
| 今回完了後 | SOUL.mdへ長く使う声と判断基準を置き、読み込み先とほかの設定ファイルとの境界を確認できます |
読み飛ばせる章: すでに
SOUL.mdでidentity、style、avoid、defaultsを分け、短い見直しを続けている場合は、「最初は4つの見出しで短く書く」を飛ばし、「抽象語を観察できる振る舞いへ変える」から読みます。
SOUL.mdが変えるもの
SOUL.mdが担当するのは、Hermes が「誰であり、どう話すか」です。
- 口調と温度感
- 率直さの程度
- 回答の詳しさ
- 不確実な時の振る舞い
- 意見が食い違った時の姿勢
- 避けたい表現や癖
たとえば「短く答える」だけでは、難しい相談まで短く切り詰める可能性があります。「通常は簡潔にし、判断材料が必要な時は理由を示す」と書けば、声と実用性を一緒に定義できます。
一方、SOUL.mdへすべての指示を集めると、人格と作業規約が混ざります。公式文書は、用途を次のように分けています。
| 残したい内容 | 置き場所 | 例 |
|---|---|---|
| Hermesのidentityと話し方 | SOUL.md | 率直さ、温かさ、説明の深さ、避ける表現 |
| 利用者についての事実や好み | USER.md | 名前、役割、好む連絡方法 |
| Hermesが学んだ継続的な事実 | MEMORY.md | 環境の特徴、過去に分かった注意点 |
| repository固有の規約 | AGENTS.mdまたは.hermes.md | test command、directory構成、deploy手順 |
| 一時的な会話モード | /personality | teacher、technical、creative |
判断基準は短くできます。多くの会話へ持ち越す「声」ならSOUL.md、特定 project だけの「仕事のルール」ならAGENTS.mdです。
読み込む場所はworking directoryではない
通常の保存先は次です。
~/.hermes/SOUL.md
独自のHERMES_HOMEを使う instance では、保存先もその配下へ変わります。
$HERMES_HOME/SOUL.md
repository 直下へSOUL.mdを置いても、Hermes の主な人格としては読みません。project を移動するたび人格が偶然変わらないように、現在の Hermes instance に属する 1 枚だけを読みます。
CLIで実際の読み込み先を確かめる
編集前に、公式 CLI のhermes config pathで、起動中の Hermes が使う設定先を確かめます。出力される絶対パスは端末ごとに異なるため、次のように末尾と同じ directory 内のSOUL.mdだけを検査します。
config_path="$(hermes config path)"
test "$(basename "$config_path")" = 'config.yaml' &&
printf '%s\n' 'config path: OK'
test -s "$(dirname "$config_path")/SOUL.md" &&
printf '%s\n' 'SOUL.md: present'
Hermes を一度起動済みで、SOUL.mdが空でない場合の期待する出力は次です。
config path: OK
SOUL.md: present
1 行目は CLI が返した設定先がconfig.yamlであること、2 行目は同じ Hermes instance に空でないSOUL.mdがあることを示します。2 行目が出ない場合は、まだ初回起動していないか、確認している instance が違います。この検査で確認できるのは保存先だけです。内容が意図した話し方になるかは、新しいセッションで別途確かめます。
初回は starter file が自動で作られます。すでに自分のSOUL.mdがある場合、Hermes は上書きしません。内容が無い、空白だけ、または読み込めない場合は、組み込みの default identity へ戻ります。
読み込みの位置も重要です。
[SOUL.md]
identityと基準の声
│
▼
[tool guidance / Memory / Skills]
能力と継続的な文脈
│
▼
[AGENTS.mdなど]
project固有の規約
│
▼
[/personalityなどのoverlay]
一時的な話し方
SOUL.mdは土台ですが、唯一の指示ではありません。後段の規約や一時 overlay と矛盾させないことが、安定した人格を作る近道です。
最初は4つの見出しで短く書く
公式ガイドは、identity、style、avoid、defaults という単純な構成を例示しています。見出し自体を必須とはしていません。役割を分けると矛盾を見つけやすくなります。
技術的な相談相手なら、次のように書けます。
# Identity
あなたは、現実的で落ち着いた技術パートナーです。
正しさと利用者の目的を、もっともらしさより優先します。
# Style
- 答えの要点を冒頭で伝えます
- 通常は簡潔にし、判断に必要な理由は省きません
- 専門用語を使う時は、必要に応じて短く説明します
# Avoid
- 根拠のない断定をしません
- 同意するためだけの賛同をしません
- 大げさな宣伝調の表現を避けます
# Defaults
- 不確実な点は、事実と推測を分けます
- 前提が弱い時は、丁寧に反対意見を示します
- 質問が曖昧でも、安全な範囲で進められる時は仮定を明示して進めます
この例で決めているのは職務手順ではなく、会話を通じて変えたくない姿勢です。package manager、テスト、port 番号、公開手順は書いていません。それらは project ごとに変わるからです。
最初から長い人格設定を作る必要もありません。公式ガイドは、まず 4〜8 行を加え、会話を続け、違和感に応じて調整する流れを勧めています。一般的な「親切にする」「分かりやすくする」だけを並べるより、自分が違いを感じる基準を少数選びます。
抽象語を観察できる振る舞いへ変える
「賢い」「プロらしい」「人間らしい」は、読む人によって意味が変わります。返答を見て判定できる書き方へ変えると、修正点が分かります。
| 抽象的な希望 | 観察できる書き方 |
|---|---|
| 正直に答える | 不明な点を断定せず、確認済みの事実と推測を分ける |
| 簡潔に答える | 答えの要点を冒頭に置き、追加説明は判断に必要な分だけ続ける |
| 批判的に考える | 前提が弱い場合は、同意せず理由と代案を示す |
| 優しく答える | 問題点は曖昧にせず、人格ではなく案を対象に指摘する |
| 主体的に動く | 安全で可逆な作業は仮定を明示して進め、重大な選択は尋ねる |
こう書けば、返答を読んだ時に「短すぎる」「反対理由が無い」「推測が事実のように見える」と具体的に直せます。
一度に完成させず、同じ質問で比べる
編集後は、新しいセッションを始めます。SOUL.mdはセッション開始時に読み込まれるため、進行中の会話だけを続けても変更後の内容になりません。
比較には、人格の境界が出やすい 3 種類の質問を使います。
- 短く済む事実確認
- 正解が 1 つではない設計相談
- 利用者の案に弱い前提があるレビュー
同じ質問を編集前後で試し、次の観点だけを記録します。
| 観点 | 確認すること |
|---|---|
| 長さ | 簡単な問いへ説明を足しすぎていないか |
| 率直さ | 問題のある案へ迎合していないか |
| 不確実性 | 確認できない内容を断定していないか |
| 温度感 | 直接的でも、不要に冷たくなっていないか |
| 一貫性 | 別topicでも同じ判断姿勢が残るか |
合わなかった時は、形容詞を増やすより、原因になった 1 行を直します。「常に短く」が説明不足を生むなら、「簡単な問いは短く、意思決定には理由を添える」へ変えます。小さな差分なら、どの指示が効いたのか追えます。
SOUL.mdへ入れないもの
人格ファイルが効かない時、指示を追加し続けるとさらに読みにくくなります。次の内容は別の場所へ分けます。
project固有のcommand
pnpm testを使う、migration を直接編集しない、API は 8000 番で動く、といった規約はAGENTS.md側です。別 project でも同じ声を保つSOUL.mdとは寿命が違います。
利用者のプロフィール
利用者の氏名、職種、連絡の好みは、人格ではなく利用者についての情報です。USER.mdとSOUL.mdは別の仕組みで、片方を編集してももう片方へ内容は移りません。
一時的な役割
今日だけ教師として説明する、今回だけ厳しい reviewer になる、といったモードは/personalityが担当します。SOUL.mdは基準の声、/personalityはセッション単位の overlay です。具体的な切り替え手順は「Hermes Agentの人格を一時的に切り替える」で確認できます。
毎回の出力形式
あらゆる返答を同じ見出し数や文字数へ固定すると、簡単な問いまで重くなります。SOUL.mdには人格の default を置き、特定成果物の形式はその依頼や Skill へ寄せます。
読み込み前に検査と切り詰めが行われる
SOUL.mdの内容は、そのまま identity の位置へ入る前に prompt injection の pattern 検査を受け、長すぎる場合は切り詰められます。wrapper 文は追加されないため、ファイル本文の書き方がそのまま重要です。
長いファイルは切り詰められます。そのため、後半の指示は反映されない可能性があります。人格を細かな規則の倉庫にせず、広い状況で使う少数の基準へ絞る方が扱いやすくなります。
反映されない時の確認順
| 症状 | 確認すること | 対応 |
|---|---|---|
| 編集しても話し方が変わりません | 編集後も同じセッションを続けています | Hermesを再起動するか、新しいセッションを始めます |
| repository直下のfileが読まれません | 保存先がworking directoryです | ~/.hermes/SOUL.mdまたは現在の$HERMES_HOME/SOUL.mdを編集します |
| defaultのような返答になります | fileが空、空白だけ、または読み込めません | 内容とpermissionを確認し、新しいセッションで試します |
| 一部の指示だけ弱く見えます | 文中に矛盾があります | 反対方向の表現を探し、優先する方だけを残します |
| 期待より別の口調になります | /personalityが有効です | /personalityでactiveなoverlayを確認します |
| 後半の指示が効きません | fileが長すぎます | project規約や一時指示を別の場所へ移します |
確認は保存場所、新しいセッション、overlay、矛盾、長さの順に進めます。人格を全面的に書き直す前に、読み込まれている 1 枚と一時設定を特定します。
良いSOUL.mdは短い憲法になる
SOUL.mdは、すべての仕事を命令する手順書ではありません。多くの会話をまたいで残したい identity、声、判断姿勢を置く場所です。
まず短い 4〜8 行から始めます。抽象的な理想を、返答から確認できる振る舞いへ変えます。project の command はAGENTS.mdへ、一時的な役は/personalityへ分けます。そして編集後は新しいセッションで、同じ質問を使って差分を見ます。
長い設定より、矛盾なく繰り返し使える少数の基準の方が、Hermes を同じ相手として育てやすくなります。
一次情報
| 出典 | 確認した内容 |
|---|---|
| Personality & SOUL.md | SOUL.mdの保存場所、system prompt内の位置、security scanning、AGENTS.mdと/personalityとの違い |
| Use SOUL.md with Hermes | 書く内容、短く始める手順、編集後のセッション再開、troubleshooting |
| Which File Does What? | SOUL.md、USER.md、MEMORY.md、project contextの役割と読み込み時点 |
| NousResearch/hermes-agent | 公開repository上のPersonality & SOUL.md原文 |
公開ドキュメントは更新される可能性があります。保存場所や prompt 構成は、実際に使う版の公式文書でも確認してください。
