PC の定期ジョブが「丸ごと止まった」ことを PC の外で検知する（Apps Script 心拍・dead-man switch）

何の問題を解くか

Windows タスクスケジューラ／cron で毎日動く集計・点検ジョブがあり、PC 上に見張り番（watchdog）も置いている。 しかし PC 自体が落ちる・スリープする・ログインが切れると、見張り番も一緒に止まるので「止まった」を誰も報告しない。 沈黙は「正常」と見分けがつかない。

受け取り手を PC の外（Google Apps Script のウェブアプリ＋時間トリガー）に置き、 各ジョブが心拍を打ち、来るはずの心拍が来なければ外側が鳴らす構成にする。

構成

各ジョブ(node 等) ──POST action=heartbeat──▶ Apps Script ウェブアプリ ──▶ シート「heartbeat」(job×slot ごと最新1行)
                                                    ▲
                              時間トリガー checkHeartbeats (例 10:00 / 19:00) ──NG のみ──▶ チャット通知(Webhook)

Apps Script 側

1. 保存は「job×slot ごとに最新1行の上書き」。追記で伸ばさない（判定が最新行だけで済み、シートが肥大しない）。 列: job, slot, at, status, summary, checks。書き込みは LockService.getScriptLock() で排他。
2. status は started / ok / failed の3値。started が無いと「起動して落ちた」と「起動していない」を区別できない。
3. 期待表を定数で持つ: {job, slot, due:'HH:MM'} の配列。現在時刻（必ず Utilities.formatDate(d,'Asia/Tokyo',…) で固定の TZ に落とす）が due を過ぎたものだけ判定し、 missing（行なし）/ stale（日付が今日でない）/ failed / incomplete（started のまま）に分ける。判定関数はシートにも通知にも触らない純関数にする。
4. 通知は NG のときだけ。毎朝1回だけ「監視稼働中: N job 正常」の1行を出すと、監視そのものの沈黙にも気付ける。
5. Webhook の応答コードを必ず読む（muteHttpExceptions:true、2xx 以外は失敗扱い。429 を成功と数えない）。
6. 心拍の記録は例外を投げない（{ok:false,error} を返すだけ）。監視の失敗で本業のジョブを止めない。
7. トリガー設置関数は UI 非依存で作り、ウェブアプリのアクションからも呼べるようにする。

ジョブ側（クライアント）

export async function sendHeartbeat({ job, slot, status, summary = '', checks = null, call = gatewayCall }) {
  try { const r = await call('heartbeat', { job, slot, status, summary, checks }); return { ok: r?.ok !== false, response: r }; }
  catch (e) { return { ok: false, error: e.message }; }   // 投げない
}

開始時に started、終了時（finally）に ok / failed。致命的エラーで抜ける経路でも failed を打つ。

落とし穴（実際に踏んだもの）

1. シートの日付セルをそのまま返すと書式が壊れる。String(cell) は "Sat Oct 10 2026 20:47:06 GMT+0900 (…)" になり、 受け手が slice(0,10) で日付を取ると心拍が届いても毎回 stale ＝ 監視が永久に赤になる。 返す側で ISO（yyyy-MM-dd'T'HH:mm:ssXXX）に揃え、受ける側も書式を仮定せず Date.parse で解釈し、 解釈できない値は unreadable として正常にも古いにも倒さない。テストは実応答の文字列そのままで書く。
2. 監視自身の心拍を「NG を見つけたら failed」にしない。それをすると「監視が止まった」と「監視が異常を見つけた」が同じ表示になる。監視の心拍は「動いたか」、検出結果は summary に分ける。
3. 期待表は2か所（GAS とクライアント）に置くなら、一致をテストで固定（片方だけ直すと黙ってずれる）。
4. デプロイ反映は「新しく足したキーが応答に入ったか」で判定（getBuildInfo に heartbeat:true を足す）。成功表示や応答長は当てにならない。
5. due 時刻は「ジョブの実所要時間」の後ろに置く。ブラウザ操作で数十分かかる後段ジョブを開始予定時刻＋30分にすると毎日誤報になる。

「動いた」の先: 正しさと再発防止も同じ形で足す

• 心拍は「動いた」しか言えない。出力の妥当性（例: 市場最安が自社平均の3倍超、未取得が50%超、提案0件）を純関数で検査し、NG なら status を failed にする。判定不能は null として NG（false）と分ける。
• 過去事故を「1事故1ファイル」のプローブ（{id, incidentDate, source, what, probe(ctx)→{ok,evidence}}）にして毎日回す。 プローブは「鳴る例」だけでなく「クリーンなリポジトリで鳴らない」こともテストする。コメント行や自分自身のソースに正規表現が当たる誤検知は、実リポジトリで回すまで見えない。 テスト用のコンテキストが注入（readRepo 等の差し替え）を本当に効かせているかも確認する。効いていないと「鳴る例」のテストが実ファイルを読み、異常検出が丸ごと未検証になる。