Qwen Coderとは｜ライセンス・必要メモリ・料金・接続方法を一次情報で【2026年9月版】

本記事の情報について: 本記事は2026年9月4日時点で、Qwen公式リポジトリ・Hugging Faceのモデルカード・Qwen3-Coder-Next技術報告（2026年2月3日）・Alibaba Cloud Model Studioの料金表・Qwen Code公式ドキュメント・Anthropic公式ドキュメント、および当社リポジトリでの実測を直接参照して整理しています。オープンウェイトモデルは公開・改版の速度が速いため、意思決定に用いる際は各出典の最新版をご確認ください。本文中のライセンスに関する記述は一般的な整理であり、個別案件の法的助言ではありません。

「Qwen Coderが良いらしい」と言われて調べ始めると、無料で使えるという記事と、GPUが必要だという記事と、Claude Codeから使えるという記事が同時に出てきます。しかもそれぞれ、書かれた時期もモデルの世代も違います。本記事は、そのどれが2026年9月時点で成立しているのかを、公式の一次資料だけで確かめた結果をまとめたものです。

この記事の要点

Qwen Coderとは、Alibaba Cloudが開発するコーディング特化の大規模言語モデル群と、その周辺ツールの総称です。企業が採用を検討するうえで、2026年9月時点で押さえておくべき点は次の8つです。

• 「Qwen Coder」という言葉は3つの別物を指します。オープンウェイトのモデル群（Qwen3-Coder-*）、ターミナルCLIの「Qwen Code」、そしてクラウドアプリの「coder.qwen.ai」です。ネット上の評判はこの3つが混ざったまま語られています。
• ライセンスはApache 2.0で、追加の利用制限はありません。Qwen3-Coder-480Bに同梱されたLICENSEは、Apache Software Foundationが配布する原文と、著作権表示の1行と末尾の改行を除いて完全に一致しました。ただし最新のQwen3-Coder-Nextにはリポジトリ内にLICENSEファイルが存在しません。
• 同じモデルでも、動かす外枠（スキャフォールド）でスコアが10.4ポイント動きます。公式技術報告のTerminal-Bench 2.0では、4つの外枠のうち最良のTerminus2-jsonで36.2、最低のQwenCodeで25.8でした（Terminus2-xml 34.2、ClaudeCode 30.9）。「Qwen3-Coderは○点」という単独の数字は、どの外枠で動かすかを指定しない限り意味を持ちません。
• 主力のQwen3-Coder-Nextは、コンシューマ向けGPU 1枚では動きません。公式GGUFの4bit量子化版が48.4GB、Ollama配布版が52GBです。24GBのGPU 1枚には載りません。
• APIの料金は「階層課金」です。1リクエストの入力トークンが階層を超えると、そのリクエストの入出力すべてが上位階層の単価になります。API専用の上位モデルqwen3-coder-plusは256K超で出力が100万トークンあたり60ドルとなり、Claude Opus 5の25ドルの2倍以上になります。なおAPI前提なら、Alibaba自身がQwen-Coderではなく最新の汎用モデルを推奨しています。
• Qwen Code CLIの無料枠（Qwen OAuth）は2026年4月15日に終了しました。検索上位には2025年7〜8月に書かれた日本語記事が複数あり、「無料で使える」という前提そのものが現在は成立していません。
• Claude Codeから使う構成は、Anthropicの公式サポート対象外です。Qwen側は「Claude Codeとシームレスに統合できる」と書いていますが、Anthropicは「いかなるゲートウェイ経由であれ、Claude Codeを非Claudeモデルにルーティングすることはサポートしない」と明記しています。
• 256Kのコンテキストに、リポジトリは入りません。当社の中規模Next.jsアプリのソース308ファイルを公式トークナイザで数えると398,593トークンあり、ネイティブの262,144トークンに収まりませんでした。

本記事が扱う範囲：モデル比較・導入可否の判断は別記事です

本記事はQwen Coder単体の技術仕様・ライセンス・料金・接続方法に絞っています。目的が別のところにある場合は、先に次の記事をご覧いただくほうが早く進みます。

• どのモデルを選ぶかを比較したい方（Llama・Qwen・Gemma・ELYZA-JPの違い、Ollama・LM Studio・vLLMの使い分け）は、ローカルLLMおすすめ比較｜日本語・費用・選び方をご覧ください。どのモデルを採用するかを選ぶための横断比較表はそちらに集約しています。本記事で他社モデルの性能を比較するのは、Qwenの技術報告に載っている比較対象の引用に限ります（API単価・サポート範囲・ライセンスの対照はこの限りではありません）。
• そもそもローカルLLMを導入すべきかを判断したい方（クラウドとの損益分岐、総保有コスト、法務上の位置づけ、体制）は、ローカルLLMは自社に必要か｜導入判断・費用・体制の実務ガイドをご覧ください。

逆に、「Qwen Coderという名前を聞いたが、実際に自社で使えるのか、何が必要で、いくらかかるのか」を確かめたい方は、このまま読み進めてください。

