Claude Media
Opus 4.5の使用量上限・制限が急に厳しくなった理由と、当たったときの対処

Opus 4.5の使用量上限・制限が急に厳しくなった理由と、当たったときの対処

Opusの使用量上限・制限に急に当たるときの見分け方と対処、2026年1月にOpus 4.5で報告が相次いだ件の仮説をchangelogと照合します。

Opusの使用量上限や制限に急に当たったときは、まず表示される文言で種類を見分けます。You've hit your Opus limitならOpusファミリー限定の枠です。/modelでSonnetなどに切り替えれば、作業を続けられます。

session limitとweekly limitは全モデル共通なので、モデルを替えても戻りません。文言ごとの意味と対処は、後半の表にまとめています。

2026年1月8日の週次リセット以降、Claude CodeでOpus 4.5の使用量上限が急に厳しくなったという報告がGitHub Issueに集まりました。プランはMax・Pro・法人のPremium Seatまで幅広く、コメントは約40件に及びます。「使用パターンを変えていないのに数時間で上限に当たる」という訴えが共通しています。

この件に公式の原因説明は付いていません。コメントの1人はAnthropicがバグを認めたと書いていますが、出典は示されていません。利用者が挙げた仮説を当時のchangelogと照合すると、時系列と合わないもの、実在の修正と重なるもの、計測データが1人分しかないものが混在しています。あわせて、現在の上限メッセージの読み方と、消費の増えた原因を切り分ける手順も扱います。

2026年1月に何が報告されたか

GitHub Issue #17084は、2026年1月9日に起票されました。投稿者の整理では、Opus 4.5は2025年11月の提供開始時点では上限に妥当感があり、12月は「ホリデーボーナス」で上限が2倍でした。1月1日にボーナスが失効して通常水準へ戻り(この時点の厳格化は別issueの#16157・#16270が報告)、さらに1月6〜8日ごろ追加の引き下げが起きた、という見立てです。

あゆみ

1月のクライアント更新と報告の流れ

  1. 2025年11月Opus 4.5の提供開始

    投稿者によれば、この時点の上限は妥当でした。

  2. 2025年12月上限が2倍のホリデーボーナス期間

    投稿者の整理による時期です。

  3. 2026年1月1日ボーナス失効

    別issueの#16157・#16270が厳格化を報告しました。

  4. 1月7日v2.1.0 / v2.0.76 のリリース

    v2.1.0の修正項目に、サブエージェントが親のモデルを既定で引き継がないことがある不具合が入っています。

  5. 1月8〜9日週次リセットと#17084の起票

    リセット翌日だけで週次枠の27%を消費したという報告です。同じ9日にv2.1.2とv2.1.3が出ました。

  6. 1月13日v2.1.6のリリース

    週次リセット後、低い消費率でレート制限の警告が出る不具合が修正されました(警告は消費70%から)。

報告された数値には具体性があります。報告者の名前は伏せ、プランと内容だけ並べます。

プラン報告内容
Max(投稿者本人)報告内容週次リセット翌日だけで「All models」週次枠の27%を消費、当該セッションだけで33%消費
Max 5x報告内容単純作業1時間でセッション枠の67%を消費
法人Premium Seat報告内容実働できるのは1日約2時間・週10時間程度に体感が悪化
Max報告内容前週は2日で99ドル分使って週次枠の11%消費、当該週は1日目で13.52ドル分使って12%消費(自己算出で実効週次上限が約900ドルから約112ドルへ)
不明報告内容1月17日に「All models」週次枠38%消費、追加使用料が20ユーロ上限の102%に到達、12月と同じ使用パターンで悪化
Pro報告内容Sonnetを使っていても同時期に悪化(以前は2時間の作業が通ったのが、今は1時間が限度)

利用者が挙げた4つの説明と、changelogの照合結果

コメント欄では原因についていくつかの仮説が交わされました。当時のクライアントバージョンの公式changelogと突き合わせると、支持できるものとできないものに分かれます。

バックグラウンドエージェントがHaikuからOpusに変わった説

あるコメント主は、セッション開始時に自動起動する3つのバックグラウンドエージェントのうち2つがHaikuからOpusに変わったとみて、これが原因ではないかと投稿しました。changelogで「組み込みExploreエージェントが会話のモデルを継承する(Opusを上限にキャップ)」と記録されているのはv2.1.198(2026年7月1日)です。1月の時期からは半年ほど後の変更にあたります。

