技術ブログ

Hermes Agentの記憶・人格・スキルを混ぜずに育てる

約11分で読めます
#Hermes Agent#AIエージェント#プロンプト設計#Skills
Hermes Agentの記憶・人格・スキルを混ぜずに育てる

同じ注意書きをSOUL.mdとMEMORY.mdの両方へ置くと、AI エージェントは賢くなるより先に重くなります。手順まで常時読み込ませれば、更新漏れも増えます。

2026 年 8 月 29 日、Hermes Agent v0.20.5 でプロンプト量を測りました。普段使う環境では、Skills の索引が 10,273 バイト、Memory が 2,508 バイト、User Profile が 1,693 バイトでした。小さな記録も毎回の入力へ積み上がります。

私は、人格は姿勢、記憶は事実、スキルは手順として分けます。置き場所を先に決めると、エージェントを育てても指示が絡まりません。

前回の移行確認から、日常運用へ進む

前回は、OpenClaw から Hermes Agent へ移す対象をhermes claw migrate --dry-runで数えました。今回は、移行後に情報をどこへ置くかを決めます。

前回完了時今回完了後
記憶、人格、スキルの移行候補を確認できましたそれぞれの保存先を理由付きで選べます
本番を書き換えずに移行件数を確認しました専用のHERMES_HOMEで配置を試せます
競合を移行前に見つけました重複した指示を常時読み込む事態を避けられます

すでにSOUL.md、Memory、Skills を分けており、hermes prompt-sizeも確認済みなら、「増やす前に測る」まで飛ばせます。

置き場所で寿命が変わる

Hermes Agent は、セッション開始時に複数の情報を組み立てます。公式ドキュメントでは、SOUL.mdを人格、MEMORY.mdとUSER.mdを記憶、Skills を必要時に読む手順として扱います。

ここで「デプロイ前にテストする」という手順を Memory へ保存すると、その手順は関係のない相談でも入力へ入ります。反対に、利用者の言語設定を Skill へ置くと、その Skill を開かない会話では好みが伝わりません。

保存先を分ける理由は、見栄えではありません。常時必要な情報だけを短く保ち、長い手順を必要な仕事まで待機させるためです。

情報置き場所判断の目安
判断姿勢、口調、価値観SOUL.mdほぼ全ての会話で守る内容です
環境、制約、学んだ事実MEMORY.md次のセッションでも必要な事実です
名前、好み、期待する報告形式USER.md利用者についての安定した情報です
複数段階の作業、検証、失敗時の戻り方SKILL.md特定の仕事でだけ読む手順です
リポジトリ固有の規則AGENTS.mdなどその作業ディレクトリだけで必要です

用語を揃える

用語ここでの意味
HERMES_HOME設定、人格、記憶、スキルをまとめるHermesのホームです
SOUL.mdエージェントの人格と常設の行動姿勢です
MemoryMEMORY.mdとUSER.mdから作る、セッション開始時の固定スナップショットです
Skill必要なときにskill_viewで読む再利用可能な手順です
Progressive Disclosure索引だけを常時見せ、本文を必要時に読む方式です
Prompt cache同じ入力の先頭部分を再利用する仕組みです

Hermesが読む流れ

公式の Prompt Assembly では、情報を stable、context、volatile の順で組み立てます。Skills の索引は stable、プロジェクト規則は context、Memory と User Profile は volatile へ入ります。

┌──────────────────────────────┐
│ SOUL.md + Skillsの短い索引   │ stable
└──────────────┬───────────────┘
               ▼
┌──────────────────────────────┐
│ AGENTS.mdなどの作業規則      │ context
└──────────────┬───────────────┘
               ▼
┌──────────────────────────────┐
│ MEMORY.md + USER.md          │ volatile
└──────────────┬───────────────┘
               ▼
        モデルへ渡す入力
               │
               └── 必要な仕事だけSkill本文を読む

Memory を書き換えても、進行中のセッションへ即座には入りません。ディスクへの保存は即時ですが、新しい内容は次のセッション開始時に読み込まれます。この固定スナップショットが、途中で入力の先頭を変えずに済む理由です。

本番を触らずに配置を試す

既存の~/.hermesへ直接書く必要はありません。HERMES_HOMEを/tmp/hermes-layer-labへ向ければ、検証用の小さな環境を作れます。

次の Python を実行すると、人格、記憶、利用者情報、デプロイ手順を別々に配置します。

python3 - <<'PY'
from pathlib import Path

root = Path('/tmp/hermes-layer-lab')
(root / 'memories').mkdir(parents=True, exist_ok=True)
(root / 'skills' / 'deploy-staging').mkdir(parents=True, exist_ok=True)

