Claude Codeの使用量が足りない。実測したら犯人はCLAUDE.mdだった

職業訓練の授業が始まる前に、Claude Codeのセッション制限に達しました。講師に聞けるので困り果てたわけではありません。ただ、プログラミング未経験の身にとって、細かい疑問を気軽に何度でも投げて、その場ですぐ試せる相棒がいないのは地味に困ります。契約は月200ドルのプラン（Claudeの有料プランで、使用量枠がいちばん大きいもの）なのに、です。

結果を先に書くと、原因を実測で特定し、契約を1つも変えずに、1日の固定消費を約62%削減 しました。犯人はCLAUDE.md（Claude Codeがプロジェクトごとに自動で読み込む指示書ファイル）です。

この記事は「何を測って、どう判断したか」の記録です。測り方はそのまま真似できます。

状況：火曜の時点で、週の枠を40%使っていた

使用量の枠は週単位で、私の環境ではリセットは土曜の朝です（リセットの曜日は人によって違う可能性があります）。火曜の時点で、すでに週の枠の40% を使っていました
公式の告知では、9月14日から標準の週間上限が恒久的に25%引き上げ になります。現在適用中の「50%増量」と比べると 1.25 ÷ 1.50 ＝約0.83。実質はおよそ17%減る 計算です
サイトの自動処理をClaude Codeのスケジュール実行（決まった時刻に自動で動く仕組み。以下「ルーチン」）に任せており、枠が尽きるとサイトの更新が全部止まります

上のプランに乗り換える逃げ道はありません。すでにいちばん上です。授業前の一件は事故ではなく、構造的に足りていない状態の表れでした。

最初に考えた「他社への移行」は、「移す」ではなく「分ける」問題だった

最初に考えたのは「別のAIサービスに処理を逃がせないか」でしたが、調べると他社のコーディング支援サービスにも使用量の枠があります。多くは時間単位と週単位の二段構えで、週の上限が非公開のものもありました。

全部を別の1社に移しても、「枠が尽きたら止まる」構造は変わりません。単一障害点（そこが止まると全体が止まる箇所）が別の場所に移動するだけ です。

しかし「分ける」なら話は別です。処理を複数のサービスに分ければ、片方の枠が尽きてももう片方は動きます。冒頭の場面がまさにそれで、自動処理が別のサービスで動いていれば、授業前でもClaude側の枠は残っていたはずです。問うべきは「移行するかどうか」ではなく 「どう分けるか」 でした。

ただし、分けるには追加の費用がかかります。その判断の前に自分の使い方を直す——それには、何が枠を食っているかをまず測る必要がありました。

実測：履歴を集計したら、1つのプロジェクトが54.6%を占めていた

Claude Codeはやりとりの履歴を ~/.claude/history.jsonl に残しています。1行が1回のやりとりで、実行プロジェクト（作業フォルダ）が project 欄に入っています。プロジェクト別に集計します。

jq -r .project ~/.claude/history.jsonl | sort | uniq -c | sort -rn

（jq はJSONを扱うコマンドラインツール。プロジェクト名を取り出す→数える→多い順に表示、の1行です）

やりとりの総数：19,731件
1位のプロジェクトだけで10,768件＝全体の54.6%
2位は23.9%、3位は7.8%

半分以上を1つのプロジェクトが食っており、探す場所が1か所に絞れました。

犯人：286KBのCLAUDE.mdが、1日74回読み込まれていた

そのプロジェクトのCLAUDE.mdは 286,104バイト ありました。運用ルールを書き足し続けた結果です。定期的に見直すよう指示も出していたのにここまで育っていた——気をつけていれば防げる話ではなく、測らないと気づけない類の肥大だったのです。

CLAUDE.mdは起動のたびに自動で読み込まれ、1回で7.2〜9.7万トークン（トークン＝AIが文章を処理する単位。使用量はこの数で数えます）を消費していました。このプロジェクトのルーチンは 1日74回。起動のたびに新しいセッションになるので、74回動けば74回読み込まれます。

7.2〜9.7万トークン × 74回 ＝ 1日 533万〜718万トークン

本来の処理を始める前に、これだけが毎日消えていました。

しかも、プロンプトキャッシュ（同じ内容の再読み込みで消費が割り引かれる仕組み）は有効時間が短く、ルーチンは1日の中で時間が離れて動きます。割引がほとんど効かず、74回のほぼ毎回フルで消費 していました。

対処①：CLAUDE.mdを分割して、1回あたりの消費を6割減らした

やったことは削除ではなく分割です。

ファイルサイズ：286,104バイト → 119,821バイト
1回あたりの消費：7.2〜9.7万トークン → 3.0〜4.0万トークン

38節の詳細を docs/ 配下の26ファイルに移し、CLAUDE.md側には「◯◯するときは docs/xxx.md を先に読む」という呼び出しを41本置きました。その作業に必要なときだけ読む 形です。

内容は1文も捨てていません。指示書を削ると挙動が変わるので、「減らす」のではなく「置き場所を変える」に徹し、分割後に全節を機械的に照合して元の記述が残っていることを確認しました。

分割先が必要な作業では読んだ分を消費しますが、関係のないルーチンにまで毎回全文を読ませるよりはるかに安くつきます。

対処②：ルーチンの棚卸しと、枠の再配分

掛け算のもう片方、実行回数も見直しました。残り件数を全ルーチンで実測すると、大物は1つ（残り76,648件）だけで、他はほぼ完了。処理対象がないのに起動だけしていたものがありました。

空振りしていた処理を、1日20回 → 6回に削減
浮いた枠で、別の2つの処理を1日6回 → 10回に増やした

後者がポイントです。節約ではなく再配分で、同じ枠のまま、サイトの更新頻度はむしろ上がりました。

残った大物は、仕組み上「1時間に1回」が起動間隔の上限なので、回数ではなく 1回あたりの処理件数を増やす 軸で対応しました。全件の完走見込みは77日から38日に縮んでいます。

結果：1日の固定消費が約62%減った

	変更前	変更後
指示書 1回あたり	7.2〜9.7万トークン	3.0〜4.0万トークン
ルーチン回数	74回/日	68回/日
1日の固定消費	533万〜718万トークン	204万〜272万トークン

約62%の削減です。契約は1つも変えていません。

測定の注意：「先週と今週の使用率」の比較は使えなかった

最初は「先週と今週の使用率を比べればいい」と考えましたが、比較になりませんでした。週によって作業が違い、対話しながらの開発作業の量が毎週変わるからです。削減の効果なのか、今週ヒマだっただけなのか区別できません。

そこで、変わっていない部分——ルーチンの固定消費——だけを切り出して計算 しました。指示書のトークン数と実行回数はどちらも実測でき、掛け算で出せます。上の表の数字はその計算値です。

まとめ

契約を増やす前に、まず測る。 何が食っているか分からないまま移行先を探すのは順番が逆でした
他社に全部移しても、単一障害点が移動するだけです。 必要なのは「移す」ではなく 「分ける」。ただし分けるには費用がかかるので、まず使い方を直してから判断します
CLAUDE.mdは「削る」のではなく 「分割して、必要なときだけ読む」 形にすれば、内容を捨てずに減らせます
浮いた枠を別の処理に回せた のが一番の収穫です。同じ契約のまま、サイトの更新頻度は上がっています

なお、他社サービスを使うかどうかは、枠の数字ではなく実際に触って決めるつもりです。

→ その後、実際に触って決めました：Claude Codeの枠を逃がすためGrokを試した。自動処理は代替できなかったが、契約はした