0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Microsoft Foundry on Windowsとは?WindowsアプリでローカルAIを扱うための基盤をざっくり整理する

0
Last updated at Posted at 2026-06-16

はじめに

fig_01.jpg

WindowsまわりのAI機能を追っていると、Microsoft Foundry on WindowsWindows AI APIsFoundry LocalWindows ML など、近い名前のものがいくつか出てきます。

以前は Windows Copilot RuntimeWindows AI Foundry という名称も使われていたため、古い記事や資料では複数の名前を見かけることがあります。2026年6月時点で、この記事では現在の総称である Microsoft Foundry on Windows を主に使います。

最初に見ると少し分かりにくいのですが、ざっくり捉えるなら Windows上でローカルAIを使うための開発者向けの土台 と考えると整理しやすいです。

この記事では、個人の整理メモとして、Microsoft Foundry on Windows が何を指しているのか、どの構成要素をどう見ればよいのかをまとめます。

なお、WindowsのAI機能はプレビュー・Experimental・対応ハードウェア依存の要素が多くあります。この記事は 2026年6月15日時点で確認した Microsoft Learn の情報をもとにした整理です。

まず結論

fig_03.jpg

Microsoft Foundry on Windows は、WindowsアプリにローカルAI機能を組み込むための仕組み群です。

公式ドキュメントでは Microsoft Foundry on Windows という名前で説明されており、主に次の3つの入口があります。

  • Windows AI APIs
  • Foundry Local
  • Windows ML

それぞれ役割が少し違います。

入口 ざっくりした役割 向いているケース
Windows AI APIs Microsoftが用意したローカルAI機能をAPIとして使う Copilot+ PCなどで、OCR・画像処理・Phi Silicaなどを素早く使いたい
Foundry Local OSS LLMや音声文字起こしモデルをローカルで動かす LLMやWhisper系のモデルを端末上で扱いたい
Windows ML ONNX Runtimeベースで任意のモデルを動かす 自前モデル、Hugging Face等のモデル、細かい制御が必要

つまり、Microsoft Foundry on Windows を1つの単体SDKとして見るよりも、WindowsでAIモデルを動かすための複数の選択肢をまとめた傘 と見るほうが理解しやすいです。

Microsoft Foundry on Windowsとは

fig_04.jpg

Microsoft Learn の Windows AI ページでは、Windowsアプリをより賢くするために、ローカルモデル、NPUハードウェア、リモートAPIを活用する方法が案内されています。

その中で Microsoft Foundry on Windows は、WindowsアプリにローカルAI機能を統合するための主要なソリューションとして説明されています。

できることを大きく分けると、次の3つです。

  • Microsoftが用意したAI機能をAPIとして使う: Windows AI APIs
  • OSSのLLMや音声モデルを選んでローカル実行する: Foundry Local
  • 自前またはONNX形式へ変換したモデルを柔軟に実行する: Windows ML

Foundry Localは、単にMicrosoftが用意した組み込みAPIを呼び出すというより、OSSモデルを選択・管理してローカル実行する入口として見ると分かりやすいです。

Windows AI APIs

fig_05.jpg

Windows AI APIs は、Windowsアプリから使えるAI機能のAPI群です。

公式ドキュメントでは、AI機能を使うために自分でモデルを探したり、実行したり、最適化したりしなくてもよいAPIとして説明されています。

代表的な例として、次のようなものがあります。

  • Phi Silica
  • Text Recognition、つまりOCR
  • Speech Recognition
  • Image Description
  • Image Generation
  • Image Super Resolution
  • Image Foreground Extractor
  • Image Object Extractor / Image Segmentation
  • Image Object Erase / Object Erase
  • Video Super Resolution
  • App Content Search

なお、公式ドキュメント内でも、概要ページでは Image Object ExtractorImage Object Erase、ハードウェア対応表では Image SegmentationObject Erase のように、近い意味の表記が併存しています。記事内では現在の個別API名を優先しつつ、「画像内の対象抽出」「画像内の対象削除」として大きく捉えています。

また、App Content Search はアプリ内のテキストや画像を索引化し、キーワード検索と意味ベースのセマンティック検索を提供する機能です。現時点では、AppContentIndexer は Windows App SDK 2.0 Experimental 4 の Private Preview として説明されています。そのため、Semantic Search を独立した正式API名のように扱うより、App Content Search の機能として説明するほうが自然です。

特に注意したいのは、対応ハードウェアです。

多くのAPIは Copilot+ PC のNPUを前提にしています。一方で、Speech Recognition と Video Super Resolution はCPUでも利用でき、Phi Silica は一部GPUにも対応しています。

ただし、Phi Silica のGPU対応は条件が具体的です。2026年6月時点の公式情報では、NVIDIA GeForce RTX 30シリーズ以降、6GB以上のVRAM、Developer Modeの有効化、Windows Insider Experimental Channel build 26300.8553以降、Windows App SDK 2.2.2-experimental9以降、GPUメーカーから直接入手した最新ドライバーが必要とされています。AMD GPU対応は coming soon とされています。

