Coworkでタスク失敗をリカバリする — 検知から再実行まで

Scheduled Tasksが実行はされたのに想定と違う結果を出した、あるいは途中で止まって一部だけ処理された。この状態からの復旧は、①検知②停止③原因の切り分け④再実行、の順で進めます。タスクがそもそも実行されない原因の切り分けはCoworkスケジュールタスクが実行されないときの確認手順が扱うので、本記事は実行はされた後の障害対応に絞ります。

実行後の失敗はまず気づけるかどうかが分かれ目

Scheduled Tasksの実行結果は自動では通知されません。失敗に気づくための手段は、契約プランによって使えるものが変わります。

個人プランでは、左サイドバーの「Scheduled」ページを定期的に見に行く以外に検知手段がありません。公式の安全ガイドも「Review outputs after each run(実行のたびに結果を確認する)」を運用上の心得として挙げています。確認を怠ると、失敗が何週間も気づかれないまま繰り返される事態になります。

Team・Enterpriseプランは、OpenTelemetry(OTel)をSIEMや可観測性ツールに接続することで、この確認作業を能動的な監視に変えられます。OTelが流すイベントには、MCPサーバー名・ツール名・パラメータ・成否・実行時間を含む全ツール呼び出しの記録と、リクエストごとのモデル・トークン数・エラーを含むAPIリクエストの記録が含まれます。1件のユーザープロンプトに紐づく全イベントには共通のprompt.idが付くため、ある実行で何が起きたかを後から再構成できます。ただしOTelはTeamプランでも使える一方、組織管理イベントを記録する監査ログとCompliance APIはEnterpriseプラン限定です。Teamプランのまま運用する場合、この2つは使えずOTelだけが検知手段になります。この可視性の違いはCowork監査ログと権限管理にまとめています。

検知したら、まず停止する

失敗に気づいた時点で最初にすべきことは、原因の特定より先にタスクを止めることです。個々のタスクを開き、一時停止(Pause)を選ぶと、次回以降の実行が止まります。削除ではなく一時停止を選ぶ理由は、原因調査の途中でタスクの設定内容(依頼文・頻度・対象フォルダ)を見返す必要があるためです。削除すると設定内容ごと失われます。

書き込みを伴うタスクが失敗した場合は、停止と同時にその失敗が外部に及ぼした影響の有無も確認します。メール送信や外部システムへの書き込みを含むタスクであれば、失敗した実行が意図しない送信や書き込みを部分的に実行してしまった可能性があるかを、OTelのツール呼び出しログ、またはScheduledページの実行結果から確認します。

原因を切り分けてから直す

停止した後、原因を切り分けます。ここでの切り分けは大きく4種類に分かれます。

• 依頼文の条件が曖昧だった: 「重要な連絡」のような主観的な条件は、実行のたびに判定が揺れます。機械的に判定できる条件へ書き換えます
• 接続先の状態が変わっていた: コネクタの接続が切れていた、権限が変わっていた、対象のファイルやレコードが削除・移動されていたなど、タスク側ではなく外部の状態変化が原因のケースです
• タスクの対象範囲が想定より広がっていた: 新しいデータが増えたことで、処理対象が当初の想定を超え、途中で止まった、あるいは扱いきれない量になったケースです
• ローカルのファイルやアプリに依存していた: Scheduled Tasksはクラウド側で動きますが、対象フォルダやローカルアプリを使うタスクは実行時にClaude Desktopアプリを経由してPCへアクセスします。Desktopアプリが閉じている、PCがスリープしているタイミングでは、この経路が成立せず結果が空になったり途中で止まったりします

原因が接続先の状態変化であれば、コネクタを一度切断してからつなぎ直す対応が有効なことがあります。依頼文の条件が原因であれば、タスクの編集画面からその場で書き換えられます。ローカル依存が原因であれば、実行予定時刻にPCが起動していたか、Desktopアプリが常駐していたかをまず確認します。

具体例で見る復旧の流れ — 週次レポートタスクの認証切れ

具体的な流れは、実際の失敗パターンで追うと分かりやすくなります。「毎週月曜9時にHubSpotの週次商談レポートをSlackに投稿する」Scheduled Taskが、ある週から空のレポートを投稿し続けたケースを例にします。

まず検知です。個人プランであれば、Scheduledページの実行履歴を開き、直近数回分の出力を見比べます。過去は数字が入っていたレポートが、ある週から「データが取得できませんでした」という文言に変わっていれば、そこが異常の起点です。Team・EnterpriseでOTelを設定済みであれば、該当する実行のprompt.idに紐づくツール呼び出しを見て、HubSpotへの呼び出しがエラーを返している行を直接特定できます。

次に停止です。このタスクを一時停止し、次回以降の空レポート投稿を止めます。投稿自体はSlackへの書き込みですが、内容が空であるため外部への実害は限定的です。実害が大きい失敗(誤ったデータをそのまま投稿していた場合など)であれば、停止と同時にSlack側の該当メッセージを削除するかどうかも検討します。

