Hermes Agentの過去セッションを名前で引き継ぐ｜list・rename・resumeを試す

ターミナルを 2 枚開いたままhermes -cを実行すると、どの会話へ戻るのでしょうか。2026 年 9 月 8 日、私は先に workspace を指定して候補を探しました。実行結果はNo sessions found.です。何も見つからない結果でも、別の会話を推測で再開するより安全です。

Hermes Agent は、同じターミナルで続ける場合の手掛かりを持っています。ただし、端末を閉じた後や複数のリポジトリを往復する運用では、「直近」だけに任せない方が確実です。候補を workspace で絞り、タイトルか ID を確認してから再開します。

前回完了時から今回完了後まで

前回の「Hermes Agentの記憶・人格・スキルを混ぜずに育てる」では、常に必要な事実を Memory へ置き、作業手順を Skill へ分けました。今回は、どちらにも残すほどではない過去の会話を、必要な時だけ見つけて再開します。

時点	状態
前回完了時	人格、記憶、スキルの保存先を分けられます
今回開始時	過去の会話へ戻るとき、直近の1件に頼りがちです
今回完了後	workspace、タイトル、IDを照合して対象だけを再開できます

Memory の整理が目的なら前回へ進めます。再開したいセッション ID が分かっている場合は、「ID を指定して再開する」まで飛ばせます。

なぜ再開より候補確認が先なのか

hermes -cは便利です。公式 docs によると、同じターミナルでは breadcrumb を使い、そのターミナルのセッションを優先します。手掛かりがない場合や 30 日を超えて古い場合は、直近のセッションへ戻ります。

普段の 1 枚だけなら、この動きで困りません。複数のターミナル、tmux の pane、複数の Git repository を使うと、「直近」と「今続けたい仕事」にずれが生じます。別案件の会話を開いたまま作業すると、前提だけでなく working directory まで取り違えるおそれがあります。

私は、再開操作を候補確認と対象指定に分けます。

保存済みsession
  └─ workspaceで絞る
       ├─ 0件 → 再開せず、sourceやworkspaceを見直す
       └─ 候補あり → titleとIDを照合
                         ├─ 名前が曖昧 → rename
                         └─ 対象を特定 → resume

削除や prune は、この確認経路へ入れません。検索条件を間違えても履歴を失わない、読み取り中心の手順にします。

用語を揃える

用語	ここでの意味
セッション	1つの会話と、そのmessage historyやmodel情報をまとめた記録です
セッション ID	保存済みセッションを一意に指定する識別子です
title	人がセッションを探し、名前で再開するための表示名です
workspace	セッションが属するGit repositoryのroot、または作業directoryです
breadcrumb	同じterminalで前回のセッションを見つけるための小さな手掛かりです
resume	保存済みの会話履歴を読み込み、続きから対話する操作です
セッション search	過去の会話から特定の発言をオンデマンドで探す機能です
Memory	毎回のセッションで必要な少数の事実を、常時contextへ入れる仕組みです

手元のCLIで使える操作を確認する

今回の実機はHermes Agent v0.21.0 (2026.8.31)でした。最初に version と help を読みます。

hermes --version
hermes sessions --help
hermes sessions list --help

期待するのは固定された文面ではありません。sessionsの subcommand にlistとrenameがあり、listの option に--workspace、--limit、--sourceが出ることを確認します。

実機のhermes sessions --helpには、list、export、delete、prune、archive、optimize、repair、stats、rename、pin、browse、importなどが表示されました。本稿で使うのは読み取り用のlistと、対象を確認した後のrenameだけです。

version 確認が済んでおり、--workspaceも help に出る環境では、この章を飛ばせます。

workspaceで候補を絞る

<project-name>は、実際の repository 名かパスへ置き換える placeholder です。

hermes sessions list --workspace <project-name> --limit 20

期待出力では、title、preview、last active、ID を確認します。title がないセッションでは、preview、source、ID を中心に表示されます。表示形式はセッションの状態や CLI 版で変わるため、列を固定した script として parse しません。

今回、実在する repository 名で 3 件まで探した結果は次の通りでした。

No sessions found.

これは CLI の失敗ではありません。指定した workspace metadata に一致するセッションがなかった、という読み取り結果です。ここでhermes -cへ切り替えて別の直近セッションを開くと、絞り込みの意味がなくなります。

0 件の場合は、次の順で条件を見直します。

1. repository の basename ではなく、実パスの一部を指定します。
2. --source cliなど、会話を始めた入口を確認します。
3. --limitを増やす前に、探している会話が本当にその workspace で始まったか確認します。

3 つを試しても特定できなければ、再開せずに新しいセッションを始めます。誤った履歴を引き継ぐより、必要な前提を短く渡し直す方が安全です。

セッションへ名前を付ける

候補が見つかっても、title が空欄だったり似た名前が並んだりすると、翌週には区別できません。<session_id>は一覧で確認した実値へ置き換えます。

hermes sessions rename <session_id> "payments-api-investigation"

期待する結果は、対象 ID の title が指定した名前へ変わることです。変更後は、同じ一覧をもう一度読みます。

hermes sessions list --workspace <project-name> --limit 20

この再確認では、指定した ID と新しい title が同じ行にあるか見ます。rename の終了 code だけで完了とせず、対象を読み返します。

会話中なら、次の slash command でも title を付けられます。

/title payments-api-investigation

title は 100 文字以内で一意です。制御文字、zero-width 文字、RTL override は除去されます。私は日付より、repository と調査対象が分かる短い名前を付けます。日付は last active で確認できるためです。

IDを指定して再開する

