毎朝の売上集計をAIに任せたのに、翌日は前日の判断を忘れている。担当者は同じ説明を足し、AIは似た確認を繰り返す。定期実行が増えるほど、この小さな手戻りは効いてきます。
Nous Researchは2026年8月21日、Hermes Agent v0.20.5（タグ v2026.8.19）を公開しました。公式リリースには、前版から約323件のPRを取り込んだパッチ版であることに加え、cronジョブの永続メモリと、ジョブごとのreasoning effort（推論の深さ）が挙げられています。
派手な新機能というより、定期業務を「毎回ゼロから始める単発処理」から「前回までの経緯を踏まえて続ける仕事」へ近づける更新です。ただし、記憶を有効にすれば業務が勝手に賢くなるわけではありません。保存する範囲を決めないまま使うと、古い判断や個人情報まで次回へ持ち越します。
今回、公式に確認できること
v0.20.5のリリースノートは、この版をv0.20.4以降の変更をまとめた安定タグと説明しています。そこで列挙された変更の一つが、cronジョブの永続メモリとジョブ単位の推論強度です。完全な整理版リリースノートはv0.21.0で公開予定とも書かれているため、現時点で細かな挙動まで断定するのは早いでしょう。
Hermesの公式cronドキュメントでは、定期ジョブにプロンプト、使用スキル、モデル、作業ディレクトリ、配信先などを持たせられます。公式メモリ文書は、継続セッションで利用者の前提や過去の要点を引き継ぐ考え方を説明しています。今回の更新は、この二つを定期処理の運用に近づけるものと読めます。
ここから先は私の実務上の解釈です。定期ジョブが保持すべきなのは、会話全文ではありません。「前回どこまで処理したか」「何を例外として保留したか」「次回は何を確認するか」という短い作業状態です。仕事の正本は別に置き、メモリは次の実行へ渡す付箋として扱う方が壊れにくい。
向いているのは、前回との差分が価値になる業務
一番相性がいいのは、毎回同じ形で回しつつ、前回との差分を見たい仕事です。たとえば、問い合わせの滞留確認、公開記事の重複検査、在庫や価格の変化監視、週報の未完了項目の追跡。前回の対象IDや保留理由を持てれば、同じ行を何度も処理する事故を減らせます。
逆に、給与、契約、採用評価など、誤った記憶の持ち越しが人や金銭に直結する業務は慎重に扱うべきです。AIの記憶だけを証拠に処理を確定してはいけません。元データ、承認履歴、更新者、更新日時を正本側で確認し、人の承認を残す必要があります。
記憶は「正本」ではなく、再開位置に限定する
中小企業でよく起きる失敗は、AIのメモリ、チャット、スプレッドシート、社内文書のどれが正しいのか分からなくなることです。保存先が増えるほど、Company Brainではなく情報の墓場になります。
定期ジョブに持たせる情報は、次のように絞ると扱いやすくなります。
- 前回処理したレコードIDと実行日時
- 未完了の理由と、再開に必要な条件
- 人が承認した例外だけを短く要約したもの
- 次回の検査対象と、終了判定
顧客情報の全文、秘密鍵、契約書本文、請求金額の確定値を、便利だからという理由で会話メモリへ寄せるのは悪手です。そうした情報は権限管理された正本に残し、ジョブ側には参照先と状態だけを渡します。
推論の深さは、仕事の難しさに合わせる
ジョブごとのreasoning effortは、AIに付けるギアだと考えると分かりやすい。URLの死活確認や定型集計に重い推論は要りません。処理時間とコストが増え、出力の揺れまで大きくなることがあります。
一方、複数の資料を比較して矛盾を探す、例外理由を分類する、公開前の記事を反証まで含めて検査する仕事は、浅い推論では見落としが増えます。高いギアを使う価値があります。
私は、定期業務を二つに分けるのが現実的だと見ています。取得、照合、件数確認は軽い設定で回す。判断が必要な行だけを別工程へ送り、深い推論か人の確認を使う。全件を最も重い設定にするより、速度、費用、説明のしやすさを揃えやすくなります。
導入前に決める四つの境界
- 何を覚えるか
処理済みID、保留理由、次回確認事項など、再開に必要な情報へ限定します。 - いつ捨てるか
完了済み案件や期限切れの例外を残し続けると、古い前提が判断へ混ざります。保存期間と更新条件を先に決めます。 - どこを正本にするか
顧客台帳、請求、契約、記事本文などの正式データは既存システムに残します。メモリは正本の代わりではありません。 - どこで人に戻すか
金額確定、公開、削除、対外送信は承認対象にする。AIが迷ったときの停止条件も書いておきます。
小さく試すなら、同じジョブを三回回す
最初から全社の定期業務へ広げる必要はありません。一つの低リスク業務を選び、同じ条件で三回動かします。見る数字は、重複処理件数、再説明にかかった時間、誤った持ち越し件数、1回あたりの処理時間と費用です。
三回目でも同じ確認を繰り返すなら、覚える項目が足りません。前回の誤りを引きずるなら、保存範囲が広すぎます。高い推論設定でも結果が変わらないなら、その工程は軽いギアへ戻せます。
運用で起きやすい三つの事故
一つ目は、成功した処理と失敗した処理を同じように記憶することです。APIが途中で止まったのに「処理済み」と残せば、次回は未処理データを飛ばします。止まった定期処理を安全に戻す手順と同じく、外部システムを再取得して確認した事実だけを完了として保存します。
二つ目は、担当者が直した内容をAIの古い要約で上書きすること。定期ジョブの開始時に正本の更新日時を確認し、メモリより新しい変更があれば正本を優先する設計が要ります。「前回こうだった」は、現在も正しいとは限りません。
三つ目は、例外が増え続けることです。「この取引先だけ別扱い」「今月だけ保留」といった条件を無期限に残すと、数か月後には誰も理由を説明できません。例外には根拠、承認者、期限を持たせ、期限が来たら自動適用せず再確認へ戻します。
ログも分けて考えます。実行ログは、何時に何件を処理し、どこで失敗したかを調べるための記録です。メモリは、次回どこから再開するかを渡す短い状態です。両方を一つの長文へ詰め込むと、読み込み量が増える割に判断は安定しません。
公開や対外送信には、記憶とは別の承認を置く
記事公開、メール送信、請求確定、データ削除は、前回うまくいったから今回も自動承認、という扱いにしない方が安全です。定期ジョブのメモリは作業の連続性を作りますが、権限までは引き継ぎません。
公開前なら、参照元URLの再取得、重複確認、本文への内部メモ混入検査、画像とモバイル表示の確認までを機械で済ませられます。その検査結果を承認条件に使う。記憶を信用するのではなく、その回の証拠で通す形です。
この更新で見えてくるのは、AIの性能競争より地味な課題です。定期実行に必要なのは、賢いモデルだけではない。記憶の境界、正本の保存先、停止条件がそろって初めて、昨日の続きから安全に仕事を再開できます。
一次情報
- Nous Research: Hermes Agent v0.20.5 release
- Hermes Agent公式ドキュメント: Cron Jobs
- Hermes Agent公式ドキュメント: Memory
確認日: 2026年8月23日。リリースノートで確認できる事実と、運用上の解釈を分けて記載しています。