Qwen3.6-Max-Preview: エージェント型コーディングと世界知識が強化された次世代モデル

• Qwen3.6-Plusの後継として、前作比でエージェント型コーディング、より強力な世界知識、指示追従性能が向上
• 6つの主要コーディングベンチマークで最高スコアを記録し、コーディングエージェント性能の大幅な向上を確認
• preserve_thinking機能をサポートし、エージェント型タスク時に前ターンの思考過程をメッセージに保持する方式を使用
• 世界知識ベンチマークではSuperGPQA +2.3、QwenChineseBench +5.3など改善され、指示追従ではToolcallFormatIFBench +2.8を記録
• Qwen Studioで対話型テストが可能で、Alibaba Cloud Model Studio APIを通じてqwen3.6-max-previewとして呼び出し予定

---

主な改善点

• Qwen3.6-Plus比でエージェント型コーディング能力が大幅に向上: SkillsBench +9.9, SciCode +6.3, NL2Repo +5.0, Terminal-Bench 2.0 +3.8
• **世界知識(world knowledge)**を強化: SuperGPQA +2.3, QwenChineseBench +5.3
• **指示追従(instruction following)**を改善: ToolcallFormatIFBench +2.8
• 6つの主要コーディングベンチマークで最高スコアを達成: SWE-bench Pro, Terminal-Bench 2.0, SkillsBench, QwenClawBench, QwenWebBench, SciCode

モデルの特徴とアプローチ

• Alibaba Cloud Model Studioを通じて提供されるホスティング専用モデル
• 実世界エージェント(real-world agent)および**知識信頼性(knowledge reliability)**の性能向上
• Qwen Studioですぐに対話型テストが可能
• APIモデル名はqwen3.6-max-previewで、Alibaba Cloud Model Studio APIで近日利用可能

API利用と機能

• OpenAI互換のchat completionsおよびresponses API、Anthropic互換インターフェースなど業界標準プロトコルをサポート
• preserve_thinking機能により、前ターンの**推論過程(reasoning content)**を保持でき、エージェント型タスクに推奨
• enable_thinking: True設定時、推論内容と応答をストリーミング方式で分離して受信可能
• APIの地域別Base URLを提供: 北京、シンガポール、米国(バージニア)

開発状況

• 現在はプレビューリリース段階で継続的に反復改善中であり、今後のバージョンで追加改善を予定

[GN⁺]

Hacker Newsの意見

• みんながSOTA比較にばかり執着しているのは、ちょっと滑稽に感じる。自分は glm 5.1 が Opus にはできなかったことをやってのけた場面を見たし、コードもよりうまく書くのを経験した。qwen max はまだ使っていないが、ローカルの 122b モデルが文書をよりよく読み、より正確に処理する様子も見た。結局、ベンチマークは一部にすぎず、実際にはモデルごとに強みが違うのだから、ハンマーとレンチを単純な優劣で比べるように語るべきではないと思う

  • 個人プロジェクトでは Ollama Cloud の pi.dev で GLM-5.1 を使っていて、かなり満足している。会社では pi.dev と Claude Sonnet、Opus 4.6 を併用している。Claude Code も良いが、最近のアップデート以降 compact を頻繁にしなければならず不便だった。pi.dev を使うときは MCP tool calling がなくても API 連携がうまくいくので、不満はなかった。むしろ Web サイト制作は GLM-5.1 のほうが Claude Opus より上手いと感じたし、今作っているフルスタック開発プラットフォームでも非常によく働いてくれている
  • GLM 5.1 は、中国モデルが本当に追いついたと初めて感じさせてくれたモデルだった。だから Claude Max の購読も解約したし、正直まったく惜しくなかった。人によって意見が分かれるのを見ると、もう絶対的な SOTA の優劣よりも、ドメインと利用パターンの違いのほうが重要な段階に来たように思う
  • 自分が Claude と ChatGPT を使い続けるほぼ唯一の理由は tool calling だ。skills のような便利な機能もあるし。qwen や deepseek も使ってみたが、文書出力すらうまくいかないことがあった。みんなこうしたツールで文書や Excel をどう処理しているのか気になるし、できるなら自分も乗り換えたい
  • 数か月前には Qwen3-Coder が Claude Opus や Google Gemini よりはるかに良い Rust コードを生成してくれた。特に Rust の x86-64 ベクトル拡張まで活用するコードを出してきて印象的だった。自分は Zed editor や trae CLI のような harness から呼び出して使っていたが、本当にかなり驚かされた
  • モデルはベンチマークの点数が概ね似通っていて差も小さいので、こういう状況なら別の基準で選ぶのが合理的だと思う。自分の場合は JetBrains プラグイン さえまともなら、どのベンダーにでもすぐ移るつもりがある

