常駐プロセスが落ちたら気づきたい。素直に書くとこうなる。

# 5分ごとに動かす
if not process_is_alive():
    notify("プロセスが落ちています")

これは動く。そして一番困る状況で、一番静かになる。

障害	この監視	デッドマン装置
プロセスだけ落ちた	検知できる	検知できる
マシンがスリープした	検知できない	検知できる
マシンが落ちた・ネットが切れた	検知できない	検知できる

監視スクリプトが同じ機械に載っている以上、機械ごと死んだら監視も死ぬ。
そして監視が死ぬと、通知は来ない。静かになる。

この記事は、その素直な監視をノートPCに24時間載せて失敗し、
実測で稼働率33%だと分かってから設計を直すまでの話。

① 向きを反転する —— 「落ちたら鳴らす」ではなく「生きていたら送る」

デッドマン装置（dead man's switch）にする。

自分 : 正常なときだけ、外部へ ping を送る
外部 : 予定の ping が来なかったら通知する

判定を外に置くのがすべてで、これで「自分が死んだこと」を自分で言わなくてよくなる。

import urllib.request

PING_URL = "https://hc-ping.com/<uuid>"   # healthchecks.io など

def watchdog() -> int:
    if not process_is_alive():
        return 1                      # **異常なら、何もしない。** pingを送らない
    try:
        urllib.request.urlopen(PING_URL, timeout=10)
    except OSError as e:
        # ping が送れないこと自体は自分では解決できない。**黙らない**
        log(f"ping送信に失敗: {e}")
        return 1
    return 0

ここで大事なのは 異常時に「異常です」と送らないこと。
送る仕組みに依存すると、送れない状況（＝一番困る状況）で通知が消える。
沈黙そのものを信号にする。

② ノートPCに24時間監視は成立しない（実測）

反転させて満足していたら、今度は通知が止まらなくなった。

原因はマシンが寝ることだった。フタを閉じれば寝るし、AC電源でも寝る。
sleep 0 はアイドルスリープの設定で、クラムシェルスリープには効かない。

5日ぶんを実測した数字がこれ。

	実測
ping の稼働率	33%
15分を超える断絶	55件
「監視が動いていない」通知（このままなら）	110通

最初は「ミュートが効かない」問題に見えた。だが調べると、通知は全部正しかった。
監視は本当に止まっていた。バグは通知側ではなく、「24時間動いている」という前提の側にあった。

通知がうるさいとき、まず黙らせ方を探さない。
その通知が正しいなら、直すのは受け手ではなく期待のほう。

③ 期待を実態に合わせる —— 監視する窓を絞る

監視に意味がある時間帯だけを窓にする。私の場合、対象プロセスが要るのは
特定の時間帯と、月のうち数日だけだった。

WATCH_START, WATCH_END = 22, 7      # JST 22:00 〜 翌07:00
WATCH_DAYS = range(1, 7)            # **カレンダー日**の 1〜6日

def in_window(now: datetime) -> bool:
    if now.day not in WATCH_DAYS:
        return False
    h = now.hour
    return h >= WATCH_START or h < WATCH_END    # 日付をまたぐ窓

def watchdog(now: datetime) -> int:
    if not in_window(now):
        return 0        # 接続もせず、pingも送らず、**ログも書かない**
    ...

窓の外でログも書かないのは、書くと日に190行たまって、
夜間の記録が押し流されるからだ。監視のログが監視の役に立たなくなる。

これで実行回数が年3.3万回から約20分の1になった。
月中に落ちても構わない。次に困るのは翌月で、その前の窓で捕まる。
失うのは長期の稼働データだけ。

④ ここで踏んだ罠 —— カレンダー日と「セッション日」

窓を日付でも絞るとき、「セッション日」で実装して外した。

対象は夜からの時間帯なので、「7時より前は前日扱い」にしたくなる。
だが cron はカレンダー日で撃つ。 ずれる。

時刻	cron が ping を期待するか	セッション日で実装した場合
6日 22:00	する	前日扱いにならず対象外 → 送らない → アラート
1日 00:30	する	前月末扱い → 送らない → アラート

