Claude Codeの上限が17%減。取り戻す5つの対策を実測

Claude Codeの週間制限は、夏のキャンペーンが終わった2026年9月中旬に17%下がりました。最上位プランのユーザーからは、水曜には一週間分の枠が空になるという報告が出ています。Anthropic自身の発表では制限が恒久的に25%引き上げられたと書かれていますが、その直後の投稿では同じ変更を17%の削減と呼んでいます。

制限を持たせるためのヒント集は、どれも数字を一つも載せていません。この記事では各対策に実測値を一つずつ添えて、順位を付けました。目立つ結果は二つあります。1か月分のトークンのほぼ半分がサブエージェントに使われていたこと、そして一度長い休憩を挟むと次のメッセージでセッションの大部分が書き直されることです。

ここでの計測は、一人の開発者の1か月分のClaude Codeログに基づいています。9月3日から10月3日までの455セッション、6万3,398リクエストです。

キャンペーンは5月から9月13日まで続き、週間制限を50%引き上げていました。5時間ごとの枠の制限は一度も変わっていません。8月末にAnthropicの開発者向けアカウントが25%の恒久的な引き上げを発表し、同じスレッドの一つ後の投稿で、実際には17%の削減になると述べています。どちらの発言も正しいのです。

期間	週間制限(元の制限を100とする)
キャンペーン前	100
キャンペーン中(5月から9月13日)	150
9月14日以降の恒久的な水準	125

150から125への低下が、ユーザーが体感している17%です。最上位プランを二つ契約しているユーザーは、水曜に100%に達したことはこれまで一度もなかったと書いています。同じプランの別のユーザーは、火曜の朝の時点で86%でした。ただし原因は制限の引き下げだけではありません。9月初めに、より多くを消費するモデルが登場したため、枠が空になるのがすべてこの変更のせいとは限りません。

手元で見えるのはパーセンテージです。/usage 画面では、直近の使用量がスキル、サブエージェント、プラグイン、接続中の各MCPサーバーに分けて表示され、キャッシュミスも示されます。キー一つで、直近1日と直近7日を切り替えられます。見えないのは、制限そのもののトークンでの大きさです。Anthropicが公表するのはパーセンテージと倍率だけで、トークン数は公表していません。したがって以下の計測値はすべて、一つの作業量に対するトークン数であり、週の何割かを示すものではありません。

ログからトークンを数えるときには落とし穴があります。ログには同じ応答が複数回書かれるため、すべての行を足すと186億トークンになります。重複を除いて一度ずつ数えると93億トークンです。単純に数えると、あらゆる数字がほぼ倍になってしまいます。

サブエージェントとは、セッションが副次的な作業のために起動する別のClaudeで、作業が終わると結果を報告します。計測した1か月では、サブエージェントが2,631回の実行で全トークンの48.1%を使っていました。

指標	サブエージェントの割合
全トークン	48.1%
出力トークン	63.9%
公開価格表と同じ重みで出力とキャッシュ書き込みを加重した場合	55.3%

サブエージェントには入場料もかかります。何かを始める前の最初のリクエストだけで、中央値で4万7,117トークンを運んでいます。指示文、ツール一覧、スキル一覧がすべて再送されるためです。別の人が別のマシンで測ったところ、エージェント自身のプロンプトがごく短くても、1回の起動で1万6,000から2万1,000トークンかかっていました。その記事の言い方を借りれば、エージェントのファイルは起動コストの中の誤差にすぎません。

もう半分はモデルです。デフォルトでは、サブエージェントはメインの会話のモデルを引き継ぎます。そのため、セッションを最大のモデルに切り替えると、すべての助手も同じモデルで動きます。計測したログでは、最小のモデルが処理したサブエージェントのリクエストは1%未満でした。対策はエージェントのファイルに一行書くだけです。model フィールドに、テストの実行やファイル検索のような作業向けの小さいモデルを指定します。

そこから二つの習慣が導かれます。その場でこなせる小さな作業にはサブエージェントを使わないこと。そして、使い続けるものには小さいモデルを固定することです。

この結果には限界があります。モデルを固定することで週の何割が節約できるかは、まだ誰も測っていません。また、小さいモデルがより多くのターンを必要とすれば、かえってコストが増えることもあります。48%という数字は、大きく枝分かれする作業から出たものです。自分の割合は /usage 画面で確認できます。

