Hermes Agentの人格を仕事別に分ける｜HERMES_HOMEの境界を実機で確かめる

執筆役には柔らかい言葉を求め、レビュー役には遠慮のない指摘を求めます。同じSOUL.mdを共有したまま両方を動かすと、片方へ足した指示がもう片方にも効きます。名前だけ変えても、人格の保存先は分かれません。

Hermes Agent では、人格を分ける単位がHERMES_HOMEです。公式の Profile 機能は、profile ごとに別の home を用意します。そこへSOUL.md、Memory、Skills、設定、cron、セッションを分けて置きます。

2026 年 9 月 13 日、Hermes Agent v0.21.0 で 2 つの検証用 home を作りました。設定の参照先と system prompt の byte 数が別々になることを確認し、検証後は両方を削除しました。本番の profile とSOUL.mdは変更していません。

前回の一時切り替えから、役割の分離へ進む

前回の「Hermes Agentの人格を一時的に切り替える」では、1 つの Hermes で/personalityを切り替えました。今回の目的は、一時的な話し方ではなく、並行して使う 2 つの役割を分けることです。

時点	状態
前回完了時	1つの基準人格へ一時的なoverlayを重ねられます
今回開始時	執筆役とレビュー役が同じhomeを使うと、人格と記憶が混ざります
今回完了後	役割ごとにHERMES_HOMEを分け、参照先を出力で確認できます

すでに profile を分け、hermes profileで現在地を確認できる場合は、「2 つの検証用 home で差を測る」まで飛ばせます。

なぜ名前だけでは足りないのか

AI エージェントの名前は表示です。人格を保存する境界ではありません。Hermes Agent は、現在のHERMES_HOME直下にあるSOUL.mdを主な人格として読みます。

同じ home へ 2 つの process を向けると、SOUL.mdだけでなく Memory の書き込み先も共有します。片方が保存した事実を、もう片方が次のセッションで自分の記憶として読み込みます。公式 Profile ガイドも、2 つの agent process で同じ profile を共有しないよう明記しています。

私は、役割を長く並行運用するなら profile を分けます。短い作業だけ口調を変えるなら/personalityを使います。この境界を先に決めると、人格ファイルを毎回書き換えずに済みます。

用語を揃える

用語	この回での意味
HERMES_HOME	Hermesの設定、人格、記憶、Skill、セッションなどを持つhomeです
SOUL.md	そのHermes instanceで継続して使う主な人格です
profile	独立したHERMES_HOMEを持つHermesの運用単位です
/personality	現在のセッションへ一時的に重ねる話し方です
working directory	terminal toolが作業を始めるdirectoryです。profileとは別です
system prompt	SOUL.mdや規則、Memoryなどを組み立ててmodelへ渡す入力です

人格が分かれる構成

profile は人格の名前札ではなく、状態 directory の境界です。

                    ┌─────────────────────┐
                    │  OS上の同じ利用者   │
                    └──────────┬──────────┘
                               │
                 ┌─────────────┴─────────────┐
                 ▼                           ▼
┌──────────────────────────┐   ┌──────────────────────────┐
│ writer profile           │   │ reviewer profile         │
│ HERMES_HOME = writer     │   │ HERMES_HOME = reviewer   │
│                          │   │                          │
│ SOUL.md: 穏やかな編集者  │   │ SOUL.md: 厳密なreviewer  │
│ Memory / Skills / cron   │   │ Memory / Skills / cron   │
└────────────┬─────────────┘   └────────────┬─────────────┘
             ▼                              ▼
       writerのsession                reviewerのsession

working directoryとOS権限は別途設定します

ここで重要なのは、profile が filesystem sandbox ではない点です。local backend では、2 つの profile が同じ OS 利用者の権限で動きます。人格と状態は分かれても、読める file まで自動で制限されません。

2つの検証用homeで差を測る

本番 profile を増やす前に、一時 directory で読み込み境界だけを確かめます。次の command はtempfile.TemporaryDirectoryを使うため、処理が終わると検証 directory を削除します。API call は行いません。

python3 -c "import json, os, pathlib, subprocess, tempfile
with tempfile.TemporaryDirectory(prefix='hermes-persona-lab-') as root:
    root = pathlib.Path(root)
    homes = {'writer': root/'writer', 'reviewer': root/'reviewer'}
    souls = {
        'writer': '# Soul\n\n穏やかな編集者として、短い日本語で答えます。\n',
        'reviewer': '# Soul\n\n厳密なレビュー担当として、根拠と不足を分けます。\n',
    }
    for name, home in homes.items():
        home.mkdir()
        (home/'SOUL.md').write_text(souls[name], encoding='utf-8')
        env = os.environ | {'HERMES_HOME': str(home)}
        path_result = subprocess.run(
            ['hermes', 'config', 'path'], env=env,
            text=True, capture_output=True, check=True,
        )
        size_result = subprocess.run(
            ['hermes', 'prompt-size', '--json'], env=env,
            text=True, capture_output=True, check=True,
        )
        data = json.loads(size_result.stdout)
        config_home = pathlib.Path(path_result.stdout.strip()).parent.name
        print(f'{name}: config_home={config_home}')
        print(f'{name}: soul_chars={len(souls[name].strip())}')
        print(f'{name}: system_prompt_bytes={data[\"system_prompt\"][\"bytes\"]}')
    print(f'distinct_soul={souls[\"writer\"] != souls[\"reviewer\"]}')
print('cleanup=done')"

実機の出力です。

writer: config_home=writer
writer: soul_chars=30
writer: system_prompt_bytes=5575
reviewer: config_home=reviewer
reviewer: soul_chars=32
reviewer: system_prompt_bytes=5583
distinct_soul=True
cleanup=done

