なぜ予定タスクの失敗をチェックポイントに分けて見るのか？
記録された問題が、実行場所、ワークスペース、フォルダーアクセス、ツール承認、承認モードと、別々の段階で現れているからだ。共通点は誰もリアルタイムに応答しないことである。チェックポイントに分ければ、作成時に「このステップに人は必要か」と問え、あとからデバッグするより手間が少ない。
ワークスペースの起動に失敗しても、タスクは動くのか？
更新履歴によれば動く。期限の来た予定タスクは約10分後にワークスペースなしで開始されるが、ワークスペースが必要なコマンドはその実行で失敗する。したがってタスクは実行されたように見えても、ワークスペースを要しない部分しか完了していない可能性がある。「Scheduled task failed」通知と実際の結果で確認する。
予定タスクで「ask」とされたツールはどうなるのか？
更新履歴によれば、実行は承認プロンプトを表示して待ち、スキップはしない。新しい実行は古い実行の未応答プロンプトを取り消す。待機にタイムアウトがあるかは書かれておらず、タスクが自分であきらめるとは想定しないこと。完全に無人で動かすタスクは、そうしたツールに依存しないようにする。
「自動承認」がデフォルトになれば、これらの問題は消えるのか？
消えない。自動承認が影響するのはツール使用前に確認するかどうかだけで、ワークスペースの起動失敗、フォルダーアクセス、組織がaskとするツールには関係しない。またClaudeが作成したタスクにのみ、組織が許可する場合にのみ適用される。askポリシーとこのデフォルトの相互作用は説明されておらず、決めつけないこと。
予定タスクの売りは、自分がその場にいなくてよいことだ。ところが最近の公式更新履歴の修正は、ほとんどが誰もいないときにどこかのステップが止まる問題だ。この記事では、記録されたそれらの動作を5つのチェックポイントに整理し、タスク作成時に自問できるようにする。設計上の助言は私による整理であり、公式のチェックリストではない。
10月6日から、新規に作成した予定タスクはクラウドで実行され、既存のコンピューターベースの予定タスクは引き続きコンピューター上で動く。ローカルのタスクにはデスクトップアプリと使える状態のコンピューターが必要で、これは以前の記事で扱ったスリープの制約である。自分のタスクがどちら側かを把握する。
更新履歴によれば、Claudeのワークスペースが起動に失敗するコンピューターでは、期限の来た予定タスクは約10分後にワークスペースなしで開始され、ワークスペースが必要なコマンドはその実行で失敗する。つまりタスクは「動いた」ものの、縮小した形で動いた可能性がある。
10月8日の更新は、Claudeがセッションがすでに持つフォルダーへのアクセスを再度求め、誰も承認できない承認待ちで予定実行が止まる問題を修正した。この事例は直ったが、教訓は変わらない。タスクが必要とするフォルダーは、作成時に確認しておく。
組織の承認ポリシーは一部のツールを「ask」にできる。更新履歴によれば、予定タスクがそのようなツールに達すると、実行はスキップせず承認プロンプトを表示して待ち、同じタスクの新しい実行は古い実行の未応答プロンプトを取り消す。待機にタイムアウトがあるかはドキュメントに書かれていないため、無期限に待つ可能性があると想定する。
10月1日から、Claudeが作成する予定タスクは組織が許可する場合「自動承認」がデフォルトとなり、実行はツールを直接使い、安全でなさそうなときだけ一時停止する。手動で設定したタスクはこのデフォルトの影響を受けない。
予定タスクを作る前に、ひとつ問う。どこかのステップが、人のリアルタイムの応答を必要としないか。必要なら、設計し直すか、止まって待つことを受け入れる。タスクが必要とするフォルダーとツールは作成時に一通り確認し、「Scheduled task failed」通知に注意する。これは無人実行でプロダクトが出してくれる数少ない合図の一つだ。