MENU
「このサイトでは広告を利用しています」 | AI技術ラボ - 現場目線の本音レビュー
  1. ホーム
  2. ツール選定・技術検証
  3. 【実践検証】Claude Code × Ollama Part2｜72GBモデルで実際に開発してみた結果

【実践検証】Claude Code × Ollama Part2｜72GBモデルで実際に開発してみた結果

広告
ツール選定・技術検証

前回の記事では、Ollama × Claude Codeの環境構築方法を解説しました。

👉 前回: Ollama × Claude Code：API費用ゼロでAIコーディング環境を構築する完全ガイド

「環境は構築できた。で、実際どこまで使えるの？」

ネット上の検証記事のほとんどは、MacBook環境で「実用的ではない」と結論づけています。
しかし、それはGPUパワーが足りていなかっただけかもしれません。

今回はRTX 8000×2（VRAM 96GB） という企業向けGPU環境に、80Bパラメータの大規模モデル（実行時VRAM占有量 約72GB） を載せて検証しました。
MacBookの検証記事とは、根本的にスケールが違います。

この記事は以下のような方に向けて書いています：

  • 前回の記事で環境を構築済みで、次のステップを知りたい方
  • ローカルLLMでどこまで実用的な作業ができるか気になる方
  • Ollamaのコンテキストエラーに悩んでいる方

この記事を読むことで、ローカルLLMの実力と限界、そして安定運用のための具体的な設定方法が分かります。

この記事のポイント

  • 80Bパラメータモデル（VRAM約72GB）で議事録システムのプロンプト改善を実装できた
  • コンテキストエラーが発生 — AutoCompact OFFとKVキャッシュ圧迫が有力な要因（継続検証中）
  • Ollamaコンテキストサイズの4つの設定方法を完全解説
  • 当面の対策は128k（131,072トークン）への調整
目次

今回の検証で使ったモデルと環境

前回の記事で構築した環境をベースに、より大きなモデルで検証しました。

項目前回（構築編）今回（検証編）
モデルqwen3-coder / gpt-ossqwen3-coder-next（80B / VRAM約72GB）
コンテキストデフォルト（4,096）262,144トークン（モデル設定値※）
Claude Code環境構築のみ実タスクに投入

前回の記事では推奨モデルとして紹介したqwen3-coderよりも、大幅にスケールアップしたモデルです。

モデル: Qwen3-Coder-Next（80Bパラメータ / MoEアーキテクチャ、3B活性化）
VRAM占有量: 約72GB（96GB中の約75%）
コンテキスト: 262,144トークン（モデル設定値※）
GPU使用率: 100% GPU動作

※コンテキストサイズについて補足
Ollamaのシステムデフォルトは4,096トークンです。ただし、qwen3-coder-nextモデルはModelfileで262,144トークンがデフォルト値として定義されています。今回は特に設定を変更せず、ollama psで確認したところ262,144トークンと表示されました。他のモデルを使う場合はシステムデフォルトの4,096トークンが適用されるため、コンテキストサイズは必ずモデルごとに確認してください。

検証内容 — 議事録システムのプロンプト改善

社内の議事録作成システムのプロンプトを、Claude Code経由でローカルLLMに改善させました。

社内で運用しているPython製の議事録作成システムの改善が今回のタスクです。

やりたかったこと

  1. Gitリポジトリのクローンとコード解析
  2. 画像解析スクリプトのプロンプト改善
  3. 要約スクリプトのプロンプト改善

いずれも「Claude Code経由でローカルLLMにコードを読ませ、改善を提案・実装させる」という流れです。

実際にできたこと

以下の作業は問題なく完了しました。

1. Gitリポジトリの操作

# リポジトリのクローン → ✅ 正常動作
# ブランチ確認 → ✅ 正常動作
# ファイル読み込み → ✅ 正常動作

2. 画像解析スクリプトの改善

改善前は汎用的な画像説明プロンプトでした。
ローカルLLMがコードを分析し、議事録用のキャプション生成に特化したプロンプトを提案・実装しました。

  • system roleの追加
  • 出力を議事録向けに最適化

3. 要約スクリプトの改善

改善前は一般的な要約プロンプトでした。
以下の改善を自律的に提案・実装しました。

  • 一般的な要約 → 会議議事録作成専門家プロンプトに変更
  • 出力形式の明確化（要約・議論要点・決定事項・ネクストアクション）
  • 専門用語保持の指示を追加

