Windows ML execution providersの2026年4月更新で最初に押さえるべき点は、Windows上のAI推論をNPU・GPU・CPUへ振り分ける実行基盤が、Windows UpdateとExecutionProviderCatalog APIを前提に運用される形へ整理されていることです。単に「対応GPUが増えた」という話ではなく、IT管理者はWindows 11のバージョン、ドライバー、Windows Updateポリシー、アプリ側のWindows MLバージョン、各EPのライセンスまで確認する必要があります。Microsoftの公式ドキュメントでは、Windows MLがNPU・GPU・CPU向けのexecution providerを提供し、対象EPはWindows 11 バージョン24H2、ビルド26100以降のPCで動的ダウンロードできると説明されています。(Microsoft Learn)
Windows ML execution providersで何が変わったか
Windows ML execution providersは、ONNX RuntimeでAIモデルを実行するときに、処理をCPU、GPU、NPUなどの適切なハードウェアへ渡すための仕組みです。Windows MLはONNX Runtimeとハードウェア向けに調整されたEPを組み合わせ、ローカル環境でのAI推論を高速化します。EPは、NPU・GPU・CPUといった計算基盤の違いをアプリ側から扱いやすくする役割を持ちます。(Microsoft Learn)
2026年4月更新で実務上重要なのは、次の3点です。
| 観点 | 2026年4月更新で見るべきポイント | 実務への影響 |
|---|---|---|
| 配布方式 | 対応EPはExecutionProviderCatalog APIで動的に取得・登録する前提 | アプリに全EPを同梱しない設計が取りやすい |
| 更新管理 | EPの更新版はWindows Updateの任意の非セキュリティプレビュー、いわゆるD week releaseで提供される | 管理端末では更新リングや検証タイミングの設計が必要 |
| 対応判断 | EPごとに対応チップ、ドライバー、ライセンス条件が異なる | 「Windows 11なら動く」と判断すると失敗しやすい |
Microsoft Learnでは、Windows MLに含まれるEPとしてCPUとDirectML、ただしDirectMLはlegacy扱いとされています。一方、MIGraphX、NvTensorRtRtx、OpenVINO、QNN、VitisAIなどは、対応端末・ドライバー条件を満たす場合にWindows MLのEPカタログから利用できる位置づけです。(Microsoft Learn)
2026年4月時点の対応EPとバージョン早見表
Windows ML execution providersは、Windows ML 2.x向けと1.8.x向けで表が分かれています。新規開発、既存アプリの保守、社内検証のどれを行うかによって、参照すべきバージョン表を間違えないことが重要です。
Windows ML 2.x向けの主なEP
| Execution provider | 主な対象ハードウェア | 現行バージョン | 次期予定バージョン | 管理上のポイント |
|---|---|---|---|---|
| MIGraphX（AMD） | AMD GPU | MSIX 1.8.55.0、2026 4D | MSIX 1.8.56.0、GPU EP Ver49、Insiders 2026 4E、GA 2026 5D | AMD GPU環境の検証向け。GenAI用途は現時点の対応状況を個別確認 |
| NvTensorRtRtx（NVIDIA） | NVIDIA GeForce RTX | MSIX 0.0.28.0、2026 4D | MSIX 0.0.33.0、Insiders 2026 4E、GA 2026 5D | RTX世代とドライバー条件の確認が必須 |
| OpenVINO（Intel） | Intel CPU・GPU・NPU | MSIX 1.8.69.0、OpenVINO 2026.0、2026 3D | MSIX 1.8.79.0、OpenVINO 2026.1、Insiders 2026 4E、GA 2026 5D | Intel系端末ではCPU、GPU、NPUのどこで使うかを分けて検証 |
| QNN（Qualcomm） | Snapdragon X系NPU | MSIX 2.2420.43.0、QAIRT 2.42、2026 4D | MSIX 2.2450.47.0、QAIRT 2.45、Insiders 2026 4E、GA 2026 5D | Copilot+ PCやWindows on Arm端末で重要 |
| VitisAI（AMD） | AMD NPU | MSIX 1.8.59.0、2026 4D | MSIX 1.8.62.0、EP 2705、Insiders 2026 4E、GA 2026 5D | AMD NPU搭載端末ではドライバー範囲に注意 |
Microsoftは、現行版として掲載されているEPのみがサポート対象で、Upcoming versionはプレビューでありリリースが保証されるものではないと明記しています。また、2026 4Dのような表記は「2026年4月のD週」を意味します。(Microsoft Learn)
Windows ML 1.8.x向けで注意すべき違い
既存アプリがWindows ML 1.8.xを使っている場合、2.x向け表だけを見ると判断を誤ります。特にMIGraphXは、1.8.xで利用する場合に必要なMicrosoft.WindowsAppSDK.MLの最小バージョン条件があります。
| Execution provider | 1.8.x向け現行バージョン | 次期予定 | 必要なMicrosoft.WindowsAppSDK.ML 1.8.x |
|---|---|---|---|
| MIGraphX（AMD） | MSIX 1.8.55.0、2026 4D | MSIX 1.8.56.0、GA 2026 5D | 1.8.2109以上 |
| NvTensorRtRtx（NVIDIA） | MSIX 1.8.24.0、2026 2D | 公式表では次期予定なし | 任意の1.8.x |
| OpenVINO（Intel） | MSIX 1.8.69.0、OpenVINO 2026.0、2026 3D | MSIX 1.8.79.0、OpenVINO 2026.1、GA 2026 5D | 任意の1.8.x |
| QNN（Qualcomm） | MSIX 1.8.30.0、QAIRT 2.40.0.251030、2026 1D | 公式表では次期予定なし | 任意の1.8.x |
| VitisAI（AMD） | MSIX 1.8.59.0、2026 4D | MSIX 1.8.62.0、GA 2026 5D | 任意の1.8.x |
既存の業務アプリを更新する場合は、「OSは条件を満たしているが、アプリ側のWindows MLパッケージが古くて対象EPを使えない」というケースが起こり得ます。MIGraphXのように最小パッケージバージョンが明示されているEPは、端末側だけでなくアプリの依存関係も確認してください。(Microsoft Learn)
D week releaseをどう読むべきか
Windows ML execution providersの更新は、Windows Updateの任意の非セキュリティプレビュー更新、いわゆるD week releaseと関係します。MicrosoftのWindowsクライアント更新サイクルでは、任意の非セキュリティプレビュー更新は通常、毎月第4火曜日に提供され、翌月の月例セキュリティ更新に向けた早期検証の機会とされています。(Microsoft Learn)
IT管理者にとっては、ここが重要です。
| 運用パターン | 判断 |
|---|---|
| 個人PC・開発機 | D week releaseで早めに検証しやすい |
| 社内の管理端末 | Intune、WSUS、Configuration Managerなどの更新ポリシーと整合させる |
| 本番アプリの配布先 | Upcoming versionを前提にせず、現行版で動作確認する |
| グローバル展開 | 地域ごとのWindows Update制御、ネットワーク制限、ドライバー配布方法を分けて確認する |
「GA予定があるから本番前提で組み込む」のではなく、現行版で動くフォールバック設計を作るべきです。特にAI推論は端末差が大きいため、D weekの更新を検証リングに流し、問題がなければ段階的に展開する運用が現実的です。
ハードウェアとドライバー要件で失敗しやすいポイント
Windows ML execution providersは、EP名だけを見ても導入可否を判断できません。同じメーカーのPCでも、世代、NPUの有無、GPUドライバー、Windows Updateの状態によって結果が変わります。
| EP | 主な要件 | よくある失敗 |
|---|---|---|
| MIGraphX（AMD） | GPUバージョン25.10.13.09が必要。Microsoft LearnではGenAIシナリオは現時点で未対応と記載 | AMD GPU搭載だけで動くと判断する |
| NvTensorRtRtx（NVIDIA） | NVIDIA GeForce RTX 30XX以上、推奨最小ドライバー32.0.15.5585、CUDA 12.5 | RTX 20系や古いドライバー環境まで対象に含めてしまう |
| OpenVINO（Intel） | CPUはTiger Lake、第11世代以降。GPUはAlder Lake、第12世代以降。NPUはArrow Lake、第15世代以降。各ドライバー条件あり | 「Intel PCならOpenVINOでNPUが使える」と誤解する |
| QNN（Qualcomm） | Snapdragon X EliteまたはSnapdragon X Plus、Qualcomm Hexagon NPU、NPUドライバー30.0.140.0以上 | Windows on Arm端末ならすべて対象と誤認する |
| VitisAI（AMD） | Adrenalin Edition 25.6.3から25.9.1、NPUドライバー32.00.0203.280から32.00.0203.297の範囲 | 最新ドライバーなら必ずよいと考え、対応範囲を確認しない |
特にVitisAIのように最小・最大のドライバー範囲が示されているEPでは、「最新にすれば解決する」とは限りません。社内検証では、PCモデル、SoC/GPU型番、NPU有無、ドライバーバージョン、Windowsビルド、EPバージョンをセットで記録しておくと、トラブル時の切り分けが速くなります。(Microsoft Learn)
IT管理者が導入前に確認すべきチェックリスト
Windows ML execution providersを社内端末や業務アプリに関係させる場合、確認すべき項目はアプリ開発だけに限りません。Windows Update、ネットワーク、ライセンス、端末調達まで含めて見る必要があります。
| 確認項目 | 確認する理由 | 実務での見方 |
|---|---|---|
| Windowsバージョン | EPカタログ経由の取得はWindows 11 24H2、ビルド26100以降が前提 | winverやデバイス管理台帳で対象端末を抽出 |
| Windows Updateポリシー | EP更新はWindows Update経由で提供される | Intune、WSUS、Configuration Managerの更新リングを確認 |
| ハードウェア構成 | EPごとにCPU、GPU、NPU、SoCの条件が異なる | PCモデル単位ではなく、実チップとドライバーで分類 |
| アプリのWindows MLバージョン | 2.x向けと1.8.x向けでEPバージョン表が異なる | NuGet依存関係とアプリの配布方式を確認 |
| 初回ダウンロード | EPが未導入の場合、初回にダウンロードが発生する可能性がある | ユーザー通知、進捗表示、ネットワーク制限時の挙動を設計 |
| ライセンス | EPごとにAMD、NVIDIA、Intel、Qualcommなどのライセンス条件がある | 本番利用前に法務・調達部門と確認 |
| オフライン端末 | Windows ML EPカタログ方式だけでは取得できない場合がある | Bring your own EP方式やハイブリッド構成を検討 |
Microsoftの比較資料では、Windows ML EPsはExecutionProviderCatalog APIで取得し、Windows Updateによる自動更新やアプリサイズ低減が利点とされています。一方で、管理端末、オフライン環境、厳密なバージョン固定が必要な場合は、EPをアプリ側に同梱するBring your own方式が選択肢になります。(Microsoft Learn)
開発・検証で使う基本フロー
Windows ML execution providersは、インストールしただけではONNX Runtimeから自動的に使えるとは限りません。実装側では、EPを探す、必要なら準備する、登録する、選択するという流れを組む必要があります。
端末で利用可能なEPを列挙する
まずExecutionProviderCatalog.GetDefault()でカタログを取得し、FindAllProviders()で利用可能なEPを列挙します。Microsoftのドキュメントでは、ReadyStateによってNotPresent、NotReady、Readyを判定し、それぞれ次のアクションを決める形が示されています。(Microsoft Learn)
var catalog = ExecutionProviderCatalog.GetDefault();
var providers = catalog.FindAllProviders();
foreach (var provider in providers)
{
Console.WriteLine($"{provider.Name}: {provider.ReadyState}");
}ReadyStateの考え方は次の通りです。
| ReadyState | 状態 | 次に行うこと |
|---|---|---|
NotPresent | EPが端末にインストールされていない | EnsureReadyAsync()でダウンロードと準備を行う |
NotReady | EPはあるが、アプリの実行時依存関係に追加されていない | EnsureReadyAsync()で利用可能な状態にする |
Ready | EPが利用可能 | TryRegister()または登録APIでONNX Runtimeに登録する |
本番アプリでは初回ダウンロードを制御する
開発時は、すべての互換EPをまとめて準備・登録するEnsureAndRegisterCertifiedAsync()が便利です。ただしMicrosoftは、初回実行時にネットワーク速度やダウンロード対象EPによって数秒から数分かかる可能性があると説明しています。(Microsoft Learn)
本番アプリでは、以下のような設計が安全です。
| 設計項目 | 推奨される考え方 |
|---|---|
| 初回起動 | いきなり大きなダウンロードを始めず、必要性をユーザーに伝える |
| 管理端末 | Windows Updateが制限されている可能性を前提にする |
| 進捗表示 | ダウンロード中であることを明示し、アプリが固まったように見せない |
| 失敗時 | CPU EPやDirectMLなど、利用可能なEPへのフォールバックを用意する |
| ログ | EP名、ReadyState、ドライバー、Windowsビルドを記録する |
登録後にONNX RuntimeでEPを選択する
Windows ML EPを端末に準備した後は、ONNX Runtimeで使えるように登録する必要があります。Microsoftの登録手順では、インストール済みのWindows ML EPをONNX Runtimeで使うためにRegisterCertifiedAsync()を使う方法が示されています。登録前の既定状態では、ONNX Runtimeに見えるEPは含まれているEPに限られる点にも注意が必要です。(Microsoft Learn)
var catalog = ExecutionProviderCatalog.GetDefault();
await catalog.RegisterCertifiedAsync();EPの選択では、最初から自動選択に任せるより、明示的にEPを選ぶ方が検証結果を安定させやすくなります。Microsoftも、まずは明示的なEP選択から始め、その後にDevice Policiesを試すことを推奨しています。また、Windows ML EPやドライバーが更新されると、利用可能なEPデバイス一覧が実行時に変わる可能性があるため、アプリは想定外のEP追加・消失に耐える設計にすべきです。(Microsoft Learn)
Windows ML EPsとBring your own EPの選び方
Windows ML execution providersの更新を見たとき、すべてのアプリがEPカタログ方式だけでよいとは限りません。管理端末やオフライン環境では、Windows Updateが制限されることがあります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Windows ML EPs | アプリサイズを抑えたい、Windows Update経由でEP改善を取り込みたい、Windows 11 24H2以降の一般利用者向けに展開したい | 初回ダウンロードにネットワークが必要。管理端末ではWindows Updateポリシーの影響を受ける |
| Bring your own EP | オフライン環境、厳密なEPバージョン固定、Windows Updateが制限された社内端末 | EPをアプリに同梱するためアプリサイズが増え、更新も自前で管理する |
| ハイブリッド | 通常はWindows ML EPsを使い、失敗時に同梱EPへフォールバックしたい | 実装と検証は複雑になるが、可用性は高めやすい |
Microsoftの比較資料では、Windows ML EPsはセットアップが簡単で、Windows認証済みEPをWindows Updateで自動更新できる一方、Bring your own方式はオフライン環境や厳格なバージョン管理に向くと整理されています。(Microsoft Learn)
パワーユーザーが確認すべきポイント
個人でAIアプリやローカル推論ツールを使う場合も、Windows ML execution providersの更新は無関係ではありません。アプリがWindows ML EPを使う設計なら、同じアプリでもPC構成によって体感速度が変わる可能性があります。
まず確認したいのは、次の4点です。
| 確認すること | 見るべき理由 |
|---|---|
| Windows 11 24H2以降か | EPカタログ経由の取得条件に関わる |
| GPU・NPUの種類 | NVIDIA RTX、Intel NPU、Snapdragon X、AMD NPUなどで対象EPが変わる |
| ドライバー | EPごとに最小バージョンや対応範囲がある |
| アプリの対応 | アプリがWindows ML EPを利用する実装になっていなければ、OS側だけ更新しても効果は出にくい |
「PCにNPUがあるのに速くならない」という場合は、アプリがNPU対応EPを選択していない、EPが未インストール、ドライバーが条件を満たしていない、Windows Updateが保留されている、といった原因が考えられます。ベンチマークだけで判断せず、アプリのログや設定画面で使用中のEPを確認できるかを見るのが近道です。
技術選定者が見るべき調達・設計上の判断基準
Windows ML execution providersの更新は、PC調達やAIアプリの標準環境を決める立場にも影響します。特にオンデバイスAIを業務に組み込む場合、「AI PC」や「NPU搭載」という表記だけで標準端末を決めるのは危険です。
| 判断軸 | 推奨される確認 |
|---|---|
| 標準PCの選定 | 利用予定アプリがどのEPに対応しているかを先に確認する |
| ベンダー分散 | Intel、AMD、Qualcomm、NVIDIAでEPとドライバー条件が異なるため、端末群を分けて検証する |
| アプリ配布 | Windows ML EPs方式か、Bring your own方式か、ハイブリッドかを決める |
| 更新管理 | D week releaseを検証リングへ流すか、本番リングでは月例更新まで待つかを決める |
| サポート体制 | 問い合わせ時にEP名、Windowsビルド、ドライバー、アプリバージョンを収集できるようにする |
グローバル展開では、地域や部門によってWindows Updateの制御、ネットワーク制限、端末ベンダーが異なることがあります。日本本社で検証した構成が、海外拠点の管理端末でそのまま動くとは限りません。EPカタログ方式を採用する場合は、Windows Updateの到達性とポリシーを展開国ごとに確認してください。
2026年4月更新を受けて次にやるべきこと
Windows ML execution providersの2026年4月更新は、AI推論の高速化そのものよりも、EPをどう配布し、どう検証し、どう本番運用に載せるかを考えるための更新と捉えるべきです。
まずは、対象端末がWindows 11 24H2、ビルド26100以降かを確認します。次に、利用予定アプリがWindows ML 2.xなのか1.8.xなのかを確認し、対応するEPバージョン表を見ます。そのうえで、GPUやNPUの型番、ドライバー、Windows Updateポリシー、ライセンスをチェックしてください。
開発・検証チームは、FindAllProviders()でEPを列挙し、ReadyStateを見て、必要なEPだけを準備・登録する流れを実装します。本番アプリでは、初回ダウンロード、失敗時のフォールバック、EPデバイス一覧の変化を前提にしておくことが重要です。
IT管理者や技術選定者は、D week releaseを使った早期検証リングを作り、問題がなければ段階的に展開する運用を検討しましょう。Windows ML execution providersは、端末側AIの性能を引き出す強力な仕組みですが、効果を安定して出すには、OS、ドライバー、アプリ、更新ポリシーをセットで管理する必要があります。
コメント