scheduled tasks
予約タスクが丸ごと消えて13日間気づかなかった記録：定期実行の見張り方
2026年9月9日の朝、デスクトップのClaudeアプリの登録簿が作り直され、予約タスク6本の登録が丸ごと消えました。手順書のファイルは残っていたので、フォルダがあるのを見て「登録されているはず」と思い込み、13日間、誰も気づきませんでした。失敗は記録に残らず、走らなかった回は「何も起きない」だけだからです。この面は、何が消えて何が止まったか、どう気づいたか、見張りをどう足したかの記録です。
このサイトはAnthropicの公式サイトではありません。Claude Codeの機能・料金・提供範囲は変わる可能性があるため、重要な判断の前には公式のドキュメントと自分のアカウント設定を確認してください。
先に結論：定期実行は「あるはず」でなく、一覧と最終実行時刻で見る
確かめる材料を2つに絞ります。
- 予約タスクの一覧を、アプリの機能で取得する。手順書のフォルダの有無では判断しない。
- 各タスクが最後に走った時刻を、セッションの記録から読む。
手順書のファイルが残っていても、登録簿から外れていれば走りません。13日間気づけなかった最大の理由はここでした。もう1つ、サイトの運用には「判断が要らない定期処理」と「判断が要る処理」があり、前者は複数のAIに役割を分ける記録にあるとおりWindowsのタスクへ移していました。そちらは止まらず、Claudeに任せていた側だけが止まった形です。
確かめる手順：自分の環境で、止まっている予約を見つける
- アプリの予約タスクの一覧を出し、自分が登録したはずのタスク名と突き合わせる。
- 各タスクの手順書の説明文から、実行の予定時刻を控える。登録簿が消えるとcron式も消え、説明文に書いた分しか残らないので、あらかじめ説明文に時刻を書いておく。
- セッション記録の先頭にあるタスク名のタグ（予約タスクが起動したことを示す印）を集め、タスクごとの最終実行時刻を出す。
- 別の動きから逆算する。例えば「押す係」が止まると、待機リストで配った回数だけが伸びて、押した記録が0の行が並ぶ。
- パソコンで動く定期処理（Windowsのタスク）は別系統なので、別に一覧を見る。
登録簿の実体は、アプリがMSIXの箱に入っているため、アプリから起動したプロセスにしか見えない場所にあります。Windowsのタスクスケジューラから起動した処理からは、通常の場所を探すとファイルが見つかりません。外から読む道具は、両方の場所を探すように直しました。
記録1：何が、いつ消えたか
2026年9月22日に、管理役のセッションが発見しました。予約タスクの一覧が返すのは、9月20日に作った1本だけでした。登録簿の置かれたフォルダが2026年9月9日の9時38分に作り直されており、それより前の登録簿はどこにも残っていませんでした。消えたものは次のとおりです。
| タスク | 頻度 | 役割 |
|---|---|---|
| 登録リクエストの係 | 1日4回 | 待機リストからインデックス登録を押す |
| SEO監視の解釈 | 毎朝 | 監視の結果を読み、title/descriptionを本番へ |
| 公式発表の取り込み | 毎朝 | 公式の発表を取り込んでページを更新 |
| 催しのトップ切り替え | 毎朝 | トップを次のイベントへ切り替える |
| 期間中の日次更新 | 毎朝 | 手順3（新情報の報告）だけ。日付更新はWindows側で無事 |
| 再確認の1回限り | 9月21日 | 走らなかった |
最後に走った回は、4本とも2026年9月9日の8時32分でした。9時38分の作り直しの、約1時間前です。
影響は、インデックス登録の係に最もはっきり出ました。9月13日以降の登録は1日0から3本で、ほぼ1つのサイトの担当が手で押していた分だけ。それまでは1日8から12本で、多数のサイトに押していました。待機リストでは、配った回数だけが伸びて、押した記録0の行が並びました。3つのサイトは一度も押されていませんでした。これが唯一の徴候で、気づいたのは13日後です。別の系統の定期処理は止まっていなかったので、監視役は気づけませんでした。監視役はWindowsのタスクしか見ていなかったからです。
記録2：直したこと、直さなかったこと
9月22日の対応は次のとおりです。
- 登録リクエストの係は、運営者の判断で1日2回に減らして登録し直した。元は1日4回。元の手順書は
.bakの名前で残した。 - SEO監視の解釈は止めたまま。担当がtitleを直している最中で、自動で本番へ書くと衝突するため。
- 1回限りの再確認は、管理役が手で実行した。
- 公式発表の取り込みなど4本は、Windowsの定期処理と担当セッションで回っているので、戻さなかった。
- 登録簿と一緒に、ツールの許可も消えていた。初回は画面で「今すぐ実行」を押して許可しないと、予定の回が許可待ちで止まる。
見張りも足しました。毎朝のパルス処理の「急ぐもの」に、2つの検査を追加しました。①登録簿に登録リクエストの係が無い、または無効。②72時間で押されたサイトが1つ以下（待機が10サイト以上あるとき）。②を48時間にしなかったのは、止まっている間も1つのサイトの担当が手で押していて、空白が最大2日程度だったからです。検査を厳しくしすぎると、正常な日にも鳴ります。
ついでに別の欠陥も見つかりました。期限を過ぎた割り込みが最高点のまま、そのサイトの一巡の先頭を取り続けていました（8サイト）。順番を決める処理で、一巡の中の並びだけ下げました。
記録3：定期実行が「予定どおり」走らない、その他の原因
消えた以外にも、定期処理が予定どおり走らない原因が重なっていました。
- パソコンの再起動：このパソコンは、2〜3日に1回、予期しない再起動をしていました。90日で34回。発生時刻は0時台から23時台まで満遍なく分散していて、特定の処理が引き金ではありませんでした。ハードウェアの不良として扱います。「クラッシュが多い日は自分の重い処理のせい」と考えるのをやめました。
- 通知の宛先が満杯：2026年9月4日、毎朝の報告や警告をまとめて送っていた宛先の箱が満杯で、全部が跳ね返っていました。送信側のログは「送れた」と成功を返します。転送先で捨てられるのはローカルからは見えません。「送信成功」を「届いた」と読みません。
- 直接実行すると無出力で終わる：定期処理のジョブのファイルを、実行役を通さず直接実行すると、無出力、終了コード0で終わり、異常なしと誤読して、91時間の失敗を4日間見逃しました。
- 測り方の誤り：使用量の見積りを「1回平均×予定回数」で出したら、4倍ずれました。定期処理は予定どおり走っていないからです。セッション記録に実在する回数で割ります。
判断の要らない仕事は、Claudeを起動しないWindowsの定期処理に移しました。トークンを使わず、失敗はメールとトーストで鳴ります。ただし、その見張りも止まれば誰も見ていません。取り戻す側も見張りの対象に入れました。こうした失敗を記録に積む形は戻された変更と回帰にも通じます。
よくある質問
手順書のファイルが残っているのに、予約が消えていることはありますか。
あります。この記録がそれです。手順書のフォルダと、アプリの登録簿は別物で、登録簿が作り直されると手順書だけ残ります。フォルダがある、は登録がある、の証拠になりません。
定期処理が止まったことに、早く気づく方法は何ですか。
成果物の側から逆算します。待機リストで配った回数だけ伸びて押した記録が0、のように、仕事の結果に出る数字の食い違いを見ます。その上で、一覧と最終実行時刻を朝のパルスで検査します。しきい値は、止まっている間の実際の空白に合わせます。
消えた予約を戻すとき、何が必要ですか。
実行の予定時刻は、手順書の説明文に書いてあったものだけが残ります。あらかじめ説明文に時刻を書いておくと戻せます。登録簿と一緒にツールの許可も消えるので、初回は画面で「今すぐ実行」を押して許可します。