Qwen3とは｜Dense/MoEの二層構造・Thinkingモード切替と性能を実務目線で解説

Qwen3にはどんなモデル（サイズ・種類）があり、ローカルで動かすにはどれを選べばよいか

Qwen3はAlibaba（Qwenチーム）が2025年に公開したオープンウェイトLLMで、系列は「Denseモデル（0.6B・1.7B・4B・8B・14B・32B）」と「MoEモデル（Qwen3-30B-A3B、Qwen3-235B-A22B）」の二層構造です。いずれもApache 2.0ライセンスで公開されており、GGUF版（llama.cpp / Ollama等）を使えばローカルGPUで量子化実行できます。手元のVRAMに収まる最大サイズを選ぶのが基本方針です。

• Dense系の選び方（用途で分ける）：試作・軽量チャットは8B、日本語の要約・分類など実務精度を求めるなら14B〜32Bが目安。Q4_K_M量子化での必要VRAMは概ね「8B≈6〜8GB／14B≈10〜12GB／32B≈20〜24GB」程度で、文脈長を伸ばすほどKVキャッシュ分が上乗せされます（正確な値は動作環境で要検証）。
• MoE系の位置づけ：Qwen3-30B-A3Bは総パラメータ30Bのうち推論時に約3Bだけを活性化するため、生成が速い一方で重み自体はメモリに載せる必要があります。より大規模な用途にはQwen3-235B-A22Bが用意されています。
• 共通の要点：Qwen3は思考の深さを切り替えるハイブリッド思考（Thinking／Non-thinking）を備えます。API利用時の正確なトークン単価や最新モデル名（Flash／Plus系など）は改定されやすいため、導入前にAlibaba Cloud（Model Studio）等の公式料金ページで必ず確認してください。

実務者の視点――機密データ前提でオープンウェイトLLMを選ぶときに私たちが見る点

クリスタルメソッドでは、外部にデータを出せない機密性の高い業務向けにローカル／オンプレミス環境でのLLM運用と、実在企業の実データを用いたRAG（検索拡張生成）の構築・運用を継続的に手がけています。その実務経験から、Qwen3のようなApache 2.0系のオープンウェイトLLMを候補に据えるとき、ベンチマーク値そのものよりも先に確認しているのは次の観点です。第一に手元のGPUに収まる活性パラメータ規模と量子化の余地で、同一VRAM予算ならDense上位より活性22B相当のMoEのほうが知識容量を確保しやすい局面があります。第二にfunction callingと構造化（JSON）出力の安定性で、RAGやツール連携では単発の精度より「壊れた出力を返さない再現性」が運用コストを左右します。第三に自社の業務コーパスと評価データで独立検証してから採否を決めるという手順で、公開ベンチマークの序列は自社タスクの序列と一致しないことが少なくありません。特に機密データ用途では、重みをダウンロードして閉域で完結できるオープンウェイトであること自体が、規制対応・情報統制の面で本質的な前提条件になります。

Qwen3とは何か――開発背景とモデル系列の二層構造

Alibaba Cloud の Qwen チームが2025年に公開したQwen3は、オープンウェイト大規模言語モデル（LLM）の研究・実務両面において注目すべき位置を占める。前世代 Qwen2.5 が約18兆トークンで事前学習されていたのに対し、Qwen3 は約36兆トークンに倍増した。対応言語は29言語から119言語へ拡張され、アーキテクチャ面では Dense（密結合）と MoE（Mixture-of-Experts）という二系統が初めて同時導入された（出典：Qwen3 公式ブログ、2026-06-08 確認）。

Qwen3 の提供形態は、大きく二層に分かれる。

• オープンウェイト（Apache 2.0）――Qwen3 Dense 系・MoE 系・Qwen3-Coder・Qwen3-VL など。HuggingFace から無料ダウンロード・商用利用が可能（HuggingFace Qwen3 コレクション、2026-06-08 確認）。
• クローズド旗艦 API（重み非公開）――qwen3-max（1兆パラメータ超 MoE）は Alibaba Cloud Model Studio（DashScope API）経由でのみ提供。HuggingFace からダウンロードはできない点に注意が必要である。バランス型の qwen3.5-plus・軽量高速の qwen3.5-flash も同 API に併設されている。

