CLAUDE LABEN
SUNSET — 旧 Workbench の廃止は本日8月17日です。保存済みのプロンプト・プロンプトバージョン・eval は当日以降アクセスできなくなるため、Export での退避は今日が最後の機会ですAPI — /v1/experimental/generate_prompt・improve_prompt・templatize_prompt も同日で停止します。停止後はエラーが返るため、これらを呼ぶスクリプトは今日中の切り替えが必要ですCONSOLE — 後継の Workbench は Console 上のステートレスな構成になります。サーバー側に作業を保存せず、下書きはブラウザに残り、任意のリクエストをコードとして書き出せますOSS — Claude for Open Source が Claude Max 20x を6か月無償提供しています。受け入れは最大1万人で、個人単位の付与、API クレジットもチーム共有も自動有料化もありませんQUOTA — Claude Code 契約者向けの週次利用枠 50% 上乗せは8月19日までです。残り2日となりましたSELF-HOSTED — Claude Code のセルフホスト環境がパブリックベータです。自社インフラでセッションを動かし、内部ネットワークと独自ツールを使えます。Team と Enterprise が対象ですSUNSET — 旧 Workbench の廃止は本日8月17日です。保存済みのプロンプト・プロンプトバージョン・eval は当日以降アクセスできなくなるため、Export での退避は今日が最後の機会ですAPI — /v1/experimental/generate_prompt・improve_prompt・templatize_prompt も同日で停止します。停止後はエラーが返るため、これらを呼ぶスクリプトは今日中の切り替えが必要ですCONSOLE — 後継の Workbench は Console 上のステートレスな構成になります。サーバー側に作業を保存せず、下書きはブラウザに残り、任意のリクエストをコードとして書き出せますOSS — Claude for Open Source が Claude Max 20x を6か月無償提供しています。受け入れは最大1万人で、個人単位の付与、API クレジットもチーム共有も自動有料化もありませんQUOTA — Claude Code 契約者向けの週次利用枠 50% 上乗せは8月19日までです。残り2日となりましたSELF-HOSTED — Claude Code のセルフホスト環境がパブリックベータです。自社インフラでセッションを動かし、内部ネットワークと独自ツールを使えます。Team と Enterprise が対象です
記事一覧/Claude Code
Claude Code/2026-07-03中級

増えた枠を基線に混ぜない — 週次上限+50%の期限付きウィンドウでバックログを片づける設計

Claude Code の週次上限が7/13まで50%引き上げられました。期限付きの余裕を日常の実行頻度に混ぜず、終わりのあるバックログ消化だけに使うためのバーストキュー設計と、期限後の基線膨張を検出する台帳をコード付きでまとめました。

Claude Code223レート上限2自動運用17スケジューリング2バックログコスト管理13

プレミアム記事

6月の最終週、私自身の定期実行を1日40回から36回へ整理したばかりでした。使用量が想定を超えていたためで、どのタスクを残すかをかなり慎重に選んだ記憶が新しいところです。その直後に、Claude Code を含む各プロダクトの週次上限が7月13日まで50%引き上げられるという知らせが届きました。減らした翌週に増える、という間の悪さに少し笑ってしまいましたが、増えた枠を眺めて最初に浮かんだのは「積み残しの一括処理に使えるのではないか」ということでした。

ただし今回の引き上げには期限があります。7月13日を過ぎれば枠は元に戻ります。この「期限付き」という性質を軽く見ると、期限の翌朝に自動運用が壊れます。ここで共有するのは、期限付きの引き上げ枠を日常の処理量(基線)に混ぜずに、終わりのある仕事だけを流し込むための設計です。動くコードと、個人開発の現場で運用中の途中経過をあわせて置いておきます。

期限付きの引き上げは「借りた枠」です

恒久的な引き上げと期限付きの引き上げは、数字の上では同じ「+50%」でも運用上はまったくの別物です。

基線、つまり毎日・毎週決まって流れる処理量を、引き上げ後の枠に合わせて150%に慣らしてしまったとします。7月14日に枠が100%へ戻った瞬間、基線を約33%削る必要が生じます(150 → 100 は 50/150 = 33.3% の削減です)。私のように定期タスクが数十本ある環境では、33%の削減は「どの3本に1本を止めるか」という選別作業そのものであり、6月末に一度やった苦しい整理をもう一度、今度は準備期間なしでやることになります。

