【9/14確定】Claude Codeの上限は「読ませた量」で決まる｜実処理の94.7%はキャッシュ書き込みだった

Claude Codeの週次上限が、2026年9月14日から恒久的に25%引き上げられます。ただし、今より17%減ります。この記事では、その計算の中身と、自分のログ4万ターンを数えて分かった「上限を溶かしているのは、書いた量でも会話の回数でもなく、読ませた量だった」という実測を書きます。

私はエンジニアではありません。文系出身でClaude Codeを4か月使ってきただけの非エンジニアです。それでも、パソコンの中に残っているログを数えることはできます。数え方もそのまま載せるので、同じ確認はどなたでもできます。

9月14日から25%増える。ただし、今より17%減る

先に結論を書きます。数字の動きはこうです。

もともとの標準を100とすると、今は150です。2026年5月13日から8月31日まで、Claude Codeの週次上限は標準の50%増しになっていました。この増量は8月31日で終わり、9月1日から標準の100に戻りました。

そして9月14日から、標準そのものが125に引き上げられます。恒久的な変更で、対象はPro、Max、Team、シート課金のEnterpriseです。

つまり、9月14日を境にこうなります。

もとの標準と比べれば、25%増えます。増量キャンペーン中の今と比べれば、17%減ります。どちらも同じ変更を、違う地点から見ているだけです。

この17%という数字は、私が勝手に計算したものではありません。Anthropic自身が認めています。最初の告知は「25%引き上げ」だけを伝えるものでしたが、その後スレッドは削除され、訂正が投稿されました。訂正にはこう書かれています。

（今日と比べると、これはClaude Codeの週次上限が17%減ることになります）

告知を出し、消し、減ることを明記して出し直した。この経緯自体が、今回いちばん誠実な情報だったと思っています。

前回「一次ソースが見つからない」と書いた点に、答えが出ました

8月31日に、増量キャンペーンが終わる日の記事を書きました。そのなかで、9月14日からの恒久25%増について「一次ソースが見つからない」として保留にしています。

あのとき出回っていたのは、削除される前の告知を引用した二次情報だけでした。公式のサポート記事には8月31日で増量が終わることしか書かれておらず、9月14日の話は確認が取れませんでした。裏が取れないものは書かない、という方針でそのまま保留にしました。

その保留が、今日ほどけました。訂正が出て、複数の報道が同じ数字を報じ、17%という表現も公式の言葉として確認できます。前回の記事を読んでくださった方には、ここが答え合わせになります。

前回の記事Claude Codeの週次上限が9/1から戻る｜ログ6万件を数えて分かった、上限を溶かす本当の犯人では、上限の実数値がどこにも公開されていないこと、それでもログから逆算できることを書いています。

9月1日、枠は本当に戻ったのか

増量が終わった当日、つまり今日の数字も見ておきます。

午前中までで518ターン、キャッシュ読み込みを除いた実処理量は361万トークンでした。上限に近づいたときに出る警告は、一度も出ていません。

前回の記事で「9月1日から、自分は上限に当たるのか」と書きました。今のところの答えは「当たっていない」です。ただしこれは私の使い方の話で、増量前の5週間も一度も当たっていませんでした。当たる人と当たらない人の差がどこにあるのかを、ここから数字で割っていきます。

実処理量6億8,975万トークンを、3つに割ってみた

直近21日ぶんのログを集計しました。対象は40,995ターン、総トークンは110億7,189万です。

このうち、キャッシュ読み込み（cache_read）が103億8,213万で、総量の93.8%を占めます。前回の記事で「上限に効くのはキャッシュ読み込みを除いた実処理量だ」と書いた部分です。読み直しはほとんど課金にも上限にも効きません。

残った実処理量は6億8,975万トークン。今回はこれを、さらに3つに割りました。

• キャッシュ書き込み（cache_creation）: 6億5,322万 = 実処理の94.7%

• 出力（output）: 3,630万 = 実処理の5.3%

• 入力（input）: 22万 = 実処理の0.0%

はじめてこの並びを見たとき、正直に言うと数え間違いを疑いました。それくらい偏っています。

94.7%は「新しく読ませた量」だった

キャッシュ書き込みというのは、Claudeに新しく読ませた内容を、次回以降のために保存する処理のことです。ファイルを読ませる、ログを渡す、長い資料を貼る。そのたびにここが増えます。

一方、出力はClaudeが書いた文字、入力は自分が打った文字です。

この3つを比べると、上限を動かしているのはキャッシュ書き込みだけだと分かります。94.7%対5.3%対0.0%です。

ここから2つのことが言えます。

