Qwen3 Coder Next入門2026｜使い方・料金・実力検証

80Bパラメータのモデルを、たった3Bの活性化コストで動かす。Alibaba Qwenチームが2026年2月に公開したQwen3 Coder Nextは、MoE（Mixture of Experts）アーキテクチャでコーディングエージェント用途に振り切った異色のモデルだ。SWE-bench Verifiedで70.6%を叩き出しながら、Ollamaでローカル実行できる。API料金は入力$0.11/Mトークンと、商用モデルの数十分の一。

筆者が実際にローカル環境で回してみると、256Kトークンのコンテキストウィンドウを活かしたリポジトリ規模のコード理解が光る場面と、3Bパラメータの限界を感じる場面の両方があった。万能ではない。だが「この用途ならクラウドAPIに課金する必要がない」と思えるケースが確実にある。

CursorやClaude Codeのバックエンドとしても差し込める。以下、技術的な仕組みからローカル実行の手順、競合との実力差まで順に見ていく。

Qwen3 Coder Nextとは何か — MoEアーキテクチャの核心

Qwen3 Coder Nextを一言で表すなら「巨大な知識を持ちながら、推論時は小さく動く」モデル。Qwen3-Next-80B-A3B-Baseをベースに、コーディングエージェント用途に特化したファインチューニングを施している。

MoEの仕組み — なぜ3Bで80B級の性能が出るのか

通常のLLMはすべてのパラメータを毎回の推論に使う。GPT-5.5なら数千億パラメータが毎トークンで活性化する。MoE（Mixture of Experts）は発想が逆で、80Bのパラメータを「エキスパート」と呼ばれるサブネットワークに分割し、各トークンの処理に必要なエキスパートだけを呼び出す。Qwen3 Coder Nextの場合、80B中の3Bだけが各推論で動く。

家に専門書が100冊あるとして、毎回100冊すべてを読むのではなく、問題に応じて必要な3冊だけ棚から引き抜く。読む量は3冊分だが、100冊分の知識にアクセスできる。MoEの効率はこの比喩に近い。

ハイブリッドアテンションとは

もう一つアーキテクチャ上の工夫がある。全レイヤーでフルアテンションを使うのではなく、一部のレイヤーにスライディングウィンドウアテンションを組み合わせるハイブリッド構成を取っている。256Kトークンという長大なコンテキストを扱いながらメモリ消費を抑える仕掛けだ。

コーディングエージェントにとって、この長コンテキストは決定的に重要になる。リポジトリ全体の構造を把握したうえでコードを生成・修正するタスクでは、数千行のソースコードを一度にコンテキストに載せる必要がある。4Kや8Kのコンテキストしか持たないモデルでは、ファイル間の依存関係を見落とす。

エージェント特化の訓練手法

ベースモデルからコーディングエージェントに仕上げるまでの訓練は3段階で構成される。大規模なコード合成タスクでの教師あり学習、実行環境とのインタラクション学習、そして強化学習（RL）によるエラーリカバリー能力の強化。特に3段階目が効いている。実際にコードを実行してエラーが出た場合に、そのエラーから回復する能力を強化学習で鍛えている。

エラーが出たら止まるモデルと、エラーから自律的に復帰するモデル。AIエージェントとして使う場面では、この差が作業完了率に直結する。

ベンチマーク比較 — 3Bパラメータの破壊力

数字を先に出す。Qwen3 Coder NextはSWE-bench Verifiedで70.6%を記録した。これは活性化パラメータ3Bのモデルとしては異常な数値だ。DeepSeek V3.2は37Bを活性化して70.2%。12倍のコンピュートで0.4ポイント下回っている。

絶対値で見ればGPT-5.5やClaude Opus 4.6には届かない。だがここで注目すべきは「パラメータ効率」だ。3Bの活性化コストでSonnet 4.5に肉薄するスコアを出している。ローカルのGPU1枚で動くモデルが、クラウド専用の巨大モデルと同じ土俵で戦えている事実は重い。

