ストアの説明文を十数か国語ぶん並べて見比べていた午前のことです。個人開発の壁紙アプリに新しいカテゴリを足すにあたり、その名前をどう訳し分けるか、過去のレビュー指摘をまとめた PDF を三つ添えて、一つの会話のなかで一語ずつ相談しておりました。十一時を少し回ったころ、送った一文の下に「使用量の上限に達しました」という帯が出て、再開できる時刻だけが示されました。
最初に浮かんだのは「今日はまだそんなに送っていないはずなのに」という戸惑いです。送った回数を指折り数えても、ふだんの半分ほどでした。同じ戸惑いを覚えた方がいらっしゃるかもしれません。——けれど、止まった理由は回数ではありませんでした。
最初にお伝えしたいのは、この帯が出たときに見るべきものは送信履歴ではなく、設定画面の二本のバーと、いま開いている会話の重さだということです。私が順番に見た三つの数字と、そこから引いた線引きを書き残します。
症状の見分け方 — 止まったのは「どの上限」か
Claude には性質の違う上限が二種類あります。使用量の上限と、長さの上限です。前者は一定時間のあいだにどれだけ使えるかという「予算」で、後者は一つの会話にどれだけの情報を載せられるかという「器」です。公式ヘルプの説明に沿って、私は次のように見分けております。
| 画面に出る手がかり | 上限の種類 | 回復の仕方 |
|---|---|---|
| 「使用量の上限に達しました」と再開時刻 | セッション上限（五時間の窓） | 時刻を待つ。新しい会話を開いても送れない |
| 週の上限とリセットの曜日・時刻 | 週次上限 | 七日周期のリセットを待つ |
| 会話が長すぎる旨の文言 | 長さの上限（コンテキスト） | 新しい会話を始めれば続けられる |
見分けの要点は一つで、新しい会話を開いて送れるなら長さの上限、開いても送れないなら使用量の上限です。私の場合は新しい会話でも同じ帯が出ましたので、使用量のほうでした。
ここで一つ、見落としていたことがあります。使用量は claude.ai と Claude Desktop、そして Claude Code のすべてで一つの枠を分け合っています。あの朝、別のウィンドウではヒーリング音源アプリの古い通知コードを Claude Code に整理させておりました。会話を止めたつもりでいても、隣の窓は同じ財布から払い続けていたのです。
数字① Settings > Usage の二本のバー
最初に見る場所は、設定の「Usage」です。Pro・Max・Team と席数制の Enterprise では、ここに「現在のセッション」と「週の上限」の二本の進捗バーが並び、セッションの残り時間と、週のリセット日時が表示されます。
私はこの画面を開くまで、セッションという単位を意識しておりませんでした。五時間の窓は最初のメッセージから数え始めますので、朝九時に送れば十四時までが一つの窓です。帯に出ていた再開時刻は、ちょうどその区切りでした。
ここで見るのは残り時間よりも、二本のバーの伸び方の差です。十一時の時点で週のバーがほとんど動いていないのにセッションのバーだけが満ちていれば、「今週使いすぎた」のではなく「この数時間に何か重いことをした」のだと切り分けられます。私の朝はまさにその形でした。
数字② その会話の往復数と添付の量
次に見たのは、止まった会話そのものです。上から辿ると四十往復を超えており、最初のほうに三つの PDF、途中で表計算のスクリーンショットが二枚ありました。
ここが思い込みの正体でした。Claude は一通ごとに、それまでの会話をもう一度読み直してから答えます。四十往復目の一文は、その一文だけでなく、三つの PDF と三十九往復ぶんの文章を背負って送られているのです。送った「回数」は少なくても、一通あたりの「重さ」は朝の最初の一通とは比べものにならないほど育っていました。
公式ヘルプも、長い会話が自動コンテキスト管理（「考えを整理しています」という表示）に入ると使用量をより多く消費すると書いており、上限が近いなら新しい会話を始めるよう勧めています。その一節を読んで自分の朝の正体に気づいたのは、止まったあとでした。
添付の量を感覚で測らないために、いまは渡す前にページ数を数えています。macOS の標準の Python にライブラリを一つ足すだけで動く短いスクリプトです。
# 添付候補の PDF を、ページ数の多い順に並べて見積もる
# 何を解決するか: 「三つだけ」と思って渡した PDF が合計で何ページあるかを先に知る
from pathlib import Path
from pypdf import PdfReader # pip install pypdf
folder = Path.home() / "Documents" / "store-review-notes"
rows = []
for pdf in folder.glob("*.pdf"):
try:
pages = len(PdfReader(pdf).pages)
except Exception: # 壊れたファイルは -1 を残して先へ進む
pages = -1
rows.append((pages, pdf.name))
for pages, name in sorted(rows, reverse=True):
print(f"{pages:>4} p {name}")
print(f"合計 {sum(p for p, _ in rows if p > 0)} ページ")なぜこう書くかと言えば、判断したいのは一冊の厚さではなく合計だからです。私の三つは合わせて百ページ近くありました。四十往復のあいだ、毎回その百ページが読み直されていたと考えれば、昼前に尽きたのは不思議ではありません。
数字③ 送信ボタンの隣にあるモデル名と effort
三つ目は、送信ボタンの隣に出ているモデル名と effort です。effort は応答ごとにどれだけ考えるかの深さで、高くすれば丁寧になりますが、その分トークンを使い、上限に早く届きます。Low と Medium が日常の作業向け、High が品質と速さの均衡、xhigh と Max は長時間の実装や深い分析向けと、ヘルプは位置づけています。
私はその朝、前日の実装相談の設定のまま High で訳語の相談をしておりました。訳語の揺れを見比べるだけなら Medium で足りたのです。さらに、Opus 5.5 と Fable 5.1 では thinking を切ることができませんので、effort を下げる以外に軽くする手がありません。モデル名を見て「重いほうのままだった」と気づく、それだけで次の窓の使い方が変わります。
接続しているコネクタと Web 検索も同じで、ヘルプははっきり「トークンを多く消費する」と書いています。訳語の相談に Web 検索は要りませんでしたのに、前の会話の設定から切っていませんでした。
直し方 — 私が引いた三本の線
切り分けができたあと、次の窓からは三つのことを変えました。
一つ目は、会話を切り替える合図を決めたことです。添付を三つ以上渡した会話で「考えを整理しています」が出たら、そこで要約を一段落だけ書かせて新しい会話へ移ります。要約には結論・残っている論点・次に渡す資料名の三項目だけを残しております。
二つ目は、繰り返し参照する資料をプロジェクトに置くことです。プロジェクトの知識はキャッシュされ、再利用時には新しい内容より少なく数えられます。毎回会話に PDF を貼り直していた私のやり方は、いちばん高い払い方でした。
三つ目は、作業の種類で effort を切り替えることです。訳語の比較や文面の整えは Medium、仕様の読み解きや実装の相談だけ High に上げます。
節約すべきは送る回数ではなく、一通ごとに背負わせる過去の量です。 この線引きをしてから、同じ午前の作業が窓の半分で収まるようになりました。
直らないときの次の一手
三つを見直しても上限に届く日はあります。そのときの順番も決めてあります。
まず、設定の Usage に「Reset for free」が出ていないかを見ます。対象のプランには時々リセットが配られ、押せばセッションか週の上限がその場で満タンに戻ります。ただし一度使うと戻せず、期限付きのこともあり、ボタンは Web と Desktop にだけ出ます。モバイルとターミナルの Claude Code からは押せませんので、ブラウザを開く手間だけは要ります。
次に、待てない仕事なら使用量クレジットです。Usage の画面で有効にして前払いしておけば、上限に届いても API の標準料金で続けられます。月の上限額を「Adjust limit」で決めておけば、使いすぎの不安は抑えられます。私は上限額を小さく置き、発動したら「今週の使い方を見直す合図」と受け取るようにしております。
そして、どちらも使わずに待つ日もあります。再開時刻までの空白に、添付する PDF をページ数で削り、要約の一段落を書いておくと、次の窓の最初の一通が軽くなるのです。
無人で動く定期タスクでは、この「毎回読み直される量」がもっと見えにくい形で積み上がります。手順書が一回の実行で何度読み直されているかを数えて削った記録は、定期タスクの手順書を削る前に、その一冊が何回読み直されるかを数えました に書き残しております。
まずは次に上限の帯を見た瞬間、送信履歴ではなく Settings > Usage を開いて、二本のバーのどちらが満ちているかを見ていただければと思います。私の午前は、その一手から軽くなりました。