候補を特定できたら、一覧に出た ID をそのまま使います。

hermes --resume <session_id>

<session_id>は例示用の文字列です。架空の ID を実行済みの値として使いません。期待する動作は、指定したセッションの履歴が読み込まれ、前回の会話 recap が表示されることです。

Hermes Agent は、resume 時に記録済みの working directory へ戻ります。画面に workspace を復元した表示が出たら、作業を続ける前に次も確認します。

pwd
git status --short --branch

pwdは想定した project root、git statusは想定した branch と差分を示す必要があります。dirty な別 branch へ戻った場合は、そのまま編集を始めません。

会話だけを戻し、現在の directory を維持したい場合は明示します。

hermes --resume <session_id> --no-restore-cwd

この option は workspace の復元を止めます。会話の前提と現在地がずれるため、使用後のpwd確認は省きません。

名前とdirectoryから再開する

名前が一意なら、ID を覚える必要はありません。

hermes -c "payments-api-investigation"

圧縮で同じ会話の lineage が増えた場合、名前による再開は最新の continuation を選びます。my project、my project #2、my project #3のように分かれた履歴を、人が毎回追い直さずに済みます。

特定 directory の最新セッションへ戻る方法もあります。

hermes --resume latest --in ./my-project

--inは最初に directory を指定し、その workspace に属する最新セッションを選びます。複数 repo を往復する場合は、引数なしの-cより意図が明確です。

ID を一覧から貼り付ける運用ができていれば、この章は飛ばせます。自動化では「latest」の意味が時間で変わるため、対象を固定したい処理では ID を優先します。

Memory、セッション search、resumeを分ける

3 つは、過去を扱う点だけが共通しています。入出力と寿命が違います。

機能	使う場面	contextへの入り方
Memory	好み、環境、長く守る規約を毎回使います	セッション開始時に常時入ります
セッション search	先週の判断や発言を必要な時だけ探します	検索結果だけをその場で読みます
resume	1つの会話を履歴ごと続けます	選んだセッションの会話を読み込みます

公式 docs では、Memory と User Profile の合計は小さく制限されています。一方、セッション history は SQLite へ蓄積され、FTS5 で検索できます。過去の細かな調査結果を全部 Memory へ詰める必要はありません。

「以前、公開条件をどう決めたか」だけを探すならセッション search が合います。その会話の作業を続けるなら resume を使います。毎回必ず守る公開条件なら Memory や project context へ置きます。

この分担にすると、思い出したい会話の量が増えても、毎 turn の prompt を同じ割合で太らせずに済みます。

exportする前に秘密を落とす

再開前の確認だけなら export は不要です。監査や共有で会話を file へ出す場合は、範囲と redaction を明示します。

hermes sessions export session.jsonl \
  --session-id <session_id> \
  --redact

期待するのは、指定した 1 件が JSONL へ出力されることです。--redactは API key、token、credential の除去に使います。それでも、共有前には生成 file を目視します。redaction を指定した事実だけで、公開可能とは判断しません。

候補だけを確かめる filter 操作では、--dry-runを使える場合があります。手元のexport --helpに option があることを確認してから使います。

hermes sessions export session.jsonl \
  --cwd /path/to/project \
  --dry-run

本稿では export file を作りません。再開対象の確認に、履歴の複製は必要ないためです。

よくあるエラー

表示・状況	主な原因	対応
No sessions found.	workspaceまたはsourceに一致するセッションがありません	pathとsourceを見直し、推測で直近セッションを開きません
想定と違う会話が開く	引数なしの-cがterminalのbreadcrumbか最新セッションを選びました	一覧へ戻り、IDまたは明示titleで再開します
titleで再開できない	titleの誤記、または対象をrenameしていません	IDで一覧を照合し、必要ならrenameします
resume後に別directoryへ移る	保存済みworking directoryが復元されました	pwdで確認し、維持したい場合は--no-restore-cwdを使います
workspaceで絞れない	セッションに期待したworkspace metadataがありません	sourceと開始場所を確認し、新規セッションも選択肢にします
exportへ秘密が残る不安がある	会話にはtool出力やcredentialが含まれ得ます	--redactを付け、共有前にfileを目視します
docsのoptionがhelpにない	導入済みCLIと公式docsの版が違います	手元の--helpを優先し、未確認のoptionを実行しません

日常運用の最小手順

毎回すべての機能を使う必要はありません。私は次の 4 操作へ絞ります。

# 1. 候補をproject単位で見る
hermes sessions list --workspace <project-name> --limit 20

# 2. 必要な場合だけ、確認済みIDへ名前を付ける
hermes sessions rename <session_id> "<project-and-purpose>"

# 3. 対象をIDで再開する
hermes --resume <session_id>

# 4. directoryとbranchを確認する
pwd
git status --short --branch

1 件目で 0 件なら停止します。2 件以上なら preview、last active、ID を照合します。resume の成否ではなく、再開後の working directory と branch まで確認して完了です。

出典

資料	確認した内容
Hermes Agent Sessions	SQLite保存、terminal別continue、workspace filter、title、resume、export、redaction
Hermes Agent Persistent Memory	Memoryとセッション searchの役割、容量、FTS5による過去会話検索
NousResearch/hermes-agent	Hermes Agentの公式repository

公式 docs は更新されます。実行前には、手元のhermes --versionと各 subcommand の--helpも照合します。

過去の会話が残っていることと、正しい会話へ戻れることは別です。workspace で候補を減らし、名前か ID で対象を固定し、復元後の directory を読む。この順番なら、「直近」という便利な省略を、複数案件の事故原因にせず使えます。