この記事で解決できること
- Claude Max の使用量が突然枯れる原因（2種類ある）
- Tokenocalypse バグ（GitHub issue #22943）の概要
- 5時間ローリングウィンドウの「見えない消費」が発生する条件
- 予測可能な使い方に切り替えるための判断軸
環境
- Claude Max プラン（5x または 20x）
- Claude Code を日常運用している個人開発者
- スケジュール実行・ルーティンで自動化している場合も対象
結論
Claude Max の使用量が突然枯れる問題には 2 種類の原因があります:
1. 設計上の予測しにくさ
5時間ローリングウィンドウは「今どれだけ残っているか」がリアルタイムで UI に出ない。大量消費した 5 時間前を把握していないと、制限到達タイミングが読めない。
2. Tokenocalypse バグ（GitHub issue #22943）
実際の消費量と報告される消費量が乖離するバグ。内部的なトークンカウントが正しく処理されず、制限に届いていないのに枯渇判定が出るケースが報告されている。
どちらも「払った料金が足りない」ではなく「残量が把握できない / 予測と実態がズレる」問題です。
5時間ローリングウィンドウの仕組みと落とし穴
Claude Code の Max プランは過去5時間の使用量が一定を超えるとレート制限が発動します。
過去5時間の使用量 > しきい値 → レート制限発動
重要なのは「現時点から過去5時間」という動くウィンドウです。
午前10時に大量使用しても、午後3時には午前10時分がウィンドウ外に出るので、制限は自然と緩和されます。
「見えない消費」が増えるパターン
| パターン | 理由 |
|---|---|
| 複数ファイルを並行編集 | 1ターンのコンテキスト量が増加 |
| 長時間セッション | セッション後半はコンテキスト蓄積でトークン消費が増える |
| 長い migration 生成 | 入出力どちらも大きくなる |
| cron・自動実行 | 人が見ていないうちに蓄積 |
Tokenocalypse バグとは
GitHub issue #22943「Tokenocalypse」は、実際の使用量と内部カウントが乖離するバグです（2026年確認）。
「さほど使っていないのに突然制限に当たった」場合は、このバグが原因の可能性があります。
判別方法
- 使いすぎた記憶がない状態で制限に当たった
- セッションを完全に終了して新規セッションを開始したら復帰した
Anthropic は issue #22943 を認識済みで対処中（2026年9月時点）。
対処法
1. タスク粒度を分割する
長大な1タスクより「小さな独立したタスク × 複数セッション」の構成にすると、1回あたりのトークン消費が安定します。
# NG: 大きなタスクを1セッションで処理
claude "全ファイルをリファクタして migration も書いて PR も出して"
# OK: タスクを分けてセッションを分割
claude "src/lib/auth.ts をリファクタ"
claude "migration_20260917.sql を生成"
2. 大量消費の時間設計
- 大きな作業は夜間や朝一に集中させる
- 日中は軽い問い合わせや短い編集に限定する
- 5時間ウィンドウの衝突を回避できる
3. Tokenocalypse 疑いの対処
突然の枯渇で「使いすぎた記憶がない」場合:
- セッションを完全終了
- 新しいセッションを開始
- バグ起因なら新セッションで復帰することが多い
まとめ
Claude Max の「突然枯れる」は金額の問題ではなく、設計上の残量不可視性 + Tokenocalypse バグが組み合わさった予測困難性の問題です。
| 原因 | 対処 |
|---|---|
| ローリングウィンドウの可視化不足 | 時間設計・タスク分割 |
| セッション後半の消費増 | 1セッション1タスク原則 |
| Tokenocalypse バグ | 新セッションで再試行 |
AI ツールを業務に組み込む設計の実験ログを書いています。 https://masatoman.net