Claude Codeの週次上限の消費が3.6倍との報告 — 9/25以降の測り方

Claude Codeの週次上限が、9月25日のリセットを境に約3.6倍の速さで減るようになった。GitHubのissue #97398に、こうした報告が投稿されました。投稿者の数字は、リセット前は「1%減るのに約93回の応答」、リセット後は「約30回」です。

コメント欄には、MaxだけでなくTeamシートやProの利用者も同じ症状を書き込んでいます。原因の特定や修正の告知は、12件のコメントのどれにも書かれていません。この記事では報告の中身を整理し、自分の環境で同じ比較をする方法を示します。

issue #97398の数字は何を言っているか

issue #97398は2026年9月26日に作られ、いまもopenのままです(ラベルは bug と area:cost)。バージョンは2.1.283、環境はmacOSと書かれています。

投稿者は、ローカルのトランスクリプトを応答ごとに重複排除して数えました。

「3.6倍」は、この約93回と約30回の比から出ています。投稿者は次の点も添えています。

• 平均コンテキストは前週273k、今週252kで、ほぼ同じ
• モデルの構成も、起動時のコンテキスト(約70k)も同じ
• 9月23日にアカウントへ追加クレジットが付与されていた

追加クレジットの付与がリセット直前だった点は、投稿者自身が時系列として書き添えているだけです。因果は示されていません。

同じ症状を書いた人の数字はどこまで揃うか

コメントには、条件の違う利用者が自分のトランスクリプトから出した数字が並んでいます。倍率は揃っていません。

注目したいのは、変化の起点がそろっていない点です。issue本文は9月25日のリセット、あるコメントは10月3日のリセット、別のコメントは9月24日の週から悪化しています。「ある日に全員一斉に倍率が変わった」という形ではありません。

もう一つ、倍率の幅も広いです。3.6倍は最大の報告で、他の計測は1.7倍から2.5倍あたりに散っています。投稿者ごとに、使い方もモデルもプランも違うためです。

原因として挙がった仮説と、検証された範囲

コメントでは、原因候補がいくつか提示されています。確定したものはありません。

スレッドで数字が出た利用者側の要因は、security-guidanceの約10%(本人の見積もり)とキャッシュミスの調査で、どちらも3.6倍は説明していません。サブエージェントの多用や長いコンテキストの再読み込みが効く環境は確かにあり、その切り分けはトークン消費が異常に早い原因と切り分け方にまとめています。一方で、同じ作業量・同じモデル構成を保ったまま減りだけが速くなったという報告が複数あり、そこが論点です。

別のissueで見えている近い症状

同じ area:cost ラベルの下に、時期の違う報告が少なくとも2件あります。

• #94211(9月14日): Windowsのバージョン2.1.270。以前なら週次の3〜4%で済んだPRレビューのワークフローが、5時間枠を95%まで使い、週次も12%に達した。投稿者は数字を測っておらず「手元の記憶」と断っています。
• #101937(10月14日): macOSのバージョン2.1.299。Opus 5.5で「30〜50%/日」減ると報告。コメントでは、週次は変わらず5時間枠だけが10月13日ごろから厳しくなったという別の計測が出ています。

3件は、減る速さが変わったという点で似ていても、変化したメーターと時期が違います。「全部が同じバグ」とは、スレッドの記述からは言えません。Opus 4.5の頃の上限強化は別の時期の話で、Opus 4.5の使用量上限が急に厳しくなった理由にあります。

自分の消費を測る手順

報告者たちの方法は、トランスクリプトの集計と、/usage の週次パーセントの突き合わせです。ここで一つ壁があります。トランスクリプトに、メーターの値は残りません。パーセントを後から思い出して書くと、サポートに「記憶違い」と言われかねません。

ステータスラインはこの穴を埋められます。公式のドキュメントでは、ステータスラインのスクリプトが受け取るJSONに rate_limits.five_hour.used_percentage と rate_limits.seven_day.used_percentage、リセット時刻の resets_at が入ります。この項目が出るのはclaude.aiのProとMaxの契約者で、セッションの最初のAPI応答の後からです。

1. メーターを記録するステータスライン

次のスクリプトは、公式のサンプルと同じく標準入力のJSONを読み、メーターをログへ追記しつつ画面用の1行も出します。jq が必要です。

