AIDive

動画パック

Claude Code 週次上限の引き下げ: 計測したレバー、キャッシュ表、月曜のチェックリスト

10 分で読めます

TL;DR

  • Claude Code の週次上限は、基準の 100 からプロモーション水準の 150 に上がり、2026年9月14日に恒久的な 125 で確定しました。プロモーション水準と比べると 17% の引き下げ、旧基準と比べると 25% の引き上げです。どちらの言い方も同時に正しいです。
  • 1か月分のローカルログでは、サブエージェントが全トークンの 48.1%、重み付きコストの 55.3% を占めました。最大のレバーは、サブエージェントの起動を減らし、残すものには小さなモデルを固定することです。
  • サブエージェントは 5 分キャッシュを書き込み、メインセッションは 1 時間キャッシュを書き込みます。冷えた間隔のあとの次のリクエストは、温かい状態の約 19 倍のキャッシュを書き直します。
  • メインセッションで 60 分を超える休憩を挟むと、次のリクエストでのキャッシュ再書き込みは中央値 130,332 トークンです。間隔が 5 分未満なら 1,176 です。
  • effort を下げても、このログではリクエストあたりの出力は減りませんでした(メインセッションで high は平均 778 トークン、medium は 837)。無料の節約ではなく、品質とのトレードオフとして扱ってください。
  • プロンプト提案をオフにすることと、シェル出力のフィルタリングは、実際に効きますが小さなレバーです。最後に数えてください。

計測が示すこと

見出しの数字の算術です。基準 100、プロモーション水準 150、恒久水準 125。125 / 150 = 0.8333 なので、削減は 16.67%、丸めて 17% です。誤った読み方は、増分(50% から 25%)を引き算して 25% の削減と呼ぶことです。s2

プロモーションは 2026年5月13日から 2026年9月13日まで行われ、Claude Code のみで週次上限を 50% 引き上げ、5 時間の上限には手を付けませんでした。Pro、Max、Team、席数課金の Enterprise プランが対象でした。s1

以下の計測は 1 台のマシンの Claude Code ログによるものです。2026-09-03 から 2026-10-03 までの、メインセッション 455、サブエージェント実行 2,631、重複排除後のリクエスト 63,398 です。最初の発見は数え方そのものに関するものです。各リクエストはログ上で平均 1.96 行に現れるため、全行を合計すると総トークンが 99.3% 過大になります。これらのログを読むスクリプトは、まず (message.id, requestId) で重複排除する必要があります。s11

サブエージェントが最大の項目です。重複排除後、総トークンの 48.1%、出力トークンの 63.9%、重み付きコストの 55.3% を占めます。サブエージェント実行の最初のリクエストは、何かを始める前に中央値 47,117 トークンのプロンプトを抱えています。p90 は 52,681、最大は 126,769 です。ツールセットを絞ったエージェントはずっと低く始まります(最小 5,295)。s8

モデルの選択がこれを増幅します。サブエージェントは、model フロントマター、呼び出しごとの model パラメータ、または CLAUDE_CODE_SUBAGENT_MODEL で指定しない限り、メイン会話のモデルを継承します。さらに v2.1.251 以降は、環境変数だけではフロントマターを上書きできず、CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 が必要です。ログでは、claude-opus-5 だけで全トークンの 31.5%、重み付きコストの 35.8% を占め、そのうち 63.2% はサブエージェント内で使われました。s3

キャッシュ階層は、リクエストがどこで動くかで決まります。このデータでは、サブエージェントのキャッシュ書き込みの 100.0% が 5 分、メインセッションの 100.0% が 1 時間で、混在したリクエストはありませんでした。サブエージェント実行内では、後続リクエスト 41,790 件のうち 5 分を超える間隔のあとに届いたのは 95 件(0.2%)だけでしたが、それらは平均 74,582 の cache_creation トークンを書き込み、温かいリクエストは 3,886 でした。subagentPromptCacheTtl 設定と環境変数 CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL は 5m か 1h を受け付け、Claude Code v2.1.242 以降が必要です。s4

独立した検証でも同じ分かれ方が見られました。サブエージェントの全リクエストが ephemeral_5m_input_tokens で書き込まれ、親は ephemeral_1h_input_tokens を使い、あるエージェントは 5 分の窓を過ぎたリクエストでプレフィックス 20,971 トークンをすべて書き直しました。s6

メインセッションで相当するのが長い休憩です。前のリクエストから 5 分未満で届いたリクエストは、中央値 1,176 の cache_creation トークンを書き込みました(n = 18,029)。5 分から 60 分は 1,327(n = 414)。60 分超は 130,332(n = 79)で、プロンプトの中央値は 175,523 トークン、p90 は 674,348 です。ドキュメントによれば、超過課金になるとメイン会話も 5 分階層に落ちます。s3

セッション開始は固定コストです。メインセッションの最初のリクエストは中央値 55,989 トークン(p90 72,000)で、CLAUDE.md とメモリの大きさにより、プロジェクトごとに 15,764 から 105,020 まで幅があります。以前の公開計測では、空のディレクトリで約 29k、MCP サーバー 3 台で 30.4k、実際のリポジトリで 38.8k が下限でした。s9

effort は、ドキュメントが推すレバーですが、ログは報いてくれません。メインセッションでは、high のリクエストの出力は平均 778 トークン、medium は 837 でした。サブエージェントでは high が 323、medium が 642 です。この比較は交絡しているので(タスク、モデル、プロジェクトが違う)、疑う理由にはなっても証明にはなりません。Claude Code チーム自身のガイダンスは、effort を予算のつまみではなく、推論をどこに使うかとして位置づけています。s10

