毎朝と毎晩、私は自分の自動化ループにブログの記事執筆と公開まで任せています。この記事も、実はそのループが回している最中に「あ、これは自分で書かなきゃ」と思ったネタです。Claude Codeの利用上限に引っかかって処理が止まる。これが、そのループを組んでいて一番厄介な事故でした。
Claude Codeを使い倒している方なら、利用上限（usage limit）で実行が途中で止まった経験、一度はあると思います。対話中に止まるだけなら「もう一声待とう」で済みますが、私のように夜間・早朝に無人で長時間の自動化ループを回していると話が変わってきます。上限に当たった瞬間のプロセスがそのまま死んで、次にいつ復帰できるかも分からない。しかも困ったことに、ちょうど作業ファイルを書き換えている途中でコミットしていない、というタイミングで止まることがあるのです。
最初の頃は、朝起きてログを見て「あれ、昨夜のタスクが途中で止まっている」と気付くところから始まっていました。原因を追うと、決まって利用上限に当たったタイミングでプロセスがそのまま終了しています。厄介なのは、そこで止まったファイルの状態です。編集途中のコードが半端に残っていたり、コミットする前提で進めていた変更が未保存のままだったり。次に手動で再実行しても、Claude Code自身は「自分がどこまでやったか」を覚えていません。同じ作業をもう一度やり直そうとして、さっき書きかけたコードと衝突する。これを何度か繰り返して、さすがに人間が毎回気付いて手で直すのは無理だと悟りました。
自作の回避策：復旧コミットしてから続きに戻る
この事故に何度もやられたので、私は自分の自動化ループに手作業でルールを組み込みました。誰かに教わったわけではなく、痛い目を見た回数だけルールを足していった、という方が正確です。ループの起動時に必ず通す前段の処理として、こんな仕組みを入れています。
- 実行のたびに、進捗を示す短い一行を記録しておく（どこまで終わったかのチェックポイント）
- 次回起動時、まずこのチェックポイントを読む
- もし前回未コミットの成果物が残っていたら、それを「復旧コミット」としてまず退避してから、チェックポイントの続きの作業に戻る
要するに「上限で死んだら、次に生き返ったときにまず現場復旧してから続きをやる」というだけの、地味な運用ルールです。ただこれ、自分でプリフライト手順としてルール化するまでは何度も痛い目を見ました。上限に当たって強制終了→次の起動でチェックポイントを見ずにゼロから再実行→半端に書きかけのファイルと衝突、というパターンを2、3回はやらかしています（正直、最初の頃は原因調査だけで小一時間溶かしていました）。
v2.1.234のリリースノートを見て二度見した
そんな折、Claude Code v2.1.234（2026-08-17付、releasebot.ioのアップデート情報より）のリリースノートを眺めていて、思わず二度見しました。書いてあったのはこういう内容です。
「Claude Codeは、claude.aiの利用上限がリセットされたタイミングで、セッションを自動的に継続するようになった。これは /config でオフにできる」という趣旨の記述です。設定項目としては「Continue automatically at usage limit」というトグルが用意されている、とのことでした。Desktop版のほうにも似た仕組みが入っていて、セッション上限に達した際に出てくる「limit card」に「Auto-continue when limits reset」というチェックボックスが追加された、という報告も見つかりました。
つまり「上限に当たる→リセットを待つ→自動で処理を継続する」という、まさに私が手作業でルール化していたパターンの前半部分（待ってから再開する、という部分）を、CLI本体がネイティブに面倒を見てくれるようになったわけです。1年前の自分に教えてあげたい話でした。
これが効いてくる場面は、私の場合だとだいたい決まっています。深夜から早朝にかけて長めのタスクを走らせているとき、平日昼間にコード量の多いリファクタリングを任せているとき、そして複数のタスクを連続で消化させる無人ループを回しているとき。どれも「人間が画面の前にいない時間帯に上限へ当たる」パターンです。今までは、上限に当たった瞬間にそこでループが完全に止まり、次に人間が気付くまで何もしない時間が発生していました。自動で継続してくれるなら、この「気付くまでの空白時間」がそのまま丸ごと消えることになります。地味ですが、無人運用の実効性という意味ではかなり大きい変化だと思います。
ただし、正直なところ全部が置き換わるわけではなさそう
ここで少し慎重になっておきたいところです。リリースノートを読む限り、公式に明言されているのは「上限リセットを検知してセッションを自動継続する」という点までで、私が自作していた仕組みのもう半分——止まった瞬間に残っている未コミットの成果物をどう扱うか、という部分——について詳しい挙動は書かれていませんでした。待機のポーリング間隔やトリガーの正確な判定ロジックといった技術的な内部動作も、公開情報からは読み取れませんでした（この記事執筆時点でreleasebot.ioの記述を確認した範囲では、という留保付きです）。
なので「セッションの継続」と「作業ファイルの復旧」は、たぶん別レイヤーの話として捉えたほうが安全です。上限で死んだ瞬間にgit的な意味でコミットされていない変更がどう扱われるかは、私の運用ではまだ自分でチェックポイントとrecovery commitのルールを持っておいたほうが安心だと思っています。餅は餅屋というか、CLIが面倒を見てくれる範囲と、自分のワークフロー側で担保すべき範囲は分けて考えたほうがよさそうです。
もう一つ気になっているのは、自動継続そのもののコスト感覚です。人が介在せずに「リセットされたら即座に続きをやる」を繰り返すと、当然その分の利用枠を消費します。長時間ループを回している身としては便利この上ないのですが、意図せず動き続けてほしくない場面（一時的に作業を止めたい、コストを抑えたい時期など）もあるはずです。そういうときのために /config のトグルでオフにできる、という設計は理にかなっていると思いました。逆に言えば、デフォルトでオンなのかオフなのか、自分の手元でまだ確証が持てていません（これは実際に触って確かめるしかなさそうです）。
それでも「公式機能になった」ことの意味は大きい
とはいえ、これは素直にありがたい話です。今まで「上限で落ちたら人間が気付いて再実行する」か「自分でリトライの仕組みを組む」しかなかったところに、CLI側の標準機能として自動継続の選択肢が用意された。長時間の自動化ループを組んでいる開発者にとっては、信頼して手放せる範囲が一段広がったということだと思います。
この「安全に自動実行を任せられる範囲が広がっていく」流れは、以前にオートモードがデフォルトになった話を書いたときにも感じたことと地続きです。毎回の承認を求めなくなったこと、上限のリセットを勝手に待って継続すること。どちらも「人間が張り付いていなくても回る」方向への一歩に見えます。無人実行を前提にするなら、Hooksで通知を飛ばす仕組みと組み合わせておくと、上限で待機に入った・自動継続した、といったイベントに気付きやすくなるはずです（このあたりは私もまだ実運用で検証中です）。
実際に /config を開いて「Continue automatically at usage limit」のトグルを確認してみましたが、デフォルトの状態や挙動の詳細まではこの記事の裏取りだけでは断定できませんでした。有効化して自分のループで試した後日談は、また改めて追記できればと思っています。
「自作の回避策が公式機能になる」のはこれが初めてではない
振り返ってみると、これは私にとって初めての経験ではありません。以前、Claude Codeが実行のたびに毎回許可を求めてくる仕様に対して、自分でHooksを組んで「危険な操作だけ止めて、それ以外は自動で通す」というルールを作っていました。その後にオートモードがデフォルト化されて、似たような判断をCLI本体が標準で持つようになった、というのも同じ構図です。自分が手作業で埋めていた運用の穴を、後から公式機能が塞ぎにくる。これがここ半年ほどのClaude Codeの進化の仕方だと感じています。
正直、こういうニュースを見るたびに「自分の工夫が無駄になった」とは思いません。むしろ逆で、自分が困っていたポイントが正しく困りどころだった、という答え合わせのような感覚があります。無人の自動化ループを長く回している人ほど、同じ壁に当たっているはずです。だからこそ公式機能として取り込まれる。というわけで、自分の運用ルールを手作りしておくこと自体にも意味があったと思っています。
長時間ループを組む人ほど、一度は自分の運用を見直すタイミング
私のように毎日ループを回していると、ログを延々と眺めているだけで疲れてきます。長時間の自動実行を無理なく監視するという意味では、ログを畳んで要点だけ見えるようにする話もあわせて読んでいただくと、無人運用の負荷を下げるヒントになるかもしれません。
もし今、自分の自動化ループの中に「利用上限で止まったらどうするか」の設計が一切ない、という方がいたら、今回の話をきっかけに一度見直してみることをおすすめします。やることはシンプルです。まず、今の自分のワークフローが上限で強制終了したときにどんな状態で止まるのかを、実際に一度再現して観察してみましょう。ファイルが半端な状態で残るのか、それとも綺麗に途中で止まるだけなのか。ここが分かっていないと、CLI側の自動継続機能だけに頼るのは少し怖いです。そのうえで、/config の「Continue automatically at usage limit」を有効にしつつ、自分の側では最低限「未コミットの変更を検知したら安全な形で退避する」くらいの保険は残しておく。これが今のところ私が辿り着いた落としどころです。
今回の自動継続機能は、派手な新機能ではありません。ですが、自分が地道に運用でカバーしてきた穴の一つが、公式機能として塞がれていくのを見るのは、なんというか感慨深いものがあります。同じように利用上限との戦いで自作の回避策を持っている方がいたら、どんな工夫をしているかコメントで教えてもらえると嬉しいです。私も自分の運用をもう少しシンプルにできそうな気がしています。
コメント