LLM ロングコンテキストウィンドウ（エルエルエム ロングコンテキストウィンドウ）
LLM（大規模言語モデル）が一度に処理できるトークン数の上限を大幅に拡張した技術。従来の4K〜8Kトークンから128K〜10Mトークンへと飛躍的に増加し、長大な文書の要約・分析や複数文書の横断的な質問応答が可能になった。GPT-4 Turbo（128K）、Claude 3.5（200K）、Gemini 1.5 Pro（2M）などが代表例。
ロングコンテキストウィンドウとは
LLMのコンテキストウィンドウとは、モデルが一度の推論で参照できるトークン（テキストの最小単位）の総数を指す。2023年以前の主要モデルは4K〜8Kトークンが標準だったが、2024年以降は128K〜10Mトークンへと急速に拡大した。これにより、書籍1冊分（約10万字）や論文数十本分のテキストを一度に入力して処理することが実現している。
ロングコンテキスト技術の発展は、RAG（Retrieval-Augmented Generation）に頼らずとも大量の情報を直接モデルに渡せるという利点をもたらした。ただし、コンテキストが長くなるほど推論コストが増大し、情報の「迷子」問題（Lost in the Middle）も顕在化するため、用途に応じた適切な設計が求められる。
主要モデルのコンテキスト長比較
| モデル | コンテキスト長 | リリース時期 | 特徴 |
|---|---|---|---|
| GPT-4 Turbo | 128Kトークン | 2023年11月 | OpenAI初の100K超モデル |
| Claude 3.5 Sonnet | 200Kトークン | 2024年6月 | Anthropic製、長文精度が高い |
| Claude 4 Opus | 200Kトークン | 2025年5月 | 最高推論性能+長文対応 |
| Gemini 1.5 Pro | 2Mトークン | 2024年2月 | Google製、業界最大級 |
| Gemini 2.5 Pro | 1Mトークン | 2025年3月 | 実用的な1M長コンテキスト |
| Command R+ | 128Kトークン | 2024年4月 | Cohere製、RAG特化 |
| Mistral Large 2 | 128Kトークン | 2024年7月 | 欧州製オープンウェイト |
| Llama 3.1 405B | 128Kトークン | 2024年7月 | Meta製オープンソース最大 |
| Qwen2.5 72B | 128Kトークン | 2024年9月 | Alibaba製、多言語対応 |
| Yi-Lightning | 200Kトークン | 2024年11月 | 01.AI製、高コスパ |
コンテキスト長拡張の主要技術
ロングコンテキストの実現には複数の技術革新が必要となる。
- 位置エンコーディングの拡張: RoPE（Rotary Position Embedding）をベースにYaRN、ALiBi、NTK-awareスケーリングなどの手法で、学習時より長いシーケンスに対応する
- アテンション効率化: Sliding Window Attention、Ring Attention、FlashAttention-2/3などで、O(n²)のアテンション計算コストを削減する
- KVキャッシュ最適化: GQA（Grouped-Query Attention）、MQA（Multi-Query Attention）、PagedAttentionでメモリ使用量を圧縮する
- コンテキスト圧縮: LLMLingua、AutoCompressor、ICAE（In-Context Autoencoder）などで入力トークン数自体を削減する
- メモリ階層設計: MemoryBank、InfiniAttentionなどで、長期記憶と短期記憶を分離して効率的に管理する
実用上の課題と対策
Lost in the Middle 問題
2023年のStanford大学の研究により、LLMはコンテキストの先頭と末尾の情報は正確に取得できるが、中間部分の情報を見落とす傾向があることが判明した。この「Lost in the Middle」問題は、コンテキストが長くなるほど深刻化する。
対策として以下が有効とされる：
- 重要な情報をコンテキストの先頭または末尾に配置する
- チャンク分割＋再帰的要約で段階的に処理する
- Needle in a Haystack（NIAH）テストでモデルの検索精度を事前評価する
コスト問題
ロングコンテキスト利用時のAPIコストは入力トークン数に比例して増大する。
| モデル | 入力単価（1Mトークン） | 128Kフル入力時のコスト |
|---|---|---|
| GPT-4 Turbo | $10.00 | $1.28 |
| Claude 3.5 Sonnet | $3.00 | $0.38 |
| Gemini 1.5 Pro | $3.50 | $0.45 |
| Gemini 2.5 Pro | $1.25〜$10.00 | $0.16〜$1.28 |
Prompt Cachingを活用すれば、繰り返し同じコンテキストを使用する場合にコストを50〜90%削減できる。
ロングコンテキスト vs RAG
| 比較項目 | ロングコンテキスト | RAG |
|---|---|---|
| 情報の鮮度 | 入力時点の情報 | リアルタイム検索可能 |
| 精度 | 全文参照で高精度 | 検索品質に依存 |
| コスト | トークン単価×入力量 | 検索+生成の合計 |
| レイテンシ | 入力量に比例して増加 | 検索時間+生成時間 |
| スケーラビリティ | コンテキスト上限あり | 理論上無制限 |
| 実装の複雑さ | シンプル | ベクトルDB+チャンク設計が必要 |
2025年以降は「ロングコンテキスト＋RAG」のハイブリッド構成が主流となりつつある。ベースとなるドキュメントをロングコンテキストで投入し、最新データや巨大コーパスはRAGで補完する設計パターンが実用的とされる。
よくある質問（FAQ）
Q1: コンテキストウィンドウが大きいほど優れたモデルなのですか？ A: 必ずしもそうではない。コンテキスト長はモデルの能力の一側面に過ぎず、推論精度・速度・コストのバランスが重要である。2Mトークン対応のGemini 1.5 Proでも、特定タスクでは128K対応のClaude 3.5 Sonnetに精度で劣る場合がある。用途に応じた選択が必要。
Q2: ロングコンテキストを使えばRAGは不要になりますか？ A: 完全に不要にはならない。ロングコンテキストには上限があり（最大でも数百万トークン）、数百万件の文書を扱う場合はRAGが必須。また、リアルタイム更新が必要なデータ（株価、ニュースなど）もRAG向き。両者を組み合わせたハイブリッド構成が2025年の標準的アプローチとなっている。
Q3: ロングコンテキスト利用時にコストを抑えるには？ A: Prompt Caching（Claude、Geminiが対応）を活用すれば、同一プレフィックスの再利用で50〜90%のコスト削減が可能。また、LLMLinguaなどのコンテキスト圧縮ツールで不要な情報を事前に除去し、実効的なトークン数を減らす手法も有効。入力量が多い場合はバッチ処理で割引を受けられるプロバイダもある。
Q4: 日本語テキストの場合、コンテキスト長はどう変わりますか？ A: 日本語は英語に比べて1文字あたりのトークン数が多い（概ね1.5〜2倍）。128Kトークンのモデルでは英語で約10万語処理できるが、日本語では約5〜7万字が目安。トークナイザの種類（BPE、SentencePiece、tiktoken）によっても差がある。
まとめ
- ロングコンテキストウィンドウは2024〜2025年にかけて128K〜2Mトークンまで拡大した
- GPT-4 Turbo、Claude 3.5/4、Gemini 1.5/2.5 Pro が主要プレイヤー
- RoPE拡張、Sliding Window Attention、KVキャッシュ最適化が基盤技術
- Lost in the Middle問題やコスト増大が実用上の課題
- RAGとの併用（ハイブリッド構成）が2025年の標準アプローチ