DGX Spark の 128GB メモリで Claude Code + Ollama のローカル実行に再挑戦してみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

以前の記事で、MacBook Pro（M4 32GB）上のローカル LLM で Claude Code を動かそうとして全滅した話を書きました。

https://dev.classmethod.jp/articles/claude-code-ollama-local/

1.5B から 14B まで試しましたが、Qwen2.5-Coder は「TodoWrite の JSON テキストをそのまま出力するだけ」、DeepSeek-R1 は存在しないファイルを Read したと言い張るハルシネーション、Gemma2 は関係ないタスクリストを延々と生成・・・と、どのモデルもツール呼び出しの壁を越えられませんでした。

128GB の統合メモリがあれば、120B クラスのモデルも載せられます。前回 14B で駄目だったものが、モデルサイズを 10 倍にしたら動くのか。結論から言うと、「モデルによっては実用に近づくものの、Claude Sonnet 4.5 の代替にはまだ遠い」という結果でした。

前回からの変化点

前回の検証（2026 年 1 月 25 日）から約 2 週間で、いくつか状況が変わっています。

ソフトウェアの更新

Ollama は v0.15.1 → v0.15.5 にアップデート。ollama launch claude による簡単セットアップは前回と同様です。Claude Code は v2.1.15 → v2.1.34 に更新されています。今回の検証で大きく変わったのは、主にハードウェア（MacBook Pro 32GB → DGX Spark 128GB）とモデルのスケールです。

新たに登場したモデル

前回の検証以降、ツール呼び出しに対応した新しいモデルが続々と登場しています。現在の Ollama Claude Code 推奨モデル は qwen3-coder、glm-4.7、gpt-oss の 3 系統です。今回は qwen3-coder の次世代版である qwen3-coder-next と glm-4.7-flash、gpt-oss:20b / gpt-oss:120b の 4 モデルを検証しました。

• gpt-oss — OpenAI が GPT-2 以来約 6 年ぶりに公開したオープンウェイトモデル
• glm-4.7-flash — SWE-bench 59.2%、MoE で軽量
• qwen3-coder-next — SWE-bench 70.6%、80B MoE でコーディング特化

Claude Code はツール定義 + システムプロンプトだけで大量のトークンを消費します。Ollama v0.15.5 では VRAM に応じて num_ctx が自動設定されますが（48GB 以上で 262144）、今回は安定性を考慮して 65536 に明示指定しています。

# Modelfileでコンテキストを拡張
FROM gpt-oss:20b
PARAMETER num_ctx 65536

検証環境

前回との比較

メモリは 4 倍、帯域幅は約 2.3 倍。載せられるモデルサイズが 14B → 120B+ へと広がります。

検証タスク

各モデルで以下の 4 つのタスクを実行し、結果を比較します。プロンプトについてはモデルの解釈に幅をもたせる少々雑なものを渡しています:)

• タスク A — FizzBuzz のコード生成（前回との比較用）
  プロンプト: FizzBuzzを書いて
• タスク B — React コンポーネントのファイル作成（ツール呼び出し）
  プロンプト: ReactでシンプルなカウンターコンポーネントをTypeScriptで書いてファイルに保存して
• タスク C — 既存コードの読み取り + 修正（Read → Edit の連携）
  プロンプト: utils.ts にバグがあるみたいなので、読んで修正して

タスク C で使うバグ入りの utils.ts は以下のコードです。removeDuplicates で seen.add(item) が欠落しているため重複排除が機能せず、average は空配列で NaN を返します。

export function removeDuplicates<T>(items: T[]): T[] {
  const seen = new Set<T>();
  const result: T[] = [];
  for (const item of items) {
    if (!seen.has(item)) {
      result.push(item);
      // seen.add(item) が欠落 — 重複排除が機能しない
    }
  }
  return result;
}

export function titleCase(str: string): string {
  return str
    .split(" ")
    .map((word) => word.charAt(0).toUpperCase() + word.slice(1).toLowerCase())
    .join(" ");
}

export function average(numbers: number[]): number {
  let sum = 0;
  for (const n of numbers) {
    sum += n;
  }
  return sum / numbers.length; // 空配列で NaN を返す
}

• タスク D — プロジェクト作成 + テスト実行（複数ステップのエージェント動作）
  プロンプト: 新しいディレクトリ fizzbuzz-project を作って、FizzBuzz関数をTypeScriptで実装し、テストも書いて実行して

検証の前提

• 各タスクは 3 回実行して安定性も確認

検証候補モデル

DGX Spark の 128GB メモリで動作可能なモデルの中から、ツール呼び出し対応を条件に選定しました。

検証 1: gpt-oss:20b

OpenAI が GPT-2 以来約 6 年ぶりに公開したオープンウェイトモデル。まずはウォームアップがてら試します。

セットアップ

ollama launch claude --model gpt-oss-20b-64k

タスク A: FizzBuzz

3 回実行したところ、結果にばらつきがありました。

• 1 回目（48 秒）— テキストでコードを出力するだけで、ファイルは作成されず
• 2 回目（31 秒）— fizzbuzz.ts を Write ツールで作成。コードも正しい
• 3 回目（48 秒）— fizzBuzz.ts と fizzBuzz.test.ts を作成。テストまで自発的に書いてくれましたが、途中で Invalid tool parameters エラーが出て自力リカバリする場面も

同じプロンプトなのにファイルを作ったり作らなかったり。ツール呼び出しの判断が安定していませんね。

タスク B: React コンポーネント生成

「ファイルに保存して」と明示したところ、1 回目から Counter.tsx を Write ツールで作成できました（44 秒）。useState、interface、React.FC を使った標準的な実装で、コード品質には問題なし。

「保存して」と言えばファイルを作り、言わなければテキスト出力するあたり、指示の明確さに敏感なモデルのようです。

タスク C: 既存コードの読み取り + 修正

バグ入りの utils.ts を「読んで修正して」と依頼した結果です。

• 1 回目 — Read は成功。average の空配列問題は発見したものの、removeDuplicates の seen.add(item) 欠落は見逃し。さらに「コードの修正自体は行いません」と Edit を拒否
• 2 回目は Read 後に Edit を 3 回試みるも全てエラーとなり、最終的に「バグは検出できませんでした」「seen.add(item) が正しく呼び出されています」と報告しましたが、実際にはバグはそのまま残っているのでハルシネーションです
• 3 回目 — 表形式の分析で seen.add 欠落と average 空配列の両方を正しく発見。ただし修正はテキスト提案のみで、Edit ツールは使わず

3 回を通じて、Edit ツールを一度も成功させられませんでした。「コードを読んで分析する」はできても「修正を実行する」ができない。

タスク D: プロジェクト作成 + テスト実行

npx がフックにブロック（検証環境ではnpm、npxを利用不可にしていたため）され bun に切り替え、bun:test の API を間違えて（assertEquals は存在しない）リトライを重ねること 4 回、最終的に全テスト通過。2 分 37 秒かかりました。

面白いのは、エラーメッセージを読んで自力で修正していく粘り強さです。bun:test の正しい API（expect）を知らないまま、node:assert の strict.strictEqual にたどり着いて解決するという力技でした。

所感

コード生成の品質は十分ですが、ツール呼び出しが不安定。特に Edit が一度も成功しなかったのは痛いです。「書いて」と言えばコードは出るものの「既存コードを直して」は厳しく、Claude Code のエージェント機能をフルに使うには力不足かなと思います。

検証 2: GLM-4.7-Flash

SWE-bench 59.2% で ollama launch にも対応している本命候補です。

セットアップ

ollama launch claude --model glm-4.7-flash-64k

タスク A: FizzBuzz

gpt-oss:20b とは明らかに違う動きを見せました。

• 1 回目（4 分 17 秒）— pwd で作業ディレクトリを確認 → ファイル検索 → utils.ts を Read → Edit で FizzBuzz 関数を追記 → テストスクリプトを Write → bun run で実行して動作確認まで完了
• 2 回目（3 分 8 秒）— 同様に既存の utils.ts に Edit で追記。今回は「テストファイルを作成して動作確認もできますか？」とユーザーに確認を取る姿勢

gpt-oss:20b では一度も成功しなかった Edit ツールが 1 回目から安定して動いています。新規ファイルを作る代わりに既存ファイルに追記するという判断も、より「開発者的」です。

ただし応答時間は 3〜4 分。gpt-oss:20b の 30〜50 秒と比べるとかなり遅い。

タスク B: React コンポーネント生成

1 回目から mkdir -p src/components でディレクトリ構造を作り、src/components/Counter.tsx を Write で保存（4 分 21 秒）。作成後に Read で自分の出力を検証する丁寧さも見せました。