この二層構造を正確に把握した上で用途を選定することが、Qwen3 活用の出発点となる。Qwen2.5・Qwen2 はレガシー世代であり、新規プロジェクトでは Qwen3 系への移行が公式推奨とされている。マルチモーダル周辺技術の体系についてはマルチモーダルAI解説記事を、LLM の基盤となるディープラーニングの原理についてはディープラーニング基礎解説をあわせて参照されたい。

Qwen3 のアーキテクチャ――Dense/MoE の選択原理と Thinking モードの設計

Dense モデルと MoE モデル：何が違うのか

Dense モデルは全パラメータを推論のたびに使用する従来型の構造であり、Qwen3 では 0.6B から 32B までの6サイズが用意される。MoE モデルは、入力ごとにパラメータの一部（Expert）のみを活性化するスパースアーキテクチャを採用する。スパースモデリングの理論的背景についてはスパースモデリング解説記事が参考になる。

Qwen3-235B-A22B の場合、総パラメータは 235B だが推論時の活性パラメータは 22B 相当となる。すなわち235B 規模の知識容量を、22B 相当の計算コストで引き出せるというのが MoE の本質的な優位性である。同様に Qwen3-30B-A3B は総 30B / 活性 3B という構成をとる。MoE は VRAM 効率の観点から、大規模な知識を限られたハードウェア上で扱う場合に特に有効となる。

モデル名	アーキテクチャ	総パラメータ	活性パラメータ	主な適用場面
Qwen3-0.6B	Dense	0.6B	0.6B	エッジ・IoT
Qwen3-1.7B	Dense	1.7B	1.7B	モバイル・組込み
Qwen3-4B	Dense	4B	4B	軽量サーバー・低コストクラウド
Qwen3-8B	Dense	8B	8B	汎用（コンシューマー GPU）
Qwen3-14B	Dense	14B	14B	業務システム・ミドルレンジ
Qwen3-32B	Dense	32B	32B	高精度タスク・オンプレミス上位
Qwen3-30B-A3B	MoE	30B	3B	速度重視・コスト最適化
Qwen3-235B-A22B	MoE	235B	22B	オープンウェイト最高精度

出典：Alibaba Cloud Model Studio — Supported Models（2026-06-08 確認）、Qwen3 公式ブログ

Thinking / Non-Thinking モードの切替設計

Qwen3 の技術的な特徴として最も実務的な意味を持つのが、思考（Thinking）モードと非思考（Non-Thinking）モードを同一モデルインスタンス内で動的に切り替えられる設計である。前世代では推論特化モデルと汎用モデルを用途ごとに別々に管理する必要があったが、Qwen3 ではその必要がない。

Thinking モードでは Chain-of-Thought を内部で展開し、段階的仮説検証を経て回答を生成する。数学的証明・複雑なコードデバッグ・多段階推論に適しているが、生成トークン数が増加するため応答時間とコストも上昇する。Non-Thinking モードは即時応答を優先し、チャット・要約・翻訳・コード補完など、スループット重視のタスクに向く。

切替は /think または /no_think コマンド、あるいはシステムプロンプト経由で制御する。エージェント構成においては「計画立案フェーズ＝Thinking モード、ツール呼び出しフェーズ＝Non-Thinking モード」という役割分担が設計として整合しやすく、同一モデル内で制御できるためオーケストレーション構造が単純になるという設計上の利点がある。強化学習との接点については強化学習解説記事も参照されたい。

全 Dense モデルで Grouped Query Attention（GQA）を採用しており、KV キャッシュのメモリ使用量を抑えながら、一部モデルでは最大 128K トークンのコンテキストウィンドウを持つ。長文書処理・大規模コードベース解析・RAG（検索拡張生成）といった実務ユースケースへの適性が高い。機械学習の基礎については機械学習解説記事を参照されたい。

Qwen3 のベンチマーク性能――公式データの読み方と留意点