加えて、Phi Silica API は Limited Access Feature として提供されています。アプリから利用するには、Microsoftへの申請とLAFのunlock tokenが必要です。対応ハードウェアを持っていれば、すぐに一般公開アプリから自由に利用できるという状態ではない点にも注意が必要です。

また、Phi Silica と Image Description は中国では利用できない、という注記もあります。グローバル向けのアプリで使う場合は、この地域制約も確認しておく必要があります。

2026年6月時点では Experimental や Insider ビルド前提のものもあるため、実装時には必ず個別APIの対応状況を確認する必要があります。

Windows AI APIsが向いている場面

Windows AI APIs は、次のような場合に向いていそうです。

  • AI機能を短いコードで組み込みたい
  • モデルの配布や最適化をなるべくMicrosoft側に任せたい
  • Copilot+ PC向けのアプリ体験を作りたい
  • OCR、画像加工、超解像、要約など、既存APIで目的が足りる

逆に、独自モデルを細かく制御したい場合や、Copilot+ PC以外も広くサポートしたい場合は、Foundry Local や Windows ML も候補になります。

Foundry Local

fig_06.jpg

Foundry Local は、ローカル環境でLLMなどのモデルを動かすための入口です。

Microsoft Learn の現行整理では、Foundry Localは、Windows、macOS(Apple silicon)、Linuxで利用できるクロスプラットフォームのローカルモデル実行環境です。OSS LLMや音声文字起こしモデルを扱う選択肢として位置づけられています。

ただし、利用するSDKやパッケージ、実行経路によって要件が異なります。

一方、Microsoft.AI.Foundry.Local.WinML パッケージを使うWindows向け.NETクイックスタートでは、build 26100以降、つまり実質的にはWindows 11 24H2相当以降、.NET 9.0 SDK以降、DirectX 12対応GPUが前提条件として示されています。GPUパススルーのない仮想マシンも対象外です。

そのため、「Windows 10以降ならどの環境でも同じように動く」とは読まないほうがよさそうです。

Windows AI APIs が「用意されたAI機能をAPIで使う」イメージだとすると、Foundry Local は「ローカルLLMを選んで動かす」方向に近いです。

たとえば、次のような用途が考えられます。

  • アプリ内で文章を要約する
  • 自然言語の入力を構造化データに変換する
  • ローカルでチャットや補助機能を提供する
  • 音声をテキスト化する

クラウドAPIだけに寄せるのではなく、端末上で処理できる選択肢を持てる点がポイントです。

Windows ML

fig_07.jpg

Windows ML は、より低いレイヤーでモデルを動かすための仕組みです。

この記事で扱うWindows MLは、現在開発が進められているONNX Runtimeベースの新しいWindows MLです。Windows 10時代から存在する旧Windows ML APIとは区別して考える必要があります。

公式ドキュメントでは、Hugging Faceなどの外部モデル、自分で学習したモデル、その他のモデルを Windows 10以降のPCでローカル実行する選択肢として説明されています。

Windows MLはONNX Runtimeベースの文脈で語られており、モデルの互換性や性能はハードウェアに依存します。

OS要件も実行経路によって変わります。CPUおよびDirectMLによるGPU実行は、Windows App SDKが対応するWindowsで利用できます。一方、NPUや特定GPU向けのベンダー最適化Execution Providerには、Windows 11 version 24H2、つまり build 26100 以降が必要です。

Windows AI APIsやFoundry Localで足りる場合はそちらが近道ですが、次のような場合はWindows MLを検討することになります。

  • 自前のONNXモデルを使いたい
  • Hugging Faceなどから取得してONNX形式へ変換したモデルを使いたい
  • 特定ドメイン向けに学習したモデルを使いたい
  • モデル配布や推論制御をアプリ側で持ちたい
  • Windows 10以降を含めて対応範囲を設計したい
  • ただし、NPUや特定GPU向けのベンダー最適化Execution Providerには、Windows 11 24H2以降が必要

どう選べばよいか

fig_08.jpg

公式ドキュメントの考え方に寄せると、選び方は次の順で考えると分かりやすいです。

  1. 目的の機能が Windows AI APIs にあり、Copilot+ PC向けでよければ、まずWindows AI APIsを見る
  2. LLMや音声文字起こしをローカルで扱いたい場合は、Foundry Local を見る
  3. 独自モデルや既存モデルを柔軟に扱いたい場合は、Windows ML を見る

もちろん、実際のアプリではこれらを組み合わせることもありえます。

たとえば、画像の前処理はWindows AI APIs、文章の生成や整形はFoundry Local、業務固有の分類モデルはWindows ML、というような構成も考えられます。

Microsoft Foundryとの違い

fig_09.jpg

名前が似ているので、クラウド側の Microsoft Foundry と混同しやすいところです。以前は Azure AI Foundry という名称も使われていましたが、現在の公式ドキュメントでは Microsoft Foundry として整理されています。

かなり大ざっぱに分けると、次のように見るとよさそうです。

名前 主な場所 ざっくりした役割
Microsoft Foundry(旧 Azure AI Foundry) Azure / クラウド クラウド上でAIアプリやエージェントを構築・運用する
Microsoft Foundry on Windows Windows / ローカル端末 WindowsアプリにローカルAIを組み込む