原因の切り分けでは、HubSpotコネクタの接続状態を確認します。多くの場合、認証トークンの期限切れやOAuthの再認可漏れが原因です。コネクタを一度切断し、再接続します。

再接続後はオンデマンド実行で1回動かし、正しい数字が返ってくることを確認してから一時停止を解除します。このタスクに完了報告の指定を加えておけば、次に同じ認証切れが起きたときも、レポートの中身を見なくても異常に気づけるようになります。

修正後はオンデマンド実行で確認してから再開する

原因を直したら、スケジュールを再開する前にオンデマンド実行でその場を動かします。これはScheduled Tasksの管理機能の一つで、次回の予定を待たずにその場でタスクを1回だけ実行できる機能です。オンデマンド実行で正しい結果が返ることを確認してから、一時停止を解除(Resume)してスケジュールに戻します。

修正が不十分なまま再開すると、次回の定期実行で同じ失敗を繰り返すだけでなく、書き込み系のタスクであれば同じ種類の誤った書き込みを再度発生させるリスクがあります。オンデマンド実行での確認は、この二次被害を防ぐための最後の関門です。

再発防止として組み込んでおきたいこと

一度失敗したタスクは、同じ種類の失敗を繰り返しやすい性質を持ちます。再発防止として効くのは次の2点です。

正常終了時の完了報告をプロンプトに含める。実行結果が自動通知されない以上、正常時に短い完了報告を出力させておけば、報告が来ないこと自体が異常の合図になります。出力をSlack投稿やメール送信するタスクであれば、その通知先を見るだけで正常性を判別でき、Scheduledページを毎回開く必要がなくなります。

実行が正常に完了した場合は、末尾に
「[正常終了] 処理件数: {件数}」の1行を必ず付けてください。
データが取得できない、対象が0件などの異常時は
「[要確認] 理由: {具体的な理由}」を付けてください。

この一文を既存のタスクの依頼文に加えるだけで、実行結果の先頭数行を見るだけで正常・異常を判別できるようになります。

書き込みを伴うタスクの承認モードを見直す。失敗が外部への書き込みを伴っていた場合、そのタスクの承認モードが「Automatically approve(自動承認)」や「Skip all approvals(承認スキップ)」のままで良いのかを再検討します。Automatically approveでも、Claudeが危険と判断した操作は自動実行されず確認待ちで止まります。ただし確認を返せるのは人がいるときだけです。無人の時間帯に動くタスクでは、この確認待ちのままタスクが止まり続けます。機微な操作を含むタスクは「Manually approve(手動承認)」に戻す判断も選択肢に入りますが、その場合は無人の時間帯の実行がすべて承認待ちで止まる代償を伴います。取り消しにくい操作の見極め方はCoworkの取り消せない操作をどう見極めるかにまとめています。

よくあるつまずき

タスクを削除して作り直し、失敗の記録も消してしまう。原因が分からないまま削除して作り直すと、一時的には直ることがありますが、何が原因だったかの記録が残らず、同じ失敗が別の形で再発したときに手がかりが無くなります。まずは一時停止で止め、原因が本当に切り分けられないときの最終手段として削除・再作成を使います。

個人プランなのにOTelでの検知を前提に運用を組んでしまう。OTelはTeam・Enterpriseプラン限定の機能です。個人プランのアカウントでは、Scheduledページを見に行く運用以外の検知手段が無いことを前提に、完了報告をプロンプトに含める工夫でカバーする必要があります。

よくある質問

「Automatically approve」で動いていたタスクが失敗した場合、承認が自動実行だったのか人が承認したのかを後から区別できるか

個人プランのScheduledページの実行履歴だけでは区別できません。Team・EnterpriseでOTelを設定していれば、各ツール操作について「ユーザーが承認したか、拒否したか、既存の権限設定に基づいて自動実行されたか」を示す人間の承認判断イベントが記録されるため、そこで区別できます。個人プランでこの区別が必要な場面が多いなら、承認モードを「Manually approve」に寄せて、判断の記録をタスクの依頼文自体に残す(承認するたびに理由を一言添えさせるなど)運用でカバーします。

一時停止したタスクの設定内容はどこまで保持されるか

一時停止は実行のスケジュールだけを止める操作で、依頼文・頻度・対象フォルダ・承認モードなどタスクの設定内容はすべてそのまま残ります。原因調査の途中で設定内容を見返し、その場で編集してから再開することもできます。

まとめ

Scheduled Tasksの失敗からの復旧は、検知→停止→原因の切り分け→オンデマンド実行での確認→再開、の順で進めます。検知の手段は契約プランで異なり、個人プランはScheduledページの手動確認、Team・EnterpriseはこれにOpenTelemetryによるリアルタイム監視が加わります。停止は削除ではなく一時停止を選び、原因調査の材料を残したまま進めるのが安全です。修正後はオンデマンド実行で正しく動くことを確認してから再開し、正常終了時の完了報告をプロンプトに組み込んでおくと、次に同じ失敗が起きたときの検知が早くなります。