初心者 11 分構成

を理解するための窓口を コンテキスト

端的な回答

コンテキストウィンドウとは、モデルが一度に処理するトークン数の上限です。システム指示、履歴、添付文書、生成中の回答をすべて合計したものが対象になります。各トークンに対応するエントリがKVキャッシュに保持されるため、メモリを消費します。Ollamaでは、VRAMが24 GiB未満のカードの場合、デフォルト値は4,096トークンです。モデルに読み込ませられる量を制限しているのは、多くの場合、モデル自体ではなく、このコンテキストウィンドウです。

コンテキストウィンドウが小さすぎると、モデルはやり取りの冒頭を忘れたり、文書が途中で切り詰められたりします。大きすぎると、VRAMを使い切り、処理全体が遅くなります。このガイドでは、コンテキストウィンドウに何が含まれるのかを説明し、実際のモデルのアーキテクチャに基づいてメモリ消費量を計算したうえで、思わぬ問題を避けながら調整する方法を紹介します。

著者 Mohamed Meguedmi·更新 2026-09-30·Windows・macOS・Linuxでテスト済み

#コンテキスト ウィンドウに含まれる内容

Ollamaのドキュメントによると、コンテキスト長とは、モデルがメモリ内で参照できるトークン数の上限です。この一つの枠に、システムメッセージ、会話履歴、貼り付けたファイルや文書の抜粋、直近の質問、そしてモデルが書いている途中の回答がすべて合算されます。推論モデルでは、思考に使うトークンも数に含まれます。合計がコンテキストウィンドウを超えると、何かを削る必要があります。通常、ツールは冒頭部分を切り詰めるか、リクエストを拒否します。モデルはこのウィンドウの外にある情報を記憶していません。ただし、外部の仕組み（要約、RAG）が情報を再び渡す場合は別です。

i
コンテキストウィンドウと記憶は同じものではありません
昨日の会話を「覚えている」アシスタントは、コンテキストウィンドウのおかげで覚えているわけではありません。アプリケーションが履歴やデータベースを読み直し、その内容をプロンプトにコピーしています。ウィンドウは、ある時点でそこに入れられる内容の上限です。

#トークン：ウィンドウを埋める単位

ローカルAIキット

お使いのマシンで、プライベートかつ無料のChatGPTを1時間で構築 — LM Studio、Ollama、Open WebUI、ご自身のドキュメント、クラウド不要。

  • 永久に利用できるオンラインスペース
  • PDF + ファイル
  • 生涯アップデート
ローカルAIキット →または すべてのキットを無期限で利用 — 49 € →

トークンは単語ではありません。モデルのトークナイザーが定義するテキストの断片で、多くの場合、音節やよく使われる単語に相当します。珍しい単語や長い単語は複数のトークンになります。同じ内容でも、フランス語は一般に英語より多くのトークンを消費します。ほとんどのトークナイザーが主に英語で訓練されているためです。正確な比率はモデルごとに異なるので、大まかな目安に頼らず、実際に測定してください。Ollama の API は、リクエストごとにプロンプトのトークン数を prompt_eval_count として返します。

プロンプトの実際のトークン数をカウント
curl http://localhost:11434/api/generate -d '{"model":"qwen3:8b","prompt":"Bonjour le monde","stream":false}'
# lisez prompt_eval_count et eval_count dans la réponse JSON
経験則
高密度のフランス語テキストのA4一枚は、トークナイザーによって異なりますが、約1,000トークンに相当します。ご自身のドキュメントでprompt_eval_countを使用して確認してください。
一冊の本
数十万トークン：分割しなければ、32,000または64,000トークンのコンテキストウィンドウには収まりません。
回答
推論モデルは、ユーザーに見える回答を出す前に数千の思考トークンを生成することがあり、これらのトークンもコンテキストウィンドウを消費します。

#どのサイズのコンテキストウィンドウを選ぶべきか

Ollama はビデオメモリに応じてデフォルト値を設定します。VRAM 24 GiB 未満では約 4 000 トークン (4k)、24 GiB から 48 GiB の間では 32k、48 GiB 以上では 256k です。同じページでは、Web 検索、エージェント、コーディングツールなど、大規模なコンテキストを必要とするタスクには少なくとも 64 000 トークンを推奨しています。最近のモデルははるかに高い最大値を謳っています。例えば、QuelLLM のカタログでは Kimi K2.5 が約 256 000 トークン、Kimi K3、DeepSeek V4 Flash、GLM 5.2 が約 100 万トークンと記載されています。しかし、謳われている最大値は、お使いのマシンで利用可能なコンテキストを意味するわけではありません。メモリ、場合によっては品質がそれを妨げます。

用途に応じたコンテキストウィンドウのサイズ
用途コンテキストウィンドウの目安注記
短い会話、質問と回答4,096から8,192トークン文書を貼り付けない場合は十分
記事の要約または分析16,000から32,000トークンテキストのトークン数を確認してください
リポジトリでのコードアシスタント64,000トークン以上Ollama がコーディングツールに推奨しています
ツールとウェブ検索を備えたエージェント64,000トークン以上各ツール呼び出しでテキストが再投入されます
非常に大きなコーパスウィンドウを表示しないでくださいすべてを送るのではなく、RAGを利用してください