以下は Qwen3 公式ブログ（qwenlm.github.io/blog/qwen3/）が公表するベンチマーク結果の抜粋である。ベンチマーク数値は測定条件・プロンプト設計・評価時点によって変動するため、傾向の把握に留め、自社タスクでの独立検証を経てから採否を判断することが前提となる。

ベンチマーク	評価対象	Qwen3-235B-A22B	Qwen3-32B	Qwen3-4B
AIME 2024	数学競技問題	85.7	79.7	―
MATH-500	高校〜大学数学	97.4	96.7	―
LiveCodeBench	コーディング（実務問題）	70.7	65.9	―
MMLU-Pro	多分野知識・推論	81.2	79.7	Qwen2.5-72B 相当とされる
GPQA Diamond	博士レベル科学問題	71.1	68.4	―
MultiIF	多言語指示追従	77.0	71.5	―

注目すべき点が二つある。第一に、Qwen3-32B が多くのベンチマークで前世代 Qwen2.5-72B を上回るという圧縮効率の向上。32B はコンシューマー向け GPU（VRAM 40GB 程度）で動作する現実的なサイズであり、「高精度をオンプレミスで」という要件に対する有力な選択肢となる。第二に、Qwen3-4B が前世代 Qwen2.5-72B と同等の MMLU-Pro 性能を示しているとされる点。スマートフォンや組込みシステムでの実用化の閾値を大きく下げる意義がある。

ただしベンチマークの限界も認識しておく必要がある。AIME や MATH-500 は数学的思考の断面を測るものであり、実務における文脈理解・指示追従・ハルシネーション抑制の全体像を表さない。応用研究の広がりという観点では、J-GLOBAL に登録された研究（Qwen3-Powered Log Classification for Improved SOC Decision）がセキュリティオペレーションセンター（SOC）のログ分類タスクへの Qwen3 適用を報告している。音声合成分野では Qwen3-TTS の技術報告（J-GLOBAL）が、マルチモーダル検索では Qwen3-VL の埋込み・リランカー研究（J-GLOBAL）が公開されており、Qwen3 ファミリーの研究活動の射程の広さを示している。

Qwen3 の実務活用――用途別の設計指針と限界

コーディング・ソフトウェア開発支援

LiveCodeBench スコアが示すとおり、Qwen3 はコーディングタスクで高い水準を示す。コーディング特化のオープンウェイト派生として Qwen3-Coder（例：Qwen3-Coder-Next、総 80B / 活性 3B）も存在する。代表的な用途として以下が挙げられる。

• Python・SQL スクリプトの生成・デバッグ
• テストコード自動生成（pytest 形式など）
• OpenAPI 仕様書からのクライアントコード生成
• コードレビューと改善提案

Thinking モードを有効化するとデバッグ精度が向上しやすい傾向がある。エラーメッセージを与えた際に内部仮説を立てて検証するプロセスが働き、根本原因の特定に至る可能性が高まる。ただし定量的な評価は測定条件に強く依存するため、自社タスクでの検証を経てから判断することを前提とすること。

日本語業務文書処理

119言語対応と学習データ倍増の結果として、日本語タスクの品質が前世代から向上している。ビジネスメール・報告書のドラフト生成、英日・日英翻訳、会議議事録の要約・アクションアイテム抽出、法律・契約書の要点整理（専門家レビュー前の前処理）などが実務で試みられている。テキストマイニングとの連携についてはテキストマイニング解説記事が参考になる。自然言語処理モデルの系譜についてはBERT・NLP 解説記事が体系的な背景理解に役立つ。

エージェント・RAG システムの中核 LLM

Qwen3 は function calling（ツール呼び出し）と構造化出力（JSON 出力）の安定性が高く、LangChain や LlamaIndex との統合が整備されている。マルチエージェントシステムのオーケストレーターとして複数ツールを順に呼び出すタスクでも動作が安定しやすいとされる。GAN を用いた画像生成システムとの連携など、マルチモーダル用途への応用についてはGAN 解説記事も参照されたい。