「Qwen Coder」は3つの別物を指す

Qwen Coderという言葉が指す対象は、2026年9月時点で3つに分かれています。この区別をしないまま情報を集めると、料金も必要スペックもライセンスも噛み合わなくなります。

1. モデル群「Qwen3-Coder」

ウェイトが公開されているオープンウェイトのモデル群です。GitHubのQwenLM/Qwen3-Coderリポジトリで公開され、Hugging FaceとModelScopeから重みを取得できます。自社サーバーやローカルPCで動かせるのはこれです。本記事の中心もここになります。

2. ターミナルCLI「Qwen Code」

npm install -g @qwen-code/qwen-code@latest でインストールするコマンドラインのコーディングエージェントです（Node.js 22以上が必要）。注目すべきは出自で、公式READMEに「このプロジェクトは当初Google Gemini CLI v0.8.2をベースにしていた。Qwen Code v0.1以降は上流との同期をやめ、独立した開発に移行した」と明記されています。つまりQwen Codeは、Qwen専用ツールではなくOpenAI・Anthropic・Gemini各プロトコルに対応した汎用エージェントとして育っています。

3. クラウドアプリ「coder.qwen.ai」

coder.qwen.ai は「Qwen Coder」という名前を掲げた公式アプリの配布ページです。同ページのメタディスクリプションでは「セキュアなクラウドサンドボックス上で動作し、機能の実装・バグ修正・プルリクエスト生成を行うコーディングエージェント」と説明されています。ローカルで動かすモデルとは別物で、配布されているのはモバイル向けアプリです。本記事はローカル実行とAPIを主対象とするため、この種のクラウド型コーディングエージェントは個別に掘り下げず、他社の同種サービスとまとめて後述の判断表で位置づけます。

補足：SWE-bench 77.80%は別モデルの成績

Qwen Codeの公式READMEには、SWE-bench Verified（500ケース）でバージョン0.0.14が平均77.80%というスコアが掲載されています。この数字だけが独り歩きしがちですが、同じREADMEの評価設定表には測定に使ったモデルとして Qwen 3.7 Max と書かれています。これはオープンウェイトのQwen3-Coderではなく、別のモデルです。「Qwen Codeで77.80%出た」ことと「Qwen3-Coderが77.80%出せる」ことは、まったく別の話だと理解しておいてください。オープンウェイトモデル自体のスコアは後述の技術報告の数値が正になります。

モデルのラインナップと世代

Qwen3-Coderとして公開されているモデルは、2026年9月時点で次の3系統・4モデルです（出典: QwenLM/Qwen3-Coder README、Hugging Faceモデルカード）。

現在の主力はQwen3-Coder-Nextです。Hugging Faceでの公開は2026年1月30日、最終更新は2026年2月3日でした。

なお、これとは別に、APIでのみ提供される qwen3-coder-plus と qwen3-coder-flash があります。Qwen3-CoderのGitHub READMEがダウンロード先つきで挙げている公開ウェイトはNext / Next-Base / 480B / 30B とそのFP8・GGUF版の8件で、この2つは含まれていません。Model StudioのAPIモデルIDとしてのみ確認できるため本記事の主対象ではありませんが、階層課金の影響がもっとも大きく出るモデルなので、後述の料金表では併記します。

Qwen3-Coder-Nextの特徴は、総パラメータ80Bのうち推論時に使うのが3Bだけという構成にあります。GitHubのREADMEによれば、Qwen3-Next-80B-A3B-Baseを土台に、ハイブリッドアテンションとMoE（Mixture of Experts、入力ごとに一部の「専門家」だけを働かせる仕組み）を組み合わせたアーキテクチャを採用しています。モデルカードでは「アクティブパラメータが10〜20倍のモデルに匹敵する性能」と説明されています。

この構成が実務上意味するのは、計算量は3B相当で軽い一方、メモリには80B分の重みを置く必要があるという点です。後述するメモリの話は、ここから直接効いてきます。

運用上、次の2点は事前に把握しておく価値があります。

• コンテキスト長はネイティブ262,144トークンです。READMEのQwen3-Coder共通の記述には、Yarn（コンテキスト長を延長する手法）で最大100万トークンまで拡張できるとあります。ただしNext自身の配布設定（config.json の rope_scaling）は null で、既定では無効です。
• 推論モード（thinking）は持ちません。モデルカードに「このモデルはnon-thinkingモードのみをサポートし、出力に <think></think> ブロックを生成しない」と明記されています。思考過程を出力させる前提の運用設計はできません。

READMEによれば、対応言語は358のプログラミング言語です。

ライセンスをApache 2.0の原文で確認した結果

Qwen3-Coderのライセンスは、Apache License 2.0です。ただし「Apache 2.0と書いてある」ことと「Apache 2.0そのものである」ことは別なので、原文を取得して照合しました。

