Claude CodeをClaude Proで使っていると、必ずと言っていいほど悩まされるのがUsage Limitの上限です

実際の消費量は、メッセージの長さ、添付ファイル、会話履歴の長さ、使っているモデルや機能によって変わります。Proには5時間ごとにリセットされるsession-based limitがあり、さらにweekly usage limitもあります。(Claude Help Center)

Claude Proを前提に、基本的には「利用枠にはいつか当たる」と考えて運用しています。そのうえで、できるだけ無駄なcontextを持たせず、重い作業を始めるタイミングを調整し、必要な情報は会話ではなくファイルに逃がすようにしています。

/clear

新しい作業を始めるときや、モデルを切り替えるときは、まず /clear するようにしています。

/clear は、空のcontextで新しい会話を始めるためのコマンドです。前の会話自体は /resume から戻れるので、作業を完全に捨てるわけではありません。むしろ、今の作業に必要ない古い履歴を切り離すために使っています。(Claude Code)

注意したいのは、モデル切り替え時と長時間idleが発生するときです。

Claude Codeでは、各modelが別々のprompt cacheを持っています。そのため、/model でモデルを切り替えると、会話内容が同じでも次のrequestでは会話履歴全体をcache hitなしで読み直します。長い会話を抱えたままモデルを切り替えると、最初の一発でかなり利用枠を消費する可能性があります。(Claude Code)

また、セッションをまたぐような長時間のidleが発生する時も注意が必要です。Claude subscriptionではClaude Codeのmain conversationに1時間TTLのprompt cacheが使われますが、長時間idleにするとcacheはexpireします。reset待ちなどで1時間以上空けてから再開すると、次の入力で長い履歴を再処理することがあります。(Claude Code)

さらに、新しいClaude Code sessionではworking directory、OS、shell、git status snapshotなどがprefixに影響します。公式ドキュメントでも、sequential sessionsがcacheを共有できるのは、同じmachine・directoryで、かつ起動時のgit status snapshotが一致する場合だと説明されています。つまり、セッション再開時にprefixが変わったり、TTLが切れたりして、結果的にcache missになりやすいと考えた方がよいです。(Claude Code)

そのため、私はモデルを変える前や、作業を長時間止める前に、必要な情報をplanやspecとしてファイルに残してから /clear するようにしています。新しいsessionの最初の入力で、いきなり過去の長い会話履歴を背負わせるのは避けた方がよいです。

同じ作業を続けたい場合は /clear ではなく /compact を使います。/compact は会話履歴をsummaryに置き換えるため、conversation layerのcacheは作り直しになりますが、次のturnでは短いsummaryだけを元にcacheを再構築できます。古い履歴を捨ててよい自然な区切りで使うと、利用枠の節約にも精度維持にも効きます。(Claude Code)

/schedule で早朝にセッションを始めます

Claude Proでは5時間ごとのsession limitがあります。朝6時に作業を始めると、11時、16時のように、日中の作業時間で複数回のリセットを見込みやすくなります。(Claude Help Center)

また最近は利用枠が緩和されてるため5時間のsessionをクリアさえすればかなりのtoken量を使えるようになります。2026年5月6日にAnthropicは、Claude Codeの5時間rate limitsをPro/Max/Team/Enterprise向けに2倍にし、Pro/Maxのpeak hours limit reductionを取り除いたと発表しました。さらに、Claude Codeのweekly limitsを7月13日まで50%増やしています。(Anthropic, ClaudeDevs, Business Insider)

とはいえ、ProでClaude Codeを集中的に使うと、5時間セッションをすぐに使い切ってしまいます。weekly limitが一時的に緩くなっていても、短時間で重い作業を詰め込めばsession limitには普通に当たります。

私は日中の働く時間でセッションのresetをなるべく増やしたいので、早朝に /schedule で定期作業を走らせるようにしています。/schedule はClaude Codeのroutinesを作成・更新・実行するためのコマンドで、routinesはAnthropic管理のcloud infrastructure上で動きます。朝のうちにhelloなどのコマンドを打つように設定しておくと、日中の5時間枠を意識しながら作業しやすくなります。(Claude Code) sessionの開始タイミングを意識するだけで日中のresetの回数が2回から3回に増やせます。

なるべく英語で指示します

正直、これは誤差です。ただ、日本語より英語の方がtoken効率がよいことが多いので、短く済む指示は英語で書くようにしています。

