WindowsとNVIDIAで進むPhysical AI｜RTX Spark・Azure Local・製造業エッジ活用の現在地

Physical AIの現在地：ロボットだけでなくマルチモーダル現場AIへ広がる

Microsoft Build 2026では、Microsoft Foundry、Microsoft Fabric、Windows AI、Azure LocalといったMicrosoftのPhysical AI基盤の更新と、Surface RTX Spark Dev Box、NVIDIA RTX Sparkといったハードウェア面の発表が相次ぎ、Microsoft × NVIDIA連携、ローカルAI実行基盤、ロボティクスのエージェント化を横断する動きが示されました。

Build 2026前後の動向を踏まえると、Physical AIの実装ではロボティクスに加えて、映像・音声・PDF・センサーデータといったマルチモーダルデータを扱う基盤も重要な要素になりつつあります。

製造装置のセンサーストリーム、保守マニュアルのPDF、検査ライン上のカメラ画像など、物理世界に紐づく非構造化データを丸ごとエージェントから扱う仕組みが、ロボティクスの議論と並列に進んでいる構図です。

Physical AIが扱う範囲の拡張

Build 2026のテーブルセッション「The Intelligence grid: Agentic AI for Real-World Robotics（TT652）」では、ロボティクスシステムが「スクリプト型の自律」から「適応的・意思決定型の振る舞い」へ移行している様子が議論されました。General Roboticsの共同創業者は、エージェント型アーキテクチャがロボットアーム、移動ロボット、ドローンといったヘテロジニアスなハードウェア横断で、reason・plan・collaborate・actを行う仕組みを実現していると説明しています。

別のテーブルセッション「Multimodal data: Architecting pipelines that don't break at scale（TT655）」では、企業データの大きな割合を動画・音声・PDF・センサーストリームといったマルチモーダル形式が占める現状が、議論の起点になりました。企業活動では、構造化データだけでなく、製造現場のセンサーデータ、品質検査のカメラ画像、保守マニュアルのPDF、コールセンターの音声ログといった非構造化／マルチモーダルデータも多く扱われています。

これらをそのままAI推論に流そうとすると、従来のバッチ型パイプラインでは処理が追いつかず、CPUとGPUの待ち時間やI/Oボトルネックが課題になる点が、TT655セッション内で指摘されています。

Microsoft × NVIDIA連携の三本柱：Foundry・Omniverse・Fabric

Microsoft × NVIDIA連携のイメージ 引用:NVIDIA

2026年3月のNVIDIA GTCで発表されたMicrosoftとNVIDIAの連携は、Build 2026にかけて実装段階へ進み、Microsoft FoundryとMicrosoft Fabricを軸に、NVIDIA Omniverseが補完要素として組み合わさる三本柱で整理できます。

Build 2026では、この連携を「Windows AI PCからAzureクラウドまでをつなぐ統一スタック」として位置づけ直す発表が続きました。

Microsoft Foundry × NVIDIA Nemotronモデル

Microsoft Foundryは、エンタープライズスケールでAIエージェントを構築・運用するための基盤として提供されています。GTCでは、NVIDIA NemotronモデルがFoundryを通じて利用可能になることが発表されました。
Foundry Agent Serviceの一般提供とFoundry Control PlaneのObservability機能により、開発者は推論・計画・実行を行うエージェントを本番運用レベルで構築できます。

続くBuild 2026では、NVIDIA側からも新発表が示されました。Physical AI向けの完全オープンなオムニモデルNVIDIA Cosmos 3、推論モデルNVIDIA Nemotron 3 Ultra、セキュアなエージェント実行ランタイムNVIDIA OpenShellなどです。

Microsoft FoundryやAzure AIインフラとNVIDIA側のモデル・実行環境を組み合わせると、Physical AI用エージェントのモデル選定や実行場所の選択肢が広がります。

Microsoft Fabric × NVIDIA Omniverse

Microsoft FabricとNVIDIA Omniverseライブラリの統合は、ライブの運用データと、物理的に正確なデジタルツインおよびシミュレーションを接続する仕組みです。これにより、製造業や運用領域の組織は、ダッシュボードやアラートを越えて、機械・施設・ワークフロー全体でのAI駆動アクションへ移行できるようになります。

工場のセンサーデータがFabricに流れ込み、Omniverse上のデジタルツインで現場の状況を立体的に再現し、AIが次に取るべきアクションを判断する。こうした流れが、実用的な構成として整いつつあります。

Azure AIインフラとPhysical AI Data Factory Blueprint

Azure側のインフラは、Vera Rubin NVL72や液冷型Grace Blackwell GPUの大規模展開により、推論集約・推論ベースのワークロードに最適化されてきています。MicrosoftはPhysical AI Data Factory BlueprintとFoundryの統合により、物理資産・シミュレーション・クラウド学習環境を、繰り返し可能なエンタープライズパイプラインとして接続できるようにしました。あわせて、Microsoft公式GitHubには、Azure Physical AI Blueprintを検証するためのツール群としてPhysical AI Toolchainが公開されており、Blueprintをローカル開発・検証に落とし込む際の参考になります。

Build 2026ではこの連携が「Windows devicesからDGX Station for Windows、Azureクラウドまでをつなぐ統一スタック」として整理されています。製造業の文脈では、Microsoft Foundry／Microsoft Fabric／Azure Local／Windows AIを主軸にした実行基盤の上で、NVIDIA側のモデルやGPUが補完的な選択肢として加わる構図と捉えると理解しやすくなります。

三本柱の意味するところは、「モデル」「データと現実世界の接続」「インフラとパイプライン」の3層でPhysical AIを扱う仕組みが、相互に噛み合った形で揃いつつある点です。次のセクションからは、この三本柱が具体的にどうWindows PCやオンプレ拠点へ降りてくるのかを見ていきます。

NVIDIA RTX Spark：Windows PCに来るPhysical AI実行環境

Build 2026の直前に発表されたNVIDIA RTX Sparkは、Windows PC側にPhysical AIの実行環境を持ち込むスーパーチップです。Build 2026で示されたWindows AI路線の前提となるハードウェアとして位置づけられます。

RTX Sparkの概要と提供時期

RTX Sparkは最大1ペタフロップ級のAI演算性能と最大128GBのユニファイドメモリを備え、Windows PC側でローカルAI実行を行うためのスーパーチップとして位置付けられます。2026年秋から、Microsoft Surfaceを含む複数のOEMが搭載モデルを順次提供する予定です。

これまでクラウドGPUでしか扱えなかった規模のモデルをローカルで動かす道が開かれた、というのが本発表の中心的な意義です。

NVIDIA RTX Sparkのイメージ 引用：Microsoft Windows Blog

Microsoft Foundry on Windows / Foundry Localとの接続

RTX Sparkを搭載したWindows PCでは、ローカルAI実行の選択肢としてMicrosoft Foundry on Windowsが想定されます。Windows AI公式概要ページでは、Microsoft Foundry on Windowsの構成要素として、Windows AI APIs、Foundry Local、Windows MLが整理されています。Windows MLを介したONNX Runtime実行と、Foundry LocalによるLLMのローカル実行が、一貫した構成として位置付けられている内容です。

RTX Sparkは「ハードウェアとしてのPhysical AI実行環境」を、Microsoft Foundry on Windowsは「ソフトウェアとしての実行レイヤー」を担う役割分担になります。

個別のSKU別性能や提供価格、リリース順序は、OEM各社のプロダクトページやWindows Experience Blogで更新される領域です。

Surface RTX Spark Dev BoxとProject Solara：エージェント開発機とagent-first devices

Build 2026では、Microsoft自社のSurface RTX Spark Dev Boxと、エージェント中心のデバイスプラットフォームProject Solaraも発表されました。前者はPhysical AI／エージェントを「作る側」、後者は「動かす側」を担う構成です。

Surface RTX Spark Dev Box

Surface RTX Spark Dev Boxは、NVIDIA RTX Sparkスーパーチップを搭載したAI開発向けWindowsミニPCです。

Surface RTX Spark Dev Box 引用：Microsoft Devices Blog

主な特徴を以下に整理します。

対応モデル規模やトークンコンテキスト、熱設計などの詳細仕様は、製品提供後に公開される正式スペックでの確認が前提となります。

「デスク上に置く1ペタフロップ級のAI演算機」という構成は、クラウドGPUに寄せがちだったエージェント型AIパイプラインの検証、ローカルでの大規模モデル実行、モデル微調整を、現場の開発機に持ち込むことを意味します。Microsoft Foundryがローカルから本番までを統合的に扱えるため、Surface RTX Spark Dev Boxでローカル試作を行い、そのままAzure側にスケールアップするという流れも組みやすくなります。

製造業の文脈では、装置メーカーや電子部品メーカーの設計現場で、開発検証機として配備するパターンが想定されます。

Project Solara：agent-first devicesのプラットフォーム

Build 2026のキーノートでMicrosoft Technical FellowのStevie Bathiche氏が紹介したProject Solaraは、エージェント中心のデバイスを支える新しいプラットフォームです。概要は次のようになります。

• chip-to-cloudプラットフォーム：デバイスとクラウドの境界を越え、エッジに軽量な「窓」、Azure側に状態管理を置く構成
• MDEP（Microsoft Device Ecosystem Platform）：AOSPベースのOSで、デバイスメーカーが立ち上げやすいよう整備
• Agent Shell：ローカル／クラウドのエージェントを動的に呼び出すシェル

Project Solaraのプラットフォーム構造 引用：Microsoft commandline

想定デバイスは、バッジ型のポータブル端末や、デスクに置く固定型端末など、用途・ワークフローに特化した小型・専用デバイスです。マルチモーダル設計が前提となっており、グランス可能なディスプレイ、音声、ビジョンで必要なエージェントを呼び出します。Microsoft Intuneや Microsoft Entra IDを用いた管理基盤に加え、QualcommやMediaTekのシリコンを用いたコンセプト／リファレンスデザインも示されています。コンセプトデザインをもとに、Microsoft社内での利用と、業界リーダーとのprivate pilot開始予定が示されています。

Dev BoxとSolaraの関係

両者は「agent-first」というビジョンを共有しつつ、役割が分かれています。Surface RTX Spark Dev Boxはエージェントを作る側の開発機、Project Solaraはエージェントを動かす側のデバイスプラットフォームです。

Build 2026のMicrosoftは、強力な開発機（Dev Box）でエージェントを作り、Solaraを搭載した多様な専用デバイスでエージェントを動かすというPhysical AI／Agentエコシステムの形を示しました。Project Solaraの提供条件や製品化時期は未公表のため、今後の公式発表で確認が必要です。

Azure Local：拠点・工場でPhysical AIを動かす実行基盤

拠点や工場でPhysical AIを動かす際の実行基盤として位置付けられるのがAzure Localです。

ここではBuild 2026前後で示された追加要素とPhysical AIへの関係を確認します。

Sovereign Private Cloud向けスケール拡張

Azure Localは、単一のSovereign Private Cloud環境で数千サーバー規模までスケールできるようになりました。技術的にはdisaggregated deploymentsとSANストレージを採用し、エッジ拠点の小規模ノードから、政府機関・防衛関連・規制業界が要求する大規模プライベートクラウドまでを1つのスタックでカバーします。

従来は数百単位のノード構成が中心でしたが、今回のスケール拡張により、政府機関・防衛関連・規制業界などが要求する大規模プライベートクラウドも単一スタックで扱えるようになりました。AT&Tのような大規模通信事業者がミッションクリティカルな基盤をAzure Local上で運用する事例も同発表内で紹介されています。

製造業の文脈では、複数の拠点を跨いだAzure Local展開を「拠点ごとに小さく、合計では大規模に」という方針で進めやすくなります。

Foundry Local on Azure Local：multinodeとvLLM対応

Build 2026ではFoundry Local on Azure Localのプレビューが公開されました。Build 2026の更新点は次の通りです。

• multinodeデプロイメント対応：シングルノードからマルチノードへスケールアウト可能
• vLLMランタイム対応：高スループットなLLM推論が可能
• NVIDIA RTX PRO 6000 Blackwell Server Edition対応：オンプレ側でも高性能なGPU推論基盤を構成しやすくなる
• Azure Arc経由のオーケストレーション：エッジ・ハイブリッド・完全切断環境を横断管理

これにより、Azure Local上でFoundry Localを動かし、その上でPhysical AI向けのモデルを推論する構成が採りやすくなりました。

Foundry Local on Azure Localの構成要素の概要図 引用：Microsoft Tech Community

Foundry Local on Azure Localの発表では、Chevronがリモート拠点や洋上プラットフォームなど、接続制約や安全要件の強い現場でAIを動かす例が紹介されています。

こうした現場では、Azure LocalとFoundry Localを組み合わせるローカル実行基盤が、クラウド依存を抑えながらAIを展開する選択肢になります。

Azure Local for Small Form Factor Devices

Build 2026ではAzure Local for Small Form Factor Devicesがpublic previewとして発表されました。
これは産業用PCや耐久化デバイスといった小型機器向けにAzure Localを拡張するもので、製造業や小売エッジの配置向けにターンキーAI推論とAzure側からのデバイス管理を提供します。

Microsoft Learnでは、Small Form Factor Deployments of Azure Localのプレビュー機能として、ASUS NUC 14 Pro／15 Pro、Lenovo ThinkEdge SE30／SE100、OnLogic HX521が検証済みデバイスとして示されています。

本構成では仮想化レイヤーを介さない軽量なスタックを取ることで、AKS（Azure Kubernetes Service）、Foundry Local、Azure IoT Operationsといったコンポーネントを、工場や小売エッジに置く小型機器上に直接持ち込める設計になっています。

Azure Local for Small Form Factor Devicesの軽量アーキテクチャ 引用：Microsoft Tech Community

工場ラインに沿った産業用PC上でFoundry Localが動き、ローカル推論の結果をAzure側の管理面へ集約する流れが採りやすくなります。製造業の現場で「センサーデータをそのまま全部クラウドに送らず、まずローカルで判定する」というアーキテクチャを実装する際に、有力な選択肢になると考えられます。

ロボティクスのエージェント化：OM1・StackChan・General Robotics

Build 2026のロボティクス関連セッションでは、「スクリプト型自律」から「エージェント型」へのパラダイム転換が繰り返し取り上げられました。

OM1：ハードウェア非依存のorchestration layer

Build 2026のデモセッション「OM1: Modular by Design, Hardware-Agnostic by Default. Your gateway to next-gen robotics（DEM306）」では、OM1という新しいオーケストレーション層が紹介されました。OM1は、ロボットが本来持っている独自のスタック・ハードウェア・インターフェースを跨いで、AIの認知インフラと接続するためのモジュラー・ハードウェア非依存の中間層です。

セッションではUnitree Go2を用いたライブデモが行われ、クラウドシミュレーター上での挙動も示されました。ロボットごとのSDKに依存せず、必要なcapabilityをモジュールとして付け替えできる設計が特徴です。

StackChan：手のひらサイズのAIロボット

ライトニングトーク「Building an AI Robot 'StackChan' with GitHub Copilot and Foundry（LTG469）」では、手のひらサイズのオープンソースAIロボット「StackChan」の構築事例が紹介されました。組み込み開発の初心者が、GitHub Copilot、Microsoft Foundryのgpt-realtimeモデル、.NETを組み合わせてPhysical AIロボットを実装したというストーリーです。

エンタープライズ用途ではないものの、Foundryの音声リアルタイムAPIがロボティクスの開発体験をどう変えるかを示すサンプルとして参考になります。

General RoboticsのAgentic Architecture

テーブルトーク「The Intelligence grid: Agentic AI for Real-World Robotics（TT652）」では、General Roboticsの共同創業者が、エージェント型アーキテクチャを本番環境のロボットに適用するアプローチを紹介しました。

エージェント型アーキテクチャでロボットが行う動作の中心は、以下の4つです。

• Reason：状況を推論する
• Plan：行動計画を立てる
• Collaborate：他のロボットや人と協調する
• Act：物理的なアクションを実行する

これをロボットアーム、移動ロボット、ドローンといったヘテロジニアスなハードウェア横断で適用する点が、従来のロボットコントローラーとの大きな違いです。スクリプト型自律では「決められた動作を決められた順番で行う」のに対し、エージェント型では状況の変化に合わせて行動を組み替えていきます。

Foundry Agent ServiceとAgent Toolkitの役割

ロボティクスのエージェント化を支える基盤として、Microsoft FoundryのFoundry Agent ServiceとNVIDIAのAgent Toolkitが用意されています。Microsoft × NVIDIA Build 2026共同発表では、Foundry Agent ServiceとAgent Toolkitの組み合わせによって、Microsoft Foundry上で本番運用レベルのエージェントを構築する経路が示されました。構築したエージェントを実際にデバイス側で動かす段階では、WindowsデバイスではMicrosoft Foundry on WindowsやFoundry Local、オンプレミス拠点・ハイブリッド・ソブリン環境ではFoundry Local on Azure Localを通じてローカル展開する構成が用意されています。

これにより、ロボティクスのソフトウェアスタックでも、ロボットごとの制御実装だけで完結させるのではなく、Foundry Agent Serviceでエージェントを構築し、OM1のような中間層やFoundry Local系の実行基盤と組み合わせる設計を検討しやすくなっています。

マルチモーダルデータパイプライン：現場データを扱うアーキテクチャ

Physical AIを支えるもう一方の柱が、マルチモーダルデータパイプラインの設計です。Build 2026では、動画・音声・PDF・センサーストリームを継続的に処理するためのデータ基盤も重要な論点として扱われました。

TT655で示されたマルチモーダルデータ処理の課題

テーブルトーク「Multimodal data: Architecting pipelines that don't break at scale（TT655）」では、企業活動で扱うデータのうち、非構造化マルチモーダル形式が大きな割合を占める現状が議論の起点になりました。動画・音声・PDF・センサーストリームといった形式のデータです。

企業活動では、構造化データだけでなく、製造現場のセンサーデータ、品質検査のカメラ画像、保守マニュアルのPDF、コールセンターの音声ログといった非構造化／マルチモーダルデータも多く扱われています。

これらをそのままAI推論に流そうとすると、従来のバッチ型パイプラインでは処理が追いつかないことが、TT655セッション内で課題として共有されました。CPUとGPUの待ち時間やI/Oボトルネックがスループットを律速する論点も、同セッションで取り上げられています。Build 2026にあわせて、Anyscale on AzureはAKS上のpublic previewとして発表されており、Ray Dataによるストリーミング型CPU + GPUエンジンをAzure環境で動かすための公式経路も整っています（Ray Data自体の設計指針はAnyscale公式ブログに補足あり）。

Rayを中核にしたAnyscale on AzureのAIライフサイクル 引用：Microsoft Tech Community

Ray Dataによるストリーミング型CPU + GPUエンジン

セッションでは、AnyscaleがRay Dataを用いて構築したストリーミング型CPU + GPUエンジンが紹介されました。狙いを整理すると以下のようになります。

• バッチ型ではなくストリーミング型で、大量のマルチモーダルデータを継続的に流し込む
• CPUとGPUの橋渡しを最適化し、GPU稼働率を上げる
• 自動運転（AV）やPhysical AIチームのワークロードをAzure上でスケールする

製造業に置き換えると、ライン上のカメラ画像と振動センサーの流入を常時推論し続けるためのデータ基盤として機能します。バッチで深夜にまとめて集計するのではなく、現場で即時に判定する構成です。

Foundry LocalのOn-Device APIとマルチ言語音声認識

エッジ側で扱うマルチモーダル処理についても、Build 2026で強化が入りました。Foundry Localには40以上の言語に対応したNVIDIA Nemotron 3.5 ASR Streaming Multilingualモデルが統合され、リアルタイムの音声認識をオンデバイスで実行できるようになっています。

一方、GitHub Copilot CLIにもローカル音声入力が追加され、初回に音声認識用のruntimeとモデルをダウンロードする設計です。

加えて、現場の運用で必要になる細かな制御も追加されました。C#、Python、JavaScript、Rust、C++の5つのSDKに対して、モデルおよび実行プロバイダーのダウンロードキャンセル、進行中の推論キャンセルといった操作が利用できます。

