ローカル LLM は、入力の大半を黙って捨てていた

手元の Mac で動かす LLM（ローカル LLM）に、コードの下書きや長いファイルの要約を任せていました。ある日、渡したファイルのごく一部しか読まれていないことに気づきました。エラーは一度も出ていませんでした。

何が起きていたか

使っていたのは Ollama です。Ollama は、モデルが一度に扱える長さ（コンテキスト長）を、指定しなければ既定の 4,096 トークンで動かします。モデルの仕様書に「256K まで扱える」と書いてあっても、指定しない限り、その長さは使われません。

あふれた分は、警告なしで捨てられます。Ollama の内部で動く推論サーバが、先頭のわずかなトークンだけを残し、古い側から捨てて処理を続ける設定（--context-shift）で起動しているためです。

約4万トークンある CSS ファイルを要約させたときの記録では、モデルが実際に読んでいたのは 2,050 トークン、全体の約5%でした。要約は、それらしい文章で返ってきていました。大きいファイルほど、読まれない割合が増えます。要約させたい場面ほど、要約になっていない、ということです。

出力の側でも壊れる

あふれるのは入力だけではありません。生成している最中にコンテキストがいっぱいになると、古い側、つまり最初に渡した指示文から捨てられます。指示を失ったモデルは、どこで止まればいいか分からなくなります。

実際に、コード生成用のモデルが、同じ断片を38分間出し続けました。しかも、同じ指示で別の回には正常に終わります。テストで一度うまくいっても、安心できません。

対処

コンテキスト長を、毎回明示して渡します。ollama run のコマンドには、コンテキスト長を指定する手段がありません。HTTP の API（/api/generate）経由で呼び、num_ctx を指定します。

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3-coder:30b",
  "prompt": "...",
  "stream": false,
  "options": { "num_ctx": 32768, "num_predict": 4096 }
}'

• num_ctx：扱う長さ。必要な長さを毎回指定する。
• num_predict：出力の上限。止まらなくなったときの安全弁です。上限で打ち切られたら、そのことを呼び出し側で警告するようにしておきます。黙って短い答えを返させないためです。

サーバ側の既定値を環境変数（OLLAMA_CONTEXT_LENGTH）で上げる方法もあります。ただ、全モデル共通になるうえ、アプリの更新で黙って戻る余地が残るので、自社ではリクエストごとの指定にしました。

代償もあります。長いコンテキストで動かすと、速度は約3割落ちました。それまで測っていた速度は、4,096 トークンしか見ていない状態での数字だった、ということです。

そもそも、大きなファイルを丸ごと渡すのをやめるのが一番確実です。探したい語が分かっているなら、grep などで該当箇所だけ抜き出してから渡せば、切り捨ては起きません。

日本語に、簡体字が混ざる

もうひとつ、日本語の文章を書かせるときの癖があります。Qwen 系のモデルは、日本語の中に中国語の簡体字を混ぜます。「地下鉄」を「地铁」と書きました。コード生成用のモデルでは、試した2回とも混ざりました。

見た目が漢字なので、校正で読み流してしまいます。ローカル LLM に日本語を書かせるなら、字種のチェックを前提にする必要があります。Shift_JIS（cp932）に変換できない文字を拾うだけでも、多くは見つかります。

共通すること

どちらも、モデルは何事もなかったように、それらしい答えを返します。切り捨ては設定の既定値の問題で、簡体字はモデルの癖の問題です。原因は別ですが、「答えが返ってきた」ことが、何の保証にもならない点は同じです。

自社では、ローカル LLM に任せる仕事を、①入力が小さい、②間違っても実害がない、③答えが毎回同じである必要がない、の3つがそろうものだけに絞っています。

2026年8月時点の Ollama と、qwen3-coder:30b・Qwen 系のモデルで確認した内容です。既定値は版によって変わることがあります。

技術コラムの一覧へ