Hermes Agentのbackground reviewを本体モデルから分離する｜費用・通知・書き込み承認を別々のつまみにする

2026 年 9 月 3 日、本番で使っている Hermes Agent v0.20.6（2026.8.27 版）の設定を読みました。auxiliary.background_reviewは enabled true、provider auto、model は空、timeout は 120 でした。display.memory_notificationsは on、memory.write_approvalは false でした。

この組み合わせの意味は単純です。応答後の記憶整理が起動すると、本体と同じ chat model で走ります。書き込みは承認なしで反映され、通知は標準の表示だけです。処理の存在、費用、書き込みへの同意という別々の関心事が、実質 1 つの初期値に束ねられています。

私は、この 3 つを別のつまみへ戻します。今日は本番を変更せず、隔離したHERMES_HOMEで設定の解決だけを確認しました。

前回から今回への差分

朝のHermes AgentをGit worktreeで分離するでは、並列編集の境界を Git の worktree で分けました。今回は、turn 後に自動で走る記憶処理の境界を分けます。対象はファイルではなく、モデル費用と記憶への書き込みです。

前回完了時	今回完了後
エージェントごとの編集場所をworktreeで分けました	turn後のreviewを本体モデルから分離する設定を確認しました
未commit変更の交差を止めました	費用、通知、書き込み承認を別々の設定キーで制御できます
本番の変更はbranchのdiffで追えました	記憶の変更を/memory pendingの承認待ちで追う手順を確認しました

すでにauxiliary.background_review.modelを指定済みなら、「止める・黙らせる・承認するは別のつまみ」まで飛ばせます。設定値の分離だけを知りたい場合は、「隔離 HERMES_HOME で設定解決だけを試す」から読めます。

なぜ初期値のまま放置しないのか

Hermes Agent の Persistent Memory は、応答後に background review を起動できます。この review は会話を読み返し、記憶へ残す内容を抽出します。公式ドキュメントによると、デフォルトではこの処理も main chat model を使います。

つまり、本体に高価なモデルを選ぶほど、目に見えない裏の処理も同じ単価で動きます。費用を意識して本体モデルを選んでも、その判断は裏側へ届いていません。

もう 1 つの問題は同意です。write approval が false のままだと、review が抽出した内容はそのまま記憶へ書き込まれます。通知を on にしていても、それは書き込み後の報告です。「何が書かれるかを先に見る」機会がありません。

公式ドキュメントは、review を小型モデルへ逃がす利点を「3〜5 倍安い」と説明しています。これは公式の説明であり、当環境の実測ではありません。私はまだ費用を測っていないため、この記事では金額や削減率を書きません。それでも、review の単価と本体の単価を別々に選べる状態には価値があります。

分離には品質面の差もあります。別モデルを指定した review は、全 transcript ではなく compact digest を読みます。直近 turn は原文のまま、古い部分は要約です。細部まで拾わせたい場面では、この差を理解したうえで選びます。

用語表

用語	ここでの意味
post-turn background review	turn終了後にHermesが自動でforkする記憶整理の処理です
auxiliary.background_review	このreviewのenabled、provider、model、timeoutを持つ設定群です
provider: auto	providerを自動選択する初期値です。modelが空なら本体のchat modelで動きます
compact digest	別モデル指定時にreviewへ渡す短縮版の会話です。直近turnは原文、古い部分は要約です
/refine	記憶整理を手動で起動するコマンドです。自動forkを止めても使えます
display.memory_notifications	記憶更新の表示量です。off、on、verboseの3段階です
memory.write_approval	trueで書き込みを保留し、承認するまで記憶へ反映しない設定です
HERMES_HOME	設定と記憶の置き場所です。差し替えると本番と別の隔離環境を作れます

post-turn reviewの流れ

turnの応答が完了
   │
   ▼ auxiliary.background_review.enabled: true なら自動fork
post-turn background review
   │
   ├─ model未指定: 本体のchat modelが全transcriptを読む
   └─ model指定あり: 指定モデルがcompact digestを読む
   │
   ▼ 記憶へ残す内容を抽出
memory.write_approval
   ├─ false: そのまま書き込み
   └─ true: stageへ保留
        └─ /memory pending → /memory approve / /memory reject
   │
   ▼
display.memory_notifications (off / on / verbose)
   └─ 表示量だけを変え、reviewと書き込みは止めない

この図の 3 段は独立しています。fork を止める、表示を変える、書き込みを保留する。それぞれ別のキーです。

まず本番の現在値を読む

設定操作はconfig.yamlの手編集ではなく、公式のhermes configを使います。読み取りは 3 つのキーで足ります。

hermes config get auxiliary.background_review
hermes config get display.memory_notifications
hermes config get memory.write_approval

私の本番では、冒頭に書いたとおり enabled true、provider auto、model 空、timeout 120、通知 on、write approval false でした。これは設定の読み取りであり、費用の測定ではありません。ここで大事なのは、model が空という 1 点です。空のままなら、review の単価は本体モデルと連動し続けます。

隔離HERMES_HOMEで設定解決だけを試す

本番のHERMES_HOMEへいきなり書き込む必要はありません。各コマンドだけに検証用の環境変数を渡します。端末全体の設定を変えないため、後の本番操作へ検証先が残りません。

mkdir -p /tmp/hermes-review-lab

HERMES_HOME=/tmp/hermes-review-lab hermes config set auxiliary.background_review.enabled true
HERMES_HOME=/tmp/hermes-review-lab hermes config set auxiliary.background_review.provider openrouter
HERMES_HOME=/tmp/hermes-review-lab hermes config set auxiliary.background_review.model google/gemini-3-flash-preview
HERMES_HOME=/tmp/hermes-review-lab hermes config set display.memory_notifications verbose
HERMES_HOME=/tmp/hermes-review-lab hermes config set memory.write_approval true

