Hermes Agentのcronをモデル変更から守る｜固定とdrift guardの実務

チャット用のモデルを替えただけで、29 本の定期処理まで同じモデルに切り替わる。無人運用では避けたい挙動です。料金だけでなく、応答形式や tool 呼び出しの癖も変わるからです。

Hermes Agent の cron には、この連鎖を止めるmodel_drift_guardがあります。2026 年 9 月 6 日に稼働中の環境を調べると、guard はtrueでした。一方、cron 全体のデフォルトモデルは未設定でした。私は重要な job ほど provider と model を明示し、guard を最後の防波堤にします。

前回は、正常時の配信を[SILENT]で抑え、実行台帳を別に確認しました。今回は実行より手前へ戻り、「どのモデルで走らせるか」を固定します。

前回から今回への差分

項目	前回完了時	今回完了後
通知	正常時だけ静音にします	変更しません
実行モデル	global defaultへ追従する余地があります	job単位かcron全体で固定します
モデル変更	定期処理への影響を個別に判断します	drift guardで意図しない継承を止めます
起動前検査	実行後の履歴を中心に見ます	provider、skill、deliveryを実行前に検査します
完了判定	runとdeliveryを分けます	さらに「どのmodelで走ったか」を加えます

すでに各 job へ model と provider を固定している場合は、「設定後の確認」まで飛ばせます。

なぜチャットと定期処理を分けるのか

対話では、新しいモデルを数分だけ試すことがあります。失敗しても画面を見ながら戻せます。cron は人が見ていない時間に起動します。日次 job なら、設定ミスが翌朝まで見つからないこともあります。

特に注意したいのは、次の変化です。

• 従量課金の provider へ切り替えます
• tool 呼び出しの形式が変わります
• 長い入力に対する応答量が変わります
• OAuth と API key で更新方式が変わります
• JSON や[SILENT]など、出力契約の守り方が変わります

モデル選びは品質調整だけではありません。無人処理では、費用と権限の境界でもあります。

modelを決める順序

Hermes Agent は、cron 実行時に次の順で model を解決します。

[cron jobが発火]
       │
       ▼
[job固有のmodel/providerはあるか]
       │
       ├─ ある ─────────────→ その組み合わせで実行
       │
       └─ ない
            │
            ▼
[cron.modelはあるか]
       │
       ├─ ある ─────────────→ cron全体の既定値で実行
       │
       └─ ない
            │
            ▼
[global defaultを確認]
       │
       ├─ 作成時と一致 ─────→ 実行
       │
       └─ 作成時から変化 ───→ drift guardが停止・一度だけ通知

優先順位は「job 固有の固定」「cron.model」「global default」です。job 固有の固定が最も狭く、影響範囲を読みやすくなります。

用語を揃える

用語	この手順での意味
global default	hermes modelで選ぶ、通常の対話にも使うデフォルトmodelです
per-job pin	1本のcron jobへ保存するmodelとproviderです
cron.model	固定のないcron jobに使う、cron全体のデフォルトmodelです
model drift	job作成時からglobal defaultのmodelやproviderが変わることです
drift guard	未固定jobが変更後のglobal defaultを黙って継承するのを止める機能です
preflight	推論前にprovider、skill、deliveryの準備を検査する処理です
blocked_config	事前検査に失敗し、推論を始めなかった状態です

現在の境界を読み取る

検証環境は Hermes Agent v0.21.0 でした。

hermes --version

実測した先頭行です。

Hermes Agent v0.21.0 (2026.8.31) · upstream baf7ceea

次に guard を確認しました。

hermes config get cron.model_drift_guard

実測結果は次のとおりです。

true

cron 全体の model も読みました。

hermes config get cron.model

この環境では値の出力がありませんでした。つまり、job 固有の固定がなければ global default が候補になります。空欄を「安全なデフォルト値」と考えない方がよいです。

固定はjob単位から始める

新しい job を作る CLI には、--modelと--providerがあります。2026 年 9 月 6 日の実機 help で、両方を確認しました。

hermes cron create --help

該当部分の実測結果です。

[--model MODEL] [--provider MODEL_PROVIDER]
--model MODEL         Pin this job to a specific inference model
--provider MODEL_PROVIDER
                      Inference provider paired with --model

作成時は、schedule と prompt に続けて両方を指定します。次は OpenAI Codex を使う場合の書式です。

hermes cron create "0 9 * * *" \
  "リポジトリのCI状態を確認し、日本語で要点を返す" \
  --name "morning-ci-check" \
  --model "gpt-5.6-sol" \
  --provider "openai-codex" \
  --workdir "$(pwd)"

利用できる provider は環境ごとに違います。別の契約を使う場合は、hermes modelで選択可能な組み合わせを確認し、その正確な値を指定します。

既存 job は作り直さず、editで固定できます。

hermes cron edit "morning-ci-check" \
  --model "gpt-5.6-sol" \
  --provider "openai-codex"

