コンテキスト長とは？ローカルAIで長文・PDFが重くなる理由を初心者向けに解説

Prompt Processingと途中停止からcontextを見直す

contextの設定値を大きくすれば常に解決するわけではありません。LM StudioのPrompt Processingが遅い時は入力長・履歴・system promptを、途中停止ではRAM/VRAMと生成条件を分けます。Ollamaではollama psのCONTEXTと公式Context length Docsを合わせて確認します。

• LM StudioのPrompt Processingが遅い - 最初の返答までの入力処理を確認する
• 速度・RAM・VRAMを測る方法 - 生成中の速度を条件付きで測る
• LM Studioの回答が途中で止まる - LM Studio利用時の停止を確認する
• Ollamaの回答が途中で止まる - Ollama利用時の停止を確認する
• OllamaでGPUが使われない - CPU/GPU分割とPROCESSORを確認する

agent workloadをチャット負荷と分ける

ファイル検索、tool call、長いcontext、KV cache、embedding、checkpoint、並列処理が加わると、短い一問一答よりPC負荷が増えやすくなります。モデルサイズだけでなく、処理の回数とデータの往復を見ます。

• ローカルAIエージェントのPC負荷 - RAM、VRAM、CPU、GPU、SSD別の切り分けを見る

公式最大contextとT4で実用になるcontextは別

Qwen3.6-27Bの公式native contextが262,144でも、T4 16GBで同じ長さを確保できるとは限りません。contextを増やすとKV cacheと処理負荷が増えるため、Colabでは4096などから始め、空きVRAMを見て段階的に上げます。

• Colab T4でcontext OOMを直す - 短文は動くが長文で落ちる症状を切り分ける

コンテキスト長を固定して速度を比べる

同じモデルでもコンテキスト長が違えば、必要メモリ、TTFT、長文時の安定性が変わる可能性があります。LM StudioとOllamaを比べるときは、設定値と実際の入力長を同時に記録します。

• コンテキストを含めた実測方法 - TTFTと生成速度を分けて記録する

長いPDFを丸ごと入れる方法とRAGは別物

コンテキスト長を伸ばして長文を入れる方法と、RAGで必要そうな断片を検索して入れる方法は違います。どちらも便利ですが、メモリ、速度、検索漏れ、原文照合の負担を分けて考えます。

• チャンク分割と検索漏れ - 長文PDFとRAGの違いを読む

30秒結論：長くすれば賢くなるわけではない

PDFチャットでは、全文を毎回詰め込むより、質問に関連する断片を検索して渡す方が現実的です。重い時は、モデルサイズを下げ、履歴を短くし、検索で渡す文書量を見直します。

コンテキスト長とは

コンテキスト長は、AIが一度に見られる範囲のようなものです。質問文、会話履歴、貼り付けた資料、システム指示、回答に必要な余白などが、この範囲の中に入ります。

大きいコンテキスト長に対応したモデルでも、手元のPCで同じように快適とは限りません。長くするほど計算量やメモリ/VRAM使用量が増えやすく、回答開始までの待ち時間も伸びることがあります。

トークンとは

トークンは、AIが文章を処理するときの単位です。日本語の文字数と完全に同じではありませんが、初心者は「AIが読むために文章を細かく分けた単位」と考えると十分です。

長い文章を貼る、会話履歴を残す、PDFの本文をたくさん入れると、トークン数が増えます。トークン数が増えるほど、モデルが読む量だけでなく、計算やメモリ使用も増えます。

入力内容別の重さ比較

会話履歴が長くなると重くなる理由

チャットを続けると、過去の会話も文脈として残る場合があります。履歴が長いほど、AIが参照する文章量が増え、コンテキストを圧迫します。

長く話しているうちに遅くなった、前の内容と混ざる、回答がぼやける場合は、新しいチャットに分ける、不要な履歴を削る、要点だけ再入力する、といった整理が有効です。

PDFや長文が重くなる理由

PDFを丸ごとAIに読ませることと、PDFから必要部分を検索して答えることは違います。PDF全文をそのまま渡すと、トークン数とメモリ負荷が増えやすくなります。

文書チャットでは、PDFを分割し、検索して、関係しそうな部分だけAIに渡すRAGの考え方が使われることがあります。長文を扱いたい人は、コンテキスト長とRAGをセットで理解すると失敗原因を切り分けやすくなります。

コンテキスト長・モデルサイズ・メモリの違い表

メモリ・VRAM・CPU/GPUとの関係

8GBメモリでは、長文やPDF活用はかなり慎重に見る必要があります。16GBなら短い文章や小さな文書から試し、32GB以上なら少し選択肢が広がりますが、GPUなしでは速度面に期待しすぎないほうが安全です。

GPUやVRAMがある場合でも、コンテキスト長を上げすぎると負荷が増えます。モデルサイズ、量子化、コンテキスト長を同時に上げると、どれが原因で重いのか分かりにくくなります。

コンテキスト長を上げれば解決するわけではない

コンテキスト長を最大にすれば長文問題が解決する、とは考えないでください。長い入力を全部渡しても、回答が遅い、要点がぼやける、根拠が不明になる、メモリ不足になることがあります。