ベンチマークの読み方 — 数字の裏にある注意点

SWE-benchのスコアはエージェントスキャフォールディング（実行環境の構成）に大きく依存する。同じモデルでもスキャフォールドが違えば10ポイント以上変わることがある。Qwen3 Coder Nextの70.6%は公式のスキャフォールド構成での数値で、Claude Codeのような高度なスキャフォールドと組み合わせた場合のスコアではない。

もったいないと感じるのが、最大出力トークンの16K制限だ。複雑なリファクタリングタスクでは、1回の出力で複数ファイルを書き換える必要がある。16Kだと途中で切れるケースがあり、その場合はマルチターンで対応する必要が出てくる。

料金 — API利用とローカル実行のコスト

API入力単価はClaude Sonnet 4.6の27分の1。ローカルで動かせば電気代だけで済む。

API料金の比較

入力トークンあたりの単価はClaude Sonnet 4.6の約27分の1。1日50回、各回2Kトークン入力・1Kトークン出力と仮定した月額目安で、$5〜15に収まる。同じ使い方でClaude Sonnetなら$80を超える。

ローカル実行なら実質無料

オープンウェイトモデルなので、手元のGPUで動かせばAPI料金はゼロになる。かかるのは電気代と初期のハードウェア投資だけ。VRAM 24GBのGPU（RTX 4090など）が1枚あれば、量子化モデルで実用的に動く。

ただし「無料」には隠れたコストがある。モデルのダウンロード（数十GB）、セットアップの手間、GPU購入費の減価償却。月に数百回以上使うヘビーユーザーなら元が取れるが、週に数回の利用ならAPI経由のほうが合理的だ。

APIプロバイダーの選択肢

2026年5月時点で、Qwen3 Coder NextのAPIを提供しているプロバイダーは複数ある。Alibaba Cloud（Qwen公式）、OpenRouter、AWS Bedrock、DeepInfraが主要どころだ。OpenRouterはOpenAI互換APIなので、既存のツールチェーンにそのまま差し込める。AWS Bedrockを使えば、IAM認証やVPCエンドポイント経由のセキュアなアクセスも可能になる。

ローカル実行ガイド — OllamaとGGUFで動かす

ローカル実行の最短経路はOllamaだ。コマンド2つで動く。

Ollamaでの起動手順

# Ollamaのインストール（未導入の場合）
curl -fsSL https://ollama.com/install.sh | sh

# Qwen3 Coder Nextのダウンロードと起動
ollama run qwen3-coder-next

# 特定の量子化バージョンを指定する場合
ollama run qwen3-coder-next:q4_k_m

初回実行時はモデルのダウンロードが走る。フルモデルで約45GB、Q4量子化で約25GB。回線速度によるが、100Mbpsの環境で30分〜1時間ほど見ておく必要がある。

必要スペックの現実

公式にはVRAM 30GB以上の統合メモリを推奨している。だが実際に検証してみると、Q4_K_M量子化ならVRAM 24GB（RTX 4090）でも動作した。速度はフル精度より2割ほど落ちるが、インタラクティブな開発には十分使える水準だ。

VRAM 16GBのQ2量子化では、1トークン/秒を下回ることがある。PC Watchの西川氏のレビューでは「初回ロード中はフリーズしかけるレベル」と報告されている。会話のテンポで使える水準ではない。実用ラインは24GB以上だ。

GGUFモデルの選び方

HuggingFaceではUnslothが提供するGGUF量子化モデルが利用できる。量子化はJPEGの圧縮と同じ原理で、精度を少し削ってファイルサイズを3分の1にする。Q4_K_MならフルFP16の約4割のサイズで、体感品質の差はほぼわからない。