一方、基線を据え置いて増分の50%だけを別枠として扱えば、期限日に何かを削る必要はありません。別枠に入れた仕事が終わるか、期限が来て別枠が閉じるか、どちらか早いほうで自然に終わります。

6月にレート上限が恒久的に倍増したときは、増えた余裕を再試行のヘッドルームに回して間隔は詰めない、という判断をしました(そのときの経緯はレート上限が倍増しても自動運用の間隔は詰めないに書いています)。恒久増なら「安定性に変える」が答えでしたが、期限付きの場合は話が逆で、安定性の設計に組み込んではいけません。期限とともに消える余裕を前提にした安定性は、期限とともに消えるからです。

窓に入れてよい仕事と、入れてはいけない仕事

では増えた枠で何を流すか。判定基準は「その仕事に終わりがあるか」の一点です。私は次の3つの質問で仕分けています。

質問はい → 窓に入れる候補いいえ → 窓に入れない
作業量は有限で、完了が定義できるか蓄積した統合キューの消化、過去記事の内部リンク一括監査、依存パッケージの棚卸し日次の記事生成、監視・巡回
期限までに終わらなくても、翌日の運用に支障がないか残った分を通常の低優先レーンへ戻せる仕事途中で止まると不整合が残る移行作業
期限後に「続けたい」と思わずにいられるか一度きりの点検・清算系実行間隔の短縮、品質ゲートの追加実行など、効果を体感すると戻せなくなる系

3つ目の質問が実は一番重要だと考えています。窓の期間中に「生成間隔を詰めたら品質チェックの回数が増えて安心感があった」というような体験をしてしまうと、期限後にそれを手放すのが心理的に難しくなります。設定は戻せても、習慣は戻しにくい。だから最初から、習慣になり得る種類の仕事は窓に入れないのが安全です。

私の環境での具体例を挙げると、窓に入れたのは「削除済み記事の統合キューに溜まっていた31件の処理」「4サイト分の内部リンク一括監査」「参照データの過去分の整合点検」の3種類で、いずれも件数が数えられて完了が定義できる仕事です。逆に、毎日の記事生成やブラッシュアップの本数はいっさい変えていません。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
期限付きの上限引き上げを日常の実行頻度に混ぜたとき、期限翌日に必要になる削減幅(-33%)の計算根拠と、恒久的な引き上げとの切り分け方
完了見込みが期限を超えるジョブを入口で拒否する、期限を知っているバーストキューの TypeScript 実装(一回性ジョブの許可リスト付き)
基線とバーストを別々に記帳する台帳の実装と、期限後に基線が漏れ膨張していないかを1つの比率で点検する手順
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

Claude Code2026-06-25
レート上限が倍増しても自動運用の間隔は詰めない — 増えた余裕は429対策に回す
Claude Codeのレート上限が引き上げられたとき、自動運用の間隔を詰めたくなる気持ちを抑えて、増えた余裕を再試行とバックオフに回した実例です。上限とクレジット消費を別の軸で考える理由、同時実行数を固定する判断、監視すべきは再試行回数だという結論をまとめました。
Claude Code2026-07-18
headless の Claude Code を止めたのに、ビルドだけが生き残っていた — exit 143 を前提に停止処理を設計する
headless モードの Claude Code が Bash 実行中に SIGTERM を受けると、コマンドのプロセスツリーが孤児化していました。2.1.212 の修正で挙動は exit 143 に変わります。この契約を前提に、監督スクリプトと後片づけを設計し直す手順をまとめます。
Claude Code2026-07-18
プランモードを「読むだけ」と信じていた — 前提を機構で確かめ直す
Claude Code 2.1.212 で、プランモードがファイルを変更する Bash を許可プロンプトも canUseTool も通さず実行していた不具合が修正されました。前提が崩れていた期間に何が起きうるのか、手元で確かめる方法と、モード名に安全性を預けない設計をまとめます。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →