Claude Codeのスケジュールタスクが止まる3つの形（ENOTFOUND・enabled: false）

結論から

Claude Code のスケジュールタスク（定期実行）は、こちらの運用では3つの形で止まった。

止まり方	起きたこと	手当て
① 起動しない	Mac が寝ていた・アプリが閉じていた	不要。次の起動時に自動で走る
② 起動して途中で死ぬ	回線断で API に届かず即死	再試行は無い。次の回が取り返す
③ 枠そのものが無効になる	誰も意図していないのに enabled: false	毎日一覧を見て戻す

3つとも**実行した本人のログには出ない。**だから「実行したか」ではなく「成果物が git に入ったか」で判定している。

何を回しているか

このブログ（tech.rebounder.jp）の記事は、Claude Code のデスクトップアプリのスケジュールタスクが書いている。枠は1日6つ。記事を書く枠が 08:06 / 12:08 / 16:05 / 20:07 の4つと、ネタの在庫を積みアクセス数を取る枠が 11:02 / 17:07 の2つ。2026-08-16 から7週間、この形で回している。

実行はすべて画面なしで、人は入らない。だから止まったときに「誰かが気づく」ことを前提にできない。

① 起動しない — これは放っておいてよかった

Mac がスリープしていたり、アプリが閉じていたりすると、その時刻には何も起きない。だがこれは**次にアプリが起動したとき、プラットフォームが自動で走らせた。**実測で、8/17 20:07 の回が 8/18 09:59 に完走している。

手当てが要るのは、こちらではない。

② 起動して途中で死ぬ — 再試行は無い

困るのはこちらだ。2026-08-17 20:02 の夜の枠は、起動から4分で次のエラーを出して死んだ。

API Error: Can't reach the API server (ENOTFOUND)

ログは12行で、ファイルは1つも触られていない。死んだので、自分では何も記録できない。

2日後の 8/19 には回線が約1時間切れ、11:02 と 12:08 の2枠が続けて死んだ。**再試行は無く、その枠は失われた。**しかも実行自体が API に届かずに死ぬので、手順書の側で「失敗したらもう一度」と書いても効かない。

取り返しは次の回に持たせる

打てる手は「次の回が取り返す」だけだった。いまは各回の冒頭で、今日すでに何本出たかと、何枠が過ぎたかを数え、不足ぶんをその回で書くようにしている。

ただし1回で取り返すのは2本までにした。理由は3つある。

• 同じ分野の記事を1日に何本も出すと、まとめ書きは衝突しやすい
• **1回の実行が長いほど、途中で死ぬ確率が上がる。**取り返そうとして②を自分で増やすことになる
• 書く材料の在庫を食い潰す

取り返せないものを先にやる

もう1つ変えたのは順番だ。アクセス数は Cloudflare 側に7日しか残らないので、取り逃した日は永久に埋まらない。一方、記事は翌日に回せる。そこで、8/19 の取り逃し以降は記事を書く4枠すべての冒頭で、まずアクセス数を取るようにした。4枠のどれか1つでも動けば、その日のデータは埋まる。

「動いた」と「仕事をした」は別

8/18 10:01 の在庫の枠は、実行した記録（最終実行時刻）は残っているのに、在庫も積まずアクセス数も取らず、ファイルを1つ書いただけで終わっていた。繰り越し実行（10:02 完了）と重なったためだ。

実行記録だけを見ていたら、これは成功に見える。

③ 枠ごと無効になる — 1週間気づかなかった

いちばん長く見逃したのはこれだ。2026-09-27〜28 に、記事を書く4枠のうち3枠が enabled: false になっていた。**1週間気づかなかった。**公開は1日1〜4本から、1日1本ちょうどに落ちていた。

直前の実行は5回とも成功していて、失敗が原因ではない。止めた覚えのある人もいない。誰も意図していない停止だった。

監視の画面はこれを「落ち」として出してはいた。だが回線断で死んだ回と同じ見た目だったので、16件の中に埋もれた。止まっているのが「1回の実行」なのか「枠そのもの」なのかを区別していなかったのが原因だ。

いまは毎日11時の枠の最初に、スケジュールタスクの一覧を取らせている。書く枠が false になっていれば true に戻し、報告に「◯◯が止まっていたので戻した」と1行書く。意図して止めたい枠が出たら、手順書にその名前を例外として書く。書いていない枠は毎日戻される。

判定は自己申告ではなく、成果物で

3つに共通するのは、実行した側の記録を信じると見逃すことだ。死んだ実行は何も書けないし、動いただけの実行は「成功」と書く。

そこで各枠に「この枠が動いたなら git に入るはずのファイル」を決めて、それが入ったかで判定している。記事の枠なら記事ファイル、在庫の枠なら計測データ、という具合だ。朝と夕方の在庫の枠は同じファイルを書くと区別できないので、別々のファイルを心拍にしている。

待ち時間は実測で決める

起動から成果物が出るまでの時間も、最初は机上で120分と決めていた。8/17〜8/30 の実測はこうだった。

枠	中央値	最大
08:06 朝の記事	13分	113分
11:02 在庫	107分	171分
12:08 昼の記事	78分	125分
16:05 夕方の記事	122分	163分
17:07 夕方の在庫	68分	130分
20:07 夜の記事	19分	169分

夕方の記事の枠は**中央値が窓を超えていた。**記事は出ているのに半分以上が「落ち」と表示され、成功率が33%と出ていた。窓を180分に広げて誤報を消した。誤報を出す画面は、そのうち誰も見なくなる。

おまけ：無人実行が「権限待ち」で止まる

止まり方とは別に、初日（2026-08-16）に踏んだのが権限の確認だ。無人実行では誰も承認できないので、確認が出た時点でその回は終わる。原因は2つだった。

• && や ; で複数のコマンドを繋ぐと、許可リストのどれにも一致しない
• cd <ディレクトリ> && git ... は、移動先の git hooks が実行されうるための確認が毎回出る。許可リストでは外せない

どちらも書き方で避けた。1回1コマンドにし、場所は git -C <dir> と npm --prefix <dir> で指定する。cd は使わない。

まとめ

Claude Code のスケジュールタスクを無人で回すなら、止まることを前提にしたほうがいい。起動しなかった回は勝手に追いつくが、**途中で死んだ回は戻らないし、枠が無効になっても誰も教えてくれない。**こちらは「成果物が入ったか」で判定し、不足は次の回に2本まで取り返させ、取り返せないデータは全枠の冒頭で先に取る形に落ち着いた。