Windows MLでカスタムONNXを実行・配布する方法｜CPU・GPU・NPUとEPの選び方

30秒結論：Windows MLは「自分のONNXモデルを配る」ための選択肢

Windows上のローカルAIは、組み込みAPI、ready-to-use model、custom modelで入口が違います。Windows AI APIsはWindowsが用意する機能、Foundry Localはready-to-useのオープンモデルとOpenAI互換API、Windows MLは自分で用意・変換したONNXモデルをアプリへ組み込む基盤です。

そのため、Windows MLの記事でCLI・GGUF・OpenAI互換endpointを手順の中心にしません。対象が「自分のONNXモデルをWindowsアプリへ配布する」ならWindows ML、既製モデルをAPIで使うならFoundry Local、Windowsの機能を組み込むならWindows AI APIsへ戻ります。

• Windows AIの選び方（公式） - Windows AI APIs、Foundry Local、Windows MLの役割を比較する
• Foundry LocalをWindowsで使う方法 - ready-to-use model、CLI、local APIの所有者へ進む

カスタムONNXとGGUF・既製LLMを混同しない

Windows MLの最小経路はONNXモデルをCPUで推論する流れです。PyTorch、TensorFlow/Keras、TFLite、scikit-learnなどからONNXへ変換して持ち込むこともできますが、変換できたことと、対象EPで正しく・速く動くことは別に検証します。

「ONNX対応」と書かれていても、モデルが使うoperator、dynamic shape、tokenizer、前後処理、量子化、EPの対応は別です。まず短い固定入力をCPUで通し、出力が正しいことを確認してから加速へ進みます。

• Windows ML overview（公式） - ONNXへの変換、custom model、model distributionの全体像を見る
• ONNX Runtime GenAI（公式） - LLM・generative speech-to-textをWindows MLへ組み込むpreview境界を見る
• GGUFとは？ - GGUFとONNXを別のモデル形式として確認する

既存ONNXのEP互換性はWindows ML CLIで先に調べる

既存ONNXのoperatorやshapeがGPU・NPUのExecution Providerで動くかを整理したい開発者は、必要に応じてWindows ML CLIのwinml analyzeを使えます。公式CLIはtarget EPに対するgraph analysisからunsupportedやCPU fallbackの可能性を分類し、optimize、quantize、compile、buildでmodel artifactを準備できます。

analyzeはONNX graphのstatic analysisであり、target PCでの推論成功、数値一致、速度を実測する代わりにはなりません。Windows ML runtimeのARM64対応と、CLIの実行環境も分けます。現行installation docsではPython 3.11とuvを使い、Arm64端末でもx64 PythonをWindows emulationで実行する前提です。CLIを導入するときは、公式のtool availabilityとprerequisiteを先に確認してください。

• Windows ML CLI（Microsoft Learn） - model export、analysis、optimization、compile workflowを見る
• Windows ML CLI analyze / optimize docs - target EP分析とpartial supportの意味を確認する
• Windows ML CLI installation - Python 3.11、uv、ARM64端末でのx64 Python条件を見る

最小実行はCPUから始める：Windows・x64/ARM64・言語前提

Microsoftのget startedは、まずCPUでONNXモデルを実行し、動いた後にNPUやGPUのhardware-tuned EPを追加する順番を示しています。CPUでの基準がないままEPだけを変えると、モデルの問題、driverの問題、EPの問題を分けにくくなります。

1. ONNXモデル、tokenizerや設定などの関連asset、入力・出力仕様、licenseを記録する。
2. Windows MLのlanguage-specific packageを対象architectureへ追加し、公式の最小APIでCPU推論を行う。
3. 同じ入力を複数回実行し、出力、shape、エラー、CPU負荷、処理時間を基準値として保存する。
4. 必要性がある場合だけ対象GPU・NPUのEPを追加し、CPU基準と同じモデル・入力で比較する。
5. EPを替えた後は速度だけでなく、出力の正しさ、メモリ、初回取得、再現性を確認する。

公式要件を満たすことは、特定モデルのロード成功、十分な速度、GPU・NPUの利用を保証しません。Windows build、driver、モデル、EP、アプリ実装を同じ組み合わせで検証します。

• Windows ML get started（公式） - CPUでの最小実行からNPU・GPU加速へ進む順番を見る
• ローカルAI用PCスペック - RAM・GPU・VRAM・CPUを購入判断として確認する
• Windows ARMローカルAI - ARM64アプリ、runtime、backendの境界を確認する