• 会社でここ数か月ずっと Claude Code を使っていて、少し前には小さな個人 Web サイトのプロジェクトにも活用した。先週末には初めて self-hosting も試してみた。同じように CC や Codex を十分使ったうえで、ある程度満足できる自前ホスティング構成を見つけた人がいるのか気になる。自分は 32GB DDR5、AMD 7800X3D、RTX 4090、Windows と WSL 環境で ollama、docker desktop model runner、pi-coding-agent、opencode と Gemma 4、Qwen、GLM-5.1 の組み合わせをあれこれ試した。基本の RAM 使用量がすでに高く、Gemma4-31B のような良いモデルは動かせなかった。Windows 単独環境ではファイルパス処理がたびたびおかしくなり、WSL で pi や opencode を動かし、モデルは docker desktop で駆動する方式はある程度うまくいった。ただ、実際の体感性能は CC に比べて遅すぎたし、ツールの完成度も CC harness のほうがずっと高く感じた。設定に時間をかけすぎて実際の利用は長くできなかったが、それでも面白い実験ではあった

  • MoE モデルを使って、推論を CPU にオフロードしてみるといい。Gemma 4 26b-a4b や qwen3.6 35b-a3b のようなモデルが例だ。32GB RAM はほかのアプリも立ち上げると少し窮屈だが、システム RAM が十分ならかなりよく動く。GPU に一部のレイヤーを載せる方法もあるが、MoE モデルと llama.cpp の組み合わせでは問題があった。その代わり KV cache を GPU に置くと速度がかなり出て、コンテキストウィンドウも適度に維持できた。自分はローカルで非常に印象的な結果を見た。また、WSL2 で llama.cpp を直接 clone して、Claude Code のような frontier モデルにインストールとチューニングを任せることを強く勧める。llama.cpp の上に載ったアプリはオプションやフラグをすべて公開していないので、フラグを 1 つ間違えるだけでコンテキストキャッシュが効かず、性能が大きく損なわれることがある。ソースから直接ビルドすれば、問題が起きたときに実際のコードをすぐ確認できる。そのマシンなら Gemma 4 で少なくとも 20〜40tok/s 程度は出るはずで、十分に実用可能だと思うし、qwen3.6 は有効パラメータが 3b なのでさらに速いかもしれない
  • 今起きている問題は、おそらく VRAM 不足 のためにモデル全体を一度に載せられないことから来ているように思う。llmfit も一度試してみる価値がある

• この分野は、まず無料で配って名前を広めて、あとで全部 proprietary に変えていく流れのように見えて心配だ。それでも open weights は出続けてほしい。誰も open weights を出さなくなる日が来たら本当にやるせないと思う。そんな世界になれば、普通の人が自分のcomputeを直接所有するのはもっと難しくなりそうだ

  • それは少し行き過ぎた一般化だと思う。米国のモデルは最初から閉じていたケースが多かったし、逆に米国外のモデル、特に中国モデルは当初からよりオープンだった。むしろ中国側では最初は proprietary だったものが、あとから公開へ転じた例もあり、大きな Qwen モデルにもそういうケースがあった
  • 自分にはこれが国家戦略レベルの動きに見える。競争力のある無料モデルを継続的に公開して、西側企業が proprietary モデルで築こうとしているmoatを弱めようとする流れのようだ。中国に有利な物語が維持される限り、完全に proprietary に戻る可能性は低いと思う
  • チップメーカーの立場でも、私たちがローカルモデルを回せる環境が保たれるほうが利益になるはずだ
  • そうだね。中国の研究所にとってオープンソースは一種の商業戦略だと思う。モデルや推論サービスを知らせるほかの効果的なマーケティング手段が乏しいから、そうした選択をしている面がある。関連文章も参考になる
  • もともと似た構造だったように感じる。結局これもSaaSに近く、違うのは最近の frontier lab の最下位サブスクリプションが実質的に無料体験のように見える、という程度だ

