8月30日の朝、ヘルプセンターで週次上限の増量期限を確かめたところ、「2026年8月31日まで」と書かれていました。ところがその前日、Anthropic の開発者アカウントは、増量を9月13日まで延ばし、9月14日からは標準の週次上限そのものを恒久的に引き上げると告知しています。公式の恒久ドキュメントと公式の告知が、丸一日以上食い違ったままだったことになります。
私は個人開発のアプリを支える定型処理と、複数サイトの自動運用に Claude Code を毎日使っているため、この日付のずれは見過ごせませんでした。8月末で増量が切れる前提のまま9月分の実行計画を組みかけていたからです。同じ前提で予定を立てている方のために、調べて検算した内容を整理しておきます。
まず結論 — 何が、いつ、どう変わるのか
| 期間 | 週次上限の水準 | 備考 |
|---|---|---|
| 2026年9月13日まで | プロモ前の標準比 +50% | 現行の増量をそのまま継続 |
| 2026年9月14日から | プロモ前の標準比 +25% | 標準の週次上限そのものを恒久的に引き上げ |
対象は Pro・Max・Team・シート課金 Enterprise の Claude Code の週次上限だけです。5時間のローリングウィンドウは変わりません。Claude の web・デスクトップ・モバイル、そして Cowork の上限も、この変更の対象外だとヘルプセンターに明記されています。
もうひとつ押さえておきたいのは、これらの週次上限についてトークンの絶対値が一度も公表されていない点です。つまりこの変更は比率でしか語れず、裏を返せば、自分の消費量を測っていない限り影響の判断ができません。測り方は後半で扱います。
『+25%』と『17%減』が同時に成り立つ検算
告知には「標準週次上限を+25%へ恒久的に引き上げる」とあり、同じ日の追記には、今日と比べれば Claude Code の週次上限は17%の削減にあたる、という趣旨の説明が添えられています。増えるのか減るのか、一見すると矛盾して見えますが、参照点が違うだけでどちらも正しい数字です。
プロモーション前の標準週次上限を100と置いて指数化すると、こうなります。
| 時点 | 指数 | プロモ前比 | 現在（150）比 |
|---|---|---|---|
| プロモ前の標準 | 100 | — | −33.3% |
| 現在（増量中） | 150 | +50% | — |
| 9月14日以降 | 125 | +25% | −16.7%（≒17%減） |
検算は割り算2つで済みます。125 ÷ 100 = 1.25 なので、プロモ前と比べれば+25%。125 ÷ 150 ≒ 0.833 なので、今日と比べれば16.7%の減少で、四捨五入すると告知の言う17%になります。
よく見かける「50%増が25%増になるのだから25%の削減」という読み方は、演算そのものが誤りです。比べるべきは増分どうし（50と25）ではなく、水準どうし（150と125）です。白状すると、私も見出しだけ読んだ時点では同じ引き算をしかけました。
もうひとつ、パーセンテージの非可逆性にも注意が要ります。150から125への変化は16.7%の減少ですが、125から150へ戻すには20%の増加が必要です。減った割合と戻すのに必要な割合は一致しません。プロモーション中の水準を予算計画の基準線に据えていると、この差がそのまま見積もりの誤差になって表れます。
自分が影響を受けるかは /usage で分かります
この変更で実際に困るのは、この3か月半のあいだに消費量が増量分（指数150の側）まで育っていた使い方だけです。週次上限に一度も到達したことがなければ、9月14日以降も指数125、つまりプロモ前より高い水準にいるので、体感は何も変わりません。
現在の消費は Claude Code 内で /usage を実行し、「Current week (all models)」の行を見れば分かります。まずは今日の値を控えるところからです。
毎回コマンドを打つのが面倒なら、ステータスラインに常時表示してしまう手があります。ステータスラインスクリプトには JSON が標準入力で渡り、その中の rate_limits.seven_day に週次の消費率（used_percentage）とリセット時刻（resets_at）が入っています。
#!/bin/bash
# ~/.claude/statusline.sh — 週次上限の消費率を常時表示し、日次でCSVに残す
input=$(cat)
week=$(echo "$input" | jq -r '.rate_limits.seven_day.used_percentage // empty')
reset=$(echo "$input" | jq -r '.rate_limits.seven_day.resets_at // empty')
if [ -n "$week" ]; then
# 同じ日付の行がまだ無ければ1行追記（1日1回だけ記録される）
log="$HOME/.claude/week-usage.csv"
today=$(date +%F)
grep -q "^${today}," "$log" 2>/dev/null || echo "${today},${week}" >> "$log"
printf "week %s%%（resets %s）" "$week" "$reset"
else
printf "week: n/a"
fi~/.claude/settings.json に登録すれば、次のセッションから表示されます。
{
"statusLine": {
"type": "command",
"command": "~/.claude/statusline.sh"
}
}このスクリプトを仕込んでおく実務的な意味は、切り替え日をまたいだ比較にあります。9月13日までの残り2週間で日次の値が溜まっていれば、9月14日以降の消費率の変化を、告知の比率ではなく自分の数字で確かめられます。rate_limits には five_hour・seven_day_opus・seven_day_sonnet というフィールドもあり、週次プールがモデル別の内枠を抱えた共有プールになっている構造もここから読み取れます。
到達している場合は、モデル配分から見直します
記録してみて週次上限に届いていた場合、プランを変えずに取れる実質的な余地は、いま挙げたプールの構造を使うことです。週次プールはモデル横断で共有されつつ、Opus や Sonnet といったモデル別の内枠を持っています。つまり、毎回同じ手順で流れる定型的な工程を最も高価なモデルから外すだけで、週次の消費配分は変わります。
私自身、個人開発の壁紙アプリ向けのアセット分類やサイト記事の整形といった定型工程でモデルを使い分けているので、9月14日を待たずに配分を測り直すことにしました。こうした無人実行の消費を数えるときは、その前提として、起動そのものが予定どおり全部起きているかを先に確かめておく必要があります。そちらの点検手順は無音で半分になっていた定期実行と、欠落を捕まえる突き合わせに、実際に起動が欠落していた事例と合わせて書きました。
ドキュメントより告知が先に動く、という順序
冒頭の食い違いに戻ります。8月30日の時点で、ヘルプセンターの該当ページはまだ「増量は8月31日まで」のままでした。告知チャネル（開発者アカウント）が先に動き、恒久ドキュメントの追随は後から来る。今回の一件は、その順序をはっきり見せてくれました。
サポート記事を根拠に容量計画を立てる運用をしているなら、確認の順序を入れ替える必要があります。告知を先に見て、ドキュメントは「追いついたか」を後から確かめる側に回す。そして最終的な判断材料は、公式の比率ではなく自分の実測値に置く。今日 /usage を開いて週次消費の現在値を控えておくこと — 9月14日に慌てないための基準線は、その1行から始まります。