# 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 非依存で作り、ウェブアプリのアクションからも呼べるようにする。 ## ジョブ側（クライアント） ```js 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` 等の差し替え）を本当に効かせているかも確認する。効いていないと「鳴る例」のテストが実ファイルを読み、異常検出が丸ごと未検証になる。 ---