タスク C: 既存コードの読み取り + 修正

Edit ツールは使えるのに、バグの発見で苦戦しました。

• 1 回目 — average の空配列問題は発見したものの、seen.add(item) 欠落は見逃し。修正方針をユーザーに確認する形で終了
• 2 回目 — Edit を 2 回成功させて average にガードを追加、titleCase にも守りの修正。しかし seen.add はやはり見逃し
• 3 回目 — 3 つの関数すべてに「✓ 正常」の判定。seen.add(item) がないのに「重複排除が正しく機能している」と報告

3 回とも seen.add(item) の欠落を見つけられませんでした。Edit ツールは安定して動くのに、暗黙的なバグの検出が苦手という特徴が出ています。

タスク D: プロジェクト作成 + テスト実行

ここが壮絶でした。Jest を使おうとして ESM/CJS の設定地獄にハマり、8 回のリトライを経て 13 分 59 秒で全テスト通過。

特に面白かったのは、ts-node の loader エラーに対してテストフレームワーク自体を捨てる判断をしたことです。Jest のテストコードを自作の assertEquals 関数に書き換え、tsc でビルドして node で直接実行するという大胆な方針転換でした。途中で fizzbuzz(0) が "FizzBuzz" を返す問題（0 は 15 の倍数）に気づいてテストケースを修正する場面もあり、粘り強さは感じます。

ただ、14 分は待ちすぎですね。

所感

Edit ツールの安定性は全モデル中で最も高く、エージェント的な行動（ファイル探索、確認、構造化）も充実しています。一方で、応答速度が 3〜14 分と遅く、バグ検出の推論力が弱い。「手際はいいけど見立てが甘い」という印象です。

検証 3: Qwen3-Coder-Next

前回の記事で Qwen2.5-Coder:14b は「TodoWrite の JSON テキストをそのまま出力するだけ」で全滅。今回の検証でも当初は 32B 版を試す予定でしたが、2026 年 2 月 3 日に Qwen3-Coder-Next がリリースされました。80B MoE（稼働 3B）で SWE-bench Verified 70.6% を叩き出し、Ollama でもすぐに対応されました。

セットアップ

ollama launch claude --model qwen3-coder-next-64k

タスク A: FizzBuzz

3 回実行して、Write ツールの挙動にばらつきがありました。

• 1 回目（3 分 8 秒）— テキストでコードを出力するだけで、ファイルは作成されず。gpt-oss:20b と同様に CLAUDE.md のカスタム指示を拾ってしまう挙動も
• 2 回目（3 分 23 秒）— やはりテキスト出力のみ。コード品質は高く、型定義や配列予約まで意識した実装
• 3 回目（8 分 40 秒）— 既存の utils.ts を Read してから Write で fizzbuzz.ts を作成。3 関数を export、JSDoc 付きで、コード品質は全モデル中トップクラス

Write の成功率は 3 回中 1 回。ただしコードの質は明らかに高く、型安全性やドキュメント性への意識が見えます。

タスク B: React コンポーネント生成

• 1 回目（7 分 33 秒）— 1 回目から Write で Counter.tsx を作成。interface で 4 つの props、min/max 制限、リセットボタン、スタイリング内包で 96 行
• 2 回目（2 分 28 秒）— テキスト出力に戻ってしまった。コード品質は同等だが、ファイルは未作成
• 3 回目（2 分 41 秒）— 「ファイルに保存して」を明示したところ Write 成功。109 行で onIncrement/onDecrement/onChange のコールバック 3 種を備えた充実した実装

タスク C: 既存コードの読み取り + 修正

Edit ツールの安定性は良好でした。

• 1 回目（2 分 0 秒）— Read 後に average の空配列問題を発見し、Edit で throw Error を追加。ただし seen.add(item) 欠落は見逃し
• 2 回目（1 分 34 秒）— Read まではできたものの「どの関数で問題が？」と聞き返して終了。自力でバグを見つけられず
• 3 回目（1 分 14 秒）— average の空配列問題を発見して Edit で return 0 を追加。やはり seen.add は見逃し

3 回とも seen.add(item) の欠落を見つけられませんでした。「他の関数は特に問題なさそう」と報告しているので、GLM-4.7-Flash と同じ傾向です。Edit ツールは安定して動くのに、暗黙的なバグの検出は苦手。

