バイブコーディングを活用した NPU アプリ開発

これは業界で AI 拡張開発と呼ばれる手法です。インターネット上ではバイブコーディングと呼ばれますが、どちらも同じ意味です。ユーザーが何をしたいかを説明すると、AI コーディング アシスタントがコードを書き、それをユーザーが実行して問題のある箇所を伝え、AI が修正します。このような手順を繰り返し行います。ユーザーがアーキテクトと QA エンジニアの役割を担い、AI が実装を担当するという構図です。

例としては、GitHub Copilot CLI (英語) や Cursor といった各種 AI コーディング アシスタントが挙げられます。どのツールを使用するかよりも、ワークフローのほうが重要です。ユーザーが機能を説明し、AI アシスタントがコードを書き、それをユーザーが実行してうまく行った点と問題点を伝え、AI が修正します。AI は、Flask によるルーティング、CSS レイアウト、正規表現、JavaScript のイベント ハンドラーといった定型的なコードを扱います。一方で、ユーザーはアーキテクチャの決定、実機テスト、製品の評価を担当します。

なぜこれが NPU 向けの開発において特に重要となるのでしょうか? それは、AI コーディング アシスタントが OpenAI SDK のパターンを熟知しており、Foundry Local が互換性のある API を使用しているからです。「互換性がある」とは、標準の SDK がチャット内容の補完や使用頻度の高い推論パターンで動作することを意味しますが、モデル ID やストリーミングの挙動に軽微な違いが見られることがあります。マイクロソフトはこれを「OpenAI 互換の SDK および HTTP クライアント」としてドキュメントにまとめています。実際に、この記事で扱っているワークロードでは SDK をそのまま使用できます。参入障壁は以前より大幅に下がり、ワークフローを説明するだけで NPU 向けのコーディングを始めることができるようになりました。

コードを書く前に、まずは AI Toolkit for VS Code を確認します。ここでは Model Catalog と Playground の 2 つが重要となります。

Model Catalog を開き、ローカルの NPU での実行に最適化されたモデルを絞り込みます。

ローカル モデルをすべて確認したい方は、Windows 上の Microsoft Foundry ですぐに使用できるローカル LLM および Windows AI の概要ページのデシジョン ツリーをご覧ください。

Playground は、ユーザーが自身で検証を行うためのサンドボックスです。モデルを選択して読み込み、VS Code 内で直接チャットしながら開発を進めます。プロンプトのテストやレイテンシの実験、コンテキストの制限などを、アプリケーション コードを書く前から試すことができます。また、私たちが知る限りでは、Phi Silica で初期モデルをダウンロードして準備する場合に最も信頼できる方法でもあります。

ハードウェア

任意の NPU 搭載 Copilot+ PC を使用します。現在、Surface の一般ユーザー向け Copilot+ PC には Snapdragon X が搭載されており、Surface の法人ユーザー向け (業務用) Copilot+ PC では Snapdragon X と Intel Core Ultra のモデルを選べます。

ソフトウェア スタック

範囲この記事で取り扱うのは Windows 版のみです。ここで取り上げる Foundry Local、AI Toolkit、NPU ランタイムは、Windows 11 搭載の Copilot+ PC ハードウェア (Intel Core Ultra または Qualcomm Snapdragon X) が要件となっています。

Foundry Local についての注意事項: Foundry Local は現在パブリック プレビューとして提供中です。SLA はなく、下位互換性も保証されていません。リリースごとに内容が変更される可能性があるため、広範囲に展開する前にリング方式で段階的に検証を行ってください。最新情報は Foundry Local のドキュメント ハブでご覧いただけます。

⚠️ パッケージ名に関する警告: foundry-local-sdk (マイクロソフト公式 SDK) をインストールしてください。PyPI の類似した名前のパッケージと混同しないように注意しましょう。本記事の執筆時点で、foundry-local (v0.0.1) は公式 SDK ではなく、エラーが発生する (または予想外の動きをする) 可能性があります。Microsoft の SDK ドキュメントおよび PyPI (英語) を確認してください。

Foundry Local は、エイリアス システムを利用して、チップのシリーズに応じてモデルを自動的に選択します。ほとんどの開発者や、単一デバイスでの利用の場合、コードベースを 1 つ作成するだけで問題なく動作します。以下では、複数種類のデバイスが混在する企業環境に展開する場合の、プラットフォームごとの最適化について説明します。

