はじめに

皆さん、ClaudeやCodexは使っているだろうか？
私はエンジニアなのだが、実務では会社契約のClaude、個人ではchatGPTを契約しているのでCodexを使っているのだが、皆さま共通として持っている課題があるかと思う。
そう、「トークンが足りない！！！」
そうなのだ、トークンが足りないのだ。
私は現在個人PCではローカルLLMを前段においてオーケストレーションとコード生成を行わせているようにハーネスを改造中なのだが、やはり足りない。
そこで、トークンを削減するルールを手の空いたときにちまちま考えていた。
結果として、トークンを大幅に削減するついでにレスポンス速度も大きく変えることに成功したのでそのノウハウの一部を共有使用と思う。

トークンを食っている一番の要因は何か

私は普段のClaudeやCodexの思考をぼんやりと眺めていて、ふと気づいたことがある。

ファイルめっちゃ読み込むなこいつ、、、

そうなのだ、大きなプロジェクトになればなるほど、大きな実装タスクをこなそうとすればするほど、ファイルの読み込み量が半端ない。
APIや関数の機能について把握しなければ既存資産とつなげることができないので当たり前のことではある。しかし、ここは確かに思考トークンを大きく消費する要因となっている。
また、セッションを新しく立てたとき、これまでの文脈を把握していないために、既存コードから今やろうとしていることを読み取ろうとする節もある。
Claudeからセッション間でメッセージを送信しあえる機能がGAとなったが、それでもやはりこれまで何をしていて、今どれだけの進捗があるのかを全てのセッション間で共有していない。
これらをコードから読み込めてしまうが、やはりこの思考に大きく時間を使ってしまうのはとてももったいない

解決策

これらの課題を解決するために利用したのがずばり「キャッシュ」と「git-likeな差分管理」の考え方である。
以下をCLAUDE.mdやAGENTS.mdとして登録することで大きくトークン消費を減らすことができる。
他にも出力ルールやSKILLS.mdを細かくタスクごとに設定することでも私はトークン消費を削減している。

# 実装方針
バックエンドでエージェントを立て、これらを実行してください。
## CONTEXT.md
[初回のみ]
.claude/records/CONTEXT.mdを作成し、セッション内での文脈などをキャッシュ的にこちらに保存してください
[デフォルト]
セッションが開始(再開)されたときまずはこちらを読むようにし、概要を把握してください。
## MILESTONE.md
[初回のみ]
.claude/records/MILESTONE.mdを作成してください。
[デフォルト]
ユーザーから実装指示を受けた時は、ユーザーのリクエストを受けての実装までのプロセスをPHASEごとに分割してこちらに記録し、進捗を管理するようにしてください。
セッション再開時にはこちらを読み込み、未実装タスクがないかどうかを管理するようにしてください。
また、すでに実装完了した大きなタスクについてはこちらクリアし、可能な限り小さな状態に保つようにしてください。
## FUNCTIONS.md
[初回のみ]
初回にフォルダを読み込むときには別エージェントを立ち上げ、
.claude/records/FUNCTIONS.mdを作成してください
|関数名|機能概要|入力|出力|定義ファイルパス|親関数|
|---|---|---|---|---|---|
|xxx|xxx|xxx|xxx|xxx|xxx|
の形の表としてこちらに記録をお願いします。
また、この表は大分類ごとに複数作って構いません。
[デフォルト]
セッション再開時、このファイルを読み込んで概要を把握してください。このファイルには必要以上に書き込まないでください。
必要以上、ユーザーの指示によって探索した結果見つかった関数は新たにこちらに記録してください。
## API.md
[初回のみ]
初回にフォルダを読み込むときには別エージェントを立ち上げ、
.claude/records/API.mdを作成してください
|API名|機能概要|入力|出力|定義ファイルパス|
|---|---|---|---|---|
|xxx|xxx|xxx|xxx|xxx|
の形の表としてこちらに記録をお願いします。
また、この表は大分類ごとに複数作って構いません。
[デフォルト]
セッション再開時、このファイルを読み込んで概要を把握してください。このファイルには必要以上に書き込まないでください。
必要以上、ユーザーの指示によって探索した結果見つかったAPIは新たにこちらに記録してください。

こちらやAPIや関数群をテーブル形式でキャッシュ的に初回に保存する。
なので初回の実行は長い。しかし、例えばこれに関連するAPIの一覧を出して、などのタスクは思考時間を1秒程度まで短縮することができる。
更新は必要になった時、探索して見つかったときに行われる。そのような機能がありそうなファイルだけ読みにいってくれるため、毎回コードを読んで機能概要を把握するステップが短縮される。

まとめ

今回、ただルールファイルにたった40行にも満たないルールを設定しただけであるが、このたった40行によってレスポンスタイムは大きく短縮されることとなった。
身近な問題もこのようなたった少しの工夫で思いもよらぬパフォーマンスで解決できるかもしれない。