コンテキストウィンドウ管理（コンテキストウィンドウカンリ）
LLMの有限なコンテキスト長を効率的に活用するための情報選択・圧縮技術。トークン上限内で最大限の関連情報を保持し、不要な情報を適切に破棄・要約する戦略を含む。
コンテキストウィンドウ管理とは、LLMが1回の推論で参照できるトークン数の上限（コンテキストウィンドウ）を効率的に活用するための技術群である。GPT-4oの128Kトークン、Claude 3.5の200Kトークン、Gemini 1.5 Proの2Mトークンなど、モデルごとに異なるウィンドウサイズの制約下で、最も重要な情報を優先的に保持する戦略が求められる。
概要
2024年以降、コンテキストウィンドウは急速に拡大したが、「長いコンテキスト＝高品質な出力」とは限らない。Googleの研究「Lost in the Middle」（2023年）は、コンテキストの中央に配置された情報の検索精度が著しく低下することを示した。2025年のAnthropicの実験では、200Kトークンのウィンドウでも、関連情報を先頭と末尾に配置した場合の精度が中央配置より最大40%高いことが報告された。
コンテキストウィンドウ管理は以下の3つの課題を解決する：
- トークン予算の最適配分: システムプロンプト・ツール定義・対話履歴・検索結果にトークンをどう配分するか
- 情報の鮮度管理: 古い対話履歴をいつ破棄・要約するか
- 位置バイアスの回避: 重要情報をウィンドウ内のどこに配置するか
主な特徴・仕組み
- スライディングウィンドウ: 直近N件のメッセージのみを保持し、古いものから順に破棄する最もシンプルな方式。LangChainのConversationBufferWindowMemory（k=10が典型）
- 要約圧縮: 古い対話履歴をLLM自身に要約させ、圧縮した形で保持する。元の10,000トークンを500トークン程度に圧縮可能
- トークンカウント管理: tiktoken（OpenAI）やAnthropic Token Counting APIで事前にトークン数を計算し、上限の80%を超えたら圧縮処理を発動
- 優先度ベース選択: 各メッセージに重要度スコアを付与し、スコアの低いものから破棄。ユーザーの明示的な指示や直近の質問に関連する情報を高優先
- チャンク分割と選択的投入: 長文ドキュメントを段落・セクション単位に分割し、質問に関連するチャンクのみをコンテキストに投入（RAGの基本戦略）
- プロンプトキャッシュ活用: Anthropic Prompt Caching（2024年）でシステムプロンプト部分をキャッシュし、トークンコストを最大90%削減
- コンテキスト蒸留: 長いコンテキストをモデルに読ませた後、重要ポイントだけを抽出した短縮版を生成し、以降の推論に使用
コンテキストウィンドウサイズ比較
| モデル | コンテキスト長 | 入力単価(/1Mトークン) | 備考 |
|---|---|---|---|
| GPT-4o | 128K | $2.50 | 2024年5月〜 |
| Claude Opus 4 | 200K | $15.00 | プロンプトキャッシュ対応 |
| Claude Sonnet 4 | 200K | $3.00 | コスパ最良 |
| Gemini 1.5 Pro | 2M | $1.25 | 最大ウィンドウ |
| Gemini 2.5 Flash | 1M | $0.15 | 高速・低コスト |
| Llama 3.1 405B | 128K | セルフホスト | OSS最大 |
具体例・対応製品
Anthropic Prompt Caching: システムプロンプトやツール定義など繰り返し送信される部分をキャッシュし、2回目以降のトークンコストを90%削減。1,024トークン以上のプレフィックスが対象。5分間のTTL。
LangChain ConversationTokenBufferMemory: トークン数ベースでバッファサイズを管理。max_token_limit=4000のように設定し、超過分は古い順に破棄。tiktokenと統合して正確なトークンカウントを実現。
LlamaIndex ContextChatEngine: RAG検索結果をコンテキストに自動挿入し、対話履歴とのトークン配分を動的に調整。検索結果の関連度スコアが低い場合は投入を省略してトークンを節約。
実装時の注意点
コンテキストウィンドウの最後の20%（末尾に近い部分）では、モデルの注意力が低下する「Lost in the Middle」現象が発生しやすい。重要な指示やシステムプロンプトはウィンドウの先頭に配置し、検索結果は関連度順に先頭寄りから配置することが推奨される。
また、コンテキスト長を最大まで使うとレイテンシが増加する。Claude 3.5 Sonnetの場合、10Kトークン入力で約1秒、100Kトークン入力で約5秒、200Kトークン入力で約12秒のTTFT（Time to First Token）が観測される。
関連用語との違い
| 用語 | 対象 | 目的 |
|---|---|---|
| コンテキストウィンドウ管理 | トークン予算の最適化 | 有限なウィンドウ内で情報価値を最大化 |
| プロンプトエンジニアリング | プロンプトの設計・最適化 | モデルの出力品質を向上 |
| RAG | 外部知識の検索・投入 | モデルの知識を拡張 |
| トークナイザ | テキストのトークン分割 | 入力をモデルが処理可能な単位に変換 |
よくある質問（FAQ）
Q1: コンテキストウィンドウは大きいほど良いのですか？ A: 必ずしもそうではない。2Mトークンのウィンドウでも、「Lost in the Middle」問題により中央の情報は検索精度が低下する。また、大きなコンテキストはレイテンシとコストが増加するため、必要最小限の情報を厳選して投入する方が費用対効果は高い。
Q2: プロンプトキャッシュはどのモデルで使えますか？ A: 2026年時点でAnthropic（Claude 3.5/4系）とGoogle（Gemini 1.5/2.5系）が公式サポート。OpenAIはAutomatic Prompt Cachingとして同等機能を提供。いずれも1,024トークン以上の共通プレフィックスが対象で、TTLは5〜60分。
Q3: トークンカウントはどう計算すればよいですか？
A: OpenAI系はtiktokenライブラリ、Anthropic系はAnthropic Token Counting API（/v1/messages/count_tokens）を使用する。日本語はBPEトークナイザで1文字あたり約1.5〜3トークンになるため、英語の約2〜3倍のトークンを消費する点に注意。
まとめ
- コンテキストウィンドウ管理はLLMアプリケーションのコスト・品質・レイテンシを左右する重要技術
- スライディングウィンドウ、要約圧縮、優先度ベース選択など複数の戦略を組み合わせる
- 重要情報はウィンドウの先頭に配置し、「Lost in the Middle」問題を回避する
- プロンプトキャッシュの活用でトークンコストを最大90%削減可能
- 日本語は英語の2〜3倍のトークンを消費するため、より積極的な圧縮が必要