# HuggingFaceからGGUFモデルをダウンロード
# Ollamaを使わず、llama.cppで直接動かす場合
git lfs install
git clone https://huggingface.co/unsloth/Qwen3-Coder-Next-GGUF

# llama.cppで起動
./llama-server \
  -m Qwen3-Coder-Next-GGUF/qwen3-coder-next-q4_k_m.gguf \
  -c 32768 \
  --host 0.0.0.0 \
  --port 8080

コンテキスト長は-cオプションで指定する。256K全開にするとメモリ消費が跳ね上がるので、用途に応じて32K〜64K程度に絞るのが現実的な運用だ。

モデルが動いたら、次はエディタから呼び出す設定に進む。

IDE連携 — Claude Code・Cline・VS Codeでの設定

OllamaのバックエンドをClaude Codeに向ける設定は5分で終わる。Clineなら設定画面の3行で完了する。

Claude Code連携

Claude CodeはAnthropicのCLIツールだが、OpenAI互換APIを設定すればQwen3 Coder Nextをバックエンドとして使える。ローカルのOllamaサーバーをAPIエンドポイントに指定する形だ。

# Ollamaをバックグラウンドで起動
ollama serve &

# OpenAI互換エンドポイントの確認
curl http://localhost:11434/v1/models

# Claude Codeの設定例（.claude/settings.json）
{
  "model": "qwen3-coder-next",
  "apiBaseUrl": "http://localhost:11434/v1"
}

ここは見落としがちだが、Claude Codeのスキャフォールドは元々Claude向けに最適化されている。Qwen3 Coder Nextで動かすと、ツール呼び出しのフォーマット（XML形式）が微妙にずれてエラーになることがある。Clineのほうがモデル切り替えの柔軟性は高い。

Cline（VS Code拡張）での利用

ClineはVS Code上で動くAIコーディングアシスタントで、Qwen3 Coder Nextとの相性が良い。Ollamaバックエンドを指定するだけで動作する。

# Clineの設定画面で以下を入力
Provider: Ollama
Model: qwen3-coder-next
Base URL: http://localhost:11434

Clineを使う場合、num_ctxパラメータでコンテキスト長を指定できる。デフォルトでは4096に制限されることがあるため、Ollamaの設定で明示的に増やしておく。

# Ollamaのモデル設定でコンテキスト長を変更
ollama run qwen3-coder-next --num-ctx 32768

対応ツール一覧

動作確認済みのツール一覧（2026年5月時点）:

実践ユースケース — どんな開発タスクに効くか

すべてのコーディングタスクで最適解とは限らない。得意領域と苦手領域がはっきり分かれる。

得意な領域

単一ファイルのバグ修正と小規模なリファクタリング。ここが最も輝く。SWE-benchで高スコアを出している理由もこのタスク群だ。エラーメッセージとソースコードを渡して「直して」と言えば、高い精度で修正コードを返してくる。

テストコードの生成。既存の関数シグネチャからユニットテストを生成するタスクは、3Bの活性化パラメータでも十分にこなせる。テストケースの網羅性はClaude Opus 4.6に劣るが、8割方のケースをカバーできるテストを数秒で生成してくれる。

対応言語は370以上。Python、TypeScript、Rust、Go、Javaはもちろん、Haskell、Elixir、Zigといったニッチなものでもコードを吐く。ただしマイナー言語はPythonの8割程度の精度と見ておいたほうがいい。

苦手な領域

大規模なアーキテクチャ設計。「マイクロサービスの全体設計をして」といった、数十ファイルにまたがる構造的な判断を求めるタスクでは、3Bの活性化パラメータでは推論の深さが足りない。Claude Opus 4.6やGPT-5.5のような大規模モデルに任せるべき領域。

日本語でのコード説明・ドキュメント生成。検証してみると、日本語プロンプトに対するコード生成自体は問題ないが、日本語でのコード解説やREADME生成は英語に比べて品質が落ちる。技術的な日本語表現の語彙が限られている印象を受ける。

