Claude Code Desktopのスケジュールタスク、予定どおり完走は48%（395枠の実測・ENOTFOUND）

結論から

Claude Code のデスクトップアプリのスケジュールタスクを、1日6枠・74日回した。予定の時刻に動いて完走したのは半分以下だった。

その枠がどうなったか	枠数	割合
予定から15分以内に始まり、完走した	189	47.8%
15分より遅れて始まり、完走した	107	27.1%
始まったが、エラーで終わった	52	13.2%
実行記録が1件も無い	47	11.9%
合計	395

その日のうちに仕事を終えられなかった枠は、4枠に1枠（25.1%）。止まらない前提で手順を組むと、この4分の1がそのまま穴になる。

何を測ったか

このブログ（tech.rebounder.jp）の記事と計測は、Claude Code デスクトップアプリのスケジュールタスクが回している。Mac の上で動くローカル実行で、人は入らない。

• 期間：2026-08-17〜2026-10-29（74日）
• タスク：6本（記事を書く4本＋計測2本）。10/26 から4本に減らした
• 実行の総数：373回

アプリは実行のたびに、開始時刻と、エラーで終わったときのエラー文を手元に記録している。これを集計した。単位は「1タスク×1日＝1枠」。予定の30分前より前に始まった実行は、前日の枠の遅れとして数えた。

1つ除外がある。9/26〜10/04 に、4つの枠が enabled: false になっていた（止まる3つの形の③）。この間の記録なし34枠は「止まった」のではなく「止められていた」ので、分母から外した。

集計に使ったスクリプトは scripts/run-reliability.ts。読むのは開始時刻とエラー文の先頭だけで、プロンプトや出力は読まない。

失敗の7割は DNS だった

エラーで終わった52枠の内訳：

エラー	枠数
API Error: Can't reach the API server … (ENOTFOUND)	36
SSL certificate verification failed（UNABLE_TO_VERIFY_LEAF_SIGNATURE）	9
Your computer went to sleep mid-response	6
Request timed out	1

ENOTFOUND は API サーバの名前が引けなかった、つまりその瞬間に回線が無かったということ。36枠のうち19枠は、予定より遅れて始まった追いかけ実行だった。10/24 は 15:11 に3つのタスクが同時に始まり、3つとも ENOTFOUND で死んだ。Mac が起きた直後で、まだ回線が繋がっていなかったのだと考えている。

TLS の9枠は、すべて 10/08〜10/22 に出た。この時期は、通信の中身を検査する回線をよく使っていた。そうした回線は途中で証明書を差し替えるので、証明書の検証が通らなくなる。

どれも**同じ枠の中で再実行はされなかった。**死んだ実行は自分で何も書き残せないまま終わる。

遅れは中央値3時間、最大22時間

遅れて完走した107枠の遅れ：

	遅れ
中央値	3時間5分
上位10%	12時間50分
最大	22時間35分

15〜60分の遅れが21枠、1〜3時間が32枠、3時間を超えたのが54枠。

遅れの正体は、Mac が寝ていた時間の追いかけ実行。起きると、溜まっていた枠がまとめて走る。別々のタスクが3分以内に続けて始まった例が46回あった。

この追いかけ実行は助けになる。だが、**時刻に意味がある仕事には使えない。**08:04 の記事が 20:00 に出ても、その日のうちなら困らない。一方で「毎朝9時の通知」のような仕事には、3時間の遅れは失敗と同じになる。

「寝ていても後で走る」は保証されない

以前の記事で「起動しない枠は、次にアプリが起動したとき自動で走るので放っておいてよい」と書いた。74日分を数えると、これは言い過ぎだった。

枠が有効だったのに、実行記録が1件も無い枠が47枠（11.9%）ある。どのタスクも1回も起動しなかった日も、74日中4日（9/05・9/12・9/27・10/11）あった。追いかけ実行は多くの場合に起きるが、起きない日もある。

止まる前提でどう組んだか

4枠に1枠が穴になるなら、穴を前提に組むしかない。やったことは3つ。

**1. 実行記録ではなく成果物で判定する。**死んだ実行は何も書き残せない。だから「その枠が出すはずのファイルが、その時間帯に git に入ったか」で、仕事をしたかを見ている（scripts/check-runs.ts）。

**2. 後の回が前の回の穴を埋める。**夕方 16:01 の回は、まず今日の日本語記事の本数を数える。0本なら、本来の仕事（英語版づくり）をやめて日本語の記事を書く。英語版は検索からのクリックがほぼ無く、1日抜けても損が最も小さい。だから予備に回した。

**3. 枠を減らした。**昼 12:08 と夕方 17:03 の2枠は、朝と11時の回の予備として足したものだった。だが予備の枠も同じ割合で死ぬ。10/26 に4枠へ減らし、予備の役は夕方 16:01 の1枠に寄せた。

変更後の5日間（10/26〜10/30）、朝の記事の枠は2回、仕事をしなかった。10/26 は記録なし、10/27 は ENOTFOUND。それでも**日本語の記事は5日とも1本ずつ出ている。**変更前の 10/24 は、上に書いた3つ同時の ENOTFOUND で、記事は0本だった。

自分の環境で数えるには

デスクトップアプリの実行記録は ~/Library/Application Support/Claude/claude-code-sessions/ の下に、1実行1ファイルの JSON で残っている。scheduledTaskId・createdAt・error の3つを読めば、上と同じ表が作れる。予定時刻はアプリに残っていないので、手で与える。

この記事の数字は、同じスクリプトで毎月1日に更新する。

まとめ

• 予定の時刻に動いて完走したのは 47.8%。4枠に1枠はその日のうちに終わらなかった
• 失敗の7割は DNS（ENOTFOUND）。同じ枠の中での再実行は無い
• 寝ていた分の追いかけ実行は起きるが、遅れの中央値は3時間で、起きない日もある
• 時刻に意味がある仕事は載せない。載せるなら、後の回が前の回の穴を埋める形にする