Claude Code 5時間制限の「残業」機能｜Proは週1回・Maxは毎回、週次枠の代償

Claude Codeが5時間制限に達しても、作業を区切りまで終えてから止まるようになった。PC Watchが「残業」と呼んだ新機能だ。

「使用量の上限に当たる最悪のタイミングは、リファクタリングの途中だ。3ファイルは編集済み、2ファイルは手つかず、テストは赤。そこでClaudeが、ただ……止まる」

Linuxマシンで無人のClaude Codeジョブを回している開発者、Samuel Lawrentz氏はブログにそう書いた（出典: Samuel Lawrentz、2026年9月26日。日本語は筆者訳）。誰も見ていない時間に起きるので、一番嫌いな失敗だったという。

この「途中で止まる」問題に、Anthropicが手を入れた。2026年9月25日（米国時間）、開発者向けアカウント @ClaudeDevs が発表した内容の趣旨は次のとおりだ。

Claude Codeは今後、作業の途中で5時間制限に達したとき、編集の途中で打ち切るのではなく、キリの良い停止ポイントを探すようになる。週次の上限から少量の固定枠を借りて、できるところまで片付ける。 （出典: @ClaudeDevs、2026年9月25日。日本語は筆者訳）

PC Watchはこれを「残業」と呼んだ（出典: PC Watch、2026年9月28日）。言い得て妙だ。本記事では、英語圏の報道に倣ってこの機能を「ラップアップ（wrap-up）」とも呼ぶ。そして残業である以上、代償は別の場所から払われる。

Claude Codeの「残業」（ラップアップ）で何が起きるのか

Claude Codeの利用枠は2層ある。5時間ごとのセッション枠と、週次の枠だ。どちらも全モデル共通で、使用量は両方に同時に積み上がる（出典: Claude Code Docs - Errors）。

これまでは、5時間枠を使い切った瞬間にセッションが止まった。ファイルは書きかけ、テストは未実行、説明は文の途中。人間が戻ってきて、どこまで進んだかを確かめるところから再開する必要があった。

9月25日以降、Claudeは止まる前に少しだけ作業を続け、区切りの良い地点で停止する。対応環境はターミナル、IDE、Web、Slackと報じられている（出典: VibeHacker）。

前出のLawrentz氏によると、このときClaudeには「今すぐチェックポイントを作れ。現在のステップを終え、最も重要な残作業を最大3点の短い箇条書きで示せ」という趣旨の指示が渡るという（出典: Samuel Lawrentz。日本語は筆者訳）。対象バージョンについては、後述するAgent Fleetのissueがv2.1.277以降と記している。

プランによる違いは次のとおりだ（出典: PC Watch、TechnoEdge、KuCoin）。

プラン	ラップアップの発動
Pro	週1回のみ
Max	5時間制限に達するたび（週次枠が残っている場合）
Team Premium	5時間制限に達するたび（週次枠が残っている場合）

Team Premium以外のTeam・Enterpriseプランでの扱いは、報道では触れられていない。

Proは週に何度5時間枠に当たっても、ラップアップが入るのは1回だけになる。2回目以降は従来どおり、その場で止まる。ラップアップのあとも続けたい場合は、usage credits（追加利用枠）で継続できる（出典: PC Watch）。

5時間制限の「自動継続」とはどう違うのか

ここは混同しやすい。2026年8月、Claude Codeには「自動継続」が入った。使用量の上限で止まったセッションが、リセットを待って自分で続きを始める機能で、ターミナル版はv2.1.234から既定オンになっている（出典: Claude Code Docs - Interactive mode）。詳しくは自動継続の記事にまとめた。

2つの機能は、止まる前と止まった後を分担している。

• ラップアップ: 止まる直前に、区切りまで片付ける（週次枠を少し使う）
• 自動継続: 止まった後、リセットを待って再開する（追加の枠は使わない）