cron 側とコード側で「日」の定義が違うと、必ずどこかで噛み合わない。
撃つ側に合わせる。つまりカレンダー日。

送りすぎは無害、送らなすぎだけがアラートになる

デッドマン装置の性質として、余分な ping は害がない（外部のタイマーが延びるだけ）。
一方で ping が1つ足りないと通知が飛ぶ。非対称なので、迷ったら広い側に倒す。

これはテストで固定できる。1年分を総当たりして、
cron が期待する時刻を1つも落としていないことを確かめる。

from datetime import datetime, timedelta

def cron_fires(t: datetime) -> bool:
    """crontab: */5 22,23,0-6 1-6 * *  を素直に書き下したもの。"""
    return (t.day in range(1, 7) and t.minute % 5 == 0
            and (t.hour >= 22 or t.hour <= 6))

def test_窓はcronが撃つ時刻を1つも落とさない():
    t = datetime(2026, 1, 1)
    missed = []
    while t < datetime(2027, 1, 1):
        if cron_fires(t) and not in_window(t):
            missed.append(t)            # cronは撃つのに送らない = アラートになる
        t += timedelta(minutes=5)
    assert missed == [], f"送らない時刻が {len(missed)}件: {missed[:3]}"

逆（窓の中なのに cron が撃たない）は落とさない。 送りすぎは無害だからだ。
テストの非対称性が、設計の非対称性と一致している。

⑤ 監視側と外部側のスケジュールは「対」

窓を変えたら、外部サービス側のスケジュールも同時に変える。
片方だけ変えると、どちらに倒しても悪くなる。

変えたほう	起きること
コードだけ	日中の ping が来ないので、外部が障害と判定して通知が増える
外部だけ	窓の外の ping で「生きている」と誤判定される

healthchecks.io なら Simple スケジュールでは表現できないので Cron にする。

Schedule : */5 22,23,0-6 1-6 * *
Timezone : Asia/Tokyo
Grace    : 20 minutes

この2つが対になっていることは、コード側からはテストできない。
向こう側は外部サービスの設定だからだ。
だから**「片方だけ変えない」をコメントとREADMEに書いて、人間の側で守る。**
テストで守れないものは、守れないと認めて別の手を打つ。

⑥ 監視を止める手段も、監視と対で要る

うるさいときに黙らせる口は要る。ただし必ず期限付きにする。

def muted_until() -> datetime | None:
    """**無期限ミュートを作らない。** 消し忘れると監視が永久に死ぬ。"""
    ...

def notify(msg: str) -> None:
    until = muted_until()
    if until and datetime.now() < until:
        log(f"ミュート中（{until:%H:%M}まで）: {msg}")   # **捨てずに記録は残す**
        return
    send(msg)

無期限のミュートは、外れていることを教えてくれない安全装置になる。
前に書いた「その安全装置、一度も作動したところを見ていないのでは」
と同じ形だ。

まとめ

監視は自分の外に置く。「落ちたら鳴らす」ではなく「生きていたら送る」。
沈黙そのものを信号にする
異常時に通知を送ろうとしない。 送る仕組みごと死ぬのが一番困る状況
「24時間動いている」を、寝る機械に前提として載せない。 実測したら33%だった
通知がうるさいとき、黙らせ方から探さない。 その通知が正しいなら、直すのは期待のほう
cron とコードで「日」の定義を揃える。 撃つ側（カレンダー日）に合わせる
送りすぎは無害、送らなすぎだけがアラート。 非対称なら広い側に倒し、テストもそう書く
コードと外部設定は対。 テストで守れないものは、守れないと認めて文書と手順で守る
ミュートは必ず期限付き。 無期限は「外れていることを教えてくれない安全装置」

監視を作った日に、一度スリープさせてみるといい。
何も鳴らなかったら、それが答えだ。

note でも書いています

このシリーズ以外に、AIエージェントの運用から広がった政治・経済・メディア構造の話を
note で書いています。