2026.11.11

Claudeの定期タスクが許可待ちで止まり、一覧はsucceededのままだった。会話記録の最後で見分けた

運営者

2026年10月28日の点検で、Claude の定期タスクが何本も止まっていたと分かりました。
定期タスクは、決まった時刻に Claude が自分で作業を始める機能です。
僕は Claude のデスクトップアプリで、毎朝の記録などをこれに任せています。

止めていたのは、ファイルへの書き込みなどの前に出る許可の確認でした。
無人で動いているので、誰も答えません。
その回は、確認を待ったまま止まっていたのです。

気づくのが遅れたのは、実行の一覧の表示のせいでした。
止まった回も、状態は succeeded（成功）か running（実行中）と出ています。

止まった回かどうかは、その回の会話記録の最後で見分けました。
道具を呼んだところで記録が終わり、その結果が返っていない回が、止まった回でした。

毎朝の記録も、年に1回の更新も抜けていた

10月28日に分かった止まり方は、次のとおりです。

毎朝の再生数の記録（日本語学習チャンネルの分）：伸びた動画がある日に、台帳のメモへの書き込み（Edit）で止まっていた。10月27日の回は running のまま
年に1回の統計データの更新：7月28日の回は、公表を確かめたあと、データのファイルへの書き込み（Write）で止まった。古い年の版のまま残っていた
無料ツールのデータの再確認：9月15日と10月15日の回が、作業フォルダの外にある申し送りのファイルを読むところで止まった。確認が2か月空いた
動画の文字起こしの要約：取得のあとの要約の書き込みで止まり、9月15日以降の16本が要約されないまま

ほかにも3本のタスクが、約11秒で終わっていました。
何で終わったのかまでは、記録に残っていません。

止まらずに動いていたのは、曲の配信登録を進めるタスクだけです。
これだけが Auto モードで、ほかは既定のモードのままでした。

既定のモードは、書き込みのたびに確認を出す

定期タスクには、タスクごとに権限モードがあります。
権限モードは、Claude が何をするときに人の確認を求めるかの設定です。

記録では、既定のモードで確認が出る場面を次のようにまとめています。

ファイルを書く（Write）・書き換える（Edit）とき
作業フォルダの外を読み書きするとき
許可の一覧に無いコマンドを動かすとき

公式の説明では、既定のモードは Manual（設定の値は default）にあたります。
「ファイルの編集またはコマンドの実行の前に確認を求めます」という説明です。
人が見ている会話なら、確認が出ても押せば先へ進めます。
定期タスクでは押す人がいないので、そこで止まります。

公式には、止まったときの手当ても書かれていました。
その回のセッションを開いて、そこで確認に答える、というものです。

succeeded も running も、終わった印にならなかった

止まった回は、実行の一覧で succeeded か running と出ていました。
僕の記録には「一覧の状態は当てにならない」と太字で残しています。

10月27日の回は、しばらく running のままでした。
そのあと、止めた記録が無いまま、表示だけが succeeded に変わります。
台帳のメモは、書かれないままでした。
10月29日の回も同じです。

止まった回が残っていると、次の回が起きないこともありました。
11月1日の回は、書き込みの確認で running のまま止まっていました。
翌日の11月2日の回は、実行の記録すらありません。
公式の説明でも、飛ばされた回の理由の1つに「前の実行がまだ進行中だった」が挙がっています。

反対に、利用上限で失敗した回は、一覧にも failed と出ました。
11月2日の朝に2本あり、10月26日には週の上限で失敗した回もありました。
failed は正直に出るのに、許可待ちは成功や実行中に見える、という違いです。

会話記録の最後で、止まった回を見分ける

見分け方は、その回の会話記録が道具の呼び出し（tool_use）で終わっているかどうかです。
呼び出しに対する結果（tool_result）が無ければ、そこで確認を待っています。

会話記録は、パソコンの中にファイルで残っています。
公式の説明では、~/.claude/projects/<プロジェクト>/<セッション>.jsonl が会話の記録です。
メッセージや道具の呼び出し、その結果が1行ずつ入っています。
定期タスクの回は、最初の依頼文が <scheduled-task name= で始まっていました。

Windows の PowerShell なら、次のコマンドで、結果の返っていない道具がある回を並べられます。