組み合わせると、「区切りで止まり、リセット後に続きから再開する」という流れになる。引き継ぎの観点では、これは品質の改善だ。書きかけのファイルを再開する場合、Claudeは前回どこまで進んだかを推測するところから始めることになる。区切りで止まっていれば、その推測がいらない。

なお、自動継続は /config の「Continue automatically at usage limit」でオフにできる。一方、ラップアップをオフにする設定は、10月2日時点で公式ドキュメントにも変更履歴にも見当たらなかった。筆者が公式の変更履歴を確認した範囲では、v2.1.277〜v2.1.287の項目にラップアップへの言及はない。サーバー側で制御されている機能と考えられるが、公式の説明はないため断定はできない。

歓迎の声と、冷めた声

反応は割れている。

TechnoEdgeは「編集の真っ最中で動かないまま次のリセットまで止まるよりは、分割したタスクの区切りまで進めばテストなりを回しやすい、QoL向上になる変更」と評価した（出典: TechnoEdge、2026年9月28日）。

KuCoinのニュース記事は、途中停止のたびに「中途半端な変更が残り、手で直す羽目になる」という開発者 @tochukwudev の不満を紹介している。同記事によれば、この機能を理由にCodexから乗り換えると言う開発者がいる一方で、5時間制限そのものが乗り換えを阻む壁だという声もあった（出典: KuCoin、2026年9月28日。いずれも同記事経由の間接引用で、筆者は原投稿を確認していない）。

冷めた声の中心は、週次の上限だ。9月初旬に5時間枠だけをリセットする /limit-reset が見つかったときも、Redditでは「セッションだけのリセットなのが残念。自分の問題は週次の上限なんだ」というコメントが出ていた（出典: explainx.ai。同記事経由の間接引用で、筆者は原投稿を確認していない。日本語は筆者訳）。ラップアップも構造は同じで、5時間枠の終わり方を良くするが、週次の枠は増やさない。むしろ少し減らす。

9月14日には週次上限の恒久的な25%引き上げが実施されたが、それ以前のプロモーション期間と比べると実質約17%減になるという試算がある（出典: 窓の杜）。この算数は週次制限変更の記事で詳しく扱った。週次枠に余裕がないユーザーにとって、「週次枠から差し引く」という一文が引っかかるのは自然だ。

週次枠から引かれる量は非公開

筆者が一番気になったのはここだ。Anthropicは追加枠を「small, fixed（少量・固定）」としか説明していない。具体的な量は公表されていない（出典: madrobot.blog）。

PMの感覚で言えば、残業を認める制度そのものは良い。ただ、残業時間の上限が書かれていない就業規則は、運用する側が困る。週次枠の残りが少ないときに、ラップアップが週次枠をどれだけ使うのか。わからないまま使うことになる。

実際、使用量を監視するOSSツール「spillway」では、ラップアップが週次枠を目に見えない形で消費していないかを観測するissueが立っている（出典: GitHub - coderage-labs/spillway #218）。導入前の9月11日〜25日のデータでは、5時間枠が100%を超えた11回のエピソード中、週次の使用率の値が動いたのは1回、0.01だけだったという。導入後のデータで判断するとしており、結論はまだ出ていない。筆者自身はこの消費量を実測していない。

無人運用している人が気をつけること

ラップアップは、外部の自動化ツールにも影響しうる。

マルチエージェント運用ツール「Agent Fleet」のissueでは、自動継続とラップアップがどちらも、ツール側の上限検知をすり抜ける可能性が指摘されている（出典: GitHub - k-k1/agent-fleet #1422）。このツールは、上限到達時に出るメニューや、中断の記録を手がかりに再開をスケジュールしている。ラップアップでターンがきれいに終わると、その手がかりが残らない可能性がある。issueでは対策案として、Claude Codeを autoContinueAtUsageLimit: false で起動し、再開をツール側に一本化する方法が挙がっている。