タスク D: プロジェクト作成 + テスト実行

ここで Qwen3-Coder-Next の底力が出ました。

AskUserQuestion でテストフレームワークの確認（Vitest + ES Modules）を取ってから、ディレクトリ作成 → ファイル作成 → テスト実行を 4 分 17 秒で完遂。4 テスト全パスです。

GLM-4.7-Flash が 13 分 59 秒、gpt-oss:120b が再挑戦で 3 分 20 秒だったことを考えると、1 回目から一発でここまでたどり着いたのは評価できます。ユーザーに方針を確認してから動くという「確認してから実行する」姿勢も、エージェントとしては好印象です。

所感

複数のツールを使いこなし、マルチステップタスクも 1 回目で完走。前世代からの進化は明確です。一方で Write の安定性が課題で、タスク A は 3 回中 1 回、タスク B は 3 回中 2 回と、ファイル作成の判断にばらつきがあります。コード品質は全モデル中トップクラスなだけに惜しいところです。

検証 4: gpt-oss:120b

ここからが DGX Spark ならではの領域です。120B パラメータのモデルは MacBook Pro 32GB では到底動きません。

セットアップ

ollama launch claude --model gpt-oss-120b-64k

タスク A: FizzBuzz

1 回目から Edit ツールで utils.ts に FizzBuzz 関数を追記（3 分 23 秒）。ファイル検索 → Read → Edit という流れで、GLM-4.7-Flash と同じエージェント的な振る舞いを見せました。

gpt-oss:20b では 1 回目で Write すらできなかったことを考えると、パラメータ 6 倍の効果は明確です。

タスク B: React コンポーネント生成

Counter.tsx を Write で作成（2 分 29 秒）。useState、React.FC、スタイリング付きの標準的な実装。特に問題なし。

タスク C: 既存コードの読み取り + 修正

今回の検証で最も興味深い結果が出たのがこのタスクです。

• 1 回目（1 分 18 秒）— seen.add(item) の欠落と average の空配列問題を両方とも正しく発見。「seen が常に空のままなので、if (!seen.has(item)) が常に true になる」という正確な分析でした。ただし修正はテキスト提案のみで Edit は使わず
• 2 回目（1 分 33 秒）— Edit に挑戦。1 回目はエラーになったものの、再度 Read してから average にガード追加を成功。ただし seen.add の修正は今回は見逃し
• 3 回目（1 分 43 秒）— 両方のバグを発見して両方とも Edit で修正を試みました。ただし seen.add(item) を 2 回追加してしまう（seen.add(item); seen.add(item);）という品質問題が。意図は正しいけど、実行の精度がもう一歩

全モデルの中で唯一、1 回目で両方のバグを発見できたのは大きなポイントです。コード理解力はパラメータ数に比例するようですね。

タスク D: プロジェクト作成 + テスト実行

最初の実行では、Claude Code の Task ツール（サブエージェント委任）を呼び出そうとする予想外の行動を見せました。Opus 4.6、Sonnet 4.5、Haiku 4.5 に順に委任しようとしましたが、ローカル LLM からの Task 呼び出しは当然機能せず、8 分近く空転。

再挑戦で「直接実装して」と伝えたところ、今度は素直に mkdir → npm init → npm install → ファイル作成 → npm test の流れを 3 分 20 秒で完遂。Jest + ts-jest の構成も適切で、4 テスト全パスでした。

GLM-4.7-Flash が同じタスクに 14 分かかったことを考えると、120B のモデルサイズがテスト環境構築の知識にも効いている印象です。

所感

今回検証した中では最もバランスの良いモデルです。バグ検出力が高く、Edit も使え、速度も 1〜3 分台と許容範囲。ただし Edit の精度が完璧ではなく、Task 委任の空振りのような余計な動作もある。「だいぶ使えるけど、横で見ていないと怖い」という感覚でしょうか。

結果比較

モデル × タスク マトリクス

凡例: ○ 成功 / △ 一部成功 / × 失敗 — Claude Sonnet 4.5 はクラウド API での参考値

能力別の比較

前回（MacBook Pro 32GB）との比較

モデルサイズを上げることで確実に改善が見られました。詳しくは考察で掘り下げます。

考察

ツール呼び出しの精度はモデルサイズで変わるのか

今回の検証で最も明確に出た傾向は、パラメータ数がツール呼び出し精度に直結するということです。

