Claude Codeの利用上限リセット後に自動再開する設定と止め方
v2.1.234以降、Claude Codeは利用上限のリセットを待って作業を自動再開します。デフォルト挙動、Desktop版との違い、Hookでの検知、止め方をまとめます。
Claude Codeはv2.1.234以降、セッション枠や週次枠の利用上限に当たっても、そこで作業を止めません。開いたセッションの中でリセット時刻まで待ち、戻り次第そのタスクを自分で再開します。この自動再開はclaude.aiのサブスクリプションでサインインした対話セッションでデフォルトが有効で、/configの設定名はContinue automatically at usage limitです。
待っている間、画面の最下部にはこう出ます。
Usage limit reached · continuing automatically at 3:45pm · esc to cancelリセットを待つ間に何が起きるか
リセット時刻になると、表示はcontinuing shortlyを経てUsage limit reset · continuing automaticallyに変わり、Claude Codeは止まった時点の続きから作業を拾うための固定プロンプトを送ります。直前のメッセージをそのまま再送するわけではありません。
パソコンがスリープしていた場合は挙動が変わります。約30分を超えるスリープ中にリセット時刻を過ぎていたときだけ、表示はYour usage limit has reset · press enter to continueになり、Enterを押すまで再開しません。30分未満のスリープなら、そのまま自動で再開します。
待っている間に/usage-creditsで使用量クレジットを追加した、/upgrade後に再ログインした、/modelでモデルを切り替えた、のいずれかをすると、Claude Codeはその時点で利用可能かを確認し、使えるならリセットを待たずに再開します。ブラウザ側で行った契約変更や購入は自動では検知しません。opusplan(Plan Modeの間だけOpusを使い、実行フェーズではSonnetに切り替わる自動ハイブリッド設定)のようにプランモードを別モデルで動かす設定では、この早期再開は働かずリセットを待ちます。
再開したタスクが再び上限に当たった場合、Claude Codeは自分の判断で最大2回まで連続して待ちを再設定します。3回目に当たるとAutomatic continue stopped after repeated usage-limit hits · /rate-limit-options to try againと表示して止まります。
再開後のタスクは普通のターンと同じように動きます。つまり権限確認も通常どおり働くため、あなたが席を外している間に確認プロンプトでタスクが止まっていることもあります。自動再開は「上限が明けたら勝手に続行する」だけの機能で、無人での全自動完了を保証するものではありません。長時間放置する運用では、確認プロンプトが出にくい権限設定と組み合わせるか、次章のHookで停止を検知する仕組みを合わせて用意しておくと安心です。
Claude Codeが自分から待たないケースと、その手動操作
次の3つの状況では、Claude Codeは上限に当たっても自動では待ちを始めません。セッション枠と週次枠は同時に消費される仕組みで、まとまった作業を続けるとセッション枠がリセットされるより先に週次枠だけが尽きることがあります。週次のリセットは数日先になりやすく、24時間より先という条件に当てはまりやすい枠です。
| 状況 | 理由 |
|---|---|
| Remote Controlやagent teamのteammateセッション | 理由そのセッションの端末にいる人が手動で始める必要がある |
| リセットが24時間より先(週次枠など) | 理由自動で始める対象は当日中のリセットに限る |
| Opus/Sonnet限定枠に当たったが、別のモデルで作業中 | 理由次のターンでその上限に当たるとは限らない(opusplan等プランモードが限定枠側を使う設定は例外) |
これらのケースと、自動再開がオフのときは、自分の端末で上限に当たった回にリセット枠1回につき1度だけメニューが開きます。Remote Controlやagent teamのteammateセッションでは、/rate-limit-optionsを自分で実行してメニューを開きます。
/rate-limit-optionsこのメニューにはWait here, then continue automatically(待ってから自動再開)に加え、使用量クレジットを足す行と、プランを引き上げる行が並びます。claude.aiのサブスクリプションでのサインインが前提で、コマンドメニューの候補には出ないため名前をフルで打つ必要があります。待って自動再開する行だけがv2.1.234以降の要件で、クレジット追加・プラン引き上げの2行はそれより前のバージョンからあります。
上限に当たる前に残り時間を把握しておきたい場合は、/usageでプランの上限と各枠のリセット時刻を確認できます。さらに手前で先読みしたいなら、カスタムステータスラインにrate_limitsフィールドを足すと、上限に当たる前から残りの枠を画面に出し続けられます。Desktop版では、モデルピッカー横の使用量リングをクリックすると同じ情報が見られます。
自動再開そのものを提供しない状況
バックグラウンドセッションと-p実行ではメニューの行自体が出ません。APIキー・クラウドプロバイダー経由・従量課金のアカウントは請求がリクエスト単位のためリセットという概念がなく、待つ理由がありません。claude.aiログインを使わないLLM gateway経由の接続でも、待ちは提供されません。
CLIの設定とDesktop版のチェックボックスは別物
Desktop版のCodeタブには、セッション枠の上限カードにAuto-continue when limits resetというチェックボックスがあります(週次枠のカードにはありません)。オンにするとDesktop版がリセット後に中断したターンを自分で再試行し、カードに再試行時刻を表示します。
このDesktop版のチェックボックスと、CLIの/configにあるContinue automatically at usage limitは独立した設定です。片方をオフにしてももう片方には影響しません。CLIとDesktop版を両方使い分けている場合、自動再開を止めたいならそれぞれで個別にオフにする必要があります。/config自体もターミナルインターフェース専用のコマンドで、VS Code拡張のチャットパネルやDesktop版からは開けません。それらの環境で設定を変えるには、設定ファイルを直接編集するか、各アプリ自身の設定画面を使います。
止め方 — 個人設定と組織管理の両方
個人で止めるには、/configでContinue automatically at usage limitをオフにするか、ユーザー設定のautoContinueAtUsageLimitをfalseにします。
/config autoContinueAtUsageLimit=falseこのキーには注意点があります。key=value形式はオフにはできますが、オンには戻せません。無人実行を許可する設定という性質上、有効化は/configメニューでの明示的な確認操作を経る必要があるためです。
autoContinueAtUsageLimitは他のプロジェクト単位のキーと違い、リポジトリの.claude/settings.jsonからもオフにできる例外扱いです。ユーザー設定や管理設定側で値が指定されていなければ、リポジトリ側の設定でオフに倒せます。チームやEnterpriseでフリート全体の既定を制御したい管理者は、managed settings(managed-settings.jsonやMDMポリシー、claude.aiコンソールからの配信で組織が展開する設定)側でautoContinueAtUsageLimitを設定します。managed settingsは原則としてユーザー側のどの設定よりも優先される最上位層で、autoContinueAtUsageLimitもこの原則に従います。managed settingsが値を設定していない場合に限り、リポジトリ側のオフが有効になります。
Hookで自動再開の完了・失敗を検知する
自動再開の一連の動きは、Notification hookの3種類のマッチャーとして観測できます。バックグラウンドで長時間走らせるエージェントほど、待ちが再開せず終わったことに気づかず放置しやすくなります。quota_auto_resume_disabledをSlack通知や監視ツールに流しておけば、上限待ちのまま止まったセッションを人が気づく前に検知できます。
| マッチャー | 発火するタイミング |
|---|---|
quota_auto_resume_fired | 発火するタイミングリセット時刻、または待機中の操作(クレジット追加・プラン変更・モデル切り替え)で利用可能になり、タスクを再開したとき |
quota_auto_resume_stale | 発火するタイミング30分を超えるスリープ中にリセットが過ぎ、Enterを押すまで再開を保留しているとき |
quota_auto_resume_disabled | 発火するタイミング自動再開がオフだった、リセットが24時間より先に動いた、再開後も上限に当たり続けた、継続処理がモデルに届く前にブロックされた、のいずれかで待ちが再開せず終わったとき(EscやCtrl+Cでの手動キャンセルでは発火しない) |
この3種類はNotificationイベントのmatcherフィールドで指定します。いずれもv2.1.234以降が対象です。上限待ちの発生自体をSlack通知に流すような運用は、Claude Code Hooks完全ガイドのNotificationイベントの節を合わせて読むと設定しやすくなります。
待ちが途中で終わる他のケース
ここまでの状況以外にも、待ちは次の場合に再開せず終わります。
- 新しいプロンプトを送った(その内容を実行する)
- Claude Codeを終了した(セッション再開時に待ちは復元されない)
/loginでのアカウント切り替え、会話のクリアや巻き戻し、/resume、/teleport、/tuiでの再起動、Claude Desktop・バックグラウンドセッション・クラウドへの引き渡しなど、会話の主体が変わる操作をした- 継続プロンプトを止める
UserPromptSubmithookが働いた、またはモデルに届く前に処理が失敗した
Esc(空プロンプトの状態で)かCtrl+Cを押す、または/rate-limit-optionsでDon't continue automaticallyを選ぶと、明示的にキャンセルできます。キャンセル後は、そのリセット枠についてClaude Codeは自分からは待ちを再開しません。次のプロンプトを送るか、/rate-limit-optionsからWait here, then continue automaticallyを選び直す必要があります。
まとめ
利用上限に当たった直後の見分け方はClaude Codeの利用上限、リセット周期そのものはClaude制限の回復が扱っています。本記事が扱う自動再開は、リセットに当たったあとの「待つか・止めるか」を制御する設定です。個人で頻繁に上限へ当たるなら、リセットを待つより使用量クレジットの有効化のほうが作業の連続性は保てます。無人実行のCIやエージェントを長時間放置する運用では、Hookでの検知とautoContinueAtUsageLimitの管理設定を組み合わせて、待ちっぱなしのセッションが埋もれないようにしておくのが安全です。
要点を1つだけ持ち帰るなら、CLIの/configとDesktop版のチェックボックスは別の設定だということです。片方だけ確認して「もう止めたはず」と思い込むと、もう片方の環境では待ちが動き続けます。