エージェント構成の設計指針として、計画立案フェーズに Thinking モード、ツール呼び出しフェーズに Non-Thinking モードを割り当てることで、精度とスループットのバランスを取りやすくなる。同一モデル内でのモード切替が可能なため、複数モデルを並行維持するより運用の複雑さを抑えられる可能性がある。

ローカル・オンプレミス展開における実際的な考慮点

量子化（GGUF / AWQ / GPTQ）を活用することで必要 VRAM を削減できる。Qwen3-8B の Q4_K_M 量子化であれば VRAM 6GB 程度での動作が報告されており（HuggingFace Qwen3 コレクション）、コンシューマー GPU でも試験利用が現実的となる。Qwen3-235B-A22B（MoE）は活性パラメータが 22B 相当であるため、A100 80GB × 2〜4 枚が実用的な構成の目安とされているが、スループット要件・バッチサイズ・量子化の深さによって必要リソースは変動する。本番環境への適用前に十分な負荷検証を行うことが前提となる。

弊社クリスタルメソッドが開発するバーチャルヒューマン・AI アバターソリューション「DeepAI」は、リップシンク・表情生成・音声合成・対話 AI を組み合わせた製品であり、接客・研修・面接練習・広報などの用途で活用されている。Qwen3 のような高品質な日本語対話モデルとの親和性が高い領域に位置する。詳細についてはAIアバター最新情報を参照されたい。

Qwen3 のライセンスと API 料金――選択の判断軸

Qwen3 のオープンウェイトモデル群は原則として Apache 2.0 ライセンスで公開されており、商用利用・改変・再配布を広く認める（モデルごとにライセンスを個別確認すること）。GPT-4o や Claude などが商用 API のみで提供されているのと対照的に、オープンウェイトで同等以上の性能を得られるという点は、個人情報保護法・GDPR 等のデータプライバシー規制への対応やオンプレミス展開ニーズに対して本質的な選択肢を与える。

クローズド旗艦の qwen3-max（1兆パラメータ超 MoE）は Alibaba Cloud Model Studio（DashScope API）経由でのみ利用可能であり、重みは公開されていない。Model Studio 国際版の API 価格（USD / 100万トークン、2026-06-08 確認）は入力長で段階課金となるため以下は参考レンジである。

モデル	入力（$/1M トークン）	出力（$/1M トークン）	備考
qwen3-max	約 $1.20〜$3.00	約 $6.00〜$15.00	入力長で段階課金・旗艦
qwen-plus（旧世代）	約 $0.40〜$1.20	約 $1.20〜$3.60	段階課金
qwen-flash	約 $0.05〜$0.25	約 $0.40〜$2.00	段階課金。qwen-turbo の後継推奨
qwen-turbo	$0.05	$0.20	更新停止。新規は qwen-flash を推奨

出典：Alibaba Cloud Model Studio — Model Pricing（2026-06-08 確認）。価格はデプロイ地域・契約形態により変動するため、最新値は公式ページで確認すること。なお qwen-turbo は更新が停止されており、公式は後継として qwen-flash を推奨している。新規設計では qwen-turbo を「現役の主力軽量」として位置づけないよう注意が必要である。

Qwen3 の限界と留意事項――研究者として認識すべき点

Qwen3 の性能は多くのベンチマークで高い水準を示すが、実務適用にあたっては以下の限界を正確に認識しておく必要がある。

• ハルシネーション：Qwen3 を含む LLM 全般に共通する問題であり、特に最新情報・ニッチ領域・数値計算を要するタスクでは出力の事後検証が必須となる。
• Thinking モードのコスト増：複雑な推論ではトークン消費が大幅に増加し、API コストおよびレスポンスタイムが上昇する。Non-Thinking モードとの使い分け設計が重要となる。
• モデルバージョンの急速な更新：Qwen シリーズは更新頻度が高く、本稿執筆時点（2026-06）の情報が数か月後には陳腐化する可能性がある。第三者ブログには公式未確認の版番が散見されるが、公式 Model Studio ドキュメントで確認できるまで断定的に参照しないことを強く推奨する。
• ライセンスの個別確認：Apache 2.0 が基本だが、モデルごとにライセンスが異なる可能性があるため、商用展開前に HuggingFace のモデルカードを必ず確認する。
• 地政学的リスク：Alibaba Cloud が中国企業であることから、輸出管理規制の変化や政策的要因が将来的にモデルへのアクセスに影響する可能性を考慮しておく必要がある。