オープンウェイトのモデルでは、Apache 2.0やMITを名乗りながら利用制限条項を追加している例、あるいはLlamaコミュニティライセンスのように独自条項を持つ例があります。そこで、Qwen3-Coder-480B-A35B-Instructに同梱されているLICENSEファイルと、Apache Software Foundationが配布する原文（apache.org/licenses/LICENSE-2.0.txt）を機械的に差分比較しました。

結果は次のとおりです。

• 差分は2箇所のみでした。1つは付録の著作権表示テンプレートが Copyright [yyyy] [name of copyright owner] から Copyright 2024 Alibaba Cloud に置き換わっている行、もう1つはファイル末尾の改行の有無です。
• 利用制限条項、Acceptable Use Policy、独自の追加条項はいずれも存在しません。差分2箇所はどちらも付録と改行であり、条文本体（第1条〜第9条およびEND OF TERMS AND CONDITIONS、1〜178行）には1文字の差分もありません。

企業利用の観点では、これは扱いやすい部類に入ります。商用利用・改変・再配布が可能で、Llama系のようなMAU（月間アクティブユーザー）上限や命名条件、無条件の補償義務は付いていません。なおApache 2.0第9条は、再配布時に自ら保証・サポート・補償などの責任を引き受ける場合に限り、その引き受けを理由に各Contributorが負う責任や受ける請求について、Contributorを補償・防御・免責することを求めています。責任を引き受けなければ発生しない条件付きの義務です。ライセンス類型ごとの実務上の違いは商用ライセンスは「使えるか」ではなく「どう使うか」で変わるで条文ベースに整理しています。

Qwen3-Coder-NextにはLICENSEファイルがない

一方で、確認しておくべき点があります。主力のQwen3-Coder-Nextには、リポジトリ内にLICENSEファイルが存在しません。

• Qwen3-Coder-480B-A35B-Instruct と Qwen3-Coder-30B-A3B-Instruct には LICENSE ファイルがあります。
• Qwen3-Coder-Next と Qwen3-Coder-Next-GGUF には LICENSE ファイルがありません。Hugging Face APIでリポジトリ内の全ファイル（Nextは52件）を走査しましたが、ライセンス関連のファイルは0件でした。
• モデルカードの license_link は .../Qwen3-Coder-Next/blob/main/LICENSE を指していますが、このURLは実際には存在せず、取得すると「Entry not found」が返ります。

宣言そのものはメタデータ（license: apache-2.0）として明示されているため、ライセンスが不明というわけではありません。ただし稟議や法務レビューで「ライセンス条文の写しを添付してください」と言われたときに、Nextについてはリポジトリから取れないことになります。実務では次の順で進めるのが確実です。

1. 採用するモデル名とリビジョン（コミットハッシュ）を確定する。
2. そのリビジョンのモデルカードとメタデータのライセンス宣言を保存する。
3. LICENSEファイルが同梱されていない場合は、同じQwen3-Coderファミリーでファイルが存在するモデル（480Bなど）の条文と、Apache 2.0原文を併せて記録に残す。

ベンチマークを公式技術報告から読む

Qwen3-Coder-Nextの性能は、Qwenチームが2026年2月3日に公開した技術報告「Qwen3-Coder-Next Technical Report」に実数値が掲載されています。ここでは原典の表から引用します。先に結論を述べると、Qwen3-Coder-Nextの成績は「どのベンチマークを、どの外枠で走らせたか」の組み合わせで動き、どの条件でも一律に強いわけではありません。以下がその根拠です。

以下の表の読み方です。

• 「—」は、技術報告が「信頼できる結果を得られなかった」としたセルで、0点ではありません。
• 「サイズ」列は総パラメータ／アクティブパラメータで、80B/A3B は総パラメータ80B・アクティブ3Bを指します（原典の表記は 80A3）。
• 順位は、断りのない限りオープンウェイトのモデル同士で、かつその列に値のあるモデルのみを分母としています（プロプライエタリモデルとの比較は都度明記します）。
• 製品名と同じ綴りの外枠は、原典の表記をそのまま使っています（ClaudeCode、QwenCode）。それぞれ製品としての「Claude Code」「Qwen Code」を外枠に用いた構成を指します。
• 原典のTable 4はSWE-bench MultilingualとProを1枚にまとめていますが、本記事では読みやすさのため2つに分けています。

Template Following：オープンウェイトで2位（原典 Table 2）

5種類のIDE/CLIテンプレートでツール呼び出しの形式に従えるかを測った表です。対象モデルは以下の各表と異なります。

（原典のTable 2は他表と違いプロプライエタリ／オープンウェイトの区分行を持たないため、この区分は本記事で付けたものです。）

Qwen3-Coder-Nextは平均92.7で、オープンウェイト7モデルのなかではDeepSeek-V3.2（93.7）に次ぐ2位です。この表では順位が分母に依存せず、プロプライエタリを含めた10モデル全体でも2位で、Gemini-3-Proの87.0、Claude-Sonnet-4.5の85.4を上回りました。指示された書式には従えます。ただし以下の各表が示すとおり、書式に従えることと、タスクを完遂しきることは別です。

