5時間の上限に当たったとき、まず疑うべきは自分が書いたプロンプトの量ではない。裏で動いているMCPサーバーやサブエージェントだ。Claude Code 2.1.149で /usage がカテゴリ別の内訳を出すようになって、その「犯人」が初めて目で見えるようになった。実際に叩いてみたら、私の環境では上限消費の約6割が1本のMCPサーバーに集中していた。
結論:上限に当たる人ほど、まず/usageを開くべき
先に言い切ってしまう。レート上限の体感が悪い人は、プラン変更を検討する前に /usage を一度開いたほうがいい。
5月6日にPro/Maxの5時間上限が倍増したのは記憶に新しい。だが倍になっても当たる人は当たる。理由はシンプルで、消費しているのが人間の入力ではなく、自動で走るスキルやMCPツール呼び出しだからだ。
従来の /usage は「上限に対して今どれくらい使ったか」という総量しか見せてくれなかった。何が消費しているかは、ログを追うか勘で当てるしかない。2.1.149はここを変えた。skills、subagents、plugins、そしてMCPサーバーごとのコストを、内訳として分解して表示する。
地味なアップデートに見える。私も最初はそう思った。実際に開くまでは。
何が変わったのか:総量表示から「要因の分解」へ
公式CHANGELOGの2.1.149(2026-05-22)には、こう書かれている。
/usagenow shows a per-category breakdown of what’s driving your limits usage — skills, subagents, plugins, and per-MCP-server cost
ポイントは per-MCP-server の部分だ。MCPサーバーを2本3本と接続していると、どのサーバーがトークンを食っているのか、これまで切り分けようがなかった。Playwright系のブラウザ操作MCPや、巨大なスキーマを返すデータベースMCPは、ツール定義をコンテキストに常駐させるだけで重い。そこが個別に見える。
これはVim時代に、起動が遅い原因のプラグインを vim --startuptime で1本ずつ炙り出していた作業に、構造がよく似ている。重い犯人は、だいたい自分が「便利だから」と入れたやつだ。
実装手順:接続中のセッションで叩くだけ
特別な設定はいらない。バージョンを上げて、セッション内でスラッシュコマンドを打つ。
# まずバージョン確認(2.1.149以上であること)
claude --version
# 更新が必要なら
claude updateセッションを起動し、対話画面で次を入力する。
/usageすると5時間ウィンドウと週次の消費に加えて、カテゴリ別の内訳が出る。内訳は skills / subagents / plugins / MCPサーバー(サーバー名ごと)に分かれている。/diff 同様、長い表示はキーボードでスクロールできるようになったので、項目が多くても追いやすい。
実測結果:上限消費の62%が1本のMCPに集中していた
検証は、普段の開発で接続しているMCPを全部つないだ状態で行った。接続していたのは、ブラウザ操作系1本、ファイル検索系1本、社内データ参照系1本の計3本。スキルは7つ、サブエージェントは日常的に2〜3体走らせている。
3時間ほど通常作業をした直後に /usage を叩いた。結果はこうだった。
- ブラウザ操作MCP: 上限消費の約62%
- subagents(2〜3体): 約19%
- skills(7つ合計): 約11%
- 残り(plugins・その他MCP・素のプロンプト): 約8%
正直、ここまで偏っているとは思っていなかった。私の感覚では「サブエージェントを並列で回しているのが一番重い」はずだった。実際の犯人は、たまにしか使わないブラウザ操作MCPのほうだ。ツール定義とページのスナップショットが毎ターン乗るため、待機しているだけでコストを生んでいた。
対処は単純で、そのMCPを常時接続から外し、ブラウザ作業をするセッションだけ --mcp-config で個別に立ち上げる運用に変えた。これで同じ3時間作業での上限消費体感が、ざっくり4割ほど軽くなった。数字で言えば、以前は3時間弱で上限警告に届いていたのが、5時間ウィンドウを使い切らずに済むようになった。
限界と注意点
過信は禁物だ。3点ほど。
第一に、内訳はあくまで「直近ウィンドウの傾向」であって、リアルタイムの精密な課金明細ではない。割合は作業内容で日々ぶれる。
第二に、per-MCP-server の数値は接続構成に強く依存する。MCPを1本しか繋いでいない人には、当然ながら大きな発見はない。恩恵が大きいのは、3本以上を常時接続しているヘビーユーザーだ。
第三に、これは消費を「見せる」機能であって「減らす」機能ではない。減らすのは結局、構成を見直す人間側の判断になる。
私見:レート上限論争の論点がひとつ前に進んだ
レート上限を巡る議論は、ずっと「上限が厳しい/緩い」という総量の話に終始してきた。私はこの構図自体が不健全だと思っている。
本当の問題は、多くの人が「自分の上限を何が食っているか知らないまま」上限に当たっていたことだ。今回の内訳表示は、その情報の非対称を埋める。上限が足りないのか、それとも構成が無駄に重いだけなのか。これを切り分けてから初めて、プラン変更の議論ができる。
個人的には、この手の「コストを可視化するだけ」の機能は過小評価されがちだと感じる。派手な新モデルより、こういう地味な計測機能のほうが、日々の生産性にはよほど効く。
次に試すのは、この内訳をもとにMCPの常時接続を最小構成まで削り、用途別に起動プロファイルを分ける運用だ。ブラウザ操作のように重いMCPは、必要なセッションでだけ --mcp-config 指定で呼ぶ。skillsも、7つのうち毎日使うのは3つだけだったので、残りを遅延ロードに回せないか検証したい。上限が「足りない」のか「無駄に重いだけ」なのか。その切り分けを習慣にできれば、プラン論争に振り回される時間そのものが減るはずだ。来週また、数字で確かめる。
※本記事は2026-05-25時点の Claude Code 2.1.149 を実際に操作して検証した内容です。表示や数値は環境・接続構成・バージョンにより変わります。最新仕様は公式CHANGELOGをご確認ください。