モデル配布は3方式に分ける：アプリ同梱・HTTPSファイル・package

Windows MLのModel Catalogは、モデル名、variant、対応EP、license、ダウンロード情報を記述し、モデルをアプリ間で共有する入口です。配布形式を先に決めると、モデルの更新、オフライン性、アプリサイズ、整合性確認のトレードオフを説明しやすくなります。

公式schemaでは、標準ONNXと関連ファイルのfile-based distribution、システム統合や依存関係を含むpackage-based distributionを分けています。catalogの一つのmodel定義は`files`または`packages`のどちらかを使い、両方を同時に指定しません。

{
  "id": "example-cpu-v1",
  "name": "example-model",
  "version": "1.0.0",
  "publisher": "YourOrganization",
  "executionProviders": [{ "name": "CPUExecutionProvider" }],
  "license": "Apache-2.0",
  "licenseUri": "https://example.com/license"
}

上のJSONは必須項目の考え方を示す簡略例で、実際のURI、license、SHA256、model filesは自分の配布物に合わせます。Model Catalogを作るときは、publisher、version、EP、license、download URIが実体と一致しているかschemaで検証します。

• Model Catalog API（公式） - 互換モデルの検索、ダウンロード、共有、状態確認を見る
• Model Catalog schema（公式） - files/packages、license、EP、SHA256の条件を見る

Windows ML Runtimeの配布：self-containedとframework-dependent

モデルの配布方式と、Windows ML Runtimeの配布方式は別の選択です。アプリへruntimeを同梱するか、端末の共有runtimeへ依存するかを決めた後で、モデル・EPの取得方法を組み合わせます。

公式資料のself-contained runtimeは約41MBの追加サイズ目安を示しますが、これはモデルやvendor EPの容量を含むアプリ全体の保証値ではありません。framework-dependentを選んでも、モデルcatalogやEPの初回取得が不要になるとは限りません。

• Install and deploy Windows ML（公式） - runtimeのself-contained・framework-dependentと対応言語を見る
• Windows MLのEP（公式） - in-boxとon-demand provider、Windows Updateの更新境界を見る

CPU・GPU・NPUのExecution Providerを選ぶ順番

Execution Providerは、ONNX Runtimeの演算をCPU、GPU、NPUなどの実行先へ渡す層です。同じPCにCPU、内蔵GPU、dGPU、NPUがあっても、モデルが対応し、driverがあり、アプリがそのEPを選ぶ実装でなければ、搭載しているだけでは使われません。

Microsoftは、EPを最初からDevice Policies任せにせず、まず明示的に選んで結果を予測しやすくする進め方を推奨しています。CPUで基準を作り、対象hardware用のEPを追加し、最後に電力や自然なdevice選択のpolicyを試す順番が現実的です。

1. 使うWindows build、architecture、GPU/NPU型番、driverを記録する。
2. Model Catalogまたは配布資料で、そのmodel variantが対象EPを宣言しているか確認する。
3. CPUExecutionProviderで出力と処理時間を保存する。
4. 対象EPを明示的に登録し、同じ入力・同じmodel revisionでCPUとの差を測る。
5. EPが無い、取得できない、出力が違う場合は、NPU TOPSやGPU使用率だけで成功と判定せず、OS・driver・model・ログを戻って確認する。

• Accelerate AI models（公式） - EPの取得方式とsilicon-to-EPの考え方を見る
• Select execution providers（公式） - 明示選択とDevice Policiesの順番を見る
• Copilot+ PCのNPUチェック - NPU搭載とアプリ側の対応を混同しない

Windows ML package familyとEP配布方式で対応範囲を決める

Windows MLのEP一覧はpackage family別です。現行資料の2.xと1.8.xは主要なproviderが共通ですが、WebGPUはexperimentalとして2.x側だけに掲載されています。また同じ一覧は、AMD MIGraphXについて現時点でGenAI scenarioをサポートしないと明記しています。PCのGPU/NPU名やModel Catalogのprovider宣言だけで、目的のmodelとアプリpackageの対応を確定しないでください。

Model Catalogはmodel variantと必要EPを記述する仕組み、ExecutionProviderCatalogは対応するproviderを端末へ取得・登録する仕組みです。別々のcatalogなので、modelのEP宣言だけでproviderのinstall、register、実推論成功まで確認済みとは扱いません。現在のEP versionはrelease historyのCurrentを見て選び、Upcomingやpreviewの予定は確定した配布版と区別します。