サイズ設定に関する二つの落とし穴が頻繁に起こります。まず、ウィンドウ内に回答を収める必要があります。32,000トークンのうち31,000トークンをドキュメントで埋めると、回答に使える余白がほとんどなくなり、推論モデルは思考の途中で停止してしまいます。次に、会話では履歴がターンごとに増加します。最初のメッセージでは十分なウィンドウでも、20ターン目には飽和状態になる可能性があります。したがって、平均的なケースではなく、使用状況の最悪のケースを見込み、ウィンドウの約5分の1の余裕を確保してください。

#コンテキストはどれだけメモリを消費するか

コンテキストウィンドウ内の各トークンについて、モデルの各層にキーとバリューが作られ、KVキャッシュに保存されます。トークンあたりのメモリ使用量は、アーキテクチャの四つの数値から計算できます。層数、キーバリューヘッド数、ヘッドの次元数、そして一つの数値のサイズ（FP16では2バイト）です。式は、2（キーとバリュー）× 層数 × KVヘッド数 × ヘッドの次元数 × 2バイトです。注意すべきなのは、数えるのがアテンションヘッドではなく、キーバリューヘッドだという点です。最近のモデルでは、複数のアテンションヘッドがキーバリューヘッドを共有するためです（grouped-query attention）。アテンションヘッド数を使って計算すると、以下のモデルではキャッシュ容量を実際の4倍に見積もってしまいます。

Qwen3-8Bを例にとると、公式仕様では36層と8つのクエリ・キー値ヘッド（32ヘッドのクエリヘッドに対比）が記載されており、公開設定ではヘッドの次元を128と定めています。コストは2 × 36 × 8 × 128 × 2 = 147,456バイト/トークンで、144キロバイトです。

Qwen3-8BのFP16でのKVキャッシュ（モデルの設定に基づく計算）
コンテキストKVキャッシュ（FP16）KVキャッシュ（q8_0、約半分）
4 096 トークン0.56 GiB0.28 GiB
8,192トークン1.13 GiB0.56 GiB
16 384トークン2.25 GiB1.13 GiB
32 768 トークン4.50 GiB2.25 GiB
131,072トークン（YaRN使用時、モデルカードによる）18.00 GiB9.00 GiB
!
8 GB のグラフィックカードで陥りやすい落とし穴
Qwen3-8B は、Q4 量子化では重みだけで約 5 GB を使用します。コンテキストが32,768トークンの場合、KV キャッシュがさらに 4.5 GiB を使用し、計算用バッファを加える前の段階ですでに約 9.5 GB に達します。8 GB のカードでは、モデルの一部が CPU 側にオフロードされ、明確なエラーメッセージが出ないまま生成速度が大幅に低下します。ollama ps で確認してください。

2つのレバーがキャッシュを縮小します。1つ目はキャッシュの量子化です。OllamaのFAQによると、q8_0タイプはFP16のメモリ消費量の約半分を消費し、劣化は非常にわずかなのですが、q4_0は約4分の1を消費し、大きなコンテキストでは劣化がより顕著になります。これらはFlash Attentionの有効化を必要とします。2つ目は、必要な範囲にウィンドウを縮小することです。KVキャッシュに関する私たちのガイドでは、設定の詳細を説明しています。

#コンテキスト長を設定

#Ollama での設定

Ollamaでは、サーバー起動時にデフォルトの長さを設定したり、セッション用に変更したり、API経由でリクエストごとに指定したりできます。

Ollamaでコンテキストを設定する3つの方法
# Valeur par défaut pour tout le serveur
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# Pour une session interactive
>>> /set parameter num_ctx 16384

# Pour un modèle personnalisé (Modelfile)
FROM qwen3:8b
PARAMETER num_ctx 16384

ロード後、ollama ps を実行してください。CONTEXT フィールドは割り当てられた長さを、PROCESSOR フィールドはGPUとCPU間の割合を表示します。CPUに割り当てられた部分がある場合は、コンテキストの長さを減らすか、より小さなモデルに切り替えましょう。

#LM Studioの場合

LM Studioでは、モデルの読み込み時に、読み込み設定でコンテキスト長を設定します。値を変更するには、モデルを再読み込みする必要があります。確定する前に、表示される推定メモリ使用量を確認してください。

#4段階の調整手順

  1. 01
    実際に必要な量を測る
    普段使うドキュメントや会話履歴を送信し、prompt_eval_countの値を確認してください。そこに想定する回答の長さを加え、モデルが思考内容を生成する場合は、その長さも加えてください。
  2. 02
    コンテキストウィンドウを選ぶ
    この合計に20%の余裕を加えた量が収まる、最小の値を選んでください。エージェントまたはコーディングツールを使用する場合は、Ollamaの推奨どおり、少なくとも64,000トークンを確保してください。
  3. 03
    メモリを確認
    このコンテキストウィンドウの設定でモデルを読み込み、ollama psを実行してください。プロセッサ欄には「100 % GPU」と表示される必要があります。そうでない場合は、コンテキストウィンドウを小さくするか、キャッシュを量子化するか、モデルを変更してください。
  4. 04
    情報を思い出せるかテストする
    長いテキストの中ほどに具体的な事実を入れ、その内容を質問してください。モデルがその事実を見落とす場合、公表されているコンテキストウィンドウは実際に活用できる範囲を超えており、テキストの分割やRAGが必要です。

