Claude CodeとCodexを毎日使うMacで、LLMトークンの無駄を減らす7つの工夫

Claude CodeやCodexを毎日使っていると、モデルの賢さ以上に「何を毎回読み込ませているか」が効いてきます。私のMacでは、トークンを我慢して使うのではなく、同じ説明を何度も送らない、必要な知識だけ読む、軽い仕事はローカルへ逃がすという設計で無駄を減らしています。

最初に正直に書くと、私は安いモデルを常用しているわけではありません。2026年7月31日時点では、Claude CodeもCodexもかなり強いモデルと高い推論設定を既定にしています。

それでも節約を意識しているのは、モデルの能力を落とすより、能力と関係のないトークン消費を削る方が、品質を維持しやすいからです。

この記事では、現在このMacに入っている設定とログを実際に確認しながら、うまく動いているものだけでなく、まだ改善途中の部分も含めて紹介します。

「トークン節約」を3種類に分ける

ひとくちにトークン節約と言っても、実際には次の3つが混ざっています。

私はこの3つを別々に観測しています。

PRACTICE 011指示ごとの消費量を自動記録する

節約の最初の一歩は、プロンプトを短くすることではなく、何に使っているかを測ることでした。

Claude Codeでは、応答が終わるたびに動くStopフックから、直前の1指示に使ったトークンをJSONLへ記録しています。

記録している主な項目は次の通りです。

• 入力トークンと出力トークン
• 5分・1時間のキャッシュ書込とキャッシュ読込
• モデルとツール呼び出し数
• 個人用・仕事用プロファイル
• API料金に換算した場合の参考コスト

フック自体は、次のような1行を各プロファイルの設定に入れています。

bash ~/.claude/hooks/record-token-usage.sh 2>/dev/null || true

|| trueを付けているのは、計測の失敗で本来の作業を止めないためです。記録処理は便利ですが、主役ではありません。

ただし、失敗を完全に見えなくするとログの欠損に気づけません。最終成功時刻や失敗件数は別に残し、計測が動き続けているかを確認できるようにするのが安全です。私の計測も、ここは次の改善対象です。

ログは月ごとのファイルへ追記し、CLIレポートと、サーバー不要の単体HTMLダッシュボードから同じ集計ロジックで見られるようにしています。

導入後の7月分は、まだ52指示だけの部分データです。それでも、記録上の総トークンの97%以上がキャッシュ読込でした。これは「8億トークン以上を毎回新規に送っている」という意味ではありません。むしろ、入力・出力・キャッシュを分けて見ないと、数字だけでは判断できないことが分かりました。

今は「高コストだった指示」を後から確認し、巨大ファイルを読ませたのか、ツール出力が長すぎたのか、同じ調査を繰り返したのかを見直しています。

PRACTICE 02コンテキスト残量を常に表示する

Claude Codeのステータスラインには、モデル名、現在のコンテキスト使用率、残りトークン、消費速度、残量が尽きるまでの推定時間、圧縮回数を常時表示しています。

🤖 Model | 📊 使用量/上限 34% | 💡残り132k | ⏳推定時間 | 🔄圧縮1回
🔥 Burn rate | Daily | Weekly | Monthly

色分けの目安も決めています。

• 40%未満: 通常運転
• 40〜70%: 大きな調査を追加する前に整理
• 70〜85%: /compactを検討
• 85%超: 作業状態をファイルへ保存してセッションを分ける

重要なのは、限界まで一つの会話を使い切らないことです。

長い会話は、それまでの経緯を保てる一方で、現在のタスクに不要な試行錯誤まで抱え続けます。残り10%で無理に実装を続けるより、決定事項と次の作業を短いファイルへ落とし、新しいセッションで再開した方が安定します。

PRACTICE 03常時読む情報と、必要なときだけ読む情報を分ける

私の環境には、Claude Code用だけでも260個以上のスキルがあります。これを全部、毎回のシステムプロンプトへ入れたら、それだけで大きな負担になります。

たとえば、React Nativeの実装規約はReact Nativeの作業時だけ、記事の書き方は記事作成時だけロードします。

Codex側では、長尾のスキルを通常の一覧から外し、必要になったときに検索して読むdeferred-skillsという仕組みも使っています。名前と概要だけで候補を探し、該当するSKILL.mdを1つだけ全文ロードする設計です。

Claude CodeではTool Searchも有効にし、MCPツールを最初から全部使う前提にしない構成にしています。さらに、スキルとMCPの利用回数もフックで記録し、使っていないものを後から外せるようにしています。

「遅延ロードの仕組みを入れたから完成」ではなく、常時ロード領域は定期的に棚卸しする必要があるというのが現在地です。

PRACTICE 04巨大なファイルを丸ごと読ませない

日々の操作では、いきなりファイル全体をLLMへ渡さないようにしています。

1. rgでファイル名や該当行を絞る
2. 必要な前後だけ読む
3. 大きなログは件数や集計値を先に見る
4. 詳細が必要な箇所だけ追加で読む

たとえば、数MBのログからエラー原因を探すとき、ログ全文を会話へ貼る必要はありません。

rg -n "error|failed|timeout" app.log | tail -100
rg -c "address already in use" app.log

同じ考え方で、PDFは分割し、Gitの変更は対象ファイルを限定し、ツールの出力上限も小さめにします。

巨大なツール出力は、その1回だけでなく、以後のターンにも会話履歴として残ります。1回の読みすぎが、その後の全ターンに効いてくるため、最も再現性の高い節約方法だと感じています。

PRACTICE 05会話ではなく、短い状態ファイルで引き継ぐ

長い作業を別セッションへ移すときは、会話をそのまま貼り直しません。