ただし、これは絶対ではありません。tokenizerによって言語ごとのtoken数は変わりますし、同じ意味の文章でも言語によってtokenization lengthが大きく変わることは研究でも指摘されています。AnthropicにもToken Count APIがあり、promptのtoken数を事前に見積もる用途で使えると説明されています。(arXiv, Claude API Docs)

英語で書いた結果、意図が伝わらず、修正の往復が増えるなら逆効果です。なので私は、短い命令や明確な作業指示は英語で書き、微妙なニュアンスや仕様の説明は日本語で書くようにしています。

たとえば、次のような短い指示は英語で十分です。

Read docs/superpowers/plans/foo.md and execute Task 1 only.
Do not modify unrelated files.
Run the specified tests and report the result.

一方で、仕様の背景や判断基準を伝えるときは、日本語で正確に書いた方が結果的に安く済むことがあります。

planとspecはファイルに書き出す

Claude Codeで大きめの作業をする場合、planやspecを会話の中だけに置かないようにしています。必ずファイルに書き出します。

これはかなり重要です。会話履歴に作業状態を持たせると、/clear した瞬間に前提が失われます。しかし、planやspecをMarkdownファイルにしておけば、/clear 後でもそのファイルを読ませるだけで作業を再開できます。

私はSuperpowersのwriting-planやwriting-spec系のスキルを使うことがあります。Superpowersのbrainstormingスキルはdesign/specを docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md に保存する流れを持ち、writing-plansスキルはimplementation planを docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md に保存するよう設計されています。(GitHub, GitHub)

ツール自体はSuperpowersでなくても構いません。重要なのは、会話を作業状態の保存場所にしないことです。

会話には「今やること」だけを置きます。仕様、計画、検証手順、変更理由はファイルに逃がします。そうすると、/clear しても作業効率を落とさずに続けられます。

安いモデルを使う

すべての作業をOpusでやる必要はありません。

Claude Code公式のcost管理ドキュメントでも、Sonnetは多くのcoding taskをうまく処理でき、Opusより安いと説明されています。一方で、Opusは複雑なarchitecture decisionやmulti-step reasoningに残すのがよいとされています。(Claude Code)

私は正直、ここはあまり徹底できていません。ただ、Superpowersのskillやsubagentを使っていると、単純なサブタスクはSonnet側に寄せられることがあり、その分だけ節約になっている印象があります。公式ドキュメントでも、simple subagent taskではsubagent configurationでHaikuを指定する選択肢が紹介されています。(Claude Code)

一方で、複数のsubagentを束ねるような作業や、全体設計を判断する作業は、私の体感ではOpusの方が安定します。ここを無理にケチると、やり直しが増えて逆に利用枠を消費することがあります。

なので、よくやるパターンはsuperpowersのSKILL.md通り、単純な実装、調査、テスト修正、ファイル単位の作業はSonnetに寄せて、設計判断、複雑なデバッグ、subagentのオーケストレーション、長い計画のレビューはOpusを使っています。

まとめ

Claude ProでClaude Codeを使う場合、基本的には利用枠上限に当たることを前提にした方がよいです。

大事なのは、不要なcontextを持ち続けないことです。新しい作業を始めるときやモデルを切り替えるときは /clear します。同じ作業を続ける場合は /compact でcontextを整理します。長い会話に状態を持たせず、planやspecはファイルに書き出します。

また、5時間セッションの開始タイミングも意識します。早朝に作業を始めると、その日の中で複数回のリセットを使いやすくなります。/schedule を使えば、定期作業の開始タイミングもある程度コントロールできます。

指示は、短く済むなら英語で書きます。ただし、英語にしたせいで意図がずれるなら日本語で書いた方がよいです。token効率よりも、やり直しを減らす方が重要です。

モデルは、普段の作業ではOpusに寄せ、SKILLによって判定された仕事はSonnetに任せています。安いモデルを使うこと自体が目的ではなく、利用枠の中で一番失敗しにくい配分にすることが目的です。やすいモデルを使って満足のいくアウトプットが出なかったら意味がないからです。

このように作業状態の管理を意識することが。会話にすべてを抱え込ませず、必要な情報をファイルに逃がし、sessionを軽く保つことが一番効く感じがします。

この記事は Zenn にも転載しています。