ローカルLLMが動作する高性能なPCを購入したので、最近話題のQwen3.6-35b-a3bがWebアプリケーション開発でどの程度使えるのかを評価してみました。
Qwen3.6-35b-a3bについてはこちら。
「Qwen3.6」衝撃公開、視覚性能でClaude Sonnet 4.5をほぼ全項目で凌駕
PCスペック
CPU: AMD Ryzen AI MAX+ 395
GPU: Radeon 8060S
RAM: 128GB
OS: Windows 11 Pro
ハードウェア設定
RAM: 64GB
VRAM: 64GB
LLMエンジン
LM Studio 0.4.12
ROCm llama.cpp (Windows) v2.13.0
言語モデル設定
言語モデル: Qwen3.6-35b-a3b
量子化レベル: Q4_K_M
コンテキスト長: 32,768
モデルをメモリに保持: true
mmap()を試行: false
Flash Attention: true
Kキャッシュ量子化タイプ: true Q4_0
Vキャッシュ量子化タイプ: true Q4_0
他はデフォルト値
インデックス設定
埋め込み言語モデル: text-embedding-mxbai-embed-large-v1
ベクトル次元: 1024
ベクトルデータベース: qdrant
開発環境
エディタ: VS Code
プラグイン: Kilo Code (Codeモード)、コンテキストは自動圧縮・古い出力を削除に設定
※初めはRoo Codeを使っていたのですが、実行時間が5分を超過するとエラーで止まるという問題（仕様？）がありKilo Codeに切り替えた経緯があります。
リポジトリ
github.com/hideshi/qwen3.6-35b-a3b
指示内容
Nuxt.jsとLaravelを使った３つの役割が登場する小さいアプリケーション（デジタルアセット管理アプリ）の開発を、要件定義、設計、タスク作成、実装、テストという一連の流れでQwen3.6-35b-a3bに行ってもらいました。
指示書はこちらで、100行に満たないシンプルな内容になっています。
進め方
LLMそれ自体の能力を評価できるように、できるだけHuman-in-the-loopの頻度を減らし、必要最小限の指示だけを行いました。
- 「指示書を元に進めてください。」 ⇒ ドキュメントが生成される。
- 「生成したドキュメントを元に実装を進めてください。」 ⇒ コードが生成される。
- 「現在のステータスを教えてください。」 ⇒ 残タスクを教えてくれる。
- 「上から順に進めてください。」 ⇒ 残タスクを進める。
- 「テストを実行してください。」 ⇒ テストを実行しバグを修正する。
- 「テストで出た問題を１つづつ解決してください」 ⇒ テストのFAILを１つづつ修正する。
PCリソース消費の傾向
VRAMの使用量は36GBから上がりませんでした。
RAMの使用量は30GB程度から徐々に上がり最終的には60GBあたりまで上昇。LLMはRAMに保持しない設定にしているにもかかわらずかなり増えてしまったのですが、インデックス設定を行った後はRAMはほとんど上がりませんでした。CPU使用率は20%前後を維持。
LLMの動作
初めはコンテクスト長を128,000にしていました。最初のころは入力から出力まで速かったのですが、その後徐々に入力の速度が低下し、最終的には1回のリクエストの応答にだいたい4分30秒くらいかかるようになってしまいました。その後コンテクスト長を32,768に減らしたところ、入力の速度が6倍くらいに上がりました。
品質はともかくとして、ドキュメントの作成とコーディングまでは比較的スムーズに進み、数時間で終わったのですが、その後のテストで何時間回しても大量のFAILがなかなか解消しないという状態が続きました。
仕事の都合もありしばらく放置していたのですが、思い出したように取り組みを再開。インデックスの設定を行ってから再実行したところ、ようやくテストがすべてPASSになりました。
その過程で、あるテストコードの内容が全消しされるというトラブルがあり、自力で復元しようとしてツールコールエラーでできない、復元を試行⇒できないの無限ループに入ってしまいました。いったん止めてテストコードを仕様を元に一から書き直すように指示をしました。復元より一から書き直す方がだんぜん速かったです。
ほかにも、複数のテストのFAILの修正をまとめてやり始めて無限ループに入っていたので、「問題を１つづつ解決してください」という指示を与えて軌道修正をしましたが解決しなかったり、残り1ケースのFAILがなかなか解消しなかったので、ここだけ人が介入して解決しました。
結局のところ、初期データとLaravelのクエリの書き方やORMから返ってくるオブジェクトの状態が見通せていなかったので、解決方法が見つけられず無限ループに入ってしまったようでした。
VS Codeは処理中になっているが、LLM側はコネクションが切れてしまっていたので、いったん止めて「続けてください」と指示する場面もしばしばありました。
Opus4.6によるレビューの結果
成果物を別の高性能な言語モデルにレビューをしてもらうことで、客観的な評価を行いました。
評価結果のサマリは以下の通りです。全文はこちら
総合：B（良）
3Bアクティブの MoE モデルとしては網羅性・文書品質が高く、設計ドラフトとして有用。ただしコードの正確性が低く、そのままでは動作しない。
セクション別スコア
| # | セクション | スコア |
|---|---|---|
| 1 | 業務要件定義 | B |
| 2 | デザインシステム構築方針 | B+ |
| 3 | システムアーキテクチャ詳細設計 | A- |
| 4 | タスク分解（チケット分割） | A- |
| 5 | ローカル環境構築・DX方針 | A ← 最高評価 |
| 6 | コア機能の実装コード | B+ |
| 7 | テスト設計 | B |
| 8 | リファクタリング最適化戦略 | B+ |
| 9 | 運用トラブルシューティング | A- |
強み
- 9セクション全てを漏れなく出力（約15万バイト）
- S3直接アップロードのアーキテクチャ設計が的確
- docker-compose.ymlがそのまま使えるレベル
- トラブルシューティングの根本原因分析が論理的
- Markdown構造化（図表・コードブロック）が読みやすい
弱み
- Laravel 12 Concurrency APIの構文が無効なPHP
- S3アップロード方式がPresigned PUT/POSTで混在
- PHP構文エラー（
setUp(): void: void等）が複数 - ドキュメント間でカラーコード・方針が矛盾
- 設計したコンポーネントの大半がファイルとして未生成
感想
普段開発で使っているCursorのComposer 2やAntigravityのGemini 3 Flashと比べて、品質もそうですが、ケアレスミスがあるとか、難しい問題に遭遇するとパニクっちゃう（無限ループ状態に陥る）など、色々と残念なところがありました。これはルールやスキルのようなLLMの行動をコントロールする仕組みが必要なのかもしれないと思いました。
個人開発で比較的小規模なものを作る程度であれば、AntigravityのGemini 3 Flashで速度・品質ともに十分で、Google AI Plusのプランで上限をほとんど気にせず利用できている現状を考えると、あえてQwen3.6で開発をやろうという気には残念ながらならなかったです。
ローカルLLMの有効活用法を模索していくいいきっかけにはなったと思います。
終わりに
今後もローカルLLMを実用的にするための調査や情報提供をしていきたいと思っています。
「このLLMで試してほしい」「このやり方で試してほしい」などなどリクエストがあれば、お気軽にコメントください。