SWE-bench Verified：外枠しだいでオープンウェイト4位にも1位にもなる（原典 Table 3）

アクティブパラメータ3Bで、37Bや32Bのモデルと同水準に並びます。順位は外枠で割れます。SWE-Agent構成では5モデル中4位で、1位のMiniMax-M2.1（74.8）に4.2ポイント届きません。一方MiniSWE-Agent構成では5モデル中1位となり、プロプライエタリのClaude-Sonnet-4.5（68.4）も上回ります（OpenHands構成は4モデル中2位。Claude-Opus-4.5にはどの外枠でも届きません）。

SWE-bench Multilingual：外枠しだいでオープンウェイト4位にも2位にもなる（原典 Table 4）

日本語を含む多言語のコードベースを扱う企業には、Verifiedよりこちらのほうが実務に近い指標です。ここでも順位は外枠で割れます。SWE-Agent構成とMiniSWE-Agent構成では5モデル中4位ですが、OpenHands構成では64.3となり、4モデル中ではMiniMax-M2.1（67.5）に次ぐ2位で、GLM-4.7を3.5ポイント上回ります。採用する外枠とセットで見てください。

SWE-bench Pro：どちらの外枠でもオープンウェイト1位（原典 Table 4）

より難易度の高いProは、前掲の4表のなかで唯一、Qwen3-Coder-Nextの順位が外枠で動かない表です（他モデルは動きます。DeepSeek-V3.2は40.9から29.0へ落ち、オープンウェイト2位から最下位になります）。SWE-Agent構成でClaude-Sonnet-4.5と同値の44.3、MiniSWE-Agent構成でも37.9でKimi-K2.5（37.8）をわずかに上回り、どちらの外枠でも5モデル中1位です。ただしMiniSWE-Agent構成ではSonnet-4.5の39.7に届かず、Claude-Opus-4.5（46.7／44.1）はどちらの外枠でも一段上にいます。

Terminal-Bench 2.0：外枠で10.4ポイント動く（原典 Table 5）

ここが実務上もっとも重要な表です。同じモデルを4種類の外枠で動かした結果が並んでいます。

Qwen3-Coder-Nextの順位は外枠ごとに異なります。Terminus2-xml構成とQwenCode構成では4モデル中4位で最下位、Terminus2-json構成では5モデル中4位（最下位はMiniMax-M2.1の32.6）、ClaudeCode構成では3モデル中2位です。同じモデルでも、外枠を変えるだけで36.2から25.8まで10.4ポイント動きます。「Qwen3-Coder-Nextは○点」という単独の数字は、外枠を指定しない限り意味を持ちません。Terminus2-xml構成ではGLM-4.7の44.9、Terminus2-json構成ではKimi-K2.5の49.4に劣りますが、ClaudeCode構成ではKimi-K2.5が9.0まで落ちて逆転します。順位そのものが外枠で入れ替わる、というのがこの表の読み方です。

公式が認める限界：長尺タスク・ターン数・フロントエンド

技術報告の結論部では、Qwenチーム自身が、Claude Opus 4.5のようなフロンティアのプロプライエタリモデルと比べた限界として次の3点を挙げています。

• 複雑で大規模なソフトウェアエンジニアリングタスクを解く力には、依然としてギャップがある。
• 一部の複雑なタスクでは、正解に到達するまでに必要なやり取りの回数が多くなることがある。
• フロントエンドおよびUI関連の能力は、改善が必要な領域として残っている。

3点目は日本の受託開発やWeb系の内製で影響が出やすいところです。2点目のターン数増加は、後述する階層課金と組み合わさるとコストに直結します。

なお、この技術報告の比較対象はClaude Opus 4.5とSonnet 4.5であり、2026年9月時点の最新世代ではありません。現行世代との差はこの表からは読み取れない点にご注意ください。

ローカルで動かすのに本当に必要なメモリ

必要メモリは、推定値ではなく配布されているファイルの実サイズから逆算するのが確実です。量子化済みの重みは、そのサイズ分がメモリに載るためです。

公式配布物の実サイズ

公式GGUFはこのほかにQ5_0（55.0GB）、Q5_K_M（56.7GB）、Q6_K（65.5GB）、F16（159.5GB）が配布されています。この表のサイズは10進のGB表記で、括弧内は2進のGiB換算です（約7%ずれます）。次節のハードウェア表は、判定を括弧内のGiB換算で行っています。表中の太字は、その次節が判定に用いる3つの配布物です。

手元の環境で何が動くか

上の実サイズから逆算すると、次のようになります。コンテキストを長く取ればKVキャッシュの分だけさらに必要になるため、余裕は多めに見てください。

※1 VRAM合計48GiBが物理的な上限です。公式GGUF（45.1GiB）なら重みは載りますが、KVキャッシュの余地がほぼありません。Ollama配布版は上限48GiBをわずかに超え、重みだけで収まりません。

