Hermes Agentのcronで思考量をジョブ別に固定する

2026年9月18日

約13分で読めます

毎朝の差分確認に、深い推論は要りません。一方、週次の設計レビューを同じ思考量で走らせると、判断の浅さが気になります。Hermes Agent では、cron job ごとにreasoning effortを固定できます。

2026 年 9 月 18 日、Hermes Agent v0.21.0 で一時環境を作りました。minimalで job を登録し、highへの変更と固定解除まで確認しています。本番の cron table や API key には触れていません。

前回から変えること

前回の「Hermes AgentのBot Modeをprofile分離から理解する」では、profile ごとに役割、記憶、skills、cron jobs を分けました。今回は、1 つの profile が持つ複数の定期処理へ、仕事に合う思考量を割り当てます。

時点	できること
前回完了時	profileごとにBotと定期処理の所有範囲を分けられます
今回完了後	軽い確認と重い分析で、modelを変えずに思考量だけを分けられます

作成コマンドだけ必要なら「一時環境で job を作る」まで飛ばせます。既存 job の変更だけなら「high へ変更する」から読めます。設計の基準だけ欲しい場合は「仕事の重さで固定値を選ぶ」へ進めます。

なぜmodelとは別に思考量を固定するのか

model の選択と、1 回の仕事に使う思考量は別の判断です。同じ model でも、ファイルが届いたかを見るだけの処理と、複数資料から矛盾を探す処理では必要な計算量が違います。

すべてをhighにすると、軽い job にも待ち時間と費用が乗ります。すべてをminimalにすると、レビューで検討が足りなくなる恐れもあります。私は、定期処理の頻度では判断しません。失敗時の影響と判断の複雑さで固定値を決めます。

Hermes Agent の cron では、job に固定した値が global 設定より優先されます。固定値がなければ、agent.reasoning_effortや model 別の override へ戻ります。model と provider の pin とは独立しているため、推論経路を変えずに思考量だけを調整できます。

用語を揃える

用語	この回での意味
cron job	指定時刻や間隔で動くHermes Agentの定期処理です
reasoning effort	modelへ求める思考量です。`none`から`ultra`まで指定できます
per-job pin	1つのjobだけに固定したmodel、provider、思考量です
global設定	jobに固定値がないときに参照する共通設定です
clamp	modelが未対応の強さを指定したとき、provider側が対応範囲へ丸める動きです
no-agent job	LLMを呼ばず、scriptのstdoutだけを配るjobです

設定の優先順

[cron jobが起動]
       │
       ├─ reasoning_effortをjobに固定済み
       │       └─ その値を使用
       │
       └─ 固定なし
               ├─ model別reasoning override
               └─ global reasoning effort

[providerへrequest]
       │
       ├─ 指定値に対応 ──→ その強さで実行
       └─ 未対応 ───────→ providerが対応範囲へ丸めるか省略

none、minimal、low、medium、high、xhigh、max、ultraを指定できます。ただし、文字列の受理と、model による同じ強さの利用は別です。未対応の段階は provider 側で丸められます。

no-agent job には効果がありません。LLM call 自体がないためです。

CLIが対応しているか確認する

まず、導入済みの版と flag を確認しました。

hermes --version
hermes cron create --help
hermes cron edit --help

版の出力は次のとおりでした。端末固有の install path は省いています。

Hermes Agent v0.21.0 (2026.8.31) · upstream baf7ceea · local 1068df60 (+1 carried commit)
Python: 3.11.15
OpenAI SDK: 2.24.0

createとeditの両方に同じ flag がありました。

--reasoning-effort REASONING_EFFORT
  Pin this job's reasoning (thinking) effort: none,
  minimal, low, medium, high, xhigh, max, or ultra.

既存環境で flag が表示されない場合は、記事のコマンドをそのまま実行しません。先にhermes updateの対象か、公式の CLI reference で現行仕様を確認します。

一時環境でjobを作る

本番のHERMES_HOMEを使わず、検証専用 directory を作ります。同名 directory が残っていたら止めます。

LAB=/tmp/hermes-cron-reasoning-lab
[ ! -e "$LAB" ] || {
  printf 'already exists: %s\n' "$LAB"
  exit 1
}
mkdir -p "$LAB"
touch "$LAB/.cron-reasoning-marker"
export HERMES_HOME="$LAB"

翌日の一度だけ動く job を作りました。実際には gateway を起動しないため、LLM call は発生しません。model と provider も検証用 job へ明示しました。

hermes cron create '2026-09-19T12:00:00+09:00' \
  '公開前の差分を読み、要点を3行で返す。' \
  --name 'draft-review-lab' \
  --deliver local \
  --provider openrouter \
  --model google/gemini-2.5-flash \
  --reasoning-effort minimal

実行結果です。

Created job: 29027417c1d4
  Name: draft-review-lab
  Schedule: once at 2026-09-19 12:00
  Next run: 2026-09-19T12:00:00+09:00
  ⚠  Gateway is not running — jobs won't fire automatically.

警告は作成失敗ではありません。一時環境で gateway を動かしていないことを示しています。今回は job 定義だけを検査するため、そのまま進めます。

保存された値を読み取り専用で確認しました。jobs.jsonを直接書き換えず、変更にはhermes cron editを使います。

python3 - <<'PY'
import json
from pathlib import Path

