トークン節約術その2／コンテキスト管理

コンテキスト管理｜会話が伸びてもコストを増やさない設計

会話履歴・検索結果・添付文書は、入力トークンの最大の肥大化要因です。すべてを記憶させる必要はありません。「何を何ターン分、どの形式で持ち越すか」を予算として決めるのが、この術の核心です。

仕組み：会話コストは「等比ではなく累積」で膨らむ

履歴を切り詰めないと、各ターンの入力は前ターンの全量＋新規発言になります。

1 ターン平均 800 トークンの会話を 10 ターン続けると、総入力は 800 × (1+2+…+10) = 44,000 トークン。20 ターンなら 168,000 トークンと、ターン数の 2 乗に近い形で膨らみます。毎ターン何も考えずに履歴を積むのが、想定外の請求の最大原因です。

44,00010ターン全履歴の累積入力（トークン）

16,000要約持ち越し方式の累積（同一会話）

−64%方式変更だけでの削減率（試算）

直近のやり取りだけを全文で保持し、それより古い部分は 1 回だけ要約して持ち越します。

持ち越しの構成例

# 各ターンで API に送るコンテキストの構成 [システムプロンプト] … 固定（術その1で精簡、術その3でキャッシュ） [過去やり取りの要約]（約300tk） … 5ターンごとに1回だけ更新 [直近3ターンの全文]（約2,400tk）… そのまま [今回のユーザー発言]

この構成では、会話が 20 ターンに伸びても各ターンの入力は約 3,000 トークン前後で頭打ちになります。全履歴方式だと 15,000 トークンを超えるターンが出るのと比べ、差は明白です。

検索拡張（RAG）では、検索件数 top-k がそのままトークンに変換されます。1 件 600 トークンの文書を top-10 で入れると 1 回の質問に 6,000 トークン。関連度のしきい値を設けて top-3〜5 に制御するだけで、RAG 系の入力は半減します。

大きい順に、効果が確実なものから入れます。

要約で失われる情報（番号・固有名詞・日付）は、要約プロンプトに「数値・日付・固有名詞は原文のまま残す」と指示して保護します。