Claude Code Routinesの警告8種 — 「The last run」の読み方

Routines(スケジュール実行)の詳細ページで、Historyの上に「The last run didn't start because …」と始まる警告が出ることがあります。警告は全部で8種類あり、タスクを直す必要があるものと、待つかRun nowを押すだけで済むものに分かれます。

先に分かれ目を言うと、「組織の同時実行上限」「一時的な問題」「利用上限」「Failed」の4つは設定を触らなくて済みます。残りの4つは、タスクのEditかGitHub側の確認が要ります。

警告の表示場所と、消えるタイミング

警告は、タスクの詳細ページのHistoryに出ます。文頭が「The last run」で始まるので、下の表の左列から該当する文を探せば、次の一手が分かります。

警告は、その後に実行が1回始まれば消えます。つまり直したあとにRun nowで1回走らせれば、警告が消えたかどうかで直ったかを確かめられます。

なお、この機能は現在scheduled tasksという名前で説明されており、画面やURLには「Routines」の名前が残る場合があります(claude.ai/code/routines など)。警告の文面は同じです。

8種の警告と直し方の早見表

以降は、直し方が分かりにくい警告を個別に掘ります。

同時実行上限と一時的な問題 — 触らずに待つ警告

「cloud sessions running at once」の警告は、タスク側に原因がありません。組織全体で同時に動くクラウドセッションの数が上限に達しており、その間に起動時刻を迎えた実行が始まらなかった、という意味です。

直し方は2つしかありません。時間を置いてRun nowを押すか、次の定刻を待つかです。プロンプトや環境を書き換えても結果は変わりません。

「usually temporary」の警告と「The last run failed.」も同じ扱いです。再試行か次回待ちで足ります。ただし失敗した実行にはセッションがないので、「失敗の中身をセッションで読む」ことはできません。原因を探したいときは、CLIから次のように聞く方法があります(Claude Code v2.1.227以降)。

/schedule why did my nightly review do nothing this morning?

タスクの直近の実行が実行状況つきで並び、実行ログからツールエラーや権限拒否、最終結果まで読んで説明してくれます。

「環境が見つからない」— Editで環境を選び直す

「cloud environment couldn't be found or used」は、タスクに紐づく実行環境が消えた、または自分のアカウントで使えなくなった場合に出ます。

直す手順は次のとおりです。

セレクタがUnavailable environmentでなければ、環境自体は選べる状態です。この場合は詳細ページのRun nowで再試行するか、セレクタで別の環境に切り替えて保存します。

環境を切り替えると、ネットワークアクセスの設定も切り替わります。タスクは実行のたびに環境のネットワークポリシーを引き継ぎます。Default環境はTrustedのネットワークアクセスで、許可リストにないホストへの通信は 403 と x-deny-reason: host_not_allowed で失敗します。環境を替えたあとで外部への通信が失敗しはじめたら、新しい環境のAllowed domainsを見直してください。組織共有の環境は、タスク側からは読み取り専用で開きます。

環境そのものの仕組みはClaude Code Webのクラウド環境、組織共有の設定はcloud environmentの組織共有で扱っています。

「blocked」と「repository or branch」— どちらもGitHub側を疑う

この2つは文面が似ていますが、見る場所が違います。

実行は、プロンプトで指定がなければリポジトリの既定ブランチから始まります。既定ブランチの名前を変えた、リポジトリを移した、削除した、といった変更があった場合は後者の警告に当たります。GitHubトリガーで起動した場合、最初のリポジトリはPRのheadコミットから始まります。

GitHubアクセスの付与方法は2通りです。Claude GitHub Appを入れる方法と、ターミナルで /web-setup を実行して手元の gh トークンを送る方法です。Team・Enterpriseでは、どちらも組織のOwnerが有効にしておく必要があります。

警告が「repository or branch」のままでも、72時間を過ぎていれば、実はタスクがオフになっているだけかもしれません。詳細ページ上部のオン・オフのスイッチも見てください。

「settings weren't accepted」— 手がかりのない警告の点検順

「some of its settings weren't accepted」は、直し方がいちばん手探りになる警告です。Editのダイアログはどの設定が受け付けられなかったかを示してくれません。点検するのは、タスクの名前・プロンプト・モデル・リポジトリ・環境・コネクタ・トリガーの7項目です。

点検の優先順位に決まりはありません。順番を自分で決めるなら、最近変えた項目から見るのが近道です。リポジトリを足した直後なら、まずそこです。コネクタも、接続先を外したり、認証を失効させたりした直後に疑う価値があります。コネクタ側の承認エラーは別の症状で、RoutinesでMCP承認エラーが出る原因を参照してください。

「usage limit」— 戻る時期は上限の種類で変わる

「stopped because a usage limit was reached」は、サブスクの利用量の上限です。Routinesの実行はサブスクの利用量を、対話セッションと同じ形で消費します。

利用量の上限に達したとき、使用量クレジットを有効にしている組織なら、従量課金の超過分でスケジュール実行を続けられます。クレジットがなければ、利用量のウィンドウが戻るまで追加の実行は拒否されます。クレジットの設定は claude.ai/settings/usage で、Team・Enterpriseでは管理者が組織向けに有効にします。サブスクを一時停止している間は、タスクも保留されます。再開したら、タスクをオンに戻してください。

利用量の上限とは別に、起動手段ごとに1時間あたりの回数上限があります。

これらの回数上限に超過分の従量課金はありません。「usage limit」の警告の戻り時期は、サブスクの利用量のウィンドウに左右されます。API起動の手順はfire APIでRoutineを外部から起動する手順にまとめています。

Succeededと表示されても、作業が済んだとは限らない

Historyの各行は、実行の結果を末尾の表示で示します。失敗した実行にはError、キャンセルされた実行にはCancelledが付き、成功した実行は何も付きません。

ここで注意したいのは、Succeededはセッションが正常に終わったことしか意味しない点です。ネットワークでブロックされた通信、使えなかったコネクタのツール、Claudeがやり切れなかった作業は、行ではなくセッションの記録に残ります。プロンプトが求めた仕事が済んだかは、実行を開いて記録を読まないと分かりません。

成功した実行のセッションをアーカイブすると、その実行はCancelledに変わります。この場合、タスクを直す必要はありません。

警告別の切り分け順

警告の文面を覚えなくても、次の順で見れば足ります。

Routinesの全体像に戻りたいとき

トリガーの種類や、権限の扱い、作成手順はClaude Code Routines完全ガイドにあります。サイドバーにタスクが出ない症状は、警告とは別の不具合としてRoutineがサイドバーに表示されない不具合で扱っています。

警告が出るたびにタスクを作り直す必要はありません。8種のうち、設定を書き換える対象になるのは環境・設定不受理・GitHubまわりの4つです。残りは待つか、Run nowを押せば足ります。