(root / 'SOUL.md').write_text(
    '# Soul\n\n簡潔に答え、確認できない事実は断定しません。\n',
    encoding='utf-8',
)
(root / 'memories' / 'MEMORY.md').write_text(
    '検証環境は Debian 13、Python 3.11 を使う。\n',
    encoding='utf-8',
)
(root / 'memories' / 'USER.md').write_text(
    '日本語の簡潔な報告を好む。\n',
    encoding='utf-8',
)
(root / 'skills' / 'deploy-staging' / 'SKILL.md').write_text(
    '''---
name: deploy-staging
description: Use when deploying the staging service safely.
---
# Staging deploy

1. Run tests.
2. Deploy.
3. Read back the health endpoint.
''',
    encoding='utf-8',
)
print('created: SOUL.md, memories/MEMORY.md, memories/USER.md, skills/deploy-staging/SKILL.md')
PY

実行結果です。

created: SOUL.md, memories/MEMORY.md, memories/USER.md, skills/deploy-staging/SKILL.md

ここでは実際の API キーや接続先を書きません。秘密情報は Memory や Skill へ入れず、Hermes が使う秘密管理の経路へ分離します。

読み込み状態を確認する

memory statusは、Memory の本文を表示せずに有効状態を確認できます。

HERMES_HOME=/tmp/hermes-layer-lab hermes memory status

2026 年 8 月 29 日の出力では、3 項目が有効でした。

Memory status
────────────────────────────────────────
  Built-in (MEMORY.md / USER.md):
    Memory injection:   enabled ✓
    User profile:       enabled ✓
    Memory tool:        enabled ✓
  Provider:  (none — built-in only)

Provider: noneは、組み込み Memory だけを使う状態です。Hindsight や Mem0 などの外部プロバイダを追加しない検証には十分です。

増やす前に測る

prompt-sizeは、本文を外へ送らずに固定費を集計します。

HERMES_HOME=/tmp/hermes-layer-lab hermes prompt-size

今回の検証環境では、次の値になりました。

Prompt-size breakdown (platform=cli, model=unset)

  System prompt total :   20,460 B  (20.0 KB, 19,852 chars)

  Major blocks:
    skills index       :      125 B  (0.1 KB)
    memory             :      383 B  (0.4 KB)
    user profile       :      372 B  (0.4 KB)

  Prompt tiers:
    stable (identity/guidance/skills)   :   14,046 B  (13.7 KB)
    context (AGENTS.md/cwd files)       :    3,884 B  (3.8 KB)
    volatile (memory/profile/timestamp) :    2,526 B  (2.5 KB)

Skill 本文は 166 バイトでしたが、常時入った索引コストは 68 バイトでした。長い手順を Memory へ貼るより、短い説明だけを索引へ出し、本文を必要時に読むほうが扱いやすいです。

私なら、追加前と追加後でhermes prompt-sizeを取り、増え方を確認します。人格や記憶を増やす判断を、ファイル数ではなく毎回の入力バイトで見られます。

混ざりやすい例

症状原因直し方
関係のない会話でも長い手順を読む作業手順をMemoryへ保存しています手順をSkillへ移し、Memoryには安定した事実だけを残します
口調がセッションごとに揺れます人格を特定のSkillだけへ書いています全体で守る姿勢をSOUL.mdへ移します
Skillを開かないと利用者の好みが消えます好みをSkillへ置いていますUSER.mdへ短く保存します
Memoryを直した直後も古い内容で答えますセッション開始時のスナップショットを使っています新しいセッションで読み直します
同じ規則が互いに食い違いますSOUL.md、Memory、Skillへ重複しています情報の所有先を1か所に決めます
入力が大きくなり続けます一時的な結果までMemoryへ残しています期限切れの記録を削り、手順はSkillへまとめます

残す基準は「次も必要か」

AI エージェントの蓄積は、何でも覚えさせることではありません。次のセッションでも必要な事実だけを Memory へ残し、全ての場面で守る姿勢をSOUL.mdへ置きます。繰り返す作業は Skill へ逃がします。

この分け方なら、人格を変えずに手順だけ更新できます。利用者の好みを保ったまま、古いデプロイ手順も交換できます。蓄積を増やすほど、保存先の境界が効いてきます。

一次情報

資料確認した内容
Persistent MemoryMEMORY.md、USER.md、文字数上限、固定スナップショット
Skills SystemProgressive Disclosure、Skillの配置と形式
Prompt Assemblystable、context、volatileの順序とSOUL.mdの扱い
Tips & Best PracticesMemoryは事実、Skillは手順という使い分け
Hermes Agent GitHubソースコードとリリース元
この記事をシェア
hibana
この記事を書いた人
hibana

技術ブログを運営しています。日々の学びや発見を発信中。

関連記事