長文では、必要な部分だけ渡す、文書を分割する、先に要約する、RAGで検索する、という設計も重要です。

LM Studioで見るべきポイント

LM Studioでは、モデル読み込み時の設定、コンテキスト長、GPUオフロード、VRAM使用量、回答速度をセットで見ます。画面名や設定名はバージョンで変わる可能性があるため、公式ドキュメントや現在のUIを確認してください。

• GPUオフロードとは - 長文でCPU/GPU/VRAM負荷が増える理由を見る
• ローカルAIのモデルサイズ早見表 - PCメモリ別に無理の少ないモデルを選ぶ

AnythingLLMでPDFを使うときの考え方

AnythingLLMのような文書活用ツールでは、PDF全文を毎回そのままAIへ渡すとは限りません。文書を分割し、検索し、必要そうな部分をAIへ渡すRAGの仕組みが関係します。

• RAG・埋め込み・ベクトルDBの仕組み - PDFチャットの裏側を理解する
• AnythingLLMでPDFを読むには - PDF活用の入口と注意点を見る
• AnythingLLMでPDFを読ませても期待通りに答えない理由 - 回答がずれるときの原因を確認する

要約と全文読解は違う

短い要約は、文章の一部を読んで要点をまとめる用途です。全文読解や複数PDFの質問応答は、検索、根拠確認、文書分割、モデル性能が絡むため、難易度が上がります。

初心者はまず短い記事や数段落の要約から始め、次に短いPDF、最後に複数文書へ広げる順番がおすすめです。

初心者がやりがちな失敗

• コンテキスト長を最大にすれば良いと思い込む
• PDFを入れればAIが全部覚えると思う
• モデルサイズとコンテキスト長を同じものだと思う
• 長い履歴を残したまま何度も質問して重くする
• 8GBやGPUなしPCで長文PDFを最初から試す

次に読む記事

• RAG・埋め込み・ベクトルDBの仕組み - PDF全文と検索型文書チャットの違いを理解する
• PDF・文書チャットの使い分け - LM Studio、AnythingLLM、RAGの違いを見る
• 埋め込みモデルとは - 意味検索に使うモデルの役割を理解する
• ローカルAIをAPIで使う方法 - 長文をアプリやスクリプトから扱う前に読む
• Q4/Q5/Q8の違い - 軽さと品質、メモリ負荷の関係を見る
• GPUなしPCでローカルAIは使えるか - 長文に進む前の現実ラインを確認する

2026年8月の公式docsで「設定できるcontext」と「使えるcontext」を分ける

context lengthには、モデルが持つ最大値、runtimeがロード時に確保する値、現在の入力に含まれるsystem prompt・会話履歴・資料・検索結果・出力の余白があります。同じ「context」という言葉でも別の値なので、設定画面の数字だけで快適さや長文対応を保証しないでください。

モデルの最大contextを超える設定、入力が収まらない全文添付、検索結果を詰め込みすぎたRAGは、回答が速くなるとは限りません。まず実際のロード値と入力内容を固定し、短い文書から比較します。

• Ollama Context length - context設定、VRAM別の既定値、OLLAMA_CONTEXT_LENGTH、ollama psを見る
• Ollama API /api/ps - ロード中のcontext_lengthとVRAM使用量をAPIで確認する
• LM Studio Get Context Length - モデルの最大contextと入力が収まるかを確認する
• LM Studio Per-model Defaults - モデルごとのcontext sizeとロード既定値を見る
• LM Studio lms load - context length、GPU offload、estimate-onlyをCLIで確認する
• AnythingLLM Using Documents - 全文添付、context超過、embed/RAG、Max Context Snippetsを見る
• Open WebUI Knowledge - Focused RetrievalとFull Context、全文投入の制限を見る

contextを比較するための5段階チェック

1. モデル1つ、runtime1つ、同じ質問、同じ出力長に固定し、モデルの最大contextとロード設定を確認する。
2. 短いcontextと短い文章から始め、回答開始までの時間、生成速度、RAM/VRAM使用量、停止の有無を記録する。
3. 設定を変えた後は、Ollamaなら`ollama ps`、LM Studioならロード設定やestimate結果など、実際に適用された値を確認する。
4. PDFや複数文書では、全文投入、Focused Retrieval、RAGのどれを使っているかを確認し、検索されたchunkと回答の根拠を分けて見る。
5. contextを上げて遅さ、CPUへのoffload、メモリ不足、回答のぼやけが出たら、短いcontext・少ない文書・短い履歴へ戻して1条件ずつ切り分ける。

「最大値で固定してから比較する」と、モデル変更、量子化、GPU offload、parallel request、RAGの取得量が混ざりやすくなります。自分のPCでの実用値は、同じ条件で測った記録として扱い、別のPCへそのまま当てはめないでください。

• ローカルAIエージェントのPC負荷 - KV cache、tool loop、並列処理をcontextと分けて見る
• PDF・文書チャットの使い分け - 全文投入とRAGの使い分けを確認する
• RAG・埋め込み・ベクトルDB - 検索結果がcontextへ入るまでの層を見る