Get-ChildItem "$env:USERPROFILE\.claude\projects\*\*.jsonl" | ForEach-Object {
  $t = [IO.File]::ReadAllText($_.FullName)
  $task = [regex]::Match($t, '<scheduled-task name=\\"([^\\"]+)')
  if ($task.Success) {
    $used = [regex]::Matches($t, '"type":"tool_use","id":"([^"]+)","name":"([^"]+)"')
    $done = [regex]::Matches($t, '"tool_use_id":"([^"]+)"') | ForEach-Object { $_.Groups[1].Value }
    $open = @($used | Where-Object { $done -notcontains $_.Groups[1].Value })
    [pscustomobject]@{
      Started = [regex]::Match($t, '"timestamp":"([^"]+)"').Groups[1].Value
      Task    = $task.Groups[1].Value
      Waiting = ($open | ForEach-Object { $_.Groups[2].Value }) -join ","
    }
  }
} | Where-Object { $_.Waiting } | Sort-Object Started | Format-Table -AutoSize

Started は、その回が始まった時刻（世界標準時）です。
Task はタスクの名前で、Waiting に出るのが結果を待ったままの道具の名前になります。

11月10日に、部下役のAIにこれを僕のPCの記録で流してもらいました。
10月27日と10月29日の回が、Edit の結果待ちとして出ています。
記録に残っていた止まり方と、そのまま合いました。

ただ、ここに出る回がすべて許可待ちとは限りません。
途中で中断した回なども混ざると見ています。
反対に、あとで確認が閉じられた回は結果が付くので、ここには出ません。
11月1日の回がそうでした。
気になる回は、タスクの詳細画面の履歴（History）から開いて確かめます。
公式の説明では、会話記録は既定で30日より古いものから自動で消されます。

抜けた分は、手でやり直した

止まった回の仕事は、あとから手でやり直しています。

年に1回の統計データ：10月28日に、最新の年の版へ手で差し替えた
毎朝の再生数の記録：11月2日に記録の道具を手で動かし、止まっていた日のメモもまとめて書いた

止まったまま残った回は、その回の会話で停止を押せば片づく見込みです。
ここはまだ確かめていません。
別の会話の Claude から止めようとしたら、自動の判定で断られました。
停止を押すのは、僕の役目になっています。

11月1日の回は、11月3日の15時18分に、確認が答えのないまま閉じられて終わっていました。
記録には Tool permission stream closed before response received と残っています。
その1分後に次の回が始まり、毎朝の記録の表には11月3日から11月10日まで毎日の行があります。
確認を閉じたのが停止ボタンなのか、アプリの開き直しなのかは、記録に残っていません。

モードは、まだ変えていない

直し方は2つ考えています。
タスクを Auto モードにするか、書き込み先ごとに許可を足すかです。
どちらも設定の変更なので、11月2日の点検の時点でも決めていません。

その代わりに、タスクを作る・直すときの決まりを足しました。
読む場所も書く場所も、作業フォルダの中で終わるようにします。
定期タスクの結果を信じる前に、できたはずのファイルが本当にあるかも見ることにしました。

公式の説明には、別の避け方も載っています。
タスクを作ったあと Run now で1回動かし、出た確認に「常に許可」を選んでおく方法です。
フォルダの中のファイル編集なら、タスクの権限モードを Accept edits にするよう書かれています。
僕はまだ、どちらも試していません。

実行されなかった日と、スマホに届かなかった通知

許可待ちとは別に、原因まではつかめていない件が2つあります。

1つ目は、10月30日と31日に、全部の定期タスクが動かなかったことです。
止まった回を抱えていないタスクも含めてでした。
11月1日の16時59分に、そろって走り直しています。
曲の配信登録も、10月30日の分は動かず、11月2日に会話の中で手で入力しました。
11月4日にも、10時の回が19時52分に動いています。

公式の説明では、ローカルの定期タスクは、アプリが開いていてPCが起きているときだけ動きます。
起動したときに、過去7日の取りこぼしを1回だけ走らせる、とも書かれていました。
11月1日にそろって動いたのは、この動きとつじつまが合います。
ただ、その2日間にPCやアプリが動いていたかは記録に無く、原因は確かめられていません。

2つ目は、スマホへの通知です。
定期タスクの中で、Claude にスマホへ知らせを送らせても届かなかったことがあります。
送るのは PushNotification という道具です。
会話記録を見直すと、道具からの返事は2通りでした。
1つは Mobile push not sent (Remote Control inactive). です。
もう1つは Not sent のあとに this terminal is active と続き、画面に出ているので通知は要らない、という返事でした。
10月10日から11月1日までの回で、前者が3回、後者が4回あります。

Remote Control は、スマホのアプリから手元のセッションにつなぐ機能です。
公式の説明では、スマホへのプッシュ通知は Remote Control が有効なときに送れます。
ターミナルに入力中やフォーカス中は、通知を飛ばすとも書かれていました。
1つ目の返事は、前半の条件のとおりです。
2つ目は、ターミナルが使われているとみなされた返事で、後半の条件に近いと見ています。

いまは、大事な知らせを通知に頼っていません。
次の会話の最初に、部下役のAIが拾うようにしています。