※2 物理メモリには余裕がありますが、macOSはGPUに割り当てるメモリの上限を既定で搭載メモリの一部に制限します。公式GGUF（45.1GiB）でも既定の上限に近く、より大きい配布物では上限の引き上げが必要になります。

※3 128GBなら8bit版（公式GGUF 84.8GB／Ollama 85GB＝約79GiB）も載ります。

最大のQwen3-Coder-480Bは4bitでも290GBあり、上の環境ではH100 80GB×4を除いて動きません。その構成（合計320GiB）でも、重み270GiBを載せた残りは約50GiBで、長いコンテキストを取ると余裕はありません。

実務上の要点は明確です。話題になっているQwen3-Coder-Nextは、コンシューマ向けGPU 1枚では動きません。「軽量」「3Bで動く」という表現が独り歩きしていますが、3Bなのは推論時にアクティブになるパラメータであって、メモリには80B分の重みを載せる必要があります。この違いを取り違えると、ハードウェアの調達見積もりが大きくずれます。

手元のPCで試すなら、現実的な入口は qwen3-coder:30b（19GB）です。Cline公式のローカル実行ガイドも、RAM 16〜32GBは小型・量子化モデル、32〜64GBは中規模のコーディングモデル、64GB以上でより大きなモデルと長いコンテキスト、という目安を示しています。量子化の考え方と規模別のスペック感は必要なPC・GPUスペックと量子化の考え方にまとめています。

APIで使う場合の料金：階層課金という設計

自社でGPUを用意せず、Alibaba Cloud Model StudioのAPIから使う選択肢もあります。ここで理解が必要なのは、qwen3-coder系が「階層課金」を採っている点です。

公式ドキュメントの定義はこうです。「単一のリクエストの入力トークン数が特定の階層に達した場合、そのリクエストの入力トークンと出力トークンのすべてが、その階層の単価で課金される」。フラットな単価ではなく、リクエスト単位で単価そのものが切り替わります。

料金表（シンガポールリージョン／International、100万トークンあたり・USD）

表記は「入力 / 出力」です。※ qwen3-coder-30b-a3b-instruct と qwen3-coder-480b-a35b-instruct は、この階層の上限が256Kではなく200Kです（出典: Alibaba Cloud Model Studio 料金ページ）。

「安い」という前提が崩れる場所

Qwen系は安価という印象がありますが、長いコンテキストを渡す使い方では逆転します。上位のqwen3-coder-plusは256Kを超える階層で出力が100万トークンあたり60ドルです。Anthropicの公式価格（2026年9月4日時点）はClaude Opus 5が入力5ドル・出力25ドル、Claude Sonnet 5が入力2ドル・出力10ドルなので、この階層では出力単価がClaude Opus 5の2倍以上になります。

コーディングエージェントはリポジトリを読み込ませるほど入力が膨らみ、階層を押し上げやすい使い方です。技術報告が認めていた「複雑なタスクではやり取りの回数が増える」という性質も、この課金設計とは相性がよくありません。試算では、平均的なリクエストサイズではなく、もっとも大きいリクエストがどの階層に入るかを基準に置いてください。

コストを下げる方向で押さえる点は2つです。ただし1つめは、主力の qwen3-coder-next では使えません。

• コンテキストキャッシュ（対応モデルのみ）: 暗黙キャッシュにヒットした入力は標準単価の20%、明示キャッシュはヒット時10%で課金されます（ただし明示キャッシュの作成時は標準入力単価の125%がかかります）。公式は「コンテキストキャッシュに対応したモデルでは」と条件を付けており、対象は qwen3-coder-plus と qwen3-coder-flash（いずれもAPI専用）で、本記事が価格を引いているシンガポール表で明示されているのは plus のみです。qwen3-coder-next・480B・30B にはどのリージョンでも記載がありません。
• ツール定義の圧縮: tools パラメータで定義したツールの説明文もトークン数に含まれ課金対象になると明記されています。MCPサーバーを大量に接続している場合、実際の指示より定義のほうが大きいことがあります。

なお新規ユーザー向けには、各Qwen-Coderモデルにつき100万トークンの無料枠がありますが、シンガポールリージョン限定で、Model Studioの有効化・モデル公開・申請承認のうちもっとも遅い日から90日間です。

Alibaba自身は汎用モデルを推奨している

見落とされがちですが、Alibaba CloudのQwen-Coderモデル解説ページ（最終更新2026年8月26日）の冒頭には、次の注記が置かれています。「Qwen-Coderモデルの代わりに、最新の汎用モデルを使うことを推奨します」。

ベンダー自身がコード特化モデルより汎用モデルを勧めている状況です。オープンウェイトを自社で動かす目的（データを外に出さない、モデルを固定する）がないのであれば、APIで使う前提ならこの推奨に沿って汎用モデルを検討するほうが自然です。

無料枠は終わった：いま課金はどの経路で発生するか