2026 年 9 月 3 日の隔離環境では、5 行すべてが次の形式で成功しました。

✓ Set auxiliary.background_review.enabled = True in /tmp/hermes-review-lab/config.yaml
✓ Set auxiliary.background_review.provider = openrouter in /tmp/hermes-review-lab/config.yaml
✓ Set auxiliary.background_review.model = google/gemini-3-flash-preview in /tmp/hermes-review-lab/config.yaml
✓ Set display.memory_notifications = verbose in /tmp/hermes-review-lab/config.yaml
✓ Set memory.write_approval = True in /tmp/hermes-review-lab/config.yaml

続けて同じ環境で読み戻します。

HERMES_HOME=/tmp/hermes-review-lab hermes config get auxiliary.background_review
HERMES_HOME=/tmp/hermes-review-lab hermes config get display.memory_notifications
HERMES_HOME=/tmp/hermes-review-lab hermes config get memory.write_approval

結果は、background review が enabled true、provider openrouter、model google/gemini-3-flash-preview、通知が verbose、write approval が true と解決しました。書いた値がそのまま返るので、キー名の打ち間違いをここで潰せます。

最後にHERMES_HOME=/tmp/hermes-review-lab hermes config checkでも同じ検証先を指定します。2026 年 9 月 3 日の空環境では、「Config version 0 → 39 (update available)」と、多数の optional secret 不足が表示されました。これは background review の設定キーが失敗したという意味ではありません。空のHERMES_HOMEには secret が 1 つも無い、という指摘です。

なお、この隔離環境では設定の解決までを確認しました。openrouter provider での実 API 呼び出しは、この検証には含めていません。

本番へ適用する順番を決める

隔離環境で解決を確認できたら、本番への適用は 3 つの判断に分かれます。この記事の作業では、本番の値をまだ変更していません。

1 つ目は費用です。review を分離するなら、auxiliary.background_review.providerとmodelを本番でも指定します。OpenRouter の API キーが必要になりますが、値をconfig.yamlへ直書きしません。hermes config setは secret を.env相当へ、非 secret の設定をconfig.yamlへ自動で振り分けます。キーの登録もこの経路に任せ、ファイルの手編集を避けます。

2 つ目は品質です。compact digest で足りる会話が大半なら分離します。/refineは同じ review を手動で起動するため、別モデルの設定があれば digest を使います。細部を重視する場合は、別モデルの指定を外して本体モデルを使う設定へ戻し、再起動したセッションで確認します。

3 つ目は同意です。memory.write_approvalを true にすると、gateway 経由と background review の書き込みが stage へ保留されます。運用は 3 コマンドです。

hermes  # セッション内で以下を使います
/memory pending
/memory approve <id>
/memory reject <id>

保留した書き込みは/memory pendingで一覧し、id 単位で承認または却下します。承認の手間は増えますが、記憶の変更履歴を人が読む地点を 1 つ確保できます。

止める・黙らせる・承認するは別のつまみ

3 つの設定は名前が似た文脈に置かれているため、混同しやすいです。効果は重なりません。

auxiliary.background_review.enabled: falseは、自動の post-turn fork だけを止めます。記憶機能そのものは残り、手動の/refineは引き続き使えます。「自動処理は要らないが、節目で自分が整理する」運用に向きます。

display.memory_notifications: offは、表示だけを消します。review は走り続け、書き込みも止まりません。静かな画面が欲しいだけなら off で足ります。書き込みを止めたつもりで off にすると、記憶は黙って増え続けます。

memory.write_approval: trueは、書き込みを保留します。review の実行も通知も変えません。同意の位置を書き込み前へ移す、唯一の設定です。

私の並べ方はこうです。費用は provider と model、静けさは notifications、同意は write approval。どの不満をどのキーで解決するかを分けて考えると、enabled: false という一番強い手段を安易に選ばずに済みます。

よくあるエラー

症状	原因	対処
hermes config checkが大量の不足を出します	新規の隔離環境にsecretが無いだけです	background review設定の失敗ではありません。本番で使うsecretだけを登録します
通知をoffにしたのに記憶が増え続けます	notificationsは表示だけの制御です	書き込みを止めたい場合はwrite approvalを有効化するか、enabledをfalseにします
enabledをfalseにすると記憶整理が全滅すると誤解します	止まるのは自動forkだけです	手動の/refineで必要な時だけ整理を起動します
別モデルのreviewが古い話題の細部を落とします	別モデルはcompact digestを読み、手動の/refineでも同じです	model指定を外して本体モデルを使う設定へ戻し、新しいセッションで確認します
write approval有効後に書き込みが消えたように見えます	反映ではなくstageへの保留です	/memory pendingで一覧し、approveまたはrejectで処理します
config.yamlの手編集で設定とsecretが混ざります	公式はCLI経由の設定を案内しています	hermes config setでやり直します。secretは.env相当へ自動で振り分けられます

一次情報

資料	確認した内容
Hermes Agent公式ドキュメント: Persistent Memory	post-turn reviewのデフォルトモデル、auxiliary.background_reviewによる分離、compact digest、/refine、通知3段階、write approvalと/memory pending系コマンド
Hermes Agent公式ドキュメント: Configuration	hermes config get / set / unset / checkの操作、secretと非secret設定の自動振り分け
Hermes Agent GitHub	2026年9月3日時点の実機バージョンv0.20.6（2026.8.27版）の参照元
background reviewの公開実装	手動のrefineでも、別モデルを使う場合はdigestを渡す処理