cronとGatewayの基礎—止まっても気づける自動化へ
cronへジョブを登録しただけでは、自動化は完成しません。ジョブを起動するプロセスが止まれば、予定だけが残り、処理は実行されません。Hermes AgentではローカルGatewayがスケジュール実行を支えます。
四つの状態を別々に見る
1. Job defined：ジョブ定義が存在する
2. Job active：無効化されていない
3. Scheduler alive：Gatewayなど実行基盤が動いている
4. Last run succeeded：直近の実行が成功した
「active」と「次回動く」は同義ではありません。直近成功があっても、その後Gatewayが止まれば次回は実行されません。
冪等性を持たせる
同じ対象日で二回実行しても、二重投稿や二重登録が起きない処理を冪等と呼びます。
- 日次ノート：同じ自動生成範囲を更新する
- メール通知：Message-IDで送信済みを除外する
- API登録：外部IDまたは一意キーで重複を確認する
- WordPress：同じslugの下書きがあれば新規作成しない
cronは遅延、再実行、手動復旧が起こる前提で設計します。
リトライを分類する
一時的な通信障害や429・503は待って再試行できます。一方、認証失敗、権限不足、入力不正は何度繰り返しても直りません。
“`text
一時障害 → 指数バックオフ + ジッター + 上限
認証失敗 → 停止して再認証を通知
入力不正 → 対象を隔離して人へ通知
外部書き込み不明 → 再試行前に実行済みか照会
“`
タイムアウト後にAPIが実は成功していた場合、無条件再試行で二重登録になります。外部状態を確認してから再実行します。
監視する指標
- 最終成功時刻
- 直近の所要時間
- 連続失敗回数
- 対象件数と処理件数
- 省略・警告件数
- 次回予定時刻
- Gateway稼働状態
「失敗したらDiscordへ通知」だけでは、Discord接続そのものが失敗した時に気づけません。重要な自動化では、ローカルログ、別サービス、監視ツールなど複数の観測点を検討します。
まとめ
信頼できるcronは、予定時刻に動く処理ではなく、止まった時に分かり、安全に再実行できる処理です。ジョブ、実行基盤、直近成功、次回予定を別々に確認します。
参考にした一次情報
- [Hermes Agent Cron Scheduling](https://hermes-agent.nousresearch.com/docs/user-guide/features/cron)
- [Hermes Agent Security—cron_mode](https://hermes-agent.nousresearch.com/docs/user-guide/security/)
- [AWS Architecture Blog—Exponential Backoff and Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)