最終更新: 2026-06-22

コンテキストウィンドウとは

コンテキストウィンドウとは、言語モデルが1回の呼び出しで処理できるトークン数の上限であり、読み取る入力と生成する出力の両方を数えます。リクエストは、入力に応答用に確保したトークンを加えたものがこの上限内に収まるとき適合します。ウィンドウは特定のモデルにとって固定であるため、呼び出しの計画とは、その構成要素をこの上限に対して配分することを意味します。

配分

1回の呼び出しの入力は、システムプロンプト、再送される過去の会話履歴、現在のユーザーメッセージの合計です。応答用の余地を確保すると、ウィンドウが収める必要のある合計が得られます。

ここで $W$ はコンテキストウィンドウ、$n_{out}$ は確保した出力です。利用率はリクエストが消費するウィンドウの割合です。

$n_{rem}$ が負の場合、リクエストはウィンドウを超過しており、構成したままでは実行できません。

計算例

800トークンのシステムプロンプト、6000トークンの履歴、1200トークンのユーザーメッセージを持ち、応答用に2000トークンを確保するリクエストを、128,000トークンのウィンドウに対して考えます。

このリクエストは10,000トークンを必要とし、118,000トークンを残して、ウィンドウの約7.8%を使います。余地は十分にあり、ウィンドウが制約となる前に履歴は何倍にも増やせます。

超過時の挙動

合計がウィンドウを超えた場合、プロバイダーは呼び出し側が制御できる形で黙って切り詰めることはせず、呼び出しが拒否されるか最も古いコンテキストが破棄されます。いずれも結果を劣化させます。確保した出力には特に注意が必要です。入力がウィンドウをほぼ満たすと、モデルが応答する余地がほとんど残らず、応答が生成途中で打ち切られることがあります。出力を明示的に確保することで、収まる入力が切り詰められた回答を生むことを防ぎます。

活用

ウィンドウは厳格な制限であり、使用トークンに比例するコストとは別のものです。履歴は通常、最も大きく最も圧縮しやすい構成要素であるため、長い会話を収めるには一般に、それを要約または削る、システムプロンプトを短くする、確保する出力を減らす、またはより大きなウィンドウを持つモデルに移行します。単語数での目標から入力の規模を見積もるには トークンから単語数への変換 で換算してください。再送される履歴が多くのターンにわたってウィンドウと請求の双方をどのように押し上げるかについては コンテキストコストの増加の計算 を参照してください。