Qwen3 の周辺技術や関連する機械学習の体系については、クリスタルメソッドのブログ一覧で関連解説を参照されたい。バーチャルヒューマン・AI アバターへの LLM 統合に関心のある方は、弊社クリスタルメソッドが開発する「DeepAI」についてもあわせてご確認いただきたい。接客・研修・広報などの用途で実在人物の容姿・表情・声・振る舞いをデジタル空間で再現するソリューションであり、高品質な日本語対話モデルとの組み合わせにより、より自然な対話体験の構築が期待できる領域である。

参考文献

• Alibaba Cloud Model Studio — Supported Models: https://www.alibabacloud.com/help/en/model-studio/models（2026-06-08 確認）
• Alibaba Cloud Model Studio — Model Pricing: https://www.alibabacloud.com/help/en/model-studio/model-pricing（2026-06-08 確認）
• Qwen3 公式ブログ: https://qwenlm.github.io/blog/qwen3/（2026-06-08 確認）
• Qwen 公式ブログ（トップ）: https://qwenlm.github.io/blog/（2026-06-08 確認）
• HuggingFace Qwen3 コレクション: https://huggingface.co/collections/Qwen/qwen3（2026-06-08 確認）
• Qwen3-Max-Preview 公式 X 告知: https://x.com/Alibaba_Qwen/status/1963991502440562976（2026-06-08 確認）
• VentureBeat — Qwen3-Max preview: https://venturebeat.com/ai/qwen3-max-arrives-in-preview-with-1-trillion-parameters-blazing-fast（2026-06-08 確認）
• J-GLOBAL — Qwen3-Powered Log Classification for Improved SOC Decision: https://jglobal.jst.go.jp/en/detail?JGLOBAL_ID=202502292165812617
• J-GLOBAL — Qwen3-TTS 技術報告: https://jglobal.jst.go.jp/detail?JGLOBAL_ID=202602212345520563
• J-GLOBAL — Qwen3-VL 埋込みおよびリランカー: https://jglobal.jst.go.jp/detail?JGLOBAL_ID=202602202868216048

Dense/MoEの二層構造を実務でどう使い分けるか

Qwen3のラインナップを読み解くうえで最初に押さえたいのは、同じ世代の中にDense（全パラメータを毎回使う密モデル)とMoE（Mixture of Experts、専門家の一部だけを都度使う疎モデル)という二つの系統が並存している点です。どちらが優れているという話ではなく、ワークロードの性質でどちらを載せるかを設計するものだと捉えると、モデル選定の判断がぶれにくくなります。

命名規則を読むと設計意図が見える

MoE系のモデル名にある「A◯◯B」はActive（実際に活性化する)パラメータ数を表す表記として使われています（例: 総パラメータ数-A活性パラメータ数の形式)。総パラメータが大きくても、推論時に動くのは一部の専門家だけ、という構造がそのまま名前に現れているわけです。ここを理解しておくと、「総サイズは大きいのに1トークンあたりの計算量は抑えられる」というMoEの旨味と、「メモリには総パラメータ分（またはそれに近い量)を確保する必要がある」という制約を、混同せずに扱えます。なお具体的なパラメータ数・対応精度・必要メモリ量はモデルカードやリリースごとに異なるため、導入時は公式のモデルカードで確認してください。

• Denseの勘所：総パラメータ＝活性パラメータ。挙動の見積もりがしやすく、量子化・ファインチューニング・小規模構成での運用と相性が良いとされる。VRAMに載せられれば動作させやすい。
• MoEの勘所：活性パラメータが小さいため1トークンあたりの計算コストを抑えやすい一方、専門家全体を保持するためのメモリ確保と、ルーティングを含む配信基盤の設計が必要になる。

判断軸：何を優先する運用か