エミュレーション環境でのアーキテクチャ検出

ARM 版 Windows では、platform.machine() を使用すると Python x64 は AMD64 と報告します。Python と PROCESSOR_ARCHITECTURE のどちらも、エミュレーション環境では誤った値を返します。正しいアーキテクチャを取得するには、WMI を使用してください。

result = subprocess.run(
["powershell", "-NoProfile", "-Command",
"(Get-CimInstance Win32_Processor).Name"],
capture_output=True, text=True, timeout=5,
)
cpu = result.stdout.strip().lower()
if "qualcomm" in cpu or "snapdragon" in cpu:
return "qualcomm"

Snapdragon デバイスでは、可能な限りネイティブのARM64 Python を使用しましょう。これにより、パフォーマンスを向上させ、エミュレーションの不具合を抑制できます。

注意事項: Snapdragon では ARM64 Python を優先的に使用し、できるだけ x64 エミュレーションは避けてください。

チップによるモデルの互換性の違い

プレビュー版ランタイムでテストした際に見られた挙動です (2026 年 2 月)。今後 Foundry Local やドライバーが更新されると結果が変わる可能性があります。

Foundry Local はエイリアスに従ってバリアントを選択します。phi-4-mini を要求すると、入手できる範囲でハードウェアに最適なビルドを取得します。NPU 実行プロバイダー全体で利用可能なモデルは、Foundry Local が新たにリリースされるたびに拡大しています。現時点では、Qualcomm でツールを呼び出すワークロードの場合、Qwen 2.5 7B が NPU アクセラレーションに完全対応し、本番環境にも対応しています。検出とモデルのルーティングは AI コーディング アシスタントが自動的に行います。

ランタイムのライフサイクルの違い

if SILICON == "qualcomm":
# Skip warmup - QNN is unstable with rapid reconnection attempts
print("Skipping warmup on Qualcomm (first request will load model)...")
else:
# Intel: warmup + keepalive for consistent latency
warmup_model()
start_keepalive_thread(interval=180)

Intel の場合は、ウォームアップを行い、3 分ごとに keepalive ping を打つことが推奨されます。Qualcomm の場合は逆で、ウォームアップを行うと QNN ランタイムが不安定になります。最初に実行する要求でモデルの読み込みをトリガーするようにしてください。どちらのプラットフォームでも、自動再接続を積極的に使用しましょう。これはプレビュー版ランタイムの観測に基づいており、今後改善される可能性があります。

NPU から GPU へのフォールバック チェーン

try:
manager = FoundryLocalManager("phi-4-mini")  # NPU first
except Exception:
try:
from foundry_local.api import DeviceType
manager = FoundryLocalManager("phi-4-mini", device=DeviceType.GPU)
except Exception:
# ⚠️ NOT RECOMMENDED FOR PRODUCTION - last resort only.
# The port is dynamic; this may break if the service restarts.
client = OpenAI(
base_url="http://localhost:5272/v1",
api_key="not-needed"
)

トラブルシューティングの詳細については、Foundry Local のベスト プラクティスをご覧ください。

これはすべてに関わってくる制約です。コンテキストの上限はモデルによって異なります。Phi Silica の場合は約 4,000 トークンです。Phi-4 Mini はさらに多くのコンテキストを扱えますが、レイテンシとコストの関係で、実際に使用できるトークン量には制約が生じます。構造化フィールド抽出では約 1,884 トークン、ドキュメント分類では約 500 トークン、朝のブリーフィングでは約 2,200 トークンが観測されました。

設計原則: 1 つの機能をうまく実行する単一機能に特化したエンドポイントを作成しましょう。「1 つのチャットボットですべてをこなす」のではなく、/extract-fields、/classify-doc、/summarize といったエンドポイントを作成するようにします。1 つの呼び出し、1 つのジョブで、1 つの明確な応答を得るように心がけます。

正直に言うと、この制約によってアーキテクチャが洗練されるという効果もあります。すべての AI タスクに最先端モデルが必要なわけではありません。タスクのほとんどは大したものではなく、要約、抽出、分類といった単一目的のものです。これには 80/20 の計画モデルがそのまま当てはまります。つまり、GPT-4 を必要としない 80% のタスクを NPU が処理するということです。

