コンテキストウィンドウ

「コンテキストウィンドウ」とは、大規模言語モデル（LLM）が、一度の推論処理（入力されたユーザーの指示文＋過去の会話履歴＋出力されるAIの回答）において、同時に脳内に保持し、考慮に入れることができるテキストデータ量（トークン数）の物理的な上限値のことです。

モデルによって「8,000トークン」「128,000トークン」といった限界値が設定されており、このウィンドウ枠を超えた過去のテキストは、モデルの記憶から押し出されて消失（忘却）してしまいます。

コンテキストウィンドウの進化と「長文処理」の経済学

初期のLLM（GPT-3など）のコンテキストウィンドウは「2,048〜4,096トークン（日本語で数千文字程度）」と極めて狭く、長時間のチャットを行うとすぐ前の会話を忘れる問題がありました。しかし、アテンション機構の改良（FlashAttentionなど）やインフラの進化により、現在では「128k（12万8千トークン）」「1M（100万トークン）」といった超巨大なウィンドウを持つモデルが標準化しました。これにより本一冊分を丸ごとAIに入力できるようになりましたが、コンテキストが長くなればなるほど、1回のリクエストあたりのAPI料金や処理時間（レイテンシ）も乗算的に増大するため、無制限に長文を放り込むのは現実的ではありません。

「コンテキストウィンドウ」の具体的な会話例・使い方

「狭いウィンドウモデル」と「広いウィンドウモデル」の特徴比較

特徴	狭いウィンドウ (Short Context: 8k〜16k)	広いウィンドウ (Long Context: 128k〜1M+)
最大入力容量	数千文字（一般的なブログ記事程度）。	数万〜数十万文字（本1冊、大量のプログラム）。
応答速度とコスト	極めて高速、API料金も非常に安価。	長文入力時には推論に時間がかかり、API課金も高額化。

よくある疑問（FAQ）

Q：コンテキストウィンドウが「100万トークン」あれば、RAG（検索）は不要になる？

A：不要にはなりません。確かに理論上は本棚数冊分のデータをプロンプトに毎回丸ごと突っ込むことができますが、それをやると「1回のリクエストあたり数千円のAPI費用」が発生し、回答が出るまでに何十秒もかかるため、実運用が不可能です。また、先述の「Lost in the Middle（中だるみによる情報の見落とし）」リスクもあるため、費用対効果と精度を考慮すると、「RAGで必要な数十万字だけを検索し、広いコンテキストウィンドウを持つモデルに余裕を持って読ませる」というハイブリッド構成が最もスマートです。

長文インプット時におけるエンジニアリングマナー

ロングコンテキストモデルを動かす場合、余計な「ホワイトスペース」「無駄なシステム指示文」「関連性の低い過去ログ」を徹底的に削除（プロンプトのダイエット）してからインプットするのが、優れた設計マナーです。ウィンドウの余白を適切に管理することは、APIコストの削減だけでなく、モデルの「アテンション（注意の集中）」を高め、回答の精度を最大限に引き出すために不可欠な技術作法です。