Long Context LLM（ロングコンテキストエルエルエム）
100,000トークン以上の長いコンテキストウィンドウを持つLLM。書籍全体・コードベース・長大な文書を一度のプロンプトで処理できる。Gemini 1.5 Pro（100万トークン）などが代表例。
Long Context LLM とは
Long Context LLM（長文コンテキストLLM）とは、100,000トークン（約75,000語）以上のテキストを一度の推論で処理できる大規模言語モデルを指す。トークンとは概ねひらがな1〜2文字、英語1〜0.75単語に相当し、100万トークンは英語の書籍4〜5冊分に相当する。
コンテキストウィンドウの進化史
| 年 | モデル | コンテキスト長 | 書籍換算 |
|---|---|---|---|
| 2020 | GPT-3 | 4,096トークン | 約3ページ |
| 2022 | GPT-3.5-turbo | 4,096トークン | 約3ページ |
| 2023/3 | GPT-4 | 32,768トークン | 約25ページ |
| 2023/5 | Claude 1 | 100,000トークン | 約75ページ |
| 2023/11 | GPT-4 Turbo | 128,000トークン | 約96ページ |
| 2024/2 | Gemini 1.5 Pro | 1,000,000トークン | 約750ページ |
| 2024/11 | Gemini 1.5 Pro | 2,000,000トークン | 約1,500ページ |
| 2025/3 | Gemini 2.5 Pro | 1,000,000トークン | 約750ページ |
| 2025/2 | Claude 3.7 Sonnet | 200,000トークン | 約150ページ |
| 2025 | Claude 4 Opus | 200,000トークン+ | 約150ページ |
長文対応を実現する主要技術
1. RoPE（Rotary Position Embedding）スケーリング
標準的なTransformerの位置エンコーディングを学習時の最大長を超えて拡張する技術。YaRN（Yet another RoPE extensioN）やDynamic NTK Scalingなどの派生手法が存在する。
2. Sliding Window Attention
Mistral 7Bが採用。全トークン同士の注意計算（O(n²)）の代わりに、局所的なウィンドウ内のみで注意を計算し計算量を削減する。
3. Ring Attention / Sequence Parallelism
Googleが開発。超長シーケンスを複数GPUに分散して処理するアーキテクチャ。Gemini 1.5の100万トークンはこの技術が鍵。
4. FlashAttention 3
IO-Awareなアテンション計算で、メモリ効率を大幅改善。v1→v3で最大5倍高速化、長文処理の実用コストを大幅削減。
RAGとの比較・使い分け
Long Context LLMは「何でもコンテキストに入れてしまう」アプローチ。一方RAGは「必要な情報だけを検索して渡す」アプローチ。
| 観点 | Long Context | RAG |
|---|---|---|
| セットアップ | 単純（入れるだけ） | インデックス構築が必要 |
| 精度（全文参照） | 高い | 検索漏れのリスク |
| コスト | トークン量に比例 | 検索コスト + 少ないトークン |
| リアルタイム更新 | 毎回入れ直し | インデックス更新のみ |
| 適切な用途 | 〜200Kトークンの精密分析 | 数百万文書の広範検索 |
2024年以降は「Long Context + RAG」のハイブリッドが実用化されており、検索で候補を絞り込んだ後に長文コンテキストで精緻に解析するパターンが増えている。
実用ユースケース
1. コードベース全体の一括解析
大規模なコードリポジトリ（50,000行程度）をそのままClaudeに渡し、アーキテクチャ上の問題点や改善点を分析させる。
2. 法律・契約書の全文チェック
500ページ超の契約書を丸ごと入力し、不利な条項・矛盾する記述を検出させる。弁護士の事前スクリーニングコストを大幅削減。
3. 学術論文の包括的レビュー
100本以上の論文PDFをまとめて処理し、研究動向の整理や引用関係の分析に活用。
4. 多言語書籍の丸ごと翻訳・要約
英語書籍500ページをGeminiに入力し、章ごとの要約と重要概念の整理を一括実行。
5. 長時間会議の文字起こし解析
8時間の会議録音を文字起こしして全文入力し、決定事項・アクションアイテム・議論の流れを抽出。
「Lost in the Middle」問題
長文コンテキストには情報が中間部分に来ると精度が下がるという問題（「Lost in the Middle」、2023年スタンフォード発表）が存在する。
コンテキスト位置と精度の関係（概念図）:
精度高 ━━━━━━━━━━━━━━━━━
文書先頭 文書末尾
精度低 （中間部）
Gemini 1.5以降は「Needle in a Haystack」ベンチマーク（大量文書中の特定情報検索）で100%近い精度を達成し、この問題を大幅に改善している。
コストと実用上の注意点
100万トークン入力はAPIコストが非常に高い点に注意が必要。
| モデル | 入力価格（/1Mトークン） | 100万トークン処理コスト |
|---|---|---|
| Gemini 1.5 Flash | $0.075 | 約11円 |
| Gemini 1.5 Pro | $1.25 | 約190円 |
| Claude 3.5 Haiku | $0.80 | 約120円 |
| Claude 3.7 Sonnet | $3.00 | 約450円 |
| Claude 4 Opus | $15.00 | 約2,250円 |
1ドル=150円換算。書籍1冊の解析なら低コストだが、毎日大量文書を処理するシステムでは月次コストが急増する点に注意。
よくある質問（FAQ）
Q: 200,000トークン全てを「理解」できているのか？ A: 「理解」の定義次第。特定の情報を検索・引用する能力は高いが、200,000トークン全体の複雑な関係性を人間的に「理解」しているかは研究中。Lost in the Middle問題は最新モデルでも完全には解消されていない。
Q: ローカルLLMで長文コンテキストを使えるのか？ A: Qwen3-30B-A3Bが最大32,768トークン、Llama 3.1が128Kトークンに対応。ただしコンテキストが長くなるほどVRAM消費が激増し、32GB以上のGPUが必要になる場合が多い。
Q: RAGは不要になるのか？ A: 長文コンテキストで代替できるユースケースは増えているが、数百万件のドキュメントを検索するケースではRAGが引き続き必要。両者は競合でなく補完関係。
Q: プロンプトキャッシュは長文コンテキストのコスト削減に有効か？ A: 非常に有効。AnthropicのPrompt Cachingを使うと、同じ長文コンテキストを複数回使うコストが最大90%削減される。継続的な文書解析ワークフローでは必須の最適化。