初めて作成するアプリに画像認識機能を搭載しない場合は、このセクションはスキップしてかまいません。まずは Foundry Local と Phi-4 Mini の組み合わせから始めましょう。オンデバイスでの画像分類が必要になったら、こちらに戻ってきてください。

Phi Silica のセットアップ手順は Foundry Local よりもいくつか多くなりますが、クラウドに依存しないワークフローとしては最高レベルのオンデバイス画像認識機能が得られます。Phi Silica はマイクロソフトのオンデバイス モデルで、Windows AI API を通じてアクセスできます。オンデバイスでの言語およびマルチモーダルの用途に対応しており、Copilot+ PC で使用することができます。詳細な手順については、Phi Silica の使用を開始するおよび Phi Silica のチュートリアルのページをご覧ください。

Foundry Local (標準 REST API) とは異なり、Phi Silica は Windows API です。利用するには、systemAIModels の制限付き機能を含む MSIX (マイクロソフトの最新アプリ パッケージ フォーマット) でパッケージ化されている必要があるほか、パッケージ ファミリ名に関連付けられた LAF (限定アクセス機能) トークンと、オンデバイスでのモデルのプロビジョニングが求められます。開発ビルドでは LAF の強制適用が緩和される場合もありますが、本番環境への展開では常に有効なトークンが必要であると考えてください。LAF の詳細については Windows AI API のトラブルシューティングをご覧ください。

最低限の実行要件チェックリスト

• ☐ systemAIModels の制限付き機能を含む MSIX パッケージのアプリ
• ☐ オンデバイス対応の Phi Silica モデル (AI Toolkit Playground または AI Dev Gallery)
• ☐ 画像認識 API を呼び出す前にアプリで GetReadyState() を使用して準備状態をチェックする
• ☐ マイクロソフトが発行した LAF トークン
• ☐ フォールバックを検出するための正常性エンドポイント

機能を付加するパターン

アプリ全体に MSIX をパッケージ化するのではなく、小規模な C# ASP.NET Core サービスに複雑な Windows API をカプセル化します。

Flask app (localhost:5000)  →  Vision Service (localhost:5100)  →  Phi Silica on NPU
↑
MSIX packaged, LAF token,

画像認識サービスは /health、/classify、/describe、/extract-text を表示します。メイン アプリは標準の Python Web アプリケーションのままです。

この記事全体で掲げる、アーキテクチャに関する 1 つの原則を挙げるとすれば、それは「アプリが黙ってエラーを起こすような事態を許してはいけない」ということです。モデルがフリーズしたり、ドライバーが更新されたりといったことは起こり得ます。そして時折、NPU がそれに対応しないことがあります。

このような階層を最初から組み込んでおきましょう。ほとんどコストをかけずに実装でき、何か問題があった場合はすべてを守ってくれます。

Foundry Local はプレビュー期間中のため、フレームワークが進化するという前提で考えてください。混在環境への展開を考えている場合、これをあらかじめ計画に入れておかなければ、後から大きな問題になる可能性があります。

モデルの取得とオフライン対応: 初めて使用するときにはモデルをダウンロードしてローカル (通常は %LOCALAPPDATA%\.foundry\cache\models) にキャッシュします。キャッシュはユーザーごとに独立しているため、事前プロビジョニングはその前提で計画してください。

更新頻度: SLA はなく、下位互換性も保証されていません。テストはリング式に実施しましょう (開発 → パイロット → 広域展開)。ランタイム バージョンは固定します。Foundry Local や Windows が更新されたら、毎回再検証を行ってください。

ログ記録: 推論のレイテンシ、トークン数、使用されたフォールバック階層、モデルの読み込み時間を追跡します。ユーザー データや PII (個人情報) が含まれるプロンプトや応答をそのまま記録しないようにしましょう。

クラウド エスカレーション ポリシー: クラウドにルーティングする際の基準を明確かつ監査可能な形で設けましょう。ローカルでの実行を前提とし、クラウドでの実行は呼び出したときのみとします。デバイスからデータが送信されるときは毎回ログを記録します。機密性の高い環境では、管理者がクラウドへのエスカレーションを完全に禁止できるようにする切り替え機能を備えておきましょう。