#コンテキストウィンドウが大きくても、内容を正確に読み取れるとは限りません

2023年の研究「Lost in the Middle」は、コンテキスト内の情報の位置によって、モデルの性能が大きく低下する可能性を示しています。情報が冒頭や末尾にあると性能が良いことが多く、中央にあると低下します。これは、長いコンテキストに対応するとされているモデルでも同様です。2024年に公開されたベンチマークRULERは、さらに踏み込んでいます。テストされたほぼすべてのモデルで、コンテキストが長くなると精度が大きく低下し、32,000トークンで十分な水準を維持したのは半数だけでした。いずれのモデルも32,000トークン以上への対応をうたっていたにもかかわらずです。

これらの研究は当時のモデルを対象としており、2026年のモデルについては何も述べていません。2026年のモデルの中には、長文脈に特化して学習されているものも複数あります。しかし、対応方針は依然として有効です。指示と重要な事実を先頭に配置し、最後に質問を繰り返してください。また、数十万トークンに及ぶとされるウィンドウに頼る前に、ご自身のドキュメントで測定してください。最もシンプルなテストは、ご自身の分野の長いテキストの中央に具体的な情報を挿入し、それを再度質問することです。モデルが毎回その情報を取り出せる場合は、そのウィンドウは用途に利用可能です。取り出せない場合は、送信するテキストを短縮するか、分割処理に切り替えてください。

#内容が収まりきらない場合

やり取りの進行に合わせて要約する
数回のやり取りごとに会話の要約を生成させ、その要約をコンテキストの先頭に置いて再開してください。細部は失われますが、話の流れは保てます。
ドキュメントを分割する
長いPDFはセクションごとに処理し、その後、各部分の回答をまとめます。チャンク分割のガイドでは、適切なサイズを詳しく説明しています。
RAGに切り替える
コーパスがコンテキストウィンドウを大幅に超える場合は、すべてを送る代わりに、関連する少数の箇所だけを取得します。
より大きなコンテキストを持つモデルを選ぶ
メモリが追いつく場合のみ：ウィンドウを倍にする前に、前述の KV キャッシュの計算を参照してください。
FAQ
LLMのコンテキストウィンドウとは何か？+
モデルが一度に処理できるトークンの最大数です。システムメッセージ、履歴、添付文書、質問、生成中の回答を含みます。この上限を超えると、先頭部分が切り捨てられるか、リクエストが拒否されます。コンテキストウィンドウが制限するのはモデルが読める内容であり、学習中に身につけた内容ではありません。
Ollamaのデフォルトのコンテキストウィンドウはどのくらいですか？+
VRAMによって異なります。24GiB未満では4kトークン、24〜48GiBでは32kトークン、48GiBを超える場合は256kトークンです。Ollamaは、エージェント、ウェブ検索、コーディングツール向けに少なくとも64,000トークンを推奨しています。OLLAMA_CONTEXT_LENGTHまたはnum_ctxで変更できます。
ローカルモデルのコンテキストをどうやって拡張できますか？+
サーバー起動時にOLLAMA_CONTEXT_LENGTHを設定するか、対話セッションで/set parameter num_ctxを使うか、ModelfileでPARAMETER num_ctxを指定してください。その後、ollama psでモデル全体がGPU上に収まっていることを確認してください。コンテキストを長くするとメモリ消費が増え、モデルの一部がCPU側にオフロードされる場合があります。
32,000トークンのコンテキストは、どれくらいの VRAM を消費しますか？+
アーキテクチャにより異なります。Qwen3-8B の場合、FP16 での KV キャッシュは 32,768 テキストトークンで約 4.5 GiB に達し、それ以外の重みを加えます。式は以下の通りです：2 × レイヤー数 × KV ヘッド数 × ヘッド次元 × 2 バイト/トークンです。キャッシュの量子化 q8_0 により、このコストはほぼ半分になります。
より大きなコンテキストがモデルをより賢くするのですか？+
いいえ。読めるテキストの量は増えますが、推論能力が向上するわけではありません。むしろ、「Lost in the Middle」とRULERの研究は、コンテキストが長くなると精度が低下する可能性があることを示しています。できるだけ大きなウィンドウではなく、タスクに必要な大きさのウィンドウを選んでください。
ドキュメントの分析にはRAGか大きなコンテキストウィンドウが必要ですか？+
ドキュメントがコンテキストウィンドウに余裕を持って収まり、メモリも足りるなら、全文を送る方が簡単です。それを超える場合や、多数のファイルを含むデータベースに対して質問する場合は、必要な箇所だけを送るRAGの方がリソースを節約でき、多くの場合、信頼性も高くなります。

#さらに詳しく

このガイドは役に立ちましたか？

ご意見、誤りのご指摘、補足はありますか？ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。