.claude-work/session-state.mdのようなファイルに、現在のタスク、完了したこと、次にやること、重要な判断と理由、変更したファイル、テスト結果、未解決の問題だけを残します。

この形なら、新しいセッションは数百〜数千トークンで作業を再開できます。過去の会話数万トークンをもう一度読ませる必要はありません。

サブエージェント間の受け渡しも、できるだけファイル経由にしています。それぞれを独立したコンテキストで動かし、成果物だけを次の工程へ渡します。

PRACTICE 06Claude CodeとCodexの間も、最大24KBの要約で渡す

Claude CodeからCodexへ作業を移すためのローカルなhandoffも作っています。

設計上は、直近の会話、最後の回答、未完了タスク、Gitの状態、ブランチ、HEADを集め、最大24KBのMarkdownへ圧縮します。保存前にAPIキーやアクセストークンらしい文字列を伏せ、7日より古い情報や別リポジトリの情報は読みません。

Codex側は、リポジトリで最初のタスクを始めるときだけhandoffを探します。毎ターン同じ引き継ぎを読み直さないためです。

このブランチでこの機能を作っています。ここまで変更して、テストはここまで通っています。次はこのファイルを直してください。

この説明をツールをまたぐたびに繰り返さないことが狙いです。

ただし、今回の確認では、handoffを保存するフックがdotfiles側にはあるものの、現在使っているプロファイル設定へ反映されていませんでした。実際、この原稿作成セッションの開始時にも引き継ぎは見つかりませんでした。

つまり現状は、Codex側の読込は動くが、Claude Code側の保存が設定ドリフトで半稼働です。

PRACTICE 07軽い仕事はローカルLLMへ振り分ける

このMacでは、Ollama上のqwen3-coder:30bをOpenCodeから使えるようにしています。qqというラッパーコマンドで、OpenCode、Ollamaサービス、対象モデル、設定リンクの状態をまとめて確認できます。

今回の確認では、この4項目はすべて通りました。MCP用シークレットのキャッシュだけは未ロードでしたが、ローカルでコードを読む・要約する段階では不要なので、必要時だけ読み込む設計です。

ローカルLLMでは、スキルの自動読込も既定で無効にしています。

export OPENCODE_DISABLE_CLAUDE_CODE=1

必要なときだけQQ_ENABLE_SKILLS=1で戻します。小さなローカルモデルほど、巨大なシステムプロンプトの影響を受けやすいからです。

別のレート制限時フェイルオーバーでは、Claude Codeの軽量モードを使い、初期入力を約200KBから約4KBへ、約50分の1に減らせた記録もあります。その代わり、使える道具はRead、Edit、Bashの3つに絞られます。

ローカルへ任せやすいのは、Git差分の要約、コミットメッセージのたたき台、ログの分類、定型的なファイル検索、長文の一次要約、候補が0件かどうかの巡回確認です。

一方、複雑な設計判断、大規模な実装、外部サービスへの書込みは、強いクラウドモデルへ残します。

ローカルLLMは外部APIのトークンを消費しませんが、計算時間、電力、メモリは使います。また、モデルが弱いためにやり直しが増えれば、時間の節約にはなりません。無料だから全部ローカル、ではなく、やり直しの少ない仕事だけ渡すのが今の線引きです。

強いモデルを使いながら節約する

私の現在の設定は、Claude CodeもCodexも強いモデル・高い推論設定が既定です。それでもトークン節約の仕組みを増やしています。

理由は、難しい実装でモデル能力を下げ、何度も修正させる方が高くつくことがあるからです。

私が減らしたいのは「考えるためのトークン」ではありません。減らしたいのは、今回使わないスキルやMCPツールの説明、すでに終わった試行錯誤、同じプロジェクト説明の繰り返し、丸ごと貼られた巨大ログ、長すぎる途中経過と実況です。

難しい仕事には強いモデルを使い、入力は狭く、出力は必要十分にする。この組み合わせが、現時点では最も安定しています。

今から始めるなら、この順番がおすすめ

1. コンテキスト残量を見えるようにする

まず、今どのくらい使っているかを常時表示します。数字が見えるだけで、巨大ファイルを雑に読ませる回数が減ります。

2. 常時読込と必要時読込を分ける

グローバル指示には原則だけを残し、技術別・業務別の長い手順はスキルへ移します。

3. セッション状態をファイルへ保存する

タスク、判断、変更ファイル、テスト結果のテンプレートを1つ作るだけでも、会話の引き継ぎはかなり軽くなります。

4. 1指示ごとの利用量を記録する

最初から豪華なダッシュボードは不要です。JSONLへ入力、出力、キャッシュ、モデルを追記できれば十分です。

5. ローカルLLMは最後に足す

ローカルLLMの運用には、モデル管理、メモリ、起動方法、品質の見極めが必要です。先にクラウド側の無駄を減らした方が、少ない労力で効果が出ます。

まとめ

このMacでやっているトークン節約は、プロンプトを極端に短くするテクニックではありません。

1. 1指示ごとの入力・出力・キャッシュを記録する
2. コンテキスト残量と消費速度を常時表示する
3. スキルとツールを必要なときだけ読む
4. 巨大ファイルやログを先に絞り込む
5. 会話ではなく状態ファイルで引き継ぐ
6. Claude CodeとCodexの間も短い要約で渡す
7. 軽い仕事だけローカルLLMへ逃がす

そして、今回あらためて分かった最大の改善点は、節約の仕組み自体も放置すると太ることです。58KBまで育ったグローバル指示、増えたMCP、反映漏れしたhandoffフック。これらは次の棚卸し対象です。

トークンを節約する一番の方法は、弱いモデルに我慢させることではなく、強いモデルへ、今必要な情報だけを渡すことだと考えています。