Claude Codeのトークン制限を制御するcron戦略と実務活用
導入
LLMツールを使っていると、突然トークン制限に達して作業が止まることがある
特にClaude Codeはローリングウィンドウ方式のため、リセットタイミングが読みづらい
結果として
- 作業が中断される
- 計画が崩れる
- 集中が途切れる
この記事では、トークンリセットを「予測可能」にする方法を整理する
この記事では次のことをまとめます
- Claude Codeのトークン制限の仕組み
- cronによるリセットタイミング固定
- 実務で使える運用パターン
内容まとめ
トークン制限の仕組み
Claude Codeの制限は以下の特徴を持つ
- ローリングウィンドウ方式
- 最初のリクエスト時刻が基準
- 一定時間後に順次解放（例: 約5時間）
問題の本質
- リクエスト開始時刻が毎回ズレる
- リセット時刻が不定になる
- 予測不能なタイミングで制限到達
アプローチ
cronで基準時刻を固定
毎日同じ時間に軽いリクエストを送ることで
ローリングウィンドウの起点を固定する
0 7 * * * ~/.local/bin/claude --model haiku -p 'おはよう' 2>&1 &> /dev/null
仕組みの動き
例として5時間ウィンドウで考える
- 07:00 自動リクエスト実行
- → この時刻が基準になる
- 12:00 前後でトークン解放
結果
- 午前中にトークンを使い切る前提で動ける
- 昼以降に再び使える状態になる
実務での使い方
パターン1 集中消費型
- 午前に一気にトークン消費
- 昼にリセット
- 午後も継続利用
パターン2 分散利用型
- リセットタイミングを基準にタスク分割
- 高負荷処理をリセット直後に配置
パターン3 チーム運用
- チーム全体で基準時刻を揃える
- 利用ピークを分散
メリット
- リセット時刻が予測可能
- 作業計画に組み込める
- トークン枯渇による中断を回避
注意点
- ウィンドウ時間はプラン依存
- API仕様変更の影響を受ける可能性あり
- 無駄なリクエスト設計はコスト増につながる
技術者視点の考察
この手法の本質は「制約の制御」
一般的な対応
- 制限に従う
- 制限に振り回される
この設計
- 制限の起点を操作する
- システム挙動を前提に設計する
なぜ重要か
LLMは外部サービスであり
- レート制限
- トークン制限
- レスポンス遅延
など不確定要素を持つ
これを放置すると
- 開発効率が不安定になる
- チーム生産性がブレる
このアプローチの価値
- 不確定要素を「計画可能なリソース」に変換
- 作業スケジュールと同期可能
- CIやバッチとの連携も視野に入る
学び
今回のポイント
- ローリングウィンドウは設計で扱える
- cronで時間軸を固定できる
- 制約は回避ではなく制御する
まとめ
トークン制限は避けられないが
扱い方によって影響は大きく変わる
リセットタイミングを固定することで
LLM利用は「運」から「設計」へ変わる
小さな工夫だが、日々の開発効率に直結する