つまり、コードの読み込み → 分析 → 改善提案 → 実装まで、ローカルLLMだけで完結しました。

発生した問題 — コンテキストエラーの壁

順調に見えた作業ですが、途中でコンテキストエラーが発生しセッションが強制終了しました。

何が起きたか

3つ目のタスク（要約スクリプトの改善）が完了した直後、追加の作業を依頼したタイミングで、エラーが発生しました。

  • コンテキスト上限に到達：262,144トークン（モデル設定値）の上限
  • セッションの強制終了：エラー後に作業継続ができない状態

ファイルの読み込み、コード分析、改善提案、実装と、複数のステップを積み重ねた結果、コンテキストが上限に達しました。

なぜ262kもあるのに足りなくなるのか

正直に言うと、1回の検証だけでは原因を完全に特定できていません。
ただし、現時点で考えられる要因は3つあります。

要因1：AutoCompactをOFFにしていた

今回の検証では、Claude CodeのAutoCompact機能を無効（False） にしていました。

AutoCompactとは、コンテキストが大きくなったときに古い会話内容を自動で圧縮して空きを作る機能です。
これを無効にしていたため、ファイルの読み込み結果やコード分析の全文が圧縮されずにそのまま蓄積されていました。

通常であればAutoCompactが途中で会話を圧縮し、コンテキストの消費ペースを抑えてくれます。
今回のエラーは、これが最大の原因だった可能性があります。

要因2：Claude Codeのワーキングメモリが大きい

Claude Codeはファイル操作のたびに、コンテキストにコードの内容を積み上げます。
数ファイルを読み込んで分析するだけで、数万トークンを消費します。
AutoCompactがONであれば自動圧縮されますが、OFFの場合はすべてが生データのまま残ります。

要因3：KVキャッシュがVRAMを圧迫する（推測）

LLMの推論時には、モデル本体に加えてKVキャッシュがVRAMを消費します。

消費要因サイズ説明
モデル本体約48-52GBQwen3-coder-next（80B、量子化済みウェイト）
KVキャッシュ+バッファ可変（数GB〜40GB）コンテキスト使用量に比例して増大
合計（実測）約72GB〜90GB以上コンテキスト消費に応じて変動

コンテキストが大きくなるほどKVキャッシュも増大するはずです。
今回は1回のセッションで発生した現象のため、「毎回同じ条件で再現するのか」「タスクの種類や量によって変わるのか」はまだ分かっていません。

さらに問題なのは、VRAM不足時のCPUオフロードです。

VRAMに載り切らない分はCPU側のRAMにオフロードされます。
この状態では推論速度が10倍以上低下し、実質的に使えません。

ollama ps で確認すると、PROCESSORが 50% GPU / 50% CPU のような表示になります。
これが出たら、VRAMが足りていないサインです。

解決策 — Ollamaコンテキストサイズ設定ガイド

現時点の対策：コンテキストサイズをモデル設定値の262kから128k（131,072）に調整することで、VRAMの余裕を確保できます。

ただし、これが根本解決かどうかは継続検証が必要です。
まずは設定方法を押さえておきましょう。

Ollamaには4つのコンテキストサイズ設定方法があります。
用途に応じて使い分けてください。

方法1 — CLI実行中に一時変更（テスト向き）

Ollamaの対話モード中に入力します。

/set parameter num_ctx 131072

現在のセッションのみ有効です。
再起動するとデフォルト値に戻ります。

最適値を探すテスト時に便利です。

方法2 — 環境変数でデフォルト変更（全モデル共通）

Mac / Linux：

# 一時的に
OLLAMA_CONTEXT_LENGTH=131072 ollama serve

# 永続化（.bashrc等に追記）
export OLLAMA_CONTEXT_LENGTH=131072

Windows：

# システム環境変数に追加
[System.Environment]::SetEnvironmentVariable("OLLAMA_CONTEXT_LENGTH", "131072", "Machine")

前回の記事でOLLAMA_HOST等を設定した方は、同じ場所に追加するだけです。
ただし全モデルに適用されるため、小さいモデルにも128kが強制されます。

方法3 — Modelfileで固定設定（本番運用に推奨）

特定モデルだけにカスタム設定を適用する方法です。

FROM qwen3-coder-next:latest
PARAMETER num_ctx 131072

カスタムモデルとして登録します。

ollama create my-qwen3-131k -f custom-model.mf