1つ目。プロンプトを短く書いても、上限にはほぼ影響しません。自分が打った文字は全体の0.0%です。22万トークンというのは、21日ぶんの合計です。丁寧に指示を書くことをためらう理由は、少なくとも上限の面ではありません。

2つ目。Claudeに長い返事を書かせても、影響は小さい。出力は5.3%です。もちろんゼロではありませんが、ここを削っても効き目は限定的です。

効くのは、読ませた量です。大きなファイルを丸ごと渡す、ログを全部貼る、フォルダごと探索させる。この操作が上限を減らしています。

ターン数と実処理量は、まったく比例しない

「たくさん会話すると上限に当たる」という話をよく見ます。私もClaude Codeの使用量159億トークンを全部数えた記事で、そう書きました。今回のデータは、それをはっきり否定しています。

日ごとに、ターン数と実処理量を並べてみます。

• 8月31日: 5,791ターン、実処理2,394万、1ターンあたり4,135

• 8月13日: 2,749ターン、実処理9,696万、1ターンあたり35,273

• 8月21日: 3,471ターン、実処理8,326万、1ターンあたり23,988

• 8月24日: 2,992ターン、実処理1,770万、1ターンあたり5,917

• 8月27日: 2,895ターン、実処理7,037万、1ターンあたり24,310

8月31日と8月13日を比べてください。ターン数は8月31日のほうが2.1倍多いのに、実処理量は4分の1です。1ターンあたりで見ると8.5倍の開きがあります。

何が違ったのか。8月13日は記事のために大量のログとファイルを読ませた日で、8月31日は同じ資料を読み直しながら文章を書き続けた日でした。回数ではなく、新しく読ませたかどうかで決まっています。

会話の回数を気にして早めにセッションを切る、という運用をしている方は多いと思います。私もそうしていました。ですが後で見るように、切ることでかえって読み直しが増える場合があります。

読ませた量の3割は、同じものの焼き直しだった

もうひとつ、気になっていたことを測りました。

同じセッションの中で、それまで効いていたキャッシュが急に無効になり、同じ内容をもう一度読み込み直す現象があります。ログの上では、直前まで大きかったキャッシュ読み込みが急に落ち込み、同時にキャッシュ書き込みが跳ね上がる形で現れます。

40ターン以上かつ1時間以上続いたメインの会話104セッション、合計4,694時間ぶんを対象に数えました。

• 検出したキャッシュ飛び: 643回（1時間あたり0.14回）

• 焼き直したトークン: 3億544万

• 対象期間のキャッシュ書き込み10億3,909万に対して29.4%

読ませた量の3割が、同じ内容の読み直しでした。ここが減れば、そのぶん上限に余裕が出ます。

原因の一部は、公式も認めています。バージョン2.1.248の変更履歴に、こう書かれています。

（長いセッションで1時間に1回ほど起きていたプロンプトキャッシュのミスを修正。原因は認証トークンの更新後にツール定義が再描画されていたこと）

同じ回で、使用量が超過状態に入ったアカウントで--resumeの初回が全ミスになる不具合も直っています。つまり「自分の使い方が悪いから飛んでいた」わけではない部分が、確かにありました。

ただし、正直に書いておきます。「1時間に1回」という周期性は、私のログでは確認できませんでした。飛びの間隔を分布で見ると、50分から70分の帯に入るものは1.2%しかなく、66.4%は10分以内の連発でした。

私のログにはサブエージェントを大量に並列で動かしたセッションが多く含まれます。おそらくそちらの影響のほうが大きく、公式が直したバグとは別の原因で飛んでいたのだと思います。ここは断定できません。

v2.1.251から、自分の数字は /cost で見られる

ここまで私はPythonスクリプトでログを数えてきました。もうその必要はありません。

バージョン2.1.251の変更履歴に、こうあります。

（/costにセッション単位のプロンプトキャッシュ行を追加。ヒット率、ミス、再キャッシュされたトークン、warm/coldが出る。ステータスライン用にprompt_cacheオブジェクトも追加）

私が6万件を数えて出した「読み直しがほとんどで、効いているのは書き込みのほう」という話を、コマンド1つで自分の環境で確かめられるようになりました。手順はこれだけです。

Step 1: Claude Codeを最新にする。claude updateを実行し、claude --versionが2.1.251以上になっていることを確認します。

Step 2: 作業を1時間ほど普通に進めます。読み込みが多い作業と、文章を書く作業の両方を混ぜると差が見えます。

Step 3: /costと打ちます。セッションのコストに加えて、プロンプトキャッシュの行が出ます。ヒット率が高いほど、同じ内容を効率よく使い回せている状態です。再キャッシュされたトークンが多い場合は、この記事でいう「焼き直し」が起きています。