同じ gpt-oss ファミリーで比較すると、20B では Write が不安定で Edit は不可能でしたが、120B では 1 回目から両方成功しています。MoE の稼働パラメータは 3.6B → 5.1B の差ですが、全体のパラメータ数（知識量）が 6 倍に増えたことで、ツールの使い方に関する「理解」が深まっているのでしょう。

Qwen も前回の 2.5-Coder:14b は全滅でしたが、Qwen3-Coder-Next は MoE アーキテクチャと function calling の強化学習で大きく進化。マルチステップタスクを 1 回目で完走しており、Write の安定性を除けば実用に近づいています。

「見つける」と「直す」は別の能力

gpt-oss（20b / 120b）はバグを見つける能力はあるものの、Edit ツールの扱いが苦手です（20b は不可、120b は精度△）。一方で GLM-4.7-Flash は Edit ツールを安定して使えるのに、暗黙的なバグ（seen.add 欠落）を検出できません。

「コードを理解する推論力」と「ツールを正しく操作する能力」は、少なくとも現時点のローカル LLM ではまだ両立が難しいようです。クラウド API（Claude Sonnet 4.5）は両方を 1 回目で完璧にこなすので、差はこの「両立」の部分にあると感じます。

MoE モデルの優位性

今回検証した 4 モデルはすべて MoE アーキテクチャで、いずれもツール呼び出しに成功しています。前回の記事で Dense モデルの Qwen2.5-Coder:32b が全滅だったことと合わせて考えると、MoE の恩恵は大きいといえそうです。

MoE は全パラメータの一部だけを稼働させるため、同じメモリ消費量でもより大きなモデルを動かせます。128GB の統合メモリを活かすなら、MoE で大きなモデルを載せるのが知識量と速度の両面で有利です。MoE の仕組みについては DGX Spark ファーストインプレッションでも触れています。

ローカル LLM × Claude Code が向いているケース

現時点で「使いどころがある」と感じたのは以下のような場面です。

• 定型的なコード生成 — FizzBuzz や React コンポーネントのような「ゼロから作る」タスクは、gpt-oss:120b ならそれなりに実用的
• コードレビュー的な用途 — gpt-oss:120b はバグ検出が得意そうなので、「このコードにバグない？」と聞く使い方は悪くない（修正は自分でやる前提で）
• センシティブコードの処理 — ソースコードがネットワーク外に出ないのは、ローカル LLM 最大のメリット

逆に「まだ厳しい」と感じた場面もあります。

• 既存コードの修正を自動で任せる場面 — Edit の精度が不十分で、見守りが必要
• 複雑なマルチステップタスク — 到達はするけど、時間がかかりすぎる

まとめ

前回の MacBook Pro 32GB では 14B まで試して全滅でしたが、DGX Spark の 128GB メモリ環境では明確な改善が見られました。特に gpt-oss:120b は、コード生成・バグ検出・マルチステップタスクのいずれもそれなりにこなせる水準に達しています。

ただ、「使える」と「実用的」の間にはまだギャップがあります。Edit の精度が不安定だったり、テスト実行に何度もリトライが必要だったり、応答に数分待つ場面があったり。Claude Sonnet 4.5 なら数秒で完璧にこなすタスクに、ローカル LLM は数分かけて「だいたい合っている」結果を返すのが現状です。

もし 1 つ選ぶなら gpt-oss:120b を推します。128GB メモリがあるなら MoE の恩恵で速度もそこそこ出ますし、バグ検出力は全モデル中トップでした。DGX Spark ならではの選択肢です。

とはいえ、ローカル LLM の進化は速い。Ollama v0.15 の ollama launch claude だけでもセットアップが格段に楽になりましたし、今後ツール呼び出しに強い新しいモデルが出てくれば状況は変わるかもしれません。半年後にまた同じ検証をやったら、違う結論になっていそうな気がします。

参考リンク

• 前回記事: Ollama v0.15 で Claude Code をローカル実行できるか試してみた
• DGX Spark ファーストインプレッション
• Ollama Blog: Claude Code with Anthropic API compatibility
• Ollama Blog: ollama launch
• Ollama Tool Calling
• Claude Code Documentation
• BFCL Leaderboard
• Qwen3-Coder-Next 公式ブログ
• Qwen3-Coder-Next on Ollama
• Ollama Models Library