まえがき
Snapdragon X Plus（Windows on ARM）搭載のPCを昨年末に購入していたので、ローカルLLMの構築を細々とすすめています。
ただ、なかなかNPUを活用して動いてくれず、なかなか成果がでない状況でした。
昨年末は「AnythingLLM」でNPUを使ってチャットができるところまでは確認していたのですが、それなりの頻度でエラーが出て使えなくなるなど挙動が不安定なので、寝かしていました。
最近の記事で、ARM64（Snapdragon）でLM Studio×Gemma4を動かした的なものがありましたので、久しぶりにローカルLLMの構築を再開してみました。
ただ、「LM Studio」を試したところ、タスクマネージャーでNPU使用率が0%のまま…
→LM Studioの裏で動いているエンジンがQualcommのNPU（Hexagon NPU）にまだ完全対応しておらず、現状はCPU推論になっているとのこと。
結局ダメだったので、再度仕切りなおしてGeminiに聞きまくったところ、
以下の環境でそれなりに動かすことができたので、記事にしてみました。
この記事の内容
NPUをしっかり活用できるMicrosoft公式ツール 「Foundry Local」 を使い、さらに VSCodeの「Continue」拡張機能 と連携させて、ローカルAIコーディング環境を構築するまでの手順をまとめました。
環境
- PC: HP OmniBook 5 14-he
- CPU: Snapdragon(R) X Plus - X1P42100 (ARM64)
- RAM: 32 GiB
- OS: Windows 11 Home(25H2)
- NPU: Qualcomm® Hexagon™ NPU (最大45 TOPS)
-
LLM実行環境:
- Foundry Local (Microsoft公式 / NPU利用のため)
- エディタ: Visual Studio Code + Continue (拡張機能)
-
使用モデル:
- qwen2.5-7b-instruct-qnn-npu:2
1. Foundry Localのインストールと準備
Foundry Localは、Windows上でNPUやGPUを活用してAIモデルを動かすためのツールです。バックグラウンドで「OpenAI互換API」として動作してくれます。
インストール
ターミナル（コマンドプロンプトなど）を開き、以下のコマンドを実行。
winget install Microsoft.FoundryLocal
モデルの確認とModel IDの取得
インストールが完了したら、NPU対応のモデルを探します。
foundry model list
ここで表示される一覧から、NPU対応モデル（qwenなど）を探します。
後でAPIから呼び出す際に必要になるので、一番右の列にある**「Model ID」**（例: Qwen2.5-7b-qnn など）をメモしておく。
2. Foundry LocalのAPIサーバーを起動・確認する
VSCodeから接続するために、Foundry Localをバックグラウンドで起動。
foundry model run qwen2.5-7b
別のターミナルを開き、以下のコマンドで待機しているURL（エンドポイント）を確認。
foundry service status
すると、以下のようなログが出力される。
🟢 Model management service is running on http://127.0.0.1:63067/openai/status
EP autoregistration status: Successfully downloaded and registered the following EPs: QNNExecutionProvider.
QNNExecutionProvider と表示されていれば、NPUの準備は大丈夫そう。
このログにある http://127.0.0.1:63067 の部分（ポート番号は環境によって変わります）がベースURLになります。
3. VSCode (Continue) との連携
VSCodeにローカルLLMを繋ぐための定番拡張機能「Continue」を設定。
- VSCodeの拡張機能から「Continue」をインストール。
- Continueの設定ファイル(config.yml)を開く。
%USERPROFILE%\.continueにいました
config.ymlの追記
models: のリストの中に、以下のようにFoundry Localの設定を追記。
models:
# (他のモデル設定があればそのまま残す)
- name: Foundry Local (NPU)
provider: openai
model: Qwen2.5-7b-qnn # ← 【重要】foundry model listで確認した正式な「Model ID」を記載！
apiBase: http://127.0.0.1:63067/v1 # ← 先ほど確認したURLの末尾に /v1 を付ける
apiKey: dummy
⚠️ よくあるエラー：400 Bad Request
Continueのチャットから送信した際に 400 status code (no body) のエラーが出る場合、config.yml の model: に指定している名前が間違っている（Alias名になっている）可能性。必ず foundry model list の右端にある正式なModel IDを指定する。
4. いよいよ、NPU駆動のAIチャットへ
設定を保存したら、Continueのサイドバーにあるモデル選択プルダウンから「Foundry Local (NPU)」を選択。
あとはコードについて質問するだけ！
タスクマネージャーの「パフォーマンス」タブを見ると、しっかりNPUが稼働しているのが確認できます！
動作確認
試してみたのは以下のプロンプト。
htmlとjavascriptを使ってカレンダーを作成して
デザインは酷いものの、きちんと動くソースがきちんと生成されました。
ただし、ときどき中国語が混ざるのが気になりました。
→チャットの回答のみで、ソースは全部日本語でした
レスポンスはGithub Copilotなどに比べればだいぶ遅いですが、
全然致命的ではなく、Gemini CLIの1.2倍ぐらいの速度といったところでしょうか。
さいごに：ローカルLLMをエージェントとして使うのはアリ？
Clineなどの自律型エージェントツールと連携させることもシステム上は可能ですが、NPUでサクサク動く軽量モデル（数Billionパラメータ）では、複雑なツール呼び出しやJSONフォーマットの維持が途中で崩れがちです。
現状は「自動でコードを書き換えてもらうエージェント」としてより、「隣にいる優秀なペアプログラマー」としてContinue経由でチャット相談やコード補完に使うのが、実用的で最もストレスのない運用方法だと思います。
この構成の最大のメリットが、
オンプレミス環境(完全オフライン＆情報漏洩ゼロ)で生成AIのコード支援を受けられる
点でしょう。
案件によっては外部サービスが使えないケースがそれなりにあると思います。
オンプレミスであればこの制約を受けないため、積極的に活用したいですね。
なお、ご存じの方は本記事の手順踏まずとも、AI Toolkit for VS Code でいいじゃん、って思われるかもですが、本当にその通りだと思います。
まぁVSCode以外のフロントエンドも使えるのでいったん記事にさせていただきました。