Qwen3.5 ローカルLLM実機検証　9B vs 35B-A3B(MoE) 7問テスト

検証の背景と目的

当社が運用するローカルAIチャットシステムでは、Ollamaをバックエンドにしている。

RTX 3080 Ti（VRAM 12GB）という限られたハードウェアで、どのモデルが最も実用的かを判断するため、Qwen3.5シリーズの3モデルを7つの実務タスクで比較検証した。

ベンチマークサイトのスコアだけでは見えない「実際に業務で使えるか」を明らかにすることが目的だ。

普段CloudCode、Antigravity、Codex5.3、Opus4.6、Gemini3.1 Proを使う中で、それらのツール（モデル）に代わりとなれるかどうか、またさらには上位互換となることができるかを厳しい目でチェックした。

検証環境

検証は2026年3月22日に実施した。

項目	仕様
GPU	NVIDIA RTX 3080 Ti（VRAM 12GB）
RAM	64GB DDR4
OS	Windows 11 Pro
Ollama	最新版（2026年3月時点）
実行方式	Ollamaローカル実行（外部API不使用）

予選で落ちた2モデル

本検証では、まずOllamaにインストール済みの全モデル（qwen3:8b、qwen3:14b、qwen3:32b、qwen3.5:9b、qwen3.5:9b-q8_0、qwen3.5:35b-a3b）に同一の質問を投げた。

そのうちqwen3:14bとqwen3:32bは、MCPサーバーの説明を求める最初の質問で「Minecraft: Pocket Editionのサーバー」と回答した。MCPはModel Context Protocolであり、Minecraftとは無関係だ。これは完全にハルシネーションだ。

初歩的な技術用語でハルシネーションを起こすモデルは、業務利用の前提を満たさない。この時点で検証対象から除外し、残ったQwen3.5シリーズの3モデルで本検証を実施した。

比較した3モデル

モデル	パラメータ	アーキテクチャ	ファイルサイズ	VRAM使用量
qwen3.5:9b	9B	Dense（全パラメータ常時使用）	6.6GB	約8-9GB
qwen3.5:9b-q8_0	9B（高精度量子化）	Dense	10GB	約10-11GB
qwen3.5:35b-a3b	35B（推論時3Bのみ稼働）	MoE（Mixture of Experts）	23GB	約11.5GB + RAM併用

35b-a3bはMoE構造を採用している。35Bのパラメータのうち、1回の推論で使うのは3B分だけだ。料理人に例えると、35人のエキスパートが待機しているが、1つの注文には最適な3人だけが担当する。このため、12GBのVRAMでも動作する。ただし、モデルの重み全体（23GB）はVRAM+RAMに分散ロードされるため、CPU/RAM間のデータ転送がボトルネックになる。

速度の実測値

モデル	初回トークン	生成速度	合計時間	回答トークン数
qwen3.5:9b	10.8秒	71.1 tok/s	11.1秒	22
qwen3.5:9b-q8_0	17.8秒	18 tok/s	58.7秒	737
qwen3.5:35b-a3b	42.7秒	7.2 tok/s	48.9秒	44

9bの71.1 tok/sは体感でほぼ即応。35b-a3bの7.2 tok/sは待ちが生じるが、品質重視の用途なら許容範囲だ。

9b-q8_0は特異な挙動を示した。回答トークン数が737と、他のモデル（22〜44）の10倍以上。同じ質問に対して冗長な回答を生成する傾向がある。生成速度18 tok/sは9bの4分の1で、高精度量子化のメリットが速度面では見えなかった。

7問テストの設計

テストは以下の7つの実務タスクで構成した。各タスクはローカルLLMを業務で使う際に必要な能力を測定する。

問	タスク	測定する能力	配点
1	MCP（Model Context Protocol）の平易な説明	技術概念の翻訳力	10
2	AIが知らない会社の代表者名を聞く	ハルシネーション耐性	20
3	ルール付き質問（推測明記・出典付き）	指示遵守力	15
4	カジュアル文をビジネスメールに変換	日本語の自然さ・敬語力	10
5	CVRデータの分析と改善提案	数値分析・矛盾検出力	15
6	前提条件を踏まえた文章生成	文脈保持・ブランド語彙統制	15
7	Python（Windows対応）スクリプト生成	コード品質	15

配点はハルシネーション耐性（問2）を最重点とした。どれだけ高速であっても、どれだけ長文を出力できたとしても、知らないことを「知らない」と答えられないモデルは、他のスコアがどれだけ高くても業務では使えないと判断した。

総合スコア

順位	モデル	問1	問2	問3	問4	問5	問6	問7	合計
1位	qwen3.5:35b-a3b	9	18	11	10	15	14	13	90
2位	qwen3.5:9b	9	18	14	9	11	13	12	86
3位	qwen3.5:9b-q8_0	8	18	12	9	13	13	11	84

問5で見えた決定的な差

最も大きな差が出たのは問5（CVR分析）だ。

テストでは「月間PV 50,000、問い合わせ15件、CVR 0.3%」というデータを提示した。ここに意図的な矛盾を仕込んだ。50,000PVで15件なら実際のCVRは0.03%であり、提示された0.3%（150件相当）とは10倍のずれがある。

35b-a3bだけがこの矛盾を指摘した。「CVRが0.03%であり、提示された0.3%とは異なります」と明確に述べた上で、正しい数値に基づいた分析を展開した。9bと9b-q8_0は矛盾に気づかず、0.3%をそのまま受け入れて分析した。

数値の矛盾を見抜く力は、コンサルティング業務やデータ分析で業務品質に直結する。クライアントから提供されたデータに誤りがあった場合、そのまま分析を進めれば結論自体が狂う。

モデルごとの性格と得意領域

qwen3.5 9b