• Windows ML execution providers（公式） - 2.x / 1.8.xのEP差、device/driver条件、license、MIGraphXのGenAI境界を見る
• Windows ML EPs vs. bring-your-own（公式） - managed catalogとアプリ同梱のnetwork・update・pinning tradeoffを見る
• Install Windows ML execution providers（公式） - 初回download、ready state、install、registerの流れを見る
• Windows ML EP release history - package family別のcurrent versionを実装時点で確認する

モデルvariantとEPの互換性をModel Catalogで確認する

Model Catalogでは、同じ`name`の下にCPU向け、GPU向け、NPU向けなどのvariantを分け、各variantの`id`、version、publisher、license、対応EP、filesまたはpackagesを記述できます。アプリの表示名だけでmodelを固定せず、実際にロードしたvariant IDをログへ残します。

公式のModel Catalog手順は、model nameで検索して端末に合うvariantを自動選択する方法と、EPでフィルタする方法を示しています。自動選択が便利でも、productionの再現性や検証ログが必要なら、選択されたmodel ID、version、EP、driverを記録します。

• Model Catalog APIのベストプラクティス - catalog再利用、download進捗、compatibility、失敗処理を見る
• Windows MLの速度・RAM・VRAM実測 - 同じ入力でload・TTFT・generationを測る方法へ進む

オフライン・プライバシー・更新を工程ごとに分ける

Windows MLはモデル推論を端末内へ置けますが、アプリが一度も通信しないことを自動で保証する仕組みではありません。CDNからモデルを取得するcatalog、on-demandのvendor EP、Windows UpdateによるEP更新、package依存、ログ送信を分けて設計します。

1. ネットワークが使える検証環境でモデル・関連asset・EPを取得し、URIとversionを記録する。
2. 取得したファイルのSHA256、license、model ID、EP package IDを保存する。
3. ネットワークを切った状態で、同梱またはcache済みのmodelがCPU／対象EPで起動するか確認する。
4. EPが無い場合にCPUへfallbackするのか、機能を止めるのかをアプリで明示する。
5. 入力・出力・ログ・クラッシュ情報の保存先と外部送信を、Windows ML Runtimeとは別に確認する。

「self-containedだから完全オフライン」「NPUだからデータが外へ出ない」とは一般化しません。モデル配布、EP配布、推論、アプリ分析を一つずつ確認して初めて、利用者へ境界を説明できます。

• ローカルLLMの安全性とプライバシー - モデル、ログ、local server、外部APIの境界を確認する
• ローカルAIプライバシーの現実 - local処理と準備・同期・外部連携を分けて読む

用途別の最終判断：購入・開発・既製モデルを分ける

PCを買うだけならNPU TOPSやWindows MLのprovider表を先に追わず、使いたいアプリとモデルを決めます。自作アプリを配布するなら、モデル形式、EP、runtime、更新、ネットワーク、licenseまで管理できるかが判断軸です。

Windows MLは、Windows AI APIsやFoundry Localを置き換える万能なruntimeではありません。custom ONNXの制御が必要なときに選び、ready-to-use modelやWindows組み込み機能はそれぞれのownerへ戻すと、実装も記事の役割も混ざりません。

• Foundry Local Windows guide - ready-to-use modelとlocal APIの導入を見る
• Windows AI APIsのhardware matrix - APIごとのNPU・GPU・CPU条件を見る
• NPU・CPU・GPUでRAGを分ける - RAG工程の負荷を別レイヤーで確認する

失敗したときの切り分け表

GPU使用率やNPUの存在だけを成功の証拠にしません。ロードしたmodel ID、選択EP、driver、入力、出力、処理時間を同じ記録へ残して初めて、PC購入判断やアプリ配布の再現条件になります。

• ローカルAIが重い・動かない時 - 一般的なruntime・メモリ・保存先の切り分けへ戻る
• GPUなしPCで使える範囲 - CPU fallbackの現実的な期待値を確認する

公式確認日

情報確認日: 2026-09-28。MicrosoftのWindows AI solution comparison、Windows ML overview・get started・install and deploy、Accelerate AI models、supported execution providers、select execution providers、Model Catalog API・schema、ONNX Runtime GenAI、Windows ML CLIの公式資料を確認しました。provider、package、Windows build、driver、モデルcatalogは更新されるため、実装・配布時点の公式資料と実機検証を優先します。