Qwen Coderを調べると「無料で使える」という記事に行き当たります。2026年9月時点で、その前提は成立していません。

Qwen Code公式の認証ドキュメントには、次のように記載されています。「Qwen OAuthの無料枠は2026年4月15日に廃止されました。キャッシュ済みのトークンは短期間動作し続ける可能性がありますが、新しいリクエストは拒否されます」。また「Qwen OAuthは選択可能なダイアログ項目ではなくなりました。その無料枠は2026年4月15日に廃止されています」とも書かれています。

検索上位には2025年7〜8月に公開された日本語記事が複数あり、当時の無料枠（1日あたりのリクエスト上限つきの無償利用）を前提に高く評価しています。記事の内容が間違っていたわけではなく、前提が後から変わったという状態です。予算計画をこれらの記事に基づいて立てている場合は、作り直しが必要になります。

無料枠が消えた以上、CLIをどこに繋ぐかの選択が、そのまま費用がどこで発生するかの選択になります。Qwen Code CLIが初回起動の /auth メニューで提示する認証方式は、2026年9月時点で次の3つです。

このうち「Custom Provider」が、自社でモデルをホストして使う場合の入口になります。

ここまではCLI（2つめ）の話です。モデル（1つめ）の側を見ると、オープンウェイトの重み自体は引き続きApache 2.0で自由に取得できるため、推論費用を自社インフラで負担する形であれば、ライセンス料は発生しません。無くなったのはQwenが提供していた無償のホスティングであって、モデルの利用許諾ではない、という整理です。

開発ツールへの接続：サポートされる経路と、されない経路

以下は技術担当が実施する手順です。経営判断としては、ここに出てくるバージョン要件を満たせる担当が社内にいるかどうかだけ確認できれば十分です。

Qwen3-Coderを日常の開発に組み込む方法は複数ありますが、ベンダーがサポートを明言している経路と、そうでない経路があります。ここを区別せずに全社標準を決めると、後で困ります。

基本形：OpenAI互換エンドポイントを自分で立てる

Qwen3-Coder-Nextのモデルカードは、vLLMとSGLangでOpenAI互換のAPIエンドポイントを立てる方法を公式手順として示しています。

vLLM（0.15.0以上が必要）の場合は次のコマンドです。

vllm serve Qwen/Qwen3-Coder-Next \
  --port 8000 \
  --tensor-parallel-size 2 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

SGLang（v0.5.8以上が必要）の場合はこちらです。

python -m sglang.launch_server \
  --model Qwen/Qwen3-Coder-Next \
  --port 30000 \
  --tp-size 2 \
  --tool-call-parser qwen3_coder

いずれも --tool-call-parser qwen3_coder の指定が要点です。READMEには「Qwen3-Coderのfunction callingは、SGLangとvLLMの新しいツールパーサーに依存する」と注意書きがあり、これを省くとツール呼び出しが正しく解釈されません。エージェント用途では致命的なので、必ず付けてください。起動に失敗する場合はコンテキスト長を32,768などへ下げるよう公式が案内しています。

立ち上がったエンドポイント（vLLMなら http://localhost:8000/v1）は、OpenAI SDKからそのまま呼べます。

Qwen Code から使う

Qwen Codeは ~/.qwen/settings.json で接続先を定義します。OpenAI互換プロトコルの環境変数は OPENAI_API_KEY、OPENAI_BASE_URL、OPENAI_MODEL（別名 QWEN_MODEL）です。設定ファイルは次の構造を取ります。

{
  "modelProviders": {
    "openai": [
      {
        "id": "Qwen3-Coder-Next",
        "name": "self-hosted Qwen3-Coder-Next",
        "baseUrl": "http://localhost:8000/v1",
        "envKey": "OPENAI_API_KEY"
      }
    ]
  },
  "security": { "auth": { "selectedType": "openai" } },
  "model": { "name": "Qwen3-Coder-Next" }
}

セキュリティ上の注意が公式ドキュメントに明記されています。「settings.json の env フィールドを使う場合、認証情報は平文で保存されます」。APIキーは env に直書きせず、シェルの export か .env ファイルを使ってください。設定ファイルをリポジトリにコミットしてしまう事故は、この構造だと起きやすいところです。

Cline から使う

コーディングエージェントのClineは、ローカル実行（Ollama、LM Studio、Atomic Chat）とOpenAI Compatibleプロバイダの両方を公式にサポートしています。Alibaba Qwen専用のプロバイダ設定ページも用意されています。ローカルのOllamaで qwen3-coder:30b を動かし、Clineから接続する構成は、ベンダー双方がサポートを明示している経路です。

Claude Code から使う構成はサポート対象外

Qwen3-Coder-Nextのモデルカードには「256Kのコンテキスト長と多様なスキャフォールドテンプレートへの適応性により、さまざまなCLI/IDEプラットフォーム（Claude Code、Qwen Code、Qoder、Kilo、Trae、Clineなど）とのシームレスな統合が可能」と書かれています。この記述を根拠に、Claude CodeでQwen3-Coderを動かす手順を紹介する記事が国内にもあります。