セキュリティ: Foundry Local を localhost にバインドします。モデルのエンドポイントへのアクセスをローカル処理のみに制限し、明確なセキュリティ制御を経由せず外部インターフェイスにプロキシ接続されることがないように構成します。

パッケージ化: ランタイムは winget install Microsoft.FoundryLocal でインストールできます (Intune 互換)。マシン全体にインストールする場合は –scope machine と指定してください (Intune 互換)。ランタイム、事前にキャッシュされたモデル、作成したアプリケーションの 3 つのコンポーネントをステージングします。デモ リポジトリの setup.ps1 がそれぞれを検証します。

異種混在環境への対応: Intel と Qualcomm が混在する環境であれば、WMI 検出パターンと 3 階層フォールバック アーキテクチャが、オプションではなく必須となります。広範囲に展開する前に両方のチップ シリーズでテストしてください。

AI エージェント: Foundry Local を通じて Phi-4 Mini が駆動するローカルのチャット アシスタントを運用します。自然言語クエリ、ツールの呼び出し、構造化された応答などから始める方が多いでしょう。

My Day: ローカルの予定表、メール、タスク データを取得し、完全にオンデバイスで、朝のブリーフィングを構造化された形で生成します。

2 系統ルーター: 各要求を評価して、ローカルの NPU で対応できるか、それとも最先端のクラウド モデルにエスカレーションする必要があるかを判断します。判断のロジックをリアルタイムで提示し、デバイスからデータを送信する前にユーザーによる明示的な同意を求めます。

現場検査 Copilot: マルチモーダル対応のサンプルです。5 つの NPU 機能が 1 つのワークフローにまとめられています。

• • 音声: 音声認識の出力を NPU が文字に起こして、構造化されたフィールド (位置、問題のタイプ、重大度) を抽出します。

• • カメラ: 問題点を撮影した写真を Phi Silica がオンデバイスで分類します (水損、建造物のひび、カビ、機器の不具合など)。

• • ペン: ローカルの手書き認識機能により Surface ペンで写真に注釈を書き込みます。

• • レポート生成: NPU が音声、写真、注釈をまとめ、書式の整った検査レポートを作成します。

• • 翻訳: 1 タップするだけでレポート全体を完全にオンデバイスでスペイン語へ翻訳します。

対象とするインダストリーには、建設、保険請求、公益事業、製造業の品質保証、不動産管理、OSHA 規格への対応などが挙げられます。こういった環境ではネットワーク接続が弱かったり、まったくなかったりすることが珍しくないため、オフライン機能が欠かせません。

ダッシュボードには各セッションの最後にデモ値が表示されます。ローカル AI タスク数は 5、クラウド呼び出し数は 0、消費トークン数は約 520、クラウド推論費用は 0.00 ドル、デバイス外への通信は 0 バイトとなっています。

github.com/frankcx1/surface-npu-demo (英語)

コードのクローンを作成して、setup.ps1 を実行し、http://localhost:5000 を開きます。するとチップが自動検出され、適切なモデルが選択されて、すぐに実行できるようになります。

コードをフォークし、ご自身の用途に合わせて発展させてください。業界のワークフローに応じてタブを追加したり、カタログから別のモデルを選んで取り換えたりすることも可能です。良いものができたら、プル リクエストの送信をお願いします。ぜひマージさせてください。それこそが活気あふれるプロジェクトのあるべき姿です。

何を作るべきかと同様に、何を作るべきではないかを知っておくことも重要です。私の苦い経験をお伝えします。

• • モデルのトレーニングには使用しない: NPU は推論アクセラレータです。

• • 長時間にわたるエージェントのループ処理には適さない: 小規模モデルは一貫性を失いがちです。単一機能のエンドポイントを作成しましょう。

• • 無制限の会話履歴の保持には使用しない: コンテキストが約 4,000 トークンに収まるよう整理してください。

• • クラウドの機能に置き換わるものではない: 日常的に実行する大半のタスクをオンデバイスで処理できるため、クラウド分の予算を必要なタスクに回すことができます。

Surface Copilot+ PC で構築してみましょう。リポジトリ: github.com/frankcx1/surface-npu-demo (英語)