よく知られた 2 つのコツは小さい結果でした。プロンプト提案は追加のリクエストを使い、広く共有されている「約 10% 節約」は上限であって、典型的な節約ではありません。設定は promptSuggestionEnabled: false または CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION=false です。s12 20 日間のシェル出力フィルタリングは出力を 6,670 万トークンから 2,410 万トークンに減らしましたが、その 6,670 万は同じ期間に消費された新規トークンの 7.4% でした。s11

計測値

サブエージェント起動コスト、最初のリクエストのプロンプト(トークン)、モデル別:

モデル n min median p90 max
全体 2,631 5,295 47,117 52,681 126,769
claude-opus-5 1,262 36,864 43,905 48,032 50,398
claude-sonnet-5 633 5,916 52,409 53,961 126,769
claude-opus-5-5 426 39,408 47,189 48,362 48,883
claude-sonnet-5-5 165 44,471 47,348 50,197 50,863
claude-fable-5-1 102 36,551 42,593 44,286 47,385
claude-haiku-4-5 42 5,295 29,636 36,714 79,190

再開時のキャッシュ再書き込み、メインセッション、リクエスト前の間隔別:

間隔 n cache_creation median mean cache_read median prompt median
< 5 min 18,029 1,176 2,391 184,169 186,412
5 〜 60 min 414 1,327 5,575 221,857 225,168
> 60 min 79 130,332 241,499 25,264 175,523

手順: すべてのメインセッション ~/.claude/projects/*/<uuid>.jsonl と、すべてのサブエージェント実行 */<uuid>/subagents/agent-*.jsonl を、2026-09-01 以降のリクエストについて読みます。assistant の行を (message.id, requestId) で重複排除し、リクエストごとに usage レコードを 1 つ残します。総トークン = input + output + cache_read + cache_creation、プロンプトサイズ = input + cache_read + cache_creation です。間隔 = 同じセッションまたは実行内で、前のリクエストの最後のログ行からこのリクエストの最初の行までの時間です。重み付きコストは、相対重み input 1、キャッシュ書き込み 5m 1.25、キャッシュ書き込み 1h 2、キャッシュ読み取り 0.1、output 5 を使います。この重みは仮定であり、公表料金ではありません。

月曜にやること

  • 自分のプランで /usage を実行し、スキル、サブエージェント、プラグイン、MCP 別の内訳と、直近の使用量の 10% 以上で挙がった動作フラグを読む。
  • サブエージェント定義を一覧にし、検索、確認、要約だけをするものすべてに model: haiku か model: sonnet のフロントマターを追加する。
  • フロントマターに関係なくすべてのサブエージェントを 1 つのモデルにしたいなら、CLAUDE_CODE_SUBAGENT_MODEL と CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 を設定する。
  • Claude Code のバージョンが 2.1.242 以降であることを確認し、subagentPromptCacheTtl: "1h" が割に合うかをワークフローごとに判断する。ツール呼び出しの間にアイドルになるサブエージェントには効き、短いものには効かない。
  • 1 時間を超える休憩の前に、現在のセッションでタスクを終え、引き継ぎファイルを書く。戻ったら 175k トークンのプロンプトを再開せず、新しいセッションを開く。
  • 自分のログに対して、(message.id, requestId) で重複排除する読み取り専用スクリプトを書き、他の何かを変える前にメインとサブエージェントの比率を比べる。
  • 提案を使わないなら promptSuggestionEnabled: false に設定する。節約はせいぜい数パーセントと考える。

さらに読む

  • Max 5x と Max 20x: 引き下げ後にユーザーが測った容量比は、動画で扱わなかったプラン選びの問題です。s7
  • キャッシュ TTL の優先順位の全体(force 環境変数、バケット環境変数、バケット設定、サブエージェントの experimental.cacheTtl)と、超過課金で何が変わるか。s4
  • セッション途中で effort を変えると、ほとんどのモデルでキャッシュヒットなしに履歴全体を読む場合がある理由と、対象外のモデル。s3
  • 自分のセッションログで usage フィールドとキャッシュ階層を読む方法と、1 日の予算ビューに対する ccboard のやり方。s11
  • 3 つのサブエージェントファイル、3 つのモデル、各起動が実際にキャッシュへ何を書いたか。筆者自身の訂正付き。s8
  • 遅延される MCP ツール定義と、ツールスキーマをいつコンテキストに読み込むかを制御する ENABLE_TOOL_SEARCH=auto:N。s3

出典

FAQ

17% の引き下げですか、25% の引き上げですか?

どちらもです。基準が違うだけです。プロモーション前の基準 100 と比べれば、恒久水準 125 は 25% の引き上げです。2026年5月13日から9月13日までユーザーが持っていたプロモーション水準 150 と比べれば、17% の引き下げです。

subagentPromptCacheTtl はどこでも 1h にすべきですか?

サブエージェントがリクエストの間に 5 分以上アイドルになる場合だけです。ログでは後続リクエストの 0.2% がそのケースで、一律の 1h 階層は、ほぼ何も得ずに高い書き込み価格を払うことになります。まず自分の間隔の分布を測ってください。

effort を下げるとトークンは節約できますか?

このログでは目に見える形ではありません。メインセッションのリクエストは high で平均 778 出力トークン、medium で 837 でした。データは交絡しているので、正直な答えは、effort は品質のつまみであり、節約は自分のタスクで測る必要がある、ということです。

昼食後の最初のプロンプトがなぜこんなに高いのですか?

メインセッションは 1 時間キャッシュを書き込みます。60 分を超える間隔のあと、次のリクエストはプレフィックスを書き直します。ログでは中央値 130,332 の cache_creation トークンで、温かいリクエストは 1,176 です。長い休憩の前にタスクを終え、そのあとは新しく始めてください。