以降は my-qwen3-131k で呼び出すだけです。
モデルごとに最適値を固定でき、最も安定した運用ができます。

方法4 — API経由で指定（プログラム連携向き）

{
  "model": "qwen3-coder-next:latest",
  "prompt": "コードをレビューしてください",
  "options": {
    "num_ctx": 131072
  }
}

Claude Codeからの接続時や、自作ツールからの呼び出しに使用します。
リクエストごとにコンテキストサイズを変更でき、最も柔軟です。

どの方法を選ぶべきか

方法推奨シーン持続性
1. CLIテスト・一時的な変更セッション限り
2. 環境変数全モデル共通で変えたい場合永続
3. Modelfile本番運用（最推奨）永続
4. APIプログラムからの動的制御リクエスト単位

迷ったら方法3（Modelfile）を選んでください。

VRAM消費の目安 — コンテキストサイズ別

コンテキストサイズとVRAM消費は比例関係です。
以下の表で、自環境に合った設定を選べます。

コンテキストサイズ推定VRAM増加分合計VRAM目安安定性
4,096（Ollamaシステムデフォルト）ごくわずか約52GB◎ 非常に安定
32,768約2-3GB約55GB◎ 安定
131,072（推奨）約10-15GB約65-70GB○ 安定
262,144（モデル設定値）約20-35GB約72-90GB△ 限界付近

注意：上記の数値はqwen3-coder-next環境での推定値です。KVキャッシュのVRAM消費はモデルアーキテクチャや量子化レベルにより変動します。ollama psで実測値を確認してください。

VRAM容量の80%以内に収まるのが安定運用の目安です。

96GBの80% = 76.8GBなので、このモデル（ウェイト約52GB）の場合は128k以下が安定します。
ただし実用上、コーディング作業には128k程度のコンテキストが必要なため、131,072を推奨値としています。

VRAM別の推奨設定

VRAM推奨モデルサイズ推奨コンテキスト
24GB7-13GB4,096-8,192
48GB30-40GB16,384-32,768
96GB50-70GB（ウェイトサイズ）131,072

安定運用のためのモニタリング

設定したら終わりではありません。運用中のモニタリングが重要です。

ollama ps で状態を確認する

ollama ps

出力例：

NAME                        SIZE     PROCESSOR    CONTEXT   UNTIL
qwen3-coder-next:latest    72.3GB   100% GPU     131072    4 minutes from now

チェックポイント：

項目確認内容危険サイン
PROCESSORGPU比率50% GPU / 50% CPU → VRAM不足
CONTEXT設定値デフォルトに戻っていないか
SIZEモデルサイズ異常に大きい → KVキャッシュ肥大化

PROCESSOR列が最も重要です。
CPUオフロードが発生したら、コンテキストサイズをさらに下げるか、モデルサイズを小さくしてください。

まとめ — ローカルLLMでも「使える」、ただし検証はまだ途中

今回はClaude Code × Ollama環境で、80Bパラメータモデル（VRAM約72GB）を使った実タスクの検証結果を解説しました。

この記事のポイント

  • 議事録システムのプロンプト改善まではローカルLLMだけで完結した
  • 途中でコンテキストエラーが発生し、セッションが強制終了した
  • AutoCompactをOFFにしていたことが最大の要因の可能性（会話が圧縮されず蓄積）
  • KVキャッシュによるVRAM圧迫も一因と推測されるが、1回の検証では断定できない
  • 対策としてコンテキストサイズを128k（131,072）に調整する方法を解説
  • Ollamaには4つの設定方法がある（CLI、環境変数、Modelfile、API）
  • 運用時は ollama ps でVRAMの状態を常に確認

結論：ローカルLLMでも「コード読解 → 改善提案 → 実装」は実用レベルに達しています。

ただし、コンテキストエラーについては正直なところ、1回の検証だけでは理解しきれていません。

  • AutoCompactをONにすればエラーは回避できるのか？
  • 同じ条件で毎回再現するのか？
  • タスクの規模や種類によって発生条件は変わるのか？
  • 128kに下げれば本当に安定するのか？

これらは今後、実際の業務で使い込みながら検証していきます。
新しい知見が得られたらPart3として報告する予定です。

前回の環境構築編と合わせて、ぜひ自社環境でのローカルLLM活用に挑戦してみてください。

関連記事

ツール選定・技術検証
AI Anthropic ClaudeCode Ollama
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

コメント

コメントする

CAPTCHA


目次