Hermes Agent の cron スケジューラは、エージェントの仕事の 3 番目の形だ——ターン単位のチャット、/goal ループの次に来る。cron では、エージェントはスケジュールに従って無人で走る。結果は好きなメッセージングプラットフォームへ届く——あるいは deliver=all で繋がっている全部に一気に届く（#21495）。
この記事では具体的なジョブを一つ組み立てる——朝の日報——そしてそのジョブを通じてスケジューラの実体を説明する。同じパターンが夜間バックアップ、週次セキュリティ監査、オンコール交代の通知、あるいはこれまで脆い bash + cron で配線していたあらゆる仕事を捌く。
作るもの
毎平日の朝 8 時に：
- 1.夜間のメールを読む（昨日午後 5 時以降のもの）
- 2.GitHub の通知（issue、PR レビュー、メンション）を拾う
- 3.今日のカレンダーから最初の 4 時間を確認する
- 4.3 つをまとめて 1 つの Telegram メッセージにする
重要なことがあれば詳細に。何もなければ一文：「夜は静かでした。11 時までは予定が薄い。」
ステップ 1：ジョブを定義する
hermes cron add がそれを案内してくれる。CLI が訊いてくる：名前、スケジュール、ジョブの説明（自然言語）、配信先。
$ hermes cron add
Name: daily-morning-report
Schedule (cron expression or natural language): 0 8 * * MON-FRI
Description: |
Read overnight email (since 5 PM yesterday).
Pull GitHub notifications via the github skill.
Check today's calendar via google-calendar for the first 4 hours.
Summarize all three into one Telegram message.
Be brief when nothing important happened.
Delivery: telegram
0 8 <em class="italic text-slate-200"> </em> MON-FRI は標準的な cron 構文だ：分 0、時 8、日 、月 、月曜から金曜。Hermes は cron 構文も「every weekday at 8 AM」のような緩い自然言語表現も両方受ける。
ステップ 2：朝 8 時に何が走るか
次の平日の朝 8 時、Hermes は隔離されたエージェントセッションを立ち上げる。中身は：
- •ジョブの説明を最初のユーザメッセージとして
- •エージェントが呼びたい skill（
email、github、google-calendar） - •最終応答を Telegram へ流す delivery hook
永続コンテキストもない、ユーザのキー入力もない。エージェントが説明を読み、skill を呼び、メッセージを下書きし、送信する。通常 15–30 秒で終わる。
出力は Hermes bot からの Telegram メッセージとして表示される。通常より時間がかかったりエラーに当たったりした場合は、同じチャネルにエラーメッセージも来る。
ステップ 3：deliver=all——全プラットフォームへ一斉配信
既定では配信は 1 つのプラットフォーム——cron add で指定したやつ——にだけ届く。報告を「自分が立ち寄るところ全てに届けたい」なら：
hermes cron edit daily-morning-report --deliver all
これでメッセージは接続済みの全メッセージングプラットフォームへ一気に届く——Telegram、Discord、Slack、WhatsApp、Signal、LINE、SimpleX、設定したものなんでも。v0.14.0 が cron 向けにプラットフォーム単位の配信を明示的に通した（#21495）。
役に立つ場面：自分がどのアプリを開いていてもこのメッセージを必ず目にしたい、というとき。
やりすぎな場面：朝に見るのは 1 つのプラットフォームだけ。それを 1 つ選べばいい。
ステップ 4：何がスケジュールされているか確認
hermes cron list
スケジュール済みのもの、次回実行時刻、前回実行のステータスを表示する。v0.14.0 はジョブ操作向けに名前ベースのルックアップを追加した（#26231）ので、ID ではなく名前でジョブを参照できる：
hermes cron logs daily-morning-report --last 5
hermes cron disable daily-morning-report
hermes cron run-now daily-morning-report # スケジュール外で即時発火
ジョブが落ちたとき
cron ジョブは自前のサンドボックスセッションで走る（バックエンドは対話的な Hermes と同じ——サンドボックスバックエンドの記事を参照）。skill 呼び出しが失敗すれば、エージェントはそのエラーを受け取り、リトライするか正直に報告する。
ジョブ全体がクラッシュした場合（エージェント自身がエラー終了）、Hermes が既定のメッセージングプラットフォームでエラーとログへのリンクを通知する。v0.13.0 のセッション持続性のおかげで、gateway の再起動は保留中の cron 配信を失わない——重複排除はアトミック claim ＋ 失敗時のロールバックでなされている（#23401）。
実用的なジョブのパターン
実際に走らせている人がいる例：
夜間バックアップ検証。 午前 3 時の cron：バックアップスナップショットを列挙し、今日の分が存在して空でないかを確認、なければ大声でアラート。deliver=all を付けておけば、何か壊れていれば起きた瞬間に気付く。
週次セキュリティ監査。 日曜午後 10 時の cron：依存性のアドバイザリを引き、lockfile の既知 CVE をスキャン、新規脆弱性をまとめる。v0.14.0 の supply-chain advisory チェッカ（#24220）が、自前スクリプトより綺麗にこれを支える。
オンコール交代。 金曜午後 5 時の cron：今週のページャを読み、翌週の担当に 1 段落の引き継ぎを書く。共有 Slack チャネルへ配信。
Watchers（v0.14.0 の skill、#21881）。RSS フィード、HTTP JSON エンドポイント、GitHub リポジトリの変更をポーリングし、変更があったときだけ通知する。cron と組むと「X が変わったら教えて」になる——驚くほど活用されていない自動化プリミティブのひとつだ。
ログはどこに
hermes cron logs daily-morning-report
既定では直近 10 回。各回がタイムスタンプ、所要時間、呼んだ skill、配信したもの、失敗があれば何が、を見せる。ログは ~/.hermes/cron/logs/ 配下に置かれ、自動で rotate する。
なぜ shell スクリプトより嬉しいか
同じ日報を bash スクリプト ＋ cron ＋ curl で Telegram ＋ ちょっとした LLM 呼び出しで書ける。多くの人が実際そうしてきた。
エージェントの上の cron が面白いのは：
- 1.ジョブの説明そのものが仕様だ。 メンテすべきコードがない。「最初の 4 時間」を「最初の 6 時間」に変えたい——説明を書き換えるだけ、再デプロイ不要。
- 2.skill が組み合わさる。 「ついでに Linear の新規チケットも見て」を加えるのは説明に一文。shell スクリプトなら新しい API クライアントを書くことになる。
- 3.配信が分離されている。
deliver=allのおかげで、5 つのチャットアプリ向けに 5 つの webhook を書く必要がない。gateway は既に 22 のプラットフォームを喋っている。 - 4.エラーがデバッグ可能だ。 ジョブが失敗したら、エージェントが「何を試したか、なぜ失敗したか」を英語（あるいは日本語）で教えてくれる。bash スクリプトが返すのは exit code 1。
これは「エージェントの cron が常に正解」という意味ではない——100% 決定的で 30 ms で終わる必要があるジョブには、shell スクリプトの方がやはり向く。だが「この時刻に少し頭を使う仕事をして、結果を教えて」という類の仕事には、cron-on-Hermes は道具箱で一番綺麗な工具だ。