LLMのコンテキスト使用量を減らす方法

LLMで『使いすぎた』と感じる場面には、少なくとも三つあります。契約やアカウントの利用上限、APIで使ったトークンに応じた料金、一つの会話や処理で扱えるコンテキストの上限です。関係はありますが、同じものではありません。

コンテキストには、会話だけでなく、添付した資料、読ませたコード、検索やコマンドの出力、カスタム指示、メモリ、スキル、道具の定義などが入る場合があります。何が含まれるかは製品によって異なりますが、不要な情報を減らすことは、一回ごとの処理量を抑え、必要な情報を見つけやすくする助けになります。

最初から設定ファイルや自動化を作り込む必要はありません。現在の状態を確認する、関係のない仕事を別の会話へ分ける、長い仕事の状態を要約して残す、の三つから始められます。名称や操作は製品ごとに違います。

/context   # 現在のコンテキスト内訳を見る
/usage     # 利用状況を見る
/rename 認証エラー調査
/clear     # 別の目的へ移る
/compact 変更ファイル、判断理由、未解決点、テスト結果を残す

Claude Codeでは/contextで内訳、/usageで利用状況を確認できます。別の仕事へ移るなら/clear、同じ仕事を続けながら履歴を短くするなら/compactを使えます。感覚だけで削らず、まず何が大きいのかを確認します。

Codexでは、一つのチャットを一つのまとまった仕事に使うことが公式の推奨です。長くなった同じ仕事は/compactで要約でき、別方向へ枝分かれする仕事は新しいタスクや/forkへ分けられます。一般的な対話型LLMでも、別件になったら新しい会話を作る、という考え方は同じです。

自動圧縮へすべてを任せるのではなく、次の作業に必要な情報を指定します。コンテキスト圧縮は入力を短くできますが、細部が落ちる可能性があります。消えて困る決定や調査結果は会話だけに置かず、ファイルへ残します。

文章作成、資料の調査、実装、レビュー、テスト作成、原因調査は、同じ題材を扱っていても必要な情報と完了条件が違います。一つの長い会話で全部を続けるより、まとまった目的ごとに分けた方が、LLMが読み直す情報と過去の失敗を減らせます。

ただし、会話を分けるたびに同じ調査を最初から繰り返せば節約になりません。長い調査を終えたら、分かったことを小さな引き継ぎファイルへ保存し、新しい会話ではそのファイルと必要なコードだけを読ませます。

ここまでの作業を handoff.md に整理してください。
残すもの: 目的、確認済みの事実、変更ファイル、未解決点、次に行うこと、テスト結果。
会話の経緯や試しただけで不採用になった案は、次の判断に必要なものだけ残してください。

これは情報を捨てるというより、常に読み続ける会話から、必要なときに読める外部の記録へ移す方法です。AI EngineerのRecursive Coding AgentsとYour Agents Need a Save Buttonの発表も、巨大な入力や途中状態を会話の外へ置き、必要な部分を取り戻す考え方を示しています。

カスタム指示には、どの作業でも必要な規約と重要な禁止事項だけを残します。Claude CodeではCLAUDE.md、CodexではAGENTS.mdがこれに当たります。AnthropicはCLAUDE.mdを200行未満にすることを目安として示し、OpenAIも短く正確なAGENTS.mdを勧めています。長いほど従いやすくなるわけではなく、重要な規則も埋もれます。

• 毎回必要な規約と、特定の作業だけで使う手順を分ける
• 特定のディレクトリだけで必要な規則は、対象パスに限定する
• レビューやリリースなど複数手順の仕事は、必要時に読むAgent Skillへ移す
• 長い説明は常時読み込まず、必要になったときに参照する資料やSkillへ移す
• 使っていないMCPサーバーや連携ツールは無効にできないか確認する

Agent Skillは、仕事の手順や参照資料を必要なときに読み込むために使えます。Claude CodeとCodexのどちらにも同じ考え方があります。数を増やすことではなく、毎回必要な情報と必要時だけ読む情報を分けることが目的です。

長い資料や大きなリポジトリを扱うとき、最初から『全部読んで』と頼む必要はありません。知りたいこと、対象範囲、入口になりそうな章やファイル、今は不要な範囲を伝え、まず関係する場所を特定してから深く読ませます。

目的: 注文確定時に二重送信される原因を特定する。
対象: src/orders と関連するテスト。
最初に行うこと: 呼び出し経路と再現条件を調べ、根拠となるファイルと行を示す。
まだ行わないこと: 修正、全ディレクトリの読み込み、関係のないリファクタリング。
次へ進む前に、追加で読む必要がある範囲を説明する。

ログやテスト出力も同じです。一万行をそのまま会話へ入れるより、失敗、エラー、その前後、集計結果へ絞ります。型付き言語ではコードインテリジェンスを使い、文字列検索と候補ファイルの読み歩きを、定義や参照への移動へ置き換えられる場合があります。

サブエージェントへ調査を任せると、大量のファイルやログは別のコンテキストで処理され、主会話には要約だけを戻せます。実装へ使う会話を、調査途中の情報で埋めないためには有効です。

一方で、別のモデル呼び出しが増えるため、合計トークンが減るとは限りません。Claude CodeでもCodexでも、複数のエージェントはそれぞれモデルと道具を使います。並列化は時間を短くし、主会話を整理する方法にはなっても、自動的な使用量削減ではありません。

• 調査対象と質問を一つに限定する
• 成果物を、根拠となるファイル、結論、不明点の短い報告にする
• 同じコードを複数の担当へ重複して読ませない
• 終了した担当や、進展していない並列処理を動かし続けない
• 実装した会話とは別の新しい会話でレビューし、先入観を分ける

簡単な調査や定型作業まで常に最も重いモデルと高い思考量で行う必要はありません。モデルや思考量を選べる製品では、仕事の難しさに合わせて調整できます。ただし、小さなモデルが同じ検索や修正を繰り返し、最後まで完了できなければ、単価が低くても総使用量は増えます。

比較するときは、一回の入力トークンだけでなく、完了率、再試行、総入力・総出力、経過時間、人による修正、テストや型検査を通過したかを記録します。モデルや実行方法を変えるときも、同じ課題と品質ゲートで比べます。

• 製品に内訳や利用状況の表示があれば、作業の開始時と長くなったときに確認する
• 目的が変わったら新しい会話やタスクへ分ける
• 長い仕事では、圧縮前に残す内容を指定し、重要な状態をhandoff.mdなどへ書き出す
• カスタム指示から、資料やコードを見れば分かる説明と特定作業だけの長い手順を外す
• 使っていないMCPサーバーを止め、巨大なログやテスト出力を失敗部分へ絞る
• サブエージェントは大きな調査など、主会話から分離する価値がある仕事だけに使う
• 一週間後に、使用量だけでなく、完了した仕事、再試行、待ち時間、品質も比較する

全部を一度に設定する必要はありません。まず目的ごとに会話を分け、長い仕事の状態を要約して残します。次に、毎回読み込む設定と大きな出力を見直します。そこで減らなければ、並列実行、モデル、思考量、仕事の分け方を測ります。Claude Codeなら/context、/clear、目的付き/compactから始められます。Codexでも長い同一タスクは/compact、枝分かれは/forkを使えます。