Claude Code を本格的に使い始めると、必ず「上限に達しました」に出会います。この章はそれを避けるための運用を扱います。
ただし目的は節約そのものではありません。肝心なときに枠が残っている状態を作ることです。ケチって成果が落ちれば本末転倒なので、最後に線引きの話もします。
なぜ消費が増えるのか
消費の単位はトークンです。ここで多くの人が誤解するのは、「送った指示の長さ」だけでは決まらないという点です。
Claude が自分で読みに行ったファイルは、すべて入力に乗ります。大きなファイルを丸ごと読ませると一気に増える。
やり取りのたびに、それまでの履歴も一緒に送られます。長い会話は1往復あたりの単価が上がる。
テストが通るまで直し続ける動きは、失敗のたびに1往復ぶん消費します。強みの裏側。
この3つのうち、あなたが最も動かせるのは FACTOR 2 です。読むファイルは作業内容で決まり、試行回数は難易度で決まりますが、履歴の長さは運用で変えられます。
「短く指示すれば安い」は誤解です。 指示が短すぎて意図が伝わらないと、Claude は探索を増やし、外した実装を作り、やり直します。結果として往復が増えて高くつく。安いのは短い指示ではなく、一度で通る指示です。
枠は1種類ではない
第4章でも触れましたが、ここが運用のいちばんの勘所です。短い周期の枠と、長い周期の枠が別々にあります。
短いほうは比較的すぐ回復するので、待てば作業を再開できます。長いほうは回復まで日単位で、ここを使い切ると数日動けなくなります。「さっき復活したのにまたすぐ止まった」という経験は、短いほうだけが戻って長いほうが残っていた状態です。
枠の挙動そのものは usage limit reached の対処 に、週次の枠が想定より早く戻る現象を実測した結果は 週次上限の早期リセットの真相 にまとめてあります。
締め切り前の重い作業を先に済ませ、探索的な実験は枠に余裕がある時間帯に回す。
長い枠を試行錯誤で使い切り、本番作業の当日に動けない。回復を待つしかなくなる。
工数（effort）― 速さと賢さを選ぶ
Claude Code には、どれだけ考えさせるかを選ぶ設定があります。深く考えさせれば精度は上がりますが、そのぶん時間も消費も増えます。
ここは「常に最大」でも「常に最小」でも損をします。タスクの難しさで切り替えるのが正解です。
定型的な置換、フォーマット、テストの追加、既に方針が決まっている実装。考える余地が無い作業。
原因が分からないバグ、設計の選択、影響範囲が読めない変更。間違えると手戻りが大きい作業。
設定の中身と使い分けは 工数（effort）とは？速い↔賢いの使い分け で扱っています。手戻りのコストと比べるのが判断軸です。深く考えさせて1回で通るなら、軽くして3回やり直すより安く済みます。
コンテキストを畳むのはコストの話でもある
第3章では「思い出せなくなるから畳む」という文脈で扱いましたが、畳む動機はもう1つあります。長い履歴は毎回送られるので、畳まないまま作業を続けると1往復あたりの消費が膨らみ続けます。
とはいえ、畳むこと自体にも消費があります。畳みすぎると、必要な前提まで失って説明し直すことになり、かえって高くつく。判断基準は /compactは手動でやるべきか にまとめました。
畳むタイミングの目安
よい : 1つの作業が終わった直後
別のファイル群に移る前
悪い : 作業の途中（今から使う前提まで消える）
「なんとなく長くなったから」（判断が無い）
無駄になりやすい使い方
消費の大半は、成果に結びつかない往復から生まれます。よくある型を挙げます。
テストが無いと「できました」を確かめられず、あなたが見て指摘して、やり直す往復が増えます。
数千行のうち必要なのは数十行。該当箇所だけ渡せば同じ結果が安く出ます。
無関係な作業まで同じ履歴に積み上がり、以降ずっと運ぶことになります。
プロジェクト固有の決まりごとは、第6章の永続メモリに置けば毎回書かずに済みます。
自分の消費を把握する
減らす前に、いま何にどれだけ使っているかを知るほうが先です。感覚で節約しても、たいてい効かない場所を削っています。
見るべきは2つ。いまの会話がどれだけ膨らんでいるかと、枠がどれだけ残っているかです。前者は畳む判断に、後者は「今日この作業を始めてよいか」の判断に使います。
残りの枠。重い作業を始めてよいかを決めます。残りが少ないなら、軽い作業に切り替えるか、回復を待つ。
会話の膨らみ具合。次の作業に移る前に畳むかを決めます。作業の途中では見なくてよい。
大事なのは見る頻度を上げないことです。数分おきに残量を確認しても消費は減りません。作業の境目で見れば足ります。
やってはいけない節約
節約のつもりで逆効果になるやり方があります。どれもよく見かけます。
前提が伝わらず、外した実装を作らせてやり直しが増える。削るなら説明ではなく貼り付ける量。
作業の途中で畳むと、いまから使う前提まで消える。説明し直すぶん高くつきます。
原因不明のバグを浅く考えさせると、外れた仮説を何度も試す。時間も消費も増えます。
止まっている状態でいじっても効果を確かめられません。回復してから、1つずつ試す。
チームで使うときに増えるもの
一人で使っているうちは気にならなかった消費が、チームに広げると別の形で表面化します。
いちばん多いのは、全員がそれぞれ同じ前提を説明している状態です。プロジェクトの決まりごと、命名の規約、触ってはいけない場所——これらを各自が毎回書いていれば、人数ぶん重複します。第6章の永続メモリに置いてリポジトリで共有するのが正解です。
もう1つは、誰かが探索的な使い方で枠を消費し、別の誰かが本番作業で止まる型です。個人の枠か組織の枠かで挙動が変わるので、導入前にそこだけは確認しておいてください。
ルールで縛るより、共有物を整えるほうが効きます。 「トークンを節約せよ」と言っても各自の判断がばらつくだけですが、永続メモリと検証手段がリポジトリに揃っていると、全員の往復が自然に減ります。
実践 ― 消費を減らす7つの手
効果が大きい順に並べます。上の2つで大半が解決します。
履歴が短いほど1往復が安い。いちばん効きます。
自分で確かめて直せる状態にすれば、あなたとの往復が減ります。
対象ディレクトリやファイルを指定する。探索ぶんが丸ごと減ります。
定型作業に最大は要りません。難所には惜しまない。
毎回説明している内容があれば、それは書き置く対象です（第6章）。
作業が終わった直後に。途中で畳むと説明し直しになります。
調査を別の文脈に切り出せば、本体の履歴が汚れません（第6章）。
コーディング全般でのコスト最適化は AIコーディングのコスト最適化大全 に、より広い視点でまとめています。
節約しすぎないための線引き
最後に、この章で最も言いたいことです。節約は目的ではありません。
枠を気にするあまり、難しい作業まで軽い設定で回し、外れた実装を何度も直す——これは消費も時間も両方増えます。節約のつもりで浪費している典型です。
判断は「手戻りの大きさ」で。 間違えても数分で戻せる作業は軽く速く。間違えると半日溶ける作業は、最初から深く考えさせる。枠は、後者のために取っておくものです。
そしてもう1つ。止まったら休むのも運用のうちです。上限に達したときに設定をいじり倒すより、回復を待って万全の状態で再開したほうが、結果的に早く終わります。
まとめ
- 消費は読んだファイル・会話の履歴・試行の回数で決まる。動かせるのは主に履歴
- 「短い指示＝安い」は誤解。一度で通る指示が安い
- 枠は短い周期と長い周期の2種類。長いほうを使い切ると数日動けない
- 工数は難易度で切り替える。常に最大も常に最小も損
- 畳むのは記憶の話であると同時にコストの話。ただし途中で畳むと高くつく
- 効果が大きいのは会話を分けることと先に検証手段を渡すことの2つ
- 節約は目的ではない。手戻りの大きさで判断し、難所のために枠を残す