どちらも「AIアプリを作るためのFoundry」ですが、中心にある実行場所が違います。

クラウド側のMicrosoft Foundryは、モデル、エージェント、ツール、評価、監視などをAzure上で扱うAIアプリ・エージェント開発基盤として見ると分かりやすく、Microsoft Foundry on WindowsはWindows端末上のローカルAI基盤として見ると分かりやすいです。

MCP on Windowsとの関係

image.png

Microsoft Foundry on Windowsと一緒に出てきやすいものとして、MCP on Windows があります。

MCP、Model Context Protocol は、AIアプリケーションと外部ツール・データソースをつなぐためのプロトコルです。

Microsoft Learn では、MCP on Windows は Windows On-device Agent Registry (ODR) を提供し、AIアプリやエージェントがローカルアプリやリモートサーバーのMCPサーバーを発見・利用するための仕組みとして説明されています。

ここは、次のように分けると理解しやすいです。

  • Microsoft Foundry on Windows: モデルやAI機能をWindows上で実行・利用するための基盤
  • MCP on Windows: AIアプリやエージェントが外部機能・データ・ツールへ接続するための基盤

たとえば、ローカルLLMがFoundry Localで動き、そのAIアプリがMCP on Windowsを通じてFile Explorerのコネクタにアクセスする、といった方向性が考えられます。

ただし、MCPは便利な一方で、権限・ユーザー同意・監査・プロンプトインジェクション対策などの設計が重要になります。公式ドキュメントでも、MCPに関する情報にはプレリリース製品に関する注意が付いています。

何がうれしいのか

Microsoft Foundry on Windowsの価値は、単に「AIが使える」ことではなく、Windowsアプリの中でローカルAIを扱いやすくする ところにあると思います。

具体的には、次のようなメリットが考えられます。

  • ネットワークに依存しにくいAI機能を作れる
  • レイテンシを抑えやすい
  • ユーザーデータを端末内に留めやすい
  • NPUやGPUなどのローカルハードウェアを活用できる
  • モデル配布やランタイムまわりの複雑さを一部吸収できる

もちろん、すべてをローカルで完結すればよいわけではありません。

重い推論、大規模な検索、業務データ連携、運用監視などはクラウド側のほうが向いているケースもあります。そのため、実際にはローカルAIとクラウドAIをどう分けるかが設計ポイントになりそうです。

実装時に気をつけたいこと

fig_02.jpg

現時点で触る場合は、以下の点に注意したほうがよさそうです。

対応ハードウェアを確認する

Windows AI APIsには、Copilot+ PCのNPUを前提にしたものがあります。

また、GPUやCPUに対応しているAPIでも、対応GPU、ドライバー、Developer Mode、Windows App SDKのバージョンなどの条件がある場合があります。

「Windows 11なら全部動く」と考えると危ないので、APIごとに対応表を見るのがよさそうです。

モデルの初回ダウンロードに注意する

Windows AI APIs の一部モデルは、初回利用時に EnsureReadyAsync などを通じてダウンロードされます。たとえば Phi Silica、AI Image Generation、CPU版 Speech Recognition などは、モデルが端末上にない場合にダウンロードが発生する可能性があります。

モデルによっては数GB規模になる可能性もあるため、ダウンロード前にサイズや通信の発生を案内し、ユーザーの同意を得るUXが重要になります。

一方、Foundry Local側では、モデルの取得やキャッシュ管理をWindows AI APIsとは別のSDKやCLIで扱います。EnsureReadyAsync は主にWindows AI APIs側の文脈として分けておくと、両者を混同しにくくなります。

AI出力は検証前提にする

AIモデルの出力は、ユーザーの意図と違う場合があります。

特にMCPのように外部ツールやファイル操作につながる場合は、権限・確認・監査ログ・管理者制御を含めた設計が重要になります。

プレビュー情報は変わる

Windows AIまわりは更新が速く、ExperimentalやInsider向けの情報もあります。

記事や実装メモを書く場合は、日付と参照したドキュメントを残しておくと、あとから見直しやすくなります。

まとめ

fig_11.jpg

Microsoft Foundry on Windows は、WindowsアプリでローカルAIを扱うための開発者向け基盤です。

整理すると、次のようになります。

  • Windows AI APIs は、Microsoftが用意したAI機能を素早く使う入口
  • Foundry Local は、OSS LLMや音声文字起こしモデルをローカルで扱う入口
  • Windows ML は、自前モデルや既存モデルを柔軟に動かす入口
  • MCP on Windows は、AIアプリやエージェントが外部機能へ接続するための仕組み
  • 対応ハードウェア、モデル配布、ユーザー同意、Responsible AI設計は要確認

個人的には、Microsoft Foundry on Windowsは「WindowsアプリにAIボタンを付けるための機能」というより、WindowsをローカルAIアプリの実行環境として整えていく流れ と見ると理解しやすいと感じました。

まずは Windows AI APIsFoundry LocalWindows ML の3つを分けて読むところから始めると、全体像がつかみやすそうです。

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?