重要なポイント
- Llama 4 Scout (MoE)は最大10Mトークンをサポート。DeepSeek V4-FlashとQwen 3.6はそれぞれ1Mと256Kトークンをサポート（YaRNで1Mまで拡張可能）。2026年5月は百万トークン対応オープンモデル第一世代が登場。
- モデルサイズ別の実用的なコンテキスト：7B-8Bモデルは16K-32Kトークンで高品質を維持。70B+とMoEモデルはこれを256K-1Mトークンまで拡張。
- RAMはコンテキスト長とモデルサイズ両方に比例して増加。Qwen 3.6 27B（Q4_K_M）は128Kで~22 GB、1Mで~65+ GB必要。
- "中間迷子"問題は依然として存在：LLMはコンテキスト中間の詳細を見落とす。対策：重要情報をプロンプト冒頭に置き、検索にはRAGを使用するか、重複チャンクで処理する。
- 長いコンテキストは完全なドキュメント（コードベース、契約書、書籍）の総合分析に優れる。RAGは多数のドキュメントにわたる検索タスクに優れる。
- Ollamaのデフォルトは2048トークン。完全なコンテキストにはModelfileでnum_ctxを明示的に設定する。
コンテキスト長とは何か、なぜローカルLLMにとって重要なのか？
コンテキスト長は、モデルが1回の推論呼び出しで処理できる最大トークン数です。入力（ドキュメント、会話履歴、システムプロンプト）と出力（モデルの応答）の合計サイズです。 1トークン ≈ 0.75英単語；128Kトークン ≈ 96,000語。
ローカルLLMのユースケースでは、長いコンテキストにより：本全体の要約、コードベース全体を1つのプロンプトで分析、数時間の会議文字起こし処理、以前のコンテキストを失わずに長い会話履歴を維持することが可能になります。
重要な区別は、広告されたコンテキスト長（アーキテクチャがサポートするもの）と実用的なコンテキスト長（品質が維持される範囲）の差です。技術的に128Kをサポートするモデルでも、100Kトークン付近では品質が低下する場合があります。
2026年に128KトークンのコンテキストをサポートするローカルLLMは？
| モデル | コンテキストウィンドウ | 実用的な上限 | Ollamaコマンド |
|---|---|---|---|
| Llama 3.1 8B | 128K | ~32K 信頼性あり | ollama run llama3.2 |
| Llama 3.2 3B | 128K | ~16K 信頼性あり | ollama run llama3.2:3b |
| Llama 3.3 70B | 128K | ~64K 信頼性あり | ollama run llama3.3:70b |
| Qwen2.5 7B | 128K | ~32K 信頼性あり | ollama run qwen2.5:7b |
| Qwen2.5 72B | 128K | ~64K 信頼性あり | ollama run qwen2.5:72b |
| Mistral Small 3.1 24B | 128K | ~32K 信頼性あり | ollama run mistral-small3.1 |
| Gemma 2 2B | 8K | ~6K 信頼性あり | ollama run gemma2:2b |
| Mistral 7B v0.3 | 32K | ~16K 信頼性あり | ollama run llama3.2 |
長いコンテキストの処理にはどれくらいのRAMが必要か？
RAMの使用量はモデルサイズとコンテキスト長の両方に比例して増加します。 KVキャッシュはすべての処理済みトークンのAttention状態を格納し、コンテキスト長に線形に増加します。
Q4_K_Mの7Bモデルで4Kコンテキストは~6 GB RAMを使用。同じモデルで32Kコンテキストは~8-9 GB。128Kコンテキストでは~12-16 GB。
| モデル | 4Kコンテキスト | 32Kコンテキスト | 128Kコンテキスト |
|---|---|---|---|
| Llama 3.1 8B Q4_K_M | ~6 GB | ~9 GB | ~14 GB |
| Qwen2.5 14B Q4_K_M | ~9 GB | ~12 GB | ~18 GB |
| Mistral Small 3.1 24B Q4_K_M | ~14 GB | ~17 GB | ~24 GB |
| Llama 3.3 70B Q4_K_M | ~40 GB | ~45 GB | ~55 GB |
なぜ実用的なコンテキストは宣伝されている最大値より短いのか？
RoPE位置エンコーディング（Llama、Qwen、Mistralが使用）で訓練されたLLMは技術的には最大コンテキスト長までトークンを処理できますが、"中間迷子"効果として知られるパターンで品質が低下します。
LLMはコンテキストウィンドウの最初と最後の情報を最もよく活用します。中間に置かれた情報は信頼性が低くなります。128Kモデルは最初の32Kと最後の16Kトークンに対して信頼性高く回答できますが、40K-80K範囲の詳細は見落とす可能性があります。
実用的な信頼性の上限はモデルサイズに比例：3Bモデル ≈ 8K-16K；7B-8Bモデル ≈ 16K-32K；70Bモデル ≈ 64K信頼性あり。
長いコンテキストウィンドウはより多くの入力を可能にしますが、効果的な利用にはプロンプト構造が重要です。RAG、プロンプトチェーニングについてはプロンプトエンジニアリングガイドを参照してください。
Ollamaでコンテキスト長を設定するには？
Ollamaは設定されていない限り、デフォルトで2048トークンのコンテキストを使用します。完全なコンテキストウィンドウを使用するには：
モデルが以前の入力を忘れる理由と軽減策についてはコンテキストウィンドウ解説を参照してください。
# Set context length at runtime
ollama run llama3.2 --ctx 32768
# Or create a custom model with a Modelfile
cat << EOF > Modelfile
FROM llama3.1:8b
PARAMETER num_ctx 32768
EOF
ollama create llama3.1-32k -f Modelfile
ollama run llama3.1-32k
長コンテキストローカルLLM：地域別コンテキスト
EU / GDPRとAI法： EU AI法（2025年2月施行）は個人データを大規模に処理するAIシステムを潜在的に高リスクとして分類します。法的文書分析、医療記録要約、人事文書処理のためのローカル長コンテキスト推論はこのリスク層に位置します。ローカル実行はGDPR第28条に基づくサードパーティリスクを排除します。
ドイツBSIコンプライアンス：Q4_K_Mの7Bモデルと32Kコンテキスト（標準ワークステーションで~9-10 GB）が推奨構成です。Llama 3.1 8BとMistral Small 3.1がEUコンプライアンスに推奨されます。
フランスCNILガイドライン：外部API呼び出しなしのOllama経由のローカル推論は、個人データがサードパーティAIプロバイダーによって処理されないという要件を満たします。
日本（METI）： 日本語文書はトークナイザーの違いにより、同等の英語文書より1.5-2倍多くのトークンを必要とします。50ページの日本語レポートは25K-35Kトークンを消費する可能性があります。Ollamaで明示的なコンテキスト設定（PARAMETER num_ctx 32768）が必要です。Qwen2.5のネイティブ日本語トークナイザーはLlamaより30-40%効率的で、日本の法務・金融文書にはQwen2.5 14B（Q4_K_M、32Kコンテキスト）が最高の品質/RAM比を提供します。
中国： 中国のデータセキュリティ法（数据安全法）の下、クラウドAPIを通じたセンシティブ文書処理には追加のコンプライアンスが必要です。Qwen2.5（Alibaba）経由のローカル推論はすべての文書内容をオンプレミスに保持します。Qwen2.5のネイティブ中国語トークナイザーは中国語文書に30-40%トークン効率が高いです。
長コンテキストローカルLLMでよくある間違い
- 128Kコンテキストが4Kと同様に機能すると思い込む： "中間迷子"効果により、30K-80K前の情報は先頭や末尾の情報よりも信頼性低く取得されます。重要な文書分析では、長い文書を16K-32Kセクションに分割して処理してください。
- Ollamaのデフォルトコンテキストサイズを増やさない： Ollamaはデフォルトで2048トークンを使用します。常にnum_ctxを明示的に設定してください：ModelfileにPARAMETER num_ctx 32768を追加するか、実行時に--ctxを使用してください。
- 不十分なRAMで長いコンテキストを実行する： 合計8 GB RAMで128Kコンテキストの7Bモデルは深刻なスワップを引き起こします。モデル重み（~4.5 GB）と128K KVキャッシュ（~8+ GB）が8 GBを超えます。
- TTFTが長いコンテキストでスケールすることを忘れる： 32Kコンテキストでは、初回トークンまでの時間（TTFT）がコンシューマーハードウェアで5-15秒になる場合があります。
- RAGとコンテキストを混同する： RAGは多数のドキュメントにわたる検索に優れています。長いコンテキストは完全で一貫した文書（契約書、コードベース）の分析に優れています。
よくある質問
ローカルLLMで本全体を要約できますか？
典型的な300ページの本は90,000-120,000語、約120K-160Kトークンです。これはほとんどの7Bモデルの実用的な信頼性コンテキストを超えています。7Bモデルでは：本を20K語の章に分割し、各章を要約してから章の要約をまとめてください。
32Kトークンに何ページのテキストが入りますか？
標準的な英語テキスト（1ページ250語）で約50-70ページです。32Kトークンには短編小説、付録付きの完全な研究論文、または完全な技術仕様書が入ります。
コンテキスト長を増やすと推論が遅くなりますか？
はい。同じハードウェアで32Kコンテキストの処理は4Kより約3-4倍時間がかかります（アテンション計算の二次スケーリングのため）。生成速度は大きく影響しませんが、初回トークンまでの時間は入力長に比例します。
どのローカルLLMが長いコンテキストよりRAGを上手く処理しますか？
ドキュメントの検索と取得タスクでは、RAGの方が効果的な場合が多いです。RAGは3-5個の関連チャンク（合計4K-8Kトークン）を取得し、"中間迷子"問題を回避します。
KVキャッシュとは何か、なぜコンテキスト長とともに増加するのか？
KVキャッシュはコンテキストウィンドウで処理されたすべてのトークンのAttention状態を格納します。32Kコンテキストは4Kより8倍多くのKVキャッシュメモリが必要です。モデルの重みは変わらず、KVキャッシュのみが増加します。
ローカルモデルはGemini 3.1 Proのような1Mトークンのコンテキストを処理できますか？
いいえ -- 2026年4月現在、1Mトークンコンテキストをサポートするローカル実行可能なモデルはありません。Gemini 3.1 ProにはGoogleのTPUインフラが必要です。ローカルでは128Kがコンシューマーハードウェアの最大値です。
"中間迷子"問題とは何か、どう回避するか？
LLMはコンテキストの最初と最後の情報を確実に取得しますが、中間の詳細を見落とします。128Kコンテキストでは40K-80Kトークン付近が最も無視されやすいです。重要情報はプロンプトの先頭に配置し、RAGを使うか、重複する16K-32Kセクションで処理してください。
Ollamaが使用しているコンテキスト長を確認するには？
`ollama show <モデル>` を実行してください -- 出力にnum_ctxが表示されます。2048と表示された場合、Ollamaはデフォルトを使用しています。永続的に変更するには：PARAMETER num_ctx 32768のModelfileを作成し、`ollama create <名前> -f Modelfile` を実行。`ollama ps` でアクティブなセッションを確認してください。
ドキュメントQ&Aには長いコンテキストとRAGのどちらが優れていますか？
RAGは通常、ドキュメントQ&AにおいてRAMも効率的で効果的です。RAGは3-5個の関連チャンク（合計4K-8Kトークン）を取得し、"中間迷子"問題を回避します。長いコンテキストはドキュメント全体の構造を理解する必要がある場合や、セクション間の関係が重要な場合に優れています。
出典
- Lost in the Middle: How Language Models Use Long Contexts -- Liu et al., 2023
- Ollama Context Length Configuration -- Ollamaドキュメント
- Llama 3.1 Technical Report -- Meta AI, 2024
- EU AI Act Official Text -- 欧州議会、2024年