Step 4: 常に見たい場合は、ステータスラインに出します。settings.jsonのstatusLineをtype: commandにして、スクリプトの中でprompt_cacheを拾えば、画面の下に出したままにできます。

前回の記事では、/usageで直近24時間と7日間の消費バーを見る方法を書きました。/costのキャッシュ行と合わせて見ると、枠を食っているものがはっきりします。なお2.1.251では/usageにも支出上限のバーが追加されています。金額の上限が設定されている環境の方は、こちらも見ておくと状況がつかみやすくなります。

上限を延ばすためにやること4つ

数字から言えることを、4つに絞ります。

1つ目。読ませる範囲を先に決めます。 フォルダごと渡すのをやめて、対象のファイルを名指しします。実処理の94.7%がここなので、いちばん効きます。ログを見せたいときも、必要な期間だけ切り出してから渡します。

2つ目。セッションを切りすぎないようにします。 会話が長いこと自体は上限にほぼ効きません。それより、切って始め直すたびに前提を読み直させるほうが高くつきます。今日の作業が続いているなら、同じセッションを続けるほうが安いことが多いです。

3つ目。同じ資料を何度も渡さない工夫をします。 毎回貼っている前提があるなら、CLAUDE.mdに置いて読み込ませたほうが、キャッシュに乗る回数が減ります。Claude Codeの許可設定を923件ぜんぶ数えた記事で書いたとおり、ここも書き方の細部で効きが変わる部分です。

4つ目。週の頭に/costで測ります。 感覚で「使いすぎたかも」と判断するのをやめて、数字を見ます。上限の実数値は公開されていませんが、自分の週ごとの消費量は自分で測れます。9月14日から枠が動くので、その前後で比べておくと、自分にとって17%減がどれくらいの痛みなのかが分かります。

この記事の限界

3つ書いておきます。

集計は私のアカウント1つ、直近21日ぶんのログだけです。使い方が違えば内訳も変わります。特に、コードを書く時間が長い方は出力の比率がもっと高くなるはずです。

キャッシュ飛びの検出は、私が決めた条件（直前より読み込みが7割以上落ちて、書き込みが5万トークンを超えた点）による推定です。公式の定義とは違う可能性があります。

そして、週次上限の実数値そのものは、今も公開されていません。この記事で扱っているのは「何が上限を減らすか」であって、「上限が何トークンか」ではありません。

よくある質問

Q. 9月14日以降、結局増えるのですか、減るのですか。

もとの標準と比べれば25%増えます。増量キャンペーン中の今と比べれば17%減ります。9月13日まで今の枠で、9月14日から新しい枠になります。

Q. Proプランでも対象ですか。

Pro、Max、Team、シート課金のEnterpriseが対象です。

Q. プロンプトを短くすれば節約になりますか。

上限の面では、ほぼ効きません。自分が打った文字は21日ぶんで実処理の0.0%でした。指示は必要なだけ丁寧に書いて問題ありません。

Q. 会話が長くなったら/clearしたほうがいいですか。

作業が続いているなら、続けたほうが安いことが多いです。切ると前提を読み直すことになり、そのぶんキャッシュ書き込みが増えます。話題が完全に変わるときだけ切る、という使い分けが数字には合っています。

Q. 自分の環境で確認するには何が必要ですか。

バージョン2.1.251以上のClaude Codeと、/costコマンドだけです。スクリプトを書く必要はもうありません。

まとめ

• 9月14日から週次上限は恒久的に25%引き上げられます。ただし増量中の今と比べると17%減で、これはAnthropicが訂正の中で明記しています

• 直近21日、40,995ターンを数えたところ、実処理6億8,975万トークンの94.7%がキャッシュ書き込み、つまり新しく読ませた量でした

• 自分が打った文字は0.0%、Claudeが書いた文字は5.3%です。上限を減らしているのは、書いた量ではなく読ませた量です

• ターン数と実処理量は比例しません。1ターンあたりの処理量は日によって8.5倍違いました

• 読ませた量の29.4%は、同じ内容の焼き直しでした。一部は公式もバグとして修正しています

• バージョン2.1.251から、この数字は/costで誰でも確認できます

前回は「上限を溶かす犯人は実質処理量だった」まで書きました。今回はその中身を割って、94.7%が読ませた量だったところまで進めました。9月14日の切り替わりの前後でもう一度測って、また書きます。

あわせて読みたい関連記事：

Claude Codeの実測記事はX（@ai_hack_dx）でも毎日出しています。上限や設定まわりで詰まっている方は、のぞいてみてください。