一方、Anthropicの公式ドキュメントには次の一文があります。「Anthropicはサードパーティ製ゲートウェイ製品を推奨・保守・監査しておらず、いかなるゲートウェイ経由であっても、Claude Codeを非Claudeモデルにルーティングすることをサポートしていません」。

技術的には、Claude Codeは ANTHROPIC_BASE_URL で接続先を、ANTHROPIC_AUTH_TOKEN または ANTHROPIC_API_KEY で認証情報を切り替えられます。この仕組み自体は社内LLMゲートウェイ向けに公式に用意されたものです。ただしその用途は「Claudeモデルへ至る経路を組織で管理すること」であり、別ベンダーのモデルに差し替えることは想定されていません。

つまりモデル提供側とツール提供側で、主張が食い違っています。個人が試す分には各自の判断ですが、企業として全社標準に据えるかは別です。判断材料として、次の点を押さえておいてください。

• 動作不良が起きてもAnthropicのサポートは受けられません。仕様変更でいつ動かなくなっても、それは不具合ではありません。
• 前掲のTerminal-Bench 2.0のとおり、ClaudeCode構成での成績はQwen3-Coder-Nextの最良の外枠より低く出ています（30.9 対 36.2）。相性の面でも最適な組み合わせではありません。
• 同じことをするなら、ベンダー双方がサポートを明示しているClineやQwen Code経由のほうが、運用上の説明がつきます。

日本語のコードは何トークンになるか（自社リポジトリ実測）

日本語で開発している現場では、「コンテキスト256Kは十分か」「階層課金のどこに入るか」がトークン数で決まります。ここは推測ではなく実測しました。

Qwen3-Coder-Next公式のトークナイザ（tokenizer.json、語彙数151,669）をtokenizers 0.23.2で読み込み、当社のNext.jsプロジェクトのソースコードを対象に計測しています（実施日: 2026年9月4日）。公式トークナイザをそのまま読み込んで数えているだけなので、同じ条件で追試できます。計測条件は次のとおりです。

• 対象: src/ 配下の .ts／.tsx と ops/ 配下の .mjs のうち、500バイトを超えるファイル308件
• 日本語の含有率: ひらがな・カタカナ・漢字の文字数で判定
• 区分: 5%超を「日本語が5%超のファイル」、0.5%未満を「日本語がほぼ無いファイル」（両方に入らない112件は内訳表から外れます）

文字種ごとのトークン数

日本語は1文字あたり0.72〜0.92トークン、英字は0.2トークンです。単純比較では日本語のほうが4倍前後のトークンを消費します。

実際のリポジトリで測るとどうなるか

コードは大半がASCIIなので、日本語コメントが混ざっても比率はここまで極端にはなりません。TypeScript・TSX・mjsの308ファイル（合計1,478,418文字）を計測した結果です。

日本語が5%超のファイルは、ほぼ無いファイルに比べて1文字あたり1.26倍（0.310 ÷ 0.247）のトークンを消費します。日本語でコメントや定数を書く方針そのものは変える必要がありませんが、コンテキスト消費と課金額にこの係数が乗ると見込んでおくのが実態に合います。

256Kコンテキストに、リポジトリは入らない

もう1つ、実務的に重い結果が出ました。このリポジトリのソースコードだけで398,593トークンあり、Qwen3-Coder-Nextのネイティブコンテキスト262,144トークンに収まりません。中規模のWebアプリケーション1本ですらこの状態です。

ここから導かれる運用上の帰結は次のとおりです。

• 「リポジトリ全体を読ませて改修させる」使い方は、この規模でも成立しません。関連ファイルを絞って渡す設計（あるいは検索を挟む設計）が前提になります。
• 階層課金との組み合わせに注意が必要です。仮に入力を200,000トークン渡すと128K〜256Kの階層に入り、qwen3-coder-nextでは入力0.8ドル・出力4ドルの単価がそのリクエストの全体に適用されます。32K以内に収めた場合の0.3ドル・1.5ドルと比べ、単価で2.7倍です。
• 逆に、渡す範囲を絞る工夫がそのままコスト削減になります。なお前述のコンテキストキャッシュは qwen3-coder-next では割引が明示されていないため、キャッシュによる単価割引を前提にはできません。渡す量を減らすこと（ツール定義の圧縮を含む）が、階層を押し下げる直接の手段になります。

自社ホスト・API・クラウド型コーディングエージェントのどれを選ぶか

ここまでの一次情報を、採用判断の形に落とします。判断軸の中心は「性能」ではなく、データをどこに置けるかとサポートを誰が持つかです。

自社ホストのQwen3-Coderを選ぶ理由になる条件

次のいずれかに当てはまる場合、Qwen3-Coderの自社ホストは検討に値します。

