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

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

失敗に気づく手段はプランと実行場所で変わる

左サイドバーの「Scheduled」ページで過去の実行を見直すのが基本で、使える検知手段はプランによって増えます。

個人プランで公式が示す確認手段は、Scheduledページを定期的に見に行くことです。安全ガイドも運用の心得に「Review outputs after each run(実行のたびに結果を確認する)」を挙げ、スケジュールタスクの結果が期待どおりか定期的に確かめるよう求めています。

各実行は独立したCoworkセッションとして残るので、失敗した回はScheduledページの過去の実行から開き、通常のタスクと同じ画面で出力を読み返せます。

Team・Enterpriseプランは、OpenTelemetry(OTel)をSIEMや可観測性ツールに接続すると、この確認作業を能動的な監視に変えられます。流れるイベントには、MCPサーバー名・ツール名・パラメータ・成否・実行時間を含む全ツール呼び出しと、リクエストごとのモデル・トークン数・エラーを含むAPIリクエストが入ります。1件のユーザープロンプトに紐づく全イベントには共通のprompt.idが付くので、1回のプロンプトで何が起きたかを後から追えます。

OTelの対象は、クラウドで動くCowork(デスクトップ・Web・モバイル)とローカルのデスクトップセッションの両方です。クラウドのセッションを監視するにはClaude Desktopのバージョン1.22209.3以降、ローカルのデスクトップセッションを監視するには1.1.4173以降が要ります。

OTelを入れる側が先に決めておく点もあります。イベントにはユーザーのプロンプト全文が既定で含まれ、ファイルパスやコマンド引数といったツールの入力はtool_parametersに、ユーザーのメールアドレスはイベント属性に入ります。これらをSIEMへ流したくない場合は、コレクター側でフィルタやマスキングを設定してから下流へ回します。エンドポイントを管理者が設定するまでは、データは一切流れません。

組織管理イベントを記録する監査ログはEnterprise限定で、Organization settings > Data and Privacyの「Export logs」から直近180日分を書き出せます。ただしチャットやプロジェクトのタイトル・内容は監査ログに含まれず、識別子だけが出力されます。Compliance APIもEnterpriseプラン向けで、Public Sector組織は対象外です。Teamプランで、Scheduledページに加えて使える手段はOTelだけです。この可視性の違いはCowork監査ログと権限管理にまとめています。

2026年10月6日以降は、ローカルで動くタスクと見え方が分かれる

失敗を調べる前に、そのタスクがどこで動いていたかを確かめます。Pro・Maxプランでは、2026年10月6日から新しいCoworkタスクはクラウドで動き、設定の「Only on your computer」は削除されます。すでにPC上で始めたタスクはPC上に残ります。

Scheduled Tasksの説明ページには、ローカルのファイルやアプリを要するタスクは「ローカルでのみ実行される」という注記と、フォルダに紐づけられないという注記が並んでいます。一方、10月6日の変更を説明するページには、ローカルのファイルを使うスケジュールタスクもクラウドへ移り、実行にはデスクトップアプリが開いている必要があると書かれています。記述が食い違う箇所なので、ファイルを読むタスクが空の結果を返したときは、まずデスクトップアプリが開いていたかを疑います。

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

失敗に気づいたら、最初の一手は原因の特定より先にタスクを止めることです。Scheduledページから個々のタスクを開き、一時停止(Pause)を選ぶと、次回以降の実行が止まります。削除ではなく一時停止にするのは、調査の途中で依頼文・頻度・承認モードを見返せるようにするためです。

書き込みを伴うタスクが失敗したなら、停止と同時に外部への影響も確かめます。メール送信や外部システムへの書き込みを含むタスクは、失敗した実行が途中まで書き込んでいる可能性があります。OTelのツール呼び出しログか、Scheduledページの実行結果で、どこまで実行されたかを追います。

原因は4つの型に切り分けられる

停止した後は、失敗がタスクの書き方にあるのか、外側の状態にあるのかを分けます。

依頼文の条件が原因なら、タスクを開いてその場で指示を編集できます。手動で作成したタスクでは、頻度を毎時・毎日・毎週・平日・手動の中から選び、モデルと作業フォルダは任意で指定します。承認モードも作成時に選ぶ項目です。「Create with Claude」で作ったタスクは、Claudeが提示したタスク名・スケジュール・内容を確認して「Schedule」を押した時点で登録され、その内容が依頼文として保存されます。

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

「毎週月曜9時にHubSpotの週次商談レポートをSlackに投稿する」タスクが、ある週から空のレポートを投稿し続けた場合を例に、手順を追います。

再開前にオンデマンド実行で確かめる

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

修正が不十分なまま再開すると、次の定期実行で同じ失敗を繰り返します。書き込み系のタスクなら、誤った書き込みがもう一度起きるおそれもあります。

再発防止は完了報告と承認モードで組む

正常時に短い完了報告を出させておくと、報告が来ないこと自体が異常の合図になります。Slack投稿やメール送信まで行うタスクなら、通知先を見るだけで正常性を判別でき、Scheduledページを毎回開かずに済みます。

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

もう1つの見直し点が、書き込みを伴うタスクの承認モードです。「Automatically approve」では、Claudeが各操作を実行前に安全面から審査します。「Skip all approvals」では、操作を確認する仕組みがありません。どちらのモードでも、プロンプトインジェクションの被害に遭えば、気づく前に指示どおり動くおそれがあります。

安全ガイドは、機微なファイルやアカウントに触れるタスク、初めて使うツールやサイトを使うタスク、メール送信や購入のように取り消しにくい操作を含むタスクで、「Manually approve」へ切り替えるよう挙げています。ファイルの完全削除は、どのモードでも確認が入ります。さらに、人が見ていない状態で動くスケジュールタスクには、機微なファイルへのアクセスや代理の送信・購入といった元に戻しにくい操作を組み込まない、という指針も示されています。取り消しにくい操作の見極め方はCoworkの取り消せない操作をどう見極めるかにまとめています。

よくあるつまずき

タスクを削除して作り直し、手がかりまで消す。原因が分からないまま削除して作り直すと、一時的には直っても、同じ失敗が別の形で再発したときに依頼文や頻度の履歴を見返せません。まず一時停止にし、切り分けが尽きたときの最終手段として削除・再作成を使います。

個人プランなのにOTelでの検知を前提に運用を組む。OTelはTeam・Enterprise向けの機能です。個人プランではScheduledページを見に行く運用が前提なので、完了報告を依頼文に入れて補います。

よくある質問

「Automatically approve」で動いたタスクの承認を、後から人の判断と区別できるか

承認判断を記録するイベントとして挙げられているのはOTelです。Team・EnterpriseでOTelを設定していれば、各ツール操作について、ユーザーが承認したか、拒否したか、既存の権限設定に基づいて自動実行されたかが記録されます。個人プランでこの区別が要る場面が多いなら、承認モードを「Manually approve」に寄せる運用になります。

まとめ

失敗したScheduled Tasksは、削除ではなく一時停止で止め、オンデマンド実行で直ったことを確かめてから再開します。個人プランで公式が示す確認手段はScheduledページなので、正常時にも完了報告が届く依頼文にしておくと、異常に気づく手がかりが増えます。