一方で、1月のchangelogにも近い項目はあります。v2.1.0に「サブエージェントが親のモデルを既定で引き継がないことがある不具合を修正」という行があります。コメントが指したchangelogの行がこれかどうかは、投稿からは分かりません。Haikuで動くはずの処理がOpusで動いたのか、その逆なのかも、この一行からは決まりません。

反論もあります。別のコメント主は「オーケストレーター構成で以前からサブエージェントに常時Opusを使っており、11月から変えていないのに影響を受けた」と書いています。サブエージェントのモデルが原因なら、この人の消費は変わらないはずです。

セッション開始時のトークン消費が増えた説

先のコメント主は別の投稿で、空のディレクトリでセッションを開いたときの実測値を報告しています。v2.0.72では入力が約1,000トークンだったのに対し、アップグレード後は約23,000トークンに増え、その多くがキャッシュ書き込みだったとのことです。v2.0.72に戻すと消費は減ったといいます。

1月21日の追加投稿では、バックグラウンドエージェントの入力が約900トークンから約1万のキャッシュ入力トークンへ約11倍に増えたとも書かれています(Opus、起動時のみ)。計測したのは本人の環境だけです。他の報告者の環境で同じ測定が出たという書き込みはありません。1月14日のv2.1.7では、MCPツールの説明がコンテキストの10%を超えると読み込みを遅らせて必要時に探す「MCPツール検索」の自動モードが、全員で既定になりました。MCPサーバーを多く入れた構成の起動時消費に効く変更ですが、この投稿の計測は空のディレクトリで行われています。

キャッシュが切れて再構築される説

1月27日には、別のコメント主が約18,000メッセージ(1月9〜27日、Max 100ドルプラン)の分析を投稿しました。メッセージ間隔が5分以内ならキャッシュ書き込みは平均3,600〜4,600トークン前後、5分を超えると平均約7万トークンに跳ね上がっています。コールドスタートは全体の2.3%でしたが、再構築に使ったトークンは合計約2,700万と見積もられています。

同じ投稿では、前週(1月16〜22日)は消費1%あたり1,520万トークン、当週(23〜27日)は1,100万トークンと、同じ56%の消費でもトークン量が27%減ったと書かれています。翌日には別のコメント主が、自分の環境で1時間キャッシュだけが使われているようで状況がかなり良くなった、と報告しました。どちらも個人の計測で、上限の引き下げを直接証明するものではありません。ただ、枠が何トークンに相当するかが週によって動いているように見える点は、次のサーバー側説と合います。

サーバー側で上限そのものが調整された説

複数のコメントが挙げた見方です。あるコメント主は「変更はすべてAnthropicのサーバー側で起きている」と述べ、クライアントを更新せずv2.0.76のままでも87%、同じ日の夕方には100%に達したと報告しました。Opusではなく通常のProプランでSonnetを使っている利用者も同時期の悪化を書いており、Opus 4.5固有ではなく、モデルをまたぐ調整だった可能性を示しています。

クライアントのバージョンに関係なく複数の利用者が同時期に同じ体感を報告している点は、この説と整合します。2月には、Opus 4.6の試験が上限の変動と関係していたのではという推測も1件出ましたが、根拠は書かれていません。

実在のバグ修正と、規模の問題

changelogに記録された事実もあります。1月9日のv2.1.3では「会話のコンパクション中にサブエージェントが誤ったモデルを使う」「サブエージェント内のweb検索が誤ったモデルを使う」の2件が直りました。サブエージェントのモデル選択に実在の不具合があったことは確かです。

ただし、この2件だけで報告された規模の消費増を説明できるとは言えません。自己算出で約900ドルから約112ドルへ、約8分の1になったという数字を説明できるかどうかは、changelogからは決まりません。

1月の報告に説明が付かないまま、5月に上限が引き上げられた

状況が動いたのは2026年5月6日です。Claudeの利用上限が引き上げられ、Pro / Max / Team / Enterprise(seat型)のClaude Codeの5時間ウィンドウ上限が2倍になりました。ピーク時間帯の制限引き下げもProとMaxで撤廃され、OpusのAPIレート制限も大幅に引き上げられています。裏付けとして示されたのが、SpaceX Colossus 1データセンターの300MW超の計算容量です。

この発表は1月の引き下げには触れず、新規容量の投入に合わせた引き上げとして出されました。

上限に当たったとき、メッセージから何が分かるか

公式ドキュメントによると、サブスクリプションプランの使用量上限に当たると次のいずれかが表示され、後ろにリセット時刻が付きます。

