LLM入力のサイズ上限と要約
🧑 User
2026-10-25T06:09:11.763537Z
LLMのAPIにプロンプトクエリを渡すとき、インプットのコンテキストサイズ上限がわかっている場合に、プログラム側でその上限より少し小さなサイズになるようにクエリのサイズを検査し、一定サイズ以上なら、安全なサイズに要約したクエリに変更する実装を考えています。モデルのドキュメントで与えられているインプットコンテキストサイズ上限の何％に達したときに要約を起動し、何％程度のサイズに要約するのが適切あるいは典型的ですか？
🤖 Claude
2026-10-25T06:09:26.489854Z
結論から言うと、「これが標準」という業界合意の数値はありません。ただ、実務で多く使われている目安はあります。
典型的な目安
| 項目 | 一般的な値 | 備考 |
|---|---|---|
| 要約の起動閾値 | 上限の約70〜85% | 迷うなら75〜80%から始める |
| 要約後の目標サイズ | 上限の約30〜50% | 次の閾値まで数ターン分の余裕を残す |
| 最終的なハード上限 | 上限の約90〜95% | 超えたら要約ではなく切り詰め等で強制的に収める |
起動閾値と目標サイズの差(上の例なら30〜50ポイント)は、要約の頻度を決める「バッファ」です。差が小さいと、要約した直後にまた閾値に達して要約が連発します。
閾値を上限ぎりぎりにできない理由
- 出力トークンの分が必要です。 多くのAPIでは、入力と出力の合計がコンテキストウィンドウに収まる必要があります。max_tokensの分は入力から差し引いて考えます。
- トークン数の見積もり誤差があります。 自前のトークナイザがモデルの実際のものと違うと、数%〜10%以上ずれることがあります。特に日本語はずれやすいです。
- 隠れたオーバーヘッドがあります。 システムプロンプト、ツール定義、メッセージのフォーマット用トークンなどが加算されます。
- 要約処理自体にも入力が必要です。 要約をLLMに依頼するなら、要約対象と要約指示が収まる余地が要ります。閾値が高すぎると、要約すら実行できなくなります。
設計のポイント
割合より絶対値で考える: 上限が200Kなら80%は160Kですが、1M級のモデルだと80%は800Kになります。そこまで溜めると、コスト、レイテンシ、長文での精度低下が先に問題になります。長コンテキストのモデルでは、割合ではなく「実用上の上限」(例: 100〜200Kトークン)を別に決めるのが現実的です。
計測はAPIが返す値を優先: 直前のレスポンスの usage.input_tokens を基準にし、そこに次の入力の見積もりを足して判定すると、誤差を抑えられます。事前計測には、各社のトークンカウントAPI(Anthropicなら count_tokens エンドポイント)も使えます。
全部を要約しない: 次の構成が一般的です。
- システムプロンプトと直近N往復(または直近の一定トークン分)はそのまま残す
- 古い部分だけを要約する
- 要約は1回で完結させず、既存の要約に追記する形(ローリングサマリー)にすると、情報の劣化が累積しにくい
要約で失いやすい情報を明示する: 要約プロンプトで、ユーザーの制約・決定事項・未解決タスク・識別子(ID、ファイル名、数値)を必ず残すよう指示します。
要約以外の手段も併用する: 要約の前に、ツール実行結果の古い出力を削除またはスタブ化するだけで足りる場合もあります。要約より安価で、情報の歪みもありません。
出発点としての設定例
上限 = モデルのコンテキスト上限 - 出力予約(max_tokens) - 安全マージン(5%程度)
起動閾値 = 上限 × 0.75〜0.80
要約後の目標 = 上限 × 0.40 (システムプロンプト・直近履歴を含めた合計)
ハード上限 = 上限 × 0.95 (超過時は古い履歴から強制削除)
そのうえで、実際の会話ログで要約頻度・要約後の回答品質・コストを測り、調整するのがおすすめです。RAGや長文ドキュメント入力が中心のシステムだと、会話履歴中心のシステムより、要約後の目標を低め(30%前後)にしたほうが安定することが多いです。
なお、上記の数値は特定のドキュメントに基づく規定値ではなく、実装上の経験則です。使うモデルやフレームワーク(LangChainのSummaryBufferMemory等)ごとに既定値は異なるので、採用するものの仕様も確認してください。