Opus 4.5の使用量上限が急に厳しくなった理由 — 2026年1月の一斉報告を振り返る

2026年1月8日の週次リセット以降、Claude CodeでOpus 4.5の使用量上限が急に厳しくなったという報告がGitHub Issueに20件以上集まりました。プランはMax・Pro・Enterprise Premium Seatまで幅広く、「使用パターンを変えていないのに数時間で上限に当たる」という内容が共通しています。Anthropicから公式な理由の説明は最後まで付きませんでした。利用者が挙げた仮説を当時のchangelogと照合すると、時系列が合わないものと実際に裏付けが取れるものが混在しています。本記事はその整理と、現在の使用量上限がどういう仕組みで動いているかをまとめます。

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

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

報告された数値には具体性があります。

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

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

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

コメント主のgerrywastakenは、セッション開始時に自動起動する3つのバックグラウンドエージェントのうち2つがHaikuからOpusに変わったとみて、これが原因ではないかと投稿しました。ただしchangelogを遡ると、組み込みExploreエージェントが「会話のモデルを継承(Opusを上限にキャップ)」する挙動に変わったのはv2.1.198です。投稿者らが問題を報告していたv2.0.76・v2.1.1の時期からは、大きく後の変更にあたります。同じスレッドでalex-feelも反論しています。「自分はオーケストレーター構成で以前からサブエージェントに常時Opusを使っており、11月から変えていないのに影響を受けた」という内容です。時系列・実例の両方で裏付けが弱い仮説です。

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

gerrywastakenは別の投稿で、空のディレクトリでセッションを開いた際の/context実測値を報告しています。v2.0.72では約1,000トークンだったのに対し、アップグレード後は約23,000トークン(多くがキャッシュ書き込み)に増えていたとのことです。これは本人の環境での実測ですが、母数が1人分で、他の報告者の環境で同様の測定は確認できません。

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

alex-feelは「変更はすべてAnthropicのサーバー側で起きている」と述べています。クライアントを更新していない(v2.0.76のまま)にもかかわらず87%、翌日には100%に達したと報告しました。binarybccのようにOpusではなくSonnetを使う通常のProプランでも同時期に同様の悪化を報告しており、Opus 4.5固有の変更というより、モデルをまたいだ広い調整だった可能性を示しています。クライアントのバージョンに関係なく複数の利用者が同時期に同じ体感を報告している点は、この仮説と整合します。

なお、実際にchangelogへ記録されている確かな事実もあります。同じ1月のv2.1.3では、2つのバグが修正されました。「サブエージェントがコンパクション時に誤ったモデルを使う」バグと、「サブエージェント内のweb検索が誤ったモデルを使う」バグです。これはバックグラウンドエージェントのモデル変更説を裏付けるものではありません(このバグはサブエージェントのモデル選択ロジックの不具合で、gerrywastakenが指摘したHaiku→Opusの起動モデル変更そのものとは別物です)。tyler6204の自己算出では実効週次上限が約900ドルから約112ドルへ下がったとされていますが、この2件のバグ修正だけでその規模の消費増加を説明できるとは、一次ソースからは判断できません。ただ、同じ時期にサブエージェントのモデル選択まわりに実在の不具合があったことは、公式記録から確認できます。

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

Issue #17084もその親issueの#16157・#16270も、Anthropicから原因を説明するコメントは付かないまま推移しました。状況が動いたのは2026年5月6日です。Claudeの利用上限が引き上げられ、Pro / Max / Team / Enterpriseの5時間ウィンドウ上限が2倍になりました。ピーク時間帯の利用制限も撤廃されています。同じ発表でOpusモデルのAPIレート制限も大幅に引き上げられました。裏付けとして示されたのが、SpaceX Colossus 1データセンターの300MW超の計算容量投入です。

この5月の発表は1月の引き下げに触れておらず、あくまで新規容量の投入に合わせた引き上げとして発表されています。1月の報告への説明は出ないまま、5月6日に容量拡大とあわせて上限が引き上げられました。

現在の使用量上限はどう分かれているか

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

セッション枠と週次枠は全モデル共通で同時に消費されるため、モデルを切り替えても回避できません。一方、OpusまたはSonnet限定枠に当たった場合は、/modelでそのファミリー外のモデルに切り替えれば作業を続けられます。v2.1.234以降は、対話セッションであればリセット時刻まで自動で待って作業を再開する機能もあります。条件はclaude.aiサブスクリプションでのサインインです。設定と挙動はClaude Codeの利用上限リセット後に自動再開する設定と止め方にまとめています。

「なぜ自分の消費が急に増えたのか」を利用者自身が調べる手段も、2026年1月の時点より増えています。/usageはスキル・サブエージェント・プラグイン・MCPサーバーごとの消費割合を出す内訳表示を備えています。長文コンテキストやキャッシュミスといった挙動フラグが、直近の消費の10%以上を占めると警告も出ます。使用量クレジットは1Mコンテキストのように機能単位で要求されることもあります(参考: Usage credits required for 1M contextの意味と対処)。上限に当たる前に自分の消費内訳を把握する手段は、確実に増えています。

急に消費が増えたと感じたら何を確認するか

急に消費が増えたと感じたときに切り分けられる点は次のとおりです。

1. /usageの内訳表示でスキル・サブエージェント・MCPサーバーのどれが直近の消費を押し上げているか確認する
2. ステータスラインのcurrent_usageでリクエスト単位の内訳を継続的に見る(詳細はClaude Codeのcurrent_usageで直近リクエストの内訳を読む)
3. 当たった上限がセッション/週次(全モデル共通)なのか、Opus/Sonnet限定なのかをエラーメッセージの文言で見分ける。限定枠なら/modelで別ファミリーに切り替えて作業を続けられる
4. サブエージェントを多用する構成なら、モデル配分が意図どおりかを見直す。単純作業のサブエージェントにmodel: haikuを指定していない構成は、意図せず高コストなモデルで動き続けていることがあります。設計の考え方はClaude Codeサブエージェントのモデル配分設計で扱っています

/usage

サーバー側の上限そのものが変わったかどうかは利用者側からは確認できませんが、少なくとも自分の消費がどこで増えているかは、2026年1月の時点よりはっきり見える状態になっています。

まとめ

2026年1月のOpus 4.5使用量上限の急な厳格化には、Anthropicからの公式説明が付きませんでした。1月の報告への説明は出ないまま、5月6日にSpaceX由来の容量拡大とあわせて上限が引き上げられています。原因として挙がった3つの仮説のうち、バックグラウンドエージェントのモデル変更説はchangelogの時系列と合いません。トークン消費増加説は個人の実測に留まります。最も複数の報告と整合するのは、サーバー側での調整説です。単一の確定した答えは無い出来事ですが、当時の報告と公式記録を照合すれば、何が起きたと言えて何が言えないかの線は引けます。