自前のスクリプトで「途中停止」を検知して再開させている人は、検知ロジックが今も機能しているか一度確かめたほうがいい。

Lawrentz氏は同じブログで、上限に備えた運用も勧めている（出典: Samuel Lawrentz）。

• 大きなタスクではまずTodoリストを作らせる
• タスク単位ではなく、ステップ単位でコミットする
• 使用率が90%近くになったら、並列処理を始めない
• 重い作業の前に /usage（使用量を表示するコマンド）で残量を確認する

ラップアップは「区切り」を探す機能なので、区切りが細かいほどうまく働く。ステップ単位のコミットは、この機能と相性がいい。

電脳狐影ならこう使う

結論から言うと、この変更は歓迎する。途中停止のコストは、止まった瞬間ではなく、再開するときに払う。何が終わっていて何が終わっていないかを人間が調べ直す時間だ。それが減るなら、週次枠の少しの消費は払う価値があると判断する。

そのうえで、プラン別にこう動く。

Proプランの場合: ラップアップは週1回しかない前提で作業を刻む。5時間枠の終盤に大きなリファクタリングを始めない。/usage で残量が少なければ、その日は小さなタスクに切り替える。週1回の保険を、いつ使うか自分で選べるわけではない点は覚えておきたい。

Maxプランの場合: 特に何もしなくていい。ただし週次枠ぎりぎりで回している週は、ラップアップ分も週次から引かれることを計算に入れる。

無人運用の場合: 自動継続とラップアップの両方が既定で動く前提で、外部ツールやスクリプトの検知ロジックを点検する。あわせて、取り返しのつかない操作は permissions の deny 設定（特定の操作を禁止する設定）で止めておく。この点はauto modeの記事でも書いた。

週次の上限そのものに不満がある人には、この機能は答えにならない。そこは正直に書いておく。上限に頻繁に当たるなら、プランの見直しか、Sonnet 5.5へのモデル切り替えで消費を抑えるほうが効く。

技術的な内部実装については、PMとしての理解の範囲で書いている点を断っておく。

---

関連記事

• Claude Code自動継続が既定オン｜使用量リミットの切り方と再開1発目の罠
• Claude Code 9月14日の週次制限変更：「+25%増」は実質-17%削減の算数
• Claude使用制限が突然キツくなった理由｜ピーク時間帯の仕組みと7つの対策
• Claude Opus 5.5 & Sonnet 5.5：価格40%削減の衝撃と選び方の指針
• Claude Code auto modeが8月14日デフォルト化｜manualに戻す設定
• Claude Code Modsとは何か｜TypeScriptでAgentの動作を書き換える新機構

---

免責事項

• 本記事の情報は2026年10月2日時点のものです。Claude Codeの仕様や使用量の上限は予告なく変更される場合があります。最新情報は公式の変更履歴を参照してください。
• ラップアップ機能のプラン別の発動条件・対象バージョン・対応環境は、@ClaudeDevsの発表と各報道・GitHub issueに基づきます。@ClaudeDevsの投稿は報道経由で確認しており、筆者は原投稿を直接確認できていません。2026年10月2日時点で、公式ドキュメントにはこの機能の詳しい説明は見当たりませんでした。
• 引用した英語の投稿・記事は筆者による翻訳であり、意訳を含みます。KuCoin経由で紹介した開発者の発言は間接引用で、筆者は原投稿を確認していません。
• GitHub issueやブログでの観測・報告は各ユーザーの環境における情報であり、Anthropicの公式見解でも筆者が再現検証したものでもありません。
• usage creditsは標準のAPI料金で課金されます。料金には別途税が課される場合があり、為替により円建ての負担額は変動します。
• 本記事はAnthropic社およびその関連会社と提携・提供関係にあるものではなく、内容は筆者独自の見解です。本記事にアフィリエイトリンクは含まれません。

※ 記載の会社名・製品名は各社の商標または登録商標です。