#!/bin/bash
# ~/.claude/statusline-log.sh
input=$(cat)
echo "$input" | jq -c --arg t "$(date -u +%FT%TZ)" '{
  t: $t,
  five: .rate_limits.five_hour.used_percentage,
  week: .rate_limits.seven_day.used_percentage,
  week_resets_at: .rate_limits.seven_day.resets_at
}' >> ~/.claude/rate-log.jsonl
echo "$input" | jq -r '"[\(.model.display_name)] week \(.rate_limits.seven_day.used_percentage // "-")%"'

settings.json には次のように登録します。

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline-log.sh"
  }
}

実行権限(chmod +x)も必要です。ステータスラインは更新のたびに走るので、ログファイルは増え続けます。測り終えたら設定を外してください。

2. トランスクリプトを集計する

報告者たちは ~/.claude/projects 配下のJSONLにある usage ブロックを使っています。次のコマンドは、その方法を真似た一例です。ストリーミング中の重複を避けるため、同じIDの最後の行だけを残します。

find ~/.claude/projects -name '*.jsonl' -exec cat {} + | jq -s \
  --arg since "2026-10-03T00:00:00Z" '
  [ .[] | select(.message.usage != null and .timestamp >= $since) ]
  | group_by(.message.id) | map(last)
  | { responses: length,
      weighted: ( map(.message.usage
        | (.input_tokens // 0)
          + 1.25 * (.cache_creation_input_tokens // 0)
          + 0.1  * (.cache_read_input_tokens // 0)
          + 5    * (.output_tokens // 0)) | add ) }'

重み(入力1、キャッシュ書き込み1.25、キャッシュ読み取り0.1、出力5)は、issue #97398の複数のコメントが「API価格の比」として使っている係数です。モデルによって価格の比は違い、サブスクリプションの上限計算が同じ重みだと示す記載も、公式ドキュメントにありません。同じ式を前後の週に当てて比べるための物差しとして使ってください。since を変えれば、リセット以降の区間だけを切り出せます。ファイルが大きいと jq -s は多くのメモリを使うので、月ごとに分けて回すのが安全です。

なお、/usage の内訳(スキル・サブエージェント・プラグイン・MCPサーバー別のシェア)も、ローカルの履歴から計算されます。公式ドキュメントには、他のデバイスやclaude.aiの使用量は含まれないと書かれています。トランスクリプトは1台分なので、他の端末やclaude.aiで使った分は集計に入りません。複数台で使う人は、手元の集計とメーターの進みが合わない場合に、まずこの点を疑ってください。

3. 比率を出して読む

ログの2点間で、週次のパーセントがどれだけ進んだかと、その区間のトークン数を並べます。

1%あたりの重み付きトークン数 = 区間の weighted ÷ (週次%の終点 − 始点)
例: 区間の weighted が 96M で、週次が20ポイント進んだなら 4.8M / 1%

見るべきは絶対値でなく、前の週との比です。次の3つに当てはまる場合は、手元の使い方では説明しにくい兆候として報告に値します。

• 平均コンテキストや作業内容が同じなのに、1%あたりの数字が週をまたいで大きく下がった
• 応答数が少ない区間で、パーセントだけが大きく進んだ
• Claude Codeを動かしていない時間帯に、メーターが進んだ

どれにも当てはまらない場合は、キャッシュの書き直しやサブエージェントの増加など、/usage の内訳に表れる要因を先に疑う方が筋が通ります。過去の履歴を日付別に並べたいだけなら、ccusageの使い方が手軽です。

issueに数字を足すときの書き方

issueのスレッドで繰り返し指摘されたのは、数字の出し方が揃っていないせいで比較できないことです。投稿するなら、次の項目を同じ形で書くと、他の報告と並べられます。

• Claude Codeのバージョン、プラン(Pro、Max 5x、Max 20x、Team)、OS
• 比べた2つの期間と、それぞれの週次パーセントの始点・終点
• 応答数と重み付きトークン数(式も添える)
• モデル構成と、サブエージェントの有無

会話の中身やプロジェクトのパスは、数字の根拠に要りません。集計値だけで足ります。

公式の回答が出るまでにできること

issue #97398のコメントには、Anthropic側の回答が付いていません。メーターの仕様が変わったのか不具合なのかは、スレッドからは判断できません。上のログを残しておけば、公式の回答が出たとき、自分の環境がその前後でどう変わったかを数字で言えます。

週次上限に届いたときの挙動、プラン別の対処、リセット時刻の確認はClaude Codeの利用上限の見分け方、Fable 5.1の別枠の週次上限はFable 5.1の週次上限とクレジットにあります。