優先したいこと	向きやすい系統	理由の要点
低レイテンシの対話・補完	小〜中型のDense	挙動が読みやすく、量子化による軽量化がしやすい傾向
大量バッチ・高スループット	MoE	活性パラメータが小さく1トークンの計算コストを抑えやすい傾向
単一GPU・省メモリで完結	Dense（小型)	総パラメータ＝メモリ量として見積もりやすい
難度の高い推論をコストを抑えて	大型MoE	大きな知識容量を持ちつつ実行時の計算コストを抑えやすい

実務では「まず小型Denseで検証し、品質が頭打ちになったらMoEへ横展開する」といった段階設計が現実的です。総パラメータ＝メモリ、活性パラメータ＝計算量という二軸で見積もると、GPU構成やコストの試算の出発点になります（実際のVRAM要件・スループットは量子化方式や推論エンジン、バッチサイズによって変わるため、最終判断は自社環境での検証と公式ドキュメントの確認を前提にしてください)。次節のThinkingモードと組み合わせると、同じモデルでも実効コストが変わりうる点も併せて設計してください。

Thinkingモード切替をコストと品質でコントロールする

Qwen3の実務上の特徴の一つが、一つのモデルで思考プロセスを出す「Thinkingモード」と、即答する「非Thinkingモード」を切り替えられるハイブリッド構造です。用途ごとに別モデルを用意しなくても、リクエスト単位で「じっくり考えさせる／すぐ返させる」を出し分けられるため、コストと品質のバランスをアプリ側で調整しやすくなります。この切替をどう制御するかは、Qwen3を本番投入する際の設計上の論点の一つになります。

切替の二つのやり方

• パラメータで固定：チャットテンプレート適用時の切替フラグ（enable_thinking 相当)で、その系統全体の挙動を決める方式。バッチ処理やAPIの既定挙動を揃えたいときに向く。
• プロンプト内のソフトスイッチ：会話の中に /think や /no_think を差し込み、ターン単位で切り替える方式。同じセッションで「調べ物は思考オン、雑談はオフ」のように細かく制御したいときに使われる。

※パラメータ名・コマンドの正式名称や対応状況はモデルのバージョンや利用するインターフェース（Transformers実装／各種推論エンジン／APIなど)によって異なる場合があるため、実装時は公式ドキュメントで最新の仕様を確認してください。

Thinkingモードでは思考部分が <think>...</think> のようなブロックで返る挙動が基本とされています。この中身をユーザーにそのまま見せるか、パースして最終回答だけ表示するかは、UI設計として最初に決めておくべき論点になります。

使いどころの設計指針

タスクの性質	推奨モード	狙い
多段の推論・計算・コード生成	Thinkingオン	途中の推論過程を展開させ回答の妥当性を上げる
定型抽出・分類・短い応答	Thinkingオフ	余計な思考トークンを省き、遅延と費用を抑える
対話UIの初動レスポンス	オフ→必要時オン	体感速度を保ちつつ難問だけ深く考えさせる

運用上の要点は、Thinkingがオンだと最終回答の前に思考トークンを消費するという前提を織り込むことです。生成される思考が長くなるほど応答は遅くなり、トークン課金や自前GPUの占有時間も増える方向に働きます。そのため、思考量に上限を設ける仕組み（いわゆる thinking budget的な考え方。対応の有無・具体的なパラメータ名は利用するAPIや推論環境によって異なるため公式仕様の確認が必要)を使い、「難しければ深く、簡単なら浅く」を調整する設計が有効とされています。まずはタスク種別ごとに既定モードを決め、想定より長い思考が出るケースをログで観察してから閾値を詰める——この順番で検証しながら進めると、品質と実効コストのバランスを取りやすくなります。

関連記事

• Qwen とは｜全体像と研究背景
• Qwen モデル一覧（世代・サイズ・タイプの選定指針）
• Qwen でできること完全ガイド
• Qwen3-Coder によるコーディング活用
• Qwen3-VL（視覚言語モデル）の活用ガイド
• Qwen の必要VRAMと量子化の目安
• Qwen でAIエージェントを構築する方法