config_homeがwriterとreviewerへ分かれました。2 つのSOUL.mdは内容も文字数も異なります。system prompt も 5575 byte と 5583 byte になり、それぞれの入力が別に組み立てられています。

8 byte の差だけで人格の品質は判断できません。この検査が確認するのは、別の home から別の入力が作られた事実です。実際の返答は、新しいセッションで同じ質問を渡し、内容を読んで評価します。

実運用ではProfile commandを使う

検証で境界を理解したら、日常運用は公式の Profile command へ任せます。たとえば、執筆専用の profile は次の形で作れます。

hermes profile create writer --description "記事を執筆し、公開前で停止する。"
writer setup
hermes profile show writer

hermes profile create writerは、独立した profile directory とwriter command alias を作ります。writer setupで model や provider を設定し、writer chatでその profile のセッションを始められます。

既存 profile の設定、Skills、SOUL.md、Memory を起点にするなら--cloneがあります。ただし、cron とセッション history は複製されません。これは、定期 job の二重実行を避けるための安全な初期値です。

hermes profile create reviewer --clone --description "記事を読み、根拠不足を指摘する。"
hermes profile show reviewer

clone 後は、reviewer側のSOUL.mdを役割に合わせて見直します。元 profile と同じ人格を複製しただけでは、役割分担は完成しません。

現在地を質問ではなくcommandで確かめる

「あなたは writer ですか」と model へ尋ねても、正しい profile を使っている証拠にはなりません。会話中の文脈から、それらしい答えを返す場合があるためです。

profile の確認には、状態を読む command を使います。

hermes profile
hermes profile show writer
writer config path
writer prompt-size --json

注目するのは profile 名、profile path、model、gateway の状態です。config pathが想定外なら、SOUL.mdを編集する前に止めます。別 profile の人格を直しても、起動中の agent には反映されません。

working directoryも別に決める

profile を分けても、terminal command の開始場所は自動で profile directory になりません。執筆役を特定の repository から始めたい場合は、その profile の設定へ絶対パスを指定します。

writer config set terminal.cwd /absolute/path/to/articles
writer config get terminal.cwd

これは開始場所の設定です。filesystem access をその directory へ閉じ込める sandbox ではありません。権限境界が必要なら、Docker などの terminal backend や OS 権限を組み合わせます。

私は、次の 3 つを分けて確認します。

• 人格と Memory は profile で分けます
• command の開始場所はterminal.cwdで固定します
• 読み書きの強制境界は sandbox と OS 権限で作ります

変更が効くのは新しいセッションから

SOUL.mdは system prompt の先頭に入ります。進行中のセッションは、開始時に作った prompt を保持します。file を直した直後に同じセッションで質問しても、古い人格のまま返答することがあります。

人格を変更した後は、新しいセッションを作ります。Memory も同じ考え方です。disk への書き込みは完了していても、保存内容は次のセッション開始時に読み直されます。

確認用の質問は、役割ごとに同じものを 1 件だけ使うと比較しやすくなります。たとえば「根拠が足りない原稿へ、修正優先度を付けてください」と渡します。writer は読みやすさを、reviewer は証拠不足を優先する設計なら、その差が返答へ出ているかを読みます。

よくあるエラー

表示や症状	主な原因	対応
SOUL.mdを変えても人格が同じです	進行中のセッションが古いpromptを持っています	新しいセッションを始めて確認します
writerを起動したのにreviewerの口調です	command aliasまたはsticky defaultが想定と違います	hermes profileとconfig pathで参照先を確認します
2つのagentが同じ事実を勝手に覚えます	同じHERMES_HOMEを共有しています	processごとに別profileを使います
profileを分けたのに他のdirectoryを読めます	profileをsandboxと誤解しています	Dockerなどの実行境界とOS権限を使います
cloneした直後に同じ人格で答えます	SOUL.mdもcloneされています	新profile側の人格を見直し、新しいセッションで確認します
cronが複製されません	--cloneと--clone-allはcronを複製しません	必要なjobだけを新profileへ明示的に作ります
byte数が記事と一致しません	Hermesの版、Skills、設定が異なります	絶対値ではなく、同じ環境内の差を比べます
terminal.cwdを設定したのに外へ移動できます	cwdは開始場所であり、アクセス制御ではありません	sandboxまたは専用OS userを検討します

人格を増やす前に所有者を決める

執筆役とレビュー役を分ける目的は、返答へ別の演技を足すことではありません。どの agent がどの人格、Memory、Skill、cron を更新するのかを明確にすることです。

短い役割変更なら/personalityで足ります。長く並行して動く役割なら profile を分けます。さらに強制的な file 境界が必要なら sandbox を使います。この順番なら、人格の調整と権限の設計を混同しません。

今回の検証では、writerとreviewerが別の config home を参照し、system prompt も別に組み立てられました。検証 directory はcleanup=doneまで確認しています。本番の profile、Memory、cron には触れていません。

一次情報

出典	確認した内容
Hermes Agent Profiles	profileごとの状態分離、clone、command alias、cwdとsandboxの違い
Personality & SOUL.md	SOUL.mdの読込場所、主な人格、一時overlayとの境界
Prompt Assembly	system promptの組み立て、SOUL.mdの位置、新セッションでの再読込
Persistent Memory	Memoryのprofile境界、固定snapshot、同じhomeを共有しない理由
CLI Commands Reference	profile、config path、prompt-size --jsonのcommand
Hermes Agent GitHub	公式source repositoryとrelease元

※2026 年 8 月 17 日から 9 月 13 日までの GSC では、hermes agent 人格が 2 impressions、平均掲載順位 6.5 でした。この検索意図と、AI エージェントを役割別に育てる関心を、profile 境界の実機確認へつなげています。