コンテキストウィンドウ
コンテキストウィンドウとは、大規模言語モデル（LLM）が1回のリクエストでまとめて参照できる入力トークンと出力トークンの最大範囲のことです。これはモデルの作業記憶として機能し、この上限を超えた情報は切り捨てられるか、処理されません。
コンテキストウィンドウとは、モデルが1回の処理で扱える入力トークンと出力トークンの最大容量のことであり、プロンプト、会話履歴、添付ドキュメント、生成される回答のすべてがその中に収まる必要があります。
上限はモデルによって大きく異なり、GPT-4oは128K、標準のClaudeは200K、GPT-4.1ファミリーは1M、Gemini 1.5 Proは2Mトークンをサポートします。
ウィンドウが大きいからといって自動的に性能が向上するわけではありません。トークン数が増えるにつれて精度と再現率は低下する傾向があり、この現象はcontext rotとして知られています。
「Lost in the Middle」研究（arXiv:2307.03172）では、重要情報が入力の冒頭または末尾にあるときに性能が最も高く、中央にあると急激に低下するU字型の曲線が示されています。
コンテキストウィンドウは容量と上限の概念であり、その有限の空間に何を入れるか、そしてどのように入れるかを決めるのはcontext engineeringであり、隣接しつつも明確に焦点の異なる分野です。
コンテキストウィンドウとは
コンテキストウィンドウとは、大規模言語モデルが応答を生成する際に参照できるテキストの最大範囲のことです。システムプロンプト、ユーザーの質問、過去の会話履歴、添付された文書、そしてモデル自身が生成する回答のすべてがこの範囲に含まれます。IBMは、入力を処理し出力を生成する際に、モデルが一度に考慮できるテキスト量だと説明しています。
ここでの単位はtokenであり、単語ではありません。トークンとは、モデルがテキストを分割する際の断片です。英語ではおおむね4文字が1トークンに相当しますが、韓国語では文字や形態素レベルでもっと細かく分割される傾向があるため、同じ文でもトークン数が多くなる場合があります。コンテキストウィンドウが128Kトークンであれば、1回のリクエストに入力と出力を合わせて約128,000トークンまでしか収められないという意味です。
重要なのは、コンテキストウィンドウはモデルが学習した膨大な知識とは別の概念だということです。学習データがモデルの長期的な知識だとすれば、コンテキストウィンドウは、その時点のリクエストだけに対して機能する「ワーキングメモリ」に近いものです。Anthropicの公式ドキュメントでは、コンテキストウィンドウをモデルのワーキングメモリになぞらえ、より大きなウィンドウによって、より複雑で長いプロンプトを扱えるようになると説明しています。
主要モデルのコンテキストウィンドウ長
以下の表は、公式ドキュメントおよび発表内容を照合して確認した、代表的なモデルのコンテキストウィンドウ上限を示しています。数値はモデルのバージョンや提供環境によって変わる場合があるため、実運用では各プロバイダーの最新のモデル比較を確認してください。
モデル | プロバイダー | コンテキストウィンドウ | 注記 |
|---|---|---|---|
GPT-4o | OpenAI | 128,000 tokens | 最大出力は約16Kトークン |
GPT-4.1 / mini / nano | OpenAI | 1,000,000トークン | GPT-4o（128K）から大幅に拡張 |
Claude（標準、例：Sonnet 4.5） | Anthropic | 200,000トークン | 一部の上位モデルは1Mトークンをサポート |
Gemini 1.5 Pro | 2,000,000トークン | 発表時点で最長のコンテキスト | |
Gemini 1.5 Flash | 1,000,000トークン | 軽量・高速版 |
GPT-4.1の発表でOpenAIは、このモデルファミリーが約750,000語（約3,000ページ）を処理できると述べ、GoogleはGemini 1.5 Proの2百万トークンが約19時間の音声、または数千ページのテキストに相当すると説明しました。要するに、コンテキストウィンドウの大きさが、一度に投入できる सामग्रीの量を決定します。
ウィンドウが大きいほど常に優れているのか — 制限とエビデンス
直感的には、より大きなウィンドウのほうが優れているように思えますが、実際にはそうではありません。Anthropicは公式ドキュメントで、トークン数が増えるにつれて精度と再現率が低下することをcontext rotと呼び、含める量と同じくらい、何を含めるかが重要だと強調しています。
この制約を実証的に示した画期的な研究は、Liu et al. (2023)、Lost in the Middle: How Language Models Use Long Contexts（arXiv:2307.03172、TACL掲載）。マルチドキュメント質問応答とキー・バリュー検索タスクを用いて、この論文は、回答に必要な情報が入力の冒頭または末尾にあるときに性能が最も高く、その情報が中央に配置されると性能が急激に低下することを確認しました。情報の位置を移動させると、性能は両端で高く中央で低いU字型の曲線を描き、この傾向は長文コンテキスト対応をうたうモデルでも同様でした。
要するに、より大きなコンテキストウィンドウは含められる情報量の上限を引き上げるだけであり、その中のすべての情報をモデルが等しく有効に活用できることを保証するものではありません。実務上は、ウィンドウを無差別に埋めるよりも、重要な情報を冒頭や末尾など有利な位置に置くか、不要な情報を削るほうが効果的です。この有限のウィンドウに何をどの順序で入れるかを設計する作業は、別の概念としてコンテキスト・エンジニアリングと呼ばれます。コンテキストウィンドウが器の大きさだとすれば、コンテキスト・エンジニアリングはその器に何を、どのように入れるかを考えることです。