指示遵守（問3）で最高スコアを記録した。「推測には（推測）と明記せよ」「数値には出典を付けよ」というルールに最も正確に従った。一方、与えられた数値をそのまま受け入れる傾向があり、データの矛盾には気づかなかった。

速度は71.1 tok/sで3モデル中最速。日常的なチャットや定型作業に向いている。

qwen3.5 9b-q8_0

CVR分析（問5）では具体的なツール名（GA4、ヒートマップ等）を交えた実務的な回答を出した。知らないことに対しては正直に「知識ベースにない」と棄権する姿勢も見られた。

とはいえ、品質スコアで9bを下回り（84 vs 86）、速度も4分の1（18 tok/s vs 71.1 tok/s）、VRAMは1.5倍多く使う。高精度量子化の恩恵が7問テストでは見えなかった。

qwen3.5 35b-a3b

総合スコア90で1位。数値矛盾の指摘、SIer語彙の回避（「導入支援」ではなく「プロダクト」「製品」を一貫使用）、pathlibを使ったPythonicなコード生成など、品質面で安定して高い。

初回トークンまで42.7秒、生成速度7.2 tok/sという遅さはトレードオフだ。品質重視のタスク（データ分析、レビュー、重要な文章作成）に限定して使うのが現実的な運用になる。

当社での運用方針

検証結果を踏まえ、用途別にモデルを使い分ける方針とした。チャットUIにタスクタグを実装し、タグ選択でモデルが自動切替される仕組みを構築済みだ。

用途	推奨モデル	理由
日常チャット	qwen3.5:9b	71.1 tok/sの即応性。指示遵守に強い
データ分析・レビュー	qwen3.5:35b-a3b	数値矛盾を見抜く鋭さ。品質スコア最高
文章・提案作成	qwen3.5:35b-a3b	語彙統制力。ブランドガイドライン遵守に強い
コード生成	qwen3.5:35b-a3b	pathlib使用。シンプルで実用的なコード
夜間バッチ処理	qwen3.5:35b-a3b	速度が問題にならない用途で最高品質を活用

Nejumi Leaderboard 4との照合

当社の検証結果を、日本語LLM評価の定番であるNejumi Leaderboard 4（2026年3月6日版、Qualiteg社公開）のスコアと照合した。

モデル	Nejumiスコア	順位（全体）	当社スコア
Gemini 3.1 Pro Preview	0.8430	1位	—
Claude Opus 4.6	0.8394	2位	—
GPT-5.2	0.8285	3位	—
qwen3.5:35b-a3b相当（397B-A17B）	0.8191	5位	90/100
qwen3.5:9b	0.7485	33位	86/100

出典: Qualiteg社 日本語対応LLMランキング2026（3月6日版）

Nejumiスコアでは35b-a3bの上位モデル（397B-A17B）が商用API（GPT-5.2）に迫る5位にランクインしている。9bは33位で、商用モデルとの差は依然として大きい。

当社の実務テストでは35b-a3bと9bの差は4点（90 vs 86）だったが、Nejumiスコアでは0.07ポイントの差がある。実務タスクでは差が縮まる傾向がある一方、ベンチマーク上の能力差は無視できない。

検証から得た教訓

ベンチマークスコアだけではモデルの実力は測れない。9b-q8_0はVRAMを多く使い、速度も遅いにもかかわらず、品質では通常の9bに及ばなかった。高精度量子化がどのタスクでも有利に働くわけではない。

MoE構造の35b-a3bが12GB VRAMで動作する事実は、「VRAMが足りない＝大型モデルは使えない」という思い込みを覆す。推論時に使うパラメータ数を絞る設計により、限られたVRAMでも実用的な品質が得られる。

最終的に重要なのは、モデル選定を「1つに絞る」のではなく「タスクに応じて使い分ける」ことだ。速度が必要な場面では9b、品質が必要な場面では35b-a3b。この使い分けをUIレベルで実装したことで、ユーザーが意識しなくても最適なモデルが選ばれる仕組みになった。

結論

Qwen3.5がいかに優れていようと、普段AntigravityやClaude Codeがある中で、Qwen3.5をそれらの代替として使えるかどうかは懐疑的だ。なぜなら代替できるほどの精度の検証も時間をかけてあらゆる業務で使っていく中で弱点が見えてくるため、今回の検証では精度が不十分かどうかも検証できていない。趣味で使うレベルでなら使えるが、スピードと精度を競う業務では使う気にはならない。つまり現時点で、ClaudeやGeminiを解約してQwen3.5をそれらの代わりに使うという選択肢は考えられない。ましてや、弊社はAntigravityやClaude Codeを導入していて、Google AI ULTLAやClaude Maxプランに加入し、その恩恵を受けていると、開発業務においてもQwen3.5を使う理由が見当たらない。

Qwen3.5の強みはネットにつながらないこと

ただ一点、Qwen3.5にしかできないことがある。それは機密情報や個人情報を扱う場合だ。この場合においてネットにつながるAIは一切使えない。そのため弊社では機密情報や個人情報を鍵のかかった他のAIには見えない環境に設置し、Qwen3.5で個人情報、顧客情報を含んだデータを処理する方式を取っている。

具体的には、ワークフロー開発やFAQツール開発において、個人情報や顧客情報が含まれたログデータをマスキングすることなく、そのままQwen3.5に入れて分析できる。このような使い方で、データを安全に処理して、プロンプト開発やワークフロー開発に役立てている。AIを使って効率的に分析をしたいけど、AIが使えないという環境においてははローカルLLMはなくてはならない存在だ。

---

検証日: 2026年3月22日 / 検証環境: RTX 3080 Ti, Windows 11 Pro, Ollama / 検証者: 株式会社ユニバーサルマーケティング