• 顧客との契約や社内規程で、ソースコードを外部の生成AIサービスに送信できない。これが最も強い理由です。ライセンスが制限条項なしのApache 2.0であることは、この構成を後押しします。
• モデルのバージョンを長期間固定したい。医療・金融・公共系など、検証済みの構成を凍結して運用する必要がある領域です。
• すでにGPUサーバーがあり、稼働率に余裕がある。新規調達を前提にすると、クラウド利用のほうが安く済むケースが多くなります。損益分岐の考え方はクラウドLLMとローカルLLMの費用は、どこで逆転するのかで公式価格から試算しています。

立ち止まって構成を見直したほうがよい条件

次のいずれかに当てはまる場合は、Qwen3-Coderの自社ホスト以外の選択肢も並べて検討してください。

• 「安いから」が主な動機である。長文脈では階層課金で逆転します。かつAlibaba自身が汎用モデルの利用を推奨しています。
• フロントエンド・UI開発が主戦場である。公式が改善余地のある領域として明示しています。
• 手元にあるのが24GBのGPU 1枚である。Qwen3-Coder-Nextは動きません。30B版から始めるか、構成を見直してください。
• 全社標準としてClaude Codeに接続して使いたい。Anthropicのサポート対象外です。

導入前チェックリスト

稟議・社内検討にそのまま転用できる形で整理しました。

目的と前提

• 外部の生成AIサービスにソースコードを送信できない制約が、契約または社内規程に実在するか確認した
• 「安いから」以外の採用理由を1つ以上言語化した
• 対象業務を1つに絞った（全社展開から始めていない）
• 撤退基準を文書化した

モデル選定

• 採用するモデル名とリビジョン（コミットハッシュ）を確定した
• そのモデルがQwen3-Coder-Next／480B／30Bのどれか特定した
• non-thinkingモードのみである点が、想定する使い方と矛盾しないことを確認した
• フロントエンド／UI比重の高い業務でないことを確認した（公式が弱点として明示）

ライセンス

• モデルカードのライセンス宣言を保存した
• LICENSEファイルの有無を確認した（Next系には同梱されていない）
• 社内利用のみか、外部提供・再配布まで行うかを確定した
• 出力の誤りに対する検証工程を業務フローに組み込んだ（Apache 2.0は無保証）

ハードウェアと実行環境（技術担当と確認）

• 配布物の実サイズ（Next＝4bitで48.4〜52GB、30B＝約19GB）を基準に必要メモリを見積もった
• コンテキスト長に応じたKVキャッシュの余裕を上乗せした
• vLLMまたはSGLangのバージョン要件（vllm>=0.15.0 / sglang>=v0.5.8）を満たした
• --tool-call-parser qwen3_coder を指定した

コストと運用

• APIを使う場合、最大リクエストがどの課金階層に入るか試算した
• 対象リポジトリのトークン数を実測し、コンテキストに収まるか確認した
• 接続する開発ツールが、ベンダー双方のサポート範囲に入っているか確認した
• 実際に使うCLI/IDEでの成績（Qwen3-Coder-NextはTerminal-Bench 2.0で最良の外枠と最低の外枠に10.4ポイント差）を確認した
• APIキーを設定ファイルに平文で保存しない運用にした

よくある質問（FAQ）

まとめ

Qwen Coderは、Apache 2.0という扱いやすいライセンスと、アクティブ3Bという効率の良さを持つ、検討に値するモデル群です。ただし2026年9月時点で採用を判断するなら、次の8点は数字で押さえておく必要があります。

1. 名前が3つの別物を指す。モデル群・CLI・クラウドアプリを区別しないと、評判も料金も噛み合いません。
2. ライセンスは制限条項なしのApache 2.0。ただし主力のNextにはLICENSEファイルが同梱されていません。
3. スコアは動かす外枠で最大10.4ポイント動く（Terminal-Bench 2.0、4つの外枠）。単独のベンチ数値だけで判断しないでください。
4. Qwen3-Coder-Nextはコンシューマ向けGPU 1枚では動かない。実配布サイズは4bitで48.4〜52GB（配布元による）。手元で試すなら30B版から始めてください。
5. APIは階層課金。長文脈では単価が上がり、API専用のqwen3-coder-plusは256K超で出力100万トークンあたり60ドル＝Claude Opus 5の25ドルの2倍以上になります。そもそもAPI前提なら、Alibaba自身がQwen-Coderではなく最新の汎用モデルを推奨しています。
6. Qwen Code CLIの無料枠は2026年4月15日に終了。2025年の記事を前提にした予算計画は作り直しが必要です。
7. Claude Codeへの接続はAnthropicのサポート対象外。全社標準にするならClineやQwen Codeを選んでください。
8. 256Kにリポジトリは入らない。当社の中規模アプリで398,593トークン。渡す範囲を絞る設計が前提になります。

採用の可否を分けるのは性能差ではなく、「ソースコードを外部に送信できるか」と「障害時に誰がサポートを持つか」です。ここが決まれば、選択肢は自然に絞られます。