ANTIGRAVITY LABEN
記事一覧/Agents & Manager
Agents & Manager/2026-09-06上級

エージェントの定期実行で、失敗より先に「走らなかった」を疑うようになりました

定期実行の台帳は成功率100%のまま、夕方の枠だけが二週間走っていませんでした。期待発火表と実行台帳を突合して欠落を出す監査を、cron 展開・終了コード・台帳の書き方の実測とあわせて書き残します。

Antigravity364エージェント70定期実行cron2運用監視

プレミアム記事

壁紙の分類バッチを一日二回に増やしたつもりでいた朝、処理済みの枚数がどうにも足りないことに気づきました。台帳を開くと、実行の記録はきれいに並んでいます。ステータスはすべて OK です。エラーは一件もありません。

それでも枚数が足りないのです。並んでいる時刻をひとつずつ読んで、ようやく分かりました。朝の枠しかありません。夕方の枠は、二週間ぶん一度も現れていませんでした。

私はそれまで、無人で動かす仕組みの健全性を「失敗が出ていないこと」で測っておりました。失敗が出ないなら大丈夫だと考えていたのです。けれど走らなかった回は、失敗としても記録されません。台帳には何も書かれず、通知も鳴りません。何も起きなかったという事実だけが、そこに残ります。

以来、私は監視の向きを一つ変えました。起きたことを見るのをやめたわけではありません。それに加えて、起きるはずだった回数を先に数えるようにしたのです。

失敗の通知は、走らなかった回には届きません

理由を書き出すと当たり前でした。失敗通知はプロセスが立ち上がって初めて発火します。起動しなかった回にはプロセスがなく、したがって通知の主体もいないのです。

Antigravity の Remote Control が返してくれるプッシュ通知も、性質は同じです。エージェントがタスクを完了したとき、あるいは追加の入力を求めたときに届きます——つまり、動き始めた実行についてだけ届きます。私はこの通知にかなり助けられておりますが、「今日はそもそも動かなかった」を教えてくれる経路ではありません。

手元の台帳で数えてみます。三日ぶんの記録に対して、失敗だけを拾う経路が捕まえる件数はこうなりました。

照合できた実行: 6
欠落した実行  : 3
failure-only 通知が拾う件数: 0

成功率は 6/6 で 100% です。同じ台帳を、期待した回数の側から見ると 6/9 で 67% になります。同じデータを見ているのに、分母を変えるだけで結論が変わりました。

成功の記録ではなく、起きるはずだった回数を数えます。 この一文を運用メモの先頭に置いてから、私は夜中の処理をようやく信用できるようになりました。

期待の側は、式ではなく表として持ちます

原因を探し始めたとき、私はまず cron 式を疑いました。30 4,16 * * * と書いてあります。読み返しても間違いは見つかりません。式そのものを検証しても、答えは出ませんでした。

そこで、式を読むのをやめて展開してみました。分と時のフィールドを素直に開くだけの、短い関数で足ります。

# expect.py — cron 式から「期待発火時刻」を展開する最小実装
# 日・月・曜日は * の前提。定期実行の監査に必要なのは分と時だけでした。
from datetime import datetime
 
def parse_field(f, lo, hi):
    """カンマ・ハイフン・スラッシュを展開して値の集合を返します。"""
    out = set()
    for part in f.split(","):
        if part == "*":
            out |= set(range(lo, hi + 1))
            continue
        if "/" in part:                       # */6 や 0-23/6 の形
            base, step = part.split("/")
            rng = range(lo, hi + 1) if base == "*" else range(
                int(base.split("-")[0]), int(base.split("-")[-1]) + 1)
            out |= set(v for v in rng if (v - min(rng)) % int(step) == 0)
            continue
        if "-" in part:                       # 9-17 の形
            a, b = part.split("-")
            out |= set(range(int(a), int(b) + 1))
            continue
        out.add(int(part))
    return sorted(out)
 
def expected(expr, day):
    """その日に発火するはずの datetime を昇順で返します。"""
    minute_field, hour_field = expr.split()[0], expr.split()[1]
    minutes = parse_field(minute_field, 0, 59)
    hours = parse_field(hour_field, 0, 23)
    return [day.replace(hour=H, minute=M, second=0, microsecond=0)
            for H in hours for M in minutes]

手元で走らせた結果です。

'30 4,16 * * *'      -> 2 回/日  ['04:30', '16:30']
'30 4 * * *'         -> 1 回/日  ['04:30']
'30 16 * * *'        -> 1 回/日  ['16:30']
'0 */6 * * *'        -> 4 回/日  ['00:00', '06:00', '12:00', '18:00']

式としては二回です。書き方は正しかったのです。それでも実際に走っていたのは一回でした。実行基盤が複数スロットの表記をどう扱うかは、式の正しさとは別の話だったのだと、このとき初めて腑に落ちました。

一日に二回動かしたい処理は、いまは枠ごとに別のジョブへ分けています。表記をまとめる利点より、片方が黙って落ちる危険のほうが高くつきます。

書き方式としての期待取り得る事故いまの扱い
30 4,16 * * *2 回/日片方だけ発火しても無音使いません
30 4 * * *30 16 * * *各 1 回/日片方が止まれば欠落として出ますこちらに分けます
0 */6 * * *4 回/日間引きに気づきにくい突合が必須です

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
起動そのものが起きなかった回を、失敗通知とは別の経路で拾えるようになります
いま動いているスケジュールに手を入れないまま、期待発火表との突合を後から足せるようになります
成功率と充足率のずれ(同じ台帳で 6/6 と 6/9)を、自分の運用で数えられるようになります
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥2,480 の永久アクセス
メンバーシップを見る →

関連記事

Agents & Manager2026-07-29
agent.md の綴り誤りが権限を広げていた — frontmatter を厳格に検証する lint を書く
agent.md の frontmatter は綴りを間違えてもエラーになりません。既定値へ静かに落ちた結果、意図と逆の権限が適用されていた実例と、権限キーだけを厳しく検証する lint の実装・実測を記録しました。
Agents & Manager2026-07-17
エージェントに渡した参照メモの7割は届いていませんでした — head で切る運用の限界を測った記録
head で行数を切って渡していた参照メモの7割がエージェントに届いていなかった、という実測に基づく記録です。行数ではなくセクション単位の契約で切り取り境界を設計し直し、予算内で何を残すかを決めるまでの過程を、検証データとともにまとめています。
Agents & Manager2026-07-16
作業中のエージェントに、次の指示をいつ渡すか — 待つ・割り込む・積むを実運用で測りました
Antigravity v2.3.0 で入ったメッセージのキューイングと Send Now。待つ・割り込む・積むの三択を同じ物差しで測り、積んだ指示が古くなる問題と、前提スタンプで手戻りを22%から9%へ下げた記録をまとめました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →