Windows AIでまず押さえるべき結論は、Copilotの画面が変わるだけの更新ではなく、WindowsアプリにローカルAI、NPU、クラウドAPIを組み込むための開発基盤が「Microsoft Foundry on Windows」を中心に整理されたことです。開発者は Windows AI APIs、Foundry Local、Windows ML を使い分け、管理者は Copilot+ PCの要件、モデル配布、Windows App SDK、MCPの権限管理 を確認する必要があります。(Microsoft Learn)
特に企業環境では、「Windows AIを入れれば全端末で同じAI機能が動く」と考えると失敗しやすくなります。Windows AI APIsは主にCopilot+ PC向け、Foundry Localはより広い端末でのローカルLLM向け、Windows MLは独自ONNXモデルを扱うための基盤です。この記事では、2026年5月時点の公式情報をもとに、変更点、影響範囲、管理者・開発者が確認すべき設定と移行ポイントを実務目線で整理します。(Microsoft Learn)
Windows AIで何が変わるのか
Windows AIの大きな変更点は、AI機能が「Copilot単体」ではなく、Windowsアプリから使える複数のAI基盤として整理されている点です。現在の中心概念は Microsoft Foundry on Windows で、Windows AI APIs、Foundry Local、Windows ML、AI Dev Gallery、MCP on Windowsなどがその周辺に位置付けられています。(Microsoft Learn)
公式情報では、過去に使われていた「Windows Copilot Runtime」「Windows AI Foundry」などの名称も整理されています。現在の umbrella brand は Microsoft Foundry on Windowsであり、Microsoft Foundryというクラウド側のAIプラットフォームとは区別して考える必要があります。(Microsoft Learn)
| 観点 | 以前の捉え方 | 2026年時点で押さえるべき整理 |
|---|---|---|
| Windows AIの位置付け | Copilot関連機能の一部 | WindowsアプリにAIを組み込む開発基盤 |
| 主な対象 | エンドユーザーのAI体験 | 利用者、IT管理者、アプリ開発者 |
| ローカルAI | 端末ごとの差が大きい | NPU、GPU、CPUを前提に実装パターンを選ぶ |
| API選択 | 個別APIやクラウドAPI中心 | Windows AI APIs、Foundry Local、Windows MLを用途で選ぶ |
| 管理対象 | アプリやCopilotの有効化 | モデル、ランタイム、MCP接続、ログ、更新リングまで含む |
実務上のポイントは、「どのAI機能を使うか」よりも先に、「どの端末で、どのランタイムで、どのモデルを、どの権限で動かすか」を決めることです。ここを曖昧にしたまま展開すると、Copilot+ PCでは動くが一般PCでは動かない、仮想環境で検証できない、初回モデルダウンロードで詰まる、といった問題が起きやすくなります。
Windows AIを構成する主要要素
Windows AI APIsはCopilot+ PC向けの最短ルート
Windows AI APIsは、Microsoftが管理するローカルAIモデルをWindowsアプリから使うためのAPI群です。Phi Silica、OCR、画像説明、画像の超解像、オブジェクト消去、アプリ内コンテンツ検索、Video Super Resolutionなどが含まれます。モデルの探索や最適化を自前で行わず、少ないコードでAI機能を組み込みやすいのが利点です。(Microsoft Learn)
ただし、Windows AI APIsは主に Copilot+ PC を前提にしています。Copilot+ PCは高性能なNPUを備えたWindows 11世代のPCで、公式ガイドでは40TOPS超のNPUが説明されています。すべてのWindows 11 PCで同じAPIが動くわけではないため、対象端末の確認が必須です。(Microsoft Learn)
開発時は、GetReadyState() や EnsureReadyAsync() のような準備状態の確認を前提に設計します。モデルが未取得、未対応、または展開に失敗した場合に備えて、Foundry LocalやクラウドAPIへフォールバックする実装を用意しておくと、端末差による障害を減らせます。(Microsoft Learn)
Foundry LocalはローカルLLMを広い端末で使う選択肢
Foundry Localは、LLMをWindows端末上でローカル実行するための仕組みです。Windows AI APIsでカバーできないLLM用途や、Copilot+ PC以外も対象にしたい場合の候補になります。公式手順では、CLIのインストール、モデルカタログからのモデル取得、.NETやPythonからの利用手順が示されています。(Microsoft Learn)
注意したいのは、Foundry Localならどの環境でも快適に動く、という意味ではない点です。Windows向けのWinMLパッケージではDirectX 12対応GPUが前提として示されており、GPUパススルーのない仮想マシンでは期待どおり動かないケースがあります。モデルサイズ、初回ダウンロード、キャッシュ場所、社内ネットワークからの取得可否も事前に確認しましょう。(Microsoft Learn)
Windows MLは独自モデルやONNX移行の中核
Windows MLは、ONNX Runtimeを基盤にしたWindows向けのローカルAI推論フレームワークです。NPU、GPU、CPUの実行プロバイダーを活用し、PyTorch、TensorFlow/Keras、scikit-learnなどから変換したモデルをWindowsアプリで動かす用途に向いています。(Microsoft Learn)
既存アプリでスタンドアロンのONNX Runtimeを使っている場合、Windows MLへ移行すると、実行プロバイダーの取得や更新をWindows側に寄せられる可能性があります。ただし、ONNX Runtimeのバージョン互換、Windows App SDKの展開方式、C++ヘッダーの扱い、既存ランタイムとの共存を確認してから段階移行するのが安全です。(Microsoft Learn)
MCP on WindowsはAIエージェント連携の管理ポイント
MCP on Windowsは、AIアプリやエージェントが外部ツールやデータソースと連携するためのModel Context ProtocolをWindows上で扱う仕組みです。Windows On-device Agent Registry、つまりODRを通じて、ローカルアプリやリモートサーバーのMCPサーバーを発見・利用できるようにします。(Microsoft Learn)
管理者にとって重要なのは、MCPが単なる開発者向け機能ではなく、権限管理、ログ、監査の対象になる点です。公式情報では、ユーザーやIT管理者がWindows設定やMicrosoft Intuneなどの管理ツールを使って、各エージェントのMCPサーバーアクセスを制御できるとされています。(Microsoft Learn)
AI Dev Galleryは検証とサンプル確認に使う
AI Dev Galleryは、WindowsアプリにAI機能を組み込む開発者向けのオープンソースアプリです。ローカルAIモデルを使ったインタラクティブなサンプル、Windows AI APIsのサンプル、モデルのダウンロードや実行、C#ソースコードの確認、Visual Studioプロジェクトへのエクスポートに対応しています。(Microsoft Learn)
PoC段階では、いきなり社内アプリへ実装するよりも、AI Dev Galleryで対象APIやモデルの動作、端末ごとの速度、モデルのダウンロード要件を確認するほうが効率的です。ただし、Hugging Faceなど外部由来のモデルを使う場合は、モデルカード、ライセンス、Responsible AIの観点を確認する必要があります。(Microsoft Learn)
利用者への影響
利用者にとってのWindows AIの影響は、主に3つです。1つ目は、Copilot+ PCではNPUを使ったローカルAI機能が増えること。2つ目は、アプリによってはクラウドに送らず端末内で推論できる体験が増えること。3つ目は、端末性能やOSバージョンによって使えるAI機能に差が出ることです。(Microsoft Learn)
| 利用者の状況 | 期待できること | 注意点 |
|---|---|---|
| Copilot+ PCを使っている | Windows AI APIsを使うアプリで高速なローカルAI機能を利用しやすい | APIや機能ごとに対応状況が異なる |
| 一般的なWindows 11 PCを使っている | Foundry LocalやWindows ML対応アプリでローカルAIを使える可能性がある | NPU前提の機能は使えない場合がある |
| Windows 10環境が残っている | Windows MLや一部ローカルAI基盤の対象になる可能性がある | OSビルド、ランタイム、GPU要件の確認が必要 |
| 仮想デスクトップやVDIを使っている | 検証や一部アプリ利用は可能 | GPU/NPUパススルーがないとローカルAI検証に向かない場合がある |
「ローカルAIだから常に安全」と考えるのも危険です。モデルやランタイムの取得時にインターネット接続が必要な場合がありますし、アプリがログや利用データをどう扱うかは実装次第です。企業利用では、ローカル処理、クラウド連携、ログ、監査、ユーザー同意をまとめて確認する必要があります。
管理者が確認すべき設定・展開ポイント
Windows AIの展開では、端末、OS、ランタイム、アプリ、モデル、権限管理を分けて確認します。特にCopilot+ PC向け機能と一般PC向け機能を同じ計画で扱うと、検証結果が本番環境とずれる可能性があります。
| 確認項目 | 管理者が見るべきポイント | 失敗しやすい例 |
|---|---|---|
| 端末要件 | Copilot+ PCか、NPU/GPU/CPU構成、x64/ARM64 | 開発機では動くが一般配布PCで動かない |
| OSビルド | Windows 11 24H2相当以降が必要な機能がないか | OS更新リングが古くAPIやEPが使えない |
| Windows App SDK | フレームワーク依存か自己完結型か | ランタイム未導入でアプリが起動しない |
| モデル配布 | 初回ダウンロード、キャッシュ、社内プロキシ | オフライン環境でモデル取得に失敗する |
| Microsoft Store / winget | AI Dev GalleryやFoundry Local CLIの導入可否 | Store禁止環境で検証手順が詰まる |
| MCP | ODR、許可するMCPサーバー、Intune制御 | エージェントが不要なデータソースへ接続する |
| ログと監査 | MCP接続、AI応答、エラー、ユーザー操作 | 問題発生時に誰が何を実行したか追跡できない |
| Responsible AI | コンテンツフィルター、説明責任、年齢制限 | 生成・加工結果の扱いが社内規程に合わない |
| 仮想環境 | GPU/NPUパススルーの有無 | VDIでPoCして本番端末の性能を判断してしまう |
Windows MLの展開方式も重要です。公式情報では、Windows MLはWindows App SDKの一部として提供され、フレームワーク依存と自己完結型の2方式があります。フレームワーク依存はアプリサイズを抑えやすく、自己完結型は依存関係をアプリ側に含めるためバージョン管理をしやすい一方、サイズが増えます。(Microsoft Learn)
企業展開では、いきなり全社配布せず、OS更新リング、Windows App SDK Runtime、モデル取得経路、Intuneポリシー、EDRとの相性を含めて小規模パイロットを行うのが現実的です。
開発者が確認すべき移行・実装ポイント
開発者は、最初に「どのWindows AI基盤を使うか」を用途から決めます。判断基準はシンプルです。既製のAI機能をCopilot+ PC向けに早く実装したいならWindows AI APIs、LLMや音声系のローカル実行を広い端末で試したいならFoundry Local、独自モデルやONNXモデルを本格運用したいならWindows MLを選びます。(Microsoft Learn)
| 開発目的 | 第一候補 | 判断基準 |
|---|---|---|
| OCR、画像説明、画像補正などを短期間で追加 | Windows AI APIs | Copilot+ PCを対象にできるか |
| ローカルLLMをアプリに組み込む | Foundry Local | モデルサイズ、GPU、初回ダウンロードを許容できるか |
| 独自のONNXモデルを動かす | Windows ML | モデル変換、EP、配布方式を制御したいか |
| すべての端末でAI機能を維持したい | 複数方式の併用 | ローカル不可時のクラウドフォールバックが必要か |
| AIエージェントからアプリ機能を呼び出したい | MCP / App Actions | 権限、監査、アクション設計が整理できているか |
Windows AI APIsを使う場合は、APIが使える前提で画面や処理を組まないことが重要です。モデルが未準備のときは EnsureReadyAsync() で取得・準備が必要になる場合があります。準備中のUI、失敗時のメッセージ、代替処理を設計しておくと、ユーザー体験が大きく崩れません。(Microsoft Learn)
また、アプリのマニフェスト設定も見落としがちです。Windows AI APIsの利用では、systemAIModels capabilityを Package.appxmanifest に追加する手順が示されています。テンプレートから作っただけでは必要な権限が入っていない場合があるため、ビルドエラーだけでなく実行時エラーも含めて確認しましょう。(Microsoft Learn)
Foundry Localでは、モデル名をフルIDで固定するより、公式手順で示されているようにモデルエイリアスを使い、端末に応じて適切なハードウェア向けバリアントを選ばせる設計が実用的です。Pythonでは foundry-local-sdk-winml と foundry-local-sdk の混在による依存関係衝突にも注意が必要です。(Microsoft Learn)
Windows MLへ移行する場合は、既存のONNX Runtimeコードを一気に置き換えるのではなく、ONNX Runtimeのバージョン互換、Windows App SDKの展開方式、実行プロバイダーの取得方法を確認したうえで、モデル単位で段階的に移行するのが安全です。公式情報でも、既存のONNX RuntimeとWindows MLを一部共存させる移行が示されています。(Microsoft Learn)
App ActionsとMCPは「便利な連携」より先に権限設計が重要
App Actions on Windowsは、Windowsアプリが実装した個別の機能を、他のアプリや体験から呼び出せるようにする仕組みです。たとえば、テキスト翻訳、画像処理、ファイル操作のような再利用しやすい機能をアクションとして登録できます。(Microsoft Learn)
ただし、App ActionsやMCPは、AIエージェントに「何を実行させるか」を広げる機能でもあります。便利さだけで設計すると、ファイルアクセス、外部送信、誤操作、プロンプトインジェクションのリスクが高まります。アクションの粒度は小さくし、入力・出力の型、対象ファイル、実行権限、監査ログを明確にしましょう。(Microsoft Learn)
実装前に確認したい観点は次の通りです。
| 観点 | 確認すること |
|---|---|
| アクションの粒度 | 「社内資料を全部処理」ではなく「選択したファイルを要約」のように限定する |
| 入力データ | Document、Photo、Textなど、扱うエンティティを明確にする |
| 権限 | ユーザー操作なしに実行される範囲を制限する |
| 年齢・安全性 | 子どもが使う可能性がある機能では contentAgeRating などを検討する |
| 監査 | どのエージェントが、どのMCPサーバーやアクションを呼んだか記録する |
Windows AI導入で失敗しやすいポイント
Windows AIの導入で多い失敗は、機能名だけを見て判断してしまうことです。特に次の点は、企画・PoC・本番展開の各段階で確認しておきましょう。
| 失敗しやすいポイント | 回避策 |
|---|---|
| Windows AI APIsが全Windows PCで動くと思い込む | Copilot+ PC要件とAPIごとの対応状況を確認する |
| ローカルAIならネットワーク不要と考える | モデルやランタイムの初回取得、更新経路を確認する |
| NPU性能だけで端末を選ぶ | メモリ、GPU、ストレージ、バッテリー、対象モデルも見る |
| 開発環境だけで検証する | 実際の配布対象端末、標準ユーザー権限、社内プロキシで試す |
| DirectML前提の古い設計を続ける | Windows MLと実行プロバイダーの現在の方針を確認する |
| モデルの利用条件を確認しない | モデルカード、ライセンス、社内利用可否を確認する |
| 失敗時の処理を用意しない | NotSupported、モデル未準備、ダウンロード失敗時の代替経路を作る |
| MCPやApp Actionsを広く許可する | 最小権限、ログ、Intune管理、承認済み接続先に限定する |
特にDirectMLについては、現在のWindows AIの文脈ではWindows MLと実行プロバイダーを中心に考えるほうが自然です。公式の比較情報でも、DirectMLは従来の低レベルAPIとして位置付けられ、Windows ML側の実行プロバイダー管理が新しい方向性として示されています。(Microsoft Learn)
実務での進め方
Windows AIを社内または自社アプリに取り込む場合は、次の順番で進めると無駄な手戻りを減らせます。
| 手順 | 実施内容 | 成果物 |
|---|---|---|
| 現状把握 | 対象端末、OSビルド、GPU/NPU、Windows App SDK Runtimeの有無を棚卸し | 対象端末リスト |
| ユースケース分類 | OCR、要約、画像処理、検索、独自推論、エージェント連携に分ける | API選定表 |
| 小規模検証 | AI Dev Galleryやサンプルで端末ごとの動作を確認 | PoC結果 |
| 実装方針決定 | Windows AI APIs、Foundry Local、Windows ML、クラウドAPIの組み合わせを決める | アーキテクチャ図 |
| 管理設計 | モデル取得、MCP、ログ、Intune、更新リングを決める | 運用ポリシー |
| 段階展開 | 開発者、IT部門、一部ユーザーの順に展開 | パイロット結果 |
| 本番運用 | エラー率、推論時間、モデル更新、ユーザー問い合わせを監視 | 改善バックログ |
開発者だけでWindows AIを進めると、配布や権限で止まりやすくなります。一方、管理者だけで制御を強めると、アプリが必要なモデルやランタイムを取得できず、AI機能が使えません。早い段階で、開発、IT管理、セキュリティ、法務・コンプライアンスの確認ポイントを分けておくことが重要です。
まず確認すべきチェックリスト
Windows AI対応を始めるなら、最初に次の項目を確認してください。
- 対象ユーザーのPCがCopilot+ PCか、一般Windows 11 PCか、Windows 10 PCかを分ける
- 使いたい機能がWindows AI APIsで足りるか、Foundry LocalやWindows MLが必要かを判断する
- Windows App SDK、OSビルド、.NET、Visual Studio、Pythonなどの前提条件を確認する
- モデルの初回ダウンロード、キャッシュ、更新、オフライン利用可否を確認する
- MCPやApp Actionsを使う場合は、最小権限、ログ、Intune管理を先に設計する
- 本番展開前に、実配布端末と同じ権限・ネットワーク・セキュリティ製品で検証する
Windows AIは、単なる新機能ではなく、Windowsアプリの作り方と管理方法を変える基盤です。まずは「Copilot+ PC向けに既製APIを使うのか」「一般PCでも動くローカルLLMを使うのか」「独自モデルをWindows MLで運用するのか」を切り分けましょう。そのうえで、端末要件、モデル配布、権限管理、フォールバックを設計すれば、Windows AIを安全かつ現実的に展開しやすくなります。
コメント