• 今日 Kimi K2.6 も一緒に出たので、両者を比べるのはかなり自然だと思う。価格だけ見ても Qwen は入力 1.3 ドル、出力 7.8 ドルなのに対し、Kimi は入力 0.95 ドル、出力 4 ドルなので Qwen のほうが高く見える。発表記事で重なっているベンチマークも 2 つしかないが、SWE-Bench Pro と Terminal-Bench 2.0 のどちらでも Kimi が Qwen をやや上回っていた。もちろんモデルごとに強みが違い、ベンチマークがすべてではないが、数字だけを基準にすれば Kimi のほうが魅力的に感じられる

  • 中国モデルの価格が上がってきて、魅力が少し薄れたと感じる。それに Gemma-4 が出てからは、パレートフロンティアに残るモデルも多くないと思う。自分の体感も近いし、arena リーダーボード の統計も参考になる

• この発表の皮肉は、名前そのものにあるように思う。Max-Preview は proprietary で cloud-only だ。自分から見ると、本当に重要な Qwen は人々が自分のハードウェアで回している open weights のシリーズだ。自分は dual A4000 で 32B と 72B をローカルで動かしている。hosted Max との差はまだあるが、リリースのたびにその差が縮まっているのがわかる。だから本当に興味深い問いは、Max が Opus とどう比べられるかではなく、open-weight tier がいつごろ大半のワークロードで cloud tier を無意味にするのか、という点だ

• みんなが SOTA ばかり追いかけている間、自分は MiniMax M2.5 で並列セッションをいくつも回しながら、月 10 ドルでコーディング作業を全部こなしていて、制限にもほとんど引っかかっていない

  • 真面目な業務なら、月 10 ドルと 100 ドルの差は大半のプロの開発者にとって大きく悩むほどではないと思う。学生や低所得国のユーザーのような例外はあるにしても、高年収の開発者がツール費用を過度に節約しようとするのを見るといつも不思議だ。今の SOTA モデルですら一回限りの作業以上では完全には信頼しにくいと感じるのに、そこからさらに性能の低いモデルを監視しながら月 10〜100 ドルを節約するのは、まったく魅力的ではない。self-hosted モデルは軽くて捨ててもいい仕事では楽しく実験しているが、実際に重要な業務では自分の時間を無駄にしたくない
  • その月 10 ドルはどこに払っているのか気になる。OpenRouter なのか聞きたい
  • それを実際にどう使っているのか気になる。opencode を使っているのか、それとも別のフロントエンドなのか知りたい

• 自分は Qwen の context caching ドキュメント も見て、Opus、Codex、Qwen を一緒に試したが、Qwen が多くのコーディング作業で強いのは確かだと感じた。ただ、自分がいちばん気にしているのは 長時間セッション での振る舞いだ。Qwen は大きなコンテキストウィンドウを売りにしているが、実際の長文脈効率は context caching の方式に大きく左右されるように思う。公式ドキュメントでは implicit、explicit caching の両方を提供しているが、TTL は数分レベルと短く、prefix ベースの一致や最小トークン条件のような制約がある。こうした制約のため、コーディングエージェントのように文脈が継続的に膨らむワークフローでは、キャッシュの再利用が期待ほどうまくいかないことがある。だからトークン単価は低く見えても、長いセッションでは cache hit rate が下がって再計算が増え、体感コストが高く感じられることがある。それでもセキュリティ関連の作業では、個人的に Qwen が Opus よりうまくやった場合もあった。自分の経験では、Qwen は個々のメソッドや関数単位のような短い作業では Opus よりはるかに優れているが、全体的なコーディング体験としては Claude のような自律的な end-to-end コーディングアシスタントというより、関数単位のジェネレーターに近く感じられた

  • それでも長いセッションを短く区切って新しく始めるのが best practice なのは確かだと思う。Anthropic の Claude Code Best Practices でも、「より良いプロンプトを持つクリーンな新しいセッションは、修正が積み重なった長いセッションよりほぼ常に優れている」と案内している
  • 最後に確認した時点では、context caching はコストとレイテンシを下げるだけで、実際にどのトークンが出力されるかは変えなかった

