ローカルLLM（大規模言語モデルを手元のマシンで動かす仕組み）をCIやQAの検証環境に組み込んでいるチームに向けた内容です。Ollamaはモデルのダウンロードから推論サーバーの起動までを1コマンドでこなせるツールとして、社内検証環境や自動テストの土台に使われる場面が増えています。
Ollamaのv0.33.0-rc2では、長時間の事前処理（prefill、プロンプトを事前にモデルへ読み込ませる処理）を途中でキャンセルした際にハングする不具合が修正されました。あわせてKVキャッシュ（推論の途中結果を保存して再利用する仕組み）の整合性が壊れるケースへの対処も入っています。テスト自動化の文脈では、キャッシュ破損はテスト結果の再現性を崩す原因になるため見過ごせません。
この記事では、この修正内容を踏まえて、AIエージェントを使ったテスト自動化パイプラインでOllamaをアップグレードする際の確認手順を整理します。
前提条件
以下の環境を想定します。
- Ollamaがすでにインストール済みで、v0.32系またはそれ以前を利用している
- Claude CodeやLangChainなど、エージェント型クライアントからOllamaのAPIを呼び出す構成がある
- CI環境またはローカル検証環境で、繰り返しプロンプトを送るテストシナリオが存在する
- macOS、Linux、Windowsのいずれか（今回のリリースはこの3プラットフォーム向けビルドを含みます）
バージョン確認は次のコマンドで行えます。
ollama --version出力が0.32.x以前であれば、今回のrc（release candidate、正式版に先立って配布される検証用ビルド）の対象です。
なぜこの修正がテスト自動化に関係するか
まず前提として、prefillという処理を理解しておく必要があります。
LLMにプロンプトを渡すと、モデルは入力トークン（文章を分割した単位）を順番に読み込んで内部状態を構築します。この読み込み処理がprefillです。
長いプロンプト、たとえば数万トークンに及ぶログファイルやテストケース一覧を渡す場合、prefillに数十秒かかることがあります。
ここでエージェントクライアント側がタイムアウトなどでリクエストをキャンセルすると、以前のOllamaでは処理がハングして応答が返らなくなる不具合がありました。
さらに厄介なのは、キャンセル後に再試行した際の挙動です。修正前は「リストア地点」（処理を途中から再開するための保存ポイント）が不正確で、実際にはカバーしていない範囲までカバー済みと記録されることがありました。
具体例として、4万7000トークン中4万6000トークンまで処理が進んでいたのに、再試行時にゼロから再処理が発生するケースが報告されていました。再帰的な層構造を持つモデル（RNN系やMamba系のアーキテクチャ）で特に起きやすい問題です。
テスト自動化の観点では、この不具合は2つの意味で問題になります。1つは実行時間のばらつきです。同じテストケースでも再試行のたびに処理時間が数十秒単位で変動すると、CI/CDパイプラインのタイムアウト設定や実行時間メトリクスが不安定になります。
もう1つはキャッシュの信頼性です。KVキャッシュが壊れた状態で推論を続けると、同じ入力に対して出力が微妙に変わることがあります。回帰テスト（過去の挙動が壊れていないかを確認するテスト）でこれが起きると、テストの再現性そのものが疑わしくなります。
手順：アップグレードと検証
1. 現行バージョンのバックアップと記録
アップグレード前に、現在のバージョンとモデル一覧を記録しておきます。
ollama --version > ollama_version_before.txt
ollama list > ollama_models_before.txtロールバックが必要になった場合の判断材料になります。
2. rcビルドのインストール
公式リリースページ（GitHub Releases）からv0.33.0-rc2のインストーラーまたはバイナリを取得します。
Linuxであれば、公式スクリプトを使う方法があります。
curl -fsSL https://ollama.com/install.sh | shインストール後、再度バージョンを確認します。
ollama --version0.33.0-rc2が表示されれば適用完了です。
3. 長時間prefillを伴うテストシナリオの再実行
既存のCIジョブやテストスイートの中から、長いプロンプト（数千〜数万トークン）を扱うシナリオを選び、意図的にキャンセルを発生させて挙動を確認します。
たとえば、リクエスト送信後にクライアント側のタイムアウトを短く設定し、キャンセルが発生するようにします。
curl --max-time 5 http://localhost:11434/api/generate \
-d '{\"model\":\"llama3\",\"prompt\":\"長文プロンプト\"}'修正前のバージョンでは、この操作の後にサーバーがハングしたり、次のリクエストの処理時間が異常に伸びたりする現象が見られました。
4. 実行時間メトリクスの比較
アップグレード前後で、同じテストシナリオの実行時間を比較します。
CIのログやメトリクス収集基盤（PrometheusやDatadogなど）を使っている場合は、prefillにかかった時間とキャンセル後の再試行時間を分けて記録すると、改善効果が数値で確認できます。
動作確認の方法
アップグレードが正しく機能しているかは、次の3点で確認できます。
- キャンセルを伴うリクエストの後、サーバーがハングせず次のリクエストを正常に処理できるか
- 同じ長文プロンプトを複数回送った際の実行時間のばらつきが縮小しているか
- Claude Code連携を使っている場合、プロンプト先頭に挿入される「残りトークン数」のシステムメッセージによってKVキャッシュが壊れていた挙動が解消されているか
3点目は今回のリリースで個別に触れられている修正です。Claude Codeの「tokens left」というカウントダウン表示がプロンプトの先頭に挿入されることで、リクエストのたびにKVキャッシュが再構築されてしまう問題がありました。この機能を無効化する対応が今回のrcに含まれています。
ハマりやすいポイント
rc（release candidate）は正式リリースではない点に注意が必要です。
本番運用のCIパイプラインに直接組み込む前に、ステージング環境や検証専用のジョブで先行して動かすのが無難です。
特にモデルアーキテクチャが再帰構造を含むもの（Mamba系など）を使っている場合、今回修正されたリストア地点の不具合の影響を強く受けていた可能性があるため、優先的に確認しておくとよさそうです。
まとめ
Ollamaのv0.33.0-rc2は、長時間prefillのキャンセル時にハングする不具合と、KVキャッシュのリストア地点が不正確になる不具合を修正したリリースです。
テスト自動化やCI/CDパイプラインでOllamaを使っている場合、次の3点を確認する価値があります。
- ollama --versionで現行バージョンを確認し、v0.32系以前ならアップグレード候補として検討する
- 長文プロンプトを扱うテストシナリオでキャンセルを誘発し、ハングや再処理の有無を確認する
- Claude Code連携がある場合、トークンカウントダウン表示によるキャッシュ破損が解消されているか確認する
rcの段階でも修正内容自体は具体的で検証しやすいため、まずはステージング環境で挙動を確かめてから本番のパイプラインに反映するのが安全な進め方です。