他モデル比較 — DeepSeek V3.2・Claude・GPTとの違い

コーディングモデルの選択肢は2026年に入って急増した。主要な競合との差を数字で見る。

DeepSeek V3.2との違い

DeepSeek V3.2も中国発のオープンウェイトモデルだが、活性化パラメータが37Bと12倍大きい。当然、ローカル実行のハードルも高い。VRAM 48GB以上のGPUが必要で、RTX 4090 1枚では量子化しても厳しい。性能差が0.4ポイントしかないことを考えると、ローカル実行目的ならQwen3 Coder Nextのほうが現実的な選択肢になる。

Claude Sonnet 4.6との違い

正直に言えば、コード生成の品質ではClaude Sonnet 4.6が上だ。特に複雑なロジックの設計やエッジケースの処理で差が出る。だがコストが27倍違う。「月に$300払ってClaudeを使うか、$10でQwen3 Coder Nextを使うか」という問いになる。個人開発者やスタートアップにとって、この差は無視できない。

主要AIサービスの詳しい比較はこちらの記事でまとめている。

Qwen3-Coderシリーズ内の使い分け

Coder Next以外にも、Qwenチームはコーディングモデルを複数リリースしている。Qwen3-Coder（480B-A35B）はフルサイズ版で、API経由でのみ実用的に使える。Qwen3-Coder-Plus（30B-A3B）は中間サイズ。用途に応じた選び方はシンプルだ。

つまずきポイントと対処法

VRAM不足で詰まるのが9割だ。残りの1割はツール呼び出しフォーマットの不一致。

Ollamaでメモリ不足エラー

最も多いトラブルがVRAM不足。エラーメッセージはout of memoryやCUDA error: out of memory。対処は3段階ある。

ツール呼び出し形式の互換性

本モデルのツール呼び出し（function calling）はXML形式を採用している。OpenAI互換APIを介すと自動変換されるケースが多いが、一部のツールでは手動でフォーマット変換が必要になる。Aiderでは--model ollama_chat/qwen3-coder-nextと明示的にモデル名を指定しないと、デフォルトのフォーマットが合わずにエラーになる。

長コンテキストでの性能劣化

256Kトークンまで対応しているが、コンテキストが長くなるほど推論精度が落ちる傾向がある。検証すると、64Kトークンを超えたあたりから回答の関連性が薄れ始める。ローカル実行では32K〜64Kの範囲で使うのが、精度と速度のバランスが最も良い。

よくある質問

まとめ — 誰にQwen3 Coder Nextを勧めるか

ポジションを取る。Qwen3 Coder Nextは「ローカルで動くコーディングエージェント」を探している開発者にとって、2026年5月時点で最も合理的な選択肢だ。

3Bの活性化パラメータでSWE-bench 70.6%。API料金は入力$0.11/Mトークン。Ollamaで手元のRTX 4090に載る。Apache 2.0で商用利用も自由。このスペック・コスト・ライセンスの組み合わせは、他のモデルでは再現できない。

一方で、万能ではない。大規模な設計タスクや高度な日本語ドキュメント生成ではClaude Opus 4.6やGPT-5.5に劣る。16Kの最大出力トークンも、大きなリファクタリングでは制約になる。

自分なら、日常的なバグ修正・テスト生成・コードレビューにはQwen3 Coder Nextをローカルで回し、アーキテクチャ設計や複雑なデバッグには商用モデルを使う。月のAPI費用を$300から$30に落とせる。

# 今すぐ試す
ollama run qwen3-coder-next

プロンプトエンジニアリングの基本を押さえておくと、Qwen3 Coder Nextの出力品質をさらに引き上げられる。AIエージェントの仕組みを理解しておくと、スキャフォールドの選択やツール連携の最適化に役立つ。

AIコーディングツールを活用したキャリア構築については、AIエンジニア転職ガイドも参考にしてほしい。