job = json.loads(
    Path("/tmp/hermes-cron-reasoning-lab/cron/jobs.json").read_text()
)["jobs"][0]
for key in ("name", "model", "provider", "reasoning_effort", "deliver"):
    print(f"{key}: {job.get(key)!r}")
PY

name: 'draft-review-lab'
model: 'google/gemini-2.5-flash'
provider: 'openrouter'
reasoning_effort: 'minimal'
deliver: 'local'

model、provider、思考量が別 field で保存されました。minimalは model 名の一部ではありません。

highへ変更する

既存 job は作り直さずに変更できます。検証では作成時に返った ID を使いました。

hermes cron edit 29027417c1d4 --reasoning-effort high

Updated job: 29027417c1d4
  Name: draft-review-lab
  Schedule: once at 2026-09-19 12:00
  Skills: none

CLI の更新結果には思考量が表示されません。そのため、保存値をもう一度読みます。

python3 - <<'PY'
import json
from pathlib import Path

job = json.loads(
    Path("/tmp/hermes-cron-reasoning-lab/cron/jobs.json").read_text()
)["jobs"][0]
print("reasoning_effort:", repr(job.get("reasoning_effort")))
PY

reasoning_effort: 'high'

変更は反映されました。表示が短いコマンドでは、終了 code だけでなく保存結果も確認します。

固定を外してglobal設定へ戻す

空文字を渡すと per-job pin を外せます。

hermes cron edit 29027417c1d4 --reasoning-effort ''

Updated job: 29027417c1d4
  Name: draft-review-lab
  Schedule: once at 2026-09-19 12:00
  Skills: none

同じ読み取りを実行すると、値はNoneでした。

reasoning_effort: None

minimalへ戻したわけではありません。job 固有の指定を外し、共通設定へ従う状態です。ここを曖昧にすると、global 設定を変更した日に思考量も変わります。

仕事の重さで固定値を選ぶ

私は次の目安から始めます。正解を固定する表ではなく、初期値を決めるための運用基準です。

仕事	初期値	理由
file到着確認、件数確認	`minimal`	判断が短く、失敗条件をscriptで検査できます
定型の要約、日次digest	`low`または`medium`	情報の取捨選択は必要ですが、長い検討は不要です
複数資料の比較、設計review	`high`	矛盾、前提、代替案を追う時間を確保します
scriptだけの監視	指定しない	`no-agent`ならLLMを呼びません

思考量を上げても、成果物検査は省けません。記事生成なら frontmatter、textlint、type check、build を model の外側で確認します。review job なら、対象件数、必須 section、出典 URL の有無を script で検査できます。

高い思考量を品質保証の代わりにしないことが大切です。highは考える量を増やしますが、正しい file を読んだことや、公開条件を満たしたことまでは保証しません。

model pinと一緒に考える

思考量だけ固定し、model を未固定にすると、model 側の変更によって実効値は変わる場合があります。反対に、model と provider を固定しても安心はできません。credential や利用上限までは保証されないためです。

無人 job では、次の 3 点を別々に決めます。

どこで考えるか   model + provider pin
どれだけ考えるか reasoning effort pin
何をもって完了か deterministic artifact gate

毎日公開物を作る job なら、3 つ目が最重要です。agent が「完了」と返しても、必要な file、状態、時刻、PR を外側で数えます。不足していれば run を失敗にします。

一時環境を片付ける

marker とパスを確認してから削除しました。

case "$LAB" in
  /tmp/hermes-cron-reasoning-lab)
    test -f "$LAB/.cron-reasoning-marker"
    ;;
  *)
    printf 'unexpected LAB path\n' >&2
    exit 1
    ;;
esac

rm -rf -- "$LAB"
unset HERMES_HOME
test ! -e "$LAB" && printf 'cleanup: OK\n'

cleanup: OK

よくあるエラー

症状	原因	対応
`unrecognized arguments: --reasoning-effort`	導入版がflagへ未対応です	`hermes --version`と公式CLI referenceを確認します
`ultra`を指定したのに期待ほど考えません	modelがその段階へ未対応です	providerが丸める前提で、対応するmodelと実行logを確認します
`edit`後の表示に思考量が出ません	更新結果のsummaryが短い仕様です	job定義を読み取り、`reasoning_effort`を確認します
固定解除後に思考量が変わりました	global設定へ戻ったためです	固定が必要ならjobへ値を再設定します
`no-agent` jobで変化がありません	LLM callがありません	思考量を設定せず、scriptの速度と終了codeを見ます
`high`でも成果物が欠けます	思考量と完了条件を混同しています	file数、状態、schema、buildを外側で検査します
一時jobが動きません	検証用gatewayを起動していません	定義検査だけなら正常です。実行試験ではgateway状態を確認します

固定値はjobの契約にする

思考量は、その場で気分よく上げる設定ではありません。定期処理が担う判断の重さを、job 定義へ残すための契約です。

軽い確認はminimal、設計 review はhighというように分けると、同じ model を使いながら費用と待ち時間を調整できます。私は model、思考量、完了条件を別々に固定します。最後の成果物検査だけは、どの強さを選んでも外しません。

公開一次情報

出典	確認した内容
Hermes Agent公式ドキュメント: Cron Jobs	per-job reasoning effort、指定値、優先関係、固定解除、no-agentへの非適用
Hermes Agent公式リファレンス: CLI Commands	`hermes cron create`と`hermes cron edit`の位置づけ
Hermes Agent GitHub repository	source codeとrelease元

この記事を書いた人

hibana

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