name でも参照できますが、同名 job が複数あると Hermes Agent は変更を拒否します。私は一覧から ID を読み、変更対象を 1 本に絞ります。

cron全体を同じmodelへそろえる場合

多数の job を同じ model で動かすなら、cron.modelをデフォルト値にできます。設定ファイルを直接編集せず、CLI を使います。

hermes config set cron.model "gpt-5.6-sol"
hermes config set cron.model_provider "openai-codex"

この方法は一括管理しやすい一方、用途ごとの差が見えにくくなります。軽い監視と長文調査を同じ model へ載せると、費用か品質のどちらかに無理が出ます。個人的には、重要な更新 job を per-job pin にし、残りへcron.modelを使う構成が扱いやすいです。

model_drift_guardは有効のままにします。

hermes config set cron.model_drift_guard true

guard をfalseにすると、未固定 job は global default の変更をすぐ継承します。定期処理で意図的に追従させたい場合を除き、無効化する理由は多くありません。

preflightは推論前に止める

model を固定しても、provider の認証情報が切れていれば実行できません。Hermes Agent の preflight は、推論を始める前に次を検査します。

• provider の認証情報を解決できるか
• job へ付けた skill が実行可能か
• delivery target が存在し、認証済みか

失敗するとlast_statusはblocked_configになります。警告は一度だけ届き、LLM 呼び出しは発生しません。壊れた job が毎回 token を消費する事態を避けられます。

preflight を確認するときも、設定ファイルを直接触りません。

hermes config get cron.preflight

値が未設定なら、公式仕様のデフォルト値が有効です。明示する場合は次を使います。

hermes config set cron.preflight true

fallback provider を使う job では、primary key だけを見て事前に止めると fallback 経路を潰します。そのため公式仕様は、fallback chain がある場合に provider key 検査を省きます。ここは「検査漏れ」ではなく、代替経路を残す設計です。

設定後の確認

設定値だけでなく、gateway と scheduler も確認します。

hermes cron status

2026 年 9 月 6 日の実測結果です。

✓ Gateway is running — cron jobs will fire automatically
Ticker heartbeat: 31s ago
29 active job(s)
Next run: 2026-09-06T08:30:00+09:00

Gateway is runningだけでは足りません。Heartbeat が更新され、次回時刻が未来を指していることも見ます。

続いて一覧を読みます。

hermes cron list

対象 job のName、Schedule、Skills、Workdir、Last runを照合します。model 固定を追加した場合は、その job へ意図した値が保存されたことも確認します。別の job まで変わっていないことが重要です。

最後に履歴を見ます。

read -r -p '確認するjob ID: ' job_id
hermes cron runs "$job_id" --limit 5

job_idには、直前の一覧で確認した対象の ID を入力します。

変更直後に手動実行する場合は、外部更新を伴わない job に限定します。投稿、公開、課金 API を含む job では、確認のための再実行が二重処理になります。次の定刻を待ち、台帳と出力を照合する方が安全です。

よくあるエラー

症状	原因	確認と修正
global modelを替えた後、jobが走りません	未固定jobをdrift guardが止めています	jobへmodel/providerを固定するか、global defaultを元へ戻します
毎回同じ警告が来ません	drift警告とpreflight警告は同じ問題を繰り返し通知しません	hermes cron listで状態を確認します
modelを指定したのに認証で止まります	providerの指定違いか認証情報の期限切れです	modelとproviderの組み合わせ、OAuth更新、API key解決を確認します
skill付きjobがblocked_configになります	skillのcommand、環境変数、credential fileが不足しています	skill readinessを直して次回runを待ちます
jobを直したのにgatewayの挙動が古いままです	更新後のprocessが古いmoduleを保持しています	hermes cron statusとgatewayの再起動要否を確認します
同名jobをeditできません	nameが重複しています	hermes cron listから正確なjob IDを使います
設定確認のつもりで更新が二重になりました	hermes cron runが実処理を予約しました	読み取りはlist、status、runsで済ませます

私なら三段で止める

第一段は per-job pin です。公開や外部投稿など、結果を戻せない job へ使います。第二段はcron.modelです。要約や調査など、同じ性質の job 群をまとめます。第三段に drift guard を残し、未固定 job の見落としを止めます。

さらに preflight を有効にし、認証情報、skill、delivery の不足を推論前に検出します。この構成なら、チャットで新しい model を試しても、夜間 job は勝手に追従しません。

cron は「時刻になったら prompt を送る」だけの機能ではありません。model、provider、tool、workdir、delivery まで含む実行契約です。無人化を増やすほど、便利なデフォルト値より明示した境界を選びます。

一次情報

出典	確認した内容
Hermes Agent Scheduled Tasks	model解決順、per-job pin、drift guard、preflight、CLI、実行履歴
Hermes Agent Configuring Models	provider と model の設定方法、認証方式
Hermes Agent Security	credential管理とfile write safety
Hermes Agent GitHub repository	公開sourceとrelease情報