Claude Codeは、会話をサーバー側のプロンプトキャッシュに保持します。読み戻すコストは、もう一度送るコストのごく一部です。メインセッションのキャッシュは1時間持ちます。サブエージェントのキャッシュは5分です。

ドキュメントにははっきり書かれています。サブエージェントは、サブスクリプションでも、長くするよう選ばない限り5分です。メインの会話の外にあるものはすべて同じで、バックグラウンド作業やコンパクションも含まれます。計測したログも一致していました。サブエージェントのキャッシュ書き込みはすべて5分の階層に、メインセッションのものはすべて1時間の階層に入っていました。

Redditのある開発者が、その影響に気づきました。自分のサブエージェントの一つが、1日に8回もコンテキスト全体を書き直していたのです。対策は設定ファイルへの一行、"subagentPromptCacheTtl": "1h" です。

彼の計測	変更前	変更後
キャッシュ書き込み	1,220万トークン	300万トークン
サブエージェント4つでの5時間枠	2%から100%	0%から22%

これは一人のユーザーが別々の2日を比べたものであり、管理されたテストではありません。ここで計測したログでは、ほとんど影響がありません。サブエージェントの後続リクエスト4万1,790件のうち、5分を超える待機の後に来たのは95件(1,000件につき約2件)だけでしたが、そのたびに約7万5,000トークンが書き直されていました。

つまり、サブエージェントの動き方次第です。長いビルドやレビュー、あるいはあなたの返事を待つことが多いなら、有効にしてください。短いバーストで動くなら、そのままで構いません。1時間持つキャッシュは、書き込みのコストのほうが高いからです。

メインセッションのキャッシュは1時間持ちます。それより長く休むとキャッシュは消え、次のメッセージは何も読み戻せません。ドキュメントにも明記されています。休憩の後に送るメッセージはキャッシュにヒットせず、コンテキスト全体が再処理されます。

メッセージ前の間隔	リクエスト数	書き直されたキャッシュ(中央値)
5分未満	18,029	1,176トークン
5分から60分	414	1,327トークン
60分超	79	13万332トークン

その時点の典型的なセッションは17万5,523トークンを抱えていたので、大部分が再び書き込まれたことになります。さらに、メーターは書き込みと読み取りを同じには扱いません。ある開発者はClaude Codeの前段にログ取得用のプロキシを置き、5時間枠を観察しました。彼の比率では、キャッシュに書き込まれたトークンは、読み取られたトークンの約40倍の重みがあります。

Claude Codeもこれを把握しています。長い休憩の後に大きなセッションを再開しようとすると、代わりに要約から再開することを提案してきます。それを受け入れてください。

もっと安上がりな習慣は、その前の段階にあります。タスクが終わったら、キャッシュがまだ温かいうちにセッションをクリアします。クリアは無料で、次のタスクは小さな状態から始まります。コンパクションも有効ですが、巨大なセッションのコンパクションはそれ自体が巨大なリクエストです。

キャッシュを失う原因は休憩だけではありません。セッションの途中でモデルを切り替えると、モデルごとに別のキャッシュを持つため、キャッシュが空になります。最新のモデルでは、effortを変えても空になりません。Claude Codeは、キャッシュが温かいうちにモデルを切り替えるとき確認を求めてきますが、その確認が警告です。

限界もあります。コールドリターンの79件は小さなサンプルで、コンパクションの直後のものも含まれます。また、要約では細部が失われるため、この対策には継続性という代償があります。

effortとは、モデルが答える前にどれだけ長く考えてよいかを表すものです。lowからmaxまで5段階あり、思考は出力として課金されます。デフォルトはほとんどのモデルでhigh、最新の2つのモデルではmediumです。

ドキュメントによれば、思考の予算は1リクエストあたり数万トークンに達することがあり、最上位の段階は考えすぎになりやすいとされています。最新のモデルでは思考をオフにすることができないため、段階の選択が唯一の調整手段です。

ある開発者が、同じ29の実際のタスクを5つすべての段階で実行しました。