メッセージ意味対処
You've hit your session limit意味セッション枠(ローリングウィンドウ)を消費し切った対処表示されたリセット時刻まで待つ、/usage-creditsで追加購入
You've hit your weekly limit意味週次枠を消費し切った(全モデル共通)対処同上。モデル切り替えでは回避できない
You've hit your Opus limit意味Opusファミリー限定の枠を消費し切った対処/modelで別ファミリーに切り替えれば作業継続可
You've hit your Sonnet limit意味Sonnetファミリー限定の枠を消費し切った対処同上

セッション枠と週次枠は全モデル共通で、同時に消費されます。重いワークフローを一気に走らせると、セッションがリセットされる前に週次枠を使い切ることもあります。限定枠に当たった場合の切り替えには注意点があります。モデルごとにプロンプトキャッシュが別なので、切り替えた最初のリクエストは会話全体を読み直し、キャッシュは効きません。

v2.1.234以降は、claude.aiサブスクリプションでサインインした対話セッションなら、リセット時刻まで待って作業を再開する機能もあります。設定と挙動はClaude Codeの利用上限リセット後に自動再開する設定と止め方にあります。

起動時にモデルを選ぶ場合、v2.1.289のclaude --helpでは--modelがopusやsonnetといったエイリアスを受け付けると説明されています。

claude --model sonnet

--fallback-modelというオプションもありますが、ヘルプの説明は「既定のモデルが過負荷または利用不可のとき」の自動切り替えで、使用量上限には触れていません。

Opusの減りが早いと感じたときに変えられる設定

Opusは複雑な設計判断や多段の推論に充て、通常のコーディングはSonnetで足りる、というのが公式のコスト管理の考え方です。/modelで途中切り替えができ、既定のモデルは/configで変えられます。

Opusへ切り替えると、セッションのモデルを引き継ぐサブエージェントもOpusで動きます。単純な作業のサブエージェントには、設定でmodel: haikuを指定できます。推論が重くなる場面では、/effortで思考の深さを下げる手もあります。

消費が急に増えたと感じたときの切り分け

消費の内訳を自分で調べる手段は、2026年1月の時点より増えています。/usageのプラン別の内訳表示(スキル・サブエージェント・プラグイン・MCPサーバーごとの割合)はv2.1.149(2026年5月22日)で入りました。長文コンテキストやキャッシュミスといった挙動が直近の消費の10%以上を占めると、フラグが出ます。数値は手元のセッション履歴から概算するため、他の端末やclaude.aiでの利用は含まれません。

手順

消費が増えた原因を切り分ける

  1. 1

    当たった上限の種類を文言で見分ける

    session / weekly なら全モデル共通で、モデルを替えても戻りません。Opus / Sonnet なら、そのファミリー限定の枠です。

  2. 2

    /usageで内訳を見る

    スキル・サブエージェント・MCPサーバーのどれが直近の消費を押し上げているか、長文コンテキストやキャッシュミスのフラグが立っていないかを確かめます。

  3. 3

    ステータスラインで継続的に見る

    current_usageでリクエスト単位の内訳を表示できます。詳細はClaude Codeのcurrent_usageで直近リクエストの内訳を読むにあります。

  4. 4

    サブエージェントのモデル配分を見直す

    単純作業のサブエージェントにmodel: haikuを指定していない構成は、意図せず高コストなモデルで動き続けることがあります。設計の考え方はClaude Codeサブエージェントのモデル配分設計で扱っています。

/usage

1Mコンテキストのように、機能単位で使用量クレジットが要求される場合もあります(Usage credits required for 1M contextの意味と対処)。サーバー側の上限そのものが動いたかどうかは、利用者側からは見えません。似た「アイドル中にクォータ自体が動いた」という報告は別記事にあります。

まとめ

1月の厳格化に公式の原因説明は付かず、5月6日に容量拡大とあわせて上限が引き上げられました。複数の報告と整合するのはサーバー側の調整説で、サブエージェントのモデルや起動時トークンの説は個人の計測に留まります。

自分の消費が急に増えたときは、上限の文言で種類を見分け、/usageの内訳とキャッシュミスのフラグから確かめるのが手がかりになります。

参照した一次ソース

この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。

  1. github.com/anthropics/claude-code/issues/17084
  2. code.claude.com/docs/en/costs
  3. code.claude.com/docs/en/errors
  4. code.claude.com/docs/en/changelog
この記事を共有:XはてブLinkedIn