32GBノートPCでローカルLLMはどこまで実用になるのか。ZenbookでQwen2.5、Qwen3.5、Qwen3.6を測ってみた
2026年4月に、手元のZenbookでローカルLLMを試したときは、十分な検証ができなかった。モデルを起動して少し触るだけでは、「本当に業務で使えるのか」「どこから先はクラウドLLMに任せるべきなのか」が判断できない。
そこで今回は、同じWindowsノートPCで、OllamaのWindowsネイティブ版を使い、Qwen系モデルを改めて測定した。速度だけでなく、メモリ、GPU/NPUの使われ方、回答品質、長文処理、構造化出力、コード理解、画像理解、ツール利用まで確認した。
結論から言うと、32GBメモリのノートPCでは、7Bから10B級が現実的な上限だった。最新世代の大型モデルも「動く」ことは動くが、継続利用するにはメモリ余裕がなさすぎる。
検証環境
使用したPCは ASUS Zenbook S 14 UX5406SA。主な構成は次の通り。
比較したモデル
最初の比較対象は、2026年4月時点の基準として qwen2.5:7b、現在の同規模モデルとして qwen3.5:9b にした。その後、最新Qwen系として既にPC内に入っていた qwen3.6:35b-a3b も大型モデル枠で追加評価した。
まず疎通確認
最初に軽量モデル llama3.2:1b で、Ollama APIに対して「2+2の答えだけを返してください。」と送った。
結果は3.435秒で 4。APIエラーもOllamaの異常終了もなかったため、本測定へ進んだ。
速度測定
速度試験では、各モデルに同じ日本語プロンプトを投げた。
日本語で、ローカルLLMを業務利用する利点を3点、200文字以内で説明してください。前置きや結論の繰り返しは不要です。
各モデルでコールド起動1回、ウォーム実行2回を測った。qwen3.5 と qwen3.6 はthinking対応モデルなので、通常比較では think:false を明示した。これを指定しないと、qwen3.5 はthinkingトークンに出力枠を使い切って空応答になるケースがあった。
意外だったのは、qwen3.6:35b-a3b のウォーム時生成速度が悪くなかったことだ。MoE系だからか、短文生成だけを見ると9B級より速い場面もあった。
ただし、coldロードは約62秒、最大メモリは99.99%。この時点で「速度は出るが、ノートPCとしての余裕はない」という評価になった。
実務テスト
次に、業務利用を想定して4種類のテストを行った。
日本語文書の要約
業務要件をJSONへ構造化
プロジェクトのリスク整理
Pythonコードの不具合特定と修正
採点は25点満点。正確性、重要論点、指示遵守、日本語品質、余計な情報の少なさを見た。完全な客観評価ではなく、機械判定と主観評価が混ざる点は制約として残る。
この範囲では、大型の qwen3.6 が明確に高得点になるわけではなかった。短めの実務プロンプトでは、7Bから10B級でも十分に戦える。
ただし画像理解では差が出る。qwen2.5:7b は画像非対応。qwen3.5:9b と qwen3.6:35b-a3b は、簡単なシステム構成図の要素、矢印、問題点をおおむね正しく読めた。画像理解スコアはいずれも24/25だった。
長文テスト
長文テストでは、FACT-01からFACT-12までの検証情報を文書の冒頭、中盤、末尾に分散配置し、最後に抽出させた。
ここはかなり厳しい結果だった。公称コンテキスト長だけを見ると、qwen2.5:7b は32K、qwen3.5:9b と qwen3.6 は256K級に見える。しかし、このPCで実用的に扱える長文は4096程度までだった。
8192では両モデルとも5分タイムアウト。qwen3.6 は実務テスト後にメモリ使用率が98.17%まで上がったため、長文テスト自体を止めた。
起動できる最大値と、安定して使える最大値は別物だと分かった。
ツール利用
qwen2.5:7b と qwen3.5:9b では、Ollamaの /api/chat とローカルの固定関数を使って、簡単なツール利用テストをした。
関数は get_inventory(item_code)。入力は「ITEM-001の利用可能在庫を確認してください。在庫情報が必要な場合はget_inventoryを呼び出してください。」で、10回ずつ試した。
このレベルの単純なFunction Callingなら、7B級でもかなり安定していた。ただし、これは固定関数1個の小さな試験であって、ファイル操作や複数ステップの自律エージェントを安全に任せられることまでは意味しない。
GPUとNPUは使われたのか
今回のOllama実行では、ollama ps のPROCESSOR表示はすべて 100% CPU だった。
Windows側のGPUカウンターには一部GPU利用率の変動が見えたが、compute使用率はほぼ0%。NPUは Intel AI Boost として認識されていたが、PowerShell標準の使用率カウンターは取得できなかった。
少なくとも今回のWindowsネイティブOllama環境では、「Intel Arc GPUやNPUをLLM推論にしっかり使えている」とは言いにくい。実測上はCPU主体の挙動として見るべきだと思う。
最終判定
モデル判定コメントqwen2.5:7bB用途を限定すれば実用的。速度、メモリ、安定性のバランスがよいqwen3.5:9bB画像とtools対応が強み。メモリ余裕はやや少ないqwen3.6:35b-a3bD動くが、32GBノートPCでは非実用的。メモリ余裕がなさすぎる
qwen3.6 は最新世代で機能も多いが、このPCでは「すごいモデル」より先に「メモリを食い尽くすモデル」になってしまった。短いプロンプトでは良い結果を出すが、業務で継続利用する前提では怖い。
32GBノートPCで任せられる実務
今回の結果から、ローカルLLMに任せやすいのは次のような仕事だ。
社内文書の下書き要約
要件整理のたたき台作成
JSON化などの構造化支援
小規模コードレビューの補助
機密情報をクラウドへ送る前のローカル草稿処理
簡単なFunction Callingの試作
特に qwen2.5:7b と qwen3.5:9b は、完璧ではないが「人間が確認する前提の補助役」としては十分使える。
クラウドLLMへ残すべき仕事
逆に、次の用途はまだクラウドLLMや人間のレビューを組み合わせた方がいい。
大量文書をまたぐ調査
長大な仕様書の一括読解
厳密な法務、会計、食品表示判断
大規模設計レビュー
複雑な画像や図面の読解
ファイル操作を伴う自律エージェント運用
ローカルLLMは「安全に閉じた環境で使える」ことが強みだが、性能や安定性までクラウドLLMと同じと考えるのは危ない。
OpenClawのようなエージェント基盤は再導入すべきか
今回、OpenClawは使っていない。目的は分散AI基盤ではなく、ローカルLLM単体の実力を測ることだったからだ。
ツール利用テストだけを見ると、qwen2.5:7b と qwen3.5:9b は10/10成功で、関数呼び出しの基礎能力はある。ただし、これはかなり単純なテストだ。ファイル操作、複数ツール、長い作業計画、失敗時の復旧まで含めると、まだ追加検証が必要になる。
現時点の判断は、「再導入するなら qwen3.5:9b まで。qwen3.6 を載せるのはメモリ面で厳しい」。そして、最初から自律実行させるのではなく、読み取り中心、承認付き、ログ保存ありの範囲から始めるのが安全だと思う。
まとめ
今回一番はっきりしたのは、ローカルLLMの実用性はモデルの新しさだけでは決まらないということだ。
qwen3.6:35b-a3b は最新世代で、短文生成も画像理解も悪くない。しかし32GBノートPCではメモリに余裕がなく、実験後半で停止条件に達した。
一方で、qwen2.5:7b と qwen3.5:9b は、派手さはないが実務補助として扱いやすい。特に qwen3.5:9b は画像とtools対応があるため、現在のZENBOOKで使うなら最もバランスがよい。
ローカルLLMは、クラウドLLMの代替というより、手元で閉じて使える補助エンジンとして考えるのが現実的だ。32GBノートPCでは、7Bから10B級を中心に使い、長文・高精度判断・大規模設計はクラウドLLMへ残す。その線引きが、今回の実測でかなり明確になった。
