夜中に動かした定期処理が止まり、朝になっても「失敗したのか、まだ動いているのか」が分からない。Hermes Agentを常駐AI作業員として使うと、精度より先にこの問題が効いてきます。
Hermes Agent v0.20.3は、2026年8月16日に公開された安定版です。公式リリースによると、v0.20.2以降の約125件のプルリクエストをまとめ、cronの自己復旧、古い実行権の整理、停止したジョブの再開、セッション引き継ぎ時のデータ欠落修正などが入りました。派手な新機能ではありません。ただ、AIに仕事を預けるなら、こういう修正のほうが効きます。
今回の変更で見るべき点
公式リリースには、cron scheduler self-heal、EMFILE recovery、stale-claim reconciliation、wedged-job re-armが明記されています。要するに、開けるファイル数の上限に達したり、実行中を示す古い状態が残ったり、ジョブが固まったりしたときに、定期処理を戻す仕組みが強化されました。
もう一つはセッション引き継ぎです。長時間の仕事では、担当するエージェントや接続先が途中で変わります。引き継ぎ時にデータが落ちると、次のエージェントは古い前提で作業を続けます。v0.20.3では、この欠落に関する修正も含まれています。
なお、今回のリリースノートは「詳細版」ではありません。開発元は、v0.20.0以降の変更を整理した詳しい説明をv0.21.0で公開するとしています。ここでは、公式リリースに書かれた範囲だけを扱います。
中小企業では「自動化率」より復旧方法を決める
定期処理を増やすと、人が触る回数は減ります。その代わり、止まったときの判断が難しくなる。請求書の整理、問い合わせの分類、記事公開、日次レポートなどは、二重実行すると困る仕事です。
私は、定期処理を作るときに次の4項目を先に決めます。
- 1回の実行を識別するID
- 処理中、完了、失敗の保存先
- 同じ仕事を再実行しても重複しない条件
- 人へ戻す期限と通知先
自己復旧機能があっても、この4項目は省けません。復旧は「もう一度動かす」だけでは足りず、どこまで終わったかを確認してから再開する必要があるからです。
たとえば記事公開なら、「本文を作った」「画像を登録した」「公開状態に変えた」を別々に記録します。途中で止まった場合、次の実行は未完了の工程だけを進めます。全部を最初からやり直すと、同じ記事や画像が増えます。問い合わせ返信でも同じで、下書き作成と外部送信を一つの処理にまとめないほうが安全です。
導入前に確認する3つの境界
最初に、定期処理を「自動で再開してよい仕事」と「人の確認が必要な仕事」に分けます。情報収集や下書き生成は前者に寄せやすい。一方、公開、送信、請求、削除は後者です。
次に、再試行の上限を決めます。無限に再開すると、外部APIの利用量やサーバー負荷が増え、同じ相手へ複数回送信する事故も起きます。回数だけでなく、経過時間でも打ち切る設計が現実的です。
最後に、正本の保存先を固定します。チャットの会話だけを引き継ぎ情報にすると、セッションが切れた瞬間に仕事の経緯が薄くなります。実行ID、対象、結果、次に行う処理をファイルやデータベースへ残し、次のエージェントはそこから再開します。
運用担当が見る画面も一つに絞ります。複数のログやチャットを探し回る状態では、復旧に時間がかかります。「いま動いている仕事」「確認待ち」「失敗した仕事」を同じ一覧で見られるだけでも、朝の確認はかなり軽くなります。
まず1本だけ試す
いきなり複数業務を常時運転にしないほうが安全です。毎朝の情報収集など、失敗しても顧客へ直接影響しない処理を1本選び、1週間動かします。見る数字は成功率、再試行回数、人が復旧に使った時間です。
自動化の価値は、動いた回数では測れません。止まったあと、誰が見ても同じ場所から戻せるか。Hermes Agent v0.20.3は、その地味で面倒な部分を前に進めたリリースです。
一次情報
確認日：2026年8月18日。機能名と変更範囲は公式リリースの記載に基づきます。実際の再開条件は、利用環境とジョブ設定で変わります。