技術ブログ

Hermes Agentのcronを異常時だけ通知する｜[SILENT]と監査ログを分ける

約11分で読めます
#Hermes Agent#AIエージェント#Cron#監視
Hermes Agentのcronを異常時だけ通知する｜[SILENT]と監査ログを分ける

通知が来ないのに、実行記録は残っています。2026 年 9 月 1 日に Hermes Agent の cron 出力を調べると、最終応答が[SILENT]だけだった監査ファイルは 32 件ありました。

正常なら黙り、異常なら知らせる。監視では自然な動きですが、「ジョブが動かなかった」と「動いて黙った」は見分ける必要があります。私はチャットの静けさを成功の証拠にせず、実行履歴とローカル出力を別に確認します。

前回は、収集処理を Python へ分け、整形済み JSONL だけを Hermes Agent へ渡しました。今回は、その判断結果を毎回通知せず、変化や異常があるときだけ届けます。

前回から今回への差分

項目前回完了時今回完了後
入力scriptが収集したJSONLをagentへ渡します変更しません
正常時の応答毎回、結果を配信します最終応答を[SILENT]だけにします
異常時の応答通常結果と同じ経路で配信します問題の内容だけを配信します
監査実行履歴を確認します実行履歴とローカル出力を照合します
完了判定通知の有無に寄りやすい状態ですcompleted、出力保存、deliveryを分けて読みます

すでに cron の作成とhermes cron runsを使える場合は、「最終応答を 2 択にする」まで飛ばせます。

なぜ「通知なし」を成功扱いしないのか

Hermes Agent の cron は、実行と配信を別に扱います。agent が成功しても、Slack の権限や delivery target の設定が違えば通知は届きません。反対に、正常時の最終応答へ[SILENT]を入れれば、届かないことが正しい動作になります。

画面上の結果はどちらも「メッセージがない」です。しかし、内部状態は異なります。

[Scheduler tick]
       │
       ▼
[cron jobを実行]
       │
       ├─ 失敗 ───────────────→ 失敗を配信
       │
       └─ 成功
            │
            ▼
       [最終応答を判定]
            │
            ├─ [SILENT]を含む → chat配信を抑制
            │                    local出力は保存
            │
            └─ 通常の報告 ────→ delivery targetへ配信

公式ドキュメントでは、[SILENT]による抑制は成功した run だけに適用されます。失敗した run は、最終応答に marker があっても配信対象です。障害まで隠す仕組みではありません。

用語を揃える

用語この手順での意味
quiet markercronの配信を抑える文字列[SILENT]です
final responsetool実行が終わったあと、agentが最後に返す本文です
delivery最終応答をSlack、Telegram、localなどへ渡す処理です
local output~/.hermes/cron/output/へ保存される実行記録です
execution ledgerhermes cron runsで読める、claimedからterminal stateまでの台帳です
terminal statecompleted、failed、unknownのいずれかです
delivery failureagentの処理は終わったものの、送信先へ届かなかった状態です

最終応答を2択にする

prompt には、正常時と異常時の返し方を両方書きます。marker を説明文へ混ぜず、正常時は marker だけに固定します。

対象を確認する。
変化も異常もなければ、最終応答は [SILENT] だけにする。
異常があれば、対象、観測値、確認時刻、次に見る場所を日本語で返す。
[SILENT] と異常報告を同じ応答へ混ぜない。

[SILENT]は「何も変わらなかった」という業務判断です。tool の途中経過を静かにする設定ではありません。agent は必要な確認を終えたあと、最終応答で marker を返します。

私は「問題がなければ短く報告する」とは書きません。短い正常報告も毎回配信されるためです。「marker だけ」と出力形式を決めます。

実機で監査ファイルを数える

2026 年 9 月 1 日、Hermes Agent v0.20.6 のホストで確認しました。まず version を読みます。

hermes --version

実測の先頭行です。

Hermes Agent v0.20.6 (2026.8.27) · upstream 71c823bb

次に、profile 内の cron 出力から、## Responseより後ろが[SILENT]だけのファイルを数えました。

python3 - <<'PY'
from pathlib import Path

count = 0
for path in Path.home().joinpath(".hermes/cron/output").glob("*/*.md"):
    text = path.read_text(errors="replace")
    marker = "\n## Response\n"
    if marker not in text:
        continue
    response = text.split(marker, 1)[1].strip()
    if response == "[SILENT]":
        count += 1

print(f"silent_response_files={count}")
PY

実測結果は 32 件でした。

silent_response_files=32

この数は保存期間と job 数で変わります。重要なのは、チャットへ通知されなくても監査ファイルが残る点です。公式仕様も、抑制した出力を~/.hermes/cron/output/へ保存すると説明しています。

