Microsoftは米国時間2026年10月7日、Windows向けのローカルAI実行基盤「Windows ML」に、GGUF形式のAIモデルをllama.cppで実行できる実験的な機能を追加した。公式発表では、文章生成や音声認識に対応する新しいAPIと、その基盤となるWindowsネイティブの「Runtime API」も紹介している。これまでONNX形式を中心に展開してきたWindows MLで、GGUF形式の公開モデルもアプリに組み込めるようになった。ただし、共通のAPIでモデルを呼び出せることと、同じハードウェアですべての機能を利用できることは異なる。今回の変更を理解するには、モデル形式ごとの実行方法や、対応するハードウェアの違いを押さえる必要がある。
Windows MLがGGUFに対応、llama.cppのモデルをアプリに組み込み可能に
今回追加されたWindows MLの「Text Generation API」は、ONNX形式とGGUF形式の言語モデルに対応し、モデル形式に応じて適切な推論エンジンを選択する。
GGUF形式の場合はllama.cppを使用する。GGUFモデルをONNX形式に変換してから実行するわけではない。
従来のWindows MLでは、共通のモデル形式であるONNXと、各社のハードウェアに対応した「実行プロバイダー（Execution Provider）」を組み合わせる方式が中心だった。
実行プロバイダーとは、AIモデルの計算処理をCPUやGPU、NPUなどのハードウェアで実行するためのソフトウェアだ。
Windows側で実行プロバイダーの取得や更新を管理することにより、開発者がハードウェアごとに必要なソフトウェアを、すべてアプリへ同梱する負担を軽減できる。
従来のONNX Runtime APIは引き続きサポートされ、新しいRuntime APIと並行して提供される。
今回のGGUF対応によって、開発者はllama.cppで試していた言語モデルを、Windows MLを利用するアプリに組み込みやすくなる。
新しいText Generation APIは、入力された文章をモデルが処理できるトークンへ変換する作業や、生成結果を順次返すストリーミング出力、生成処理の中断などを担当する。
一方、使用するモデルの選定や配布は開発者が行う必要がある。
モデル形式によって、トークナイザーの扱いも異なる。ONNX形式ではモデルに対応したトークナイザーを別途用意する必要があるが、GGUF形式ではトークナイザーがモデルファイルに含まれているため、個別に準備する必要はない。
さらに、アプリの試作を容易にするため、OpenAIのAPIと互換性のあるローカルエンドポイントも用意された。
Microsoftが紹介した例では、「WinMLServer」を使ってGGUFモデルを起動し、OpenAI SDKの接続先をPC内のローカルアドレスに変更している。
これにより、開発者はクラウドのOpenAI APIで使い慣れた呼び出し方法を利用して、ローカルAIモデルを試せる。
ただし、APIの呼び出し方法に互換性があっても、クラウド上のOpenAIモデルと同等の性能や機能が利用できるわけではない。
もう一つの新機能が、開発者自身が用意したWhisperモデルを利用できる音声認識APIだ。
このAPIでは、ONNX形式のWhisperエンコーダーとデコーダー、トークナイザーを組み合わせ、音声をテキストに変換する。
さらに、認識したテキストをGGUF形式の言語モデルへ渡せば、音声入力と文章生成を組み合わせたアプリを構築できる。
Microsoftがモデルを管理する既存のWindows AI APIsとは異なり、使用するモデルを開発者が自由に選べることが特徴だ。
その代わり、モデルの配布や更新も開発者自身が担当する必要がある。
GGUFに対応しても、NPUで実行できるわけではない
今回追加されたRuntime APIと、文章生成・音声認識の各APIは、いずれも実験段階にある。
MicrosoftのRuntime API公式文書では、本番環境での利用はサポートされておらず、これらのAPIを使用したアプリをMicrosoft Storeに公開しないよう明記されている。
ただし、これはWindows ML全体が本番利用に対応していないという意味ではない。従来のONNX Runtimeを利用する仕組みは、引き続き正式にサポートされている。
今回のGGUF対応で特に注意したいのが、対応するハードウェアの違いだ。
Windows MLのGGUF対応で現在検証されている実行環境は、CPUとNVIDIAのCUDAであり、NPUには対応していない。
Windows ML全体ではNPUを利用できるものの、今回追加されたGGUFモデルの実行機能も、Copilot+ PCなどに搭載されるNPUで動作するわけではない。
MicrosoftのRuntime API文書と、Windows ML向けllama.cppパッケージの説明を基に、モデル形式ごとの違いを整理すると、次のようになる。
| モデル形式 | 実行エンジン | 対応するハードウェア | 実行に必要なソフトウェア |
|---|---|---|---|
| ONNX／ORT | ONNX Runtime | CPU、GPU、NPU。ただし、モデルや実行プロバイダーが対象機器に対応している必要がある | Windows MLが実行プロバイダーの取得・更新を管理 |
| GGUF | llama.cpp | 今回検証されているのはCPUとNVIDIA CUDA。NPUには非対応 | CPU用モジュールと、必要に応じてCUDA用モジュールをアプリ側で用意 |
※2026年10月8日時点の実験版Runtime APIに関する公式文書を基に整理したもの。処理速度の比較ではなく、llama.cpp本体が対応するすべてのハードウェアを示したものでもない。
ONNX形式についても、NPUに対応するからといって、どのモデルでもそのまま実行できるわけではない。
実際には、モデルが使用する演算や、実行プロバイダーの対応状況によって利用できるハードウェアが決まる。
一方、GGUF形式でCUDAを利用するには、対応するNVIDIA製GPUとドライバーが必要になる。
Windows ML向けのllama.cppパッケージでは、対応GPUが見つからない場合にCUDAを使用せず、CPUによる実行を利用できると説明されている。
つまり、共通のAPIを通じてモデルを扱えるようになっても、推論エンジンの配布方法まで統一されるわけではない。
GGUFモデルをアプリに組み込む開発者は、CPU用やCUDA用のモジュールをどのように配布するか、対象PCにどのようなハードウェアを求めるかを検討する必要がある。
これは、アプリの配布サイズや動作要件にも影響する。
なお、従来のONNX形式でも、ハードウェアによる制約は残る。
Windows MLの概要文書によると、NPUや特定のGPU向けに最適化された実行プロバイダーには、Windows 11 24H2以降が必要とされている。
新しいAPIが登場したからといって、すべてのWindows PCで同じように動作するわけではない。
ローカルAIアプリを開発する際には、モデル形式だけでなく、使用する推論エンジンと実行先のハードウェアを組み合わせて確認することが重要になる。
llama.cppの高速化機能が、すべて新APIで使えるわけではない
Microsoftは今回の発表で、NVIDIAやオープンソースコミュニティと協力し、llama.cppの性能改善にも取り組んできたと説明している。
具体的には、複数のGPU演算をまとめて実行するカーネル融合や、CPUとGPUの処理順序の最適化などが挙げられた。
さらに、Eagle-3、MTP、D-Flash2といった、文章生成を高速化する技術への対応も進められている。
ただし、これらは主にllama.cpp自体の機能改善であり、Windows MLのText Generation APIからすべて利用できるという意味ではない。
現在のText Generation APIの仕様を見ると、文章生成の制御には多くの制約が残されている。
例えば、現時点で対応している生成方式は「greedy decoding（貪欲法）」のみだ。
これは、文章を生成する際に、次のトークンとして最も確率が高い候補を毎回選択する方式である。
一方、一般的な言語モデルのAPIで利用されるtemperatureやtop-p、top-kなど、生成する文章の多様性を調整する機能には、まだ対応していない。
推測デコードやMTP（Multi-Token Prediction）も、Text Generation APIでは利用できない。
推測デコードは、生成されるトークンを先読みすることで、文章生成を高速化する技術だ。MTPも、複数のトークンを予測することで生成処理の効率化を図る。
llama.cpp側がこうした機能に対応していても、その機能がText Generation APIを通じて公開されていなければ、アプリから直接指定することはできない。
つまり、推論エンジンが持つ機能と、その上に構築されたAPIから利用できる機能は必ずしも一致しない。
同様の制約は、会話テンプレートや構造化出力にもある。
会話テンプレートは、ユーザーとアシスタントの発言を、使用する言語モデルが想定する形式に整えるための仕組みだ。
また、構造化出力は、JSONなどの決まった形式で結果を返すように制御する機能である。
現時点のText Generation APIでは、これらも未対応となっている。
そのため、単にモデルを読み込んで文章を生成するだけなら利用できても、複雑な対話機能や、厳密なJSON出力を必要とする業務アプリに組み込むには、追加の実装が必要になる場合がある。
対応するプログラミング言語にも制限がある。
現在のRuntime APIとText Generation APIはC++とPythonに対応しているが、C#はサポートされていない。
また、ONNX形式の文章生成モデルには、APIが想定する入出力構造を備えていることが求められる。
具体的には、入力トークンIDや出力ロジットに加え、過去の計算結果を保持するKVキャッシュや、現在の生成位置に関する状態を受け渡すための構成が必要だ。
したがって、ONNX形式のモデルファイルを用意するだけでは十分とは限らない。
使いたいモデルが、新しいText Generation APIの要求する構造に対応しているかを事前に確認する必要がある。
PyTorchとTritonで開発し、ONNXでアプリへ配布する
今回の発表では、GGUFやllama.cppへの対応だけでなく、Windows上でのAIモデル開発を支えるPyTorchやTritonの進展も紹介された。
ただし、PyTorchのWindows Arm64向けネイティブCPUビルドが、今回初めて提供されたわけではない。
Microsoftはすでに2025年4月、PyTorch 2.7でWindows Arm64向けネイティブビルドが利用できるようになったと発表している。
今回の説明では、このCPU向けビルドに加えて、NVIDIAが対応ハードウェア向けに提供するCUDA対応のWindows Arm64パッケージについても紹介された。
ただし、ArmベースのWindows PCであれば、どの機種でもCUDAを利用できるという意味ではない。
CUDAを利用するには、対応するNVIDIA製GPUなど、必要なハードウェアとソフトウェアがそろっている必要がある。
AIモデルの開発では、PyTorchが学習や追加学習を担い、TritonはGPUで効率よく計算を実行するためのコード生成に利用される。
Microsoftが紹介した例では、PyTorchのtorch.compileを利用し、複数の演算をTritonが生成するGPUカーネルにまとめている。
これにより、細かな演算を何度も個別に実行する負担を減らし、モデルの計算処理を高速化できる可能性がある。
ただし、開発環境でモデルを高速化することと、そのモデルをアプリに組み込んだ際に同じ性能を得られることは別の問題だ。
Microsoftの例では、開発したモデルをONNX形式に書き出し、Windows MLで実行できるようにしている。
このときONNX形式に書き出されるのは、モデルの計算処理を表すグラフであり、Tritonが生成したGPUカーネルそのものではない。
アプリで実行する際には、Windows MLの実行プロバイダーが、ONNX形式の計算グラフを対象ハードウェアで処理する。
つまり、PyTorchとTritonを使った開発環境で高い性能が得られても、ONNX形式に変換するだけで、その高速化が別のGPUやNPUでも再現されるとは限らない。
配布先のハードウェアに合わせた最適化や、実際の動作検証が必要になる。
その準備を支援するのが「Windows ML CLI」だ。
Windows ML CLIには、モデルを解析し、最適化や量子化、コンパイルを行う機能が用意されている。
モデルの計算グラフを対象ハードウェアに適した形へ変更し、対応する実行プロバイダー向けにコンパイルすることで、アプリでの効率的な実行を目指す。
最後にベンチマークを行い、実際の性能を確認することもできる。
Microsoftが紹介した開発例では、Arm64向けのPyTorch環境とは別に、Windows ML CLIを利用するためのx86_64版Python環境を用意している。
Windows上でモデルの開発から配布準備まで進められるようになっても、すべてのツールを同じ実行環境で動かせるとは限らない。
Tritonについても、対応するGPUやソフトウェアのバージョンに制約がある。
Windows向けTritonの対応表では、旧世代のNVIDIA製GPUアーキテクチャであるTuringとVoltaはTriton 3.2でサポートされているが、3.3以降では対応が打ち切られている。
PyTorchとTritonのバージョンにも互換性の条件がある。
したがって、AIモデルの開発からWindowsアプリへの組み込みまでを円滑に進めるには、対応するハードウェアに加え、各種フレームワークや開発ツールの組み合わせも確認する必要がある。
ローカルAIの実用化に向けて、モデルと実行環境の選択が重要に
今回追加されたRuntime APIでは、複数のAIモデルを組み合わせ、処理の段階ごとにCPUやGPU、NPUなどの実行先を指定できる。
Microsoftは、Windowsの画像や音声バッファーを効率よくモデルへ渡す仕組みや、事前にモデルをコンパイルすることで起動時間を短縮する機能も紹介している。
例えば、音声認識モデルで入力された音声をテキストに変換し、その結果を言語モデルへ渡して応答を生成するようなアプリでは、どの処理をどのハードウェアで実行するかを指定できることが重要になる。
処理内容に応じて実行先を選べれば、性能や電力効率を改善できる可能性がある。
ただし、今回追加されたGGUF形式の実行機能については、前述の通り、CPUとNVIDIA CUDAという制約がある。
Runtime API全体でNPUを選択できることと、GGUFモデルをNPUで実行できることは同じではない。
すでにONNX Runtimeを利用して本番アプリを開発・運用している場合は、従来の実行環境を維持しながら、必要な部分で新しいRuntime APIを試す方法が考えられる。
また、GGUF形式の公開モデルを利用するWindows専用アプリを試作したい開発者にとっては、今回の新機能が新たな選択肢になる。
一方、C#での開発やGGUFモデルのNPU実行、temperatureなどによる細かな生成制御を必要とする場合は、現時点の実験版APIだけでは要件を満たせない可能性がある。
ローカルAIには、クラウドにデータを送信せずに処理を実行できることや、クラウド推論で発生するトークン単位の利用料金を抑えられることなどの利点がある。
その一方で、モデルの配布や更新、必要なメモリーの確保、対象PCでの処理速度など、開発者が管理しなければならない項目も増える。
特にWindows PCは、CPUやGPU、NPUの構成が機種によって大きく異なるため、同じAIモデルでも実行できる機器や得られる性能に差が生じる。
今回のWindows MLの拡張によって、GGUF形式の公開モデルをWindowsアプリに取り込む選択肢は増えた。しかし、APIが共通化されたからといって、モデル形式やハードウェアによる制約がなくなったわけではない。
今回の進展で重要なのは、ONNXを中心とする従来の実行環境を維持しながら、llama.cppとGGUFを利用する新しい選択肢が加わったことだ。
今後、新しいRuntime APIが正式提供へ移行し、文章生成機能や対応ハードウェアが拡充されれば、開発者がさまざまな公開モデルをWindowsアプリへ組み込む際の負担はさらに軽減される可能性がある。
ただし、実際に利用する際には、対象PCでの起動時間やメモリー使用量、推論速度などを確認する必要がある。
GGUFモデルを手軽に試せるようになったことは一つの前進だが、それを幅広いWindows PCで安定して動くアプリへ発展させるには、モデルの選定から実行環境の最適化まで、引き続き慎重な検証が求められる。