• Qwen 側が Opus 4.5 と比較しているのを見ると、それを善意で受け取るのは少し難しい。Opus 4.7 が最新すぎて外れたのは理解できるとしても、Opus 4.6 は出てからかなり経っているからだ

  • 自分にとって Opus 4.5 は、さまざまな問題でモデルが十分に使えると感じられた最初の地点だった。それ以前は、開発作業に AI を使うと必ず幻覚のせいで時間を余計に取られ、生産的な選択ではなかった。だが、もし進歩が Opus 4.5 で止まっていたとしても、私たちはすでに非常に多くの実務作業を素早く処理できていたはずだと思う。ソフトウェア開発が再びすべて手書き中心に戻ることはもうないだろう。だから Opus 4.5 に近いか、少し良い程度の水準を 10 分の 1 の価格で提供するなら、多くの人にとって十分魅力的だろう。もちろん西側の開発者にとっては、Opus 4.7 に月 100 ドル以上払うことにも大きな価値がある。低い等級のモデルが浪費させる時間のほうがはるかに高くつくからだ。当面は、より時間を無駄にさせず、より少ないプロンプト修正でより良い結果を出すモデルにプレミアムを払い続けるつもりだ。同時に、変化の速さには本当に驚かされるし、最近ではオープンモデルも 2 年前の frontier モデルと競える水準にまで来たと感じる。Qwen 3.6 MoE 35B A3B や大きな Gemma 4 モデルは、高性能な Macbook、Strix Halo、最近の 24GB や 32GB GPU 程度の普通の機材でも動かせるし、pre-AI 時代の開発者向けノート PC より極端に高いわけでもない。コードも書けるし、文章もかなりうまく書けるし、ツールも使え、文脈長も実務には十分だ。まだ Opus 4.5 ほどではないが、かなり印象的だ。自分もセキュリティとコードレビューにはすでに複数のモデルを組み合わせて使っており、大半のソフトウェア開発では依然として Claude Code と Opus が最高だと感じているが、Qwen も喜んで試すつもりだ。小型モデルもサイズの割に非常によくできているので、大型モデルにも期待している
  • お金がまったく問題でないなら、結局は Codex 5.4 や Opus 4.7 のような最高性能だけを見ればいいと思う。でも多くの人にとっては、コストに対する品質が非常に大きな変数だ。Claude の契約者の中にも、コストと使用量の制約のために Opus 4.7 を常用できず、Sonnet や以前の Opus を使っている人が多い。だから価値に対する品質の曲線を見るなら、こうした比較にも十分意味があると思う
  • ここ数か月、Opus 4.6 の性能があまりにもばらついていたので、わざわざトークンを無駄にしたくなかった
  • Sonnet 4.6 が出たとき、自分はデフォルトモデルを Opus から Sonnet に切り替えた。体感では Sonnet 4.6 が Opus 4.5 級 に近かったからだ。4.6 と 4.7 のほうがより良いのは確かだが、ほとんどの作業では飛躍幅が大きくないので、いまやコスト削減は十分に合理的な選択になった。もっと安いモデルがその水準に到達すればさらに大きいし、GLM 5.1 もかなり近く見えるのでよく使っている。そういう観点では Opus 4.5 との比較も妥当だと思う
  • 比較は最も近い対象同士で行うべきだと思う。そしてベンチマークを提供元が自分で出すなら、当然ながら自社モデルが強いフレームワークだけを選び、不利なものは外す可能性が高い。だから結局信頼できるのは独立ベンチマークだと思う

• 最近の中国プロバイダーを見ていると、パターンがあるように感じる。ひとつはモデルを closed source のままにしておく方向へ向かっていること、もうひとつは価格をかなり大きく引き上げていることだ。場合によっては 100% 近く上がることもある

  • それをまるで中国企業だけの特徴のように言うのは少し変に聞こえる。ほかの国の企業もまったく変わらないと思う
  • Qwen max はもともと cloud only だったし、1T を超えるモデルなのでコストが高いのは当然だと思う
  • 価格を大きく上げるという点で、米国企業と何が違うのか逆に聞きたい
  • その話が GLM 5.1、DeepSeek V3.2、今出たばかりの Kimi K2.6 のようなモデルにも当てはまるのか聞きたい。実際にはそうした事例にはあまり当てはまらないように見えた
  • そのやり方は 米国企業も本当に大好きではないか、という反応が先に出る

• 面白いのは、ローカル実行できる Qwen モデル群については一通り知っていても、クラウドモデル側はまったく知らないということがあり得る点だ。自分は 3.5 系列と 3.6 を 1 つ知っているくらいで、Plus という名前は今回初めて見た

  • 記憶が正しければ、Plus シリーズは Qwen chat が公開された時からあったはずだ。少なくとも去年の初めには Plus モデルを直接使った記憶がある