製造業エッジAIの想定ユースケース

ここまでの動向を製造業の文脈に当てはめると、エッジAIの想定ユースケースは半導体製造装置、電子部品、FA・制御系の3領域に分けて整理できます。以下は公式発表とセッション情報をもとに想定した適用パターンであり、実装にあたっては個別要件に応じた検証が必要です。

半導体製造装置メーカー

半導体製造装置メーカーは、リアルタイム性が要求される検査や、装置挙動を解釈するセンサー解析が中心です。

• ライン上の検査画像によるリアルタイム不良検知：開発・検証段階はRTX Spark搭載開発機で行い、産業ラインの本番運用は Azure Local + RTX PRO 6000 Blackwell Server Edition の組み合わせでFoundry Localの推論ランタイムを動かす構成
• 装置センサーデータのマルチモーダル解析：振動・温度・電流などのストリームをストリーミング型のデータパイプラインで処理し、異常パターンを早期検知
• 装置稼働ログ × Fabric × デジタルツイン：FabricとOmniverseの連携で、装置の挙動をデジタルツイン上で再現し、エージェントが対処策を提案

装置1台あたりの判定遅延をミリ秒単位まで詰める必要がある場合や、通信量・機密性の要件が厳しい場合は、エッジ・拠点で推論し、必要な情報だけをクラウドへ集約する分担構成が有効です。Azure LocalやFoundry Localのように、拠点側で動く実行基盤がその中心に据わります。

電子部品メーカー

電子部品メーカーでは、検査ラインの判定とトレーサビリティが代表的な適用領域です。

• 検査ラインでのCVベース判定：Windows AIを搭載したラインPC上でFoundry Local + Windows MLを用いた高速推論
• トレーサビリティの統合：Azure IoT HubとMicrosoft Fabricを組み合わせ、部品ロットごとの履歴を一元管理
• 不良傾向の長期解析：FabricのData Warehouse機能でロット間の比較や歴史的トレンドを解析

検査判定そのものはエッジで実行し、トレーサビリティと長期解析はFabric側で集約するという、役割分担型の構成が有効です。

FA・制御系

FA・制御系の領域では、AGV／AMR、協働ロボット、設備異常検知などにエージェント型Physical AIが広がっています。

• AGV／AMR制御へのエージェント型AI適用：General Robotics型のreason／plan／collaborate／actアーキテクチャを採用
• 設備異常検知：Azure IoT EdgeとFoundry Localを組み合わせ、エッジで一次判定、クラウドで二次解析
• 協働ロボットの判断統合：OM1のようなオーケストレーション層を用いて、ハードウェアを跨いだ判断統合

特にAGV／AMRの制御では、Foundry Agent Serviceでエージェントの構築・運用基盤を整え、OM1のようなハードウェア非依存のオーケストレーション層と組み合わせることで、異なるハードウェアをまたぐ設計を検討しやすくなります。

まとめ

本記事では、Build 2026を起点に、WindowsとNVIDIAが連携して進めるPhysical AIの現在地、Microsoft × NVIDIA連携の三本柱、NVIDIA RTX SparkとSurface RTX Spark Dev Box、Project Solara、Azure LocalとFoundry Local、ロボティクスのエージェント化、マルチモーダルデータパイプライン、製造業エッジAIの想定ユースケースまでをご紹介しました。

Build 2026のPhysical AI関連発表を整理すると、ロボティクスだけでなく、映像・音声・PDF・センサーデータを扱うマルチモーダル基盤も重要な要素になっています。Microsoft × NVIDIAの連携はFoundry × Omniverse × Fabricの三本柱で進み、開発機からクラウドまでをつなぐ統一スタックとして整備されつつあります。

東京エレクトロンデバイスでは、Windows AIとNVIDIA RTX Spark、Azure Local、Microsoft Foundryを組み合わせたPhysical AI基盤の構築を総合的にサポートしています。開発機の選定、エッジ実行基盤の設計、Microsoft Fabricを中心としたデータ統合、エージェントを用いたロボティクス連携まで、製造業エッジAIの導入に関するご相談をお受けしています。ご興味のある方はこちらからお問い合わせください。