Qwen3.6-Max-PreviewとKimi K2.6がほぼ同時リリース、フラッグシップ級コーディングモデルを並べて比較
目次
中国発の1T級MoEフラッグシップが、4月20日から21日にかけての24時間の中で2本立て続けに出てきた。
AlibabaのQwen3.6-Max-Previewと、Moonshot AIのKimi K2.6。
どちらもコーディングエージェント向けに明確に振ってきたモデルで、ベンチマークも重なりが多く横並びで比較しやすい。せっかくなので1本の記事として整理しておく。
リリースタイミング
両モデルともX（旧Twitter）で告知されたのがほぼ同じタイミングで、告知と同時に正式提供が始まっている。
いわゆる「ウェイトだけ先にHugging Faceに上がっていたのが後から発見される」タイプのサイレント先行公開ではなく、告知＝正式リリースの扱いで見てよい。
| モデル | X告知 (JST) | 正式提供開始 |
|---|---|---|
| Qwen3.6-Max-Preview | 2026-04-20 夜 | Alibaba Cloud DashScope と Qwen Studio Web UI で即時利用可 |
| Kimi K2.6 | 2026-04-21 未明 | Hugging Faceでウェイト公開、kimi.com と platform.moonshot.ai で同時提供 |
Qwen側は、既にQwen3.6-35B-A3Bが4月17日にオープンウェイト公開されていて、その延長でMax-PreviewがAPI専用のクローズド枠として追加された形。
Kimi側は1月末公開のKimi K2.5から約3ヶ月ぶりのメジャー更新で、アーキテクチャはK2.5系を踏襲したまま、RLとAgent Swarmの段数を押し上げてきた構成になる。
結果として、「オープンウェイトで1段下の型が先に出ているQwen」と「フラッグシップをそのままオープンウェイトで出し続けるKimi」という提供戦略の違いが、今回も綺麗に並ぶ形になった。
シリーズ内での位置付け
flowchart LR
Q[Qwen3.6シリーズ] --> Q1[35B-A3B<br/>オープンウェイト<br/>ローカル動作可]
Q --> Q2[Plus<br/>クラウド専用<br/>1Mコンテキスト]
Q --> Q3[Max-Preview<br/>フラッグシップ先行版<br/>API専用]
K[Kimiシリーズ] --> K1[K2.5<br/>1T MoE<br/>ネイティブマルチモーダル]
K1 --> K2[K2.6<br/>コーディング・エージェント<br/>強化版]QwenはMax-Previewをクローズド、35B-A3Bをオープンと2枚使いしており、Plusは別枠の1Mコンテキスト特化モデル。
KimiはK2.6そのものがオープンウェイトで、同じ系譜にクローズド別型がない。フラッグシップをそのままModified MITで配り切っているのが構造的な違い。
基本スペック
諸元レベルで横並びにする。Qwen側は内部アーキテクチャが非公開の項目が多く、そこで情報量に差が出る。
| 項目 | Qwen3.6-Max-Preview | Kimi K2.6 |
|---|---|---|
| 総パラメータ | 1T超（正確な数は非公開） | 1T |
| 1トークンあたりアクティブ | 非公開 | 32B |
| アーキテクチャ | Sparse MoE（詳細非公開） | MLA + SwiGLU、61レイヤー、384 + 共有1エキスパート、Top-K 8 |
| コンテキスト長 | 262,144（256K） | 262,144（256K） |
| 最大出力トークン | 8,192 | 長時間ステップ前提で上限は実運用側に寄せる |
| モダリティ | テキストのみ | テキスト中心（K2.5系列のマルチモーダル基盤を継承） |
| 量子化 | 非公開 | ネイティブINT4（QAT） |
| ライセンス | クローズドソース、API専用 | Modified MIT（ウェイト配布あり） |
| 語彙サイズ | 非公開 | 160K |
コンテキスト長は奇しくも両者256Kで完全一致。
Qwen3.6-Max-PreviewはPlus（1M）と比べると短めに設定されていて、推論メモリ予算とコストのバランスを優先した調整に見える。
Kimi K2.6はINT4 QATを前提にしている分、1T MoEのままでも手元に降ろしやすい側に振ってあるのが大きい。
ベンチマーク
両モデルで同名のベンチマークを拾える範囲でまとめる。数値はそれぞれの公式発表とArtificial Analysisから拾ったもので、評価条件（プロンプト、ツール構成、試行回数）は揃っていない点は注意。
| ベンチマーク | Qwen3.6-Max-Preview | Kimi K2.6 | 参考: Kimi K2.5 | 参考: Qwen3.6-35B-A3B |
|---|---|---|---|---|
| SWE-Bench Pro | 57.30 | 58.6 | 50.7 | 49.5 |
| Terminal-Bench 2.0 | 65.40 | 66.7 | 50.8 | 51.5 |
| GDPval-AA | 51.0 | — | — | — |
| AA Intelligence Index | 52.0 | — | — | — |
| HLE Full（ツールあり） | — | 54.0 | 50.2 | — |
| BrowseComp | — | 83.2 | 74.9 | — |
| Toolathlon | — | 50.0 | 27.8 | — |
| SWE-Bench Multilingual | — | 76.7 | 73.0 | — |
| MathVision（python併用） | — | 93.2 | 85.0 | — |
SWE-Bench ProとTerminal-Bench 2.0の2軸で見ると、Kimi K2.6がQwen3.6-Max-Previewをわずかに上回る位置にある。
どちらもK2.5世代から10ポイント前後の跳ね上がりを見せていて、「エージェント型コーディングに効くRL」が両陣営で同時に効いてきているのが読み取れる。
一方でQwen側はAA Intelligence Indexでの総合評価（201モデル中2位）が強く、Kimi側はBrowseCompやToolathlonのようなツール駆動・Web自律系で頭1つ抜けている傾向。汎用的な知能総合値 vs エージェント特化スコア、という得意分野の違いとして見ておくとわかりやすい。
ただしArtificial Analysisの計測では、Qwen3.6-Max-Previewは評価タスクの生成量が平均26Mトークンに対し約74Mトークンと 3倍近い冗長さ を示した。
コーディングエージェントのように手順を逐次書き出すタスクでは冗長性が有利に働く場面もあるが、一般チャット用途では max_tokens やシステムプロンプトで出力を締めにかからないとコストが膨らみやすい。
エージェント関連機能
両者ともコーディングエージェントに軸足を置いているが、推す方向性は少しずれている。
Qwen3.6-Max-Preview側
- Qwen3.6-Plusを上回るエージェント型コーディング能力を明示的にハイライト
- 実世界エージェントと知識信頼性の向上を訴求
- 実装としてはDashScopeのOpenAI互換エンドポイントにそのまま流せる（DashScope API実装ノートに最小構成を寄せた）
- Qwen-Agent経由でMCPサーバーと束ねる使い方は35B-A3Bと同じパターンで組める
Kimi K2.6側
- Agent Swarmのスケール上限を 100×1,500ステップ → 300×4,000ステップ に拡張
- 300並列サブエージェントが1つのオーケストレーターの下で協調実行する前提で作ってある
- 1ミッションを12時間・4,000ツールコール連続で走らせる長時間コーディングの事例（Qwen3.5-0.8BのMac最適化タスク、exchange-coreの最適化）を公式で提示
- WebGL・GSAP・Framer Motion・Three.jsなど、動きのあるフロントエンド生成を強化
- 外部ランタイムとして OpenClaw / Hermes Agent を名指しで連携先に挙げ、「プロアクティブエージェント」を前提化
- Claw Groupsとして、自分のエージェントと他人のエージェントを同じループに入れるマルチオーナーシップ機能をリサーチプレビュー提供
Qwen側は「API経由でまともに強いフラッグシップを呼べる」ことを優先していて、実行ランタイム側はユーザー任せ。
Kimi側は「モデル + ランタイム + マルチエージェント前提のUX」までセットで押し込んでくる構成になっている。
ここはMoonshot AIがKimi LinearでのAttnRes研究、CursorがComposer 2でK2.5を採用した件、と着実にハーネス側の足回りを作ってきた流れの延長でもある。
料金と提供形態
触る側のコスト感はかなり違う。
| 区分 | Qwen3.6-Max-Preview | Kimi K2.6 |
|---|---|---|
| 提供形態 | API専用（DashScope）、Web UIあり | ウェイト配布 + API（platform.moonshot.ai、OpenAI/Anthropic互換） |
| 入力料金 | $6 / 1M トークン（DataLearner集計） | 公式ページ参照（K2.5系の価格帯を踏襲） |
| 出力料金 | $24 / 1M トークン（同上） | 同上 |
| プレビュー無料枠 | Artificial Analysisでは $0.00 と記録されており、期間中は無料枠の可能性 | ウェイトを手元に降ろせばAPI料金は発生しない |
| ローカル推論 | 不可 | vLLM / SGLang / KTransformers 等で可能（transformers 4.57.1以上・5.x未満） |
Qwen3.6-Max-Previewは「フラッグシップ級をOpenAI互換APIでそのまま叩ける」手軽さが売りで、差し替えコストが低い代わりにコストは従量・冗長傾向込みで膨らみやすい。
Kimi K2.6はウェイトを手元に降ろせるので、自前のGPU資産があればAPIコストゼロでフラッグシップを回せる。代わりに1T MoEをまともに動かす推論基盤を用意するコストは相応にかかる。
触る前に把握しておきたい点
両モデル共通で、プレビュー / 初期リリース段階ゆえの注意がいくつかある。
- Qwen3.6-Max-Previewはテキスト専用で、マルチモーダル入力はQwen3-Omni側を使う
- Qwen3.6-Max-Previewの出力上限は8Kなので、長文生成はストリーミング + 継続プロンプトでの分割設計が前提
- Qwen3.6-Max-Previewはモデル名・料金・コンテキスト長が正式版までに変わる可能性がある
- Kimi K2.6を本気で回す場合、Agent Swarmの300並列 × 4,000ステップは権限・課金・セキュリティ設計が破綻しやすい規模感。特に外部ランタイム（OpenClawなど）と組み合わせる場合は、サブスク枠からサードパーティハーネスを締め出した流れと同じ論点が、そのまま課金・監査側に跳ね返ってくる
- Kimi K2.6のMITベースのウェイト配布は、ライセンス上は取り回しやすいが、本番投入時はOpenAI/Anthropic互換APIの契約条項側で差が出ることがある
Qwen側の「オープン全振り」から2枚使いへの舵切り
Qwen3世代はそもそも、Qwen3-Coder-Next・Qwen3-Omni・Qwen3.6-35B-A3Bと、エージェント用途のフラッグシップ寄りモデルまでApache 2.0のオープンウェイトで配り切る路線で走ってきた系譜だ。
「上から下までとにかくオープン」という立て付けが、Qwenブランドの中核的な説明力になっていた時期でもある。
今回のQwen3.6-Max-Previewは、その路線から最上位の1枚だけを抜き出してAPI専用のクローズド枠に置き直した形になる。
オープンウェイト側は35B-A3Bで維持しつつ、フラッグシップは手元に降ろせないクラウド専用品に寄せる2枚使いで、MistralやCohereが辿った「頭はクローズド、裾野はオープン」に近い整理と見ておくのが自然だ。
Max-Previewで内部アーキテクチャ（総パラメータ・アクティブ数・MoE構成・量子化）がいっさい非公開になっているのも、この舵の切り方と噛み合っている。
整理するとこう並ぶ。
| シリーズ | 最上位の扱い | 中位〜下位の扱い |
|---|---|---|
| Qwen3.6 | Max-Previewはクローズド（DashScope API専用、アーキテクチャ非公開） | 35B-A3BはApache 2.0でオープン、Plusは1M特化のクラウド枠 |
| Kimi K2 系 | K2.6そのものがModified MITでオープンウェイト、アーキテクチャも開示 | 下位モデル自体を持たず、フラッグシップ1本で両立 |
Kimi側はこの流れに対して 真逆に振ってきている のが今回のリリースの肝になる。
1T MoEのフラッグシップをそのままHugging Faceに置き、ネイティブINT4 QATまで噛ませて「手元で動かす前提」を崩していない。
ランタイム側もKimi CLIやAgent Swarm、さらにOpenClaw / Hermes Agentとの連携とセットで提示しており、「モデル + ハーネス + 運用」をフルスタックでオープン寄りに寄せ切る戦略だ。
同じ中国発1T級MoEが、フラッグシップの公開レイヤーで正反対に振れているのが今回の2本立てリリースの地味に大事なところ。
Qwenがオープンウェイトのラベルを「コスト重視の中位モデル」側に寄せていくなら、エージェント実装の主役（特にローカル・オンプレ側の期待値）はKimi側に段々傾いていく可能性が高い。
逆にMax-Previewの料金とレート制限が安定運用されていけば、「クラウドから叩くのはQwen、オンプレで長時間回すのはKimi」という住み分けに落ち着いていくのかもしれない。
背景にありそうなQwenチーム側の内部事情
Max-PreviewをクローズドAPIに寄せた今回の判断は、モデル単体の話だけでは説明しきれない部分がある。
SNSや中国語圏の解説記事を拾っていく範囲でも、2026年初頭以降、Qwenチーム周辺でいくつかの動きが観測されている。
- Qwenの主要開発者の一部が、別プロジェクトへの異動・独立・他社移籍に動いているという観測が断続的に流れている
- Alibaba Cloud側の事業方針として、研究寄りの全方位オープン化路線から、生成AI事業を明確に収益フェーズに入れる方向にギアを切り替える動きが強まっている、という観測も複数のSNS投稿・まとめで見かける
- 内部でオープン派と収益重視派の温度差が広がっている、という話も断続的に出ているが、公式発表や信頼度の高い一次情報は確認できていない
ここは噂ベースの情報を重ねた話なので、確度は落とした状態で受け取るのが無難だ。
一方で「最上位フラッグシップを急にクローズドAPI専用に切り直す」「内部アーキテクチャや量子化情報まで全部伏せる」という今回の思い切った判断は、こうした内部事情と経営方針の転換を仮定すると、動きとしては辻褄が合う側面がある。
オープンウェイトを取り続けるKimiとの対比がここまで綺麗に出てきている背景には、中国発LLM事業を「どこで稼ぐか」の設計に各社が本腰を入れ始めたタイミングもあるのかもしれない。
真偽含めて一次情報の追い方は別途必要になるが、Max-Preview単品のスペック比較だけで読み切らず、Qwenブランドの公開戦略が踊り場に入っている可能性は頭の片隅に置いておきたい。
SWE-Bench ProとTerminal-Bench 2.0のレンジはほぼ並んでいて、数値だけ見れば好みで選べる段階に入っている。
ここから先はどのハーネスに載せて、誰の権限と課金で、どれだけの時間動かし続けるかという運用側の勝負になりそうだ。