effortレベル	タスク1件あたりの平均コスト	合格したタスク(29件中)
low	$2.50	23
medium	$3.15	28
high	$5.01	26
xhigh	$6.51	25
max	$8.84	27

品質はコストに比例しませんでした。mediumはそれより上のどの段階よりも多くのタスクに合格し、1ドルあたりの合格数も最も多くなりました。彼の言葉では、曲線はmediumでピークになるようです。Claude Codeチームも同じように使っています。エンジニアの一人は、lowかmediumで作り、レビューをして、検証だけをhighで走らせます。

この対策が品質を犠牲にしうる理由が、次の点です。彼が選んだ難しい問題では、lowは5回中0回しか合格せず、highは5回中5回合格しました。lowの1回の試行は2分で済み、highは33分かかりました。

そこで、段階はステップに合わせます。作るときはmedium、ミスが高くつくとき(古いコードのバグ、マイグレーション、最後の確認)はhigh、maxはほとんど使いません。セッションログにはすべてのリクエストのeffortが記録されているので、実際に何で動かしていたかを確認できます。

これらのコストは古いモデルでのドル建てであり、週の割合ではありません。それを公表した人はいません。また、安く済ませようとして失敗し、二度走らせた場合は、一度で成功するより高くつきます。

どのリストにも載っているのに、ほとんど効果のない対策があります。試すのは無料ですが、一週間分の枠が消えた原因はそこではありません。

このグループで本当に効くのは、起動時に読み込まれるものです。ある記事は、空のフォルダでの最初のリクエストを2万9,061トークン、実際のプロジェクトの中では4万弱と計測しました。ここで計測したログでは、最初のリクエストの中央値は5万5,989トークンで、プロジェクトによって1万5,764から10万5,020まで幅があります。/context コマンドを使うと、中身(メモリファイル、スキル、ツール一覧)が表示され、読み込んだメモリファイルが一つずつ示されます。使っていないものは削りましょう。効果が控えめなのは、そのブロックが一度書き込まれた後、以降のターンではキャッシュから読まれるからです。痛いのは、コールドスタートのときと、サブエージェントを起動するたびです。

よくあるヒント	実測
MCPサーバーを外す	3つのサーバーの51個のツールで1,350トークン、1つのツールを持つ1サーバーで18トークン
プロンプトの提案をオフにする	あるユーザーで3〜4%。「最大10%」という主張は、巨大なコンテキストを持つ一つのアカウントから出たもの
シェル出力のフィルタリング	総量の約0.1%(そのフィルタの貢献者による計測)

ツール定義は今ではデフォルトで遅延読み込みされるため、MCPサーバーの影響はごくわずかです。ドキュメントも、プロンプトの提案のコストは小さいと述べています。三つとも、コンテキストが大きくなるほど増え、遅延読み込みがオフの古いモデルではサーバーのコストが大きくなります。気が済むならオフにしても構いませんが、一週間分の枠が戻ってくるとは期待しないでください。

実測値に基づく順位です。

順位	対策	実測	落とし穴
1	サブエージェントを減らし、安いものにする	全トークンの48.1%、1回の起動あたり4万7,117	並列性が下がる
2	コールドセッションを再開しない	1,176に対して13万332トークンが書き直された	要約では細部が失われる
3	effort: 作るときはmedium	タスク1件あたり$3.15、$5.01と比較。29件中28件合格	lowは難問で失敗する
4	サブエージェントのキャッシュを1時間にする	キャッシュ書き込みトークンが1,220万から300万	サブエージェントが待つ場合にだけ効く
5	起動時に読み込まれるものを削る	2万9,061のベースラインに対して+9,744トークン	セッションごとに一度だけの支払い

人気の3つ(MCPサーバー、プロンプトの提案、シェル出力)は、一週間分の枠が消えた原因ではありません。

限界をはっきり言うと、この順位はトークン単位で、一人の1か月分の作業と、他の人の計測値に基づいています。Anthropicは制限のトークンでの大きさを公表していないので、外部の誰もこれをあなたの週の割合に換算できません。順番はあなたの場合と違うかもしれません。それは /usage 画面が教えてくれます。

最も大きい二つの対策は、設定ではなく習慣であり、無料です。サブエージェントの起動を減らすこと、そしてコールドセッションをそのまま全部再開しないことです。