一覧と履歴を別々に読む

ジョブが登録されているかは一覧で確認します。

hermes cron list

2026 年 9 月 1 日の実機では、朝稿レビューjob に次の値が表示されました。

Name:      hibanas morning PR review request
Schedule:  30 8 * * *
Deliver:   slack:C0BRCUJBVCG
Last run:  2026-08-31T08:30:14.637323+09:00  ok
Execution: completed

一覧のokは実行結果です。通知を抑えたか、delivery が成功したかまで一語で表すものではありません。対象 job の履歴も読みます。

hermes cron runs d0cfe5837f6c --limit 5

completedなら agent run は完了しています。failedなら異常です。unknownなら、再起動後に元の process が消えたことを確認した監査記録です。公式仕様では、unknownを自動再実行しません。

特定の run を二重実行すると、外部投稿や更新を重ねる恐れがあります。通知が届かないだけでhermes cron runを押してはいけません。先に ledger と local output を照合します。

空文字と[SILENT]は使い分ける

公式の troubleshooting には、出力が空なら delivery を抑えるとあります。no-agent job で、正常時に script が何も出さない設計なら空の stdout が自然です。

LLM を使う job では、空の最終応答を期待するより[SILENT]を明示する方が判断を追いやすくなります。監査ファイルを検索すれば、agent が静音を選んだ run を数えられます。

jobの形正常時異常時
agentあり最終応答を[SILENT]だけにします問題の本文を返します
--no-agent --scriptstdoutを空にします警告をstdoutへ書き、非0終了も検討します
定期レポート通常本文を返します本文へ失敗箇所を含めます

日次レポートまで静音にすると、期待した情報も消えます。静音は、正常時の情報価値が低い監視へ限定します。

markerを本文へ混ぜない

公式仕様は、最終応答に[SILENT]が「含まれる」場合に配信を抑えると説明しています。次の返し方は避けます。

異常はありません。[SILENT]

人には正常報告に見えますが、cron は message 全体を送らない判定にします。さらに危険なのは、異常報告の末尾へ marker を残す形です。

APIが3回失敗しました。確認が必要です。[SILENT]

この応答も抑制対象です。prompt では「正常時は marker だけ」「異常時は marker を書かない」と明記します。

よくあるエラー

症状原因確認と修正
正常なのに毎回通知されます[SILENT]の綴りや角括弧が違います最終応答をASCIIの[SILENT]だけに固定します
異常報告も届きません異常本文へmarkerを混ぜています異常時の応答からmarkerを外します
通知がなく、実行済みか分かりませんchatだけを見ていますhermes cron runsと~/.hermes/cron/output/を確認します
completedなのに通知がありません正常な静音かdelivery failureですlocal outputの最終応答と一覧のdelivery状態を分けて読みます
同じ失敗通知が毎回届きます[SILENT]は失敗runを隠しません原因を修正するか、incidentを確認して既知のsignatureだけackします
no-agent jobが正常時にも通知しますscriptが改行や状態文をstdoutへ出しています正常時のstdoutを空にし、診断はfileや履歴へ残します
手動runの結果がすぐ出ませんhermes cron runは次のscheduler tickへ予約します最大60秒のtick後にrunsを確認します

私なら監視と報告を分ける

死活監視、在庫変化、PR の有無など、正常時に伝える内容がない job は静音にします。週次レビューや日次要約は、変化が少なくても定期的に本文を返します。

静音 job にも、対象、正常条件、異常条件、確認時刻の扱いを明記します。「何もなければ黙る」だけでは、取得失敗を「変化なし」と誤判定する恐れがあります。取得が 0 件になるはずのない source なら、0 件を異常へ倒します。

通知は結果の運搬手段であり、実行台帳ではありません。私は、静音を選べる job ほど local output と execution ledger を残します。静かな朝を作るため、見えない場所の記録を厚くします。

一次情報

出典確認した内容
Hermes Agent Scheduled Taskssilent suppression、local output、失敗runの配信、execution history、manual runの非同期動作
Hermes Agent Cron Troubleshooting空出力と[SILENT]、delivery failure、gatewayの60秒tick、確認順序
Hermes Agent Cron Internalsscheduler、保存、配信を分けた内部構成
Python pathlibPath.globとread_textによる監査ファイルの確認

※GSC では直近 28 日間に「hermes agent cron」が 1 impression、平均掲載順位 10 でした。数値は需要の補助として使い、題材は AI エージェントの無人運用で通知疲れを減らす関心から選んでいます。

この記事をシェア
hibana
この記事を書いた人
hibana

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

関連記事